Re: [PATCH v8 4/5] rtc: mt6397: Add support for the MediaTek MT6358 RTC

[Yingjoe Chen <yingjoe.chen@mediatek.com>]

On Thu, 2020-03-05 at 15:37 +0800, Ran Bi wrote:
> Hi,
> 
> On Wed, 2020-03-04 at 20:59 +0800, Nicolas Boichat wrote:
> > Hi,
> > 
> > On Mon, Feb 17, 2020 at 11:52 AM Ran Bi <ran.bi@mediatek.com> wrote:
> > >
> > > On Tue, 2020-02-04 at 00:50 +0800, Yingjoe Chen wrote:

<....>

> > > >
> > > > Putting these in header file doesn't looks right to me.
> > > > Who need this? can you move them back to rtc-mt6397.c?
> > > > Joe.C
> > > >
> > >
> > > This could also effect kernel/drivers/power/reset/mt6323-poweroff.c
> > > which using same region of RTC registers.
> > > There are 2 ways of modification:
> > > 1. kernel/drivers/rtc/rtc-mt6397.c implement do_pwroff function and
> > > export to mt6323-poweroff.c
> > > 2. Just modify mt6323-poweroff.c file to compatible this patch. I mean
> > > using RTC_WRTGR_MT6397 to replace RTC_WRTGR. Or modify mt6323-poweroff.c
> > > like rtc-mt6397.c
> > 
> > Oh, I see, so basically both rtc-mt6397.c and mt6323-poweroff.c need
> > to know at what offset RTC_WRTGR actually is. Correct?
> > 
> 
> Yes, you are right both drivers need to know RTC_WRTGR offset. Offsets
> of other registers are the same.
> 
> > Is there any plan to have mt6323-poweroff.c support any of the other
> > PMICs (not just MT6323?)?
> > 
> 
> Currently, we don't have a plan to let mt6323-poweroff.c support other
> PMICs. Because other PMICs like mt6397 and mt6358 could using
> arm-trust-firmware PSCI power off flow instead. mt6323-poweroff.c was
> prepared for platform without arm-trust-firmware.

This depends on SoC instead of PMIC.
We will need mt6323-poweroff.c for soc with armv7 CPU, because we won't
have ATF on them. I'm not aware of new plan for this.


> > a. If not, I'd just add:
> > #define RTC_WRTGR_MT6323 RTC_WRTGR_MT6397
> > in rtc.h, for added clarity, use that in mt6323-poweroff.c
> > (s/RTC_WRTGR/RTC_WRTGR_MT6323/), and be done with it.
> > 
> 
> I would just change RTC_WRTGR to RTC_WRTGR_MT6397 in mt6323-poweroff.c
> at next patchset.
> 
> > Actually, even if there's a plan, you can go ahead with this simpler
> > solution for now, and fix later when the issue comes up.
> > 
> > b. If you ever want to support multiple PMICs with mt6323-poweroff.c,
> > you'd need that offset for 2 different sub-devices under the same mfd,
> > so the matching logic belongs in the main mfd device, not in
> > rtc/poweroff driver.
> > 
> > So I'd move the matching logic in drivers/mfd/mt6397-core.c, and add
> > rtc_wrtgr offset (or a full _data structure) to `struct mt6397_chip`,
> > or, probably better, add a IORESOURCE_REG to the matching resources to
> > specify the offset (that's what drivers/mfd/88pm860x-core.c seems to
> > be doing, for example).
> > 
> > And then mt6323-poweroff.c should probably be renamed to mt6397-poweroff.c.
> > 
> > (actually, looking at this, I'm even questioning if mt6323-poweroff.c
> > should even exist, and if you should just fold it into rtc-mt6397.c?
> > Since they use the same registers?)
> > 
> 
> mt6323-poweroff.c which hijack pm_power_off pointer is only for platform
> without arm-trust-firmware. This is the reason I am considering
> mt6323-poweroff.c should not be folded into rtc-mt6397.c.


Using/sharing same set of registers from different drivers is not good: 

- WRTGR is a special register to 'commit' previous changes. If 2 drivers
are running at the same time, it is possible to commit incomplete update
and cause unexpected result. It is easier to control this from same
driver.

- It is easy to overlook the register is access by others and lead to
bugs/build fails when doing driver update, eg, this patchset.

- The trigger code is duplicate in mt6323-poweroff.c, can just call
mtk_rtc_write_trigger.


So I agree with Nicolas, mt6323-poweroff should be folded into
rtc-mt6397.c. We should be able to disable pm_power_off hijacking for
platform with armV8 CPU. Maybe we can keep "mediatek,mt6323-pwrc"
compatible in mt6323-poweroff.c for this.

I'm ok with implement a. as suggested by Nicolas for now.

Joe.C