Sergei Shtylyov <sshtyl...@ru.mvista.com> writes: > 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. >
Or we could clone the pig, call it an OMAP-P1x, and teach it to fly ;) >> 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. Both of these seem like logical extensions of existing code. Not justification for new code. > 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). None of these live under arch/arm/* so are irrelevant to the decision of whether or not to create a new mach- dir. >> 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 see autodetection as an option for debug and development kernels. I have no problems with a slight performance hit for the auto-detect option when building multi-device kernels (yes, I know it is for *every* interrupt.) For single device kernels it can be #ifdef'd away as I suggested earlier. Kevin >>>> 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... > _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
