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��.n��������+%������w��{.n�����{��)��^n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�m
