All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.