All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Laurent Pinchart
	<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
Cc: Thierry Reding
	<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Sam Ravnborg <sam-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org>,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
Date: Sat, 18 Apr 2020 17:16:35 +0300	[thread overview]
Message-ID: <7978ed3b-7dcc-2219-c42d-740e3ce64189@gmail.com> (raw)
In-Reply-To: <20200417205828.GM5861-N3hz7ZxfLydczECFQUw77jytWr6r+dGw0E9HWUfgJXw@public.gmane.org>

17.04.2020 23:58, Laurent Pinchart пишет:
> Hi Dmitry,
> 
> On Fri, Apr 17, 2020 at 11:52:11PM +0300, Dmitry Osipenko wrote:
>> 17.04.2020 23:31, Laurent Pinchart пишет:
>>> On Fri, Apr 17, 2020 at 10:41:59PM +0300, Dmitry Osipenko wrote:
>>>> 17.04.2020 22:30, Laurent Pinchart пишет:
>>>> ...
>>>>>>  #include <drm/drm_atomic.h>
>>>>>> +#include <drm/drm_bridge.h>
>>>>>
>>>>> You could add a forward declaration of struct drm_bridge instead, that
>>>>> can lower the compilation time a little bit.
>>>>
>>>> This include is not only for the struct, but also for the
>>>> drm_bridge_attach(). It looks to me that it should be nicer to keep the
>>>> include here.
>>>
>>> drm_bridge_attach() is called from .c files. In the .h file you can use
>>> a forward declaration. It's entirely up to you, but as a general rule, I
>>> personally try to use forward structure declarations in .h files as much
>>> as possible.
>>
>> The current Tegra DRM code is a bit inconsistent in regards to having
>> forward declarations, it doesn't have them more than have.
>>
>> I'll add a forward declaration if there will be need to make a v5, ok?
> 
> It's up to you, you don't have to use a forward declaration if you don't
> want to, I was just pointing out what I think is a best practice rule
> :-)

Alright, then I'll leave the include as-is in this patch since it should
be better to keep the code consistent even if it's a bit less optimal
than it could be, IMO.

We may return to cleaning up of driver includes later on.

>>>> ...
>>>>>> +	port = of_get_child_by_name(output->of_node, "port");
>>>>>
>>>>> Do you need to check for the presence of a port node first ? Can you
>>>>> just check the return value of drm_of_find_panel_or_bridge(), and fall
>>>>> back to "nvidia,panel" if it returns -ENODEV ?
>>>>
>>>> Without the check, the drm_of_find_panel_or_bridge() prints a very noisy
>>>> error message about missing port node for every output that doesn't have
>>>> a graph specified in a device-tree (HDMI, DSI and etc).
>>>>
>>>> https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/of/property.c#L621
>>>
>>> Ah yes indeed. That's not very nice.
>>
>> Please let me know if you'll have a better idea about how this could be
>> handled.
> 
> It should be good enough as-is I think. You may however want to support
> both "port" and "ports", as even when there's a single port node, it
> could be put inside a ports node.
> 

I'll make a v5 that will have additional patches for making
drm_of_find_panel_or_bridge() to better handle that case.

While at it, I'll also add a patch that will wrap RGB panel into bridge.

Thank you very much for the reviews!

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-tegra@vger.kernel.org,
	Thierry Reding <thierry.reding@gmail.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v4 2/3] drm/tegra: output: Support DRM bridges
Date: Sat, 18 Apr 2020 17:16:35 +0300	[thread overview]
Message-ID: <7978ed3b-7dcc-2219-c42d-740e3ce64189@gmail.com> (raw)
In-Reply-To: <20200417205828.GM5861@pendragon.ideasonboard.com>

17.04.2020 23:58, Laurent Pinchart пишет:
> Hi Dmitry,
> 
> On Fri, Apr 17, 2020 at 11:52:11PM +0300, Dmitry Osipenko wrote:
>> 17.04.2020 23:31, Laurent Pinchart пишет:
>>> On Fri, Apr 17, 2020 at 10:41:59PM +0300, Dmitry Osipenko wrote:
>>>> 17.04.2020 22:30, Laurent Pinchart пишет:
>>>> ...
>>>>>>  #include <drm/drm_atomic.h>
>>>>>> +#include <drm/drm_bridge.h>
>>>>>
>>>>> You could add a forward declaration of struct drm_bridge instead, that
>>>>> can lower the compilation time a little bit.
>>>>
>>>> This include is not only for the struct, but also for the
>>>> drm_bridge_attach(). It looks to me that it should be nicer to keep the
>>>> include here.
>>>
>>> drm_bridge_attach() is called from .c files. In the .h file you can use
>>> a forward declaration. It's entirely up to you, but as a general rule, I
>>> personally try to use forward structure declarations in .h files as much
>>> as possible.
>>
>> The current Tegra DRM code is a bit inconsistent in regards to having
>> forward declarations, it doesn't have them more than have.
>>
>> I'll add a forward declaration if there will be need to make a v5, ok?
> 
> It's up to you, you don't have to use a forward declaration if you don't
> want to, I was just pointing out what I think is a best practice rule
> :-)

