Re: [PATCH v1 0/2] pinctrl / 8250_dw: Allow drivers to keep init pinctrl state until first open

[Doug Anderson]

Hi,

On Wed, Aug 12, 2026 at 12:00 AM Andy Shevchenko
<andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
>
> > What we need is we need to _assert_ chip select (make CS_N low) until
> > we know that the other side is powered.
>
> Isn't this dangerous? Some noise on the bus for whatever reason might produce
> undesired "communication".

I dunno about dangerous, but it's an extra hassle for software to get
right for sure.


> > ...we can't use the "opened" we've been talking about in UART because
> > there's no real idea of "open"ing a SPI bus. It's transaction
> > oriented.
>
> But any SPI message that is queued is basically an "open" stage. So, it sounds
> like SPI core should change pin control states when message is queued and when
> it's done. Like be coupled with runtime PM?

Certainly the SPI driver can change pin states between "bus idle" and
"message being sent". The SPI core can auto-runtime-pm the host and
the host can change between "idle" and "default" states. It all works
fine. The problem is that we have a 3rd state: remote device is
unpowered. The SPI core doesn't have this concept right now.


> > ...we can't use the normal "runtime pm" concept in SPI and start the
> > SPI bus in suspended state because the "runtime suspended" state of
> > the bus would want the chip select deasserted (CS_N high).
>
> Sounds like a PCB / electrical level of design issue. I would solve this
> by gating CS signal using power of the peripheral connected. Have you talked
> to your HW engineers about this problem?

Yup, this is often solved in hardware, but apparently not in our
hardware. Thus it becomes a "small matter of software". ;-) It looks
too late to change, in this case...


> > 2. Invent a "pwrseq" solution for SPI where we run a sequence of steps
> > (turning the regulator on) before probing the SPI bus, like other
> > "pwrseq" drivers. Of course, most of those are for "discoverable"
> > busses, but the idea of powering up a peripheral before probing the
> > bus it's on is similar. This seems an extreme amount of work.
>
> Btw, isn't there some development for the undiscoverable buses?

Right, "pwrseq" has been looked at for a bunch of busses, but I don't
think there's anything magical/generic that could just be applied to
SPI.


> > 3. Hack the "CS GPIO" to be controlled by the client. It looks like we
> > could fully move the GPIO (including the pinctrl in the DT) to the
> > client. Then the client could call spi_set_csgpiod() after it's turned
> > on the regulator. The client could have an "init" state for the GPIO
> > that keeps it low and then transition to "default" right before
> > calling spi_set_csgpiod().
>
> > Of everything, solution #3 doesn't seem terrible. I also still don't
> > totally hate the idea of extending the "init" state... Of course,
> > there's also some chance we can figure out other ways to get this
> > regulator turned on sooner.
>
> Yes, #3 seems okay, but wouldn't be even better to have some flag in
> SPI core or pin control on per message basis (see also above)?

It could certainly be interesting to add the "remote unpowered"
concept to the SPI core, where SPI device drivers could tell the SPI
core when they're powered or not and that could cause the SPI
controller driver to select a different pinctrl state. We'll have to
think about that when we're ready to upstream the driver for the
relevant SPI device...