> Matthijs van Duin <matthijsvanduin@xxxxxxxxx> wrote: > 44400500 target 11 vcp > 44800100 target 18 vlynq ? scrap these guesses: I don't think Netra has a vcp module, and I had only filled in vlynq based on it being the only remaining target NIU. Once the memory ranges for the targets have been determined they should be easy to identify conclusively. On 18 March 2015 at 17:54, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > Oh there's a gap here and it goes all the way to 2400.. Is there > a gap on am335x too? There are indeed. See my work-in-progress spreadsheet on its L3 interconnect: http://goo.gl/miyCQw As with the memory map, there are some "ghost" modules which I'm reasonably sure don't exist, even though they have a target NIU and clkctrl registers. I haven't yet checked which initiator the sole bandwidth regulator on subarctic is attached to. Plausible options are SGX, the LCD controller, or one of the EDMA TCs. I also just noticed how *big* its statistics collectors are. o.O For comparison, the ones on netra and centaurus are 0x200 (statcoll 0 and 3) or 0x400 (statcoll 1 and 2). >> 2. Disable all L3 Target NIUs. You will temporarily lose access to all >> peripherals, OCMC ram, and on subarctic also DDR memory (I think on >> devices with a DMM you'd retain access to DDR memory). Note that the >> service network itself isn't considered an L3 target. > > Hmm well we could that in the kernel using the SRAM code as long as > it does not reset the devices. If you run with MMU disabled then you'd have to run out of the 64K internal SRAM, and catch data aborts since all writes will be non-posted. With MMU enabled, locking code and MMU translation tables into the (much larger) L2 cache makes more sense. I *think* disabling the NIU only blocks access to the module and doesn't affect the module operationally. I'd be inclined to put external RAM into self-refresh during the procedure just to be sure, in case disabling NIUs results in clock gating (which would otherwise be hard to notice). > OK the driver would have to be enabled with interrupts while scanning. Polling makes more sense, especially since nothing else can be going on at the same time anyway. I still think a separate tool that scrapes as much data as possible from the target and pours it into DT form makes more sense than doing it in a kernel driver, especially since discovered targets may often still need manual identification. Also, probing discovered targets requires you enable the clock(s) they need and if necessary release local reset. Auto-discovery of these associations may also be possible, but probably would become a rather lenghy procedure. A separate tool can also leave a record of what it's doing in SRAM and enable the watchdog to be able to recover from probes that lock up the system (and log a warning about them). Also, on HS devices, it would surprise me if you're allowed to access any interconnect registers at all. Matthijs -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
