On Thu, Apr 21, 2016 at 12:20 PM, Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> wrote: > From: Bjorn Andersson <bjorn.andersson@xxxxxxxxxxxxxx> > > The document defines the binding for a component that loads firmware for > and boots the Qualcomm WCNSS core. > > Signed-off-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxxxxxx> > Signed-off-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> > --- > > Rob, > > I got your Ack on v2, but I would like to make a small amendment before merging > this. > > > As we discussed related to the WiFi binding I should reference the mmio > registers by a phandle to a DT node specifying the two necessary register > blocks (ccu & dxe). > > These two register blocks are part of the riva/pronto (the two major versions) > subsystem, that also contains the "pmu" register block, which is what I access > here. > > Further more, the ccu block contains valuable information for debugging > purposes that the implementation of this binding would find useful. > > > I would therefor like to double this node (in the dts) as both the > riva/pronto-pil and the target for the mmio phandle reference from the WiFi > node. > > This works fine, but unless using reg-names for defining the order or the regs > I get a messy ordering dependency between the two bindings. I do not know which > of the other 7-8 register blocks we will add for debugging, but with the below > change I can keep them in block order regardless of the order we implement them > in. You should know based on the compatible string what the number and order of register ranges are. reg is not something we want evolving over time. > So, can I update the "reg" and add "reg-names" as below to the binding and > depend on reg-names for the ordering of reg? Or should I speculatively add all > ranges I know of to keep the order sane? I'm okay with using this for convenience of the client not having to care which compatible the block is, but the above should still be met. Also, you could add a cell which is the index to the register range you need. Rob -- 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
