Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for max77620/max20024 RTC driver

[Krzysztof Kozlowski <k.kozlowski@xxxxxxxxxxx>]

W dniu 08.01.2016 o 19:20, Laxman Dewangan pisze:
> Hi Krzysztof,
> Thanks for review.
> 
> Accepted most of review comment and will update in next patch.
> 
> Answer to query:
> 
> 
> On Friday 08 January 2016 07:33 AM, Krzysztof Kozlowski wrote:
>> 2016-01-07 23:38 GMT+09:00 Laxman Dewangan <ldewangan@xxxxxxxxxx>:
>> ---
>>   drivers/rtc/Kconfig        |   9 +
>>   drivers/rtc/Makefile       |   1 +
>>   drivers/rtc/rtc-max77620.c | 574
>> +++++++++++++++++++++++++++++++++++++++++++++
>> The driver (as most of Maxim's) looks quite similar to existing RTC
>> driver, like max77802. It is difficult to spot the exact differences
>> (I don't have 77620's datasheet) but I would suggest not duplicating
>> the work. Maybe the biggest difference is the way you configure the
>> regmap... but still sometimes the regmap config can be shared.
> Yaah, that is the issue on IP based PMIC system and it happen with the
> Maxim and TI.
> The MFD and its sub module drivers are too much couped  and hence
> dificult to use the IP driver across PMIC. For almost all Maxim PMIC, we
> end up of same type of RTC driver.
> 
> Probably, we need to enhance the mfd sub system to allow sub module
> driver to decoupe from its APIs.

Actually the MFD and other subsystems are quite decoupled already and
support sharing drivers for common IP block. The problem is that we
develop drivers in a coupled way. This is not only issue of this
particular set of drivers. Others were developed in a same way.

So instead I would be happy to see this driver developed in the
decoupled way so existing RTC driver could be reused. If this requires
changing existing MFD driver like max77686 then please go ahead. I may
provide testing for that purpose. Something similar I made recently to
the max77693 and max77843. Both devices have different parent MFD
drivers but share some of the specific subsystem drivers: regulator and
input/haptic.

> 
> 
> +
> +       rtc->irq = platform_get_irq(pdev, 0);
> +       ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
> +                       max77620_rtc_irq, IRQF_ONESHOT | IRQF_EARLY_RESUME,
> 
>> Why early resume?
> 
> When we go on suspend, the interrupts are masked by framework. For
> regmap-irq, it is stored on local reg value but not written into the
> PMIC register.
> In Nvidia Tegra system, ARM GIC controller registered before the other
> interrupt controller like GPIO, PMIC etc.
> When wakeup happened through RTC alarm, we get the interrupt from PMIC
> and on resume path, the PMIC isr handler get called after PMIC interrupt
> to the GIC is unmasked. But at this time, PMIC RTC alarm is still in
> masked state by regmap-irq which causes the interrupt to RTC ignore in
> the PMIC ISR handler and so RTC Isr did not get called and not cleared
> interrupt. This causes PMIC ISr handler to stuck on loop.
> 
> The need is to unmask the RTC alarm interrupt on PMIC interrupt driver
> before PMIC interrupt served so that we can have proper interrupt status
> in handler and rtc isr can get called.
> 
> For this, RTC alarm interrupt need to be EARLY_RESUME.

Okay, this is quite common issue and I think this can be solved by
disabling the IRQ in suspend:
http://lxr.free-electrons.com/source/drivers/mfd/max77843.c#L205

IMHO this would be preferred way because you won't be moving device
suspend/resume callbacks to a syscore level.

Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html