On 10/22/2012 02:28 PM, Felipe Balbi wrote:

Hi,

On Mon, Oct 22, 2012 at 02:27:20PM +0200, Benoit Cousson wrote:

quoted

Hi Felipe,

On 10/22/2012 11:46 AM, Felipe Balbi wrote:

quoted

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