Hello.
Kevin Hilman wrote:
Either way, the lack of a complete proposal (not necessarily
in the form of patches) makes it hard to get anywhere with
such OMAP-L1xx discussions...
I think I've expressed it clear enough: common shared code is
to be moved to plat-davinci/ and OMAP-L1x support is to be
added into new mach- directory.
And yet Kevin felt that was missing details (not complete)...
While that sounds plausible to me at this point, it's also
clear that the missing details could make a big difference.
Let us be more clear. What exactly details are needed?
The technical justification for a new mach- + plat- directory. In
particular, justification for why extending current code in existing
mach-davinci cannot work.
I guess it can. Pigs can fly too, given enough thrust.
So far, in terms of core code (stuff that lives under arch/*) I've
heard that the primary differences are
- new INTC
- additional PSC (but same programming model)
- new pinmux layout
Mostly the PinMux register being protected in fact. The 4-bit per pin
seems to be taking DM355's layout further.
TIMER64+ too, with the compare regs that we have to use.
MUSB driver will need the different DMA driver and different glue
layer but that's outside the scope of arch/arm/ (DMA driver needs to be
backed by CPPI 4.1 support though). There's also .
There are some additional devices like OHCI, RTC (seems tobe
OMAP-alike IIUC)... video stuff is totally missing but that hasn't
appear in upstream still IIUC.
SPI controller is extended compared to DaVinci one. MMC works a bit
differently, so the driver will need additional platform data and EDMA
related changes (even for PIO mode).
To me these are hardly justification for a new mach directory. I see
relatively simple solutions for these in the current framework.
I don't see an acceptable solution to the cp_intc issue -- unless you
want to live with #ifdef'ery... autodetection is certainly *not* an option.
I suspect that until patches appear, discussion can get no
further. Plus, if it's going to be "mach-omap-L1" it'd
be good to have enough detail that the OMAP team (and RMK)
can see why it should pair with "plat-davinci" instead of
the more obvious "plat-omap".
Damn that rename again...
Exact marketing names aside... The fact remains that the omap name is
a marketing name. The vast majority of the HW IP is shared with the
rest of the DaVinci family. I'm not aware of any HW IP shared with
OMAP (other than MUSB.)
Probably only RTC (according to Mark's words). I'm not familiar with
OMAP much...
Kevin
WBR, Sergei
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
