On Mon, Apr 26, 2010 at 20:24:53, Chemparathy, Cyril wrote: > Hi Sekhar, > > [...] > >> +/* > >> + * TNETV107X platforms do not use the static mappings from Davinci > >> + * IO_PHYS/IO_VIRT. This SOC's interesting MMRs are at different > >> addresses, > >> + * and changing IO_PHYS would break away from existing Davinci SOCs. > >> + * > >> + * The primary impact of the current model is that IO_ADDRESS() is not to > >> be > >> + * used to map registers on TNETV107X. With the exception of early boot > >> code > >> + * in tnetv107x_init() (where fixed maps are necessary), all other pieces > >> of > >> + * code absolutely _must_ use ioremap(). > >> + * > >> + * 1. The first section in here is specifically for edma, even > >> through the > >> + * edma driver code properly ioremap()s its register space. This is > >> + * because the edma MMRs on tnetv107x unfortunately fall within the > >> + * davinci IO_PHYS - (IO_PHYS + IO_SIZE) range, and therefore the edma > >> + * driver's ioremap() gets subverted by davinci_ioremap(). Yikes! > > > > I had pointed this earlier, but don't remember a follow-up discussion. > > > > Why not just redefine IO_PHYS for this SoC? > > I thought I'd responded in [1].
Ah right. I guess I missed it. > But this does bring up a good point. Now that ioremap interception no > longer remaps per IO_PHYS/IO_VIRT, the edma ioremap() should operate > correctly even without this special iotable entry. I will get rid of > this in the next rev. Thanks! The hack was quite unintuitive to me, so glad to see its back. Regards, Sekhar _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
