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
