Samsung S3C6410 mainline merge coordination

[jassisinghbrar@gmail.com (jassi brar)]

On Wed, Sep 2, 2009 at 11:47 PM, Mark Brown<broonie@sirena.org.uk> wrote:
> On Wed, Sep 02, 2009 at 10:44:35PM +0900, jassi brar wrote:
>
>> Yes, none of mainline SMDK supports SoC-Slave mode or sourcing I2S IP with
>> various possible clocks(PCLK, EPLL, CDCLK) etc yet. Samsung tree has
>> implemented
>> and fully tested these features for 6410, 6440 and C100.
>
> There's existing users in mainline with the S3C24xx working as slave,
> including some for which I have hardware so I'm fairly confident that
> that should work.
>
> I've also had reports that the S3C64xx works as slave in mainline, the
> code certainly claims that it should work.

Ofcourse, i can see Neo1973 implement SoC-Slave mode. There is no
reason why some users won't have 6410 running in Slave mode too at
their end.
I recently released one small but essential patch to you to make
wm8580 generate proper clocks -- essential when wm8580 is I2S master
-- that made me doubt if Slave support is even implemented/tested on
SMDKs in mainline.

My plan was to submit something like smdk_wm8580.c (smdks have wm8580
as the main I2S codec) which can be make menuconfig'ed for
SoC-Master/Slave and source clock support.
Plus, some logical re-arrangement of i2s.c code.
How about that?

>> My idea is to submit only "better enabled" I2S driver with Slave support.
> In general it's much better (and certainly standard practice within
> Linux) to enhance and refactor existing drivers incrementally rather
> than provide entirely new drivers.
I didn't exactly mean .c files.

>?The idea is to avoid confusion
> between the variants and issues that can come from replacing one
>set of problems with another.
got it.


>> In the long run, I see I2S drivers segregated by the I2S spec version
>> they implement....
>> S3C2410 has I2S-2.0, S3C6410 has I2S-3.2 and I2S-4.0, S5P6440 has
>> I2S-4.0, S5PC100 has
>> I2S-3.2 and I2S-5.1 and so on. That is, we have something like
>> samsung-i2s_v20.c, samsung-i2s_v32.c,
>> samsung-i2s_v40.c, samsung-i2s_v51.c.
>
> It really depends on how much difference there is between the blocks at
> what point it becomes worth forking a new driver - in many cases the
> newer blocks are close to register compatible with the older ones so
> a forked driver would have more in common with the original driver than
> the differences. ?Where that is the case it makes sense to try to keep
> things together but if conditional code begins to dominate some or
> all of the driver then that suggests forking the relevant bits.
Ofcourse, we shudn't keep 95% identical _v20, _v32, _v40 and _v50.c
For the time being, when our driver doesn't make use of any spec
differentiator, all SoCs can be served with a single file.
But as we implement more and more support to 40 (5.1channel)and 50(5.1
channel + channel mixing) versions, we will need segregation.
Ofcourse, intersection cud always be separated out, as does PXA.
But as i  said - In the long run.
As a starter we cud do by converting Samsung's I2S code 24xx(and even
s3c) agnostic?