Re: [meta-ti] [dunfell/master PATCH 0/6] am65x/j7*: Remove non-existent 5.10.y dtb*

["Denys Dmytriyenko" <denis@denix.org>]

Praneeth,

On Sun, Apr 18, 2021 at 11:51:06PM -0500, praneeth via lists.yoctoproject.org wrote:
> On 4/16/2021 12:35 PM, Denys Dmytriyenko wrote:
> >On Thu, Apr 15, 2021 at 04:22:20PM -0400, Denys Dmytriyenko wrote:
> >>On Thu, Apr 15, 2021 at 02:00:31PM -0500, Bajjuri, Praneeth wrote:
> >>>On 4/15/2021 1:24 PM, Denys Dmytriyenko wrote:
> >>>>On Thu, Apr 15, 2021 at 12:07:05PM -0500, praneeth via lists.yoctoproject.org wrote:
> >>>>>Denys,
> >>>>>
> >>>>>On 4/15/2021 12:10 AM, praneeth@ti.com wrote:
> >>>>>>From: Praneeth Bajjuri <praneeth@ti.com>
> >>>>>>
> >>>>>>The current ti-linux-5.10.y integration branch doesnt have support for
> >>>>>>non base board dtb/o form the primary latest processor board on am65 and
> >>>>>>j7* evms yet.
> >>>>>>
> >>>>>>Removing these dtb/o for enabling the builds to continue.
> >>>>>>Plan to add these blob and overlays back once the equivalent support is
> >>>>>>added in the integrated ti-linux-5.10.y kernel.
> >>>>>>
> >>>>>
> >>>>>Need your recommendation if this is the right approach to enable the
> >>>>>builds at this early stage of LTS migration (and re-enable the
> >>>>>overlays once the support is added in kernel).
> >>>>
> >>>>That's kind of normal to start a new LTS with bare minimum of dtb/o support.
> >>>>
> >>>>But I have 2 concerns:
> >>>>
> >>>>1. Maybe better to just push commit with removal, instead of reverting old
> >>>>commits - it may get quite confusing soon with reverts of reverts...
> >>>
> >>>makes sense. will squash in v2.
> >>>
> >>>>
> >>>>2. Do you think it's still premature to make 5.10 as a default in meta-ti
> >>>>dunfell branch? Since dunfell is kind of established stable (not a new LTS),
> >>>>anyone who updates meta-ti will go from fully working 5.4 to a very minimal
> >>>>and bare 5.10 - may be a bad user experience...
> >>>
> >>>Was thinking in similar line.
> >>>So, till the 5.10 baseline matures i will continue to use
> >>>dunfell-next to stage the patches and keep dunfell branch untouched
> >>>w.r.t merging 5.10 specific changes.
> >
> >Another approach could be to keep using core-next branding for a bit longer,
> >leaving 5.4 as a default, until 5.10 is ready.
> 
> the final SDK release with 5.4 on dunfell has already been made so
> not aware of anyone using this combination for active development
> now.
> 
> and 5.10 needs to be getting to a better shape soon.
> Thinking, it makes sense to switch to 5.10 and start addressing the
> regressions as we progress with development.

I see dunfell has been merged with "empty" 5.10 which is the default.
What happened to keeping this to dunfell-next for now? As you said above:

| So, till the 5.10 baseline matures i will continue to use
| dunfell-next to stage the patches and keep dunfell branch untouched
| w.r.t merging 5.10 specific changes.

While I understand the need to migrate from 5.4 to 5.10 and get developers 
working on it, willingly introducing regressions into a stable branch is 
quite undesirable. Anyone developing a product for a TI part with meta-ti 
would normally pull the latest stable branch. And while last week it used 
to work perfectly fine, providing full-featured 5.4 experience, this week 
it appears to be very barebone and with limited features 5.10 experience by 
default...

Will be needing to advise people to pin down to 07.03.00.005 tag and not rush 
to the latest 2021.00.001 tag for now.


> >>>Let me know if this a good approach, The only problem in that case
> >>>is the graphics update for 5.10 that i recently pulled to dunfell
> >>>branch. Need to revert it to keep 5.4 dunfell experience retained.
> >>
> >>Try those updates first with 5.4 before reverting them, mayve they'll work.
> >>
> >>
> >>>Any other ideas?