BPI-R2 already has an on-board RTC

thanks, like my fix :wink:

@jofri

it seems that poweroff from 4.19-rc1 is not compatible with 4.19 final. i have added 2 includes to get it compilable, but board does not poweroff completely

power consumption is 1 W instead of 0.2W and all leds are going in a darker mode, but lit all, also network-leds stay on

also in this strange mode reset-switch does not work

i also changed this because i load kernel from tftp

-CONFIG_RTC_DRV_MT6397=m
+CONFIG_RTC_DRV_MT6397=y

can help here again? it seems that the main files (drivers/mfd/mt6397-core.c, drivers/rtc/rtc-mt6397.c) are not changed in last time

https://patchwork.kernel.org/patch/10593453/ seems not to be merged…that was my first thought

@moore @linkerosa @Jackzeng can you help here? Something seems to be changed between rc1 and final (or rc7…had same behaviour while testing hdmi)

edit: mhm, it seems that tjis issue depends on any module…if i boot from sd-card with modules poweroff works like expected…if i boot kernel from tftp (only uImage) it does not working

Hello Frank,

So I have now tested 4.19. With me everything is as it should be at boot by sd. With tftp I have not tested, but are you sure that the kernel synonymous to the modules fits. “uname -a” and module-path.

Greetings

On tftp i have no modules (load only uimage) so i guess i need any module for this to work…this i want to make builtin. But i don’t know which module it is…the rtc and power are already builtin. Keyboard-pmic should be module for users who have soldered power-switch

@jofri can you try to make your Patch included in mainline?

Hello,

do you mean in your master branch?

i mean making it ready to post to linux-mediatek :wink:

like i did for dsa-patches and will do for fbdev if i get answer from CK Hu :slight_smile:

make a git format-patch and then a scripts/checkpatch.pl

https://github.com/frank-w/BPI-R2-4.14/commit/981dbf745c8c80300707ee2a5c1e25189b51a2e6.patch

this removes some code and i don’t know why…you have to describe it and maybe split into multiple parts. but when it is in mainline it will be maintained.

Hello Frank,

I inserted poweroff in your branch ‘origin / 4.20-rc’

(last commit 7dfcda746c0d50aae40839327753eda165320f9d)

and tested it with checkpatch.pl without error.

The compiler runs without errors. Unfortunately I can not check the kernel myself, because my R2 is in use elsewhere.

0001-add-doc-and-MAINTAINERS-for-poweroff.patch (4,4 KB) 0002-add-dts-for-poweroff.patch (1,1 KB) 0003-add-driver-and-MAINTAINERS-for-poweroff.patch (15,3 KB)

1 Like

Thank you,i test it as far as i can

btw. For multi-patch you need also cover-letter (description what series do) its a textfile beginning with 0000- (patch 0/x) created by format-patch --cover-letter

Is it necessary to remove rtc for poweroff?

Thanks, I’ve learned a lot here. A year ago, I did not start to mess with git. Also docuwiki arouses my interest.At the moment I am dealing with the BPI-W2. This is a big construction site.

no

a sorry, you move the code (to rtc.h) not remove it…

btw. i also started with git here with my first kernel (while getting 4.14 running (sd-card issue) )

you should drop my defconfig in your Patch because this does not exist on mainline (and brings warning because i’ve already set option while copy from 4.19)

will now compile and test it…

nano /etc/acpi/events/power

event=button/power

action=/sbin/poweroff

service acpid restart

rebased my 4.20-poweroff to avoid the warning (maybe will cause problems if i want to merge…but will not do this on rc)

@jofri have you tried to send it to mainline? Any problems? Have you created cover-letter?

@jofri any idea how to get poweroff working in uboot?

maybe we can implement it like this: https://patchwork.ozlabs.org/patch/1075860/

i don’t know how to convert linux regmap_write to uboot pmic_clrsetbits which seem to do similar

as far as i found in your patches this seems to be the key to power off the board:

which value is pwrc->base ? maybe it’s the same as REG_DEVCTRL for the rk8xx

1 Like

pwrc->base should be this (drivers/mfd/mt6397-core.c):

#define MT6323_PWRC_BASE	0x8000

regmap_write(dev,reg,val) is defined here: https://elixir.bootlin.com/linux/v4.19/source/drivers/base/regmap/regmap.c#L1778

writing in uboot:

pmic_reg_write(struct udevice *dev, uint reg, uint value)

maybe i can use this: http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/power/domain/mtk-power-domain.c;h=c67e8804b16f9355820882d95f30c4330ddef640;hb=9dec738a8b843bcdcf22ed3e11c59255e9f79d2b#l258 ?

currently it seems there is no pmic implemented yet, so i don’t know how i can get the device to set the register-value :frowning:

Mhm…uboot has also regmap_write…but how to get the regmap (first param)? I found no use in mt7623 patches in uboot,but regmap-config-option is set

http://patchwork.ozlabs.org/patch/667503/

In kernel the regmap is defined/allocated in probe

Imho i only need this:

struct mt6397_chip *mt6397_chip = dev_get_drvdata(pdev->dev.parent);
mt6397_chip->regmap;

how to get the pdev (passed to probe) in uboot and where does dev_get_drvdata reads the data?

Imho i need to define a platform-device in dts and a platform-driver struct,something like this:

static struct platform_driver mt6397_driver = {
    .probe = mt6397_probe,
    .remove = mt6397_remove,
    .driver = {
        .name = "mt6397",
        .of_match_table = of_mt6397_match
    }, 
};

But i still don’t understand where the regmap getting its data…here the parent-dev is used…this is the mt6323-node…maybe there is a shorter way without creating the full mt6323-node

Edit 24.10.2019:

Poweroff patches are finally prepared for mainline (5.5 merge window):

https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/log/?h=ib-mfd-power-rtc-5.5

https://patchwork.kernel.org/patch/11208473/

Any idea about poweroff in uboot?

edit 22th Nov 2019:

with the great help of @ray i got manually poweroff working in uboot:

mw 0x1000d09c 0xc0004300
mw 0x1000d09c 0xc01e0001

where register 1000d09c is pwrap-base (1000d000) + PWRAP_WACS2_CMD (0x9c) and value is calculated this way:

printf "%x\n" $(( (1 << 31) | ((0x8000 >> 1) << 16) | 0x4300 ))
c0004300
printf "%x\n" $(( (1 << 31) | ((0x803c >> 1) << 16) | 1 ))
c01e0001

based on linux access method:

WR4(wrp, PWRAP_WACS2_CMD, (1 << 31) | ((adr >> 1) << 16) | wdata);

here 0x8000 is MT6323_PWRC_BASE and 0x3c is the RTC_WRTGR

how it’s done in linux:

#define MT6323_PWRC_BASE 0x8000
#define RTC_BBPU 0x0000
#define RTC_BBPU_KEY (0x43 << 8)
#define RTC_WRTGR 0x003c

regmap_write(pwrc->regmap, pwrc->base + RTC_BBPU, RTC_BBPU_KEY);
regmap_write(pwrc->regmap, pwrc->base + RTC_WRTGR, 1);

with pmic-calculation:

1 Like