| Message ID | 20230330101752.429804-2-francesco@dolcini.it (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/bridge: ti-sn65dsi83: Add DSI video mode configuration | expand |
On Thu, Mar 30, 2023 at 3:48 PM Francesco Dolcini <francesco@dolcini.it> wrote: > > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > SN65DSI8[34] device supports burst video mode and non-burst video mode > with sync events or with sync pulses packet transmission as described in > the DSI specification. > > Add property to select the expected mode, this allows for example to > select a mode that is compatible with the DSI host interface. > > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > --- > .../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > index 48a97bb3e2e0..ebee16726b02 100644 > --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > @@ -35,6 +35,14 @@ properties: > vcc-supply: > description: A 1.8V power supply (see regulator/regulator.yaml). > > + dsi-video-mode: > + description: | > + 0 - burst-mode > + 1 - non-burst with sync event > + 2 - non-burst with sync pulse > + $ref: /schemas/types.yaml#/definitions/uint32 > + enum: [0, 1, 2] I'm thinking this can go to dsi common code since the video modes are common across all controllers and make the core initialize the default and update if any sink devices are willing to change the modes. Sound like a big move but worth useful. Thanks, Jagan.
On Thu, Mar 30, 2023 at 07:56:26PM +0530, Jagan Teki wrote: > On Thu, Mar 30, 2023 at 3:48 PM Francesco Dolcini <francesco@dolcini.it> wrote: > > > > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > SN65DSI8[34] device supports burst video mode and non-burst video mode > > with sync events or with sync pulses packet transmission as described in > > the DSI specification. > > > > Add property to select the expected mode, this allows for example to > > select a mode that is compatible with the DSI host interface. > > > > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > > --- > > .../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > > index 48a97bb3e2e0..ebee16726b02 100644 > > --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > > +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > > @@ -35,6 +35,14 @@ properties: > > vcc-supply: > > description: A 1.8V power supply (see regulator/regulator.yaml). > > > > + dsi-video-mode: > > + description: | > > + 0 - burst-mode > > + 1 - non-burst with sync event > > + 2 - non-burst with sync pulse > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + enum: [0, 1, 2] > > I'm thinking this can go to dsi common code since the video modes are > common across all controllers and make the core initialize the default > and update if any sink devices are willing to change the modes. Sound > like a big move but worth useful. Not sure I understood where do you want to move this. In any case this is something about the display side of the DSI video connection, with the bridge as a special case, not about the controller. To my understanding the controller is supposed to support all the modes. Francesco
On Thu, Mar 30, 2023 at 8:32 PM Francesco Dolcini <francesco@dolcini.it> wrote: > > On Thu, Mar 30, 2023 at 07:56:26PM +0530, Jagan Teki wrote: > > On Thu, Mar 30, 2023 at 3:48 PM Francesco Dolcini <francesco@dolcini.it> wrote: > > > > > > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > > > SN65DSI8[34] device supports burst video mode and non-burst video mode > > > with sync events or with sync pulses packet transmission as described in > > > the DSI specification. > > > > > > Add property to select the expected mode, this allows for example to > > > select a mode that is compatible with the DSI host interface. > > > > > > Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> > > > --- > > > .../devicetree/bindings/display/bridge/ti,sn65dsi83.yaml | 8 ++++++++ > > > 1 file changed, 8 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > > > index 48a97bb3e2e0..ebee16726b02 100644 > > > --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > > > +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml > > > @@ -35,6 +35,14 @@ properties: > > > vcc-supply: > > > description: A 1.8V power supply (see regulator/regulator.yaml). > > > > > > + dsi-video-mode: > > > + description: | > > > + 0 - burst-mode > > > + 1 - non-burst with sync event > > > + 2 - non-burst with sync pulse > > > + $ref: /schemas/types.yaml#/definitions/uint32 > > > + enum: [0, 1, 2] > > > > I'm thinking this can go to dsi common code since the video modes are > > common across all controllers and make the core initialize the default > > and update if any sink devices are willing to change the modes. Sound > > like a big move but worth useful. > > Not sure I understood where do you want to move this. Yes, it can be new may be Documentation/devicetree/bindings/display/dsi-device.yaml > > In any case this is something about the display side of the DSI video > connection, with the bridge as a special case, not about the controller. > To my understanding the controller is supposed to support all the modes. Yes, that is what I'm saying. DSI sink will send this mode via mode_flags and the controller act accordingly. The point here is these modes are generic across all DSI sink devices so having common bindings can make it easy for all devices to use. As I said it can be new, but worth trying - anyway let's see how others are commenting on this. Thanks, Jagan.
On Thu, Mar 30, 2023 at 12:17:51PM +0200, Francesco Dolcini wrote: > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > SN65DSI8[34] device supports burst video mode and non-burst video mode > with sync events or with sync pulses packet transmission as described in > the DSI specification. > > Add property to select the expected mode, this allows for example to > select a mode that is compatible with the DSI host interface. Why does this need to be in DT? The source and sink drivers should know what their capabilities are and pick the best common one. Rob
On Mon, Apr 03, 2023 at 04:06:22PM -0500, Rob Herring wrote: > On Thu, Mar 30, 2023 at 12:17:51PM +0200, Francesco Dolcini wrote: > > From: Francesco Dolcini <francesco.dolcini@toradex.com> > > > > SN65DSI8[34] device supports burst video mode and non-burst video mode > > with sync events or with sync pulses packet transmission as described in > > the DSI specification. > > > > Add property to select the expected mode, this allows for example to > > select a mode that is compatible with the DSI host interface. > > Why does this need to be in DT? > The source and sink drivers should know what their capabilities are > and pick the best common one. Is there a best mode? Isn't this a decision how do we want the 2 peers to communicate? For the MIPI-DSI Linux/DRM experts: am I missing something? Is there another way to have a DSI video sink to ask for a specific mode? (I copied this from an existing DSI panel binding). Francesco
On 4/3/23 23:15, Francesco Dolcini wrote: > On Mon, Apr 03, 2023 at 04:06:22PM -0500, Rob Herring wrote: >> On Thu, Mar 30, 2023 at 12:17:51PM +0200, Francesco Dolcini wrote: >>> From: Francesco Dolcini <francesco.dolcini@toradex.com> >>> >>> SN65DSI8[34] device supports burst video mode and non-burst video mode >>> with sync events or with sync pulses packet transmission as described in >>> the DSI specification. >>> >>> Add property to select the expected mode, this allows for example to >>> select a mode that is compatible with the DSI host interface. >> >> Why does this need to be in DT? > >> The source and sink drivers should know what their capabilities are >> and pick the best common one. > > Is there a best mode? I think yes: Burst (is better than) Sync Events (is better than) Sync Pulses Burst is most energy efficient, Sync-Pulses is the simplest and least energy efficient and with most constraints. > Isn't this a decision how do we want the 2 peers > to communicate? I don't think so, I believe the Host and nearest bridge should be able to negotiate their capabilities (mode, link rate, etc.) within the DRM subsystem. > For the MIPI-DSI Linux/DRM experts: am I missing something? Is there > another way to have a DSI video sink to ask for a specific mode? I'm afraid this is not implemented yet, so ... plumbing needed. [...]
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml index 48a97bb3e2e0..ebee16726b02 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -35,6 +35,14 @@ properties: vcc-supply: description: A 1.8V power supply (see regulator/regulator.yaml). + dsi-video-mode: + description: | + 0 - burst-mode + 1 - non-burst with sync event + 2 - non-burst with sync pulse + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + ports: $ref: /schemas/graph.yaml#/properties/ports