From mboxrd@z Thu Jan  1 00:00:00 1970
From: andy@warmcat.com (Andy Green)
Date: Fri, 04 Mar 2011 08:25:51 +0000
Subject: [PATCH 2/4] OMAP3 I2C document why cpu type and not peripheral
	unit ID used to probe
In-Reply-To: <4D700441.50206@ti.com>
References: <20110303134744.30648.91218.stgit@otae.warmcat.com>
	<20110303135030.30648.14923.stgit@otae.warmcat.com>
	<4D700441.50206@ti.com>
Message-ID: <4D70A20F.6070508@linaro.org>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

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