[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bb328e16-7815-4518-832f-456cf1b7e704@linux.dev>
Date: Fri, 24 Nov 2023 15:51:00 +0800
From: Sui Jingfeng <sui.jingfeng@...ux.dev>
To: Maxime Ripard <mripard@...nel.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Phong LE <ple@...libre.com>,
Neil Armstrong <neil.armstrong@...aro.org>,
Sui Jingfeng <suijingfeng@...ngson.cn>,
linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
Thomas Zimmermann <tzimmermann@...e.de>
Subject: Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
Hi,
On 2023/11/24 15:38, Maxime Ripard wrote:
> On Fri, Nov 24, 2023 at 01:52:26AM +0800, Sui Jingfeng wrote:
>> On 2023/11/23 16:08, Dmitry Baryshkov wrote:
>>>> I'm agree with the idea that drm bridges drivers involved toward to a direction
>>>> that support more complex design, but I think we should also leave a way for the
>>>> most frequent use case. Make it straight-forward as a canonical design.
>>> Not having anything connector-related in the drm_bridge driver is a
>>> canonical design.
>> What you said is just for the more complex uses case. I can't agree, sorry.
>>
>> By choosing the word "canonical design", I means that the most frequently used
>> cases in practice are the canonical design, 95+% motherboards I have seen has
>> only one *onboard* display bridges chip. For my driver, I abstract the internal
>> (inside of the chip) encoder as drm_encoder and abstract the external TX chip as
>> drm_bridge, this design still works very well.
>>
>>
>> Originally, I means that this is a concept of the hardware design.
>> You are wrong even through in the software design context, the
>> transparent simple drm bridge drivers(simple-bridge.c) also *allow*
>> to create drm connector manually. I don't think I need to emulate
>> more example, please read the code by youself.
'emulate' -> 'enumerate'
> Ok. That's it. We've been patient long enough. You have been given a
> review and a list of things to fix for your driver to be merged.
This series is not relevant to my driver, can we please *limit*
the discussion to this series?
> Whether
> you follow them or not is your decision.
I'm not saying that I will not follow, just to make sure what's solution is you want.
I need discussion to figure out.
> We won't tolerate insulting comments though.
There is *no* insulting, please don't misunderstanding before *sufficient* communication, OK?
Originally, I thought Dmitry may ignore(or overlook) what is the current status.
> Maxime
Powered by blists - more mailing lists