On Wed, Mar 10, 2010 at 6:04 PM, Liam Girdwood lrg@slimlogic.co.uk wrote:
On Wed, 2010-03-10 at 17:31 +0900, jassi brar wrote:
On Wed, Mar 10, 2010 at 5:24 PM, Liam Girdwood lrg@slimlogic.co.uk wrote:
On Wed, 2010-03-10 at 16:48 +0900, Jassi Brar wrote:
The header with I2S register map and bit definitions has been copied to where the drivers are(sound/soc/s3c24xx/) since the header has nothing usable for platform code. Also, it will help avoid need for co-ordination between ASoC and S3C ARCH trees. For now, the header regs-s3c2412-iis.h is left intact but rendered useless by making ASoC drivers include the newly copied version of it (sound/soc/s3c24xx/regs-i2s-v2.h) Later the header could be dropped by patches to S3C PLAT tree.
I'm not too keen on moving CPU register and bit definitions out of ARCH.
The header doesn't contain absolute register addresses, but only offsets.
Isn't this really the same thing ?
If two SoCs have same controllers but mapped at different addresses, the ARCH maintainer would find a common place for the header rather than making two headers with one define different and rest all same. If another such SoC comes up the cycle starts again.(That has apparantly happened with S3C support over the years) Now, rather than moving around the header with definitions of what is _only_ used by the controller driver, why not move it close to the driver? The base addresses can(and should) always be defined in PLAT specific location.
The base address of I2S controllers are defined in PLAT specific header. So, I think we can move the header.
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. Some drivers do have the controller bit definitions beside drivers. I could atleast see some serial and spi drivers.
Then, I really want S3C ASoC modifications to not wait on S3C ARCH patches appearing upstream first.
Having said that, I am willing to(not to mean I have another choice) take word of the maintainer on the matter and first send patches to s3c ARCH and wait until they appear in Mark's tree before submitting the remaining patches.