* Re: [PATCH v2 0/5] clk: meson: Fix GXBB and GXL/GXM GP0 PLL
From: Michael Turquette @ 2017-03-27 20:02 UTC (permalink / raw)
To: sboyd, carlo, khilman
Cc: devicetree, Neil Armstrong, linux-kernel, linux-amlogic,
linux-clk, linux-arm-kernel
In-Reply-To: <1490178747-14837-1-git-send-email-narmstrong@baylibre.com>
Hi Neil,
Quoting Neil Armstrong (2017-03-22 03:32:22)
> This patchset fixes support for the Amlogic GXBB then GXL/GXM embedded GP0 PLL.
>
> The current support is done via a very generic interface where only the
> N/M/OD parameters are changed in the control registers.
>
> But unlike the Fixed PLL, this PLL is not initialized by the bootloader or
> firmware, and needs some parameters to initialize and lock correctly.
>
> This patchset also adds the GXL variant compatible string which is already
> supported by the GXL and GXM DT nodes.
>
> Changes since v1 at [1]:
> - Rebase on the Mali clocks patchset at [2]
> - also depends on v2 Audio Clocks patchset from Jerome Brunet at [3]
> - Add match table and separate tables for gxl
> - Switch to probe function to use match table data only
> - Rename unreset_for_lock to clear_reset_for_lock
Thanks for the quick changes. Applied to clk-meson, a stable branch,
which was merged into clk-next.
Best regards,
Mike
>
> [1] http://lkml.kernel.org/r/1489411604-18700-1-git-send-email-narmstrong@baylibre.com
> [2] http://lkml.kernel.org/r/1490177935-9646-1-git-send-email-narmstrong@baylibre.com
> [3] http://lkml.kernel.org/r/20170309104154.28295-1-jbrunet@baylibre.com
>
> Neil Armstrong (5):
> clk: meson: Add support for parameters for specific PLLs
> clk: meson-gxbb: Add GP0 PLL init parameters
> clk: meson-gxbb: Add GXL/GXM GP0 Variant
> clk: meson-gxbb: Expose GP0 dt-bindings clock id
> dt-bindings: clock: gxbb-clkc: Add GXL compatible variant
>
> .../bindings/clock/amlogic,gxbb-clkc.txt | 3 +-
> drivers/clk/meson/clk-pll.c | 53 +++-
> drivers/clk/meson/clkc.h | 23 ++
> drivers/clk/meson/gxbb.c | 314 +++++++++++++++++++--
> drivers/clk/meson/gxbb.h | 4 +-
> include/dt-bindings/clock/gxbb-clkc.h | 1 +
> 6 files changed, 366 insertions(+), 32 deletions(-)
>
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH RFC v4 10/10] tty: serdev: add functions to retrieve common UART settings
From: Rob Herring @ 2017-03-27 20:00 UTC (permalink / raw)
To: Stefan Wahren
Cc: Mark Rutland, David S. Miller, Greg Kroah-Hartman, Jiri Slaby,
Marcel Holtmann, Sebastian Reichel, netdev,
devicetree@vger.kernel.org, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1490621848-24828-11-git-send-email-stefan.wahren@i2se.com>
On Mon, Mar 27, 2017 at 8:37 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Currently serdev core doesn't provide functions to retrieve common
> UART settings like data bits, stop bits or parity. This patch adds
> the interface to the core and the necessary implementation for
> serdev-ttyport.
It doesn't provide them because why do you need to know? The attached
device should request the settings it needs and be done with it. Maybe
some devices can support a number of settings and you could want
negotiate the settings with the UART, though surely 8N1 is in that
list. It's rare to see something that's not 8N1 from what I've seen.
Rob
^ permalink raw reply
* Re: [PATCH v4 3/3] ARM64: dts: meson-gx: Add MALI nodes for GXBB and GXL
From: Michael Turquette @ 2017-03-27 19:53 UTC (permalink / raw)
To: Kevin Hilman, Neil Armstrong
Cc: sboyd, carlo, linux-amlogic, linux-clk, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <m237e2iirk.fsf@baylibre.com>
Quoting Kevin Hilman (2017-03-24 12:20:31)
> Neil Armstrong <narmstrong@baylibre.com> writes:
>
> > The same MALI-450 MP3 GPU is present in the GXBB and GXL SoCs.
> >
> > The node is simply added in the meson-gxbb.dtsi file.
> >
> > For GXL, since a lot is shared with the GXM that has a MALI-T820 IP, this
> > patch adds a new meson-gxl-mali.dtsi and is included in the SoC specific
> > dtsi files.
> >
> > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>
> LGTM, I can apply this when the clk driver changes are merged (feel free
> to let me know when that happens, in case I'm not paying attention.)
Applied to clk-meson, a stable branch, which has been merged into
clk-next.
Kevin, the dtsi is all yours.
Regards,
Mike
>
> <bikeshed>
> nit: This series (and previous ones) use MALI, but I believe the correct
> way is Mali. Could you standarize on that throughout the series?
> </bikeshed>
>
> Kevin
>
> > ---
> > arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 37 ++++++++++++++++++++
> > arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi | 43 ++++++++++++++++++++++++
> > arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi | 1 +
> > arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi | 1 +
> > 4 files changed, 82 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> > index 04b3324..0617a3d 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> > @@ -478,6 +478,43 @@
> > };
> > };
> >
> > +&apb {
> > + mali: gpu@c0000 {
> > + compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
> > + reg = <0x0 0xc0000 0x0 0x40000>;
> > + interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-names = "gp", "gpmmu", "pp", "pmu",
> > + "pp0", "ppmmu0", "pp1", "ppmmu1",
> > + "pp2", "ppmmu2";
> > + clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
> > + clock-names = "bus", "core";
> > +
> > + /*
> > + * Mali clocking is provided by two identical clock paths
> > + * MALI_0 and MALI_1 muxed to a single clock by a glitch
> > + * free mux to safely change frequency while running.
> > + */
> > + assigned-clocks = <&clkc CLKID_MALI_0_SEL>,
> > + <&clkc CLKID_MALI_0>,
> > + <&clkc CLKID_MALI>; /* Glitch free mux */
> > + assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
> > + <0>, /* Do Nothing */
> > + <&clkc CLKID_MALI_0>;
> > + assigned-clock-rates = <0>, /* Do Nothing */
> > + <666666666>,
> > + <0>; /* Do Nothing */
> > + };
> > +};
> > +
> > &i2c_A {
> > clocks = <&clkc CLKID_I2C>;
> > };
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> > new file mode 100644
> > index 0000000..f06cc234
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-mali.dtsi
> > @@ -0,0 +1,43 @@
> > +/*
> > + * Copyright (c) 2017 BayLibre SAS
> > + * Author: Neil Armstrong <narmstrong@baylibre.com>
> > + *
> > + * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > + */
> > +
> > +&apb {
> > + mali: gpu@c0000 {
> > + compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
> > + reg = <0x0 0xc0000 0x0 0x40000>;
> > + interrupts = <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 165 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 166 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 167 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 168 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-names = "gp", "gpmmu", "pp", "pmu",
> > + "pp0", "ppmmu0", "pp1", "ppmmu1",
> > + "pp2", "ppmmu2";
> > + clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
> > + clock-names = "bus", "core";
> > +
> > + /*
> > + * Mali clocking is provided by two identical clock paths
> > + * MALI_0 and MALI_1 muxed to a single clock by a glitch
> > + * free mux to safely change frequency while running.
> > + */
> > + assigned-clocks = <&clkc CLKID_MALI_0_SEL>,
> > + <&clkc CLKID_MALI_0>,
> > + <&clkc CLKID_MALI>; /* Glitch free mux */
> > + assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
> > + <0>, /* Do Nothing */
> > + <&clkc CLKID_MALI_0>;
> > + assigned-clock-rates = <0>, /* Do Nothing */
> > + <666666666>,
> > + <0>; /* Do Nothing */
> > + };
> > +};
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> > index 615308e..5a90e30 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d.dtsi
> > @@ -42,6 +42,7 @@
> > */
> >
> > #include "meson-gxl.dtsi"
> > +#include "meson-gxl-mali.dtsi"
> >
> > / {
> > compatible = "amlogic,s905d", "amlogic,meson-gxl";
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> > index 08237ee..0f78d83 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> > +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
> > @@ -42,6 +42,7 @@
> > */
> >
> > #include "meson-gxl.dtsi"
> > +#include "meson-gxl-mali.dtsi"
> >
> > / {
> > compatible = "amlogic,s905x", "amlogic,meson-gxl";
> --
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/9] clk: meson: update clock controller for audio support
From: Michael Turquette @ 2017-03-27 19:52 UTC (permalink / raw)
To: Kevin Hilman, Jerome Brunet
Cc: Stephen Boyd, Carlo Caione, linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <m2r324bq9s.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Quoting Kevin Hilman (2017-03-10 16:39:27)
> Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org> writes:
>
> > This patchset is a first round of update to the meson clock controllers
> > to bring audio support. The patchset is based on clk-next. It could be
> > rebased on amlogic tree later on, if you prefer the patches to go through
> > Kevin's tree.
>
> I'd prefer these go through the clk tree, and get an immutable branch
> that I can use for my stuff that goes through the arm-soc tree.
Applied to clk-meson, a stable branch, which has been merged into
clk-next.
Kevin, feel free to use clk-meson or any commit id therein: they will
not be rebased.
Regards,
Mike
>
> Kevin
>
> > First patch fix an issue found while writing patch 5 (Giving ternary
> > operator to SET_PARM)
> >
> > Following Stephen comment on the v1, patch 2 adds the const qualifiers
> > missing upstream.
> >
> > Patches 3 and 4 put the generic muxes and divisors declaration in tables so
> > the register address fixup works in the same way as the clock gates. We are
> > going to add more of these clock types for audio or gpu support, so we
> > can't continue to fix addresses individually like it is currently done.
> >
> > Patches 5 to 8 improve the support of the mpll clocks, now allowing the
> > rate to be set. Among other things, the mplls are the parent clocks of the
> > i2s and spdif clocks.
> >
> > Patch 9 expose the clock gates required to power on the i2s output.
> >
> > These patches have been tested on the meson gxbb p200 board, as part of the
> > ongoing work to bring audio support to meson SoC family.
> >
> > Changes since v1 [0]:
> > * Add SET_PARM fix to the series
> > * Add missing const qualifiers to the clock arrays
> > * No more additional patches required as SAR clocks have been merged
> >
> > [0]: http://lkml.kernel.org/r/20170228133002.17894-1-jbrunet@baylibre.com
> >
> > Jerome Brunet (9):
> > clk: meson: fix SET_PARM macro
> > clk: meson: add missing const qualifiers on gate arrays
> > clk: meson8b: put dividers and muxes in tables
> > clk: gxbb: put dividers and muxes in tables
> > clk: meson: mpll: add rw operation
> > clk: meson: gxbb: mpll: use rw operation
> > clk: meson8b: add the mplls clocks 0, 1 and 2
> > clk: meson: mpll: correct N2 maximum value
> > dt-bindings: clk: gxbb: expose i2s output clock gates
> >
> > drivers/clk/meson/clk-mpll.c | 152 ++++++++++++++++++++++++++++++++--
> > drivers/clk/meson/clkc.h | 6 +-
> > drivers/clk/meson/gxbb.c | 66 ++++++++++++---
> > drivers/clk/meson/gxbb.h | 10 +--
> > drivers/clk/meson/meson8b.c | 127 ++++++++++++++++++++++++++--
> > drivers/clk/meson/meson8b.h | 20 ++++-
> > include/dt-bindings/clock/gxbb-clkc.h | 5 ++
> > 7 files changed, 356 insertions(+), 30 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RFC v4 09/10] tty: serdev-ttyport: return actual baudrate from ttyport_set_baudrate
From: Rob Herring @ 2017-03-27 19:50 UTC (permalink / raw)
To: Stefan Wahren
Cc: Mark Rutland, David S. Miller, Greg Kroah-Hartman, Jiri Slaby,
Marcel Holtmann, Sebastian Reichel, netdev,
devicetree@vger.kernel.org, linux-serial@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1490621848-24828-10-git-send-email-stefan.wahren@i2se.com>
On Mon, Mar 27, 2017 at 8:37 AM, Stefan Wahren <stefan.wahren@i2se.com> wrote:
> Instead of returning the requested baudrate, we better return the
> actual one because it isn't always the same.
>
> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
> drivers/tty/serdev/serdev-ttyport.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH V7 2/7] PCI: Apply the new generic I/O management on PCI IO hosts
From: dann frazier @ 2017-03-27 19:46 UTC (permalink / raw)
To: zhichang.yuan
Cc: Catalin Marinas, Will Deacon, Rob Herring, frowand.list,
Bjorn Helgaas, rafael, Mark Rutland, rjw, Arnd Bergmann,
linux-arm-kernel, linux-acpi, lorenzo.pieralisi, benh,
linux-kernel@vger.kernel.org, linuxarm,
devicetree@vger.kernel.org, linux-pci,
linux-serial@vger.kernel.org, minyard, liviu.dudau, zourongrong,
john.garry, gabriele.paoloni, zhich
In-Reply-To: <1489372963-9000-3-git-send-email-yuanzhichang@hisilicon.com>
On Sun, Mar 12, 2017 at 8:42 PM, zhichang.yuan
<yuanzhichang@hisilicon.com> wrote:
> After introducing the new generic I/O space management(LIBIO), the original PCI
> MMIO relevant helpers need to be updated based on the new interfaces defined in
> LIBIO.
> This patch adapts the corresponding code to match the changes introduced by
> LIBIO.
> Signed-off-by: zhichang.yuan <yuanzhichang@hisilicon.com>
> Signed-off-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de> #earlier draft
> Acked-by: Bjorn Helgaas <bhelgaas@google.com> #drivers/pci parts
> ---
> drivers/acpi/pci_root.c | 8 +++--
> drivers/of/address.c | 4 ++-
> drivers/pci/pci.c | 96 +++++++++++--------------------------------------
> include/linux/pci.h | 3 +-
> 4 files changed, 30 insertions(+), 81 deletions(-)
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index 919be0a..4d8cc24 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -730,7 +730,8 @@ static void acpi_pci_root_validate_resources(struct device *dev,
> }
> }
>
> -static void acpi_pci_root_remap_iospace(struct resource_entry *entry)
> +static void acpi_pci_root_remap_iospace(struct fwnode_handle *fwnode,
> + struct resource_entry *entry)
> {
> #ifdef PCI_IOBASE
> struct resource *res = entry->res;
> @@ -739,7 +740,7 @@ static void acpi_pci_root_remap_iospace(struct resource_entry *entry)
> resource_size_t length = resource_size(res);
> unsigned long port;
>
> - if (pci_register_io_range(cpu_addr, length))
> + if (pci_register_io_range(fwnode, cpu_addr, length))
> goto err;
>
> port = pci_address_to_pio(cpu_addr);
> @@ -781,7 +782,8 @@ int acpi_pci_probe_root_resources(struct acpi_pci_root_info *info)
> else {
> resource_list_for_each_entry_safe(entry, tmp, list) {
> if (entry->res->flags & IORESOURCE_IO)
> - acpi_pci_root_remap_iospace(entry);
> + acpi_pci_root_remap_iospace(&device->fwnode,
> + entry);
>
> if (entry->res->flags & IORESOURCE_DISABLED)
> resource_list_destroy_entry(entry);
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 02b2903..fb5d16a 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -2,6 +2,7 @@
> #define pr_fmt(fmt) "OF: " fmt
>
> #include <linux/device.h>
> +#include <linux/fwnode.h>
> #include <linux/io.h>
> #include <linux/ioport.h>
> #include <linux/module.h>
> @@ -323,7 +324,8 @@ int of_pci_range_to_resource(struct of_pci_range *range,
>
> if (res->flags & IORESOURCE_IO) {
> unsigned long port;
> - err = pci_register_io_range(range->cpu_addr, range->size);
> + err = pci_register_io_range(&np->fwnode, range->cpu_addr,
> + range->size);
> if (err)
> goto invalid_range;
> port = pci_address_to_pio(range->cpu_addr);
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index 7904d02..079319f 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -3238,65 +3238,37 @@ int pci_request_regions_exclusive(struct pci_dev *pdev, const char *res_name)
> }
> EXPORT_SYMBOL(pci_request_regions_exclusive);
>
> -#ifdef PCI_IOBASE
> -struct io_range {
> - struct list_head list;
> - phys_addr_t start;
> - resource_size_t size;
> -};
> -
> -static LIST_HEAD(io_range_list);
> -static DEFINE_SPINLOCK(io_range_lock);
> -#endif
> -
> /*
> * Record the PCI IO range (expressed as CPU physical address + size).
> * Return a negative value if an error has occured, zero otherwise
> */
> -int __weak pci_register_io_range(phys_addr_t addr, resource_size_t size)
> +int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t addr,
> + resource_size_t size)
> {
> int err = 0;
>
> #ifdef PCI_IOBASE
> - struct io_range *range;
> - resource_size_t allocated_size = 0;
> -
> - /* check if the range hasn't been previously recorded */
> - spin_lock(&io_range_lock);
> - list_for_each_entry(range, &io_range_list, list) {
> - if (addr >= range->start && addr + size <= range->start + size) {
> - /* range already registered, bail out */
> - goto end_register;
> - }
> - allocated_size += range->size;
> - }
> -
> - /* range not registed yet, check for available space */
> - if (allocated_size + size - 1 > IO_SPACE_LIMIT) {
> - /* if it's too big check if 64K space can be reserved */
> - if (allocated_size + SZ_64K - 1 > IO_SPACE_LIMIT) {
> - err = -E2BIG;
> - goto end_register;
> - }
> + struct libio_range *range, *tmprange;
>
> - size = SZ_64K;
> - pr_warn("Requested IO range too big, new size set to 64K\n");
> - }
> + if (!size || addr + size < addr)
> + return -EINVAL;
>
> - /* add the range to the list */
> - range = kzalloc(sizeof(*range), GFP_ATOMIC);
> - if (!range) {
> - err = -ENOMEM;
> - goto end_register;
> - }
> + WARN_ON(!PAGE_ALIGNED(addr) || !PAGE_ALIGNED(size));
>
> - range->start = addr;
> + range = kzalloc(sizeof(*range), GFP_KERNEL);
> + if (!range)
> + return -ENOMEM;
> + range->node = fwnode;
> + range->flags = IO_CPU_MMIO;
> range->size = size;
> + range->hw_start = addr;
>
> - list_add_tail(&range->list, &io_range_list);
> -
> -end_register:
> - spin_unlock(&io_range_lock);
> + tmprange = register_libio_range(range);
> + if (tmprange != range) {
> + kfree(range);
> + if (!IS_ERR(tmprange))
> + err = 0;
> + }
> #endif
>
> return err;
> @@ -3307,21 +3279,10 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
> phys_addr_t address = (phys_addr_t)OF_BAD_ADDR;
>
> #ifdef PCI_IOBASE
> - struct io_range *range;
> - resource_size_t allocated_size = 0;
> -
> if (pio > IO_SPACE_LIMIT)
> return address;
>
> - spin_lock(&io_range_lock);
> - list_for_each_entry(range, &io_range_list, list) {
> - if (pio >= allocated_size && pio < allocated_size + range->size) {
> - address = range->start + pio - allocated_size;
> - break;
> - }
> - allocated_size += range->size;
> - }
> - spin_unlock(&io_range_lock);
> + address = libio_to_hwaddr(pio);
> #endif
>
> return address;
> @@ -3330,25 +3291,8 @@ phys_addr_t pci_pio_to_address(unsigned long pio)
> unsigned long __weak pci_address_to_pio(phys_addr_t address)
> {
> #ifdef PCI_IOBASE
> - struct io_range *res;
> - resource_size_t offset = 0;
> - unsigned long addr = -1;
> -
> - spin_lock(&io_range_lock);
> - list_for_each_entry(res, &io_range_list, list) {
> - if (address >= res->start && address < res->start + res->size) {
> - addr = address - res->start + offset;
> - break;
> - }
> - offset += res->size;
> - }
> - spin_unlock(&io_range_lock);
> -
> - return addr;
> + return libio_translate_cpuaddr(address);
> #else
> - if (address > IO_SPACE_LIMIT)
> - return (unsigned long)-1;
> -
> return (unsigned long) address;
> #endif
> }
fyi, this fails to build if PCI_IOBASE is defined and CONFIG_LIBIO=n:
drivers/built-in.o: In function `pci_register_io_range':
/home/ubuntu/linux-4.10.0/drivers/pci/pci.c:3266: undefined reference
to `register_libio_range'
drivers/built-in.o: In function `pci_pio_to_address':
/home/ubuntu/linux-4.10.0/drivers/pci/pci.c:3285: undefined reference
to `libio_to_hwaddr'
drivers/built-in.o: In function `pci_address_to_pio':
/home/ubuntu/linux-4.10.0/drivers/pci/pci.c:3294: undefined reference
to `libio_translate_cpuaddr'
-dann
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index eb3da1a..6401327 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -1194,7 +1194,8 @@ int __must_check pci_bus_alloc_resource(struct pci_bus *bus,
> void *alignf_data);
>
>
> -int pci_register_io_range(phys_addr_t addr, resource_size_t size);
> +int pci_register_io_range(struct fwnode_handle *fwnode, phys_addr_t addr,
> + resource_size_t size);
> unsigned long pci_address_to_pio(phys_addr_t addr);
> phys_addr_t pci_pio_to_address(unsigned long pio);
> int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr);
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v4 4/4] mvebu: wrt1900ac: Use pwm-fan rather than gpio-fan
From: Ralph Sennhauser @ 2017-03-27 19:43 UTC (permalink / raw)
To: Linus Walleij, Thierry Reding
Cc: Imre Kaloz, Andrew Lunn, Ralph Sennhauser, Alexandre Courbot,
Rob Herring, Mark Rutland, Jason Cooper, Gregory Clement,
Sebastian Hesselbarth, Russell King, linux-pwm, linux-gpio,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20170327194301.1104-1-ralph.sennhauser@gmail.com>
From: Andrew Lunn <andrew@lunn.ch>
The mvebu GPIO driver can also perform PWM on some pins. Use the pwm-fan
driver to control the fan of the WRT1900AC, giving us finer grained control
over its speed and hence noise.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
URL: https://patchwork.ozlabs.org/patch/427291/
[Ralph Sennhauser: drop flags paramter from pwms, no longer used]
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
---
arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
index 9efcf59..6d705f5 100644
--- a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
+++ b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
@@ -308,13 +308,11 @@
};
};
- gpio_fan {
+ pwm_fan {
/* SUNON HA4010V4-0000-C99 */
- compatible = "gpio-fan";
- gpios = <&gpio0 24 0>;
- gpio-fan,speed-map = <0 0
- 4500 1>;
+ compatible = "pwm-fan";
+ pwms = <&gpio0 24 4000>;
};
dsa {
--
2.10.2
^ permalink raw reply related
* [PATCH v4 3/4] ARM: mvebu: Enable SENSORS_PWM_FAN in defconfig
From: Ralph Sennhauser @ 2017-03-27 19:42 UTC (permalink / raw)
To: Linus Walleij, Thierry Reding
Cc: Imre Kaloz, Andrew Lunn, Ralph Sennhauser, Alexandre Courbot,
Rob Herring, Mark Rutland, Jason Cooper, Gregory Clement,
Sebastian Hesselbarth, Russell King, linux-pwm, linux-gpio,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20170327194301.1104-1-ralph.sennhauser@gmail.com>
From: Andrew Lunn <andrew@lunn.ch>
Now that the GPIO driver also supports PWM operation, enable the PWM
framework and fan driver in mvebu_v7_defconfig.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
URL: https://patchwork.ozlabs.org/patch/427297/
[Ralph Sennhauser: add fan driver to defconfig]
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
---
arch/arm/configs/mvebu_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/mvebu_v7_defconfig b/arch/arm/configs/mvebu_v7_defconfig
index f1a0e25..6955370 100644
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -135,6 +135,8 @@ CONFIG_DMADEVICES=y
CONFIG_MV_XOR=y
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_MEMORY=y
+CONFIG_PWM=y
+CONFIG_SENSORS_PWM_FAN=y
CONFIG_EXT4_FS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
--
2.10.2
^ permalink raw reply related
* [PATCH v4 2/4] mvebu: xp: Add PWM properties to .dtsi files
From: Ralph Sennhauser @ 2017-03-27 19:42 UTC (permalink / raw)
To: Linus Walleij, Thierry Reding
Cc: Mark Rutland, Andrew Lunn, Jason Cooper, Alexandre Courbot,
linux-gpio, Russell King, linux-pwm, linux-kernel,
Gregory Clement, devicetree, Rob Herring, Ralph Sennhauser,
Imre Kaloz, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20170327194301.1104-1-ralph.sennhauser@gmail.com>
From: Andrew Lunn <andrew@lunn.ch>
Add properties to the GPIO nodes to allow them to be also used as PWM
lines.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
URL: https://patchwork.ozlabs.org/patch/427294/
[Ralph Sennhauser:
* Use new compatible string marvell,armada-370-xp-gpio
* Add missing reg-names / #pwm-cell properties to armada-xp-mv78260.dtsi
'gpio1' node]
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
---
arch/arm/boot/dts/armada-370.dtsi | 16 +++++++++++-----
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 14 ++++++++++----
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 16 +++++++++++-----
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 16 +++++++++++-----
4 files changed, 43 insertions(+), 19 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index cc011c8..e30b076 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -137,29 +137,35 @@
};
gpio0: gpio@18100 {
- compatible = "marvell,orion-gpio";
- reg = <0x18100 0x40>;
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18100 0x40>, <0x181c0 0x08>;
+ reg-names = "gpio", "pwm";
ngpios = <32>;
gpio-controller;
#gpio-cells = <2>;
+ #pwm-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <82>, <83>, <84>, <85>;
+ clocks = <&coreclk 0>;
};
gpio1: gpio@18140 {
- compatible = "marvell,orion-gpio";
- reg = <0x18140 0x40>;
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18140 0x40>, <0x181c8 0x08>;
+ reg-names = "gpio", "pwm";
ngpios = <32>;
gpio-controller;
#gpio-cells = <2>;
+ #pwm-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <87>, <88>, <89>, <90>;
+ clocks = <&coreclk 0>;
};
gpio2: gpio@18180 {
- compatible = "marvell,orion-gpio";
+ compatible = "marvell,armada-370-xp-gpio";
reg = <0x18180 0x40>;
ngpios = <2>;
gpio-controller;
diff --git a/arch/arm/boot/dts/armada-xp-mv78230.dtsi b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
index 07c5090..429ac10 100644
--- a/arch/arm/boot/dts/armada-xp-mv78230.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78230.dtsi
@@ -202,25 +202,31 @@
internal-regs {
gpio0: gpio@18100 {
- compatible = "marvell,orion-gpio";
- reg = <0x18100 0x40>;
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18100 0x40>, <0x181c0 0x08>;
+ reg-names = "gpio", "pwm";
ngpios = <32>;
gpio-controller;
#gpio-cells = <2>;
+ #pwm-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <82>, <83>, <84>, <85>;
+ clocks = <&coreclk 0>;
};
gpio1: gpio@18140 {
- compatible = "marvell,orion-gpio";
- reg = <0x18140 0x40>;
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18140 0x40>, <0x181c8 0x08>;
+ reg-names = "gpio", "pwm";
ngpios = <17>;
gpio-controller;
#gpio-cells = <2>;
+ #pwm-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <87>, <88>, <89>;
+ clocks = <&coreclk 0>;
};
};
};
diff --git a/arch/arm/boot/dts/armada-xp-mv78260.dtsi b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
index 64e936a..333c470 100644
--- a/arch/arm/boot/dts/armada-xp-mv78260.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78260.dtsi
@@ -285,29 +285,35 @@
internal-regs {
gpio0: gpio@18100 {
- compatible = "marvell,orion-gpio";
- reg = <0x18100 0x40>;
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18100 0x40>, <0x181c0 0x08>;
+ reg-names = "gpio", "pwm";
ngpios = <32>;
gpio-controller;
#gpio-cells = <2>;
+ #pwm-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <82>, <83>, <84>, <85>;
+ clocks = <&coreclk 0>;
};
gpio1: gpio@18140 {
- compatible = "marvell,orion-gpio";
- reg = <0x18140 0x40>;
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18140 0x40>, <0x181c8 0x08>;
+ reg-names = "gpio", "pwm";
ngpios = <32>;
gpio-controller;
#gpio-cells = <2>;
+ #pwm-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <87>, <88>, <89>, <90>;
+ clocks = <&coreclk 0>;
};
gpio2: gpio@18180 {
- compatible = "marvell,orion-gpio";
+ compatible = "marvell,armada-370-xp-gpio";
reg = <0x18180 0x40>;
ngpios = <3>;
gpio-controller;
diff --git a/arch/arm/boot/dts/armada-xp-mv78460.dtsi b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
index d1383dd..2ff825d 100644
--- a/arch/arm/boot/dts/armada-xp-mv78460.dtsi
+++ b/arch/arm/boot/dts/armada-xp-mv78460.dtsi
@@ -323,29 +323,35 @@
internal-regs {
gpio0: gpio@18100 {
- compatible = "marvell,orion-gpio";
- reg = <0x18100 0x40>;
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18100 0x40>, <0x181c0 0x08>;
+ reg-names = "gpio", "pwm";
ngpios = <32>;
gpio-controller;
#gpio-cells = <2>;
+ #pwm-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <82>, <83>, <84>, <85>;
+ clocks = <&coreclk 0>;
};
gpio1: gpio@18140 {
- compatible = "marvell,orion-gpio";
- reg = <0x18140 0x40>;
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18140 0x40>, <0x181c8 0x08>;
+ reg-names = "gpio", "pwm";
ngpios = <32>;
gpio-controller;
#gpio-cells = <2>;
+ #pwm-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <87>, <88>, <89>, <90>;
+ clocks = <&coreclk 0>;
};
gpio2: gpio@18180 {
- compatible = "marvell,orion-gpio";
+ compatible = "marvell,armada-370-xp-gpio";
reg = <0x18180 0x40>;
ngpios = <3>;
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH v4 1/4] gpio: mvebu: Add limited PWM support
From: Ralph Sennhauser @ 2017-03-27 19:42 UTC (permalink / raw)
To: Linus Walleij, Thierry Reding
Cc: Imre Kaloz, Andrew Lunn, Ralph Sennhauser, Alexandre Courbot,
Rob Herring, Mark Rutland, Jason Cooper, Gregory Clement,
Sebastian Hesselbarth, Russell King, linux-pwm, linux-gpio,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20170327194301.1104-1-ralph.sennhauser@gmail.com>
From: Andrew Lunn <andrew@lunn.ch>
Armada 370/XP devices can 'blink' GPIO lines with a configurable on
and off period. This can be modelled as a PWM.
However, there are only two sets of PWM configuration registers for
all the GPIO lines. This driver simply allows a single GPIO line per
GPIO chip of 32 lines to be used as a PWM. Attempts to use more return
EBUSY.
Due to the interleaving of registers it is not simple to separate the
PWM driver from the GPIO driver. Thus the GPIO driver has been
extended with a PWM driver.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
URL: https://patchwork.ozlabs.org/patch/427287/
URL: https://patchwork.ozlabs.org/patch/427295/
[Ralph Sennhauser:
* Port forward
* Merge PWM portion into gpio-mvebu.c
* Switch to atomic PWM API
* Add new compatible string marvell,armada-370-xp-gpio
* Update and merge documentation patch
* Update MAINTAINERS]
Signed-off-by: Ralph Sennhauser <ralph.sennhauser@gmail.com>
---
.../devicetree/bindings/gpio/gpio-mvebu.txt | 32 ++
MAINTAINERS | 2 +
drivers/gpio/gpio-mvebu.c | 324 ++++++++++++++++++++-
3 files changed, 346 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
index a6f3bec..fe49e9d 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
@@ -38,6 +38,24 @@ Required properties:
- #gpio-cells: Should be two. The first cell is the pin number. The
second cell is reserved for flags, unused at the moment.
+Optional properties:
+
+In order to use the gpio lines in PWM mode, some additional optional
+properties are required. Only Armada 370 and XP support these properties.
+
+- compatible: Must contain "marvell,armada-370-xp-gpio"
+
+- reg: an additional register set is needed, for the GPIO Blink
+ Counter on/off registers.
+
+- reg-names: Must contain an entry "pwm" corresponding to the
+ additional register range needed for pwm operation.
+
+- #pwm-cells: Should be two. The first cell is the GPIO line number. The
+ second cell is the period in nanoseconds.
+
+- clocks: Must be a phandle to the clock for the gpio controller.
+
Example:
gpio0: gpio@d0018100 {
@@ -51,3 +69,17 @@ Example:
#interrupt-cells = <2>;
interrupts = <16>, <17>, <18>, <19>;
};
+
+ gpio1: gpio@18140 {
+ compatible = "marvell,armada-370-xp-gpio";
+ reg = <0x18140 0x40>, <0x181c8 0x08>;
+ reg-names = "gpio", "pwm";
+ ngpios = <17>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ #pwm-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <87>, <88>, <89>;
+ clocks = <&coreclk 0>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 58b3a22..19382f5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10295,6 +10295,8 @@ F: include/linux/pwm.h
F: drivers/pwm/
F: drivers/video/backlight/pwm_bl.c
F: include/linux/pwm_backlight.h
+F: drivers/gpio/gpio-mvebu.c
+F: Documentation/devicetree/bindings/gpio/gpio-mvebu.txt
PXA2xx/PXA3xx SUPPORT
M: Daniel Mack <daniel@zonque.org>
diff --git a/drivers/gpio/gpio-mvebu.c b/drivers/gpio/gpio-mvebu.c
index fae4db6..e310951 100644
--- a/drivers/gpio/gpio-mvebu.c
+++ b/drivers/gpio/gpio-mvebu.c
@@ -42,22 +42,34 @@
#include <linux/io.h>
#include <linux/of_irq.h>
#include <linux/of_device.h>
+#include <linux/pwm.h>
#include <linux/clk.h>
#include <linux/pinctrl/consumer.h>
#include <linux/irqchip/chained_irq.h>
+#include <linux/platform_device.h>
#include <linux/bitops.h>
+#include "gpiolib.h"
+
/*
* GPIO unit register offsets.
*/
-#define GPIO_OUT_OFF 0x0000
-#define GPIO_IO_CONF_OFF 0x0004
-#define GPIO_BLINK_EN_OFF 0x0008
-#define GPIO_IN_POL_OFF 0x000c
-#define GPIO_DATA_IN_OFF 0x0010
-#define GPIO_EDGE_CAUSE_OFF 0x0014
-#define GPIO_EDGE_MASK_OFF 0x0018
-#define GPIO_LEVEL_MASK_OFF 0x001c
+#define GPIO_OUT_OFF 0x0000
+#define GPIO_IO_CONF_OFF 0x0004
+#define GPIO_BLINK_EN_OFF 0x0008
+#define GPIO_IN_POL_OFF 0x000c
+#define GPIO_DATA_IN_OFF 0x0010
+#define GPIO_EDGE_CAUSE_OFF 0x0014
+#define GPIO_EDGE_MASK_OFF 0x0018
+#define GPIO_LEVEL_MASK_OFF 0x001c
+#define GPIO_BLINK_CNT_SELECT_OFF 0x0020
+
+/*
+ * PWM register offsets.
+ */
+#define PWM_BLINK_ON_DURATION_OFF 0x0
+#define PWM_BLINK_OFF_DURATION_OFF 0x4
+
/* The MV78200 has per-CPU registers for edge mask and level mask */
#define GPIO_EDGE_MASK_MV78200_OFF(cpu) ((cpu) ? 0x30 : 0x18)
@@ -78,6 +90,20 @@
#define MVEBU_MAX_GPIO_PER_BANK 32
+struct mvebu_pwm {
+ void __iomem *membase;
+ unsigned long clk_rate;
+ bool used;
+ struct pwm_chip chip;
+ spinlock_t lock;
+ struct mvebu_gpio_chip *mvchip;
+
+ /* Used to preserve GPIO/PWM registers across suspend/resume */
+ u32 blink_select;
+ u32 blink_on_duration;
+ u32 blink_off_duration;
+};
+
struct mvebu_gpio_chip {
struct gpio_chip chip;
spinlock_t lock;
@@ -87,6 +113,10 @@ struct mvebu_gpio_chip {
struct irq_domain *domain;
int soc_variant;
+ /* Used for PWM support */
+ struct clk *clk;
+ struct mvebu_pwm *mvpwm;
+
/* Used to preserve GPIO registers across suspend/resume */
u32 out_reg;
u32 io_conf_reg;
@@ -110,6 +140,12 @@ static void __iomem *mvebu_gpioreg_blink(struct mvebu_gpio_chip *mvchip)
return mvchip->membase + GPIO_BLINK_EN_OFF;
}
+static void __iomem *mvebu_gpioreg_blink_counter_select(struct mvebu_gpio_chip
+ *mvchip)
+{
+ return mvchip->membase + GPIO_BLINK_CNT_SELECT_OFF;
+}
+
static void __iomem *mvebu_gpioreg_io_conf(struct mvebu_gpio_chip *mvchip)
{
return mvchip->membase + GPIO_IO_CONF_OFF;
@@ -181,6 +217,20 @@ static void __iomem *mvebu_gpioreg_level_mask(struct mvebu_gpio_chip *mvchip)
}
/*
+ * Functions returning addresses of individual registers for a given
+ * PWM controller.
+ */
+static void __iomem *mvebu_pwmreg_blink_on_duration(struct mvebu_pwm *mvpwm)
+{
+ return mvpwm->membase + PWM_BLINK_ON_DURATION_OFF;
+}
+
+static void __iomem *mvebu_pwmreg_blink_off_duration(struct mvebu_pwm *mvpwm)
+{
+ return mvpwm->membase + PWM_BLINK_OFF_DURATION_OFF;
+}
+
+/*
* Functions implementing the gpio_chip methods
*/
static void mvebu_gpio_set(struct gpio_chip *chip, unsigned int pin, int value)
@@ -484,6 +534,243 @@ static void mvebu_gpio_irq_handler(struct irq_desc *desc)
chained_irq_exit(chip, desc);
}
+/*
+ * Functions implementing the pwm_chip methods
+ */
+static struct mvebu_pwm *to_mvebu_pwm(struct pwm_chip *chip)
+{
+ return container_of(chip, struct mvebu_pwm, chip);
+}
+
+static int mvebu_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct mvebu_pwm *mvpwm = to_mvebu_pwm(chip);
+ struct gpio_desc *desc = gpio_to_desc(pwm->pwm);
+ unsigned long flags;
+ int ret = 0;
+
+ spin_lock_irqsave(&mvpwm->lock, flags);
+ if (mvpwm->used) {
+ ret = -EBUSY;
+ } else {
+ if (!desc) {
+ ret = -ENODEV;
+ goto out;
+ }
+ ret = gpiod_request(desc, "mvebu-pwm");
+ if (ret)
+ goto out;
+
+ ret = gpiod_direction_output(desc, 0);
+ if (ret) {
+ gpiod_free(desc);
+ goto out;
+ }
+
+ mvpwm->used = true;
+ }
+
+out:
+ spin_unlock_irqrestore(&mvpwm->lock, flags);
+ return ret;
+}
+
+static void mvebu_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct mvebu_pwm *mvpwm = to_mvebu_pwm(chip);
+ struct gpio_desc *desc = gpio_to_desc(pwm->pwm);
+ unsigned long flags;
+
+ spin_lock_irqsave(&mvpwm->lock, flags);
+ gpiod_free(desc);
+ mvpwm->used = false;
+ spin_unlock_irqrestore(&mvpwm->lock, flags);
+}
+
+static void mvebu_pwm_get_state(struct pwm_chip *chip,
+ struct pwm_device *pwm,
+ struct pwm_state *state) {
+
+ struct mvebu_pwm *mvpwm = to_mvebu_pwm(chip);
+ struct mvebu_gpio_chip *mvchip = mvpwm->mvchip;
+ unsigned long long val;
+ unsigned long flags;
+ u32 u;
+
+ spin_lock_irqsave(&mvpwm->lock, flags);
+
+ val = (unsigned long long)
+ readl_relaxed(mvebu_pwmreg_blink_on_duration);
+ val *= NSEC_PER_SEC;
+ do_div(val, mvpwm->clk_rate);
+ if (val > UINT_MAX)
+ state->duty_cycle = UINT_MAX;
+ else if (val)
+ state->duty_cycle = val;
+ else
+ state->duty_cycle = 1;
+
+ val = (unsigned long long)
+ readl_relaxed(mvebu_pwmreg_blink_off_duration);
+ val *= NSEC_PER_SEC;
+ do_div(val, mvpwm->clk_rate);
+ if (val < state->duty_cycle) {
+ state->period = 1;
+ } else {
+ val -= state->duty_cycle;
+ if (val > UINT_MAX)
+ state->period = UINT_MAX;
+ else if (val)
+ state->period = val;
+ else
+ state->period = 1;
+ }
+
+ u = readl_relaxed(mvebu_gpioreg_blink(mvchip));
+ if (u)
+ state->enabled = true;
+ else
+ state->enabled = false;
+
+ spin_unlock_irqrestore(&mvpwm->lock, flags);
+}
+
+static int mvebu_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ struct pwm_state *state)
+{
+ struct mvebu_pwm *mvpwm = to_mvebu_pwm(chip);
+ struct mvebu_gpio_chip *mvchip = mvpwm->mvchip;
+ unsigned long long val;
+ unsigned long flags;
+ unsigned int on, off;
+
+ val = (unsigned long long) mvpwm->clk_rate * state->duty_cycle;
+ do_div(val, NSEC_PER_SEC);
+ if (val > UINT_MAX)
+ return -EINVAL;
+ if (val)
+ on = val;
+ else
+ on = 1;
+
+ val = (unsigned long long) mvpwm->clk_rate *
+ (state->period - state->duty_cycle);
+ do_div(val, NSEC_PER_SEC);
+ if (val > UINT_MAX)
+ return -EINVAL;
+ if (val)
+ off = val;
+ else
+ off = 1;
+
+ spin_lock_irqsave(&mvpwm->lock, flags);
+
+ writel_relaxed(on, mvebu_pwmreg_blink_on_duration(mvpwm));
+ writel_relaxed(off, mvebu_pwmreg_blink_off_duration(mvpwm));
+ if (state->enabled)
+ mvebu_gpio_blink(&mvchip->chip, pwm->hwpwm, 1);
+ else
+ mvebu_gpio_blink(&mvchip->chip, pwm->hwpwm, 0);
+
+ spin_unlock_irqrestore(&mvpwm->lock, flags);
+
+ return 0;
+}
+
+static const struct pwm_ops mvebu_pwm_ops = {
+ .request = mvebu_pwm_request,
+ .free = mvebu_pwm_free,
+ .get_state = mvebu_pwm_get_state,
+ .apply = mvebu_pwm_apply,
+ .owner = THIS_MODULE,
+};
+
+static void __maybe_unused mvebu_pwm_suspend(struct mvebu_gpio_chip *mvchip)
+{
+ struct mvebu_pwm *mvpwm = mvchip->mvpwm;
+
+ mvpwm->blink_select =
+ readl_relaxed(mvebu_gpioreg_blink_counter_select(mvchip));
+ mvpwm->blink_on_duration =
+ readl_relaxed(mvebu_pwmreg_blink_on_duration(mvpwm));
+ mvpwm->blink_off_duration =
+ readl_relaxed(mvebu_pwmreg_blink_off_duration(mvpwm));
+}
+
+static void __maybe_unused mvebu_pwm_resume(struct mvebu_gpio_chip *mvchip)
+{
+ struct mvebu_pwm *mvpwm = mvchip->mvpwm;
+
+ writel_relaxed(mvpwm->blink_select,
+ mvebu_gpioreg_blink_counter_select(mvchip));
+ writel_relaxed(mvpwm->blink_on_duration,
+ mvebu_pwmreg_blink_on_duration(mvpwm));
+ writel_relaxed(mvpwm->blink_off_duration,
+ mvebu_pwmreg_blink_off_duration(mvpwm));
+}
+
+static int mvebu_pwm_probe(struct platform_device *pdev,
+ struct mvebu_gpio_chip *mvchip,
+ int id)
+{
+ struct device *dev = &pdev->dev;
+ struct mvebu_pwm *mvpwm;
+ struct resource *res;
+
+ if (!of_device_is_compatible(mvchip->chip.of_node,
+ "marvell,armada-370-xp-gpio"))
+ return 0;
+ /*
+ * There are only two sets of PWM configuration registers for
+ * all the GPIO lines on those SoCs which this driver reserves
+ * for the first two GPIO chips. So if the resource is missing
+ * we can't treat it as an error.
+ */
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "pwm");
+ if (!res)
+ return 0;
+
+ /*
+ * Use set A for lines of GPIO chip with id 0, B for GPIO chip
+ * with id 1. Don't allow further GPIO chips to be used for PWM.
+ */
+ if (id == 0)
+ writel_relaxed(0, mvebu_gpioreg_blink_counter_select(mvchip));
+ else if (id == 1)
+ writel_relaxed(U32_MAX,
+ mvebu_gpioreg_blink_counter_select(mvchip));
+ else
+ return -EINVAL;
+
+ mvpwm = devm_kzalloc(dev, sizeof(struct mvebu_pwm), GFP_KERNEL);
+ if (!mvpwm)
+ return -ENOMEM;
+ mvchip->mvpwm = mvpwm;
+ mvpwm->mvchip = mvchip;
+
+ mvpwm->membase = devm_ioremap_resource(dev, res);
+ if (IS_ERR(mvpwm->membase))
+ return PTR_ERR(mvpwm->membase);
+
+ if (IS_ERR(mvchip->clk))
+ return PTR_ERR(mvchip->clk);
+
+ mvpwm->clk_rate = clk_get_rate(mvchip->clk);
+ if (!mvpwm->clk_rate) {
+ dev_err(dev, "failed to get clock rate\n");
+ return -EINVAL;
+ }
+
+ mvpwm->chip.dev = dev;
+ mvpwm->chip.ops = &mvebu_pwm_ops;
+ mvpwm->chip.base = mvchip->chip.base;
+ mvpwm->chip.npwm = mvchip->chip.ngpio;
+
+ spin_lock_init(&mvpwm->lock);
+
+ return pwmchip_add(&mvpwm->chip);
+}
+
#ifdef CONFIG_DEBUG_FS
#include <linux/seq_file.h>
@@ -555,6 +842,10 @@ static const struct of_device_id mvebu_gpio_of_match[] = {
.data = (void *) MVEBU_GPIO_SOC_VARIANT_ARMADAXP,
},
{
+ .compatible = "marvell,armada-370-xp-gpio",
+ .data = (void *) MVEBU_GPIO_SOC_VARIANT_ORION,
+ },
+ {
/* sentinel */
},
};
@@ -600,6 +891,9 @@ static int mvebu_gpio_suspend(struct platform_device *pdev, pm_message_t state)
BUG();
}
+ if (IS_ENABLED(CONFIG_PWM))
+ mvebu_pwm_suspend(mvchip);
+
return 0;
}
@@ -643,6 +937,9 @@ static int mvebu_gpio_resume(struct platform_device *pdev)
BUG();
}
+ if (IS_ENABLED(CONFIG_PWM))
+ mvebu_pwm_resume(mvchip);
+
return 0;
}
@@ -654,7 +951,6 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
struct resource *res;
struct irq_chip_generic *gc;
struct irq_chip_type *ct;
- struct clk *clk;
unsigned int ngpios;
bool have_irqs;
int soc_variant;
@@ -688,10 +984,10 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
return id;
}
- clk = devm_clk_get(&pdev->dev, NULL);
+ mvchip->clk = devm_clk_get(&pdev->dev, NULL);
/* Not all SoCs require a clock.*/
- if (!IS_ERR(clk))
- clk_prepare_enable(clk);
+ if (!IS_ERR(mvchip->clk))
+ clk_prepare_enable(mvchip->clk);
mvchip->soc_variant = soc_variant;
mvchip->chip.label = dev_name(&pdev->dev);
@@ -822,6 +1118,10 @@ static int mvebu_gpio_probe(struct platform_device *pdev)
mvchip);
}
+ /* Armada 370/XP has simple PWM support for GPIO lines */
+ if (IS_ENABLED(CONFIG_PWM))
+ return mvebu_pwm_probe(pdev, mvchip, id);
+
return 0;
err_domain:
--
2.10.2
^ permalink raw reply related
* [PATCH v4 0/4] gpio: mvebu: Add PWM fan support
From: Ralph Sennhauser @ 2017-03-27 19:42 UTC (permalink / raw)
To: Linus Walleij, Thierry Reding
Cc: Imre Kaloz, Ralph Sennhauser, Alexandre Courbot, Rob Herring,
Mark Rutland, Jason Cooper, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, Russell King, linux-pwm, linux-gpio,
devicetree, linux-kernel, linux-arm-kernel
Hi everyone
This patch series was originally submitted by Andrew Lunn but got
stalled. I picked up the series and addressed what was discussed for
the earlier submission with some helpful input from Andrew. Hopefully
this time support for the PWM fan as found on Linksys WRT1900AC (Mamba)
will make it in.
Implementing as an MFD was discarded due to backward compatibility. The
original discussion can be read at [1].
This series depends on two cleanup series. The first series [2] ("gpio:
mvebu: preparatory cleanup for pwm-fan support") is in linux
next-20170320. The second one [3] ("gpio: mvebu: use BIT macro instead
of bit shifting") is in linux-20170327.
Ralph
[1] https://patchwork.ozlabs.org/patch/427287/
[2] https://lkml.org/lkml/2017/3/16/62
[3] https://lkml.org/lkml/2017/3/17/493
---
Notes:
About npwm = 1:
The only way I can think of to achieve that requires reading the
GPIO line from the device tree. This would prevent a user to
dynamically choose a line. Which is fine for the fan found on Mamba
but let's take some development board with freely accessible GPIOs
and suddenly we limit the use of this driver. Given the above, npwm
= ngpio with only one usable at a time is a more accurate
description of the situation. The only downside is some "wasted"
space.
About the new compatible string:
Orion was chosen for the SoC variant for the same reason as in
commit 5f79c651e81e ("arm: mvebu: use global interrupts for GPIOs on
Armada XP"). I decided having the first two chips be
"marvell,armada-370-xp-gpio" and keep "marvell,orion-gpio" for the
third one for some SoCs just to be able to require the PWM property
for this compatible string. Therefore the properties remain
optional and if defined for any other than the first two chips it's
an error.
---
Pending:
* npwm = 1? I vote no if that counts. ;) (suggested by Thierry Reding)
* Tested-by: Andrew Lunn for v1 needs renewing
* Needs ACK from Thierry Reding to be merged via linux-gpio tree by Linus
Walleij. (fine with the general approach, requested changes which
should have been taken care of now)
---
Changes v3->v4:
Patch 1/4 gpio: mvebu: Add limited PWM support:
* braces for both branches in if statement if one needs it. (suggested
by Andrew Lunn)
* introduce compatible string marvell,armada-370-xp-gpio (suggest by
Thierry Reding)
* fix mvebu_pwmreg_blink_on_duration -> mvebu_pwmreg_blink_off_duration
for period callculation in mvebu_pwm_get_state()
Patch 4/4 mvebu: wrt1900ac: Use pwm-fan rather than gpio-fan
* Drop flags from pwms for Mamba, as no longer used (suggested by
Andrew Lunn)
* Use again #pwm-cell = 2, the second cell is actually the period.
Changes v2->v3:
Patch 1/4 gpio: mvebu: Add limited PWM support:
* drop pin from mvebu_pwn, can be infered (suggested by Thierry Reding)
* rename pwm to mvpwm so pwm can be used for pwm_device as in the API,
avoids some mental gymnastic.
* drop id from struct mvebu_gpio_chip, select blink counter in
mvebu_pwm_probe for all lines instead. We do not care about the
unused ones. I think a clear improvement in readability.
Makes coming up with a good comment simple as well.
* Switch to new atomic PWM API (suggested by Thierry Reding)
* rename use mvebu_gpioreg_blink_select to
mvebu_gpioreg_blink_counter_select.
* mark *_suspend() / *_resume() as __maybe_unused (suggested by Linus
Walleij)
* document #pwm-cells = 1 (suggested by Thierry Reding)
Patch 2/4 mvebu: xp: Add PWM properties to .dtsi files
* add missing reg-names / #pwm-cell properties to
armada-xp-mv78260.dtsi gpio1 node
* set pwm-cells = 1 (suggested by Thierry Reding)
All:
* always uppercase GPIO/PWM in prose (suggested by Thierry Reding)
Changes v1 -> v2:
Patch 1/4 gpio: mvebu: Add limited PWM support:
* use BIT macro (suggested by Linus Walleij)
* move id from struct mvebu_pwm to struct mvebu_gpio_chip, implement
blink select as if else and comment on the chip id for code clarity
(to accommodate Linus Walleijs request for a code clarification /
comment. If you can word it better I'm all ears.)
* Move function comment mvebu_pwm_probe into the function itself.
---
Andrew Lunn (4):
gpio: mvebu: Add limited PWM support
mvebu: xp: Add PWM properties to .dtsi files
ARM: mvebu: Enable SENSORS_PWM_FAN in defconfig
mvebu: wrt1900ac: Use pwm-fan rather than gpio-fan
.../devicetree/bindings/gpio/gpio-mvebu.txt | 32 ++
MAINTAINERS | 2 +
arch/arm/boot/dts/armada-370.dtsi | 16 +-
arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 8 +-
arch/arm/boot/dts/armada-xp-mv78230.dtsi | 14 +-
arch/arm/boot/dts/armada-xp-mv78260.dtsi | 16 +-
arch/arm/boot/dts/armada-xp-mv78460.dtsi | 16 +-
arch/arm/configs/mvebu_v7_defconfig | 2 +
drivers/gpio/gpio-mvebu.c | 324 ++++++++++++++++++++-
9 files changed, 394 insertions(+), 36 deletions(-)
--
2.10.2
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: update device tree binding for Allwinner PRCM CCUs
From: icenowy-h8G6r0blFSE @ 2017-03-27 19:13 UTC (permalink / raw)
To: Maxime Ripard
Cc: Icenowy Zheng, Rob Herring, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai,
linux-kernel-owner-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170327134719.g6l3hzbba6cxkhb7@lukather>
在 2017-03-27 21:47，Maxime Ripard 写道：
> On Mon, Mar 27, 2017 at 05:11:29PM +0800, Icenowy Zheng wrote:
>>
>> 2017年3月26日 21:10于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
>> >
>> > On Thu, Mar 23, 2017 at 07:17:03AM +0800, Icenowy Zheng wrote:
>> > >
>> > >
>> > > 23.03.2017, 04:09, "Maxime Ripard" <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>:
>> > > > On Wed, Mar 22, 2017 at 02:22:22AM +0800, Icenowy Zheng wrote:
>> > > >> 21.03.2017, 15:41, "Maxime Ripard" <maxime.ripard@free-electrons.com>:
>> > > >> > On Thu, Mar 16, 2017 at 01:28:04AM +0800, Icenowy Zheng wrote:
>> > > >> >> Many Allwinner SoCs after A31 have a CCU in PRCM block.
>> > > >> >>
>> > > >> >> Give the ones on H3 and A64 compatible strings.
>> > > >> >>
>> > > >> >> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>> > > >> >> ---
>> > > >> >> Changes in v2:
>> > > >> >> - Add iosc for R_CCU's on H3/A64. (A31, A23 and A33 seem to have different
>> > > >> >> clock for mux 3 of ar100 clk. Investgations are needed for them.)
>> > > >> >>
>> > > >> >> Documentation/devicetree/bindings/clock/sunxi-ccu.txt | 18 +++++++++++++++++-
>> > > >> >> 1 file changed, 17 insertions(+), 1 deletion(-)
>> > > >> >>
>> > > >> >> diff --git a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
>> > > >> >> index 68512aa398a9..4a4addff595d 100644
>> > > >> >> --- a/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
>> > > >> >> +++ b/Documentation/devicetree/bindings/clock/sunxi-ccu.txt
>> > > >> >> @@ -7,9 +7,11 @@ Required properties :
>> > > >> >> - "allwinner,sun8i-a23-ccu"
>> > > >> >> - "allwinner,sun8i-a33-ccu"
>> > > >> >> - "allwinner,sun8i-h3-ccu"
>> > > >> >> + - "allwinner,sun8i-h3-r-ccu"
>> > > >> >> - "allwinner,sun8i-v3s-ccu"
>> > > >> >> - "allwinner,sun9i-a80-ccu"
>> > > >> >> - "allwinner,sun50i-a64-ccu"
>> > > >> >> + - "allwinner,sun50i-a64-r-ccu"
>> > > >> >> - "allwinner,sun50i-h5-ccu"
>> > > >> >>
>> > > >> >> - reg: Must contain the registers base address and length
>> > > >> >> @@ -20,7 +22,11 @@ Required properties :
>> > > >> >> - #clock-cells : must contain 1
>> > > >> >> - #reset-cells : must contain 1
>> > > >> >>
>> > > >> >> -Example:
>> > > >> >> +For the PRCM CCUs on H3/A64, one more clock is needed:
>> > > >> >> +- "iosc": another frequency oscillator used for CPUS (usually at 32000Hz,
>> > > >> >> + not the same with losc)
>> > > >> >
>> > > >> > This is called the internal oscillator in the datasheet, it would
>> > > >> > probably make more sense to call it that way in the documentation too.
>> > > >> >
>> > > >> > This oscillator seems to be clocked at 16MHz, so we should represent
>> > > >> > it as such.
>> > > >> >
>> > > >> > And I'm wondering, are you *sure* that it's fed directly from the
>> > > >> > internal oscillator, or goes through the registers in the RTC, with
>> > > >> > the 32 divider and 16 prescaler by default that makes it at roughly
>> > > >> > the same rate (31.25kHz).
>> > > >>
>> > > >> In fact I know nothing about it -- I only represented the code in BSP
>> > > >> clock driver.
>> > > >>
>> > > >> The mux value 3 varies from SoC to SoC. For A64/H5 it's 32000,
>> > > >> for A33 it's 667000 (seems to be directly the internal OSC, as the
>> > > >> user manual says the internal OSC is 600~700kHz; but it's named
>> > > >> cpuosc rather than iosc in A33 BSP clock driver); for A80 it's even
>> > > >> PLL_AUDIO.
>> > > >
>> > > > Where are you getting those info from?
>> > > >
>> > > > As far as I know, the A33 PRCM takes the hosc, losc, pll6 and CPU
>> > > > (internal) oscillator:
>> > > > https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw5.c#L508
>> > > >
>> > > > The H3 takes the hosc and losc:
>> > > > https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw7.c#L379
>> > > >
>> > > > The A80 takes the hosc and losc:
>> > > > https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun9iw1.c#L281
>> > > >
>> > > > The A64 takes the hosc, losc, pll-periph0 and the iosc, which indeed
>> > > > seems to be fed from the internal oscillator with the divider in the
>> > > > RTC:
>> > > > https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65-bsp2.0/arch/arm64/boot/dts/sun50iw1p1-clk.dtsi#L19
>> > > > https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65-bsp2.0/drivers/clk/sunxi/clk-sun50iw1.c#L603
>> > >
>> > > But then in sunxi_init_clocks function, the iosc clock is initialized
>> > > as a fixed clock with 32000Hz.
>> > >
>> > > The clock node in BSP device tree have a compatible of
>> > > allwinner,fixed-clock, but not fixed-clock, which makes it not able
>> > > to be really probed.
>> >
>> > That clock is registered:
>> > https://github.com/longsleep/linux-pine64/blob/lichee-dev-v3.10.65-bsp2.0/drivers/clk/sunxi/clk-sun50iw1.c#L1193
>> >
>>
>> Oh yes, but conflicts exist between the iosc registered in
>> clk-sun50iw1.c and described in sun50iw1p1-clk.dtsi . The former is
>> 32000, and the latter is 16000000.
>
> No, it is 16MHz / 32 / 16 = 31.25 kHz
>
>> What should we do then?
>>
>> (Maybe it will be better to temporarily ignore this mux, as it's
>> difficult to finally find out this correct mux...)
>
> That is not an option, we will not be able to fix it afterwards.
>
> What we should do is getting an actual idea of what's going on, and
> not just hacking something together hoping it will work.
>
> You can start by figuring out how the Allwinner clock driver actually
> works and / or by trying the various muxing options with something you
> can measure the frequency with. The i2c or uart coupled with a scope
> or logical analyzer would be a great fit for that.
>
> Using the PRCM timer is another option and you can measure the
> frequency it counts at.
The MUX 3 of AR100 is surely Internal OSC on A64/H3/H5.
Some measurement done with AR100 (all in Hz):
H5 (Orange Pi PC2):
16351952
16347120
16343624
A64 (Pine64+):
11192560
11174128
11174992
H3 (Orange Pi One):
15676016
15625088
15600144
H2+ (Orange Pi Zero):
15907560
15823768
15805144
Seems that on H3/H5 the IOSC is ~16MHz, but on A64 it's... ~12MHz?
(Although the usermanual says 16Mhz in the chapter of RTC)
Maybe some further investigations should be done on more boards.
A fork of ar100-info is at
https://github.com/Icenowy/ar100-info/tree/hz-test ,
which contains IOSC frequency calculation and show in Hz. (and of
course H5/A64 support)
>
> Maxime
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 3/9] Docs: dt: document qcom iommu bindings
From: Rob Herring @ 2017-03-27 19:10 UTC (permalink / raw)
To: Rob Clark
Cc: iommu@lists.linux-foundation.org, linux-arm-msm, Robin Murphy,
Will Deacon, Sricharan, Mark Rutland, Stanimir Varbanov,
devicetree@vger.kernel.org
In-Reply-To: <CAF6AEGsoWPhZ6x-uexGKKUJwtSsn2h+MSg1tjtBdtoPGmARAEg@mail.gmail.com>
On Thu, Mar 23, 2017 at 9:45 PM, Rob Clark <robdclark@gmail.com> wrote:
> On Thu, Mar 23, 2017 at 6:21 PM, Rob Herring <robh@kernel.org> wrote:
>> On Tue, Mar 14, 2017 at 11:18:05AM -0400, Rob Clark wrote:
>>> Cc: devicetree@vger.kernel.org
>>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>>> ---
>>> .../devicetree/bindings/iommu/qcom,iommu.txt | 113 +++++++++++++++++++++
>>> 1 file changed, 113 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/iommu/qcom,iommu.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/iommu/qcom,iommu.txt b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt
>>> new file mode 100644
>>> index 0000000..fd5b7fa
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iommu/qcom,iommu.txt
>>> @@ -0,0 +1,113 @@
>>> +* QCOM IOMMU v1 Implementation
>>> +
>>> +Qualcomm "B" family devices which are not compatible with arm-smmu have
>>> +a similar looking IOMMU but without access to the global register space,
>>> +and optionally requiring additional configuration to route context irqs
>>> +to non-secure vs secure interrupt line.
>>> +
>>> +** Required properties:
>>> +
>>> +- compatible : Should be one of:
>>> +
>>> + "qcom,msm8916-iommu"
>>> +
>>> +- clock-names : Should be a pair of "iface" (required for IOMMUs
>>> + register group access) and "bus" (required for
>>> + the IOMMUs underlying bus access).
>>> +- clocks : Phandles for respective clocks described by
>>> + clock-names.
>>> +- #address-cells : must be 1.
>>> +- #size-cells : must be 1.
>>> +- #iommu-cells : Must be 1.
>>> +- ranges : Base address and size of the iommu context banks.
>>> +- qcom,iommu-secure-id : secure-id.
>>> +
>>> +- List of sub-nodes, one per translation context bank. Each sub-node
>>> + has the following required properties:
>>> +
>>> + - compatible : Should be one of:
>>> + - "qcom,msm-iommu-v1-ns" : non-secure context bank
>>> + - "qcom,msm-iommu-v1-sec" : secure context bank
>>> + - reg : Base address and size of context bank within the iommu
>>> + - interrupts : The context fault irq.
>>> +
>>> +** Optional properties:
>>> +
>>> +- reg : Base address and size of the SMMU local base, should
>>> + be only specified if the iommu requires configuration
>>> + for routing of context bank irq's to secure vs non-
>>> + secure lines. (Ie. if the iommu contains secure
>>> + context banks)
>>> +
>>> +
>>> +** Examples:
>>> +
>>> + apps_iommu: iommu@1e20000 {
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> + #iommu-cells = <1>;
>>> + compatible = "qcom,msm8916-iommu", "qcom,msm-iommu-v1";
>>
>> You didn't document the fallback above. Maybe just drop it if only a few
>> chips have this iommu.
>
> not completely sure I understand what you want..
>
> I think more than a few chips.. I suspect it is more like everything
> after the last "a" family devices (snapdragon 600?) and before 820..
> (well, more or less at least a few years worth of devices, stuff that
> seems likely to be able to run an upstream kernel would be 800, 805,
> 808, 810.. and I guess there are some cut down 6xx and 4xx variants of
> those)
Okay, then you just need to list qcom,msm-iommu-v1 above. Something
like 'followed by "qcom,msm-iommu-v1"' at the end of the list of
compatibles.
Rob
^ permalink raw reply
* Re: [PATCH] clk: stm32h7: Add stm32h743 clock driver
From: Rob Herring @ 2017-03-27 19:04 UTC (permalink / raw)
To: Gabriel Fernandez
Cc: Mark Rutland, devicetree@vger.kernel.org, Daniel Thompson,
Radosław Pietrzyk, Alexandre Torgue, Arnd Bergmann,
Nicolas Pitre, Andrea Merello, Michael Turquette, Olivier Bideau,
Stephen Boyd, Russell King, linux-kernel@vger.kernel.org,
Ludovic Barre, Maxime Coquelin, Amelie Delaunay, Lee Jones,
linux-clk, linux-arm-kernel@lists.infradead.org
In-Reply-To: <dce20025-9f42-e747-e325-e1667504e615@st.com>
On Fri, Mar 24, 2017 at 4:41 AM, Gabriel Fernandez
<gabriel.fernandez@st.com> wrote:
> Hi Rob,
>
> Thanks for reviewing
>
>
>
> On 03/24/2017 03:06 AM, Rob Herring wrote:
>>
>> On Wed, Mar 15, 2017 at 10:23:30AM +0100, gabriel.fernandez@st.com wrote:
>>>
>>> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>>>
>>> This patch enables clocks for STM32H743 boards.
>>>
>>> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
>>> ---
>>> .../devicetree/bindings/clock/st,stm32h7-rcc.txt | 152 ++
>>> drivers/clk/Makefile | 1 +
>>> drivers/clk/clk-stm32h7.c | 1586
>>> ++++++++++++++++++++
>>> include/dt-bindings/clock/stm32h7-clks.h | 165 ++
>>> include/dt-bindings/mfd/stm32h7-rcc.h | 138 ++
>>> 5 files changed, 2042 insertions(+)
>>> create mode 100644
>>> Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
>>> create mode 100644 drivers/clk/clk-stm32h7.c
>>> create mode 100644 include/dt-bindings/clock/stm32h7-clks.h
>>> create mode 100644 include/dt-bindings/mfd/stm32h7-rcc.h
>>>
>>> diff --git a/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
>>> b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
>>> new file mode 100644
>>> index 0000000..9d4b587
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/clock/st,stm32h7-rcc.txt
>>> @@ -0,0 +1,152 @@
>>> +STMicroelectronics STM32H7 Reset and Clock Controller
>>> +=====================================================
>>> +
>>> +The RCC IP is both a reset and a clock controller.
>>> +
>>> +Please refer to clock-bindings.txt for common clock controller binding
>>> usage.
>>> +Please also refer to reset.txt for common reset controller binding
>>> usage.
>>> +
>>> +Required properties:
>>> +- compatible: Should be:
>>> + "st,stm32h743-rcc"
>>> +
>>> +- reg: should be register base and length as documented in the
>>> + datasheet
>>> +
>>> +- #reset-cells: 1, see below
>>> +
>>> +- #clock-cells : from common clock binding; shall be set to 1
>>> +
>>> +- clocks: External oscillator clock phandle
>>> + - high speed external clock signal (HSE)
>>> + - low speed external clock signal (LSE)
>>> + - external I2S clock (I2S_CKIN)
>>> +
>>> +- st,syscfg: phandle for pwrcfg, mandatory to disable/enable backup
>>> domain
>>> + write protection (RTC clock).
>>> +
>>> +- pll x node: Allow to register a pll with specific parameters.
>>> + Please see PLL section below.
>>> +
>>> +Example:
>>> +
>>> + rcc: rcc@58024400 {
>>> + #reset-cells = <1>;
>>> + #clock-cells = <2>
>>> + compatible = "st,stm32h743-rcc", "st,stm32-rcc";
>>> + reg = <0x58024400 0x400>;
>>> + clocks = <&clk_hse>, <&clk_lse>, <&clk_i2s_ckin>;
>>> +
>>> + st,syscfg = <&pwrcfg>;
>>> +
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + vco1@58024430 {
>>> + #clock-cells = <0>;
>>> + compatible = "stm32,pll";
>>> + reg = <0>;
>>
>> The reg addr value and unit address don't match.
>
> ok il will change into
>
> vco1@0 {
> reg = <0>;
>
>
>>
>>> + };
>>> +
>>> + vco2@58024438 {
>>> + #clock-cells = <0>;
>>> + compatible = "stm32,pll";
>>> + reg = <1>;
>>> + st,clock-div = <2>;
>>> + st,clock-mult = <40>;
>>> + st,frac-status = <0>;
>>> + st,frac = <0>;
>>> + st,vcosel = <1>;
>>> + st,pllrge = <2>;
>>> + };
>>> + };
>>> +
>>> +
>>> +STM32H7 PLL
>>> +-----------
>>> +
>>> +The VCO of STM32 PLL could be reprensented like this:
>>> +
>>> + Vref --------- --------
>>> + ---->| / DIVM |---->| x DIVN | ------> VCO
>>> + --------- --------
>>> + ^
>>> + |
>>> + -------
>>> + | FRACN |
>>> + -------
>>> +
>>> +When the PLL is configured in integer mode:
>>> +- VCO = ( Vref / DIVM ) * DIVN
>>> +
>>> +When the PLL is configured in fractional mode:
>>> +- VCO = ( Vref / DIVM ) * ( DIVN + FRACN / 2^13)
>>> +
>>> +
>>> +Required properties for pll node:
>>> +- compatible: Should be:
>>> + "stm32,pll"
>>
>> Only 1 single PLL design for all STM32 chips ever?
>
> no, i can change into "stm32h7,pll"
Actually, should be "st,stm32h7-pll".
>
>>> +
>>> +- #clock-cells: from common clock binding; shall be set to 0
>>> +- reg: Should be the pll number.
>>> +
>>> +Optional properties:
>>> +- st,clock-div: DIVM division factor : <1..63>
>>> +- st,clock-mult: DIVN multiplication factor : <4..512>
>>> +
>>> +- st,frac-status:
>>> + - 0 Pll is configured in integer mode
>>> + - 1 Pll is configure in fractional mode
>>
>> Isn't this implied by the presence of the next property?
>
> do you prefer this ?
>
> - st,frac :
> 0 : pll is configured in integer mode
> 1..8191 : Fractional part of the multiplication factor and pll is configured
> in fractional mode
Why not no st,frac property means integer mode?
Rob
^ permalink raw reply
* Re: [PATCH 2/3] firmware: qcom: scm: Expose download-mode control
From: Rob Herring @ 2017-03-27 18:53 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andy Gross, Stephen Boyd, Mark Rutland, David Brown,
Srinivas Kandagatla, linux-kernel@vger.kernel.org, linux-arm-msm,
open list:ARM/QUALCOMM SUPPORT, devicetree@vger.kernel.org
In-Reply-To: <20170326051328.GD70446@Bjorns-MacBook-Pro-2.local>
On Sun, Mar 26, 2017 at 12:13 AM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Fri 24 Mar 08:06 PDT 2017, Rob Herring wrote:
>
>> On Fri, Mar 17, 2017 at 09:15:22PM -0700, Bjorn Andersson wrote:
> [..]
>> > diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
>> > index 20f26fbce875..8467a181f22c 100644
>> > --- a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
>> > +++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
>> > @@ -18,6 +18,7 @@ Required properties:
>> > * Core, iface, and bus clocks required for "qcom,scm"
>> > - clock-names: Must contain "core" for the core clock, "iface" for the interface
>> > clock and "bus" for the bus clock per the requirements of the compatible.
>> > +- qcom,dload-mode-addr: Specifies the address for the download mode magic (optional)
>>
>> Size? 1 cell, 2 cell(, red cell, blue cell) or follows #addr-cells?
>>
>
> I believe this implementation only applies to the 64-bit systems, but
> it's probably better to make it follow (or at least claim that it
> follows) #address-cells.
Saying it is fixed 2 cells is fine and slightly easier to parse. Just
be explicit.
Rob
^ permalink raw reply
* Re: [PATCH 1/5 v2] iio: xoadc: augment DT bindings a bit
From: Rob Herring @ 2017-03-27 18:51 UTC (permalink / raw)
To: Linus Walleij
Cc: Jonathan Cameron,
linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170327075854.7390-1-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Mon, Mar 27, 2017 at 2:58 AM, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> In order to accommodate in a logical manner for the premuxed channels
> in PM8921 and the similarly addressed channels in later PMICs, we
> need a twocell arrangement with premux and analog mux setting as
> a tuple to uniquely identify a hardware channel.
>
> These bindings are not yet in use, so it should be fine to augment
> them before we actually start using it in drivers and device trees.
>
> This scheme came out of lengthy discussions and reverse-engineering
> and reading of the few information sources we have.
>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Suggested-by: Björn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> ChangeLog v1->v2:
> - Name nodes with <01 02> in a foo@0102 pattern.
> - Minor spelling nits.
> - Delete flimsy leftover docs from an interrim development path.
Okay for the 2 cells.
> ---
> .../bindings/iio/adc/qcom,pm8xxx-xoadc.txt | 104 +++++++++++----------
> 1 file changed, 56 insertions(+), 48 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> index 53cd146d8096..ade545487ce6 100644
> --- a/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,pm8xxx-xoadc.txt
> @@ -19,32 +19,42 @@ Required properties:
> with PMIC variant but is typically something like 2.2 or 1.8V.
>
> The following required properties are standard for IO channels, see
> -iio-bindings.txt for more details:
> +iio-bindings.txt for more details, but noitice that this particular
> +ADC has a special adressing scheme that require two cells for
> +identifying each ADC channel:
>
> -- #address-cells: should be set to <1>
> +- #address-cells: should be set to <2>, the first cell is the
> + prescaler (on PM8058) or premux (on PM8921) with two valid bits
> + so legal values are 0x00, 0x01 or 0x02. The second cell
> + is the main analog mux setting (0x00..0x0f). The combination
> + of prescaler/premux and analog mux uniquely addresses a hardware
> + channel on all systems.
>
> - #size-cells: should be set to <0>
>
> -- #io-channel-cells: should be set to <1>
> +- #io-channel-cells: should be set to <2>, again the cells are
> + precaler or premux followed by the analog muxing line.
>
> - interrupts: should refer to the parent PMIC interrupt controller
> and reference the proper ADC interrupt.
>
> Required subnodes:
>
> -The ADC channels are configured as subnodes of the ADC. Since some of
> -them are used for calibrating the ADC, these nodes are compulsory:
> +The ADC channels are configured as subnodes of the ADC.
>
> -adc-channel@c {
> - reg = <0x0c>;
> +Since some of them are used for calibrating the ADC, these nodes are
> +compulsory:
> +
> +adc-channel@000c {
Leading 0s on unit addresses is wrong.
> + reg = <0x00 0x0c>;
> };
>
> -adc-channel@d {
> - reg = <0x0d>;
> +adc-channel@000d {
> + reg = <0x00 0x0d>;
> };
>
> -adc-channel@f {
> - reg = <0x0f>;
> +adc-channel@000f {
> + reg = <0x00 0x0f>;
> };
>
> These three nodes are used for absolute and ratiometric calibration
> @@ -52,13 +62,13 @@ and only need to have these reg values: they are by hardware definition
> 1:1 ratio converters that sample 625, 1250 and 0 milliV and create
> an interpolation calibration for all other ADCs.
>
> -Optional subnodes: any channels other than channel 0x0c, 0x0d and
> -0x0f are optional.
> +Optional subnodes: any channels other than channels [0x00 0x0c],
> +[0x00 0x0d] and [0x00 0x0f] are optional.
>
> Required channel node properties:
>
> - reg: should contain the hardware channel number in the range
> - 0 .. 0x0f (4 bits). The hardware only supports 16 channels.
> + 0 .. 0xff (8 bits).
>
> Optional channel node properties:
>
> @@ -94,56 +104,54 @@ Example:
> xoadc: xoadc@197 {
> compatible = "qcom,pm8058-adc";
> reg = <0x197>;
> - interrupt-parent = <&pm8058>;
> - interrupts = <76 1>;
> - #address-cells = <1>;
> + interrupts-extended = <&pm8058 76 IRQ_TYPE_EDGE_RISING>;
> + #address-cells = <2>;
> #size-cells = <0>;
> - #io-channel-cells = <1>;
> + #io-channel-cells = <2>;
>
> - vcoin: adc-channel@0 {
> - reg = <0x00>;
> + vcoin: adc-channel@0000 {
> + reg = <0x00 0x00>;
> };
> - vbat: adc-channel@1 {
> - reg = <0x01>;
> + vbat: adc-channel@0001 {
> + reg = <0x00 0x01>;
> };
> - dcin: adc-channel@2 {
> - reg = <0x02>;
> + dcin: adc-channel@0002 {
> + reg = <0x00 0x02>;
> };
> - ichg: adc-channel@3 {
> - reg = <0x03>;
> + ichg: adc-channel@0030 {
> + reg = <0x00 0x03>;
> };
> - vph_pwr: adc-channel@4 {
> - reg = <0x04>;
> + vph_pwr: adc-channel@0004 {
> + reg = <0x00 0x04>;
> };
> - usb_vbus: adc-channel@a {
> - reg = <0x0a>;
> + usb_vbus: adc-channel@000a {
> + reg = <0x00 0x0a>;
> };
> - die_temp: adc-channel@b {
> - reg = <0x0b>;
> + die_temp: adc-channel@000b {
> + reg = <0x00 0x0b>;
> };
> - ref_625mv: adc-channel@c {
> - reg = <0x0c>;
> + ref_625mv: adc-channel@000c {
> + reg = <0x00 0x0c>;
> };
> - ref_1250mv: adc-channel@d {
> - reg = <0x0d>;
> + ref_1250mv: adc-channel@000d {
> + reg = <0x00 0x0d>;
> };
> - ref_325mv: adc-channel@e {
> - reg = <0x0e>;
> + ref_325mv: adc-channel@000e {
> + reg = <0x00 0x0e>;
> };
> - ref_muxoff: adc-channel@f {
> - reg = <0x0f>;
> + ref_muxoff: adc-channel@000f {
> + reg = <0x00 0x0f>;
> };
> };
>
> -
> /* IIO client node */
> iio-hwmon {
> compatible = "iio-hwmon";
> - io-channels = <&xoadc 0x01>, /* Battery */
> - <&xoadc 0x02>, /* DC in (charger) */
> - <&xoadc 0x04>, /* VPH the main system voltage */
> - <&xoadc 0x0b>, /* Die temperature */
> - <&xoadc 0x0c>, /* Reference voltage 1.25V */
> - <&xoadc 0x0d>, /* Reference voltage 0.625V */
> - <&xoadc 0x0e>; /* Reference voltage 0.325V */
> + io-channels = <&xoadc 0x00 0x01>, /* Battery */
> + <&xoadc 0x00 0x02>, /* DC in (charger) */
> + <&xoadc 0x00 0x04>, /* VPH the main system voltage */
> + <&xoadc 0x00 0x0b>, /* Die temperature */
> + <&xoadc 0x00 0x0c>, /* Reference voltage 1.25V */
> + <&xoadc 0x00 0x0d>, /* Reference voltage 0.625V */
> + <&xoadc 0x00 0x0e>; /* Reference voltage 0.325V */
> };
> --
> 2.9.3
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] ASoC: Add support for Maxim Integrated MAX98927 Amplifier
From: Rob Herring @ 2017-03-27 18:46 UTC (permalink / raw)
To: Ryan Lee
Cc: Mark Rutland, Linux-ALSA, Kuninori Morimoto, Liam Girdwood,
Takashi Iwai, Srinivas Kandagatla, romain.perier, bardliao,
Lars-Peter Clausen, Axel Lin, Paul Handrigan,
devicetree@vger.kernel.org, Arnd Bergmann, nh6z, Mark Brown,
Charles Keepax, Dylan Reid, oder_chiou, KCHSU0,
linux-kernel@vger.kernel.org, Petr Kulhavy
In-Reply-To: <1490592778-30841-1-git-send-email-ryans.lee@maximintegrated.com>
On Mon, Mar 27, 2017 at 12:32 AM, Ryan Lee
<ryans.lee@maximintegrated.com> wrote:
> Signed-off-by: Ryan Lee <ryans.lee@maximintegrated.com>
> ---
> v2: Removed local register read/write function to avoid duplication of ASoC core function.
And what about my comments in v1?
^ permalink raw reply
* Re: [PATCH v2 1/2] soc: qcom: Add device tree binding for GLINK RPM
From: Rob Herring @ 2017-03-27 18:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andy Gross, Mark Rutland, Ohad Ben-Cohen, linux-arm-msm,
open list:ARM/QUALCOMM SUPPORT, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
open list:REMOTE PROCESSOR (REMOTEPROC) SUBSYSTEM
In-Reply-To: <20170326043159.GA70446@Bjorns-MacBook-Pro-2.local>
On Sat, Mar 25, 2017 at 11:31 PM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> On Fri 24 Mar 09:07 PDT 2017, Rob Herring wrote:
>
>> On Mon, Mar 20, 2017 at 02:09:55PM -0700, Bjorn Andersson wrote:
>> > Add device tree binding documentation for the Qualcomm GLINK RPM, used
>> > for communication with the Resource Power Management subsystem in
>> > various Qualcomm SoCs.
>> >
>> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
>> > ---
>> >
>> > Changes since v1:
>> > - None
>> >
>> > .../devicetree/bindings/soc/qcom/qcom,glink.txt | 73 ++++++++++++++++++++++
>> > 1 file changed, 73 insertions(+)
>> > create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
>> > new file mode 100644
>> > index 000000000000..da92c4f787f3
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt
>> > @@ -0,0 +1,73 @@
>> > +Qualcomm RPM GLINK binding
>> > +
>> > +This binding describes the Qualcomm RPM GLINK, a fifo based mechanism for
>> > +communication with the Resource Power Management system on various Qualcomm
>> > +platforms.
>> > +
>> > +- compatible:
>> > + Usage: required
>> > + Value type: <stringlist>
>> > + Definition: must be "qcom,glink-rpm"
>>
>> SoC specific compatibles please.
>>
>
> In addition to the generic qcom,glink-rpm I presume?
Right.
>
>> > +
>> > +- interrupts:
>> > + Usage: required
>> > + Value type: <prop-encoded-array>
>> > + Definition: should specify the IRQ used by the remote processor to
>> > + signal this processor about communication related events
>> > +
>> > +- qcom,rpm-msg-ram:
>> > + Usage: required
>> > + Value type: <prop-encoded-array>
>> > + Definition: handle to RPM message memory resource
>> > +
>> > +- qcom,ipc:
>> > + Usage: required
>> > + Value type: <prop-encoded-array>
>> > + Definition: three entries specifying the outgoing ipc bit used for
>> > + signaling the remote processor:
>> > + - phandle to a syscon node representing the apcs registers
>> > + - u32 representing offset to the register within the syscon
>> > + - u32 representing the ipc bit within the register
>> > +
>> > += GLINK DEVICES
>> > +Each subnode of the GLINK node represent function tied to a virtual
>> > +communication channel. The name of the nodes are not important. The properties
>> > +of these nodes are defined by the individual bindings for the specific function
>> > +- but must contain the following property:
>> > +
>> > +- qcom,glink-channels:
>> > + Usage: required
>> > + Value type: <stringlist>
>> > + Definition: a list of channels tied to this function, used for matching
>> > + the function to a set of virtual channels
>> > +
>> > += EXAMPLE
>> > +The following example represents the GLINK RPM node on a MSM8996 device, with
>> > +the function for the "rpm_request" channel defined, which is used for
>> > +regualtors and root clocks.
>> > +
>> > + apcs: syscon@f9011000 {
>> > + compatible = "syscon";
>>
>> syscon alone is not valid.
>>
>
> This is equivalent to how we have done this on all previous platforms.
Then they are wrong...
> On previous platforms this generally maps to one of the "Krait Processor
> SubSystem" blocks, so I'm quite worried with coming up with a compatible
> for this block will not be compatible with any future description of
> this block.
Perhaps why we should get rid of syscon. It's not supposed to be a "I
don't know how to define a binding, so just make all registers
available for now".
I don't really see how a compatible string alone would create problems
to extend the binding if you need to later. Even if it did, you can
always rev compatible strings.
>> > + reg = <0xf9011000 0x1000>;
>> > + };
>> > +
>> > + rpm_msg_ram: memory@68000 {
>> > + compatible = "qcom,rpm-msg-ram";
>>
>> Is this more than just mmio-sram?
>>
>> Or with a fixed use could be part of another node?
>>
>
> It represents one of the RAM modules of one of the other ARM cores in
> the SoC, used for shared memory communication with this ARM core. So the
> hardware is essentially mmio-sram. But it has none of the properties
> that a mmio-sram seem to have.
Properties such as?
>
> The reason I did not put it in the rpm-glink node is that in previous
> Qualcomm platforms we have exactly the same system design, but the data
> structure of the RAM was different, so it felt natural to just keep the
> same description of the hardware.
>
>> > + reg = <0x68000 0x6000>;
>> > + };
>> > +
>> > + rpm-glink {
>> > + compatible = "qcom,glink-rpm";
>> > +
>> > + interrupts = <GIC_SPI 168 IRQ_TYPE_EDGE_RISING>;
>> > +
>> > + qcom,rpm-msg-ram = <&rpm_msg_ram>;
>> > + qcom,ipc = <&apcs 0x10 0>;
>> > +
>> > + rpm-requests {
>> > + compatible = "qcom,rpm-msm8996";
>> > + qcom,glink-channels = "rpm_requests";
>> > +
>> > + ...
>> > + };
>> > + };
>
> Regards,
> Bjorn
^ permalink raw reply
* Re: [PATCH v7 1/2] dt-bindings: Add GPCv2 power gating driver
From: Andrey Smirnov @ 2017-03-27 18:42 UTC (permalink / raw)
To: Dong Aisheng
Cc: Mark Rutland, devicetree, linux-kernel, Rob Herring,
Fabio Estevam, Andrey Yurovsky, Shawn Guo, linux-arm-kernel,
Lucas Stach
In-Reply-To: <20170324063216.GC12604@b29396-OptiPlex-7040>
On Thu, Mar 23, 2017 at 11:32 PM, Dong Aisheng <dongas86@gmail.com> wrote:
> On Tue, Mar 21, 2017 at 07:50:03AM -0700, Andrey Smirnov wrote:
>> Add DT bindings for power domain driver for GPCv2 IP block found in
>> i.MX7 SoCs.
>>
>> Cc: yurovsky@gmail.com
>> Cc: Lucas Stach <l.stach@pengutronix.de>
>> Cc: Rob Herring <robh+dt@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Fabio Estevam <fabio.estevam@nxp.com>
>> Cc: Dong Aisheng <dongas86@gmail.com>
>> Cc: devicetree@vger.kernel.org
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Acked-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
>> ---
>> .../devicetree/bindings/power/fsl,imx-gpcv2.txt | 71 ++++++++++++++++++++++
>> include/dt-bindings/power/imx7-power.h | 18 ++++++
>> 2 files changed, 89 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
>> create mode 100644 include/dt-bindings/power/imx7-power.h
>>
>> diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
>> new file mode 100644
>> index 0000000..02f45c6
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
>> @@ -0,0 +1,71 @@
>> +Freescale i.MX General Power Controller v2
>> +==========================================
>> +
>> +The i.MX7S/D General Power Control (GPC) block contains Power Gating
>> +Control (PGC) for various power domains.
>> +
>> +Required properties:
>> +
>> +- compatible: Should be "fsl,imx7d-gpc"
>> +
>> +- reg: should be register base and length as documented in the
>> + datasheet
>> +
>> +- interrupts: Should contain GPC interrupt request 1
>> +
>> +Power domains contained within GPC node are generic power domain
>> +providers, documented in
>> +Documentation/devicetree/bindings/power/power_domain.txt, which are
>> +described as subnodes of the power gating controller 'pgc' node,
>> +which, in turn, is expected to contain the following:
>> +
>> +Required properties:
>> +
>> +- reg: Power domain index. Valid values are defined in
>> + include/dt-bindings/power/imx7-power.h
>> +
>> +- #power-domain-cells: Should be 0
>> +
>> +Optional properties:
>> +
>> +- power-supply: Power supply used to power the domain
>> +
>> +Example:
>> +
>> + gpc: gpc@303a0000 {
>> + compatible = "fsl,imx7d-gpc";
>> + reg = <0x303a0000 0x1000>;
>> + interrupt-controller;
>> + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
>> + #interrupt-cells = <3>;
>> + interrupt-parent = <&intc>;
>> +
>> + pgc {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + pgc_pcie_phy: power-domain@3 {
>> + #power-domain-cells = <0>;
>> +
>> + reg = <IMX7_POWER_DOMAIN_PCIE_PHY>;
>> + power-supply = <®_1p0d>;
>> + };
>> + };
>> + };
>> +
>> +
>> +Specifying power domain for IP modules
>> +======================================
>> +
>> +IP cores belonging to a power domain should contain a 'power-domains'
>> +property that is a phandle for PGC node representing the domain.
>> +
>> +Example of a device that is part of the PCIE_PHY power domain:
>> +
>> + pcie: pcie@33800000 {
>> + reg = <0x33800000 0x4000>,
>> + <0x4ff00000 0x80000>;
>> + /* ... */
>> + power-domains = <&pgc_pcie_phy>;
>> + /* ... */
>> + };
>> diff --git a/include/dt-bindings/power/imx7-power.h b/include/dt-bindings/power/imx7-power.h
>> new file mode 100644
>> index 0000000..eb70023
>> --- /dev/null
>> +++ b/include/dt-bindings/power/imx7-power.h
>> @@ -0,0 +1,18 @@
>> +/*
>> + * Copyright (C) 2017 Impinj
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#ifndef __DT_BINDINGS_IMX7_POWER_H__
>> +#define __DT_BINDINGS_IMX7_POWER_H__
>> +
>> +#define IMX7_POWER_DOMAIN_USB_HSIC_PHY 0
>> +#define IMX7_POWER_DOMAIN_USB_OTG2_PHY 1
>> +#define IMX7_POWER_DOMAIN_USB_OTG1_PHY 2
>> +#define IMX7_POWER_DOMAIN_PCIE_PHY 3
>> +#define IMX7_POWER_DOMAIN_MIPI_PHY 4
>
> Nitpick: Probably better to define according to the reference manual
> defined order.
>
> 0x800 ~ 0x83F : PGC for A7 core0
> 0x840 ~ 0x87F: PGC for A7 core1
> 0x880 ~ 0x8BF: PGC for A7 SCU
> 0xA00 ~ 0xA3F: PGC for fastmix/megamix
> 0xC00 ~ 0xC3F: PGC for MIPI PHY
> 0xC40 ~ 0xC7F: PGC for PCIE_PHY
> 0xC80 ~ 0xCBF: Reserved
> 0xCC0 ~ 0xCFF: Reserved
> 0xD00 ~ 0xD3F: PGC for USB HSIC PHY
>
> You can drop A7 core/scu/fastmix/megamix as well.
>
Sure, will do.
Thanks,
Andrey Smirnov
^ permalink raw reply
* Re: [PATCHv3 1/2] mfd: cpcap: Add missing include dependencies
From: Jacek Anaszewski @ 2017-03-27 18:38 UTC (permalink / raw)
To: Lee Jones
Cc: Sebastian Reichel, Richard Purdie, Pavel Machek, Tony Lindgren,
Rob Herring, Mark Rutland, linux-leds, devicetree, linux-kernel
In-Reply-To: <20170327142608.qcobnqrvyu7u4ybz@dell>
On 03/27/2017 04:26 PM, Lee Jones wrote:
> On Fri, 24 Mar 2017, Jacek Anaszewski wrote:
>> On 03/24/2017 09:47 AM, Sebastian Reichel wrote:
>>> This fixes compilation for files, that try to include the
>>> cpcap header in alphabetically sorted #include lists.
>>>
>>> Acked-by: Pavel Machek <pavel@ucw.cz>
>>> Acked-by: Tony Lindgren <tony@atomide.com>
>>> Signed-off-by: Sebastian Reichel <sre@kernel.org>
>>> ---
>>> Changes since PATCHv2:
>>> - Add Acked-by from Tony & Pavel
>>> ---
>>> include/linux/mfd/motorola-cpcap.h | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/include/linux/mfd/motorola-cpcap.h b/include/linux/mfd/motorola-cpcap.h
>>> index 793aa695faa0..aefc49cb7ba9 100644
>>> --- a/include/linux/mfd/motorola-cpcap.h
>>> +++ b/include/linux/mfd/motorola-cpcap.h
>>> @@ -14,6 +14,9 @@
>>> * published by the Free Software Foundation.
>>> */
>>>
>>> +#include <linux/device.h>
>>> +#include <linux/regmap.h>
>>> +
>>> #define CPCAP_VENDOR_ST 0
>>> #define CPCAP_VENDOR_TI 1
>>
>> Both patches applied to the for-next branch of linux-leds.git, thanks.
>
> Que?
Ah, sorry, for some reason I silently assumed that Tony gave ack on
your behalf :-) Probably due to lack of your activity in the subject
and Tony's understanding thereof [0].
Can I have your ack for this patch going through LED tree then?
[0] https://lkml.org/lkml/2017/3/23/413
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH] dt-bindings: arm,nvic: Binding for ARM NVIC interrupt controller on Cortex-M
From: Kumar Gala @ 2017-03-27 18:09 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: Kumar Gala, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
Signed-off-by: Kumar Gala <kumar.gala-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
Note: This is a new binding and not used by the linux kernel code right now for
the nvic. The intent would be to support both the current 'arm,armv7m-nvic'
compatible and this binding in the code in the future. The 'arm,armv7m-nvic'
doesnt have any binding spec covering it today.
.../bindings/interrupt-controller/arm,nvic.txt | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/arm,nvic.txt
diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,nvic.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,nvic.txt
new file mode 100644
index 0000000..60ee89c
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,nvic.txt
@@ -0,0 +1,37 @@
+* ARM Nested Vector Interrupt Controller (NVIC)
+
+The NVIC provides an interrupt controller that is tightly coupled to
+Cortex-M based processor cores. The NVIC implemented on different SoCs
+vary in the number of interrupts and priority bits per interrupt.
+
+Main node required properties:
+
+- compatible : should be one of:
+ "arm,v6m-nvic"
+ "arm,v7m-nvic"
+ "arm,v8m-nvic"
+ "arm,nvic"
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+ interrupt source. The type shall be a <u32> and the value shall be 2.
+
+ The 1st cell contains the interrupt number for the interrupt type.
+
+ The 2nd cell is the priority of the interrupt.
+
+- reg : Specifies base physical address(s) and size of the NVIC registers.
+ This is at a fixed address (0xe000e100) and size (0xc00).
+
+- arm,num-irq-priority-bits: The number of priority bits implemented by the
+ given SoC
+
+Example:
+
+ intc: interrupt-controller@e000e100 {
+ compatible = "arm,nvic";
+ #interrupt-cells = <2>;
+ #address-cells = <1>;
+ interrupt-controller;
+ reg = <0xe000e100 0xc00>;
+ arm,num-irq-priority-bits = <4>;
+ };
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2 1/2] dt-bindings: ata: add DT bindings for ahci-dm816 SATA controller
From: Tejun Heo @ 2017-03-27 18:06 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Rob Herring, Mark Rutland, Neil Armstrong, Michael Turquette,
Kevin Hilman, Patrick Titiano, Tony Lindgren, Sergei Shtylyov,
linux-ide, devicetree, linux-kernel
In-Reply-To: <1489489491-14195-2-git-send-email-bgolaszewski@baylibre.com>
On Tue, Mar 14, 2017 at 12:04:50PM +0100, Bartosz Golaszewski wrote:
> Add DT bindings for the onboard SATA controller present on the DM816x
> SoCs.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Applied to libata/for-4.12.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] ARM: dts: am335x-baltos: add LED support
From: Tony Lindgren @ 2017-03-27 17:45 UTC (permalink / raw)
To: yegorslists-gM/Ye1E23mwN+BqQ9rBEUg
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20170327173852.GN10760-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [170327 10:42]:
> * yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> [170324 08:17]:
> > From: Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
> >
> > All three devices provide GPIO based LEDs named power,
> > wlan and app.
> >
> > Place the same definition in all three DTS files, as
> > there are other devices (not currently upstreamed), that
> > use am335x-baltos.dtsi but use different GPIOs for these
> > LEDs.
>
> How about just add am335x-baltos-leds.dtsi and include
> it for the three boards to avoid duplication?
Or maybe even am335x-baltos-xyz-devices.dtsi or something if
you have more devices that are shared across some group
of baltos devices.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: am335x-baltos: add LED support
From: Tony Lindgren @ 2017-03-27 17:38 UTC (permalink / raw)
To: yegorslists-gM/Ye1E23mwN+BqQ9rBEUg
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <1490368503-4798-1-git-send-email-yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
* yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> [170324 08:17]:
> From: Yegor Yefremov <yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
>
> All three devices provide GPIO based LEDs named power,
> wlan and app.
>
> Place the same definition in all three DTS files, as
> there are other devices (not currently upstreamed), that
> use am335x-baltos.dtsi but use different GPIOs for these
> LEDs.
How about just add am335x-baltos-leds.dtsi and include
it for the three boards to avoid duplication?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: am335x-evmsk: adjust mmc2 param to allow suspend
From: Tony Lindgren @ 2017-03-27 17:12 UTC (permalink / raw)
To: Reizer, Eyal
Cc: Benoît Cousson, Rob Herring,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <8665E2433BC68541A24DFFCA87B70F5B363623DC-1tpBd5JUCm6IQmiDNMet8wC/G2K4zDHf@public.gmane.org>
* Reizer, Eyal <eyalr-l0cyMroinI0@public.gmane.org> [170326 01:55]:
> mmc2 used for wl12xx was missing the keep-power-in suspend
> parameter. As a result the board couldn't reach suspend state.
OK applying into omap-for-v4.11/fixes thanks.
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox