All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Green <andy@warmcat.com>
To: "Cousson, Benoit" <b-cousson@ti.com>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"patches@linaro.org" <patches@linaro.org>
Subject: Re: [PATCH 2/4] OMAP3 I2C document why cpu type and not peripheral unit ID used to probe
Date: Fri, 04 Mar 2011 08:25:51 +0000	[thread overview]
Message-ID: <4D70A20F.6070508@linaro.org> (raw)
In-Reply-To: <4D700441.50206@ti.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: andy@warmcat.com (Andy Green)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/4] OMAP3 I2C document why cpu type and not peripheral unit ID used to probe
Date: Fri, 04 Mar 2011 08:25:51 +0000	[thread overview]
Message-ID: <4D70A20F.6070508@linaro.org> (raw)
In-Reply-To: <4D700441.50206@ti.com>

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

  reply	other threads:[~2011-03-04  8:25 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-03 13:50 [PATCH 0/4] OMAP 3 and 4 i2c fixes Andy Green
2011-03-03 13:50 ` Andy Green
2011-03-03 13:50 ` [PATCH 1/4] OMAP3 and 4 hwmod I2C units only allow 16 bit access Andy Green
2011-03-03 13:50   ` Andy Green
2011-03-03 17:42   ` Cousson, Benoit
2011-03-03 17:42     ` Cousson, Benoit
2011-03-03 17:56     ` Andy Green
2011-03-03 17:56       ` Andy Green
2011-03-03 20:40       ` Cousson, Benoit
2011-03-03 20:40         ` Cousson, Benoit
2011-03-04  8:33         ` Andy Green
2011-03-04  8:33           ` Andy Green
2011-03-04 10:05           ` Cousson, Benoit
2011-03-04 10:05             ` Cousson, Benoit
2011-03-04 15:20   ` Cousson, Benoit
2011-03-04 15:20     ` Cousson, Benoit
2011-03-03 13:50 ` [PATCH 2/4] OMAP3 I2C document why cpu type and not peripheral unit ID used to probe Andy Green
2011-03-03 13:50   ` Andy Green
2011-03-03 21:12   ` Cousson, Benoit
2011-03-03 21:12     ` Cousson, Benoit
2011-03-04  8:25     ` Andy Green [this message]
2011-03-04  8:25       ` Andy Green
2011-03-03 13:50 ` [PATCH 3/4] OMAP3 and 4 i2c mark extended reg enums as extended only Andy Green
2011-03-03 13:50   ` Andy Green
2011-03-03 21:33   ` Cousson, Benoit
2011-03-03 21:33     ` Cousson, Benoit
2011-03-04  8:32     ` Andy Green
2011-03-04  8:32       ` Andy Green
2011-03-04 10:05       ` Cousson, Benoit
2011-03-04 10:05         ` Cousson, Benoit
2011-03-03 13:50 ` [PATCH 4/4] OMAP3 and 4 I2C use cpu type consistently for new register availability Andy Green
2011-03-03 13:50   ` Andy Green
2011-03-03 21:45   ` Cousson, Benoit
2011-03-03 21:45     ` Cousson, Benoit
2011-03-03 21:55 ` [PATCH 0/4] OMAP 3 and 4 i2c fixes Cousson, Benoit
2011-03-03 21:55   ` Cousson, Benoit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D70A20F.6070508@linaro.org \
    --to=andy@warmcat.com \
    --cc=andy.green@linaro.org \
    --cc=b-cousson@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=patches@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.