From: Sui Jingfeng <sui.jingfeng@linux.dev>
To: Maxime Ripard <mripard@kernel.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Phong LE <ple@baylibre.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Sui Jingfeng <suijingfeng@loongson.cn>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib
Date: Sat, 25 Nov 2023 10:30:09 +0800 [thread overview]
Message-ID: <95052fad-b3ef-4d18-8488-74cf84c50d08@linux.dev> (raw)
In-Reply-To: <tkaucp235w3nlydj7ae66g5r75w2rtjhum65cjrahmgeae7zgz@zb77pw2ih6vs>
On 2023/11/24 16:13, Maxime Ripard wrote:
> On Fri, Nov 24, 2023 at 03:51:00PM +0800, Sui Jingfeng wrote:
>> 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?
> Right, I conflated the two, I meant this series, or the general goal to
> enable that bridge with your driver. The rest of the driver is of course
> unaffected.
>
>>> 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.
> You had direct, repeated, feedback on that already by a maintainer and
> one of the most experienced dev and reviewer on bridges. If you need
> more guidance, you can definitely ask questions, but asking questions
> and telling them they are wrong is very different.
>
>>> 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.
> Saying to someone maintaining and/or reviewing that code for years now
> that they are wrong and should go read the code is insulting.
Back to that time, I'm focus on kindly technique debating, this is a kind
of defensive reply for the patch. This is a kind of remind in case of ignores.
Probably a bit of negative, but please don't misunderstanding as insult anyway.
Dmitry, really thanks a lot for the instructs, I have learned a lot while
talking with you. I will back to try mentioned method.
next prev parent reply other threads:[~2023-11-25 2:30 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-14 15:01 [PATCH 0/8] Allow link the it66121 display bridge driver as a lib Sui Jingfeng
2023-11-14 15:01 ` [PATCH 1/8] drm/bridge: it66121: Use dev replace ctx->dev in the it66121_probe() Sui Jingfeng
2023-11-14 16:01 ` Dmitry Baryshkov
2023-11-14 15:01 ` [PATCH 2/8] drm/bridge: it66121: Add bridge_to_it66121() helper and use it Sui Jingfeng
2023-11-14 16:01 ` Dmitry Baryshkov
2023-11-14 15:01 ` [PATCH 3/8] drm/bridge: it66121: Add a helper function to read bus width Sui Jingfeng
2023-11-14 16:03 ` Dmitry Baryshkov
2023-11-14 15:01 ` [PATCH 4/8] drm/bridge: it66121: Add a helper function to get the next bridge Sui Jingfeng
2023-11-14 16:05 ` Dmitry Baryshkov
2023-11-23 5:25 ` Sui Jingfeng
2023-11-23 7:54 ` Dmitry Baryshkov
2023-11-14 15:01 ` [PATCH 5/8] drm/bridge: it66121: Add a helper function to read chip id Sui Jingfeng
2023-11-14 16:06 ` Dmitry Baryshkov
2023-11-16 12:18 ` Sui Jingfeng
2023-11-16 13:00 ` Dmitry Baryshkov
2023-11-16 18:29 ` Sui Jingfeng
2023-11-16 22:00 ` Dmitry Baryshkov
2023-11-23 5:37 ` Sui Jingfeng
2023-11-23 7:48 ` Dmitry Baryshkov
2023-11-23 13:03 ` Sui Jingfeng
2023-11-14 15:01 ` [PATCH 6/8] drm/bridge: it66121: Add a helper to initialize the DRM bridge structure Sui Jingfeng
2023-11-14 16:10 ` Dmitry Baryshkov
2023-11-14 15:01 ` [PATCH 7/8] drm/bridge: it66121: Add another implementation for getting match data Sui Jingfeng
2023-11-14 16:00 ` Dmitry Baryshkov
2023-11-14 15:01 ` [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib Sui Jingfeng
2023-11-14 16:30 ` Dmitry Baryshkov
2023-11-16 9:14 ` Sui Jingfeng
2023-11-16 9:30 ` Dmitry Baryshkov
2023-11-16 10:12 ` Sui Jingfeng
2023-11-16 11:19 ` Dmitry Baryshkov
2023-11-23 5:05 ` Sui Jingfeng
2023-11-23 8:08 ` Dmitry Baryshkov
2023-11-23 13:39 ` Neil Armstrong
2023-11-23 16:20 ` Sui Jingfeng
2023-11-23 15:41 ` Sui Jingfeng
2023-11-23 16:06 ` Dmitry Baryshkov
2023-11-23 16:29 ` Sui Jingfeng
2023-11-23 17:04 ` Sui Jingfeng
2023-11-23 17:39 ` Dmitry Baryshkov
2023-11-23 17:52 ` Sui Jingfeng
2023-11-24 7:38 ` Maxime Ripard
2023-11-24 7:51 ` Sui Jingfeng
2023-11-24 8:13 ` Maxime Ripard
2023-11-24 8:48 ` Sui Jingfeng
2023-11-25 2:30 ` Sui Jingfeng [this message]
2023-11-16 10:29 ` Sui Jingfeng
2023-11-16 11:11 ` Dmitry Baryshkov
2023-11-16 11:15 ` Jani Nikula
2023-11-16 11:18 ` Sui Jingfeng
2023-11-16 11:29 ` Dmitry Baryshkov
2023-11-16 11:53 ` Sui Jingfeng
2023-11-16 12:07 ` Sui Jingfeng
2023-11-16 15:23 ` Dmitry Baryshkov
2023-11-16 17:18 ` Sui Jingfeng
2023-11-17 9:52 ` Maxime Ripard
2023-11-17 4:24 ` Sui Jingfeng
2023-11-17 9:03 ` Dmitry Baryshkov
2023-11-17 17:14 ` Sui Jingfeng
2023-11-20 8:23 ` Neil Armstrong
2023-11-17 17:35 ` Sui Jingfeng
2023-11-20 10:06 ` Dmitry Baryshkov
2023-11-17 12:13 ` Maxime Ripard
2023-11-15 13:02 ` kernel test robot
2023-11-20 9:08 ` kernel test robot
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=95052fad-b3ef-4d18-8488-74cf84c50d08@linux.dev \
--to=sui.jingfeng@linux.dev \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mripard@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=ple@baylibre.com \
--cc=suijingfeng@loongson.cn \
--cc=tzimmermann@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox