* 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. 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 -- 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
