Re: PXA270 I2C register mapping

Thanks for the answer,
I'm absolutely sure.
I just printed the addresses of the registers being accessed and there
is no 1680 offset,
so my guess is that the developer's manual has a bug (there is no
reserved space at 0x4030_0000-0x4030_1676).

Thanks anyway, it was just to see if I missed something.

Shai

On May 27, 12:13 pm, "Michel Verhagen (eMVP)" <mic...@xxxxxxxxxx>
wrote:
Are you absolutely sure BULVERDE_BASE_REG_PA_I2C is not defined as
0x40301680 or that there's no addition to RegPA.QuadPart before it's
being used?

pI2CRegs =(volatile XLLP_I2C_T *) MmMapIoSpace(RegPA,
sizeof(XLLP_I2C_T),FALSE);

This will map the struct over BULVERDE_BASE_REG_PA_I2C, so if the
registers are really at offset 0x1680 from BULVERDE_BASE_REG_PA_I2C than
it can't work correctly because the struct starts at IBMR and doesn't
account for 0x1680 bytes of space.

Good luck,

Michel Verhagen, eMVP
Check out my blog:http://GuruCE.com/blog

  GuruCE Ltd.
  Microsoft Embedded Partner
 http://GuruCE.com
  Consultancy, training and development services.shai wrote:
Anyone knows?

Thanks

On May 25, 4:49 pm, shai <sha...@xxxxxxxxx> wrote:
Hi,
I wanted to ask if someone can explain to me how the following mapping
works without a problem:

In the spec, the I2C registers are specified as:
0x4030_1680 IBMR I2C Bus Monitor register 9-30
0x4030_1684 — reserved —
0x4030_1688 IDBR I2C Data Buffer register 9-29
0x4030_168C — reserved —
0x4030_1690 ICR I2C Control register 9-23
0x4030_1694 — reserved —
0x4030_1698 ISR I2C Status register 9-26
0x4030_169C — reserved —
0x4030_16A0 ISAR I2C Slave Address register 9-28

When wanting to map them, the following code is used:

RegPA.QuadPart = BULVERDE_BASE_REG_PA_I2C;
pI2CRegs =(volatile XLLP_I2C_T *) MmMapIoSpace(RegPA,
sizeof(XLLP_I2C_T),FALSE);

when BULVERDE_BASE_REG_PA_I2C is 0x40300000.
the struct XLLP_I2C_T is defined as:
typedef struct
{
                XLLP_VUINT32_T IBMR;             /* Bus monitor
register */
        XLLP_UINT32_T RESERVED1;        /* addr. offset 0x84-0x88 */
        XLLP_VUINT32_T IDBR;    /* Data buffer Register */
        XLLP_UINT32_T RESERVED2;        /* addr. offset 0x8C-0x90*/
        XLLP_VUINT32_T ICR;     /* Global Control Register */
        XLLP_UINT32_T RESERVED3;        /* addr. offset 0x94-0x98 */
        XLLP_VUINT32_T ISR;     /* Status Register*/
                XLLP_UINT32_T RESERVED4;        /* addr. offset 0x9C-0xA0 */
        XLLP_VUINT32_T ISAR;    /* Slave address register */

} XLLP_I2C_T, *P_XLLP_I2C_T;

And everything works fine and nice.

My question is ->
Where in the code I posted does the systm take into account the 0x1680
offset between BULVERDE_BASE_REG_PA_I2C and the actual starting
address of the I2C registers?

Thanks in advance,
Shai

.

Relevant Pages

  • [PATCH 2 of 18] ipath - core driver header files
    ... ipath_debug.h contains mask values used for controlling driver debugging. ... * to communicate between kernel and user code. ... * This struct must have explict pad fields where type sizes ... * We could have a single register get/put routine, that takes a group type, ...
    (Linux-Kernel)
  • [PATCH 1 of 20] ipath - core driver header files
    ... * licenses. ... * - Redistributions in binary form must reproduce the above ... * This struct must have explict pad fields where type sizes ... * we could have a single register get/put routine, ...
    (Linux-Kernel)
  • [PATCH 1 of 18] ipath - core driver header files
    ... * licenses. ... * - Redistributions in binary form must reproduce the above ... * This struct must have explict pad fields where type sizes ... * We could have a single register get/put routine, that takes a group type, ...
    (Linux-Kernel)
  • [PATCH,RFC 2.6.14 08/15] KGDB: x86_64-specific changes
    ... +int kgdb_remove_hw_break ... +static struct pt_regs *in_interrupt_stack ... +/* Register KGDB with the die_chain so that we hook into all of the right ...
    (Linux-Kernel)
  • Re: [PATCH 2.6.19.2] r8169: support RTL8169SC/8110SC
    ... If I correctly read the patch, it should go along the 0x98000000 ... The current driver is intended to handle the whole set of PCI IDs ... Can you provide a more descriptive name for this register? ... does this new field bring something that struct net_device.dev_addr ...
    (Linux-Kernel)