[PATCH v2.1 1/9] dt-binding: remoteproc: Introduce Qualcomm WCNSS loader binding
Bjorn Andersson
bjorn.andersson at linaro.org
Fri Apr 22 09:54:31 PDT 2016
On Fri 22 Apr 09:22 PDT 2016, Rob Herring wrote:
> On Thu, Apr 21, 2016 at 12:20 PM, Bjorn Andersson
> <bjorn.andersson at linaro.org> wrote:
> > From: Bjorn Andersson <bjorn.andersson at sonymobile.com>
> >
> > 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 at sonymobile.com>
> > Signed-off-by: Bjorn Andersson <bjorn.andersson at linaro.org>
> > ---
> >
> > 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.
>
At best I can make an educated guess based on some downstream debug code
on what regs we do have. But I've already found two of the ranges being
incorrect.
> > 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.
>
Okay, I will throw in the 3 I know for now, saying those are required.
And then we add the debug regions as optionals after those, based on
which ones we need. Hopefully I haven't missed any required regions...
> Also, you could add a cell which is the index to the register range you need.
>
I'm afraid I feel that is just reimplementing reg-names, for the sake of
not using reg-names.
Thanks for your answer, I'll spin the two bindings and send them about
again.
Regards,
Bjorn
More information about the linux-arm-kernel
mailing list