Message-ID: <x3g4qxksghteg4tcv6vmuaoie3c6lh3gkjsfwj2qn4lvim6o6t@hrjtunavnedj>
Date: Mon, 8 Sep 2025 13:17:36 +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 Mon, Sep 08, 2025 at 09:14:51AM +0800, 杨孙运 wrote:
> 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.

We are getting off-topic here, but this model has issues as the platform
design company might be completely different from the company that ends
up (re)using the platform in their products.

Anyway, I'm looking forward to reviewing the next iteration of the
driver. It is really appreciated when chip vendors work on the drivers
for their chips.

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists