diff mbox series

[RFC,2/3] drm/modes: Make width-mm/height-mm mandatory in of_get_drm_panel_display_mode()

Message ID 20220401163755.302548-2-marex@denx.de (mailing list archive)
State New, archived
Headers show
Series [RFC,1/3] dt-bindings: display: panel: mipi-dbi-spi: Make width-mm/height-mm mandatory | expand

Commit Message

Marek Vasut April 1, 2022, 4:37 p.m. UTC
Make the width-mm/height-mm panel properties mandatory in
of_get_drm_panel_display_mode(), print error message and
return -ve in case these DT properties are not present.
This is needed to correctly report panel dimensions.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dmitry Osipenko <digetx@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Robert Foss <robert.foss@linaro.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
To: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/drm_modes.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

Comments

Laurent Pinchart April 1, 2022, 6:46 p.m. UTC | #1
Hi Marek,

Thank you for the patch.

On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote:
> Make the width-mm/height-mm panel properties mandatory in
> of_get_drm_panel_display_mode(), print error message and
> return -ve in case these DT properties are not present.
> This is needed to correctly report panel dimensions.

Can we guarantee this won't cause a regression ?

> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Christoph Niedermaier <cniedermaier@dh-electronics.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Dmitry Osipenko <digetx@gmail.com>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Noralf Trønnes <noralf@tronnes.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Robert Foss <robert.foss@linaro.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: devicetree@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
> ---
>  drivers/gpu/drm/drm_modes.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 3f819c7a021b..45dc2d5c3ea6 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -761,12 +761,16 @@ int of_get_drm_panel_display_mode(struct device_node *np,
>  		drm_bus_flags_from_videomode(&vm, bus_flags);
>  
>  	ret = of_property_read_u32(np, "width-mm", &width_mm);
> -	if (ret && ret != -EINVAL)
> +	if (ret < 0) {
> +		pr_err("%pOF: invalid or missing width-mm DT property\n", np);
>  		return ret;
> +	}
>  
>  	ret = of_property_read_u32(np, "height-mm", &height_mm);
> -	if (ret && ret != -EINVAL)
> +	if (ret < 0) {
> +		pr_err("%pOF: invalid or missing height-mm DT property\n", np);
>  		return ret;
> +	}
>  
>  	dmode->width_mm = width_mm;
>  	dmode->height_mm = height_mm;
Marek Vasut April 1, 2022, 8:36 p.m. UTC | #2
On 4/1/22 20:46, Laurent Pinchart wrote:

Hi,

> On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote:
>> Make the width-mm/height-mm panel properties mandatory in
>> of_get_drm_panel_display_mode(), print error message and
>> return -ve in case these DT properties are not present.
>> This is needed to correctly report panel dimensions.
> 
> Can we guarantee this won't cause a regression ?

For the upstream DTs, I think we can.
For downstream DTs, we cannot know.
Laurent Pinchart April 2, 2022, 3:19 a.m. UTC | #3
On Fri, Apr 01, 2022 at 10:36:24PM +0200, Marek Vasut wrote:
> On 4/1/22 20:46, Laurent Pinchart wrote:
> > On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote:
> >> Make the width-mm/height-mm panel properties mandatory in
> >> of_get_drm_panel_display_mode(), print error message and
> >> return -ve in case these DT properties are not present.
> >> This is needed to correctly report panel dimensions.
> > 
> > Can we guarantee this won't cause a regression ?
> 
> For the upstream DTs, I think we can.
> For downstream DTs, we cannot know.

Are there users of this function whose DT bindings don't require the
width-mm and height-mm properties ?
Marek Vasut April 2, 2022, 4:28 a.m. UTC | #4
On 4/2/22 05:19, Laurent Pinchart wrote:
> On Fri, Apr 01, 2022 at 10:36:24PM +0200, Marek Vasut wrote:
>> On 4/1/22 20:46, Laurent Pinchart wrote:
>>> On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote:
>>>> Make the width-mm/height-mm panel properties mandatory in
>>>> of_get_drm_panel_display_mode(), print error message and
>>>> return -ve in case these DT properties are not present.
>>>> This is needed to correctly report panel dimensions.
>>>
>>> Can we guarantee this won't cause a regression ?
>>
>> For the upstream DTs, I think we can.
>> For downstream DTs, we cannot know.
> 
> Are there users of this function whose DT bindings don't require the
> width-mm and height-mm properties ?

There is literally one user of this function upstream:
drivers/gpu/drm/tiny/panel-mipi-dbi.c
Noralf Trønnes April 2, 2022, 7:45 a.m. UTC | #5
Den 02.04.2022 06.28, skrev Marek Vasut:
> On 4/2/22 05:19, Laurent Pinchart wrote:
>> On Fri, Apr 01, 2022 at 10:36:24PM +0200, Marek Vasut wrote:
>>> On 4/1/22 20:46, Laurent Pinchart wrote:
>>>> On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote:
>>>>> Make the width-mm/height-mm panel properties mandatory in
>>>>> of_get_drm_panel_display_mode(), print error message and
>>>>> return -ve in case these DT properties are not present.
>>>>> This is needed to correctly report panel dimensions.
>>>>
>>>> Can we guarantee this won't cause a regression ?
>>>
>>> For the upstream DTs, I think we can.
>>> For downstream DTs, we cannot know.
>>
>> Are there users of this function whose DT bindings don't require the
>> width-mm and height-mm properties ?
> 
> There is literally one user of this function upstream:
> drivers/gpu/drm/tiny/panel-mipi-dbi.c

Yes, the function was added for that driver since it was so generic in
nature. What about adding an argument to of_get_drm_panel_display_mode()
that tells if the properties are mandatory or not?

Noralf.
Marek Vasut April 2, 2022, 4:39 p.m. UTC | #6
On 4/2/22 09:45, Noralf Trønnes wrote:
> 
> 
> Den 02.04.2022 06.28, skrev Marek Vasut:
>> On 4/2/22 05:19, Laurent Pinchart wrote:
>>> On Fri, Apr 01, 2022 at 10:36:24PM +0200, Marek Vasut wrote:
>>>> On 4/1/22 20:46, Laurent Pinchart wrote:
>>>>> On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote:
>>>>>> Make the width-mm/height-mm panel properties mandatory in
>>>>>> of_get_drm_panel_display_mode(), print error message and
>>>>>> return -ve in case these DT properties are not present.
>>>>>> This is needed to correctly report panel dimensions.
>>>>>
>>>>> Can we guarantee this won't cause a regression ?
>>>>
>>>> For the upstream DTs, I think we can.
>>>> For downstream DTs, we cannot know.
>>>
>>> Are there users of this function whose DT bindings don't require the
>>> width-mm and height-mm properties ?
>>
>> There is literally one user of this function upstream:
>> drivers/gpu/drm/tiny/panel-mipi-dbi.c
> 
> Yes, the function was added for that driver since it was so generic in
> nature. What about adding an argument to of_get_drm_panel_display_mode()
> that tells if the properties are mandatory or not?

Sure, we can do that, but maybe the question here is even bigger than 
this series.

Should every panel set mandatory width_mm/height_mm so e.g. the user 
space can infer DPI from it and set up scaling accordingly, or should 
width_mm/height_mm be optional ?

I think width_mm/height_mm should be mandatory for all panels.

Thoughts ?
Noralf Trønnes April 2, 2022, 5:08 p.m. UTC | #7
Den 02.04.2022 18.39, skrev Marek Vasut:
> On 4/2/22 09:45, Noralf Trønnes wrote:
>>
>>
>> Den 02.04.2022 06.28, skrev Marek Vasut:
>>> On 4/2/22 05:19, Laurent Pinchart wrote:
>>>> On Fri, Apr 01, 2022 at 10:36:24PM +0200, Marek Vasut wrote:
>>>>> On 4/1/22 20:46, Laurent Pinchart wrote:
>>>>>> On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote:
>>>>>>> Make the width-mm/height-mm panel properties mandatory in
>>>>>>> of_get_drm_panel_display_mode(), print error message and
>>>>>>> return -ve in case these DT properties are not present.
>>>>>>> This is needed to correctly report panel dimensions.
>>>>>>
>>>>>> Can we guarantee this won't cause a regression ?
>>>>>
>>>>> For the upstream DTs, I think we can.
>>>>> For downstream DTs, we cannot know.
>>>>
>>>> Are there users of this function whose DT bindings don't require the
>>>> width-mm and height-mm properties ?
>>>
>>> There is literally one user of this function upstream:
>>> drivers/gpu/drm/tiny/panel-mipi-dbi.c
>>
>> Yes, the function was added for that driver since it was so generic in
>> nature. What about adding an argument to of_get_drm_panel_display_mode()
>> that tells if the properties are mandatory or not?
> 
> Sure, we can do that, but maybe the question here is even bigger than
> this series.
> 
> Should every panel set mandatory width_mm/height_mm so e.g. the user
> space can infer DPI from it and set up scaling accordingly, or should
> width_mm/height_mm be optional ?
> 
> I think width_mm/height_mm should be mandatory for all panels.
> 
> Thoughts ?

If this had come up during the review of the driver I would have no
problem making it mandatory. It makes sense for DPI. Maybe it's possible
to get around the ABI break by getting in a change through -fixes before
5.18 is released? I'm fine with that.

Noralf.
Marek Vasut April 2, 2022, 5:55 p.m. UTC | #8
On 4/2/22 19:08, Noralf Trønnes wrote:
> 
> 
> Den 02.04.2022 18.39, skrev Marek Vasut:
>> On 4/2/22 09:45, Noralf Trønnes wrote:
>>>
>>>
>>> Den 02.04.2022 06.28, skrev Marek Vasut:
>>>> On 4/2/22 05:19, Laurent Pinchart wrote:
>>>>> On Fri, Apr 01, 2022 at 10:36:24PM +0200, Marek Vasut wrote:
>>>>>> On 4/1/22 20:46, Laurent Pinchart wrote:
>>>>>>> On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote:
>>>>>>>> Make the width-mm/height-mm panel properties mandatory in
>>>>>>>> of_get_drm_panel_display_mode(), print error message and
>>>>>>>> return -ve in case these DT properties are not present.
>>>>>>>> This is needed to correctly report panel dimensions.
>>>>>>>
>>>>>>> Can we guarantee this won't cause a regression ?
>>>>>>
>>>>>> For the upstream DTs, I think we can.
>>>>>> For downstream DTs, we cannot know.
>>>>>
>>>>> Are there users of this function whose DT bindings don't require the
>>>>> width-mm and height-mm properties ?
>>>>
>>>> There is literally one user of this function upstream:
>>>> drivers/gpu/drm/tiny/panel-mipi-dbi.c
>>>
>>> Yes, the function was added for that driver since it was so generic in
>>> nature. What about adding an argument to of_get_drm_panel_display_mode()
>>> that tells if the properties are mandatory or not?
>>
>> Sure, we can do that, but maybe the question here is even bigger than
>> this series.
>>
>> Should every panel set mandatory width_mm/height_mm so e.g. the user
>> space can infer DPI from it and set up scaling accordingly, or should
>> width_mm/height_mm be optional ?
>>
>> I think width_mm/height_mm should be mandatory for all panels.
>>
>> Thoughts ?
> 
> If this had come up during the review of the driver I would have no
> problem making it mandatory. It makes sense for DPI. Maybe it's possible
> to get around the ABI break by getting in a change through -fixes before
> 5.18 is released? I'm fine with that.

Well that's awesome, the dbi-spi.yaml didn't land in any kernel release 
yet, so we still have a chance to fix it ? Rob ?
Noralf Trønnes April 2, 2022, 8:08 p.m. UTC | #9
Den 02.04.2022 19.55, skrev Marek Vasut:
> On 4/2/22 19:08, Noralf Trønnes wrote:
>>
>>
>> Den 02.04.2022 18.39, skrev Marek Vasut:
>>> On 4/2/22 09:45, Noralf Trønnes wrote:
>>>>
>>>>
>>>> Den 02.04.2022 06.28, skrev Marek Vasut:
>>>>> On 4/2/22 05:19, Laurent Pinchart wrote:
>>>>>> On Fri, Apr 01, 2022 at 10:36:24PM +0200, Marek Vasut wrote:
>>>>>>> On 4/1/22 20:46, Laurent Pinchart wrote:
>>>>>>>> On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote:
>>>>>>>>> Make the width-mm/height-mm panel properties mandatory in
>>>>>>>>> of_get_drm_panel_display_mode(), print error message and
>>>>>>>>> return -ve in case these DT properties are not present.
>>>>>>>>> This is needed to correctly report panel dimensions.
>>>>>>>>
>>>>>>>> Can we guarantee this won't cause a regression ?
>>>>>>>
>>>>>>> For the upstream DTs, I think we can.
>>>>>>> For downstream DTs, we cannot know.
>>>>>>
>>>>>> Are there users of this function whose DT bindings don't require the
>>>>>> width-mm and height-mm properties ?
>>>>>
>>>>> There is literally one user of this function upstream:
>>>>> drivers/gpu/drm/tiny/panel-mipi-dbi.c
>>>>
>>>> Yes, the function was added for that driver since it was so generic in
>>>> nature. What about adding an argument to
>>>> of_get_drm_panel_display_mode()
>>>> that tells if the properties are mandatory or not?
>>>
>>> Sure, we can do that, but maybe the question here is even bigger than
>>> this series.
>>>
>>> Should every panel set mandatory width_mm/height_mm so e.g. the user
>>> space can infer DPI from it and set up scaling accordingly, or should
>>> width_mm/height_mm be optional ?
>>>
>>> I think width_mm/height_mm should be mandatory for all panels.
>>>
>>> Thoughts ?
>>
>> If this had come up during the review of the driver I would have no
>> problem making it mandatory. It makes sense for DPI. Maybe it's possible
>> to get around the ABI break by getting in a change through -fixes before
>> 5.18 is released? I'm fine with that.
> 
> Well that's awesome, the dbi-spi.yaml didn't land in any kernel release
> yet, so we still have a chance to fix it ?

It entered this merge window.
Rob Herring (Arm) April 4, 2022, 4:01 p.m. UTC | #10
On Sat, Apr 02, 2022 at 07:55:59PM +0200, Marek Vasut wrote:
> On 4/2/22 19:08, Noralf Trønnes wrote:
> > 
> > 
> > Den 02.04.2022 18.39, skrev Marek Vasut:
> > > On 4/2/22 09:45, Noralf Trønnes wrote:
> > > > 
> > > > 
> > > > Den 02.04.2022 06.28, skrev Marek Vasut:
> > > > > On 4/2/22 05:19, Laurent Pinchart wrote:
> > > > > > On Fri, Apr 01, 2022 at 10:36:24PM +0200, Marek Vasut wrote:
> > > > > > > On 4/1/22 20:46, Laurent Pinchart wrote:
> > > > > > > > On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote:
> > > > > > > > > Make the width-mm/height-mm panel properties mandatory in
> > > > > > > > > of_get_drm_panel_display_mode(), print error message and
> > > > > > > > > return -ve in case these DT properties are not present.
> > > > > > > > > This is needed to correctly report panel dimensions.
> > > > > > > > 
> > > > > > > > Can we guarantee this won't cause a regression ?
> > > > > > > 
> > > > > > > For the upstream DTs, I think we can.
> > > > > > > For downstream DTs, we cannot know.
> > > > > > 
> > > > > > Are there users of this function whose DT bindings don't require the
> > > > > > width-mm and height-mm properties ?
> > > > > 
> > > > > There is literally one user of this function upstream:
> > > > > drivers/gpu/drm/tiny/panel-mipi-dbi.c
> > > > 
> > > > Yes, the function was added for that driver since it was so generic in
> > > > nature. What about adding an argument to of_get_drm_panel_display_mode()
> > > > that tells if the properties are mandatory or not?
> > > 
> > > Sure, we can do that, but maybe the question here is even bigger than
> > > this series.
> > > 
> > > Should every panel set mandatory width_mm/height_mm so e.g. the user
> > > space can infer DPI from it and set up scaling accordingly, or should
> > > width_mm/height_mm be optional ?
> > > 
> > > I think width_mm/height_mm should be mandatory for all panels.
> > > 
> > > Thoughts ?
> > 
> > If this had come up during the review of the driver I would have no
> > problem making it mandatory. It makes sense for DPI. Maybe it's possible
> > to get around the ABI break by getting in a change through -fixes before
> > 5.18 is released? I'm fine with that.
> 
> Well that's awesome, the dbi-spi.yaml didn't land in any kernel release yet,
> so we still have a chance to fix it ? Rob ?

Yes, it can be fixed. And the binding, not the kernel, is the place to 
enforce it being mandatory IMO.

Rob
Marek Vasut April 4, 2022, 7:23 p.m. UTC | #11
On 4/4/22 18:01, Rob Herring wrote:
> On Sat, Apr 02, 2022 at 07:55:59PM +0200, Marek Vasut wrote:
>> On 4/2/22 19:08, Noralf Trønnes wrote:
>>>
>>>
>>> Den 02.04.2022 18.39, skrev Marek Vasut:
>>>> On 4/2/22 09:45, Noralf Trønnes wrote:
>>>>>
>>>>>
>>>>> Den 02.04.2022 06.28, skrev Marek Vasut:
>>>>>> On 4/2/22 05:19, Laurent Pinchart wrote:
>>>>>>> On Fri, Apr 01, 2022 at 10:36:24PM +0200, Marek Vasut wrote:
>>>>>>>> On 4/1/22 20:46, Laurent Pinchart wrote:
>>>>>>>>> On Fri, Apr 01, 2022 at 06:37:54PM +0200, Marek Vasut wrote:
>>>>>>>>>> Make the width-mm/height-mm panel properties mandatory in
>>>>>>>>>> of_get_drm_panel_display_mode(), print error message and
>>>>>>>>>> return -ve in case these DT properties are not present.
>>>>>>>>>> This is needed to correctly report panel dimensions.
>>>>>>>>>
>>>>>>>>> Can we guarantee this won't cause a regression ?
>>>>>>>>
>>>>>>>> For the upstream DTs, I think we can.
>>>>>>>> For downstream DTs, we cannot know.
>>>>>>>
>>>>>>> Are there users of this function whose DT bindings don't require the
>>>>>>> width-mm and height-mm properties ?
>>>>>>
>>>>>> There is literally one user of this function upstream:
>>>>>> drivers/gpu/drm/tiny/panel-mipi-dbi.c
>>>>>
>>>>> Yes, the function was added for that driver since it was so generic in
>>>>> nature. What about adding an argument to of_get_drm_panel_display_mode()
>>>>> that tells if the properties are mandatory or not?
>>>>
>>>> Sure, we can do that, but maybe the question here is even bigger than
>>>> this series.
>>>>
>>>> Should every panel set mandatory width_mm/height_mm so e.g. the user
>>>> space can infer DPI from it and set up scaling accordingly, or should
>>>> width_mm/height_mm be optional ?
>>>>
>>>> I think width_mm/height_mm should be mandatory for all panels.
>>>>
>>>> Thoughts ?
>>>
>>> If this had come up during the review of the driver I would have no
>>> problem making it mandatory. It makes sense for DPI. Maybe it's possible
>>> to get around the ABI break by getting in a change through -fixes before
>>> 5.18 is released? I'm fine with that.
>>
>> Well that's awesome, the dbi-spi.yaml didn't land in any kernel release yet,
>> so we still have a chance to fix it ? Rob ?
> 
> Yes, it can be fixed. And the binding, not the kernel, is the place to
> enforce it being mandatory IMO.

All right, I sent 1/3 separately with Fixes: tag, so it can be applied .
diff mbox series

Patch

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 3f819c7a021b..45dc2d5c3ea6 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -761,12 +761,16 @@  int of_get_drm_panel_display_mode(struct device_node *np,
 		drm_bus_flags_from_videomode(&vm, bus_flags);
 
 	ret = of_property_read_u32(np, "width-mm", &width_mm);
-	if (ret && ret != -EINVAL)
+	if (ret < 0) {
+		pr_err("%pOF: invalid or missing width-mm DT property\n", np);
 		return ret;
+	}
 
 	ret = of_property_read_u32(np, "height-mm", &height_mm);
-	if (ret && ret != -EINVAL)
+	if (ret < 0) {
+		pr_err("%pOF: invalid or missing height-mm DT property\n", np);
 		return ret;
+	}
 
 	dmode->width_mm = width_mm;
 	dmode->height_mm = height_mm;