Re: PXA270 I2C register mapping

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)