linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).