From mboxrd@z Thu Jan 1 00:00:00 1970 From: jassisinghbrar@gmail.com (jassi brar) Date: Fri, 4 Dec 2009 22:17:33 +0900 Subject: [PATCH 4/7] S3C64XX: Declare IISv4 PCLK for S3C6410 In-Reply-To: <20091202121053.GC12661@rakim.wolfsonmicro.main> References: <20091127164312.GA11913@rakim.wolfsonmicro.main> <1259340239-12067-4-git-send-email-broonie@opensource.wolfsonmicro.com> <20091201214201.GP4808@trinity.fluff.org> <1b68c6790912011650p58cc6b27n90b032167ebb9bc8@mail.gmail.com> <20091202121053.GC12661@rakim.wolfsonmicro.main> Message-ID: <1b68c6790912040517o2902916ckc6628c2ac9bf6088@mail.gmail.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, Dec 2, 2009 at 9:10 PM, Mark Brown 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 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.