>
>> There is some divergance in respect to the memory map that is non-trivial that
>> I'm not sure how to handle, since it totally hoses the common fsl_rio.c structures.
>> I think I want to create a new set that's p2020 specific, but has potential to be
>> shared with the other QorIQ series, so dumping the pseries-specific code into
>> platforms/pseries seems like a reasonable way to go. Thoughts?
>
> The dual-port RIO is very common on QorIQ chips. I won't suggest you add P2020 specific memory map file. The two port memory map should also be compatible with one port driver.
>
Should be, but isn't. For the most part the new registers introduced
match up with the pad present in the previous processors, but not for
the atmu registers. They are wildly inconsistent, and I don't see a
way to make them compatible.
# The current implementation
struct rio_atmu_regs {
u32 rowtar;
u32 rowtear;
u32 rowbar;
u32 pad2;
u32 rowar;
u32 pad3[3];
};
# The QorIQ p2020 register set.
struct rio_atmu_outb_window_regs {
u32 rowtar0; /* Outbound window translation address register 0 *
u32 rowtear0; /* Outbound window ext. address register 0 */
u32 pad; /* There is no rowbar0. Believe it. */
u32 rowar0; /* Outbound window attribute register 1 */
u32 rowtar1; /* Outbound window translation address register 1 *
u32 rowtear1; /* Outbound window ext. translation address registe
u32 rowbar1; /* Outbound window base address register 1 */
u32 rowar1; /* Outbound window attributes register 1 */
u32 rowsr1[3]; /* Outbound window segment register 1 */
};
struct rio_atmu_inb_window_regs {
u32 iwtar; /* Inbound window translation address register. */
u32 iwbar; /* Inbound window base address register. */
u32 iwar; /* Ibound window attribute register. */
};
struct rio_atmu_regs {
rio_atmu_outb_window_regs outb_window[8]; /* window 1-8, upcounting
rio atmu_inb_window_regs inb_window[4] /* window 4-1, downcounting
};
> -Leo
>
>