Re: UCB1400: Passing IRQ through platform_data

Re: UCB1400: Passing IRQ through platform_data

[Marek Vasut]

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 ?

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

Re: UCB1400: Passing IRQ through platform_data

[Graham Gower]

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.

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

-Graham

PS: I am on mips, not arm. Arm CC removed.
--
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

Re: UCB1400: Passing IRQ through platform_data

[Marek Vasut]

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.

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.
> 
> -Graham
> 
> PS: I am on mips, not arm. Arm CC removed.
> 
--
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

RE: UCB1400: Passing IRQ through platform_data

[H Hartley Sweeten]

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.

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

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

Re: UCB1400: Passing IRQ through platform_data

[Graham Gower]

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

RE: UCB1400: Passing IRQ through platform_data

[H Hartley Sweeten]

On Monday, March 22, 2010 6:39 PM, Graham Gower wrote:
> H Hartley Sweeten wrote:
>>>> 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

Ah, I just saw that.  I was only looking at the ucb1400_ts.c driver itself and
the only direct in-tree user arch/avr32/boards/atngw100/mrmt.c.  I didn't notice
that there was also a mfd driver.

> The ucb1400_core is registered with driver_register.

That mfd driver still registers it's children as platform drivers using
platform_device_alloc, platform_device_add_data, and platform_device_add.

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

The only in tree users of the mfd driver appear to be mach-pxa/cm-x2xx.c and
mach-pxa/palmtc.c, neither of which pass the platform_data.

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

That number was from the avr code.  Sorry for any confusion.

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

I'm going to step out of this one.

I started looking at the mfd driver to see if I could help out with your problem.
I honestly don't even get how this all works....

The two in-tree users register the 'ucb1400_core' device differently.  cm-x2xx.c
uses platform_device_register and palmtc.c uses platform_add_devices.  Those two
paths are completely different, but they probably get to the same state eventually.

The ucb1400_core driver registers a 'device_driver' on the ac97 bus.  As such, it
probably does get probed by the ac97 bus not the platform bus.  The actual ucb1400_core
probe function probably isn't even tied to the correct platform data, it's parameter
is a struct device * not a struct platform_device *.

Anyway, good luck.  Sorry I can't offer any help.

Regards,
Hartley

Re: UCB1400: Passing IRQ through platform_data

[Marek Vasut]

Dne Út 23. března 2010 02:39:19 Graham Gower napsal(a):
> 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=d
> rivers/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

Aren't you probing it from some driver or something ?
> 
> >> 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.

We know it is NULL ... that's because you're not passing it.
> 
> > 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

Re: UCB1400: Passing IRQ through platform_data

[Marek Vasut]

Dne Út 23. března 2010 03:08:21 H Hartley Sweeten napsal(a):
> On Monday, March 22, 2010 6:39 PM, Graham Gower wrote:
> > H Hartley Sweeten wrote:
> >>>> 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
> 
> Ah, I just saw that.  I was only looking at the ucb1400_ts.c driver itself
>  and the only direct in-tree user arch/avr32/boards/atngw100/mrmt.c.  I
>  didn't notice that there was also a mfd driver.

There's no ucb1400_ts anymore. There's only the MFD driver, nothing else.
> 
> > The ucb1400_core is registered with driver_register.
> 
> That mfd driver still registers it's children as platform drivers using
> platform_device_alloc, platform_device_add_data, and platform_device_add.
> 
> > 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.
> 
> The only in tree users of the mfd driver appear to be mach-pxa/cm-x2xx.c
>  and mach-pxa/palmtc.c, neither of which pass the platform_data.

You can pass platform data as I said in the earlier example. That was tested on 
PalmTC.
> 
> >>> 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.
> 
> That number was from the avr code.  Sorry for any confusion.

The '123' was just a silly number, an example, you need to fill you own ... it 
wasnt from AVR code.
> 
> >> 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...
> 
> I'm going to step out of this one.
> 
> I started looking at the mfd driver to see if I could help out with your
>  problem. I honestly don't even get how this all works....

Maybe I'm starting to recall how that whole thing worked. I took a look at the 
code and my guess might be -- it takes pdata from the ac97 bus. I'm not sure 
here, but pxa2xx-ac97 allows passing platform data through the ac97 bus, dunno 
how are other platform's ac97 implementations. If I'm right here, you might need 
to fix your mips-whatever-ac97 to allow passing platform data and then pass them 
through there.

If that's the case, the earlier example was wrong and you should start digging 
around ac97 (see git log for pxa2xx-ac97.c and find a patch that added this 
passing of platform data there).
> 
> The two in-tree users register the 'ucb1400_core' device differently. 
>  cm-x2xx.c uses platform_device_register and palmtc.c uses
>  platform_add_devices.  Those two paths are completely different, but they
>  probably get to the same state eventually.
> 
> The ucb1400_core driver registers a 'device_driver' on the ac97 bus.  As
>  such, it probably does get probed by the ac97 bus not the platform bus. 
>  The actual ucb1400_core probe function probably isn't even tied to the
>  correct platform data, it's parameter is a struct device * not a struct
>  platform_device *.
> 
> Anyway, good luck.  Sorry I can't offer any help.
> 
> Regards,
> Hartley
> 
--
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

Re: UCB1400: Passing IRQ through platform_data

[Graham Gower]

Marek Vasut wrote:
> Dne Út 23. března 2010 02:39:19 Graham Gower napsal(a):

>> 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
> 
> Aren't you probing it from some driver or something ?

I register an ac97 platform driver from an arch_initcall function. It looks
like the ucb1400_core driver is probed once the ac97 device is found.


>> 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.
> 
> We know it is NULL ... that's because you're not passing it.

When I attempt to pass it via a platform device with platform_add_devices, it
is still NULL. I suspected that it was NULL because the ucb1400_core
isn't a platform_driver  - thus I commented out the platform device
for ucb1400_core in my arch_initcall and sure enough the probe was still
being called.

-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

Re: UCB1400: Passing IRQ through platform_data

[Graham Gower]

Marek Vasut wrote:
> Maybe I'm starting to recall how that whole thing worked. I took a look at the 
> code and my guess might be -- it takes pdata from the ac97 bus. I'm not sure 
> here, but pxa2xx-ac97 allows passing platform data through the ac97 bus, dunno 
> how are other platform's ac97 implementations. If I'm right here, you might need 
> to fix your mips-whatever-ac97 to allow passing platform data and then pass them 
> through there.
> 
> If that's the case, the earlier example was wrong and you should start digging 
> around ac97 (see git log for pxa2xx-ac97.c and find a patch that added this 
> passing of platform data there).

Thanks, that was the clue I needed. With a small fix[0], I can now pass the
platform_data successfully through the ac97 codec.

-Graham

[0] http://mailman.alsa-project.org/pipermail/alsa-devel/2010-March/026419.html