BPI-R2 already has an on-board RTC

frank-w · September 2, 2018, 8:21am

thanks, like my fix

frank-w · October 23, 2018, 10:45am

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

jofri · October 24, 2018, 9:40pm

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

frank-w · October 25, 2018, 6:52am

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

frank-w · December 18, 2018, 11:58am

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

jofri · December 18, 2018, 1:42pm

Hello,

do you mean in your master branch?

frank-w · December 18, 2018, 1:44pm

i mean making it ready to post to linux-mediatek

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

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.

jofri · December 20, 2018, 9:03pm

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)

frank-w · December 21, 2018, 7:02am

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?

jofri · December 21, 2018, 9:17am

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

frank-w · December 21, 2018, 9:36am

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…

poweroff itself works
pmic-key works (power off on power-btn) after install acpid and configure like this: https://unix.stackexchange.com/a/473626

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)

frank-w · January 14, 2019, 7:37am

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

frank-w · April 3, 2019, 5:28pm

@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:

github.com

frank-w/BPI-R2-4.14/blob/0d04c20a919e3a7c0c7bfbdcbff1027ab3c23771/drivers/power/reset/mt6323-poweroff.c#L32


};


static struct mt6323_pwrc *mt_pwrc;


static void mt6323_do_pwroff(void)
{
	struct mt6323_pwrc *pwrc = mt_pwrc;
	unsigned int val;
	int ret;


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


	ret = regmap_read_poll_timeout(pwrc->regmap,
					pwrc->base + RTC_BBPU, val,
					!(val & RTC_BBPU_CBUSY),
					MTK_RTC_POLL_DELAY_US,
					MTK_RTC_POLL_TIMEOUT);
	if (ret)
		dev_err(pwrc->dev, "failed to write BBPU: %d\n", ret);

github.com

frank-w/BPI-R2-4.14/blob/4da7b54690665353f469799733d689e23d5b7407/include/linux/mfd/mt6397/rtc.h#L17


*/


#ifndef _LINUX_MFD_MT6397_RTC_H_
#define _LINUX_MFD_MT6397_RTC_H_


#include <linux/jiffies.h>
#include <linux/mutex.h>
#include <linux/regmap.h>
#include <linux/rtc.h>


#define RTC_BBPU		0x0000
#define RTC_BBPU_CBUSY		BIT(6)
#define RTC_BBPU_KEY            (0x43 << 8)


#define RTC_WRTGR		0x003c


#define RTC_IRQ_STA		0x0002
#define RTC_IRQ_STA_AL		BIT(0)
#define RTC_IRQ_STA_LP		BIT(3)


#define RTC_IRQ_EN		0x0004

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

frank-w · April 17, 2019, 1:18am

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

frank-w · April 24, 2019, 3:56pm

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

github.com

frank-w/BPI-R2-4.14/blob/0d04c20a919e3a7c0c7bfbdcbff1027ab3c23771/drivers/power/reset/mt6323-poweroff.c#L55




	WARN_ONCE(1, "Unable to power off system\n");
}


static int mt6323_pwrc_probe(struct platform_device *pdev)
{
	struct mt6397_chip *mt6397_chip = dev_get_drvdata(pdev->dev.parent);
	struct mt6323_pwrc *pwrc;
	struct resource *res;


	pwrc = devm_kzalloc(&pdev->dev, sizeof(*pwrc), GFP_KERNEL);
	if (!pwrc)
		return -ENOMEM;


	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
	pwrc->base = res->start;
	pwrc->regmap = mt6397_chip->regmap;
	pwrc->dev = &pdev->dev;
	mt_pwrc = pwrc;


	pm_power_off = &mt6323_do_pwroff;

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

github.com

frank-w/BPI-R2-4.14/blob/0d04c20a919e3a7c0c7bfbdcbff1027ab3c23771/include/linux/mfd/mt6397/core.h#L56


	MT6397_IRQ_VSRMCA15,
	MT6397_IRQ_VCORE,
	MT6397_IRQ_VGPU,
	MT6397_IRQ_VIO18,
	MT6397_IRQ_VPCA7,
	MT6397_IRQ_VSRMCA7,
	MT6397_IRQ_VDRM,
	MT6397_IRQ_NR,
};


struct mt6397_chip {
	struct device *dev;
	struct regmap *regmap;
	int irq;
	struct irq_domain *irq_domain;
	struct mutex irqlock;
	u16 wake_mask[2];
	u16 irq_masks_cur[2];
	u16 irq_masks_cache[2];
	u16 int_con[2];
	u16 int_status[2];

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:

github.com

frank-w/BPI-R2-4.14/blob/4936eef446407425fa52974cc996606b3f0a8070/drivers/soc/mediatek/mtk-pmic-wrap.c#L1132


static int pwrap_write16(struct pmic_wrapper *wrp, u32 adr, u32 wdata)
{
	int ret;


	ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle);
	if (ret) {
		pwrap_leave_fsm_vldclr(wrp);
		return ret;
	}


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


	return 0;
}


static int pwrap_write32(struct pmic_wrapper *wrp, u32 adr, u32 wdata)
{
	int ret, msb, rdata;


	for (msb = 0; msb < 2; msb++) {

Virnik · December 12, 2024, 3:35pm

Didn’t help in my case. The module was loaded as a dependency, despite not being built-in, being blacklisted in both initramfs and rootfs…

So, my solution is more simple:

root@ap-unimatrix:~# rm /lib/modules/5.15.173-bpi-r2-main/kernel/drivers/input/keyboard/mtk-pmic-keys.ko

I could disable it in the kernel as well, but I understand that my use-case could be different from the others, and because I publish my kernel as well for others to use, I kept it there.