Hi,

On Thu, Aug 01, 2024 at 10:59:38AM +0200, Arnd Bergmann wrote:

quoted

These tablets are not very attractive for hobbyists anymore as the display
support got broken and eventually deleted due to bitrot. There has been
some out-of-tree patches/interest to regain display and other features,
but no major progress really in 10 years or so. The last major mainline
feature was adding Retu watchdog support that allowed the device to stay
on longer than 30 seconds after the boot (the hardware watchdog cannot
be disabled).

I guess in OMAP-land N8x0 is one of the least used/active boards, so if
it causes "a lot of pain" then maybe could be a candidate for deprecation.
But with custom kernel config, the board has been pretty stable overall
between the releases for limited use cases.

Yes, I think it would help a lot to deprecate it, at least this
would save me the work of moving ARMv6 into an ARMv5 compatible
option (I have done the patches, but they are entirely untested
on real hardware and probably incorrect).

Would the timing make any difference to you? I.e. does it help
to keep another year or two, or would dropping it in early 2025
be the same?

Early 2025 could come too soon, but anyway during 2025 sounds OK. Let's
see if anyone else has comments. At least one more LTS release where it
has been tested would be nice.

We'd also want to coordinate this with the i.MX31 maintainers,
since dropping both together is the only way to remove
ARM1136r0 support.

quoted

quoted

=== OMAP1 ===

This is now the only ARMv4T/ARMv5 platform with no
DT support, making it a target for removal at some
point. Unlike PXA, there are still users, but it seems
there are no current plans for a DT conversion.

I would suggest going through the five boards
individually to see which ones we can remove in 2025
and keep the remaining ones for the moment.

Here situation hasn't changed - all of the boards are equally
important/useful, at least from a maintainer point of view. The routine
I use to test/debug kernel releases relies on all of them.

Ok, noted. Since you are doing the testing, that at least means
we have a chance of cleaning up the code gradually towards using
DT. Dmitry has started a migration of platform_data towards
DT compatible device properties, which can be done gradually
for the 22 platform drivers you use. This unfortunately still
leaves the nonstandard dmaengine interface (for UDC), but we
can deal with that later.

I have some plans to work on that. There's a long-standing bug with 15xx
DMA, but I have gotten that working, just need send those fixes out. After
that the conversion to new dmaengine should be more straightforward,
as we have a working testable reference for both boards using the UDC.

A.