From: Francesco Dolcini <[email protected]>
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.
Enable configuration of the DSI video mode instead of hard-coding
MIPI_DSI_MODE_VIDEO_BURST.
Francesco Dolcini (2):
dt-bindings: display: bridge: sn65dsi83: Add DSI video mode
drm/bridge: ti-sn65dsi83: Add DSI video mode configuration
.../bindings/display/bridge/ti,sn65dsi83.yaml | 8 +++++++
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 24 ++++++++++++++++++-
2 files changed, 31 insertions(+), 1 deletion(-)
--
2.25.1
From: Francesco Dolcini <[email protected]>
Enable configuration of the DSI video mode instead of hard-coding
MIPI_DSI_MODE_VIDEO_BURST. The bridge support any of burst-mode,
non-burst with sync event or non-burst with sync pulse
With this change is possible to use the bridge with host DSI
that do not support burst mode.
Signed-off-by: Francesco Dolcini <[email protected]>
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index 91ecfbe45bf9..144d0de0d278 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -145,6 +145,7 @@ struct sn65dsi83 {
struct drm_bridge *panel_bridge;
struct gpio_desc *enable_gpio;
struct regulator *vcc;
+ u32 dsi_video_mode;
bool lvds_dual_link;
bool lvds_dual_link_even_odd_swap;
};
@@ -603,6 +604,9 @@ static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx, enum sn65dsi83_model model)
return dev_err_probe(dev, PTR_ERR(ctx->vcc),
"Failed to get supply 'vcc'\n");
+ ctx->dsi_video_mode = 0;
+ of_property_read_u32(dev->of_node, "dsi-video-mode", &ctx->dsi_video_mode);
+
return 0;
}
@@ -642,7 +646,25 @@ static int sn65dsi83_host_attach(struct sn65dsi83 *ctx)
dsi->lanes = dsi_lanes;
dsi->format = MIPI_DSI_FMT_RGB888;
- dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST;
+ dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
+
+ switch (ctx->dsi_video_mode) {
+ case 0:
+ /* burst mode */
+ dsi->mode_flags |= MIPI_DSI_MODE_VIDEO_BURST;
+ break;
+ case 1:
+ /* non-burst mode with sync event */
+ break;
+ case 2:
+ /* non-burst mode with sync pulse */
+ dsi->mode_flags |= MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
+ break;
+ default:
+ dev_warn(dev, "invalid video mode %d\n", ctx->dsi_video_mode);
+ break;
+ }
+
ret = devm_mipi_dsi_attach(dev, dsi);
if (ret < 0) {
--
2.25.1
From: Francesco Dolcini <[email protected]>
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 <[email protected]>
---
.../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]
+
ports:
$ref: /schemas/graph.yaml#/properties/ports
--
2.25.1
On Thu, Mar 30, 2023 at 3:48 PM Francesco Dolcini <[email protected]> wrote:
>
> From: Francesco Dolcini <[email protected]>
>
> 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 <[email protected]>
> ---
> .../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 <[email protected]> wrote:
> >
> > From: Francesco Dolcini <[email protected]>
> >
> > 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 <[email protected]>
> > ---
> > .../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 <[email protected]> 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 <[email protected]> wrote:
> > >
> > > From: Francesco Dolcini <[email protected]>
> > >
> > > 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 <[email protected]>
> > > ---
> > > .../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.
Hi,
On 30/03/2023 12:17, Francesco Dolcini wrote:
> From: Francesco Dolcini <[email protected]>
>
> Enable configuration of the DSI video mode instead of hard-coding
> MIPI_DSI_MODE_VIDEO_BURST. The bridge support any of burst-mode,
> non-burst with sync event or non-burst with sync pulse
>
> With this change is possible to use the bridge with host DSI
> that do not support burst mode.
>
> Signed-off-by: Francesco Dolcini <[email protected]>
> ---
> drivers/gpu/drm/bridge/ti-sn65dsi83.c | 24 +++++++++++++++++++++++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> index 91ecfbe45bf9..144d0de0d278 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> @@ -145,6 +145,7 @@ struct sn65dsi83 {
> struct drm_bridge *panel_bridge;
> struct gpio_desc *enable_gpio;
> struct regulator *vcc;
> + u32 dsi_video_mode;
> bool lvds_dual_link;
> bool lvds_dual_link_even_odd_swap;
> };
> @@ -603,6 +604,9 @@ static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx, enum sn65dsi83_model model)
> return dev_err_probe(dev, PTR_ERR(ctx->vcc),
> "Failed to get supply 'vcc'\n");
>
> + ctx->dsi_video_mode = 0;
> + of_property_read_u32(dev->of_node, "dsi-video-mode", &ctx->dsi_video_mode);
> +
> return 0;
> }
>
> @@ -642,7 +646,25 @@ static int sn65dsi83_host_attach(struct sn65dsi83 *ctx)
>
> dsi->lanes = dsi_lanes;
> dsi->format = MIPI_DSI_FMT_RGB888;
> - dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST;
> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
> +
> + switch (ctx->dsi_video_mode) {
> + case 0:
> + /* burst mode */
> + dsi->mode_flags |= MIPI_DSI_MODE_VIDEO_BURST;
> + break;
> + case 1:
> + /* non-burst mode with sync event */
> + break;
> + case 2:
> + /* non-burst mode with sync pulse */
> + dsi->mode_flags |= MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
> + break;
> + default:
> + dev_warn(dev, "invalid video mode %d\n", ctx->dsi_video_mode);
> + break;
> + }
> +
>
> ret = devm_mipi_dsi_attach(dev, dsi);
> if (ret < 0) {
As I understand from DSI spec is that those are dynamic, so they are hardcoded in driver now
but they shouldn't be hardcoded in DT.
The problem is larger and we should add some sort of "supported features" we can get
from the DSI controller and set the flags accordingly because the features support accross the
DSI controllers isn't linear.
Neil
On Fri, Mar 31, 2023 at 11:06:44AM +0200, Neil Armstrong wrote:
> Hi,
>
> On 30/03/2023 12:17, Francesco Dolcini wrote:
> > From: Francesco Dolcini <[email protected]>
> >
> > Enable configuration of the DSI video mode instead of hard-coding
> > MIPI_DSI_MODE_VIDEO_BURST. The bridge support any of burst-mode,
> > non-burst with sync event or non-burst with sync pulse
> >
> > With this change is possible to use the bridge with host DSI
> > that do not support burst mode.
> >
> > Signed-off-by: Francesco Dolcini <[email protected]>
> > ---
> > drivers/gpu/drm/bridge/ti-sn65dsi83.c | 24 +++++++++++++++++++++++-
> > 1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > index 91ecfbe45bf9..144d0de0d278 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > @@ -145,6 +145,7 @@ struct sn65dsi83 {
> > struct drm_bridge *panel_bridge;
> > struct gpio_desc *enable_gpio;
> > struct regulator *vcc;
> > + u32 dsi_video_mode;
> > bool lvds_dual_link;
> > bool lvds_dual_link_even_odd_swap;
> > };
> > @@ -603,6 +604,9 @@ static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx, enum sn65dsi83_model model)
> > return dev_err_probe(dev, PTR_ERR(ctx->vcc),
> > "Failed to get supply 'vcc'\n");
> > + ctx->dsi_video_mode = 0;
> > + of_property_read_u32(dev->of_node, "dsi-video-mode", &ctx->dsi_video_mode);
> > +
> > return 0;
> > }
> > @@ -642,7 +646,25 @@ static int sn65dsi83_host_attach(struct sn65dsi83 *ctx)
> > dsi->lanes = dsi_lanes;
> > dsi->format = MIPI_DSI_FMT_RGB888;
> > - dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST;
> > + dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
> > +
> > + switch (ctx->dsi_video_mode) {
> > + case 0:
> > + /* burst mode */
> > + dsi->mode_flags |= MIPI_DSI_MODE_VIDEO_BURST;
> > + break;
> > + case 1:
> > + /* non-burst mode with sync event */
> > + break;
> > + case 2:
> > + /* non-burst mode with sync pulse */
> > + dsi->mode_flags |= MIPI_DSI_MODE_VIDEO_SYNC_PULSE;
> > + break;
> > + default:
> > + dev_warn(dev, "invalid video mode %d\n", ctx->dsi_video_mode);
> > + break;
> > + }
> > +
> > ret = devm_mipi_dsi_attach(dev, dsi);
> > if (ret < 0) {
>
> As I understand from DSI spec is that those are dynamic, so they are hardcoded in driver now
> but they shouldn't be hardcoded in DT.
>
> The problem is larger and we should add some sort of "supported features" we can get
> from the DSI controller and set the flags accordingly because the features support accross the
> DSI controllers isn't linear.
I need to change this since I do have a bridge that does not support
DSI video burst mode, while the ti-sn65 supports really any mode.
The change here is the same as what is done for the raydium,rm67191
panel, see Documentation/devicetree/bindings/display/panel/raydium,rm67191.yaml
and drivers/gpu/drm/panel/panel-raydium-rm67191.c.
What's wrong to have this in the dts so that a panel can explicitly tell
which DSI video mode it expects?
Francesco
On Thu, Mar 30, 2023 at 12:17:51PM +0200, Francesco Dolcini wrote:
> From: Francesco Dolcini <[email protected]>
>
> 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 <[email protected]>
> >
> > 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 <[email protected]>
>>>
>>> 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.
[...]