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

[jassi brar]

On Wed, Dec 2, 2009 at 9:10 PM, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:
> 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).
yes ofcourse.

>  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
If I am aware of what things u miss, i can try to reply in some permissible way.

> but I have particular concerns
> about trying to fit more substantial functionality like hardware mixing
> support into the existing driver.
that was just to make the point. I understand h/w mixing needs to be
implemented as a 'secondary' playback stream. I have not got down to
implement more features as yet.