[alsa-devel] Reforming S3C I2S towards supporting I2Sv4

[jassi brar]

On Wed, Mar 10, 2010 at 6:04 PM, Liam Girdwood <lrg at 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 at 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.