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.
