On Mon, Jun 08, 2009 at 11:43:41AM +0200, Manuel Lauss wrote:
On Mon, Jun 8, 2009 at 11:25 AM, Mark Brownbroonie@opensource.wolfsonmicro.com wrote:
If this is going to go in during the merge window I'm happy for it to go in via the MIPS tree but otherwise I'd much rather it goes via ASoC in case API changes cause merge issues. I don't know what you prefer, Ralf?
I'd rather have it all go through the MIPS tree; this is the only patch of 7 which touches files outside it, and it depends on another one to apply cleanly.
Well, like I say if it's going via MIPS I'd really prefer it to go in this merge window. If not then I'd expect that splitting out the architecture parts from the machine driver as I suggested ought to deal with the merge issues.
I'd actually love to move this file to the actual board code, however due to the way ASoC is organized this isn't at all possible. This is one of two things I don't like about ASoC: the machine registration is extremely awkward
The main problem long term with trying to move it into the architecture code is that the drivers for anything non-trivial get large enough to qualify as actual drivers - add a jack or two in there, or some more fancy clocking for example. I also catch enough errors in the machine drivers I'm reviewing that I'm a bit nervous about reducing the level of review that they get.
At the minute the APIs are too fluid to make this realistic, anyway - you'd just get constant merge issues.
compared to other platform drivers. (the other being that ASoC doesn't support multiple machines [i.e. I could actually run both AC97 and I2S simultaneously one of my boards, as independent sound cards])
I've got a board sitting on my desk here which has multiple sound systems. Unfortunately the architecture code for it is a bit of a shambles at this point so it's more trouble to work on the platform than it's worth at the minute.
+static struct resource psc1_res[] = {
If you conver the I2S driver to use the standard device probing model this could all me moved into the architecture code rather than placed in machine drivers.
Again, I'd love to, but can't: the AC97/I2S/DBDMA drivers extract base address and DMA information from the platform device resource structure; however I can't just copy the resource info from the this db1200_sound platform_driver to the soc_audio platform driver because the driver core complains about resource conflicts (two platform_devices sharing the same resources). Unless I missed a flag which needs to be passed to the resource.flags member?
If you move the selection of the switch position to the architecture code then it can arrange to register only the device that is in use in the current configuration. If the DMA and DAI drivers both need the same resources they can cooperate with each other - the system will only bring the card on-line once both the DMA and DAI driver are present.
I'd not be too concerned about having the machine driver be able to flip between the two at run time - it's unlikely to be a realistic concern for anything except reference boards and even with those it's relatively unlikely that anyone will be doing that on a regular basis. The wins for general users of the driver should cause an overall reduction in pain.