于 2018年3月27日 GMT+08:00 上午6:22:58, Rob Herring <r...@kernel.org> 写到: >On Thu, Mar 22, 2018 at 02:08:43PM +0800, Icenowy Zheng wrote: >> >> >> 于 2018年3月22日 GMT+08:00 上午1:13:42, "Jernej Škrabec" ><jernej.skra...@siol.net> 写到: >> >Hi all, >> > >> >Dne sreda, 21. marec 2018 ob 03:18:13 CET je Icenowy Zheng >napisal(a): >> >> 于 2018年3月21日 GMT+08:00 上午2:46:46, Maxime Ripard >> ><maxime.rip...@bootlin.com> >> >写到: >> >> >On Sat, Mar 17, 2018 at 01:53:49AM +0800, Icenowy Zheng wrote: >> >> >> All the sub-blocks of Allwinner A64 DE2 needs the SRAM C on A64 >> >SoC >> >> > >> >> >to >> >> > >> >> >> be claimed, otherwise the whole DE2 space is inaccessible. >> >> >> >> >> >> Add a device tree binding of the DE2 part as a sub-bus. >> >> > >> >> >Where did you get the info that it was a bus? >> >> >> >> There's no direct evidence, just some guess. >> >> >> >> The DE2 is a whole part that is just allocated a memory >> >> space at the user manual, and the SRAM controls the >> >> access to all modules in the DE2. >> >> >> >> So it might be a bus. >> >> >> >> Implement it as a bus is a clear representation on A64. >> > >> >Since there is already syscon for same mmio region, we migh as well >use >> >it >> >when loading ccu-sun8i-de2 driver on A64. >> > >> >Other options, like SRAM driver or bus driver, might better >represent >> >HW, but >> >> I think the device tree should properly represent the HW, >> it's a basic requirment. >> >> >then we would have two DT nodes covering same mmio region, which I >> >think is >> >not really acceptable. >> >> It's acceptable, and DE2 is not the only user of SRAM controller so >far. > >No, it's not acceptable. Don't create overlapping mmio regions in DT.
Then should the SRAM controller driver be configured to take the syscon? > >> >> VE will also need a SRAM region to be claimed. >> >> > >> >Any suggestions? >> > >> >BTW, H6 has same design in this regard. >> > >> >Best regards, >> >Jernej >> -- >> To unsubscribe from this list: send the line "unsubscribe devicetree" >in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > >_______________________________________________ >linux-arm-kernel mailing list >linux-arm-ker...@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel