On Thu, May 26, 2016 at 11:33:23AM -0400, Rich Felker wrote: > On Thu, May 26, 2016 at 11:38:29AM +0100, Mark Rutland wrote: > > On Wed, May 25, 2016 at 07:04:08PM -0400, Rich Felker wrote: > > > On Wed, May 25, 2016 at 11:22:15AM +0100, Mark Rutland wrote: > > > > * How must the value be written? > > > > - Which endianness? > > > > > > CPU native. > > > > Ok. I take it that a CPU's endianness cannot be switched onthe fly, > > then? Or does the hardware backing the release-addr register handle > > arbitrary endianness dynamically? > > No, it's not switched on the fly. > > > If you want to reuse the same HW block across configurations where CPU > > endianness differs, it may make sense to define an endianness > > regardless, to simplify integration concerns. > > The existing cpus are all big-endian, but I believe at one point there > was talk that it's easy to get a little-endian version if you want. In > any case the value is to be read by the cpu, so cpu endianness (i.e. > no endianness, just a value) is the only thing that makes sense to > specify. Adding a fixed endian spec independent of cpu endianness just > complicates both hardware and kernel implementation and its only > benefit seems to be supporting runtime-switchable chips where the > entry-point code has to select the endianness to match the rest of the > kernel. Sure. If endianness isn't runtime switchable, and there is no near-term plan to add that, then my concerns do not apply. [...] > > If you do /memreserve/ the region rather than carving it out of memory > > nodes, you will also need to define semantics for memreserve. Typically > > memreserve meaans that the OS should not perform any stores to the > > region, but is permitted to map it with some architecture-specific > > cacheable attributes. > > My interpretation of memreserve is just that it marks memory ranges > that the kernel cannot use for allocatable memory for its own > purposes, despite otherwise possibly lying in the range of a "memory" > node. I would not interpret it as excluding accesses by drivers that > were told to use specific addresses in the "reserved" range as part of > their DT bindings. Yes, this is strictly more correct than my wording. Given the lack of MMU or cache configration beynd on/off, it doesn't sound like there are any arch-specific memory attribute rules to document. [...] > > My questions about SMP are largely orthogonal to DT; I simply have > > experience in dealing with that for arm64, and am aware of some of the > > pain points that were not immediately obvious. > > OK, thanks for clarifying that. This is actually really helpful > feedback to have but I wasn't sure if you wanted me to consider it > part of what needs to be done for DT binding or for consideration in > designing and documenting the SMP architecture. Sorry for that; in retrospect I probably should have sent the boot protocol comments as a separate reply. [...] > OK. I'll strip it down to just the parts that are relevant for non-SMP > and submit the patch adding SMP bindings along with the SMP kernel > patches. That sounds good to me. Thanks, Mark, -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
