On Wed, Mar 10, 2010 at 06:22:29PM +0900, jassi brar wrote:
On Wed, Mar 10, 2010 at 6:04 PM, Liam Girdwood lrg@slimlogic.co.uk wrote:
I don't think your reason of "co-ordination between ASoC and S3C ARCH trees" can justify breaking kernel policy.
I believe the policy is not against moving definitions of bits that are tightly linked to the device controller esp when we seeing more and more SoCs coming with standard of-the-shelf third party controllers.
Plus controllers that may be used in multiple subsystems (like the generic serial ports a lot of SoCs have). Some architectures also like to keep headers for the IPs with the arch either due to preference or due to device differences which can be hidden from the driver with arch level compile stuff.
I personally don't mind either way for things like the I2S controller which don't have any obvious application outside ASoC so whatever you guys and Ben want works for me.
Then, I really want S3C ASoC modifications to not wait on S3C ARCH patches appearing upstream first.
If the headers stay in arch/arm we can still deal with that by either agreeing to merge them via ASoC (as has been done in the past) or by creating a branch which is merged into both ASoC and Samsung trees. It is obviously less effort to avoid this, but it's not insurmountable.