Re: [PATCH 2/4] OMAP3 I2C document why cpu type and not peripheral unit ID used to probe

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

 



On 03/03/2011 09:12 PM, Somebody in the thread at some point said:

Hi -

Thanks for your comments.

The issue is that this revision field is not really documented in OMAP4
TRM, so you should not rely on it. Moreover, as you already noticed, the
revision number is not even accurate. OMAP3 and 4 are using a different
programming model but this is not reflected in this field.

OK.

Since that issue is quite common in many OMAP IPs, we introduced a SW
field in hwmod_class that should reflect the change in IP programming
model. For the moment it is a simple integer that we increment each time
there is change in a programming model that will impact the driver.

You can check how it was done for the timer for example:

Alright. In I2C case the path is hwmod class -> platform data though since hwmod content directly is not used in the driver, but platform data is.

+
if (cpu_is_omap44xx())
dev->regs = (u8 *) omap4_reg_map;

OK, this is not part of your patch, but any call to cpu_is are forbidden
from the driver. As soon as you have the revision field from hwmod you
can get rid of all that code.

Well, as you point out they are not forbidden enough since I was just working with what was already there.

However this hwmod scheme will cover it all AFAICS, so I will extend the patches to nuke all cpu_is... from the driver.

-Andy
--
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