Hi Jagan,
On 9 January 2015 at 03:53, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi,
I'm exploring internals of dm where I'm just comparing udevice with Linux model especially on device_id scenarios.
udevice_id - u-boot
Linux:
platform_device_id of_device_id
spi_device_id input_device_id .............. ....... pci_device_id
- Does this udevice_id is a generic model in u-boot for all variant of devices? Bcz Linux defines each devices have own device_id entries.
The device id is intended to describe a particular node compatible string which can be used with a driver. It corresponds most closely with of_device_id.
On the platform data size (not device tree) we have struct driver_info which is intended to connect a driver with its platform data, to produce a device.
- diff of of_device_id vs udevice_id
Linux has:
struct of_device_id { char name[32]; char type[32]; char compatible[128]; const void *data; };
U-Boot doesn't have a name and type. It uses a pointer instead of 128 bytes for the compatible string (for efficiency). For U-Boot we use a ulong instead of a pointer for data.
- udevice_id vs fdt function calls, suppose If I write a dm driver
where my board doesn't have fdt support, is this a valid scenario.
I'm not sure what you are asking. I'd encourage you to use device tree for new drivers.
- Pls- add any info which I haven't covered.
There's quite a bit of info about platform data and device tree in the driver model README.txt.
Regards, Simon