lkml.org 
[lkml]   [2022]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v1 5/5] pinctrl: microchip-sgpio: wait until output is actually set
    Hi Horatiu,

    Am 2022-03-04 13:09, schrieb Horatiu Vultur:
    > The 02/25/2022 12:29, Michael Walle wrote:
    >> EXTERNAL EMAIL: Do not click links or open attachments unless you know
    >> the content is safe
    >>
    >> Hi Horatiu,
    >>
    >> Am 2022-02-25 10:24, schrieb Horatiu Vultur:
    >> > The 02/24/2022 17:10, Michael Walle wrote:
    >> > > Right now, when a gpio value is set, the actual hardware pin gets set
    >> > > asynchronously. When linux write the output register, it takes some
    >> > > time
    >> > > until it is actually propagated to the output shift registers. If that
    >> > > output port is connected to an I2C mux for example, the linux driver
    >> > > assumes the I2C bus is already switched although it is not.
    >> > >
    >> > > Fortunately, there is a single shot mode with a feedback: you can
    >> > > trigger the single shot and the hardware will clear that bit once it
    >> > > has
    >> > > finished the clocking and strobed the load signal of the shift
    >> > > registers. This can take a considerable amount of time though.
    >> > > Measuremens have shown that it takes up to a whole burst cycle gap
    >> > > which
    >> > > is about 50ms on the largest setting. Therefore, we have to mark the
    >> > > output bank as sleepable. To avoid unnecessary waiting, just trigger
    >> > > the
    >> > > single shot if the value was actually changed.
    >> >
    >> > I have tested this patch series on our lan9668 board and it worked
    >> > fine. Thanks!
    >>
    >> Thanks for testing!
    >>
    >> > I just have few questions:
    >> > 1. What about other boards/chips that have this sgpio, do they have
    >> > also
    >> > the same issue? Because from what I recall on sparx5 they don't have
    >> > this issue. I have seen it only on lan9668.
    >>
    >> Unfortunatly, I don't have any knowledge what IP core is used in
    >> which SoC. I assumed the lan9668 used the same as the sparx5. If
    >> that is not the case, we need a new compatible. Do you know if it
    >> the same?
    >
    > From what I see, it is the same IP.

    Good to know.

    >> On the sparx5 are there any peripheral who you would actually
    >> notice that the timing is off?
    >
    > There are some SFP connected, similar to lan966x. So I don't understand
    > why that issue is not seen there.

    Is there an I2C mux, too? Or just the SFP signals connected to
    the SGPIO? What I was seeing is that during probing of the SFPs
    the SFPs EEPROM is read and when the I2C mux is controlled by the
    SGPIO it will switch too late - or even worse, in the middle of
    a transaction. I would speculate the timing isn't that critical
    with signals just connected directly to the SFP.

    In any case, I think it is pretty clear that it cannot work the
    way it is right now, no? See the very next paragraph...

    >> That being said, I'd assume all the serial gpio controller has
    >> this "flaw". Simply because a register write won't block until the
    >> value is shifted out to the shift register and actualy loaded by
    >> strobing the load signal. It just depends on your burst setting
    >> (even with bursts off, and clocking all the time) on how large
    >> the delay is. So you might or might not notice it on a board.

    .. here

    -michael

    \
     
     \ /
      Last update: 2022-03-04 13:47    [W:3.661 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site