Hello.
Kevin Hilman wrote:
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.
CPPI 4.1 code will live there...
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.
How do you imagine that? Well, cp_intc should be enabled be
selecting DA8xx support. But how to differe the case of only DA8xx
support enabled (not needing the "adaptive" code in entry-macro.S) from
the case of the multi-SoC kernel. Are you going to do something like that:
#ifdef CONFIG_ARCH_DA8xx)
#if defined(CONFIG_DAVINCI_DM644x) || defined (CONFIG_DAVINCI_DM646x) ||
defined(CONFIG_DAVINCI_DM355)
/* adaptive code */
#else
/* cp_intc only code */
#endif
Note that the same long dependency on DM644x or DM646x or DM355 will
be needed for enabling the AINTC support code. I think it will be rather
cumbersome, and it seems worth adding an option named like
CONFIG_ARCH_DAVINCI_TRUE to be defined by that combination.
Kevin
WBR, Sergei
_______________________________________________
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
