It's unclear why many of static registers were marked as volatile.
They are pretty much bidirectional and static in a sense that
written value is kept there until a new write or chip reset.
Drop those registers from the list to allow them to be cached.
Signed-off-by: Andy Shevchenko <[email protected]>
---
drivers/pinctrl/pinctrl-cy8c95x0.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-cy8c95x0.c b/drivers/pinctrl/pinctrl-cy8c95x0.c
index 521acfdeef38..5ef772d29a36 100644
--- a/drivers/pinctrl/pinctrl-cy8c95x0.c
+++ b/drivers/pinctrl/pinctrl-cy8c95x0.c
@@ -303,17 +303,6 @@ static bool cy8c95x0_volatile_register(struct device *dev, unsigned int reg)
switch (reg) {
case CY8C95X0_INPUT_(0) ... CY8C95X0_INPUT_(7):
case CY8C95X0_INTSTATUS_(0) ... CY8C95X0_INTSTATUS_(7):
- case CY8C95X0_INTMASK:
- case CY8C95X0_INVERT:
- case CY8C95X0_PWMSEL:
- case CY8C95X0_DIRECTION:
- case CY8C95X0_DRV_PU:
- case CY8C95X0_DRV_PD:
- case CY8C95X0_DRV_ODH:
- case CY8C95X0_DRV_ODL:
- case CY8C95X0_DRV_PP_FAST:
- case CY8C95X0_DRV_PP_SLOW:
- case CY8C95X0_DRV_HIZ:
return true;
}
--
2.35.1
On Fri, Sep 2, 2022 at 9:36 PM Andy Shevchenko
<[email protected]> wrote:
>
> It's unclear why many of static registers were marked as volatile.
the static (yeah, forgot it)
> They are pretty much bidirectional and static in a sense that
> written value is kept there until a new write or chip reset.
> Drop those registers from the list to allow them to be cached.
This patch is not correct due to indexing access. It's sneaked since I
forgot I added it into my main repo. The proper approach should be to
create virtual registers and decode them before use. This allows to
cache all ports and as a benefit to debug print all port actual
statuses.
--
With Best Regards,
Andy Shevchenko
On Fri, Sep 02, 2022 at 09:42:00PM +0300, Andy Shevchenko wrote:
> On Fri, Sep 2, 2022 at 9:36 PM Andy Shevchenko
> <[email protected]> wrote:
> >
> > It's unclear why many of static registers were marked as volatile.
>
> the static (yeah, forgot it)
>
> > They are pretty much bidirectional and static in a sense that
> > written value is kept there until a new write or chip reset.
> > Drop those registers from the list to allow them to be cached.
>
> This patch is not correct due to indexing access. It's sneaked since I
> forgot I added it into my main repo. The proper approach should be to
> create virtual registers and decode them before use. This allows to
> cache all ports and as a benefit to debug print all port actual
> statuses.
To be clear: With this one removed from the bunch the rest can be applied w.o.
any change.
--
With Best Regards,
Andy Shevchenko
On Mon, Sep 5, 2022 at 4:34 PM Linus Walleij <[email protected]> wrote:
> On Mon, Sep 5, 2022 at 2:57 PM Andy Shevchenko
> <[email protected]> wrote:
> > On Fri, Sep 02, 2022 at 09:42:00PM +0300, Andy Shevchenko wrote:
> > > On Fri, Sep 2, 2022 at 9:36 PM Andy Shevchenko
> > > <[email protected]> wrote:
> > > >
> > > > It's unclear why many of static registers were marked as volatile.
> > >
> > > the static (yeah, forgot it)
> > >
> > > > They are pretty much bidirectional and static in a sense that
> > > > written value is kept there until a new write or chip reset.
> > > > Drop those registers from the list to allow them to be cached.
> > >
> > > This patch is not correct due to indexing access. It's sneaked since I
> > > forgot I added it into my main repo. The proper approach should be to
> > > create virtual registers and decode them before use. This allows to
> > > cache all ports and as a benefit to debug print all port actual
> > > statuses.
> >
> > To be clear: With this one removed from the bunch the rest can be applied w.o.
> > any change.
>
> I'll give Patrick a day or two to test/review and then I'll just apply
> them all except this one, they are all pretty self-evident
Sure!
> except ACPI
> things which have obviously been tested on hardware
Yes, I have a Galileo Gen 1 board which has been used for testing.
> so from my
> point of view it's good to merge.
Thanks!
--
With Best Regards,
Andy Shevchenko
On Mon, Sep 5, 2022 at 2:57 PM Andy Shevchenko
<[email protected]> wrote:
> On Fri, Sep 02, 2022 at 09:42:00PM +0300, Andy Shevchenko wrote:
> > On Fri, Sep 2, 2022 at 9:36 PM Andy Shevchenko
> > <[email protected]> wrote:
> > >
> > > It's unclear why many of static registers were marked as volatile.
> >
> > the static (yeah, forgot it)
> >
> > > They are pretty much bidirectional and static in a sense that
> > > written value is kept there until a new write or chip reset.
> > > Drop those registers from the list to allow them to be cached.
> >
> > This patch is not correct due to indexing access. It's sneaked since I
> > forgot I added it into my main repo. The proper approach should be to
> > create virtual registers and decode them before use. This allows to
> > cache all ports and as a benefit to debug print all port actual
> > statuses.
>
> To be clear: With this one removed from the bunch the rest can be applied w.o.
> any change.
I'll give Patrick a day or two to test/review and then I'll just apply
them all except this one, they are all pretty self-evident except ACPI
things which have obviously been tested on hardware so from my
point of view it's good to merge.
Yours,
Linus Walleij
Hi,
I've tested the patch series on my OpenBMC platform and it works fine.
I don't think it's worth the effort to implement virtual registers for
the muxed pin configuration,
but I won't stop you.
Regards,
Patrick
On Mon, Sep 5, 2022 at 3:37 PM Andy Shevchenko
<[email protected]> wrote:
>
> On Mon, Sep 5, 2022 at 4:34 PM Linus Walleij <[email protected]> wrote:
> > On Mon, Sep 5, 2022 at 2:57 PM Andy Shevchenko
> > <[email protected]> wrote:
> > > On Fri, Sep 02, 2022 at 09:42:00PM +0300, Andy Shevchenko wrote:
> > > > On Fri, Sep 2, 2022 at 9:36 PM Andy Shevchenko
> > > > <[email protected]> wrote:
> > > > >
> > > > > It's unclear why many of static registers were marked as volatile.
> > > >
> > > > the static (yeah, forgot it)
> > > >
> > > > > They are pretty much bidirectional and static in a sense that
> > > > > written value is kept there until a new write or chip reset.
> > > > > Drop those registers from the list to allow them to be cached.
> > > >
> > > > This patch is not correct due to indexing access. It's sneaked since I
> > > > forgot I added it into my main repo. The proper approach should be to
> > > > create virtual registers and decode them before use. This allows to
> > > > cache all ports and as a benefit to debug print all port actual
> > > > statuses.
> > >
> > > To be clear: With this one removed from the bunch the rest can be applied w.o.
> > > any change.
> >
> > I'll give Patrick a day or two to test/review and then I'll just apply
> > them all except this one, they are all pretty self-evident
>
> Sure!
>
> > except ACPI
> > things which have obviously been tested on hardware
>
> Yes, I have a Galileo Gen 1 board which has been used for testing.
>
> > so from my
> > point of view it's good to merge.
>
> Thanks!
>
> --
> With Best Regards,
> Andy Shevchenko
On Tue, Sep 6, 2022 at 11:36 AM Patrick Rudolph
<[email protected]> wrote:
>
> Hi,
> I've tested the patch series on my OpenBMC platform and it works fine.
Thank you!
I guess we may consider this as an equivalent to the formal Tested-by tag?
> I don't think it's worth the effort to implement virtual registers for
> the muxed pin configuration,
> but I won't stop you.
It's not a high priority to me anyway, but it is a good feature to
have since regmap allows us to dump registers. Moreover the listing
files in debugfs currently take a lot of time, that's how I come up
with this.
> On Mon, Sep 5, 2022 at 3:37 PM Andy Shevchenko
> <[email protected]> wrote:
> >
> > On Mon, Sep 5, 2022 at 4:34 PM Linus Walleij <[email protected]> wrote:
> > > On Mon, Sep 5, 2022 at 2:57 PM Andy Shevchenko
> > > <[email protected]> wrote:
> > > > On Fri, Sep 02, 2022 at 09:42:00PM +0300, Andy Shevchenko wrote:
> > > > > On Fri, Sep 2, 2022 at 9:36 PM Andy Shevchenko
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > It's unclear why many of static registers were marked as volatile.
> > > > >
> > > > > the static (yeah, forgot it)
> > > > >
> > > > > > They are pretty much bidirectional and static in a sense that
> > > > > > written value is kept there until a new write or chip reset.
> > > > > > Drop those registers from the list to allow them to be cached.
> > > > >
> > > > > This patch is not correct due to indexing access. It's sneaked since I
> > > > > forgot I added it into my main repo. The proper approach should be to
> > > > > create virtual registers and decode them before use. This allows to
> > > > > cache all ports and as a benefit to debug print all port actual
> > > > > statuses.
> > > >
> > > > To be clear: With this one removed from the bunch the rest can be applied w.o.
> > > > any change.
> > >
> > > I'll give Patrick a day or two to test/review and then I'll just apply
> > > them all except this one, they are all pretty self-evident
> >
> > Sure!
> >
> > > except ACPI
> > > things which have obviously been tested on hardware
> >
> > Yes, I have a Galileo Gen 1 board which has been used for testing.
> >
> > > so from my
> > > point of view it's good to merge.
> >
> > Thanks!
--
With Best Regards,
Andy Shevchenko
On Mon, Sep 5, 2022 at 3:30 PM Linus Walleij <[email protected]> wrote:
> On Mon, Sep 5, 2022 at 2:57 PM Andy Shevchenko
> <[email protected]> wrote:
> > On Fri, Sep 02, 2022 at 09:42:00PM +0300, Andy Shevchenko wrote:
> > > On Fri, Sep 2, 2022 at 9:36 PM Andy Shevchenko
> > > <[email protected]> wrote:
> > > >
> > > > It's unclear why many of static registers were marked as volatile.
> > >
> > > the static (yeah, forgot it)
> > >
> > > > They are pretty much bidirectional and static in a sense that
> > > > written value is kept there until a new write or chip reset.
> > > > Drop those registers from the list to allow them to be cached.
> > >
> > > This patch is not correct due to indexing access. It's sneaked since I
> > > forgot I added it into my main repo. The proper approach should be to
> > > create virtual registers and decode them before use. This allows to
> > > cache all ports and as a benefit to debug print all port actual
> > > statuses.
> >
> > To be clear: With this one removed from the bunch the rest can be applied w.o.
> > any change.
>
> I'll give Patrick a day or two to test/review and then I'll just apply
> them all except this one, they are all pretty self-evident except ACPI
> things which have obviously been tested on hardware so from my
> point of view it's good to merge.
I applied all patches now except this one (3/17), some patches needed
a bit of fuzzing because other stuff in my tree, so please check the
result once it lands in linux-next.
Yours,
Linus Walleij
On Thu, Sep 08, 2022 at 10:03:38AM +0200, Linus Walleij wrote:
> On Mon, Sep 5, 2022 at 3:30 PM Linus Walleij <[email protected]> wrote:
> > On Mon, Sep 5, 2022 at 2:57 PM Andy Shevchenko
> > <[email protected]> wrote:
> > > On Fri, Sep 02, 2022 at 09:42:00PM +0300, Andy Shevchenko wrote:
> > > > On Fri, Sep 2, 2022 at 9:36 PM Andy Shevchenko
> > > > <[email protected]> wrote:
> > > > >
> > > > > It's unclear why many of static registers were marked as volatile.
> > > >
> > > > the static (yeah, forgot it)
> > > >
> > > > > They are pretty much bidirectional and static in a sense that
> > > > > written value is kept there until a new write or chip reset.
> > > > > Drop those registers from the list to allow them to be cached.
> > > >
> > > > This patch is not correct due to indexing access. It's sneaked since I
> > > > forgot I added it into my main repo. The proper approach should be to
> > > > create virtual registers and decode them before use. This allows to
> > > > cache all ports and as a benefit to debug print all port actual
> > > > statuses.
> > >
> > > To be clear: With this one removed from the bunch the rest can be applied w.o.
> > > any change.
> >
> > I'll give Patrick a day or two to test/review and then I'll just apply
> > them all except this one, they are all pretty self-evident except ACPI
> > things which have obviously been tested on hardware so from my
> > point of view it's good to merge.
>
> I applied all patches now except this one (3/17), some patches needed
> a bit of fuzzing because other stuff in my tree, so please check the
> result once it lands in linux-next.
Looks perfect, thanks!
--
With Best Regards,
Andy Shevchenko