Hi, On Thu, Aug 01, 2024 at 10:59:38AM +0200, Arnd Bergmann wrote: > > 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. > > >> === 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.
