Re: RFC: Platform data for onboard USB assets

Andy Green
2011-03-11T18:09:26Z

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