H Hartley Sweeten wrote:
> On Monday, March 22, 2010 5:59 PM, Marek Vasut wrote:
>> Dne Po 22. března 2010 23:44:26 Graham Gower napsal(a):
>>> Marek Vasut wrote:
>>>> Dne Po 22. března 2010 07:03:29 Graham Gower napsal(a):
>>>>> Hi Marek,
>>>>> I wish to use the ucb1400_ts driver on my device. But I'm having trouble
>>>>> passing the platform_data to the ucb1400_core driver.
>>>>>
>>>>> I couldn't see any in tree examples of this being done and my attempts
>>>>> to do this via registering a platform_driver for ucb1400_core have
>>>>> failed (probably since this driver is ac97_bus_type, not a
>>>>> platform_driver).
>>>>>
>>>>> Can you provide me with info regarding the correct method for passing
>>>>> the irq to the driver?
>>>>>
>>>>> Thanks,
>>>>> -Graham
>>>> static struct ucb1400_pdata pdata = {
>>>> .irq = IRQ_GPIO(123),
>>>> };
>>>>
>>>> static struct platform_device ucb1400_core = {
>>>> .name = "ucb1400_core",
>>>> .id = -1,
>>>> .dev = {
>>>> .platform_data = &pdata,
>>>> },
>>>> };
>>>>
>>>> init() {
>>>> platform_device_register(&ucb1400_core);
>>>> }
>>>>
>>>> Like this ?
>>> That is the first thing I tried and it doesn't work. I suggest you printk
>>> the pdata in the ucb1400_core driver after having done this to confirm (I
>>> got NULL). You don't need to register a platform driver for
>>> ucb1400_core_probe() to be called anyway - presumably its enumerated from
>>> the ac97 bus.
>> Oh yes you have to, otherwise the pdata won't be passed. Besides, it's weird
>> probe()'s called if you didn't register it. But obviously whatever calls it
>> doesn't pass the pdata.
>
> The driver is registered with platform_driver_register, as such it will be tied
> to the platform bus not the ac97 bus. Being a platform driver, you do need a
> matching platform_device_register so that you get a device<->driver binding.
I suspect we are looking at different files, or different versions of the file.
I'm looking at drivers/mfd/ucb1400_core.c, which looks like this:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/mfd/ucb1400_core.c;hb=HEAD
The ucb1400_core is registered with driver_register.
I have grepped my tree and the only places I see "ucb12400_core" are in a couple
of arm board files and in my board file. Mine is commented out, and I definitely
still get the probe being called.
I added dump_stack() to the probe function.
[<80014f50>] dump_stack+0x8/0x34
[<801b1dec>] ucb1400_core_probe+0x48/0x1ac
[<801ab114>] driver_probe_device+0x128/0x254
[<801aa440>] bus_for_each_drv+0x60/0xb0
[<801ab3e4>] device_attach+0x60/0x88
[<801aa234>] bus_probe_device+0x30/0x54
[<801a8a74>] device_add+0x368/0x4f0
[<80210970>] snd_ac97_dev_register+0xa0/0xd8
[<801ef6e8>] snd_device_register_all+0x44/0x80
[<801eb2f4>] snd_card_register+0x64/0x18c
[<80216f3c>] snd_soc_instantiate_cards+0x368/0x5c4
[<80217214>] soc_probe+0x7c/0xc4
[<801ab114>] driver_probe_device+0x128/0x254
[<801aa440>] bus_for_each_drv+0x60/0xb0
[<801ab3e4>] device_attach+0x60/0x88
[<801aa234>] bus_probe_device+0x30/0x54
[<801a8a74>] device_add+0x368/0x4f0
[<801aca5c>] platform_device_add+0x14c/0x1b8
[<803813a4>] quokka_init+0x98/0xec
[<800180f0>] do_one_initcall+0x68/0x200
[<80371328>] kernel_init+0xc4/0x164
[<8001ac2c>] kernel_thread_helper+0x10/0x18
>
>> And yes, I printk'd it when I was sending this patch in and it worked for me ...
>> register the platform device and you should be ok.
>>>> btw. you don't have to pass pdata at all ... the logic for auto-detecting
>>>> IRQ is still there and is active if no pdata are supplied.
>>> This does not work for me. I have not yet investigated why.
>> I'd better get rid of that autodetection stuff altogether, but fttb it can be
>> there.
>
> Another reason your irq might not be working is that its not valid. Is gpio 123
> a valid IRQ producer on your platform? IRQ_GPIO(123) might resolve to
> (ucb->irq < 0) which would cause the probe to try auto detecting the irq.
This has nothing to do with the irq number that I'm passing (which is not 123
anyway). The ucb1400_core's dev->platform_data pointer is NULL.
>
> BTW, this driver looks a little scary.
>
> The 'platform data' that is passed to the driver is also the 'private data' used
> by the driver. Since the only data passed by the platform is the irq it would
> probably be cleaner to pass a struct ucb1400_pdata to the driver and kzalloc
> the private struct ucb1400_ts data in the driver.
>
> Just my 0.02...
>
> Regards,
> Hartley
-Graham
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
