[PATCH 4/7] S3C64XX: Declare IISv4 PCLK for S3C6410

[Mark Brown]

On Wed, Dec 02, 2009 at 09:50:15AM +0900, jassi brar wrote:
> On Wed, Dec 2, 2009 at 6:42 AM, Ben Dooks <ben-linux at fluff.org> wrote:

> > 1) If changing the .id field of the iisv4 device really a good idea,
> >   especially if there might be more than one of them in the future?

> Also, changing indices of devices with disregard to their respective clock
> might force further adhoc changes in system resources.

Well, from that point of view we'd be much better off with clkdev which
completely avoids the need to fiddle with id numbers to match clocks and
devices; the fact that this is a concern is really a limitation of the
clock API and open to fragility.  There would also be issues if someone
decided to do something like hang the PCM controllers off CLKAUDIO1 and
2 instead of 0 and 1, for example.  It's only a concern because there is
insufficient abstracton between the devices and clocks.

> I think, best wud be to modify s3c64xx_i2s.c to support 2 channel, 6
> channel, h/w mixing(maybe LP-Audio feature too) and pass flag for each
> feature via platform data
> by something like:-  .has_6_channels, .has_hw_mixer, .has_lp_audio etc

> The point to note here is to write drivers around functionality, rather than
> version, of the controller.

This can also be addressed via use of library code (which is what's
happening at the minute for the stuff that's shared between the 24xx and
64xx series).  You can also look at this from the point of view of
saying that IP blocks that are documented as having separate programming
interfaces should be presented in a similar way to the user so that it's
easier for them to find the functionality they need.

None of the approach I'm suggesting means that we can't have a single
driver file which handles more than one revision of the controller, we
can always move the registration of multiple variants into a single
source file.  The benefit is that we're not forced to do that so if the
conditional code gets to be too much which does seem likely - there's
already differences going from 24xx to 64xx, and I seem to recall that
there are some incompatibilities between IISv2 and IISv4 on the 6410 too.

Since Samsung have not been willing to share documentation (I do have
access to some but not all) it's hard to comment in detail on the most
tasteful way of handling all these things but I have particular concerns
about trying to fit more substantial functionality like hardware mixing
support into the existing driver.