Date:	Fri, 11 Mar 2011 18:09:19 +0000
From:	Andy Green <andy@...mcat.com>
To:	Greg KH <greg@...ah.com>
CC:	Alan Stern <stern@...land.harvard.edu>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Arnd Bergmann <arnd@...db.de>,
	Linux USB list <linux-usb@...r.kernel.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Platform data for onboard USB assets

On 03/11/2011 05:08 PM, Somebody in the thread at some point said:
> On Fri, Mar 11, 2011 at 04:51:53PM +0000, Andy Green wrote:
>> On 03/11/2011 04:45 PM, Somebody in the thread at some point said:
>>
>> Hi -
>>
>>> Or to put it another way...  With external, hot-plugged USB devices,
>>> there is no need to know "how it is wired".  The fact that it is on a
>>> USB bus is the only information necessary.  Why does anyone need to
>>> know more than this for on-board USB devices?
>>
>> For example, the USB device is a chip with option pins.  On the
>> board it is placed on, some of the option pins are tied in a
>> particular way that impacts its actual function, but can't be seen
>> from the chip itself. The driver covers all the options, but it
>> needs to be told which mode the chip was wired up for.
>
> Then that information is in the driver that was written for that
> specific device, it is NOT a class device if it requires this type of
> information to work properly.

I don't believe I referred to class devices anywhere.  It does not 
matter if the main chip function is class device or not.

If there is any kind of "functional implementation" knowledge that is 
outside the chip and driver itself, it has to be held somewhere, and 
applied appropriately.  platform_data from the board definition file is 
the established place for that knowledge that is specific to a board.


An example of the same idea in a different context is OMAP4 I2C IP. 
There is a single I2C driver for all OMAP, and it adapts according to 
which revision of the IP it finds.  In the perfect case, the driver 
could thoroughly figure out what to do based on what it saw at runtime.

However different CPUs wired up their busses to these IP unit at 
different widths.  It meant according to that wiring topology 
information, you had to shift the register address by different amounts 
to access it.

Even though the driver had perfect domain knowledge of its IP core, 
there was some additional "functional configuration" knowledge that it 
HAD to be passed to succeed to operate correctly.  It could not infer 
this information from inside because this information was not in the 
configuration of the IP core itself.  The information described how the 
IP core "was wired".

They solve this by defining this cpu-specific information in 
cpu-specific files in the mach-omap2 dir and passing it up by platform_data.

> Also, do you have a real example of a USB driver today that needs this?

I think you find without devpath -> platform_data mapping, the kind of 
layout given above is made quite difficult to support in Linux.

Saying, "oh go away and do it in userspace" actually means special 
scripts that grep /proc/cpuinfo to reproduce the knowledge inherent 
already in the board definition file, although it's out of your hair 
nicely, it leaves me feeling we reached an overall solution that is 
"less good than it should be".

-Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists