Re: [PATCH 0/4] Qualcomm Shared Memory State Machines
On Tue 08 Sep 05:20 PDT 2015, Linus Walleij wrote: > On Thu, Aug 27, 2015 at 7:37 PM, Bjorn Andersson > wrote: > > Let's discuss this a bit, looping in Mark Brown. > > > As some of these states on some platforms are passed as physical signals > > instead, the two drivers are modelled as gpio- and interrupt-controllers - > > providing a nice abstraction both in device tree sense and Linux > > implementation > > sense. > > I have unfortunately repeatedly encountered an argument of the type > "GPIO has nice infrastructure so let's call X 'a kind of GPIO' so > we can use that nice infrastructure". > I guess that's what you get for maintaining a subsystem with "general purpose" in the name ;) Sorry for adding one more item to your list. > I'm not pleased with something that is not really general purpose > input/output being called GPIO. It fits badly with the GPIO subsystem > when we support things like open drain and cross-mappings to > the pin control subsystem that will never be applicable to these > new users. It's more like "special purpose input/output" or > something. > Right, this doesn't match at all with the electrical properties. What it does give is the nice symmetry with the irq bits and existing apis for poking and peeking. > This happened with syscon LEDs for example, and was the reason > I implemented syscon-leds. The original proposal was to say the LEDs > register was "a kind of GPIO" on top of regmap and then use gpio-leds > on top of that. Instead I insisted it was a syscon/regmap and the > LEDs go directly to that, bypassing one layer of abstraction. > > I also imagine creating syscon-keys.c for input from arbitrary keys > in a syscon register actually. Just didn't get around to that yet. > The difference with those two cases is that the pieces didn't fit together, so we tried to use the gpio framework as an adaptor to make it work. I picked the gpio framework because: * the DT nicely represent the structure of the memory and relationship between the individual components. * the implementation needs to be able to set and clear individual bits, as well as register handlers for state changes. * I'm told the SMP2P entries are on some platform (I've never seen) actual gpio lines. > I also see some of the stuff GPIO does out-of-the-box being useful, > for example in MFD: some of these are interrupt controllers and > basically duplicate the kind of code I have in gpiolib for > GPIOLIB_IRQCHIP. > I do learn about new helper functions every time I touch these things. > So we need to figure out what is really needed. > > While sparsely documented: what about regmap (maybe in the > form of syscon) and drivers/base/regmap/regmap-irq.c for the > interrupt handling? > regmap-irq looks good and reasonable. The problem is that for SMSM I need custom masking operations and on SMP2P I have multiple regmaps sharing one incoming IRQ. So it doesn't look applicable for my use cases. > I cannot claim to understand regmap-irq.c, but I just intuitively > think it deserves consideration, such that drivers who need one > of these misc registers can read/write their bits with regmap > accessors and also get IRQs by way of regmap-irq. > I was expecting some push back from you, but as it was the cleanest abstraction I would come up with I gave it a shot :) I'll rewrite the outgoing part based on regmaps instead. Thanks for reviewing. Regards, Bjorn -- 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
Re: [PATCH 0/4] Qualcomm Shared Memory State Machines
On Tue, Sep 08, 2015 at 02:20:14PM +0200, Linus Walleij wrote: > On Thu, Aug 27, 2015 at 7:37 PM, Bjorn Andersson > wrote: > Let's discuss this a bit, looping in Mark Brown. Please don't send upstream discussions ot my work address. > While sparsely documented: what about regmap (maybe in the > form of syscon) and drivers/base/regmap/regmap-irq.c for the > interrupt handling? > I cannot claim to understand regmap-irq.c, but I just intuitively > think it deserves consideration, such that drivers who need one > of these misc registers can read/write their bits with regmap > accessors and also get IRQs by way of regmap-irq. Well, all it's doing is exporting a simple register based interrupt controller based on regmap. There's not a lot to document. If you're using it with a system controller you'd probably want to implement support for handling interrupts directly in the primary handler rather than using a threaded handler. Alternatively if there's no cache or no overlap between interrupt registers and other registers then just using the genirq MMIO code should do the trick. signature.asc Description: Digital signature
Re: [PATCH 0/4] Qualcomm Shared Memory State Machines
On Thu, Aug 27, 2015 at 7:37 PM, Bjorn Andersson wrote: Let's discuss this a bit, looping in Mark Brown. > As some of these states on some platforms are passed as physical signals > instead, the two drivers are modelled as gpio- and interrupt-controllers - > providing a nice abstraction both in device tree sense and Linux > implementation > sense. I have unfortunately repeatedly encountered an argument of the type "GPIO has nice infrastructure so let's call X 'a kind of GPIO' so we can use that nice infrastructure". I'm not pleased with something that is not really general purpose input/output being called GPIO. It fits badly with the GPIO subsystem when we support things like open drain and cross-mappings to the pin control subsystem that will never be applicable to these new users. It's more like "special purpose input/output" or something. This happened with syscon LEDs for example, and was the reason I implemented syscon-leds. The original proposal was to say the LEDs register was "a kind of GPIO" on top of regmap and then use gpio-leds on top of that. Instead I insisted it was a syscon/regmap and the LEDs go directly to that, bypassing one layer of abstraction. I also imagine creating syscon-keys.c for input from arbitrary keys in a syscon register actually. Just didn't get around to that yet. I also see some of the stuff GPIO does out-of-the-box being useful, for example in MFD: some of these are interrupt controllers and basically duplicate the kind of code I have in gpiolib for GPIOLIB_IRQCHIP. So we need to figure out what is really needed. While sparsely documented: what about regmap (maybe in the form of syscon) and drivers/base/regmap/regmap-irq.c for the interrupt handling? I cannot claim to understand regmap-irq.c, but I just intuitively think it deserves consideration, such that drivers who need one of these misc registers can read/write their bits with regmap accessors and also get IRQs by way of regmap-irq. Yours, Linus Walleij -- 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
[PATCH 0/4] Qualcomm Shared Memory State Machines
This series implements the two different mechanisms for propagating single bit state information, used on the various Qualcomm platforms. The system was traditionally used by the modem and application processor to convey information about boot progress, power states, error handling and so on. This was implemented as SMSM, with status bits representing a single local state. As the complexity of the SoC grew the state bits array grew and the need for targeting specific state information at specific remote processors appeared. SMP2P solves this by having separate shared memory regions per processor-pair. This state information is e.g. used to convey progress and status of remote firmware loading. Individual bits maps to various stages of the boot and error states. As some of these states on some platforms are passed as physical signals instead, the two drivers are modelled as gpio- and interrupt-controllers - providing a nice abstraction both in device tree sense and Linux implementation sense. Bjorn Andersson (4): dt-binding: gpio: Add Qualcomm SMSM device tree documentation gpio: qcom-smsm: Add driver for Qualcomm SMSM dt-binding: gpio: Introduce qcom,smp2p binding documentation gpio: qcom-smp2p: Qualcomm Shared Memory Point to Point .../devicetree/bindings/gpio/qcom,smp2p.txt| 112 .../devicetree/bindings/gpio/qcom,smsm.txt | 114 drivers/gpio/Kconfig | 15 + drivers/gpio/Makefile | 2 + drivers/gpio/gpio-qcom-smp2p.c | 601 drivers/gpio/gpio-qcom-smsm.c | 631 + 6 files changed, 1475 insertions(+) create mode 100644 Documentation/devicetree/bindings/gpio/qcom,smp2p.txt create mode 100644 Documentation/devicetree/bindings/gpio/qcom,smsm.txt create mode 100644 drivers/gpio/gpio-qcom-smp2p.c create mode 100644 drivers/gpio/gpio-qcom-smsm.c -- 1.8.2.2 -- 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
