Le 17.06.2010 17:02, jean-philippe francois a écrit :
- The description of alternative PINMUX configuration takes place in
da850_pins[] in da850.c
- Group of pins that describe a new feature can be defined in the
board-specific file (so they can be enabled in one call)
New features should be defined in the SoC file, because your board
might not be the only one to
need this feature.
Right, but there are an unfinite amount of possibilities so if every
single board based on OMAP-L138 want to have there own set of features
declared in the common SoC definition file upstream it will be quickly
very messy.
I think it's better to be able to cherry pick features other boards
have declared in their board-specific file and copy/modify them to be
integrated in my custom board file.
In my case I have to declare a group of GPIOs that are going to be used
to connect a matrix-keypad.
What are the chance that someone else will ever want to use the exact
same GPIOs to offer that feature ? If the GPIO are not the same then he
must declare a set of new MUX_CFGs and group them in a list so he can
enable them in his board specific file.
For example, let's say I want to enable CLKOUT2 on GIO31, on dm365.
With the following patch, I define it for
any board that might need it :
[...]
Thank you for the example.
On the other hand, if the new MUX_CFG is defined in your board file,
then every new board
that want to output CLKOUT2 on GIO31 will redefine this same features,
have a chance to get it wrong etc ...
Of course, if your board is the only in tree consumer of the new
features, it won't benefit to anyone else.
But it won't be harmful to you either.
Regards,
--
Christophe Aeschlimann
Embedded Software Engineer
Advanced Communications Networks S.A.
Rue du Puits-Godet 8a
2000 Neuchâtel, Switzerland
Tél. +41 32 724 74 31
[email protected]
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
