* Mark Brown | 2008-04-24 15:57:52 [+0100]:
On Thu, Apr 24, 2008 at 04:04:59PM +0200, Sebastian Siewior wrote:
I've sent a RFC to the alsa mailing list [1] about adding an extra field in order to pass the IRQ from the AC97 driver to the ucb1400 driver. The result was:
Now I'm curious what solution the people here prefer:
- adding a private field [1] (my favorite)
As I indicated in reply to your initial RFC any such private field ought to be a void * in order to allow other information to be passed through to drivers.
I got that.
Note that this will also need changes in all the relevant AC97 drivers to support getting the private data from platform/machine definition code to the relevant driver using whatever methods are appropriate for the platform.
Sure. I haven't found any driver that needs any extra information. For instance a board that uses ucb1400_ts and gets the interrupt via auto probing can't be auto converted due to -ENOCLUE. Therefore the ucb1400 driver acts like before if the private field is NULL.
- hacking up the ucb1400 [2] (doesn't solve [3] and needs addition code to solve [4]).
[3] is the issue with the WM97xx touchscreen drivers. That's currently solved by exactly this issue - as far as I can see from the patch you cite you're using OpenFirmware. In that case isn't modifying the driver to query OpenFirmware an idiomatic solution anyway (though it still leaves other platforms in the lurch)?
Not really. I have to parse the whole device tree and pick one single value. This isn't done by any other driver as far as I can see and it equals a global variable. My device tree currently looks like the following:
| ac97@f0000400 { | compatible = "fpga-ac97"; | reg = <f0000400 100>; | interrupts = <5 1>; | interrupt-parent = <&mpic>; | ucb1400@ac97 { | compatible = "Phillips,ucb1400_ts" | interrupts = <9 0>; | interrupt-parent = <&mpic>; | } | };
Now, while I get auto probed for my device (fpga-ac97) I grab and setup the IRQ for the ucb1400_ts device and pass the IRQ-number in the ac97 struct. If you have a platform driver you can still do something like:
|static struct resource smc91x_resources[] = { | { | .start = 0x20200300, | .end = 0x20200300 + 16, | .flags = IORESOURCE_MEM, | }, { | .start = IRQ_PF0, | .end = IRQ_PF0, | .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHLEVEL, | }, |}; |static struct platform_device smc91x_device = { | .name = "smc91x", | .id = 0, | .num_resources = ARRAY_SIZE(smc91x_resources), | .resource = smc91x_resources, |};
and add another IORESOURCE_IRQ field with holds the interrupt number for your ac97 device (in case of ucb1400_ts or some other thing for a total different driver). The ucb1400_ts driver itself does not care anymore because it is getting this information from the ac97 struct.
- something totally different what did not come to my attention yet.
Something that worked for more than just AC97 would be nice - a method for getting platform data to drivers for devices on buses that are normally autoprobed.
I thing here is a miss understanding. What would be something beside ac97? Gimme a real world example plz. According to grep ucb1400 is the driver attached to ac97 bus (well, nothing else matches on ac97_bus_type except the sound & codec thing in sound/ which don't need any extra parameters).
Sebastian