Hello Tony, On Thu, Apr 24, 2014 at 5:42 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > * Javier Martinez Canillas <javier@xxxxxxxxxxxx> [140424 08:37]: >> Hello, >> >> On Thu, Apr 24, 2014 at 5:25 PM, Nishanth Menon <nm@xxxxxx> wrote: >> > On Thu, Apr 24, 2014 at 10:16 AM, Kevin Hilman <khilman@xxxxxxxxxx> wrote: >> >> Linus Walleij <linus.walleij@xxxxxxxxxx> writes: >> >> >> >>> On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas >> >>> <javier@xxxxxxxxxxxx> wrote: >> >>> >> >>>> I've revised the patch again and I couldn't find the reason why >> >>>> certain boards are failing to boot. >> >>>> >> >>>> I can't reproduce this issue since I only have a DM3730 IGEPv2 board >> >>>> which boots fine but I should have access to an AM3354 IGEP Aquila >> >>>> board which is similar to the am335x-evmsk so I may be able to debug >> >>>> it. >> >>> >> >>> It would really REALLY appreciate if some of the people maintaining >> >>> and using OMAP1 would help Javier out in this refactoring operation. >> >>> >> >>> I'd really *hate* to have to drop his patches because of a lack of >> >>> boards. This refactoring is necessary to handle the exploding >> >>> multitude of GPIO drivers moving forward. >> >>> >> >>> We even tried to get an Innovator to boot just to be able to refactor >> >>> OMAP stuff but fell short on some special JTAG reflash snag so >> >>> we are dependent on maintainers to help out here :-/ >> >> >> >> Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been >> >> able to get it booting again. I wonder if Spectrum Digital still has >> >> these available? Their websites[1] says "call for price." >> >> >> >> Kevin >> >> >> >> [1] http://www.spectrumdigital.com/product_info.php?products_id=39 >> > >> > >> > Perhaps dumb question: but are there folks who really care about omap1 >> > boot anymore in upstream? should it be time to deprecate it - say for >> > 3.17 or so? >> > >> > Regards, >> > Nishanth Menon >> >> I know that at least Aaro Koskinen (cc'ed here) still uses mainline on >> OMAP1 boards and he is always very helpful when is asked to test some >> changes on this platform. >> >> Having said that I also wonder if at least we should split omap >> drivers to have separate support for DT-only (or in a path to be) and >> non-DT (and with no work towards migration) platforms. Since trying to >> support both DT and legacy booting is each time more hard. > > It really should not matter what the configuration data for the > drivers is. Both platform_data and DT data should be easily supported. > Yes, I think I expressed myself badly. I actually meant platforms that keep evolving vs platforms that nobody is active developing on them and is unlikely that will ever use the newer infrastructure/API/whatever that is added on the different subsystems. In the GPIO OMAP driver example we have a lot of #ifdefery to separate OMAP1 and OMAP2+ code since OMAP1 does not support sparse IRQ (and probably never will) so it can't dynamically allocate IRQ numbers and I've seen similar things in other OMAP drivers. But yes, the maintenance burden is not that much either, I was just thinking aloud if splitting these drivers would make sense or not. > And we're moving towards using platform_get_irq() and other functions > for drivers anyways as that's generic for all the drivers no matter > what the driver data source is. > > Regards, > > Tony Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