Alright, then I'll leave the include as-is in this patch since it should
be better to keep the code consistent even if it's a bit less optimal
than it could be, IMO.

We may return to cleaning up of driver includes later on.

>>>> ...
>>>>>> +	port = of_get_child_by_name(output->of_node, "port");
>>>>>
>>>>> Do you need to check for the presence of a port node first ? Can you
>>>>> just check the return value of drm_of_find_panel_or_bridge(), and fall
>>>>> back to "nvidia,panel" if it returns -ENODEV ?
>>>>
>>>> Without the check, the drm_of_find_panel_or_bridge() prints a very noisy
>>>> error message about missing port node for every output that doesn't have
>>>> a graph specified in a device-tree (HDMI, DSI and etc).
>>>>
>>>> https://elixir.bootlin.com/linux/v5.7-rc1/source/drivers/of/property.c#L621
>>>
>>> Ah yes indeed. That's not very nice.
>>
>> Please let me know if you'll have a better idea about how this could be
>> handled.
> 
> It should be good enough as-is I think. You may however want to support
> both "port" and "ports", as even when there's a single port node, it
> could be put inside a ports node.
> 

I'll make a v5 that will have additional patches for making
drm_of_find_panel_or_bridge() to better handle that case.

While at it, I'll also add a patch that will wrap RGB panel into bridge.

Thank you very much for the reviews!
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2020-04-18 14:16 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-17 17:52 [PATCH v4 0/3] Support DRM bridges on NVIDIA Tegra Dmitry Osipenko
2020-04-17 17:52 ` Dmitry Osipenko
     [not found] ` <20200417175238.27154-1-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-04-17 17:52   ` [PATCH v4 1/3] drm/tegra: output: Don't leak OF node on error Dmitry Osipenko
2020-04-17 17:52     ` Dmitry Osipenko
2020-04-17 17:52   ` [PATCH v4 2/3] drm/tegra: output: Support DRM bridges Dmitry Osipenko
2020-04-17 17:52     ` Dmitry Osipenko
     [not found]     ` <20200417175238.27154-3-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-04-17 19:30       ` Laurent Pinchart
2020-04-17 19:30         ` Laurent Pinchart
     [not found]         ` <20200417193018.GI5861-N3hz7ZxfLydczECFQUw77jytWr6r+dGw0E9HWUfgJXw@public.gmane.org>
2020-04-17 19:41           ` Dmitry Osipenko
2020-04-17 19:41             ` Dmitry Osipenko
     [not found]             ` <0acc35fd-a74b-e726-7a16-55db13265c39-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-04-17 20:31               ` Laurent Pinchart
2020-04-17 20:31                 ` Laurent Pinchart
     [not found]                 ` <20200417203154.GK5861-N3hz7ZxfLydczECFQUw77jytWr6r+dGw0E9HWUfgJXw@public.gmane.org>
2020-04-17 20:52                   ` Dmitry Osipenko
2020-04-17 20:52                     ` Dmitry Osipenko
     [not found]                     ` <15002e6e-de36-899f-0d28-896c67a29a49-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-04-17 20:58                       ` Laurent Pinchart
2020-04-17 20:58                         ` Laurent Pinchart
     [not found]                         ` <20200417205828.GM5861-N3hz7ZxfLydczECFQUw77jytWr6r+dGw0E9HWUfgJXw@public.gmane.org>
2020-04-18 14:16                           ` Dmitry Osipenko [this message]
2020-04-18 14:16                             ` Dmitry Osipenko
2020-04-17 17:52   ` [PATCH v4 3/3] drm/tegra: output: rgb: Support LVDS encoder bridge Dmitry Osipenko
2020-04-17 17:52     ` Dmitry Osipenko
     [not found]     ` <20200417175238.27154-4-digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-04-17 19:24       ` Laurent Pinchart
2020-04-17 19:24         ` Laurent Pinchart
     [not found]         ` <20200417192453.GH5861-N3hz7ZxfLydczECFQUw77jytWr6r+dGw0E9HWUfgJXw@public.gmane.org>
2020-04-17 20:11           ` Dmitry Osipenko
2020-04-17 20:11             ` Dmitry Osipenko
     [not found]             ` <598c81ef-ba22-a832-0822-e08023f3dff6-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2020-04-17 20:34               ` Laurent Pinchart
2020-04-17 20:34                 ` Laurent Pinchart
     [not found]                 ` <20200417203435.GL5861-N3hz7ZxfLydczECFQUw77jytWr6r+dGw0E9HWUfgJXw@public.gmane.org>
2020-04-17 20:51                   ` Dmitry Osipenko
2020-04-17 20:51                     ` Dmitry Osipenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7978ed3b-7dcc-2219-c42d-740e3ce64189@gmail.com \
    --to=digetx-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=sam-uyr5N9Q2VtJg9hUCZPvPmw@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.