On 08/11/2023 16:58, Laurent Pinchart wrote:
On Wed, Nov 08, 2023 at 04:34:39PM +0100, Maxime Ripard wrote:
On Tue, Nov 07, 2023 at 04:26:34PM +0100, Greg Kroah-Hartman wrote:
On Tue, Nov 07, 2023 at 01:18:14PM +0100, Maxime Ripard wrote:
On Tue, Nov 07, 2023 at 12:22:21PM +0100, Greg Kroah-Hartman wrote:
On Tue, Nov 07, 2023 at 11:57:49AM +0100, Maxime Ripard wrote:
+GKH
Why? I don't see a question for me here, sorry.
I guess the question is: we have a bus with various power states
(powered off, low power, high speed)
Great, have fun! And is this per-device or per-bus-instance?
Per bus instance
To be precise, those power states are link states. They don't
necessarily translate directly to device power states, and they're not
so much about power management than speed (and bus turn-around for
reads) management.
So the DSI core should support handling and tracking the current DSI
link state, and DSI devices should be able to request for a particular
link state.
Also, while DSI allows for multiple peripherals on a bus, the link is
point-to-point, with the peripherals being all behind a single DSI RX. >
low power is typically used to send commands to a device, high speed to
transmit pixels, but still allows to send commands.
Low power (LP) is a link state where commands can be transmitted at a
low speed, as opposed to the high speed (HS) link state that is used to
transmit both video data and commands at high speed. Any device-to-host
data transfer (in response to read commands) occurs exclusively in LP
mode (at least with DSI v1.3, I don't have acces to newer
specifications).
Depending on the devices, there's different requirements about the state
devices expect the bus to be in to send commands. Some will need to send
all the commands in the low power state, some don't care, etc. See
the mail I was replying too for more details.
We've tried so far to model that in KMS itself, so the framework the
drivers would register too, but we're kind of reaching the limits of
what we can do there. It also feels to me that "the driver can't access
its device" is more of a problem for the bus to solve rather than the
framework.
This is up to the specific bus to resolve, there's nothing special
needed in the driver core for it, right?
Yeah, we weren't really looking to handle this into the driver core, but
rather if there was a set of guidelines or feedback on implementing
those kind of features for a bus.
Do you agree? Are you aware of any other bus in Linux with similar
requirements we could look at? Or any suggestion on how to solve it?
There might be others, yes, look at how the dynamic power management
works for different devices on most busses, that might help you out
here.
Thanks for the pointers, we'll have a look
