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 ;)
OMAP-L1x is not a clone, don't be delusional. :-)
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.
Moving the exisiting code doesn't caount as a new code. :-P
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.
That's your problem. :-)
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.)
I guess we can just add a variable to check in these macros...
autodetection on every IRQ is not the price we have to pay even for
"debug and development kernels".
For single device kernels it can be #ifdef'd away as I suggested earlier.
Which would also make alternate mapping of AINTC pointless waste of page.
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
