lkml.org 
[lkml]   [2020]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: [PATCH/RFC v4 2/4] regulator: fixed: add regulator_ops members for suspend/resume
    Date
    Hi Mark,

    > From: Mark Brown, Sent: Monday, June 29, 2020 9:58 PM
    >
    > On Mon, Jun 29, 2020 at 02:42:26AM +0000, Yoshihiro Shimoda wrote:
    > > > From: Mark Brown, Sent: Friday, June 26, 2020 11:39 PM
    >
    > Copying in Sudeep for the feedback on firmware interfaces.

    Thank you very much for the discussion about the firmware.

    > > > According to the changelog this is all about reflecting changes in the
    > > > system state done by firmware but there's no interaction with firmware
    > > > here which means this will be at best fragile. If we need to reflect
    > > > changes in firmware configuration I'd expect there to be some
    > > > interaction with firmware about how it is configured, or at least that
    > > > the configuration would come from the same source.
    >
    > > I should have described background of previous patch series though,
    > > according to previous discussion [1] the firmware side (like PSCI) is
    > > also fragile unfortunately... So, I thought using regulator-off-in-suspend
    > > in a regulator was better.
    >
    > > On other hand, Ulf is talking about either adding a property (perhaps like
    > > regulator-off-in-suspend) into a regulator or just adding a new property
    > > into MMC [2]. What do you think about Ulf' comment? I'm thinking
    > > adding a new property "full-pwr-cycle-in-suspend" is the best solution.
    > > This is because using a regulator property and reflecting a state of regulator without
    > > firmware is fragile, as you said.
    >
    > TBH I worry about a property drifting out of sync with the firmware on
    > systems where the firmware can be updated.

    I understood it.

    > Personally my default
    > assumption would always be that we're going to loose power for anything
    > except the RAM and whatever is needed for wake sources during suspend so
    > I find the discussion a bit surprising but in any case that seems like a
    > better option than trying to shoehorn things in the way the series here
    > did.

    Thank you for your comment! So, I'll make such a patch series later.

    > Like I said in my earlier replies if this is done through the
    > regulator API I'd expect it to be via the suspend interface.

    I don't intend to use any regulator API for this issue for now.

    Best regards,
    Yoshihiro Shimoda

    > > [1]
    > > https://lore.kernel.org/linux-renesas-soc/CAMuHMdXjU7N4oG89YsozGijMpjgKGN6ezw2qm6FeGX=JyRhsvg@mail.gmail.com/
    > >
    > > [2]
    > > https://lore.kernel.org/linux-renesas-soc/CAPDyKFpiBU1D+a7zb+Ggm0_HZ+YR4=LXJZ5MPytXtT=uBEdjPA@mail.gmail.com/
    > >
    > > Best regards,
    > > Yoshihiro Shimoda
    > >

    \
     
     \ /
      Last update: 2020-06-30 10:30    [W:3.408 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site