Re: [PATCH 1/4] dt-binding: gpio: Add Qualcomm SMSM device tree documentation
From: Bjorn Andersson
Date: Tue Sep 01 2015 - 01:26:51 EST
On Mon 31 Aug 08:43 PDT 2015, Rob Herring wrote:
> On Thu, Aug 27, 2015 at 12:37 PM, Bjorn Andersson
> <bjorn.andersson@xxxxxxxxxxxxxx> wrote:
> > This documents a device tree binding for exposing the Qualcomm Shared
> > Memory State Machine as a set of gpio- and interrupt-controllers.
> >
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxxxxxx>
> > ---
> > .../devicetree/bindings/gpio/qcom,smsm.txt | 114 +++++++++++++++++++++
>
> > drivers/gpio/Kconfig | 8 ++
> > drivers/gpio/Makefile | 1 +
>
> Presumably this goes in patch 2.
>
Of course, my git-fu let me down.
> > 3 files changed, 123 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/gpio/qcom,smsm.txt
> >
> > diff --git a/Documentation/devicetree/bindings/gpio/qcom,smsm.txt b/Documentation/devicetree/bindings/gpio/qcom,smsm.txt
> > new file mode 100644
> > index 000000000000..06201ba76594
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/gpio/qcom,smsm.txt
> > @@ -0,0 +1,114 @@
> > +Qualcomm Shared Memory State Machine
> > +
> > +The Shared Memory State Machine facilitates broadcasting of single bit state
> > +information between the processors in a Qualcomm SoC. Each processor is
> > +assigned 32 bits of state that can be modified. A processor can through a
> > +matrix of bitmaps signal subscription of notifications upon changes to a
> > +certain bit owned by a certain remote processor.
>
> Are all the bits s/w driven, but somehow fixed in their functional definition?
>
There's a wide range of systems implementing this, but I think it's all
software. The definition of the individual bits used to be defined by
one large enum, but it looks like Qualcomm ran out of bits and started
to re-use them.
But the functions are always well defined for a given platform.
> > +This document defines the binding for a driver that implements and exposes this
> > +a GPIO controller and a set of interrupt controllers.
>
> I imagine Linus will have thoughts about that.
>
Looking forward to hearing his comments :)
I have not been able to find any other suitable framework to expose this
functionality with and I am hoping to not be forced to create a new one
as this one fits the purpose well.
> > +
> > +- compatible:
> > + Usage: required
> > + Value type: <string>
> > + Definition: must be one of:
> > + "qcom,smsm"
>
> There are not versions of the h/w?
>
There are basically 2 versions; the original version comprised the
application cpu and the modem cpu, sometime around 2008-2009 this was
replaced with something called "N-way SMSM" - i.e. this implementation.
The only change since then is in the number of entries and number of
hosts - which we can determine in runtime if it's not compatible with
the original sizes.
So I have not been able to find any reasons to be more specific.
Thanks for taking a look.
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/