From: Graham Gower <graham.gower@gmail.com>
To: H Hartley Sweeten <hartleys@visionengravers.com>
Cc: Marek Vasut <marek.vasut@gmail.com>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>
Subject: Re: UCB1400: Passing IRQ through platform_data
Date: Tue, 23 Mar 2010 12:09:19 +1030 [thread overview]
Message-ID: <4BA81BC7.9040107@gmail.com> (raw)
In-Reply-To: <0D753D10438DA54287A00B02708426976368DDD220@AUSP01VMBX24.collaborationhost.net>
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-03-23 1:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4BA70831.1040606@gmail.com>
2010-03-22 13:13 ` UCB1400: Passing IRQ through platform_data Marek Vasut
2010-03-22 22:44 ` Graham Gower
2010-03-23 0:59 ` Marek Vasut
2010-03-23 1:25 ` H Hartley Sweeten
2010-03-23 1:39 ` Graham Gower [this message]
2010-03-23 2:08 ` H Hartley Sweeten
2010-03-23 3:13 ` Marek Vasut
2010-03-24 5:07 ` Graham Gower
2010-03-23 3:01 ` Marek Vasut
2010-03-23 3:31 ` Graham Gower
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BA81BC7.9040107@gmail.com \
--to=graham.gower@gmail.com \
--cc=hartleys@visionengravers.com \
--cc=linux-input@vger.kernel.org \
--cc=marek.vasut@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).