Re: [PATCH V3 5/5] rtc: max77686: move initialisation of rtc regmap, irq chip locally

[Laxman Dewangan]

Hi Javier,

On Thursday 04 February 2016 07:33 AM, Laxman Dewangan wrote:
> On Thursday 04 February 2016 05:40 AM, Krzysztof Kozlowski wrote:
> > On 03.02.2016 22:47, Laxman Dewangan wrote:
> > > Changes from V2:
> > > - Taken care of missed sequence for removing the resource.
> > > - Fix the crash when doing unbind by using requested_threaded_irq()
> > >    instead of demv_requested_threaded_irq().
> > >
> > >   drivers/mfd/max77686.c               |  85 +-------------------
> > >   drivers/rtc/rtc-max77686.c           | 148 
> > > ++++++++++++++++++++++++++++++-----
> > >   include/linux/mfd/max77686-private.h |   3 -
> > >   3 files changed, 130 insertions(+), 106 deletions(-)
> > Looks good and works properly (RTC, unbind/rebind, wakealarm again)
> > but... after applying this patch the device cannot suspend to RAM after
> > unbind/rebind.
> >
> > Reproduce path, after booting:
> > $ echo max77686-rtc > /sys/bus/platform/drivers/max77686-rtc/unbind
> > $ echo max77686-rtc > /sys/bus/platform/drivers/max77686-rtc/bind
> > $ rtcwake -d rtc2 -m mem -s 5 -v
> > (or instead of rtcwake: echo mem > /sys/power/state)

Can you please also try to test in your setup which have MAX77802?
On this, we do not create i2c client and do regmap_init_i2c. So may be 
it helps on narrow down the issue.

> My device does not support suspend and hence I can nto test this part 
> and need your help to debug it.
>
> Few question to narrow down:
> 1. Have you try to bind/unbind mfd driver to make sure that there is 
> no inherent issue in the framework driver?
>
> 2. Does suspend entry and wake alarm work if you dont do unbind and 
> just bind it and enter into suspend?
>
> 3. Can you try locally to not use devm_regmap_init_i2c() and just use 
> the regmap_init_i2c() and proper removal of this from error path and 
> remove callback?
>
>
>
> Three things we are doing new on this movement, i2c client creating, 
> regmap_init and adding irq chip.
> And probably some issue on this calls?
> Let's try with not using devm_ * for this calls?