Re: [PATCHv9 03/18] TEMP: OMAP3xxx: hwmod data: add PRM hwmod

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/13/2011 6:51 PM, Paul Walmsley wrote:
On Thu, 13 Oct 2011, Paul Walmsley wrote:

On Wed, 12 Oct 2011, Cousson, Benoit wrote:

On 10/11/2011 1:26 AM, Paul Walmsley wrote:
On Tue, 11 Oct 2011, Cousson, Benoit wrote:

In fact the device name does not have to match the hwmod name. So we
can just create an "omap2_prm" omap_device for OMAP2, "omap3_prm"
omap_device for OMAP3... That will allow the relevant PRM driver to
be bound to the proper device.

Incidentally, given that we would be using the hwmod name and the version
number to determine the appropriate omap_device name, what IP version
numbers should we assign to these PRM IP blocks for different SoCs?

It can just be 1, 2 and 3... The idea is just to differentiate the IP for each
OMAP.

So those are basically arbitrary?  Something is not clear here.

In the current hwmod design, IP blocks with different interfaces were
intended to be uniquely identified by the hwmod name alone.  That is why
omap_hwmod_lookup() only takes a 'name' parameter.

If I understand what you want to do, you wish to change this to uniquely
identify them by a (name, interface version number) tuple.

I don't have a problem with this in theory, but it implies some changes to
the existing model.  Specifically:

- we'll need to add an interface version number to the struct omap_hwmod

- we'll need to modify omap_hwmod_lookup() to take an interface version
number

- the "ti,hwmod" DT binding that you proposed earlier will need to include
an interface version number

Hmm, reflecting on this further, is your intention to bind drivers to
hwmods by the struct omap_hwmod_class instead?

Well, somehow, the class was added for that purpose, to allow one timer driver to bind to 2 different hwmods. But in that case the device name was the same.

If we define that "rev" field as the interface version number, that should
probably work.

So then in C struct format, in a platform_device system, the mapping table
would basically become

struct omap_hwmod_driver_map {
	const char *class_name;
	const u32 class_rev;
	const char *platform_device_name;
}

This is needed if and only if you want to have a different driver for the same IP.

In the case of the timer, we do have only one device name and one driver:
class=timer, rev=1, device=omap_timer
class=timer, rev=2, device=omap_timer

Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux