linux-kernel - Re: (subset) [PATCH v4 00/29] Add HDMI support for RK3128

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 05 Jan 2024 18:50:35 +0100
From: Heiko Stübner <heiko@...ech.de>
To: Alex Bee <knaerzche@...il.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
 linux-rockchip@...ts.infradead.org, devicetree@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, Daniel Vetter <daniel@...ll.ch>,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 David Airlie <airlied@...il.com>, Rob Herring <robh+dt@...nel.org>,
 Sandy Huang <hjc@...k-chips.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>
Subject: Re: (subset) [PATCH v4 00/29] Add HDMI support for RK3128

Am Freitag, 5. Januar 2024, 18:33:34 CET schrieb Alex Bee:
> 
> Am 05.01.24 um 18:02 schrieb Heiko Stübner:
> > Am Freitag, 5. Januar 2024, 17:47:21 CET schrieb Alex Bee:
> >> Hi Heiko,
> >>
> >>
> >> Am 04.01.24 um 09:14 schrieb Heiko Stuebner:
> >>> On Fri, 22 Dec 2023 18:41:51 +0100, Alex Bee wrote:
> >>>> This is version 4 of my series that aims to add support for the display
> >>>> controller (VOP) and the HDMI controller block of RK3128 (which is very
> >>>> similar to the one found in RK3036). The original intention of this series
> >>>> was to add support for this slightly different integration but is by now,
> >>>> driven by maintainer's feedback, exploded to be a rework of inno-hdmi
> >>>> driver in large parts. It is, however, a change for the better.
> >>>>
> >>>> [...]
> >>> Applied, thanks!
> >>>
> >>> [23/29] drm/rockchip: inno_hdmi: Add variant support
> >>>           commit: 5f2e93e6719701a91307090f8f7696fd6b3bffdf
> >>> [24/29] drm/rockchip: inno_hdmi: Add RK3128 support
> >>>           commit: aa54f334c291effe321aa4b9ac0e67a895fd7b58
> >>> [25/29] drm/rockchip: inno_hdmi: Add basic mode validation
> >>>           commit: 701029621d4141d0c9f8b81a88a37b95ec84ce65
> >>> [26/29] drm/rockchip: inno_hdmi: Drop custom fill_modes hook
> >>>           commit: 50a3c772bd927dd409c484832ddd9f6bf00b7389
> >>>
> >>>
> >>> For reference, Rob has applied the rk3128 compatible in
> >>> https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git/commit/?id=21960bda59852ca961fcd27fba9f92750caccd06
> >> thanks for keeping track on this.
> >>
> >> Is there any reason the DT paches aren't merged yet? From what I can see
> >> they should be fine to be merged in your v6.8-armsoc/dts32 branch which is
> >> 6.7-rc1 based. There was only a txt-binding at this point and it's very
> >> likely that both the rockchip,inno-hdmi.yaml-conversion and the rk3128
> >> additon will both land in 6.8 (they are both in linux-next). Linus' 6.8
> >> merge-window will open earliest next week.
> > Exactly ... and the arm subarchitectures (Rockchip, etc) feed into the
> > more generic soc-tree[0]  and from there in a set of pull requests.
> >
> > Normally everything needs to go to the soc tree before -rc7 .
> > With the whole xmas stuff, I sent some stragglers in a second pull
> > request on monday, but that was already before Rob applied the
> > binding on tuesday.
> >
> > So 6.8 devicetree stuff is essentially done and the dts patches
> > from this series will go in to 6.9 .
> >
> >
> > Hope that explains things a bit :-)
> I assumed (for some reason) that sub-architecture maintainers are allowed
> to send PRs to the respective upper tree until the merge window opens and
> "all the rest" is done within this  ~2 weeks.
> Thanks for explaining.

No worries :-) .

The general rule of thumb is that everything should be done and ready
before the merge-window opens. Linus often writes very positively about
people sending him pull-requests even before the merge window opens ;-)
[meaning their tree is settled early and all test-robots have run]

And there are different rules in every tree.

For the soc tree the general rule of thumb of =< -rc7 - earlier with larger
changesets. On the other side drm-misc stays open all the time, but makes
a cut at -rc6. So everything targetted at v6.8 needs to be in before
v6.7-rc6.


Heiko