![](https://secure.gravatar.com/avatar/e75456e470b8672a32e02fc3c94a7776.jpg?s=120&d=mm&r=g)
Let me clarify, just in case, The patch-2/10 http://lists.infradead.org/pipermail/linux-arm-kernel/2009-September/000714.... enables this MACHINE driver to run 2 channels(of the 6 possible) of the I2S-v4 with the extant S3C CPU drivers, which do the job fine. The extant CPU drivers are inadequate only if we want 6channels and h/w mixing support.
On Sun, Sep 20, 2009 at 4:31 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Sun, Sep 20, 2009 at 10:49:50AM +0900, jassi brar wrote:
On Sun, Sep 20, 2009 at 1:08 AM, Mark Brown
I've applied this with a couple of additional fixups below. I've added a dependency on BROKEN since the IISv4 support is not yet present so there's no chance of it working yet.
well, i sent patches for CPU support also. they are simply put on hold until something is decided. if i were given a suggestion atleast i cud try doing that. anyways, the machine driver will almost remain the same in future when we the CPU support is there.
I think there was enough feedback on the CPU patches? IIRC the main issues were that the driver will need some way to tell that it's an IISv4 block (which it would be able to do with the existing arch/arm but not with the patches you sent)
Is it a bad idea to use only part, shared with I2S-v3, of I2S-v4 controller when the CPU driver doesn't yet support other distinguishing features? If yes, then I shud start writing the 6channel and h/w mixing stuff for the CPU driver. If no, then my patches can be accepted in current or modified form. When 6channel and/or h/w mixing is implemented in the CPU drivers we just enable those features in the controller.
and that the audio-bus clock has to be idmplemented so that the driver can probe (or the driver will need to be able to carry on if it can't get the clock).
somehow i missed emailing that patch. will resend with other parts.
Btw, I understand as soon as i see a newer for-2.6.xx branch i shud start submitting against that. Right?
For new features, yes. Bug fixes should be done against the version destined for Linus' current tree if the issue applies there.
got it. thanks
Another question ... The platform device s3c64xx_device_iisv4 is defined in arch/arm/plat-s3c/dev-audio.c whereas I2S_v4 is available only for S3C6410 and newer SoCs. Shudn't we define it somewhere like arch/arm/plat-s3c64xx/dev-audio.c? I ask because soon I'll be submitting the PCM controller CPU driver for S3C64XX and i wish to define it for s3c64xx specific platform, not the generic s3c. Please suggest.