Message-ID: <zv7twvfxlira5wmg4zwk6kgkldgdiesgqzjky4733lp2us2hmx@tohls6czl3wz>
Date: Fri, 5 Sep 2025 17:24:02 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: 杨孙运 <yangsunyun1993@...il.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.

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.

> > >>>>> +
> > >>>>> +     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