[PATCH 5/8] i2c: omap: introduce and use OMAP_I2C_IP_VERSION_3

[Felipe Balbi]

Hi,

On Mon, Oct 22, 2012 at 03:05:20PM +0200, Benoit Cousson wrote:
> 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.

aha.. I see. What a hack!

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

Tell me about it... in that case, $SUBJECT can be dropped silently, I
will respin next patch so that it checks for VERSION_2 instead of
VERSION_3.

cheers.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121022/fb9efdd5/attachment.sig>