[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <irvff5zmeqyy7yn3idc5rr2ekx5gmpcib45rrqk2vhkt33mdy4@q346i2jkehtt>
Date: Thu, 4 Sep 2025 05:17:54 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Yury Norov <yury.norov@...il.com>
Cc: Heiko Stuebner <heiko@...ech.de>, Andy Yan <andyshrk@....com>,
mripard@...nel.org, neil.armstrong@...aro.org, andrzej.hajda@...el.com,
jernej.skrabec@...il.com, jonas@...boo.se,
Laurent.pinchart@...asonboard.com, maarten.lankhorst@...ux.intel.com,
rfoss@...nel.org, simona@...ll.ch, tzimmermann@...e.de,
knaerzche@...il.com, devicetree@...r.kernel.org,
dri-devel@...ts.freedesktop.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org,
Andy Yan <andy.yan@...k-chips.com>
Subject: Re: [PATCH v7 1/2] drm/rockchip: inno-hdmi: Convert to drm bridge
On Wed, Sep 03, 2025 at 05:01:14PM -0400, Yury Norov wrote:
> On Wed, Sep 03, 2025 at 03:30:47PM +0300, Dmitry Baryshkov wrote:
> > On Wed, Sep 03, 2025 at 01:59:51PM +0200, Heiko Stuebner wrote:
> > > Hi Andy,
> > >
> > > Am Mittwoch, 3. September 2025, 13:07:38 Mitteleuropäische Sommerzeit schrieb Andy Yan:
> > > > From: Andy Yan <andy.yan@...k-chips.com>
> > > >
> > > > Convert it to drm bridge driver, it will be convenient for us to
> > > > migrate the connector part to the display driver later.
> > > >
> > > > Signed-off-by: Andy Yan <andy.yan@...k-chips.com>
> > >
> > > more like a general remark, this essentially conflicts with the
> > > big hiword-cleanup [0] that was merged today, as the inno-hdmi driver
> > > "lost" its separate HIWORD_UPDATE macro in favor a nicer generic one.
> > >
> > > I'm not sure what the best way to proceed is, apart from waiting for
> > > 6.18-rc1.
> >
> > I'd say, the correct way to handle would have been to:
> > - merge only FIELD_PREP_WM16 addition into bitmap-for-next using
> > immutable tag
> > - merge the tag + all other patches into subsystem trees. Otherwise
> > that series can cause a lot of conflicts with all affected subsystems.
> >
> > Yury, would it be possible to implement this plan instead of pulling
> > everything through your tree?
>
> Yeah, this is 100% technically correct way of moving things.
>
> The problem is that driver maintainers are usually not quick taking
> this type of changes. In my experience, if we merge #1 only, we'll
> end up with just another flavor of HIWORD_UPDATE(), maybe adopted
> by a couple of drivers.
>
> This is exactly opposite to the original goal of the series: nice and
> almost complete consolidation of scattered HIWORD_UPDATE() versions.
>
> So far, there's the only conflict with the others, and Andy said he's
> OK to hold his series.
>
> I would prefer to have all those patches in bitmap-for-next for a while.
> If there will be more conflicts, then yeah, I'll follow your route.
> Otherwise, let's keep things as they are, and encourage developers to
> test their patches against linux-next, as they normally should.
Ack, thanks for the explanation.
--
With best wishes
Dmitry
Powered by blists - more mailing lists