From: b-cousson@ti•com (Benoit Cousson)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 5/8] i2c: omap: introduce and use OMAP_I2C_IP_VERSION_3
Date: Mon, 22 Oct 2012 15:05:20 +0200 [thread overview]
Message-ID: <50854490.4060306@ti.com> (raw)
In-Reply-To: <20121022122853.GW14033@arwen.pp.htv.fi>
On 10/22/2012 02:28 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Oct 22, 2012 at 02:27:20PM +0200, Benoit Cousson wrote:
>> Hi Felipe,
>>
>> On 10/22/2012 11:46 AM, Felipe Balbi wrote:
>>> on OMAP4+ we want to read IRQSTATUS_RAW register,
>>> instead of IRQSTATUS. The reason being that IRQSTATUS
>>> will only contain the bits which were enabled on
>>> IRQENABLE_SET and that will break when we need to
>>> poll for a certain bit which wasn't enabled as an
>>> IRQ source.
>>>
>>> One such case is after we finish converting to
>>> deferred stop bit, we will have to poll for ARDY
>>> bit before returning control for the client driver
>>> in order to prevent us from trying to start a
>>> transfer on a bus which is already busy.
>>>
>>> Note, however, that omap-i2c.c needs a big rework
>>> on register definition and register access. Such
>>> work will be done in a separate series of patches.
>>
>> Do you need OMAP_I2C_IP_VERSION_3 for OMAP4?
>>
>> OMAP_I2C_IP_VERSION_2 was already introduced to detect OMAP3630 vs
>> omap4430 because they were sharing the same IP version..
>>
>> /* I2C controller revisions present on specific hardware */
>> #define OMAP_I2C_REV_ON_2430 0x36
>> #define OMAP_I2C_REV_ON_3430_3530 0x3C
>> #define OMAP_I2C_REV_ON_3630_4430 0x40
>>
>> So in theory you should not need an extra version.
>
> are you sure that's how they're used ? Looking at the code where we
> choose reg_map_ip_v1 and reg_map_ip_v2:
>
> 1120 if (dev->dtrev == OMAP_I2C_IP_VERSION_2)
> 1121 dev->regs = (u8 *)reg_map_ip_v2;
> 1122 else
> 1123 dev->regs = (u8 *)reg_map_ip_v1;
>
> And looking at reg_map_ip_v1:
>
> 218 static const u8 reg_map_ip_v1[] = {
> 219 [OMAP_I2C_REV_REG] = 0x00,
> 220 [OMAP_I2C_IE_REG] = 0x01,
> 221 [OMAP_I2C_STAT_REG] = 0x02,
> 222 [OMAP_I2C_IV_REG] = 0x03,
> 223 [OMAP_I2C_WE_REG] = 0x03,
> 224 [OMAP_I2C_SYSS_REG] = 0x04,
> 225 [OMAP_I2C_BUF_REG] = 0x05,
> 226 [OMAP_I2C_CNT_REG] = 0x06,
> 227 [OMAP_I2C_DATA_REG] = 0x07,
> 228 [OMAP_I2C_SYSC_REG] = 0x08,
> 229 [OMAP_I2C_CON_REG] = 0x09,
> 230 [OMAP_I2C_OA_REG] = 0x0a,
> 231 [OMAP_I2C_SA_REG] = 0x0b,
> 232 [OMAP_I2C_PSC_REG] = 0x0c,
> 233 [OMAP_I2C_SCLL_REG] = 0x0d,
> 234 [OMAP_I2C_SCLH_REG] = 0x0e,
> 235 [OMAP_I2C_SYSTEST_REG] = 0x0f,
> 236 [OMAP_I2C_BUFSTAT_REG] = 0x10,
> 237 };
>
> that's really not the register map on OMAP3. That only looks valid for
> OMAP1.
No that should be valid as well for OMAP2&3 thanks to the
OMAP_I2C_FLAG_BUS_SHIFT_2.
It was introduced during DT adaptation:
#ifdef CONFIG_OF
static struct omap_i2c_bus_platform_data omap3_pdata = {
.rev = OMAP_I2C_IP_VERSION_1,
.flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
OMAP_I2C_FLAG_BUS_SHIFT_2,
};
static struct omap_i2c_bus_platform_data omap4_pdata = {
.rev = OMAP_I2C_IP_VERSION_2,
};
static const struct of_device_id omap_i2c_of_match[] = {
{
.compatible = "ti,omap4-i2c",
.data = &omap4_pdata,
},
{
.compatible = "ti,omap3-i2c",
.data = &omap3_pdata,
},
{ },
};
MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
#endif
> -ECONFUSED
Well, it is confusing...
Benoit
next prev parent reply other threads:[~2012-10-22 13:05 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-22 9:46 [PATCH 0/8] I2C patches for v3.8 merge window Felipe Balbi
2012-10-22 9:46 ` [PATCH 1/8] i2c: omap: no need to access platform_device Felipe Balbi
2012-10-22 9:46 ` [PATCH 2/8] i2c: omap: reorder exit path of omap_i2c_xfer_msg() Felipe Balbi
2012-10-25 11:40 ` Shubhrajyoti Datta
2012-10-25 12:01 ` Felipe Balbi
2012-10-22 9:46 ` [PATCH 3/8] i2c: omap: fix error checking Felipe Balbi
2012-10-24 14:41 ` Michael Trimarchi
2012-10-25 10:10 ` Felipe Balbi
2012-10-25 10:33 ` Michael Trimarchi
2012-10-25 10:48 ` Felipe Balbi
2012-10-22 9:46 ` [PATCH 4/8] i2c: omap: also complete() when stat becomes zero Felipe Balbi
2012-10-22 9:46 ` [PATCH 5/8] i2c: omap: introduce and use OMAP_I2C_IP_VERSION_3 Felipe Balbi
2012-10-22 12:27 ` Benoit Cousson
2012-10-22 12:28 ` Felipe Balbi
2012-10-22 13:05 ` Benoit Cousson [this message]
2012-10-22 13:09 ` Felipe Balbi
2012-10-22 13:18 ` [PATCH v2 5/8] i2c: omap: in case of VERSION_2 read IRQSTATUS_RAW but write to IRQSTATUS Felipe Balbi
2012-10-22 9:46 ` [PATCH 6/8] i2c: omap: wait for transfer completion before sending STP bit Felipe Balbi
2012-10-22 9:46 ` [PATCH 7/8] i2c: add 'transferred' field to struct i2c_msg Felipe Balbi
2012-10-25 12:57 ` Jean Delvare
2012-10-25 13:14 ` Russell King - ARM Linux
2012-10-25 13:42 ` Jean Delvare
2012-10-25 13:46 ` Russell King - ARM Linux
2012-10-25 13:56 ` Jean Delvare
2012-10-25 14:18 ` Russell King - ARM Linux
2012-10-27 14:32 ` Jean Delvare
2012-10-27 16:40 ` Al Viro
2012-10-27 17:02 ` Al Viro
2012-10-27 17:10 ` Al Viro
2012-10-27 19:03 ` Jean Delvare
2012-10-27 17:25 ` Russell King - ARM Linux
2012-10-22 9:46 ` [PATCH 8/8] i2c: omap: implement handling for 'transferred' bytes Felipe Balbi
2012-10-22 13:30 ` [PATCH 0/8] I2C patches for v3.8 merge window Felipe Balbi
2012-10-22 14:06 ` Shubhrajyoti Datta
2012-10-22 14:06 ` Felipe Balbi
2012-10-22 15:02 ` Shubhrajyoti
2012-11-14 16:58 ` Wolfram Sang
2012-10-25 12:25 ` [PATCH v2 0/7] " Felipe Balbi
2012-10-25 12:25 ` [PATCH v2 1/7] i2c: omap: no need to access platform_device Felipe Balbi
2012-10-25 12:41 ` Santosh Shilimkar
2012-10-25 12:25 ` [PATCH v2 2/7] i2c: omap: reorder exit path of omap_i2c_xfer_msg() Felipe Balbi
2012-10-25 12:42 ` Santosh Shilimkar
2012-10-25 12:40 ` Felipe Balbi
2012-10-25 12:53 ` Lothar Waßmann
2012-10-25 12:25 ` [PATCH v2 3/7] i2c: omap: also complete() when stat becomes zero Felipe Balbi
2012-10-25 12:43 ` Santosh Shilimkar
2012-10-25 12:39 ` Felipe Balbi
2012-10-25 12:25 ` [PATCH v2 4/7] i2c: omap: in case of VERSION_2 read IRQSTATUS_RAW but write to IRQSTATUS Felipe Balbi
2012-10-25 12:53 ` Santosh Shilimkar
2012-10-25 12:52 ` Felipe Balbi
2012-10-25 13:06 ` Santosh Shilimkar
2012-10-25 12:25 ` [PATCH v2 5/7] i2c: omap: wait for transfer completion before sending STP bit Felipe Balbi
2012-10-25 12:32 ` Felipe Balbi
2012-10-25 12:34 ` [PATCH v3 " Felipe Balbi
2012-10-25 13:01 ` [PATCH v2 " Santosh Shilimkar
2012-10-25 14:15 ` Felipe Balbi
2012-10-25 12:25 ` [PATCH v2 6/7] i2c: add 'transferred' field to struct i2c_msg Felipe Balbi
2012-10-25 12:25 ` [PATCH v2 7/7] i2c: omap: implement handling for 'transferred' bytes Felipe Balbi
2012-10-27 18:55 ` Paul Walmsley
2012-11-05 8:10 ` [PATCH v2 0/7] I2C patches for v3.8 merge window Felipe Balbi
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=50854490.4060306@ti.com \
--to=b-cousson@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox