Message-ID: <CAFQXuNa7z=RHtbx6zrtGGDK4dpa++m_BPxTNj8iemLkxYPP_zA@mail.gmail.com>
Date: Mon, 8 Sep 2025 09:14:51 +0800
From: 杨孙运 <yangsunyun1993@...il.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Neil Armstrong <neil.armstrong@...aro.org>, syyang <syyang@...tium.com>, robh@...nel.org, 
	krzk+dt@...nel.org, conor+dt@...nel.org, andrzej.hajda@...el.com, 
	rfoss@...nel.org, Laurent.pinchart@...asonboard.com, jonas@...boo.se, 
	jernej.skrabec@...il.com, devicetree@...r.kernel.org, 
	dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, 
	xmzhu@...tium.com, llzhang@...tium.com, rlyu@...tium.com, xbpeng@...tium.com
Subject: Re: [PATCH v1 2/2] This patch adds a new DRM bridge driver for the
 Lontium LT9611C chip.

Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com> 于2025年9月5日周五 22:24写道：
>
> On Fri, Sep 05, 2025 at 04:58:59PM +0800, 杨孙运 wrote:
> > HI，
> >
> > As a vendors , we have begun to attempt to contribute to the Linux,
> > and we are very willing to do so.
> > there are still many rules that we don't understand and need to learn.
>
> Not top-posting and trimming your emails would be nice things to learn
> too.
>
> > <neil.armstrong@...aro.org> 于2025年9月5日周五 16:10写道：
> > > On 05/09/2025 04:55, 杨孙运 wrote:
> > > > Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com> 于2025年9月4日周四 22:39写道：
> > > >> On Thu, Sep 04, 2025 at 06:48:13PM +0800, 杨孙运 wrote:
> > > >>> Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com> 于2025年9月4日周四 10:52写道：
> > > >>>> On Wed, Sep 03, 2025 at 05:38:25AM -0700, syyang wrote:
>
> > > >>>>> +     }
> > > >>>>> +
> > > >>>>> +     if (lt9611c->bridge_added) {
> > > >>>>> +             drm_bridge_remove(&lt9611c->bridge);
> > > >>>>> +             lt9611c->bridge_added = false;
> > > >>>>> +             dev_err(dev, "DRM bridge removed\n");
> > > >>>>> +     }
> > > >>>>> +
> > > >>>>> +     if (lt9611c->regulators_enabled) {
> > > >>>>> +             regulator_bulk_disable(ARRAY_SIZE(lt9611c->supplies), lt9611c->supplies);
> > > >>>>> +             lt9611c->regulators_enabled = false;
> > > >>>>> +             dev_err(dev, "regulators disabled\n");
> > > >>>>> +     }
> > > >>>>> +
> > > >>>>> +     if (lt9611c->audio_pdev)
> > > >>>>> +             lt9611c_audio_exit(lt9611c);
> > > >>>>> +
> > > >>>>> +     if (lt9611c->fw) {
> > > >>>>
> > > >>>> You definitely don't need firmware when the bridge is up and running.
> > > >>>>
> > > >>> The previous text has already described the working logic of the firmware.
> > > >>
> > > >> It's another topic: you are storing the firmware in memory while the
> > > >> driver is bound. It's not necessary. You can release it after updating
> > > >> it on the chip.
> > > >>
> > > > I understand what you mean.
> > > > Based on the above conversation, your intention is that when the
> > > > customer needs to upgrade the firmware, they should modify the
> > > > comparison conditions of the version, then compile and burn the
> > > > kernel, and then perform the firmware upgrade, just like the LT9611UXC
> > > > driver. Instead of loading the firmware every time.
> > > > My design intention is to avoid the need for recompiling the driver
> > > > when upgrading. Instead, a file named "LT9611C.bin" can be directly
> > > > sent to the "/lib/firmware" directory via scp. Then you can either
> > > > perform a reboot for the upgrade or execute the command manually for
> > > > the upgrade.
> > > > Perhaps you are suggesting that we could follow the design approach of
> > > > the LT9611UXC driver?
> > >
> > > Yes no need to rebuild, just use sysfs to trigger an update.
> > >
> > I think you haven't attempted to understand the intention behind my design.
> >
> > If during the debugging process, the customer discovers that a certain
> > parameter in the chip's firmware is not suitable for the current
> > situation, then he requests a perfect firmware from our company to be
> > updated onto the chip.
>
> That's fine.
>
> >
> > When there are hundreds or tens of thousands of devices that need to
> > be updated, simply use sysfs to trigger the update. It is a very bad
> > thing.
>
> Delivering updates to devices it off-topic here. You can use SWUpdate,
> Mender or any other system to deliver updates and to trigger the
> firmware reflash afterwards.
>
> > If you want to use version number comparison as the upgrade condition
> > like in lt9611uxc.c, then the customer will need to modify the version
> > number comparison condition and rebuild the driver. This method is not
> > as simple as the one I have designed.
>
> Well, no. If there is a firmware update, it should be shared to
> linux-firmware and then everybody can benefit from it.
>
> Think about one company using your chip in their SoM or compute module
> and then another company integrating that module into their design?
> Who will contact you? Or a company selling devkits with your chip.
>
> Having per-customer firmware is a nightmare for developers and for
> integrators.
>

We are a company that sells our own developed chips. After other
platform design companies purchase our chips, they will design their
platforms based on the hardware schematic of our chips. During this
process, they must contact us. We will communicate about the design
opinions of the platform, the configuration of parameters, and the use
of custom firmware. We cannot provide a common firmware. This is
determined by the characteristics of the chips.

> > > >>>>> +
> > > >>>>> +     lt9611c->kthread = kthread_run(lt9611c_main, lt9611c, "lt9611c");
> > > >>>>
> > > >>>> Why do you need extra kthread for that???
> > > >
> > > > Upgrading the firmware takes time. execute it sequentially in the
> > > > probe function, it will block the system boot.
> > > > Using the kthread method will not block the system boot.
> > >
> > > Just follow the drivers/gpu/drm/bridge/lontium-lt9611uxc.c way to do this.
> > >
> > In fact, I think the method in lontium-lt9611uxc.c is a very bad one.
> > My clients often encounter situations where the system gets blocked
> > during the firmware upgrade process, and they have no idea what has
> > happened.
>
> Patches are welcome, please help us by improving LT9611UXC support :-)
>
> E.g. it would be nice to control InfoFrames or YUV output capabilities.
>
> --
> With best wishes
> Dmitry

Powered by blists - more mailing lists