* [PATCH v5 2/5] PM / Domains: Do not check if simple providers have phandle cells
From: Dave Gerlach @ 2017-04-04 2:47 UTC (permalink / raw)
To: Ulf Hansson, Rafael J . Wysocki, Kevin Hilman, Santosh Shilimkar,
Rob Herring, Arnd Bergmann
Cc: linux-arm-kernel, linux-kernel, linux-pm, devicetree,
Nishanth Menon, Dave Gerlach, Keerthy, Russell King, Tero Kristo,
Sudeep Holla, Olof Johansson
In-Reply-To: <20170404024732.32699-1-d-gerlach@ti.com>
There is no reason that a platform genpd driver registered using
of_genpd_add_provider_simple needs to be constrained to having no cells
in the "power-domains" phandle. Currently the genpd framework will fail
if any arguments are passed with for a simple provider but the framework
does not actually care, so remove the check for phandle argument count.
This will allow greater flexibility for genpd providers to use their own
arguments that are passed in the phandle and interpret them however they
see fit.
Acked-by: Kevin Hilman <khilman@baylibre.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
drivers/base/power/domain.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index e697dec9d25b..8e0550c27394 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -1622,8 +1622,6 @@ static struct generic_pm_domain *genpd_xlate_simple(
struct of_phandle_args *genpdspec,
void *data)
{
- if (genpdspec->args_count != 0)
- return ERR_PTR(-EINVAL);
return data;
}
--
2.11.0
^ permalink raw reply related
* [PATCH v5 1/5] PM / Domains: Add generic data pointer to genpd data struct
From: Dave Gerlach @ 2017-04-04 2:47 UTC (permalink / raw)
To: Ulf Hansson, Rafael J . Wysocki, Kevin Hilman, Santosh Shilimkar,
Rob Herring, Arnd Bergmann
Cc: Nishanth Menon, devicetree, Dave Gerlach, Keerthy, linux-pm,
linux-kernel, Tero Kristo, Russell King, Sudeep Holla,
Olof Johansson, linux-arm-kernel
In-Reply-To: <20170404024732.32699-1-d-gerlach@ti.com>
Add a void *data pointer to struct generic_pm_domain_data. Because this
exists for each device associated with a genpd it will allow us to
assign per-device data if needed on a platform for control of that
specific device.
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
include/linux/pm_domain.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 5339ed5bd6f9..b213d22daefd 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -117,6 +117,7 @@ struct generic_pm_domain_data {
struct pm_domain_data base;
struct gpd_timing_data td;
struct notifier_block nb;
+ void *data;
};
#ifdef CONFIG_PM_GENERIC_DOMAINS
--
2.11.0
^ permalink raw reply related
* [PATCH v5 0/5] ARM: K2G: Add support for TI-SCI Generic PM Domains
From: Dave Gerlach @ 2017-04-04 2:47 UTC (permalink / raw)
To: Ulf Hansson, Rafael J . Wysocki, Kevin Hilman, Santosh Shilimkar,
Rob Herring, Arnd Bergmann
Cc: Nishanth Menon, devicetree, Dave Gerlach, Keerthy, linux-pm,
linux-kernel, Tero Kristo, Russell King, Sudeep Holla,
Olof Johansson, linux-arm-kernel
Hi,
This is v5 of the series to add support for TI-SCI Generic PM Domains with
all ACKs in place and ready for Santosh to merge.
Previous versions can be found here:
v4: https://www.spinics.net/lists/arm-kernel/msg566778.html
v3: https://www.spinics.net/lists/kernel/msg2413975.html
v2: https://www.spinics.net/lists/kernel/msg2364612.html
v1: http://www.spinics.net/lists/arm-kernel/msg525204.html
Mostly just a resend of v4 with all ACKs and Reviewed-by tags in place with
the exception of a dropped sentence in patch 3 to avoid referencing Linux
specific behavior in the DT binding doc. Otherwise everything else is
unmodified.
Ulf and Santosh, I kept your Reviewed-by and Acked-by tags in Patch 3 because
the change was so minor and I still wanted to give you credit for taking the
time to review the patch, any issues and I'd be happy to change that.
Regards,
Dave
Dave Gerlach (5):
PM / Domains: Add generic data pointer to genpd data struct
PM / Domains: Do not check if simple providers have phandle cells
dt-bindings: Add TI SCI PM Domains
soc: ti: Add ti_sci_pm_domains driver
ARM: keystone: Drop PM domain support for k2g
.../devicetree/bindings/soc/ti/sci-pm-domain.txt | 57 ++++++
MAINTAINERS | 3 +
arch/arm/mach-keystone/Kconfig | 1 +
arch/arm/mach-keystone/pm_domain.c | 4 +-
drivers/base/power/domain.c | 2 -
drivers/soc/ti/Kconfig | 12 ++
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/ti_sci_pm_domains.c | 202 +++++++++++++++++++++
include/dt-bindings/genpd/k2g.h | 90 +++++++++
include/linux/pm_domain.h | 1 +
10 files changed, 370 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
create mode 100644 drivers/soc/ti/ti_sci_pm_domains.c
create mode 100644 include/dt-bindings/genpd/k2g.h
--
2.11.0
^ permalink raw reply
* [PATCH] arm64: dts: uniphier: add cdns, phy-dll-delay-sdclk(-hsmmc) for eMMC
From: Masahiro Yamada @ 2017-04-04 2:04 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Catalin Marinas, Will Deacon,
linux-kernel, Masahiro Yamada, Rob Herring
Adjust the PHY parameters for more stable access to the eMMC device.
Set the SDCLK output delay value to 21 (including HS200/400 modes).
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi | 2 ++
arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
index 42f1803..25a525c 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi
@@ -313,6 +313,8 @@
cdns,phy-input-delay-legacy = <4>;
cdns,phy-input-delay-mmc-highspeed = <2>;
cdns,phy-input-delay-mmc-ddr = <3>;
+ cdns,phy-dll-delay-sdclk = <21>;
+ cdns,phy-dll-delay-sdclk-hsmmc = <21>;
};
usb0: usb@5a800100 {
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
index e4499ff..c85e6e2 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20.dtsi
@@ -387,6 +387,8 @@
cdns,phy-input-delay-legacy = <4>;
cdns,phy-input-delay-mmc-highspeed = <2>;
cdns,phy-input-delay-mmc-ddr = <3>;
+ cdns,phy-dll-delay-sdclk = <21>;
+ cdns,phy-dll-delay-sdclk-hsmmc = <21>;
};
soc-glue@5f800000 {
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Rob Herring @ 2017-04-04 2:00 UTC (permalink / raw)
To: Guillaume Tucker
Cc: Mark Rutland, Sjoerd Simons, Enric Balletbo i Serra, John Reitan,
Wookey, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <db45d0d68957d699f13a0d92f4f84d8ebfd0270e.1491118230.git.guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
On Sun, Apr 02, 2017 at 08:59:44AM +0100, Guillaume Tucker wrote:
> The ARM Mali Midgard GPU family is present in a number of SoCs
> from many different vendors such as Samsung Exynos and Rockchip.
>
> Import the device tree bindings documentation from the r16p0
> release of the Mali Midgard GPU kernel driver:
>
> https://developer.arm.com/-/media/Files/downloads/mali-drivers/kernel/mali-midgard-gpu/TX011-SW-99002-r16p0-00rel0.tgz
>
> The following optional bindings have been omitted in this initial
> version as they are only used in very specific cases:
>
> * snoop_enable_smc
> * snoop_disable_smc
> * jm_config
> * power_model
> * system-coherency
> * ipa-model
>
> The example has been simplified accordingly.
>
> The compatible string definition has been limited to
> "arm,mali-midgard" to avoid checkpatch.pl warnings and to match
> what the driver actually expects (as of r16p0 out-of-tree).
>
> CC: John Reitan <john.reitan-5wv7dgnIgG8@public.gmane.org>
> Signed-off-by: Guillaume Tucker <guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
> ---
> .../devicetree/bindings/gpu/arm,mali-midgard.txt | 53 ++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> new file mode 100644
> index 000000000000..da8fc6d21bbf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
> @@ -0,0 +1,53 @@
> +#
> +# (C) COPYRIGHT 2013-2016 ARM Limited.
> +# Copyright (C) 2017 Collabora Ltd
> +#
> +# This program is free software and is provided to you under the terms of the
> +# GNU General Public License version 2 as published by the Free Software
> +# Foundation, and any use by you of this program is subject to the terms
> +# of such GNU licence.
> +#
> +
> +
> +ARM Mali Midgard GPU
> +====================
> +
> +Required properties:
> +
> +- compatible : Should be "arm,mali-midgard".
As Neil said...
> +- reg : Physical base address of the device and length of the register area.
> +- interrupts : Contains the three IRQ lines required by Mali Midgard devices.
> +- interrupt-names : Contains the names of IRQ resources in the order they were
> + provided in the interrupts property. Must contain: "JOB, "MMU", "GPU".
> +
> +Optional:
> +
> +- clocks : Phandle to clock for the Mali Midgard device.
> +- clock-names : Shall be "clk_mali".
"clk_" is redundant. Actually, if there is only 1 clock, then just drop
names. But there's not at least a core and bus clock?
> +- mali-supply : Phandle to regulator for the Mali device. Refer to
> + Documentation/devicetree/bindings/regulator/regulator.txt for details.
> +- operating-points : Refer to Documentation/devicetree/bindings/power/opp.txt
> + for details.
Is this going to be sufficient vs. operating-points-v2? Or should it be
a power domain with OPPs?
> +
> +Example for a Mali-T602:
> +
> +gpu@0xfc010000 {
Drop the '0x'.
> + compatible = "arm,mali-midgard";
> + reg = <0xfc010000 0x4000>;
> + interrupts = <0 36 4>, <0 37 4>, <0 38 4>;
> + interrupt-names = "JOB", "MMU", "GPU";
> +
> + clocks = <&pclk_mali>;
> + clock-names = "clk_mali";
> + mali-supply = <&vdd_mali>;
> + operating-points = <
> + /* KHz uV */
> + 533000 1250000,
> + 450000 1150000,
> + 400000 1125000,
> + 350000 1075000,
> + 266000 1025000,
> + 160000 925000,
> + 100000 912500,
> + >;
> +};
> --
> 2.11.0
>
--
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: [RFC PATCH 4/5] dt-bindings: soc/fsl: Update reserved memory binding for QBMan
From: Scott Wood @ 2017-04-04 0:32 UTC (permalink / raw)
To: Roy Pledge, Rob Herring
Cc: robin.murphy-5wv7dgnIgG8@public.gmane.org,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Madalin-Cristian Bucur
In-Reply-To: <VI1PR04MB32166AA6361CD6F24DBC3AAF86080-mr6QIVyDiCHPlBEOArXH089NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
On Mon, 2017-04-03 at 19:49 +0000, Roy Pledge wrote:
> On 4/3/2017 11:42 AM, Rob Herring wrote:
> >
> > On Wed, Mar 29, 2017 at 05:13:56PM -0400, Roy Pledge wrote:
> > >
> > > Updates the QMan and BMan device tree bindings for reserved memory
> > > nodes. This makes the reserved memory allocation compatiable with
> > s/compatiable/compatible/
> >
> > >
> > > the shared-dma-pool usage.
> > This change is not backwards compatible. Please state that and explain
> > why that is okay. If PPC needs to not change, then the old strings and
> > properties should remain, but deprecated.
> I think I can make the old device trees compatible since the
> "compatible" string changed without too much effort or ifdefery in the
> code. However I would like to eventually see all PPC users move to the
> new mode as I do believe it is more in alignment with the spirit of the
> reserved-memory framework that is in the kernel.
How much benefit is there to changing PPC if you have to retain the old method
anyway for compatibility? Whereas if you don't convert, you retain test
coverage for the old device trees, and don't have to worry about
the memblock_end_of_DRAM() questions.
> Do I need to mention the old mode in the binding.txt file?
Yes.
> I'm trying to keep things clean
> so someone reading the binding doesn't get a headache and trying to
> preserve my own sanity as we move forward with adding new features to
> this driver.
If they're sufficiently different then just describe the new and old nodes
separately rather than putting a bunch of if/else clauses in there.
-Scott
--
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: [RFC PATCH 2/5] soc/fsl/qbman: Use shared-dma-pool for QMan private memory allocations
From: Scott Wood @ 2017-04-04 0:24 UTC (permalink / raw)
To: Robin Murphy, Michael Ellerman, roy.pledge-3arQi8VN3Tc,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Mark Rutland, madalin.bucur-3arQi8VN3Tc
In-Reply-To: <df00c0ab-22b8-1086-def1-69baf648df72-5wv7dgnIgG8@public.gmane.org>
On Mon, 2017-04-03 at 15:52 +0100, Robin Murphy wrote:
> On 01/04/17 08:25, Scott Wood wrote:
> >
> > On Fri, 2017-03-31 at 18:55 +0100, Robin Murphy wrote:
> > >
> > > On 31/03/17 04:27, Michael Ellerman wrote:
> > > >
> > > >
> > > > Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> writes:
> > > >
> > > > >
> > > > >
> > > > > Hi Roy,
> > > > >
> > > > > On 29/03/17 22:13, Roy Pledge wrote:
> > > > > >
> > > > > >
> > > > > > Use the shared-memory-pool mechanism for frame queue descriptor
> > > > > > and
> > > > > > packed frame descriptor record area allocations.
> > > > > Thanks for persevering with this - in my opinion it's now looking
> > > > > like
> > > > > it was worth the effort :)
> > > > >
> > > > > AFAICS the ioremap_wc() that this leads to does appear to give back
> > > > > something non-cacheable on PPC (assuming "pgprot_noncached_wc" isn't
> > > > > horrendously misnamed), and "no-map" should rule out any cacheable
> > > > > linear map alias existing, so it would seem that this approach
> > > > > should
> > > > > avert Scott's concerns about attribute mismatches.
> > > > How does 'no-map' translate into something being excluded from the
> > > > linear mapping?
> > > Reserved regions marked with "no-map" get memblock_remove()d by
> > > early_init_dt_alloc_reserved_memory_arch(). As I understand things, the
> > > linear map should only cover memblock areas, and it would be explicitly
> > > violating the semantics of "no-map" to still cover such a region.
> > Discontiguous memory isn't supported on these PPC chips. Everything up to
> > memblock_end_of_DRAM() gets mapped -- and if that were to change, the
> > fragmentation would waste TLB1 entries.
> Ah, so the "PPC-specific angles I'm not aware of" category is indeed
> non-empty - I guess the lack of HAVE_GENERIC_DMA_COHERENT might be
> related, then.
>
> That said, though, AFAICS only certain x86 and s390 configurations ever
> call memblock_set_bottom_up(true), so we should be able to assume that
> the reserved region allocations always fall through to
> __memblock_find_range_top_down(). Thus if your DRAM is contiguous, then
> "no-map"-ing the reserved regions will simply end up pushing
> memblock_end_of_DRAM() down in a manner that would appear to still avoid
> overlaps.
Can you guarantee it will be at the end? What if there were other early
memblock allocations (e.g. other reserved-memory regions without no-map) that
came first?
> I can only see that going wrong if the end of DRAM wasn't at
> least 32MB aligned to begin with - is that ever likely to happen in
> practice?
Probably not, unless the user asks for an unusual memory size via mem= or
similar.
-Scott
--
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
* [PATCH linux v6 2/2] drivers: hwmon: Support for ASPEED PWM/Fan tach
From: Jaghathiswari Rankappagounder Natarajan @ 2017-04-03 23:30 UTC (permalink / raw)
To: joel, jdelvare, linux, linux-hwmon, linux-kernel, openbmc, corbet,
linux-doc, robh+dt, mark.rutland, devicetree
Cc: Jaghathiswari Rankappagounder Natarajan
In-Reply-To: <20170403233025.26952-1-jaghu@google.com>
The ASPEED AST2400/2500 PWM controller supports 8 PWM output ports.
The ASPEED AST2400/2500 Fan tach controller supports 16 tachometer
inputs.
The device driver matches on the device tree node. The configuration
values are read from the device tree and written to the respective registers.
The driver provides a sysfs entries through which the user can
configure the duty-cycle value (ranging from 0 to 100 percent) and read
the fan tach rpm value.
Signed-off-by: Jaghathiswari Rankappagounder Natarajan <jaghu@google.com>
---
v6
- Corrected odd line breaks
- Changed upto to up to
- Dropped unrelated changes
- Removed struct and used regs pointer directly
- Made groups to be null terminated
- Made correction in calculation of val/raw_data
- Removed else after return
- Removed unnecessary continuation lines
v5:
- Changed the driver to suit the changes in the device tree documentation
v4:
- Modified this driver to suit the representation in the devicetree
v3:
- Only sent out device tree documentation; did not send this driver
v2:
- Used BIT()
- Used regmap
- Avoided division when raw data is 0
- Removed empty lines between declaration
- Removed macros; Used two attribute groups and used is_visible callback
- Returned error when properties are undefined
- Removed .owner field
- Used PTR_ERR_OR_ZERO
- Removed explicit of_node_put for child nodes
Documentation/hwmon/aspeed-pwm-tacho | 22 +
drivers/hwmon/Kconfig | 9 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/aspeed-pwm-tacho.c | 846 +++++++++++++++++++++++++++++++++++
4 files changed, 878 insertions(+)
create mode 100644 Documentation/hwmon/aspeed-pwm-tacho
create mode 100644 drivers/hwmon/aspeed-pwm-tacho.c
diff --git a/Documentation/hwmon/aspeed-pwm-tacho b/Documentation/hwmon/aspeed-pwm-tacho
new file mode 100644
index 000000000000..7cfb34977460
--- /dev/null
+++ b/Documentation/hwmon/aspeed-pwm-tacho
@@ -0,0 +1,22 @@
+Kernel driver aspeed-pwm-tacho
+==============================
+
+Supported chips:
+ ASPEED AST2400/2500
+
+Authors:
+ <jaghu@google.com>
+
+Description:
+------------
+This driver implements support for ASPEED AST2400/2500 PWM and Fan Tacho
+controller. The PWM controller supports upto 8 PWM outputs. The Fan tacho
+controller supports up to 16 tachometer inputs.
+
+The driver provides the following sensor accesses in sysfs:
+
+fanX_input ro provide current fan rotation value in RPM as reported
+ by the fan to the device.
+
+pwmX rw get or set PWM fan control value. This is an integer
+ value between 0(off) and 255(full speed).
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 45cef3d2c75c..757b5b0705bf 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -341,6 +341,15 @@ config SENSORS_ASB100
This driver can also be built as a module. If so, the module
will be called asb100.
+config SENSORS_ASPEED
+ tristate "ASPEED AST2400/AST2500 PWM and Fan tach driver"
+ help
+ This driver provides support for ASPEED AST2400/AST2500 PWM
+ and Fan Tacho controllers.
+
+ This driver can also be built as a module. If so, the module
+ will be called aspeed_pwm_tacho.
+
config SENSORS_ATXP1
tristate "Attansic ATXP1 VID controller"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index aecf4ba17460..83025cc9bb45 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SENSORS_ADT7475) += adt7475.o
obj-$(CONFIG_SENSORS_APPLESMC) += applesmc.o
obj-$(CONFIG_SENSORS_ARM_SCPI) += scpi-hwmon.o
obj-$(CONFIG_SENSORS_ASC7621) += asc7621.o
+obj-$(CONFIG_SENSORS_ASPEED) += aspeed-pwm-tacho.o
obj-$(CONFIG_SENSORS_ATXP1) += atxp1.o
obj-$(CONFIG_SENSORS_CORETEMP) += coretemp.o
obj-$(CONFIG_SENSORS_DA9052_ADC)+= da9052-hwmon.o
diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c
new file mode 100644
index 000000000000..29010ad94208
--- /dev/null
+++ b/drivers/hwmon/aspeed-pwm-tacho.c
@@ -0,0 +1,846 @@
+/*
+ * Copyright (c) 2016 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 or later as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/clk.h>
+#include <linux/gpio/consumer.h>
+#include <linux/delay.h>
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/sysfs.h>
+#include <linux/regmap.h>
+
+/* ASPEED PWM & FAN Tach Register Definition */
+#define ASPEED_PTCR_CTRL 0x00
+#define ASPEED_PTCR_CLK_CTRL 0x04
+#define ASPEED_PTCR_DUTY0_CTRL 0x08
+#define ASPEED_PTCR_DUTY1_CTRL 0x0c
+#define ASPEED_PTCR_TYPEM_CTRL 0x10
+#define ASPEED_PTCR_TYPEM_CTRL1 0x14
+#define ASPEED_PTCR_TYPEN_CTRL 0x18
+#define ASPEED_PTCR_TYPEN_CTRL1 0x1c
+#define ASPEED_PTCR_TACH_SOURCE 0x20
+#define ASPEED_PTCR_TRIGGER 0x28
+#define ASPEED_PTCR_RESULT 0x2c
+#define ASPEED_PTCR_INTR_CTRL 0x30
+#define ASPEED_PTCR_INTR_STS 0x34
+#define ASPEED_PTCR_TYPEM_LIMIT 0x38
+#define ASPEED_PTCR_TYPEN_LIMIT 0x3C
+#define ASPEED_PTCR_CTRL_EXT 0x40
+#define ASPEED_PTCR_CLK_CTRL_EXT 0x44
+#define ASPEED_PTCR_DUTY2_CTRL 0x48
+#define ASPEED_PTCR_DUTY3_CTRL 0x4c
+#define ASPEED_PTCR_TYPEO_CTRL 0x50
+#define ASPEED_PTCR_TYPEO_CTRL1 0x54
+#define ASPEED_PTCR_TACH_SOURCE_EXT 0x60
+#define ASPEED_PTCR_TYPEO_LIMIT 0x78
+
+/* ASPEED_PTCR_CTRL : 0x00 - General Control Register */
+#define ASPEED_PTCR_CTRL_SET_PWMD_TYPE_PART1 15
+#define ASPEED_PTCR_CTRL_SET_PWMD_TYPE_PART2 6
+#define ASPEED_PTCR_CTRL_SET_PWMD_TYPE_MASK (BIT(7) | BIT(15))
+
+#define ASPEED_PTCR_CTRL_SET_PWMC_TYPE_PART1 14
+#define ASPEED_PTCR_CTRL_SET_PWMC_TYPE_PART2 5
+#define ASPEED_PTCR_CTRL_SET_PWMC_TYPE_MASK (BIT(6) | BIT(14))
+
+#define ASPEED_PTCR_CTRL_SET_PWMB_TYPE_PART1 13
+#define ASPEED_PTCR_CTRL_SET_PWMB_TYPE_PART2 4
+#define ASPEED_PTCR_CTRL_SET_PWMB_TYPE_MASK (BIT(5) | BIT(13))
+
+#define ASPEED_PTCR_CTRL_SET_PWMA_TYPE_PART1 12
+#define ASPEED_PTCR_CTRL_SET_PWMA_TYPE_PART2 3
+#define ASPEED_PTCR_CTRL_SET_PWMA_TYPE_MASK (BIT(4) | BIT(12))
+
+#define ASPEED_PTCR_CTRL_FAN_NUM_EN(x) BIT(16 + (x))
+
+#define ASPEED_PTCR_CTRL_PWMD_EN BIT(11)
+#define ASPEED_PTCR_CTRL_PWMC_EN BIT(10)
+#define ASPEED_PTCR_CTRL_PWMB_EN BIT(9)
+#define ASPEED_PTCR_CTRL_PWMA_EN BIT(8)
+
+#define ASPEED_PTCR_CTRL_CLK_SRC BIT(1)
+#define ASPEED_PTCR_CTRL_CLK_EN BIT(0)
+
+/* ASPEED_PTCR_CLK_CTRL : 0x04 - Clock Control Register */
+/* TYPE N */
+#define ASPEED_PTCR_CLK_CTRL_TYPEN_MASK GENMASK(31, 16)
+#define ASPEED_PTCR_CLK_CTRL_TYPEN_UNIT 24
+#define ASPEED_PTCR_CLK_CTRL_TYPEN_H 20
+#define ASPEED_PTCR_CLK_CTRL_TYPEN_L 16
+/* TYPE M */
+#define ASPEED_PTCR_CLK_CTRL_TYPEM_MASK GENMASK(15, 0)
+#define ASPEED_PTCR_CLK_CTRL_TYPEM_UNIT 8
+#define ASPEED_PTCR_CLK_CTRL_TYPEM_H 4
+#define ASPEED_PTCR_CLK_CTRL_TYPEM_L 0
+
+/*
+ * ASPEED_PTCR_DUTY_CTRL/1/2/3 : 0x08/0x0C/0x48/0x4C - PWM-FAN duty control
+ * 0/1/2/3 register
+ */
+#define DUTY_CTRL_PWM2_FALL_POINT 24
+#define DUTY_CTRL_PWM2_RISE_POINT 16
+#define DUTY_CTRL_PWM2_RISE_FALL_MASK GENMASK(31, 16)
+#define DUTY_CTRL_PWM1_FALL_POINT 8
+#define DUTY_CTRL_PWM1_RISE_POINT 0
+#define DUTY_CTRL_PWM1_RISE_FALL_MASK GENMASK(15, 0)
+
+/* ASPEED_PTCR_TYPEM_CTRL : 0x10/0x18/0x50 - Type M/N/O Ctrl 0 Register */
+#define TYPE_CTRL_FAN_MASK (GENMASK(5, 1) | GENMASK(31, 16))
+#define TYPE_CTRL_FAN1_MASK GENMASK(31, 0)
+#define TYPE_CTRL_FAN_PERIOD 16
+#define TYPE_CTRL_FAN_MODE 4
+#define TYPE_CTRL_FAN_DIVISION 1
+#define TYPE_CTRL_FAN_TYPE_EN 1
+
+/* ASPEED_PTCR_TACH_SOURCE : 0x20/0x60 - Tach Source Register */
+/* bit [0,1] at 0x20, bit [2] at 0x60 */
+#define TACH_PWM_SOURCE_BIT01(x) ((x) * 2)
+#define TACH_PWM_SOURCE_BIT2(x) ((x) * 2)
+#define TACH_PWM_SOURCE_MASK_BIT01(x) (0x3 << ((x) * 2))
+#define TACH_PWM_SOURCE_MASK_BIT2(x) BIT((x) * 2)
+
+/* ASPEED_PTCR_RESULT : 0x2c - Result Register */
+#define RESULT_STATUS_MASK BIT(31)
+#define RESULT_VALUE_MASK 0xfffff
+
+/* ASPEED_PTCR_CTRL_EXT : 0x40 - General Control Extension #1 Register */
+#define ASPEED_PTCR_CTRL_SET_PWMH_TYPE_PART1 15
+#define ASPEED_PTCR_CTRL_SET_PWMH_TYPE_PART2 6
+#define ASPEED_PTCR_CTRL_SET_PWMH_TYPE_MASK (BIT(7) | BIT(15))
+
+#define ASPEED_PTCR_CTRL_SET_PWMG_TYPE_PART1 14
+#define ASPEED_PTCR_CTRL_SET_PWMG_TYPE_PART2 5
+#define ASPEED_PTCR_CTRL_SET_PWMG_TYPE_MASK (BIT(6) | BIT(14))
+
+#define ASPEED_PTCR_CTRL_SET_PWMF_TYPE_PART1 13
+#define ASPEED_PTCR_CTRL_SET_PWMF_TYPE_PART2 4
+#define ASPEED_PTCR_CTRL_SET_PWMF_TYPE_MASK (BIT(5) | BIT(13))
+
+#define ASPEED_PTCR_CTRL_SET_PWME_TYPE_PART1 12
+#define ASPEED_PTCR_CTRL_SET_PWME_TYPE_PART2 3
+#define ASPEED_PTCR_CTRL_SET_PWME_TYPE_MASK (BIT(4) | BIT(12))
+
+#define ASPEED_PTCR_CTRL_PWMH_EN BIT(11)
+#define ASPEED_PTCR_CTRL_PWMG_EN BIT(10)
+#define ASPEED_PTCR_CTRL_PWMF_EN BIT(9)
+#define ASPEED_PTCR_CTRL_PWME_EN BIT(8)
+
+/* ASPEED_PTCR_CLK_EXT_CTRL : 0x44 - Clock Control Extension #1 Register */
+/* TYPE O */
+#define ASPEED_PTCR_CLK_CTRL_TYPEO_MASK GENMASK(15, 0)
+#define ASPEED_PTCR_CLK_CTRL_TYPEO_UNIT 8
+#define ASPEED_PTCR_CLK_CTRL_TYPEO_H 4
+#define ASPEED_PTCR_CLK_CTRL_TYPEO_L 0
+
+#define PWM_MAX 255
+
+#define M_PWM_DIV_H 0x00
+#define M_PWM_DIV_L 0x05
+#define M_PWM_PERIOD 0x5F
+#define M_TACH_CLK_DIV 0x00
+#define M_TACH_MODE 0x00
+#define M_TACH_UNIT 0x1000
+#define INIT_FAN_CTRL 0xFF
+
+void __iomem *regs;
+
+struct aspeed_pwm_tacho_data {
+ struct regmap *regmap;
+ unsigned long clk_freq;
+ bool pwm_present[8];
+ bool fan_tach_present[16];
+ u8 type_pwm_clock_unit[3];
+ u8 type_pwm_clock_division_h[3];
+ u8 type_pwm_clock_division_l[3];
+ u8 type_fan_tach_clock_division[3];
+ u16 type_fan_tach_unit[3];
+ u8 pwm_port_type[8];
+ u8 pwm_port_fan_ctrl[8];
+ u8 fan_tach_ch_source[16];
+ const struct attribute_group *groups[3];
+};
+
+enum type { TYPEM, TYPEN, TYPEO };
+
+struct type_params {
+ u32 l_value;
+ u32 h_value;
+ u32 unit_value;
+ u32 clk_ctrl_mask;
+ u32 clk_ctrl_reg;
+ u32 ctrl_reg;
+ u32 ctrl_reg1;
+};
+
+static const struct type_params type_params[] = {
+ [TYPEM] = {
+ .l_value = ASPEED_PTCR_CLK_CTRL_TYPEM_L,
+ .h_value = ASPEED_PTCR_CLK_CTRL_TYPEM_H,
+ .unit_value = ASPEED_PTCR_CLK_CTRL_TYPEM_UNIT,
+ .clk_ctrl_mask = ASPEED_PTCR_CLK_CTRL_TYPEM_MASK,
+ .clk_ctrl_reg = ASPEED_PTCR_CLK_CTRL,
+ .ctrl_reg = ASPEED_PTCR_TYPEM_CTRL,
+ .ctrl_reg1 = ASPEED_PTCR_TYPEM_CTRL1,
+ },
+ [TYPEN] = {
+ .l_value = ASPEED_PTCR_CLK_CTRL_TYPEN_L,
+ .h_value = ASPEED_PTCR_CLK_CTRL_TYPEN_H,
+ .unit_value = ASPEED_PTCR_CLK_CTRL_TYPEN_UNIT,
+ .clk_ctrl_mask = ASPEED_PTCR_CLK_CTRL_TYPEN_MASK,
+ .clk_ctrl_reg = ASPEED_PTCR_CLK_CTRL,
+ .ctrl_reg = ASPEED_PTCR_TYPEN_CTRL,
+ .ctrl_reg1 = ASPEED_PTCR_TYPEN_CTRL1,
+ },
+ [TYPEO] = {
+ .l_value = ASPEED_PTCR_CLK_CTRL_TYPEO_L,
+ .h_value = ASPEED_PTCR_CLK_CTRL_TYPEO_H,
+ .unit_value = ASPEED_PTCR_CLK_CTRL_TYPEO_UNIT,
+ .clk_ctrl_mask = ASPEED_PTCR_CLK_CTRL_TYPEO_MASK,
+ .clk_ctrl_reg = ASPEED_PTCR_CLK_CTRL_EXT,
+ .ctrl_reg = ASPEED_PTCR_TYPEO_CTRL,
+ .ctrl_reg1 = ASPEED_PTCR_TYPEO_CTRL1,
+ }
+};
+
+enum pwm_port { PWMA, PWMB, PWMC, PWMD, PWME, PWMF, PWMG, PWMH };
+
+struct pwm_port_params {
+ u32 pwm_en;
+ u32 ctrl_reg;
+ u32 type_part1;
+ u32 type_part2;
+ u32 type_mask;
+ u32 duty_ctrl_rise_point;
+ u32 duty_ctrl_fall_point;
+ u32 duty_ctrl_reg;
+ u32 duty_ctrl_rise_fall_mask;
+};
+
+static const struct pwm_port_params pwm_port_params[] = {
+ [PWMA] = {
+ .pwm_en = ASPEED_PTCR_CTRL_PWMA_EN,
+ .ctrl_reg = ASPEED_PTCR_CTRL,
+ .type_part1 = ASPEED_PTCR_CTRL_SET_PWMA_TYPE_PART1,
+ .type_part2 = ASPEED_PTCR_CTRL_SET_PWMA_TYPE_PART2,
+ .type_mask = ASPEED_PTCR_CTRL_SET_PWMA_TYPE_MASK,
+ .duty_ctrl_rise_point = DUTY_CTRL_PWM1_RISE_POINT,
+ .duty_ctrl_fall_point = DUTY_CTRL_PWM1_FALL_POINT,
+ .duty_ctrl_reg = ASPEED_PTCR_DUTY0_CTRL,
+ .duty_ctrl_rise_fall_mask = DUTY_CTRL_PWM1_RISE_FALL_MASK,
+ },
+ [PWMB] = {
+ .pwm_en = ASPEED_PTCR_CTRL_PWMB_EN,
+ .ctrl_reg = ASPEED_PTCR_CTRL,
+ .type_part1 = ASPEED_PTCR_CTRL_SET_PWMB_TYPE_PART1,
+ .type_part2 = ASPEED_PTCR_CTRL_SET_PWMB_TYPE_PART2,
+ .type_mask = ASPEED_PTCR_CTRL_SET_PWMB_TYPE_MASK,
+ .duty_ctrl_rise_point = DUTY_CTRL_PWM2_RISE_POINT,
+ .duty_ctrl_fall_point = DUTY_CTRL_PWM2_FALL_POINT,
+ .duty_ctrl_reg = ASPEED_PTCR_DUTY0_CTRL,
+ .duty_ctrl_rise_fall_mask = DUTY_CTRL_PWM2_RISE_FALL_MASK,
+ },
+ [PWMC] = {
+ .pwm_en = ASPEED_PTCR_CTRL_PWMC_EN,
+ .ctrl_reg = ASPEED_PTCR_CTRL,
+ .type_part1 = ASPEED_PTCR_CTRL_SET_PWMC_TYPE_PART1,
+ .type_part2 = ASPEED_PTCR_CTRL_SET_PWMC_TYPE_PART2,
+ .type_mask = ASPEED_PTCR_CTRL_SET_PWMC_TYPE_MASK,
+ .duty_ctrl_rise_point = DUTY_CTRL_PWM1_RISE_POINT,
+ .duty_ctrl_fall_point = DUTY_CTRL_PWM1_FALL_POINT,
+ .duty_ctrl_reg = ASPEED_PTCR_DUTY1_CTRL,
+ .duty_ctrl_rise_fall_mask = DUTY_CTRL_PWM1_RISE_FALL_MASK,
+ },
+ [PWMD] = {
+ .pwm_en = ASPEED_PTCR_CTRL_PWMD_EN,
+ .ctrl_reg = ASPEED_PTCR_CTRL,
+ .type_part1 = ASPEED_PTCR_CTRL_SET_PWMD_TYPE_PART1,
+ .type_part2 = ASPEED_PTCR_CTRL_SET_PWMD_TYPE_PART2,
+ .type_mask = ASPEED_PTCR_CTRL_SET_PWMD_TYPE_MASK,
+ .duty_ctrl_rise_point = DUTY_CTRL_PWM2_RISE_POINT,
+ .duty_ctrl_fall_point = DUTY_CTRL_PWM2_FALL_POINT,
+ .duty_ctrl_reg = ASPEED_PTCR_DUTY1_CTRL,
+ .duty_ctrl_rise_fall_mask = DUTY_CTRL_PWM2_RISE_FALL_MASK,
+ },
+ [PWME] = {
+ .pwm_en = ASPEED_PTCR_CTRL_PWME_EN,
+ .ctrl_reg = ASPEED_PTCR_CTRL_EXT,
+ .type_part1 = ASPEED_PTCR_CTRL_SET_PWME_TYPE_PART1,
+ .type_part2 = ASPEED_PTCR_CTRL_SET_PWME_TYPE_PART2,
+ .type_mask = ASPEED_PTCR_CTRL_SET_PWME_TYPE_MASK,
+ .duty_ctrl_rise_point = DUTY_CTRL_PWM1_RISE_POINT,
+ .duty_ctrl_fall_point = DUTY_CTRL_PWM1_FALL_POINT,
+ .duty_ctrl_reg = ASPEED_PTCR_DUTY2_CTRL,
+ .duty_ctrl_rise_fall_mask = DUTY_CTRL_PWM1_RISE_FALL_MASK,
+ },
+ [PWMF] = {
+ .pwm_en = ASPEED_PTCR_CTRL_PWMF_EN,
+ .ctrl_reg = ASPEED_PTCR_CTRL_EXT,
+ .type_part1 = ASPEED_PTCR_CTRL_SET_PWMF_TYPE_PART1,
+ .type_part2 = ASPEED_PTCR_CTRL_SET_PWMF_TYPE_PART2,
+ .type_mask = ASPEED_PTCR_CTRL_SET_PWMF_TYPE_MASK,
+ .duty_ctrl_rise_point = DUTY_CTRL_PWM2_RISE_POINT,
+ .duty_ctrl_fall_point = DUTY_CTRL_PWM2_FALL_POINT,
+ .duty_ctrl_reg = ASPEED_PTCR_DUTY2_CTRL,
+ .duty_ctrl_rise_fall_mask = DUTY_CTRL_PWM2_RISE_FALL_MASK,
+ },
+ [PWMG] = {
+ .pwm_en = ASPEED_PTCR_CTRL_PWMG_EN,
+ .ctrl_reg = ASPEED_PTCR_CTRL_EXT,
+ .type_part1 = ASPEED_PTCR_CTRL_SET_PWMG_TYPE_PART1,
+ .type_part2 = ASPEED_PTCR_CTRL_SET_PWMG_TYPE_PART2,
+ .type_mask = ASPEED_PTCR_CTRL_SET_PWMG_TYPE_MASK,
+ .duty_ctrl_rise_point = DUTY_CTRL_PWM1_RISE_POINT,
+ .duty_ctrl_fall_point = DUTY_CTRL_PWM1_FALL_POINT,
+ .duty_ctrl_reg = ASPEED_PTCR_DUTY3_CTRL,
+ .duty_ctrl_rise_fall_mask = DUTY_CTRL_PWM1_RISE_FALL_MASK,
+ },
+ [PWMH] = {
+ .pwm_en = ASPEED_PTCR_CTRL_PWMH_EN,
+ .ctrl_reg = ASPEED_PTCR_CTRL_EXT,
+ .type_part1 = ASPEED_PTCR_CTRL_SET_PWMH_TYPE_PART1,
+ .type_part2 = ASPEED_PTCR_CTRL_SET_PWMH_TYPE_PART2,
+ .type_mask = ASPEED_PTCR_CTRL_SET_PWMH_TYPE_MASK,
+ .duty_ctrl_rise_point = DUTY_CTRL_PWM2_RISE_POINT,
+ .duty_ctrl_fall_point = DUTY_CTRL_PWM2_FALL_POINT,
+ .duty_ctrl_reg = ASPEED_PTCR_DUTY3_CTRL,
+ .duty_ctrl_rise_fall_mask = DUTY_CTRL_PWM2_RISE_FALL_MASK,
+ }
+};
+
+static int regmap_aspeed_pwm_tacho_reg_write(void *context, unsigned int reg,
+ unsigned int val)
+{
+ void __iomem *regs = context;
+
+ writel(val, regs + reg);
+ return 0;
+}
+
+static int regmap_aspeed_pwm_tacho_reg_read(void *context, unsigned int reg,
+ unsigned int *val)
+{
+ void __iomem *regs = context;
+
+ *val = readl(regs + reg);
+ return 0;
+}
+
+static const struct regmap_config aspeed_pwm_tacho_regmap_config = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = ASPEED_PTCR_TYPEO_LIMIT,
+ .reg_write = regmap_aspeed_pwm_tacho_reg_write,
+ .reg_read = regmap_aspeed_pwm_tacho_reg_read,
+ .fast_io = true,
+};
+
+static void aspeed_set_clock_enable(struct regmap *regmap, bool val)
+{
+ regmap_update_bits(regmap, ASPEED_PTCR_CTRL,
+ ASPEED_PTCR_CTRL_CLK_EN,
+ val ? ASPEED_PTCR_CTRL_CLK_EN : 0);
+}
+
+static void aspeed_set_clock_source(struct regmap *regmap, int val)
+{
+ regmap_update_bits(regmap, ASPEED_PTCR_CTRL,
+ ASPEED_PTCR_CTRL_CLK_SRC,
+ val ? ASPEED_PTCR_CTRL_CLK_SRC : 0);
+}
+
+static void aspeed_set_pwm_clock_values(struct regmap *regmap, u8 type,
+ u8 div_high, u8 div_low, u8 unit)
+{
+ u32 reg_value = ((div_high << type_params[type].h_value) |
+ (div_low << type_params[type].l_value) |
+ (unit << type_params[type].unit_value));
+
+ regmap_update_bits(regmap, type_params[type].clk_ctrl_reg,
+ type_params[type].clk_ctrl_mask, reg_value);
+}
+
+static void aspeed_set_pwm_port_enable(struct regmap *regmap, u8 pwm_port,
+ bool enable)
+{
+ regmap_update_bits(regmap, pwm_port_params[pwm_port].ctrl_reg,
+ pwm_port_params[pwm_port].pwm_en,
+ enable ? pwm_port_params[pwm_port].pwm_en : 0);
+}
+
+static void aspeed_set_pwm_port_type(struct regmap *regmap,
+ u8 pwm_port, u8 type)
+{
+ u32 reg_value = (type & 0x1) << pwm_port_params[pwm_port].type_part1;
+
+ reg_value |= (type & 0x2) << pwm_port_params[pwm_port].type_part2;
+
+ regmap_update_bits(regmap, pwm_port_params[pwm_port].ctrl_reg,
+ pwm_port_params[pwm_port].type_mask, reg_value);
+}
+
+static void aspeed_set_pwm_port_duty_rising_falling(struct regmap *regmap,
+ u8 pwm_port, u8 rising,
+ u8 falling)
+{
+ u32 reg_value = (rising <<
+ pwm_port_params[pwm_port].duty_ctrl_rise_point);
+ reg_value |= (falling <<
+ pwm_port_params[pwm_port].duty_ctrl_fall_point);
+
+ regmap_update_bits(regmap, pwm_port_params[pwm_port].duty_ctrl_reg,
+ pwm_port_params[pwm_port].duty_ctrl_rise_fall_mask,
+ reg_value);
+}
+
+static void aspeed_set_tacho_type_enable(struct regmap *regmap, u8 type,
+ bool enable)
+{
+ regmap_update_bits(regmap, type_params[type].ctrl_reg,
+ TYPE_CTRL_FAN_TYPE_EN,
+ enable ? TYPE_CTRL_FAN_TYPE_EN : 0);
+}
+
+static void aspeed_set_tacho_type_values(struct regmap *regmap, u8 type,
+ u8 mode, u16 unit, u8 division)
+{
+ u32 reg_value = ((mode << TYPE_CTRL_FAN_MODE) |
+ (unit << TYPE_CTRL_FAN_PERIOD) |
+ (division << TYPE_CTRL_FAN_DIVISION));
+
+ regmap_update_bits(regmap, type_params[type].ctrl_reg,
+ TYPE_CTRL_FAN_MASK, reg_value);
+ regmap_update_bits(regmap, type_params[type].ctrl_reg1,
+ TYPE_CTRL_FAN1_MASK, unit << 16);
+}
+
+static void aspeed_set_fan_tach_ch_enable(struct regmap *regmap, u8 fan_tach_ch,
+ bool enable)
+{
+ regmap_update_bits(regmap, ASPEED_PTCR_CTRL,
+ ASPEED_PTCR_CTRL_FAN_NUM_EN(fan_tach_ch),
+ enable ?
+ ASPEED_PTCR_CTRL_FAN_NUM_EN(fan_tach_ch) : 0);
+}
+
+static void aspeed_set_fan_tach_ch_source(struct regmap *regmap, u8 fan_tach_ch,
+ u8 fan_tach_ch_source)
+{
+ u32 reg_value1 = ((fan_tach_ch_source & 0x3) <<
+ TACH_PWM_SOURCE_BIT01(fan_tach_ch));
+ u32 reg_value2 = (((fan_tach_ch_source & 0x4) >> 2) <<
+ TACH_PWM_SOURCE_BIT2(fan_tach_ch));
+
+ regmap_update_bits(regmap, ASPEED_PTCR_TACH_SOURCE,
+ TACH_PWM_SOURCE_MASK_BIT01(fan_tach_ch),
+ reg_value1);
+
+ regmap_update_bits(regmap, ASPEED_PTCR_TACH_SOURCE_EXT,
+ TACH_PWM_SOURCE_MASK_BIT2(fan_tach_ch),
+ reg_value2);
+}
+
+static void aspeed_set_pwm_port_fan_ctrl(struct aspeed_pwm_tacho_data *priv,
+ u8 index, u8 fan_ctrl)
+{
+ u16 period, dc_time_on;
+
+ period = priv->type_pwm_clock_unit[priv->pwm_port_type[index]];
+ period += 1;
+ dc_time_on = (fan_ctrl * period) / PWM_MAX;
+
+ if (dc_time_on == 0) {
+ aspeed_set_pwm_port_enable(priv->regmap, index, false);
+ } else {
+ if (dc_time_on == period)
+ dc_time_on = 0;
+
+ aspeed_set_pwm_port_duty_rising_falling(priv->regmap, index, 0,
+ dc_time_on);
+ aspeed_set_pwm_port_enable(priv->regmap, index, true);
+ }
+}
+
+static u32 aspeed_get_fan_tach_ch_measure_period(struct aspeed_pwm_tacho_data
+ *priv, u8 type)
+{
+ u32 clk;
+ u16 tacho_unit;
+ u8 clk_unit, div_h, div_l, tacho_div;
+
+ clk = priv->clk_freq;
+ clk_unit = priv->type_pwm_clock_unit[type];
+ div_h = priv->type_pwm_clock_division_h[type];
+ div_h = 0x1 << div_h;
+ div_l = priv->type_pwm_clock_division_l[type];
+ if (div_l == 0)
+ div_l = 1;
+ else
+ div_l = div_l * 2;
+
+ tacho_unit = priv->type_fan_tach_unit[type];
+ tacho_div = priv->type_fan_tach_clock_division[type];
+
+ tacho_div = 0x4 << (tacho_div * 2);
+ return clk / (clk_unit * div_h * div_l * tacho_div * tacho_unit);
+}
+
+static u32 aspeed_get_fan_tach_ch_rpm(struct aspeed_pwm_tacho_data *priv,
+ u8 fan_tach_ch)
+{
+ u32 raw_data, tach_div, clk_source, timeout = 0, sec, val;
+ u8 fan_tach_ch_source, type;
+
+ regmap_write(priv->regmap, ASPEED_PTCR_TRIGGER, 0);
+ regmap_write(priv->regmap, ASPEED_PTCR_TRIGGER, 0x1 << fan_tach_ch);
+
+ fan_tach_ch_source = priv->fan_tach_ch_source[fan_tach_ch];
+ type = priv->pwm_port_type[fan_tach_ch_source];
+
+ sec = (1000 / aspeed_get_fan_tach_ch_measure_period(priv, type));
+
+ msleep(sec);
+
+ while (!(regmap_read(priv->regmap, ASPEED_PTCR_RESULT, &val))
+ & !(val & RESULT_STATUS_MASK)) {
+ timeout++;
+ if (timeout > 1)
+ return 0;
+ msleep(sec);
+ }
+
+ raw_data = val & RESULT_VALUE_MASK;
+ tach_div = priv->type_fan_tach_clock_division[type];
+ tach_div = 0x4 << (tach_div * 2);
+ clk_source = priv->clk_freq;
+
+ if (raw_data == 0)
+ return 0;
+
+ return (clk_source * 60) / (2 * raw_data * tach_div);
+}
+
+static ssize_t set_pwm(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct sensor_device_attribute *sensor_attr = to_sensor_dev_attr(attr);
+ int index = sensor_attr->index;
+ int ret;
+ struct aspeed_pwm_tacho_data *priv = dev_get_drvdata(dev);
+ long fan_ctrl;
+
+ ret = kstrtol(buf, 10, &fan_ctrl);
+ if (ret != 0)
+ return ret;
+
+ if (fan_ctrl < 0 || fan_ctrl > PWM_MAX)
+ return -EINVAL;
+
+ if (priv->pwm_port_fan_ctrl[index] == fan_ctrl)
+ return count;
+
+ priv->pwm_port_fan_ctrl[index] = fan_ctrl;
+ aspeed_set_pwm_port_fan_ctrl(priv, index, fan_ctrl);
+
+ return count;
+}
+
+static ssize_t show_pwm(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct sensor_device_attribute *sensor_attr = to_sensor_dev_attr(attr);
+ int index = sensor_attr->index;
+ struct aspeed_pwm_tacho_data *priv = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%u\n", priv->pwm_port_fan_ctrl[index]);
+}
+
+static ssize_t show_rpm(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ struct sensor_device_attribute *sensor_attr = to_sensor_dev_attr(attr);
+ int index = sensor_attr->index;
+ u32 rpm;
+ struct aspeed_pwm_tacho_data *priv = dev_get_drvdata(dev);
+
+ rpm = aspeed_get_fan_tach_ch_rpm(priv, index);
+
+ return sprintf(buf, "%u\n", rpm);
+}
+
+static umode_t pwm_is_visible(struct kobject *kobj,
+ struct attribute *a, int index)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct aspeed_pwm_tacho_data *priv = dev_get_drvdata(dev);
+
+ if (!priv->pwm_present[index])
+ return 0;
+ return a->mode;
+}
+
+static umode_t fan_dev_is_visible(struct kobject *kobj,
+ struct attribute *a, int index)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct aspeed_pwm_tacho_data *priv = dev_get_drvdata(dev);
+
+ if (!priv->fan_tach_present[index])
+ return 0;
+ return a->mode;
+}
+
+static SENSOR_DEVICE_ATTR(pwm0, 0644,
+ show_pwm, set_pwm, 0);
+static SENSOR_DEVICE_ATTR(pwm1, 0644,
+ show_pwm, set_pwm, 1);
+static SENSOR_DEVICE_ATTR(pwm2, 0644,
+ show_pwm, set_pwm, 2);
+static SENSOR_DEVICE_ATTR(pwm3, 0644,
+ show_pwm, set_pwm, 3);
+static SENSOR_DEVICE_ATTR(pwm4, 0644,
+ show_pwm, set_pwm, 4);
+static SENSOR_DEVICE_ATTR(pwm5, 0644,
+ show_pwm, set_pwm, 5);
+static SENSOR_DEVICE_ATTR(pwm6, 0644,
+ show_pwm, set_pwm, 6);
+static SENSOR_DEVICE_ATTR(pwm7, 0644,
+ show_pwm, set_pwm, 7);
+static struct attribute *pwm_dev_attrs[] = {
+ &sensor_dev_attr_pwm0.dev_attr.attr,
+ &sensor_dev_attr_pwm1.dev_attr.attr,
+ &sensor_dev_attr_pwm2.dev_attr.attr,
+ &sensor_dev_attr_pwm3.dev_attr.attr,
+ &sensor_dev_attr_pwm4.dev_attr.attr,
+ &sensor_dev_attr_pwm5.dev_attr.attr,
+ &sensor_dev_attr_pwm6.dev_attr.attr,
+ &sensor_dev_attr_pwm7.dev_attr.attr,
+ NULL,
+};
+
+static const struct attribute_group pwm_dev_group = {
+ .attrs = pwm_dev_attrs,
+ .is_visible = pwm_is_visible,
+};
+
+static SENSOR_DEVICE_ATTR(fan0_input, 0444,
+ show_rpm, NULL, 0);
+static SENSOR_DEVICE_ATTR(fan1_input, 0444,
+ show_rpm, NULL, 1);
+static SENSOR_DEVICE_ATTR(fan2_input, 0444,
+ show_rpm, NULL, 2);
+static SENSOR_DEVICE_ATTR(fan3_input, 0444,
+ show_rpm, NULL, 3);
+static SENSOR_DEVICE_ATTR(fan4_input, 0444,
+ show_rpm, NULL, 4);
+static SENSOR_DEVICE_ATTR(fan5_input, 0444,
+ show_rpm, NULL, 5);
+static SENSOR_DEVICE_ATTR(fan6_input, 0444,
+ show_rpm, NULL, 6);
+static SENSOR_DEVICE_ATTR(fan7_input, 0444,
+ show_rpm, NULL, 7);
+static SENSOR_DEVICE_ATTR(fan8_input, 0444,
+ show_rpm, NULL, 8);
+static SENSOR_DEVICE_ATTR(fan9_input, 0444,
+ show_rpm, NULL, 9);
+static SENSOR_DEVICE_ATTR(fan10_input, 0444,
+ show_rpm, NULL, 10);
+static SENSOR_DEVICE_ATTR(fan11_input, 0444,
+ show_rpm, NULL, 11);
+static SENSOR_DEVICE_ATTR(fan12_input, 0444,
+ show_rpm, NULL, 12);
+static SENSOR_DEVICE_ATTR(fan13_input, 0444,
+ show_rpm, NULL, 13);
+static SENSOR_DEVICE_ATTR(fan14_input, 0444,
+ show_rpm, NULL, 14);
+static SENSOR_DEVICE_ATTR(fan15_input, 0444,
+ show_rpm, NULL, 15);
+static struct attribute *fan_dev_attrs[] = {
+ &sensor_dev_attr_fan0_input.dev_attr.attr,
+ &sensor_dev_attr_fan1_input.dev_attr.attr,
+ &sensor_dev_attr_fan2_input.dev_attr.attr,
+ &sensor_dev_attr_fan3_input.dev_attr.attr,
+ &sensor_dev_attr_fan4_input.dev_attr.attr,
+ &sensor_dev_attr_fan5_input.dev_attr.attr,
+ &sensor_dev_attr_fan6_input.dev_attr.attr,
+ &sensor_dev_attr_fan7_input.dev_attr.attr,
+ &sensor_dev_attr_fan8_input.dev_attr.attr,
+ &sensor_dev_attr_fan9_input.dev_attr.attr,
+ &sensor_dev_attr_fan10_input.dev_attr.attr,
+ &sensor_dev_attr_fan11_input.dev_attr.attr,
+ &sensor_dev_attr_fan12_input.dev_attr.attr,
+ &sensor_dev_attr_fan13_input.dev_attr.attr,
+ &sensor_dev_attr_fan14_input.dev_attr.attr,
+ &sensor_dev_attr_fan15_input.dev_attr.attr,
+ NULL
+};
+
+static const struct attribute_group fan_dev_group = {
+ .attrs = fan_dev_attrs,
+ .is_visible = fan_dev_is_visible,
+};
+
+/*
+ * The clock type is type M :
+ * The PWM frequency = 24MHz / (type M clock division L bit *
+ * type M clock division H bit * (type M PWM period bit + 1))
+ */
+static void aspeed_create_type(struct aspeed_pwm_tacho_data *priv)
+{
+ priv->type_pwm_clock_division_h[TYPEM] = M_PWM_DIV_H;
+ priv->type_pwm_clock_division_l[TYPEM] = M_PWM_DIV_L;
+ priv->type_pwm_clock_unit[TYPEM] = M_PWM_PERIOD;
+ aspeed_set_pwm_clock_values(priv->regmap, TYPEM, M_PWM_DIV_H,
+ M_PWM_DIV_L, M_PWM_PERIOD);
+ aspeed_set_tacho_type_enable(priv->regmap, TYPEM, true);
+ priv->type_fan_tach_clock_division[TYPEM] = M_TACH_CLK_DIV;
+ priv->type_fan_tach_unit[TYPEM] = M_TACH_UNIT;
+ aspeed_set_tacho_type_values(priv->regmap, TYPEM, M_TACH_MODE,
+ M_TACH_UNIT, M_TACH_CLK_DIV);
+}
+
+static void aspeed_create_pwm_port(struct aspeed_pwm_tacho_data *priv,
+ u8 pwm_port)
+{
+ aspeed_set_pwm_port_enable(priv->regmap, pwm_port, true);
+ priv->pwm_present[pwm_port] = true;
+
+ priv->pwm_port_type[pwm_port] = TYPEM;
+ aspeed_set_pwm_port_type(priv->regmap, pwm_port, TYPEM);
+
+ priv->pwm_port_fan_ctrl[pwm_port] = INIT_FAN_CTRL;
+ aspeed_set_pwm_port_fan_ctrl(priv, pwm_port, INIT_FAN_CTRL);
+}
+
+static void aspeed_create_fan_tach_channel(struct aspeed_pwm_tacho_data *priv,
+ u8 *fan_tach_ch,
+ int count,
+ u8 pwm_source)
+{
+ u8 val, index;
+
+ for (val = 0; val < count; val++) {
+ index = fan_tach_ch[val];
+ aspeed_set_fan_tach_ch_enable(priv->regmap, index, true);
+ priv->fan_tach_present[index] = true;
+ priv->fan_tach_ch_source[index] = pwm_source;
+ aspeed_set_fan_tach_ch_source(priv->regmap, index, pwm_source);
+ }
+}
+
+static int aspeed_create_fan(struct device *dev,
+ struct device_node *child,
+ struct aspeed_pwm_tacho_data *priv)
+{
+ u8 *fan_tach_ch;
+ u32 pwm_port;
+ int ret, count;
+
+ ret = of_property_read_u32(child, "reg", &pwm_port);
+ if (ret)
+ return ret;
+ aspeed_create_pwm_port(priv, (u8)pwm_port);
+
+ count = of_property_count_u8_elems(child, "aspeed,fan-tach-ch");
+ if (count < 1)
+ return -EINVAL;
+ fan_tach_ch = devm_kzalloc(dev, sizeof(*fan_tach_ch) * count,
+ GFP_KERNEL);
+ if (!fan_tach_ch)
+ return -ENOMEM;
+ ret = of_property_read_u8_array(child, "aspeed,fan-tach-ch",
+ fan_tach_ch, count);
+ if (ret)
+ return ret;
+ aspeed_create_fan_tach_channel(priv, fan_tach_ch, count, pwm_port);
+
+ return 0;
+}
+
+static int aspeed_pwm_tacho_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np, *child;
+ struct aspeed_pwm_tacho_data *priv;
+ void __iomem *regs;
+ struct resource *res;
+ struct device *hwmon;
+ struct clk *clk;
+ int ret;
+
+ np = dev->of_node;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENOENT;
+ regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(regs))
+ return PTR_ERR(regs);
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+ priv->regmap = devm_regmap_init(dev, NULL, regs,
+ &aspeed_pwm_tacho_regmap_config);
+ if (IS_ERR(priv->regmap))
+ return PTR_ERR(priv->regmap);
+ regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE, 0);
+ regmap_write(priv->regmap, ASPEED_PTCR_TACH_SOURCE_EXT, 0);
+
+ clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(clk))
+ return -ENODEV;
+ priv->clk_freq = clk_get_rate(clk);
+ aspeed_set_clock_enable(priv->regmap, true);
+ aspeed_set_clock_source(priv->regmap, 0);
+
+ aspeed_create_type(priv);
+
+ for_each_child_of_node(np, child) {
+ ret = aspeed_create_fan(dev, child, priv);
+ of_node_put(child);
+ if (ret)
+ return ret;
+ }
+ of_node_put(np);
+
+ priv->groups[0] = &pwm_dev_group;
+ priv->groups[1] = &fan_dev_group;
+ priv->groups[2] = NULL;
+ hwmon = devm_hwmon_device_register_with_groups(dev,
+ "aspeed_pwm_tacho",
+ priv, priv->groups);
+
+ return PTR_ERR_OR_ZERO(hwmon);
+}
+
+static const struct of_device_id of_pwm_tacho_match_table[] = {
+ { .compatible = "aspeed,ast2400-pwm-tacho", },
+ { .compatible = "aspeed,ast2500-pwm-tacho", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_pwm_tacho_match_table);
+
+static struct platform_driver aspeed_pwm_tacho_driver = {
+ .probe = aspeed_pwm_tacho_probe,
+ .driver = {
+ .name = "aspeed_pwm_tacho",
+ .of_match_table = of_pwm_tacho_match_table,
+ },
+};
+
+module_platform_driver(aspeed_pwm_tacho_driver);
+
+MODULE_AUTHOR("Jaghathiswari Rankappagounder Natarajan <jaghu@google.com>");
+MODULE_DESCRIPTION("ASPEED PWM and Fan Tacho device driver");
+MODULE_LICENSE("GPL");
--
2.12.2.715.g7642488e1d-goog
^ permalink raw reply related
* [PATCH linux v6 1/2] Documentation: dt-bindings: Document bindings for ASPEED AST2400/AST2500 PWM and Fan tach controller device driver
From: Jaghathiswari Rankappagounder Natarajan @ 2017-04-03 23:30 UTC (permalink / raw)
To: joel, jdelvare, linux, linux-hwmon, linux-kernel, openbmc, corbet,
linux-doc, robh+dt, mark.rutland, devicetree
Cc: Jaghathiswari Rankappagounder Natarajan
In-Reply-To: <20170403233025.26952-1-jaghu@google.com>
This binding provides interface for adding values related to ASPEED
AST2400/2500 PWM and Fan tach controller support.
The PWM controller can support upto 8 PWM output ports.
The Fan tach controller can support upto 16 tachometer inputs.
Signed-off-by: Jaghathiswari Rankappagounder Natarajan <jaghu@google.com>
---
v6:
- Changed to aspeed,fan-tach-ch
v5:
- Changed the naming scheme to aspeed,ast2400/2500-pwm-tacho
- Removed gpio pin muxing
- Added aspeed vendor prefix for fan-tach-ch
- Changed to fan@0/1
- Changed reg to 32 bits
v4:
- Used 'reg'
v3:
- Made the structure more common
v2:
- Removed '_' in node and property names
- Gave some explanation for the properties used
.../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 68 ++++++++++++++++++++++
1 file changed, 68 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
diff --git a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
new file mode 100644
index 000000000000..ac0a69ab0755
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
@@ -0,0 +1,68 @@
+ASPEED AST2400/AST2500 PWM and Fan Tacho controller device driver
+
+The ASPEED PWM controller can support upto 8 PWM outputs. The ASPEED Fan Tacho
+controller can support upto 16 Fan tachometer inputs.
+
+There can be upto 8 fans supported. Each fan can have one PWM output and
+one/two Fan tach inputs.
+
+Required properties for pwm-tacho node:
+- #address-cells : should be 1.
+
+- #size-cells : should be 1.
+
+- reg : address and length of the register set for the device.
+
+- pinctrl-names : a pinctrl state named "default" must be defined.
+
+- pinctrl-0 : phandle referencing pin configuration of the PWM ports.
+
+- compatible : should be "aspeed,ast2400-pwm-tacho" for AST2400 and
+ "aspeed,ast2500-pwm-tacho" for AST2500.
+
+- clocks : a fixed clock providing input clock frequency(PWM
+ and Fan Tach clock)
+
+fan subnode format:
+===================
+Under fan subnode there can upto 8 child nodes, with each child node
+representing a fan. If there are 8 fans each fan can have one PWM port and
+one/two Fan tach inputs.
+
+Required properties for each child node:
+- reg : should specify PWM source port.
+ integer value in the range 0 to 7 with 0 indicating PWM port A and
+ 7 indicating PWM port H.
+
+- aspeed,fan-tach-ch : should specify the Fan tach input channel.
+ integer value in the range 0 through 15, with 0 indicating
+ Fan tach channel 0 and 15 indicating Fan tach channel 15.
+ Atleast one Fan tach input channel is required.
+
+Examples:
+
+pwm_tacho_fixed_clk: fixedclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24000000>;
+}
+
+pwm_tacho: pwmtachocontroller@1e786000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x1E786000 0x1000>;
+ compatible = "aspeed,ast2500-pwm-tacho";
+ clocks = <&pwm_tacho_fixed_clk>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm0_default &pinctrl_pwm1_default>;
+
+ fan@0 {
+ reg = <0x00>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x00>;
+ };
+
+ fan@1 {
+ reg = <0x01>;
+ aspeed,fan-tach-ch = /bits/ 8 <0x01 0x02>;
+ };
+};
--
2.12.2.715.g7642488e1d-goog
^ permalink raw reply related
* [PATCH linux v6 0/2] Support for ASPEED AST2400/AST2500 PWM and Fan Tach driver
From: Jaghathiswari Rankappagounder Natarajan @ 2017-04-03 23:30 UTC (permalink / raw)
To: joel, jdelvare, linux, linux-hwmon, linux-kernel, openbmc, corbet,
linux-doc, robh+dt, mark.rutland, devicetree
Cc: Jaghathiswari Rankappagounder Natarajan
Support for ASPEED AST2400/AST2500 PWM and Fan Tach driver.
Patches based on the upstream tag 4.9. Changes made in Version 4 are indicated
in the individual patches.
The AST2400/AST2500 PWM controller can support 8 PWM output ports.
The AST2400/AST2500 Fan Tach controller can support 16 tachometer inputs.
The hwmon driver provides sysfs entries through which the user can configure the
duty cycle for the particular PWM output port and read the fan rpm value for
the particular tachometer input.
Added devicetree binding documentation for AST2400/AST2500 PWM and Fan Tach
support.
Tested on Zaius board (which has AST2500 chip) and observed that when
duty cycle is lowered then the fan speed is lowered and lower fan rpm value(
corresponding to the duty cycle) is reported and when the duty cycle is
increased then the fan speed increases and higher fan rpm value(corresponding
to the duty cycle) is reported.
Jaghathiswari Rankappagounder Natarajan (2):
Documentation: dt-bindings: Document bindings for ASPEED
AST2400/AST2500 PWM and Fan tach controller device driver
drivers: hwmon: Support for ASPEED PWM/Fan tach
.../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 68 ++
Documentation/hwmon/aspeed-pwm-tacho | 22 +
drivers/hwmon/Kconfig | 9 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/aspeed-pwm-tacho.c | 846 +++++++++++++++++++++
5 files changed, 946 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
create mode 100644 Documentation/hwmon/aspeed-pwm-tacho
create mode 100644 drivers/hwmon/aspeed-pwm-tacho.c
--
2.12.2.715.g7642488e1d-goog
^ permalink raw reply
* Re: [PATCH v3 2/7] mfd: retu: Add OF device ID table
From: Javier Martinez Canillas @ 2017-04-03 23:00 UTC (permalink / raw)
To: Tony Lindgren, Aaro Koskinen
Cc: Rob Herring, Lee Jones, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Linux-OMAP
In-Reply-To: <20170403225813.GJ10760-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Hello Aaro and Tony,
On 04/03/2017 06:58 PM, Tony Lindgren wrote:
> * Aaro Koskinen <aaro.koskinen-X3B1VOXEql0@public.gmane.org> [170403 15:56]:
>> Hi,
>>
>> On Mon, Apr 03, 2017 at 06:24:39PM -0400, Javier Martinez Canillas wrote:
>>> On 04/03/2017 06:20 PM, Rob Herring wrote:
>>>> On Mon, Apr 03, 2017 at 11:45:14AM -0400, Javier Martinez Canillas wrote:
>>>>> Hello Lee,
>>>>>
>>>>> On 04/03/2017 07:15 AM, Lee Jones wrote:
>>>>>
>>>>> [snip]
>>>>>
>>>>>>>
>>>>>>> +static const struct of_device_id retu_of_match[] = {
>>>>>>> + { .compatible = "nokia,retu-mfd" },
>>>>>>> + { .compatible = "nokia,tahvo-mfd" },
>>>>>>
>>>>>> Please drop the "-mfd".
>>>>>>
>>>>>
>>>>> Yes, I also didn't like it but I didn't want to change it since that would
>>>>> mean that backward compatiblity and bisect-ability will be broken by this
>>>>> change.
>>>>>
>>>>> In other words, just adding a vendor prefix won't cause an issue if patches
>>>>> are merged independently since if DTS patches are merged before, the driver
>>>>> will still lookup using the I2C device ID table. And if the drivers patches
>>>>> are picked before, the DTS will match using the OF device ID table.
>>>>>
>>>>> But changing to "nokia,retu" and "nokia,tahvo" means that you will need to
>>>>> pick all patches and also that the DTS and drivers changes will have to be
>>>>> done in the same patch. If you are OK with that, then I can change in the
>>>>> next version.
>>>>
>>>> tahvo is not documented nor used in any dts (in the kernel at least).
>>
>> True, there are no known DT users of Tahvo.
>>
>>>> retu is used by 1 board and happened to work, but was never documented.
>>>> So I think it is okay to change unless the N800 folks object.
>>>
>>> I'm fine with changing it (in fact I just want to fix the I2C of modalias
>>> reporting). Does this mean that backward compatibility and bisect-ability
>>> should be preserved? Or it's OK to split the changes in different patches?
>>
>> There are 2 boards actually, N800 and N810. Retu is critical, because
>> if retu-mfd/watchdog fails to probe the device will power off soon after
>> boot. So for bisect-ability you should make changes in a single patch.
>
Thanks for the confirmation. I'll squash the changes then in a single patch
to maintain bisect-ability.
> Also I wonder if this will work with arch/arm/mach-omap1/board-nokia770.c
> that does I2C_BOARD_INFO("tahvo-mfd", 0x02). Seems they all need to be
> changed with a single patch?
>
Yes, it has to be changed as well. So I guess that makes more sense if the
changes goes through your tree since is not only driver + DTS.
> Regards,
>
> Tony
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 v3 2/7] mfd: retu: Add OF device ID table
From: Tony Lindgren @ 2017-04-03 22:58 UTC (permalink / raw)
To: Aaro Koskinen
Cc: Javier Martinez Canillas, Rob Herring, Lee Jones, linux-kernel,
devicetree, Linux-OMAP
In-Reply-To: <20170403225342.eqyh3van4q6bxpuv@raspberrypi-3.musicnaut.iki.fi>
* Aaro Koskinen <aaro.koskinen@iki.fi> [170403 15:56]:
> Hi,
>
> On Mon, Apr 03, 2017 at 06:24:39PM -0400, Javier Martinez Canillas wrote:
> > On 04/03/2017 06:20 PM, Rob Herring wrote:
> > > On Mon, Apr 03, 2017 at 11:45:14AM -0400, Javier Martinez Canillas wrote:
> > >> Hello Lee,
> > >>
> > >> On 04/03/2017 07:15 AM, Lee Jones wrote:
> > >>
> > >> [snip]
> > >>
> > >>>>
> > >>>> +static const struct of_device_id retu_of_match[] = {
> > >>>> + { .compatible = "nokia,retu-mfd" },
> > >>>> + { .compatible = "nokia,tahvo-mfd" },
> > >>>
> > >>> Please drop the "-mfd".
> > >>>
> > >>
> > >> Yes, I also didn't like it but I didn't want to change it since that would
> > >> mean that backward compatiblity and bisect-ability will be broken by this
> > >> change.
> > >>
> > >> In other words, just adding a vendor prefix won't cause an issue if patches
> > >> are merged independently since if DTS patches are merged before, the driver
> > >> will still lookup using the I2C device ID table. And if the drivers patches
> > >> are picked before, the DTS will match using the OF device ID table.
> > >>
> > >> But changing to "nokia,retu" and "nokia,tahvo" means that you will need to
> > >> pick all patches and also that the DTS and drivers changes will have to be
> > >> done in the same patch. If you are OK with that, then I can change in the
> > >> next version.
> > >
> > > tahvo is not documented nor used in any dts (in the kernel at least).
>
> True, there are no known DT users of Tahvo.
>
> > > retu is used by 1 board and happened to work, but was never documented.
> > > So I think it is okay to change unless the N800 folks object.
> >
> > I'm fine with changing it (in fact I just want to fix the I2C of modalias
> > reporting). Does this mean that backward compatibility and bisect-ability
> > should be preserved? Or it's OK to split the changes in different patches?
>
> There are 2 boards actually, N800 and N810. Retu is critical, because
> if retu-mfd/watchdog fails to probe the device will power off soon after
> boot. So for bisect-ability you should make changes in a single patch.
Also I wonder if this will work with arch/arm/mach-omap1/board-nokia770.c
that does I2C_BOARD_INFO("tahvo-mfd", 0x02). Seems they all need to be
changed with a single patch?
Regards,
Tony
^ permalink raw reply
* Re: [PATCH v2 0/5] Add ARM Mali Midgard device tree bindings and gpu node for rk3288
From: Heiko Stübner @ 2017-04-03 22:54 UTC (permalink / raw)
To: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Guillaume Tucker, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Sjoerd Simons, Wookey,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, John Reitan,
Enric Balletbo i Serra,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <cover.1491118230.git.guillaume.tucker-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
Hi Guillaume,
please keep in mind to also add me (as Rockchip maintainer) as recipient in
further submissions - as also listed by scripts/get_maintainer.pl.
Thanks
Heiko
Am Sonntag, 2. April 2017, 08:59:43 CEST schrieb Guillaume Tucker:
> The ARM Mali Midgard GPU kernel driver is only available
> out-of-tree and is not going to be merged in its current form.
> However, it would be useful to have its device tree bindings
> merged. In particular, this would enable distributions to create
> working driver packages (dkms...) without having to patch the
> kernel.
>
> The bindings for the earlier Mali Utgard GPU family have already
> been merged, so this is essentially the same scenario but for
> newer GPUs (Mali-T604 ~ Mali-T880).
>
> This series of patches first imports the bindings from the latest
> driver release with some clean-up then adds a gpu node for the
> rk3288 SoC. This was successfully tested on Radxa Rock2 Square,
> Firefly, Veyron Minnie and Jerry boards board using Mali kernel
> driver r16p0 and r12p0 user-space binary.
>
> Changes since v1:
> - enabled gpu on rk3288-veyron boards
>
> Enric Balletbo i Serra (1):
> ARM: dts: rockchip: enable ARM Mali GPU on rk3288-veyron
>
> Guillaume Tucker (4):
> dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
> ARM: dts: rockchip: add ARM Mali GPU node for rk3288
> ARM: dts: rockchip: enable ARM Mali GPU on rk3288-rock2-som
> ARM: dts: rockchip: enable ARM Mali GPU on rk3288-firefly
>
> .../devicetree/bindings/gpu/arm,mali-midgard.txt | 53
> ++++++++++++++++++++++ arch/arm/boot/dts/rk3288-firefly.dtsi |
> 5 ++
> arch/arm/boot/dts/rk3288-rock2-som.dtsi | 5 ++
> arch/arm/boot/dts/rk3288-veyron.dtsi | 5 ++
> arch/arm/boot/dts/rk3288.dtsi | 23 ++++++++++
> 5 files changed, 91 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt
>
> --
> 2.11.0
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
--
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 v3 2/7] mfd: retu: Add OF device ID table
From: Aaro Koskinen @ 2017-04-03 22:53 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Rob Herring, Lee Jones, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren, Linux-OMAP
In-Reply-To: <a852be9e-e1f0-0975-abd0-a4a61f3a9750-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Hi,
On Mon, Apr 03, 2017 at 06:24:39PM -0400, Javier Martinez Canillas wrote:
> On 04/03/2017 06:20 PM, Rob Herring wrote:
> > On Mon, Apr 03, 2017 at 11:45:14AM -0400, Javier Martinez Canillas wrote:
> >> Hello Lee,
> >>
> >> On 04/03/2017 07:15 AM, Lee Jones wrote:
> >>
> >> [snip]
> >>
> >>>>
> >>>> +static const struct of_device_id retu_of_match[] = {
> >>>> + { .compatible = "nokia,retu-mfd" },
> >>>> + { .compatible = "nokia,tahvo-mfd" },
> >>>
> >>> Please drop the "-mfd".
> >>>
> >>
> >> Yes, I also didn't like it but I didn't want to change it since that would
> >> mean that backward compatiblity and bisect-ability will be broken by this
> >> change.
> >>
> >> In other words, just adding a vendor prefix won't cause an issue if patches
> >> are merged independently since if DTS patches are merged before, the driver
> >> will still lookup using the I2C device ID table. And if the drivers patches
> >> are picked before, the DTS will match using the OF device ID table.
> >>
> >> But changing to "nokia,retu" and "nokia,tahvo" means that you will need to
> >> pick all patches and also that the DTS and drivers changes will have to be
> >> done in the same patch. If you are OK with that, then I can change in the
> >> next version.
> >
> > tahvo is not documented nor used in any dts (in the kernel at least).
True, there are no known DT users of Tahvo.
> > retu is used by 1 board and happened to work, but was never documented.
> > So I think it is okay to change unless the N800 folks object.
>
> I'm fine with changing it (in fact I just want to fix the I2C of modalias
> reporting). Does this mean that backward compatibility and bisect-ability
> should be preserved? Or it's OK to split the changes in different patches?
There are 2 boards actually, N800 and N810. Retu is critical, because
if retu-mfd/watchdog fails to probe the device will power off soon after
boot. So for bisect-ability you should make changes in a single patch.
A.
--
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 v3 2/7] mfd: retu: Add OF device ID table
From: Javier Martinez Canillas @ 2017-04-03 22:24 UTC (permalink / raw)
To: Rob Herring
Cc: Lee Jones, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren, Linux-OMAP,
Aaro Koskinen
In-Reply-To: <20170403222010.xgbf7imyieyfroqr@rob-hp-laptop>
[adding OMAP folks to cc list]
Hello Rob,
On 04/03/2017 06:20 PM, Rob Herring wrote:
> On Mon, Apr 03, 2017 at 11:45:14AM -0400, Javier Martinez Canillas wrote:
>> Hello Lee,
>>
>> On 04/03/2017 07:15 AM, Lee Jones wrote:
>>
>> [snip]
>>
>>>>
>>>> +static const struct of_device_id retu_of_match[] = {
>>>> + { .compatible = "nokia,retu-mfd" },
>>>> + { .compatible = "nokia,tahvo-mfd" },
>>>
>>> Please drop the "-mfd".
>>>
>>
>> Yes, I also didn't like it but I didn't want to change it since that would
>> mean that backward compatiblity and bisect-ability will be broken by this
>> change.
>>
>> In other words, just adding a vendor prefix won't cause an issue if patches
>> are merged independently since if DTS patches are merged before, the driver
>> will still lookup using the I2C device ID table. And if the drivers patches
>> are picked before, the DTS will match using the OF device ID table.
>>
>> But changing to "nokia,retu" and "nokia,tahvo" means that you will need to
>> pick all patches and also that the DTS and drivers changes will have to be
>> done in the same patch. If you are OK with that, then I can change in the
>> next version.
>
> tahvo is not documented nor used in any dts (in the kernel at least).
> retu is used by 1 board and happened to work, but was never documented.
> So I think it is okay to change unless the N800 folks object.
>
I'm fine with changing it (in fact I just want to fix the I2C of modalias
reporting). Does this mean that backward compatibility and bisect-ability
should be preserved? Or it's OK to split the changes in different patches?
> Rob
>
Best regards,
---
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 v3 2/7] mfd: retu: Add OF device ID table
From: Rob Herring @ 2017-04-03 22:20 UTC (permalink / raw)
To: Javier Martinez Canillas; +Cc: Lee Jones, linux-kernel, devicetree
In-Reply-To: <2147b8c9-02ee-1b9c-a74e-119b0b73d1d7@osg.samsung.com>
On Mon, Apr 03, 2017 at 11:45:14AM -0400, Javier Martinez Canillas wrote:
> Hello Lee,
>
> On 04/03/2017 07:15 AM, Lee Jones wrote:
>
> [snip]
>
> >>
> >> +static const struct of_device_id retu_of_match[] = {
> >> + { .compatible = "nokia,retu-mfd" },
> >> + { .compatible = "nokia,tahvo-mfd" },
> >
> > Please drop the "-mfd".
> >
>
> Yes, I also didn't like it but I didn't want to change it since that would
> mean that backward compatiblity and bisect-ability will be broken by this
> change.
>
> In other words, just adding a vendor prefix won't cause an issue if patches
> are merged independently since if DTS patches are merged before, the driver
> will still lookup using the I2C device ID table. And if the drivers patches
> are picked before, the DTS will match using the OF device ID table.
>
> But changing to "nokia,retu" and "nokia,tahvo" means that you will need to
> pick all patches and also that the DTS and drivers changes will have to be
> done in the same patch. If you are OK with that, then I can change in the
> next version.
tahvo is not documented nor used in any dts (in the kernel at least).
retu is used by 1 board and happened to work, but was never documented.
So I think it is okay to change unless the N800 folks object.
Rob
^ permalink raw reply
* Re: [PATCH] Input: silead - list all supported compatible strings in binding document
From: Javier Martinez Canillas @ 2017-04-03 21:23 UTC (permalink / raw)
To: Rob Herring
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Robert Dolca, Hans de Goede, Dmitry Torokhov,
linux-input@vger.kernel.org, Mark Rutland
In-Reply-To: <CAL_JsqLwxROZ=H9rBx6PKTR6m55B+nyoskfSLbtrrsHojFDgJw@mail.gmail.com>
Hello Rob,
On 04/03/2017 05:15 PM, Rob Herring wrote:
> On Mon, Apr 3, 2017 at 10:51 AM, Javier Martinez Canillas
> <javier@osg.samsung.com> wrote:
>> Hello Rob,
>>
>> On 04/03/2017 11:25 AM, Rob Herring wrote:
>>> On Wed, Mar 29, 2017 at 02:25:31PM -0400, Javier Martinez Canillas wrote:
>>>> The driver contains compatible strings for different models, but the DT
>>>> binding doc only lists one of them. Add the remaining to the document.
>>>>
>>>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>>>> ---
>>>>
>>>> .../devicetree/bindings/input/touchscreen/silead_gsl1680.txt | 7 ++++++-
>>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> "dt-bindings: input: ..." is preferred for the subject, but no need to
>>> respin just for that.
>>>
>>
>> Can we document it in Documentation/devicetree/bindings/submitting-patches.txt?
>
> Yes. Actually, I was thinking of adding the preferred prefixes to
> MAINTAINERS. Then checkpatch.pl could check it perhaps.
>
That would be great.
>> I'm asking because is true that at the beginning we used "dt-bindings: foo" for
>> all DT bindings patches but then many (most?) maintainers started asking for the
>> subsystem subject line to be used for both drivers and DT bindings docs since
>> they would be merging both and also they could miss the DT bindings patches if
>> their subsystem prefix was not used.
>
> I'd argue that most subsys maintainers don't (or they just change it
> when applying). Mark B does the most. I'm not going to waste any time
> arguing over it if folks want something different. I'm mainly trying
> to get rid of subjects like "Documentation: devicetree: bindings:
> Document the DT binding for foo-bar". :)
>
Yeah, I don't have a strong opinion. I just want an authoritative doc
so I can refer subsystems maintainers to when they argue that I should
use their subsystem prefix instead of "dt-bindings: foo: ..." :)
> Rob
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH v2] ARM: dts: imx: add Gateworks Ventana GW5903 support
From: Tim Harvey @ 2017-04-03 21:18 UTC (permalink / raw)
To: shawnguo-DgEjT+Ai2ygdnm+yROfE0A
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490125452-5712-1-git-send-email-tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org>
The Gateworks Ventana GW5903 is a single-board computer based on the NXP
IMX6 SoC with the following features:
* IMX6 DualLite Soc (supports IMX6S,IMX6DL,IMX6Q)
* 4GiB DDR3 DRAM
* 32GB eMMC
* 1x microSD connector
* Gateworks System Controller:
- hardware watchdog
- hardware monitor
- pushbutton controller
- EEPROM storage
- power control
* JTAG programmable
* Inertial Module
* uBlox EMMY-W1 (bluetooth/nfc/802.11ac)
Signed-off-by: Tim Harvey <tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org>
---
v2:
- use stdout-path
- un-comment various brightness levels
- fix led gpio
- fix typo in comment
- remove unsupported bindings
- removed unnecessary status binding from i2c device node
- removed newline in property list
- name accelerometer node
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx6dl-gw5903.dts | 55 +++
arch/arm/boot/dts/imx6q-gw5903.dts | 55 +++
arch/arm/boot/dts/imx6qdl-gw5903.dtsi | 654 ++++++++++++++++++++++++++++++++++
4 files changed, 766 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-gw5903.dts
create mode 100644 arch/arm/boot/dts/imx6q-gw5903.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-gw5903.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index abdd0db..0bff8e7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -352,6 +352,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-gw551x.dtb \
imx6dl-gw552x.dtb \
imx6dl-gw553x.dtb \
+ imx6dl-gw5903.dtb \
imx6dl-gw5904.dtb \
imx6dl-hummingboard.dtb \
imx6dl-icore.dtb \
@@ -396,6 +397,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-gw551x.dtb \
imx6q-gw552x.dtb \
imx6q-gw553x.dtb \
+ imx6q-gw5903.dtb \
imx6q-gw5904.dtb \
imx6q-h100.dtb \
imx6q-hummingboard.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-gw5903.dts b/arch/arm/boot/dts/imx6dl-gw5903.dts
new file mode 100644
index 0000000..103261e
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-gw5903.dts
@@ -0,0 +1,55 @@
+/*
+ * Copyright 2017 Gateworks Corporation
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "imx6dl.dtsi"
+#include "imx6qdl-gw5903.dtsi"
+
+/ {
+ model = "Gateworks Ventana i.MX6 Duallite/Solo GW5903";
+ compatible = "gw,imx6dl-gw5903", "gw,ventana", "fsl,imx6dl";
+};
diff --git a/arch/arm/boot/dts/imx6q-gw5903.dts b/arch/arm/boot/dts/imx6q-gw5903.dts
new file mode 100644
index 0000000..a182e4c
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-gw5903.dts
@@ -0,0 +1,55 @@
+/*
+ * Copyright 2017 Gateworks Corporation
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "imx6q.dtsi"
+#include "imx6qdl-gw5903.dtsi"
+
+/ {
+ model = "Gateworks Ventana i.MX6 Dual/Quad GW5903";
+ compatible = "gw,imx6q-gw5903", "gw,ventana", "fsl,imx6q";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-gw5903.dtsi b/arch/arm/boot/dts/imx6qdl-gw5903.dtsi
new file mode 100644
index 0000000..4444251
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-gw5903.dtsi
@@ -0,0 +1,654 @@
+/*
+ * Copyright 2017 Gateworks Corporation
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ chosen {
+ stdout-path = &uart2;
+ };
+
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm1 0 5000000>;
+ brightness-levels = <
+ 0 1 2 3 4 5 6 7 8 9
+ 10 11 12 13 14 15 16 17 18 19
+ 20 21 22 23 24 25 26 27 28 29
+ 30 31 32 33 34 35 36 37 38 39
+ 40 41 42 43 44 45 46 47 48 49
+ 50 51 52 53 54 55 56 57 58 59
+ 60 61 62 63 64 65 66 67 68 69
+ 70 71 72 73 74 75 76 77 78 79
+ 80 81 82 83 84 85 86 87 88 89
+ 90 91 92 93 94 95 96 97 98 99
+ 100
+ >;
+ default-brightness-level = <100>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_leds>;
+
+ led0: user1 {
+ label = "user1";
+ gpios = <&gpio6 14 GPIO_ACTIVE_LOW>; /* MX6_LOCLED# */
+ default-state = "off";
+ };
+ };
+
+ memory {
+ reg = <0x10000000 0x40000000>;
+ };
+
+ reg_5p0v: regulator-5p0v {
+ compatible = "regulator-fixed";
+ regulator-name = "5P0V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_2p5v: regulator-2p5v {
+ compatible = "regulator-fixed";
+ regulator-name = "2P5V";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-always-on;
+ };
+
+ reg_usb_h1_vbus: regulator-usb-h1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio3 30 0>;
+ enable-active-high;
+ };
+
+ reg_usb_otg_vbus: regulator-usb-otg-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio4 15 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_12p0: regulator-12p0v {
+ compatible = "regulator-fixed";
+ regulator-name = "12P0V";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ gpio = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ sound {
+ compatible = "fsl,imx-audio-tlv320";
+ model = "imx-tlv320";
+ ssi-controller = <&ssi1>;
+ audio-codec = <&tlv320aic3105>;
+ /* routing of sink, source */
+ audio-routing =
+ /* TLV320 LINE1L pin <-> Mic Jack connector */
+ "LINE1L", "Mic Jack",
+ /* board Headphone Jack <-> HPOUT */
+ "Headphone Jack", "HPLOUT",
+ "Headphone Jack", "HPROUT",
+ "Mic Jack", "Mic Bias";
+ mux-int-port = <1>;
+ mux-ext-port = <6>;
+ };
+};
+
+&audmux {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_audmux>;
+ status = "okay";
+};
+
+&clks {
+ assigned-clocks = <&clks IMX6QDL_CLK_LDB_DI0_SEL>,
+ <&clks IMX6QDL_CLK_LDB_DI1_SEL>;
+ assigned-clock-parents = <&clks IMX6QDL_CLK_PLL3_USB_OTG>,
+ <&clks IMX6QDL_CLK_PLL3_USB_OTG>;
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-mode = "rgmii-id";
+ status = "okay";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+
+ pca9555: gpio@23 {
+ compatible = "nxp,pca9555";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ eeprom1: eeprom@50 {
+ compatible = "atmel,24c02";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
+
+ eeprom2: eeprom@51 {
+ compatible = "atmel,24c02";
+ reg = <0x51>;
+ pagesize = <16>;
+ };
+
+ eeprom3: eeprom@52 {
+ compatible = "atmel,24c02";
+ reg = <0x52>;
+ pagesize = <16>;
+ };
+
+ eeprom4: eeprom@53 {
+ compatible = "atmel,24c02";
+ reg = <0x53>;
+ pagesize = <16>;
+ };
+
+ dts1672: rtc@68 {
+ compatible = "dallas,ds1672";
+ reg = <0x68>;
+ };
+};
+
+&i2c2 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+
+ ltc3676: pmic@3c {
+ compatible = "lltc,ltc3676";
+ reg = <0x3c>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <8 IRQ_TYPE_EDGE_FALLING>;
+
+ regulators {
+ /* VDD_1P8 (1+R1/R2 = 2.505): Aud/eMMC/microSD/Touch */
+ reg_1p8v: sw1 {
+ regulator-name = "vdd1p8";
+ regulator-min-microvolt = <1033310>;
+ regulator-max-microvolt = <2004000>;
+ lltc,fb-voltage-divider = <301000 200000>;
+ regulator-ramp-delay = <7000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* VDD_DDR (1+R1/R2 = 2.105) */
+ reg_vdd_ddr: sw2 {
+ regulator-name = "vddddr";
+ regulator-min-microvolt = <868310>;
+ regulator-max-microvolt = <1684000>;
+ lltc,fb-voltage-divider = <221000 200000>;
+ regulator-ramp-delay = <7000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* VDD_ARM (1+R1/R2 = 1.635) */
+ reg_vdd_arm: sw3 {
+ regulator-name = "vddarm";
+ regulator-min-microvolt = <674400>;
+ regulator-max-microvolt = <1308000>;
+ lltc,fb-voltage-divider = <127000 200000>;
+ regulator-ramp-delay = <7000>;
+ regulator-boot-on;
+ regulator-always-on;
+ linux,phandle = <®_vdd_arm>;
+ };
+
+ /* VDD_SOC (1+R1/R2 = 1.635) */
+ reg_vdd_soc: sw4 {
+ regulator-name = "vddsoc";
+ regulator-min-microvolt = <674400>;
+ regulator-max-microvolt = <1308000>;
+ lltc,fb-voltage-divider = <127000 200000>;
+ regulator-ramp-delay = <7000>;
+ regulator-boot-on;
+ regulator-always-on;
+ linux,phandle = <®_vdd_soc>;
+ };
+
+ /* VDD_1P0 (1+R1/R2 = 1.38): */
+ reg_1p0v: ldo2 {
+ regulator-name = "vdd1p0";
+ regulator-min-microvolt = <1002777>;
+ regulator-max-microvolt = <1002777>;
+ lltc,fb-voltage-divider = <100000 261000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* VDD_HIGH (1+R1/R2 = 4.17) */
+ reg_3p0v: ldo4 {
+ regulator-name = "vdd3p0";
+ regulator-min-microvolt = <3023250>;
+ regulator-max-microvolt = <3023250>;
+ lltc,fb-voltage-divider = <634000 200000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&i2c3 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+
+ tlv320aic3105: codec@18 {
+ compatible = "ti,tlv320aic3x";
+ reg = <0x18>;
+ gpio-reset = <&gpio5 17 GPIO_ACTIVE_LOW>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ ai3x-micbias-vg = <2>; /* MICBIAS_2_5V */
+ /* Regulators */
+ DRVDD-supply = <®_3p3v>;
+ AVDD-supply = <®_3p3v>;
+ IOVDD-supply = <®_3p3v>;
+ DVDD-supply = <®_1p8v>;
+ };
+
+ accelerometer@1d {
+ compatible = "fsl,mma8451";
+ reg = <0x1d>;
+ interrupt-parent = <&gpio7>;
+ interrupts = <11 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "INT2";
+ };
+
+ /* headphone detect */
+ ts3a227e@3b {
+ compatible = "ti,ts3a227e";
+ reg = <0x3b>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
+ ti,micbias = <4>; /* 2.5V micbias */
+ };
+};
+
+&ldb {
+ status = "okay";
+
+ lvds-channel@0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <18>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: g101evn010 {
+ clock-frequency = <68930000>;
+ hactive = <1280>;
+ vactive = <800>;
+ hback-porch = <220>;
+ hfront-porch = <40>;
+ vback-porch = <21>;
+ vfront-porch = <7>;
+ hsync-len = <60>;
+ vsync-len = <10>;
+ };
+ };
+ };
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+ status = "okay";
+};
+
+&ssi1 {
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+&usbotg {
+ vbus-supply = <®_usb_otg_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg>;
+ disable-over-current;
+ status = "okay";
+};
+
+&usbh1 {
+ vbus-supply = <®_usb_h1_vbus>;
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1_200mhz>;
+ vmmc-supply = <®_3p3v>;
+ non-removable;
+ bus-width = <4>;
+ status = "okay";
+};
+
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
+ cd-gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <®_3p3v>;
+ max-frequency = <100000000>;
+ status = "okay";
+};
+
+&usdhc3 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+ non-removable;
+ vmmc-supply = <®_3p3v>;
+ keep-power-in-suspend;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+};
+
+&iomuxc {
+ pinctrl_audmux: audmuxgrp {
+ fsl,pins = <
+ MX6QDL_PAD_DI0_PIN2__AUD6_TXD 0x130b0
+ MX6QDL_PAD_DI0_PIN3__AUD6_TXFS 0x130b0
+ MX6QDL_PAD_DI0_PIN4__AUD6_RXD 0x130b0
+ MX6QDL_PAD_DI0_PIN15__AUD6_TXC 0x130b0
+ MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x130b0 /* MCK */
+ >;
+ };
+
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b030
+ MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b030
+ MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b030
+ MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b030
+ MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b030
+ MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b030
+ MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b030
+ MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b030
+ MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b030
+ MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b030
+ MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b030
+ MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b030
+ MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+ MX6QDL_PAD_ENET_TXD0__GPIO1_IO30 0x4001b0b0 /* PHY_RST# */
+ MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x4001b0b0 /* PHY_EN */
+ >;
+ };
+
+ pinctrl_gpio_leds: gpioledsgrp {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x1b0b0
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x0001b0b0 /* GSC_IRQ# */
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_8__GPIO1_IO08 0x0001b0b0 /* PMIC_IRQ# */
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ /* I2C3 */
+ MX6QDL_PAD_GPIO_3__I2C3_SCL 0x4001b8b1
+ MX6QDL_PAD_GPIO_6__I2C3_SDA 0x4001b8b1
+
+ /* Headphone Detect */
+ MX6QDL_PAD_DISP0_DAT21__GPIO5_IO15 0x0001b0b0 /* HPDET_IRQ# */
+ MX6QDL_PAD_DISP0_DAT22__GPIO5_IO16 0x0001b0b0 /* HPDET_MIC# */
+
+ /* Codec */
+ MX6QDL_PAD_DISP0_DAT23__GPIO5_IO17 0x0001b0b0 /* CODEC_RST# */
+
+ /* Touch Controller */
+ MX6QDL_PAD_KEY_COL0__GPIO4_IO06 0x0001b0b0 /* TOUCH_IRQ# */
+ MX6QDL_PAD_KEY_COL1__GPIO4_IO08 0x0001b0b0 /* TOUCH_RST */
+
+ /* Stow Sensor */
+ MX6QDL_PAD_GPIO_16__GPIO7_IO11 0x0001b0b0 /* ACCEL_IRQ2 */
+ MX6QDL_PAD_GPIO_18__GPIO7_IO13 0x0001b0b0 /* ACCEL_IRQ1 */
+ >;
+ };
+
+ pinctrl_pwm1: pwm1grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_9__PWM1_OUT 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
+ MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
+ MX6QDL_PAD_CSI0_DAT12__GPIO5_IO30 0x1b0b1 /* TXEN */
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD4_DAT7__UART2_TX_DATA 0x1b0b1
+ MX6QDL_PAD_SD4_DAT4__UART2_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbotg: usbotggrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x13059
+ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x4001b0b0 /* PWR_EN */
+ MX6QDL_PAD_KEY_COL4__GPIO4_IO14 0x1b0b0 /* OC */
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1grp200mhz {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_D3__GPIO2_IO03 0x4001b0b0 /* EMMY_EN */
+ MX6QDL_PAD_NANDF_D4__GPIO2_IO04 0x4001b0b0 /* EMMY_CFG1# */
+ MX6QDL_PAD_NANDF_D5__GPIO2_IO05 0x4001b0b0 /* EMMY_CFG2# */
+ MX6QDL_PAD_NANDF_D6__GPIO2_IO06 0x0001b0b0 /* EMMY_BTWAKE# */
+ MX6QDL_PAD_NANDF_D7__GPIO2_IO07 0x0001b0b0 /* EMMY_WFWAKE# */
+
+ MX6QDL_PAD_SD1_CLK__SD1_CLK 0x100f9
+ MX6QDL_PAD_SD1_CMD__SD1_CMD 0x100f9
+ MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x170f9
+ MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x170f9
+ MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x170f9
+ MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x170f9
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10059
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17059
+ MX6QDL_PAD_NANDF_CS0__GPIO6_IO11 0x17059 /* CD */
+ MX6QDL_PAD_KEY_ROW1__SD2_VSELECT 0x17059
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2grp100mhz {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170b9
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100b9
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170b9
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170b9
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170b9
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x170b9
+ MX6QDL_PAD_NANDF_CS0__GPIO6_IO11 0x170b9 /* CD */
+ MX6QDL_PAD_KEY_ROW1__SD2_VSELECT 0x170b9
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2grp200mhz {
+ fsl,pins = <
+ MX6QDL_PAD_SD2_CMD__SD2_CMD 0x170f9
+ MX6QDL_PAD_SD2_CLK__SD2_CLK 0x100f9
+ MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x170f9
+ MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x170f9
+ MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x170f9
+ MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x170f9
+ MX6QDL_PAD_NANDF_CS0__GPIO6_IO11 0x170f9 /* CD */
+ MX6QDL_PAD_KEY_ROW1__SD2_VSELECT 0x170f9
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
+ MX6QDL_PAD_SD3_RST__SD3_RESET 0x10059
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+ MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
+ MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
+ MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
+ MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3grp100mhz {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x170b9
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x100b9
+ MX6QDL_PAD_SD3_RST__SD3_RESET 0x100b9
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x170b9
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x170b9
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x170b9
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x170b9
+ MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x170b9
+ MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x170b9
+ MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x170b9
+ MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x170b9
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3grp200mhz {
+ fsl,pins = <
+ MX6QDL_PAD_SD3_CMD__SD3_CMD 0x170f9
+ MX6QDL_PAD_SD3_CLK__SD3_CLK 0x100f9
+ MX6QDL_PAD_SD3_RST__SD3_RESET 0x100f9
+ MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x170f9
+ MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x170f9
+ MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x170f9
+ MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x170f9
+ MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x170f9
+ MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x170f9
+ MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x170f9
+ MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x170f9
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT8__WDOG1_B 0x1b0b0
+ >;
+ };
+};
--
2.7.4
--
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] Input: silead - list all supported compatible strings in binding document
From: Rob Herring @ 2017-04-03 21:15 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Robert Dolca, Hans de Goede, Dmitry Torokhov,
linux-input@vger.kernel.org, Mark Rutland
In-Reply-To: <6574d158-7fe8-7a2f-dab6-1c155780c785@osg.samsung.com>
On Mon, Apr 3, 2017 at 10:51 AM, Javier Martinez Canillas
<javier@osg.samsung.com> wrote:
> Hello Rob,
>
> On 04/03/2017 11:25 AM, Rob Herring wrote:
>> On Wed, Mar 29, 2017 at 02:25:31PM -0400, Javier Martinez Canillas wrote:
>>> The driver contains compatible strings for different models, but the DT
>>> binding doc only lists one of them. Add the remaining to the document.
>>>
>>> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
>>> ---
>>>
>>> .../devicetree/bindings/input/touchscreen/silead_gsl1680.txt | 7 ++++++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> "dt-bindings: input: ..." is preferred for the subject, but no need to
>> respin just for that.
>>
>
> Can we document it in Documentation/devicetree/bindings/submitting-patches.txt?
Yes. Actually, I was thinking of adding the preferred prefixes to
MAINTAINERS. Then checkpatch.pl could check it perhaps.
> I'm asking because is true that at the beginning we used "dt-bindings: foo" for
> all DT bindings patches but then many (most?) maintainers started asking for the
> subsystem subject line to be used for both drivers and DT bindings docs since
> they would be merging both and also they could miss the DT bindings patches if
> their subsystem prefix was not used.
I'd argue that most subsys maintainers don't (or they just change it
when applying). Mark B does the most. I'm not going to waste any time
arguing over it if folks want something different. I'm mainly trying
to get rid of subjects like "Documentation: devicetree: bindings:
Document the DT binding for foo-bar". :)
Rob
^ permalink raw reply
* Re: [PATCH 6/15] dt-bindings: display: sun4i: Add HDMI display bindings
From: Maxime Ripard @ 2017-04-03 20:59 UTC (permalink / raw)
To: Rob Herring
Cc: Mike Turquette, Stephen Boyd, Chen-Yu Tsai,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Daniel Vetter,
David Airlie, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170315172622.lb6vy7cmbwaf7crn@rob-hp-laptop>
[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]
Hi Rob,
On Wed, Mar 15, 2017 at 12:26:22PM -0500, Rob Herring wrote:
> > +HDMI Encoder
> > +------------
> > +
> > +The HDMI Encoder supports the HDMI video and audio outputs, and does
> > +CEC. It is one end of the pipeline.
> > +
> > +Required properties:
> > + - compatible: value must be one of:
> > + * allwinner,sun5i-a10s-hdmi
> > + - reg: base address and size of memory-mapped region
> > + - clocks: phandles to the clocks feeding the HDMI encoder
> > + * ahb: the HDMI interface clock
> > + * mod: the HDMI module clock
> > + * pll-0: the first video PLL
> > + * pll-1: the second video PLL
> > + - clock-names: the clock names mentioned above
> > +
> > + - ports: A ports node with endpoint definitions as defined in
> > + Documentation/devicetree/bindings/media/video-interfaces.txt. The
> > + first port should be the input endpoint.
>
> You need an output port to an HDMI connector node and an audio port.
I started to look at the audio, and I can't find a use for an audio
port in the OF graph. As far as I understand, we will be using the
hdmi-codec, that still requires an ASoC card to create the link
between our i2s controller and the HDMI controller.
This work perfectly for us, but as far as I know, the simple-card
stuff only requires a phandle, and not an OF graph endpoint, right?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH RFC] serial: imx: support an enable-gpio
From: Uwe Kleine-König @ 2017-04-03 20:54 UTC (permalink / raw)
To: Rob Herring, Fabio Estevam
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-serial-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAL_JsqL8EQWoqyeyVb5Uj9ZaoB3Uz3yzbo114OR-FRrMEu8s=A@mail.gmail.com>
Hello,
On Mon, Apr 03, 2017 at 03:25:23PM -0500, Rob Herring wrote:
> On Mon, Apr 3, 2017 at 10:01 AM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > Hi Uwe,
> >
> > On Wed, Jul 13, 2016 at 6:01 AM, Uwe Kleine-König
> > <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> >> A part of my machine looks as follows (simplified):
> >>
> >> ,------------------------.
> >> | ,---------. |
> >> | | imx25 o--RX----◁---o---
> >> | | o--GPIO--' |
> >> | `---------' |
> >> `------------------------'
> >>
> >> that is, there is a driver on the RX line that must be enabled before
> >> the UART can be used. (That is necessary because the default mux of the
> >> RX pad after reset is an output.)
> >>
> >> To represent this in the device tree I do:
> >>
> >> pinctrl_uart5: uart5 {
> >> fsl,pins = <
> >> ...
> >> MX25_PAD_LBA__UART5_RXD 0x00000000
> >> MX25_PAD_CS5__GPIO_3_21 0x00002001
> >> ...
> >> };
> >>
> >> &uart5 {
> >> pinctrl-names = "default";
> >> pinctrl-0 = <&pinctrl_uart5>;
> >>
> >> enable-gpio = <&gpio3 21 GPIO_ACTIVE_LOW>;
>
> enable-gpios
ack.
> I imagine you already know this needs documentation. Make it common please.
Sure, I first wanted to collect some feedback to get an idea if this
would be accepted at all.
The only candidate for common code to add this functionality would be
uart_add_one_port. I wonder if this is early enough in every case.
> >> ...
> >> };
> >>
> >> This way it's ensured that the gpio is only enabled when the LBA pad is
> >> muxed as RX (together with the bootloader that sets the GPIO high).
> >>
> >> Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >
> > Since this is not imx serial specific it could be made more generic.
> >
> > What about extending
> > Documentation/devicetree/bindings/serial/slave-device.txt to handle
> > this GPIO, or maybe a regulator?
I could add a regulator that would do the right thing, that would not
match the hardware though.
> This is more like a phy than a device you talk to. It could also be
> something like an RS-232 xcvr enable (no one has done that already?).
> I think it belongs in the uart's node. You could additionally have an
> enable-gpios for a slave device.
Yes, I agree here, it is better defined in the uart's node, not in the
slave node.
Is xcvr-enable-gpios or xceiver-enable-gpios a better name?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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
* [PATCH] ARM: dts: imx: ventana: fix DTC warnings
From: Tim Harvey @ 2017-04-03 20:42 UTC (permalink / raw)
To: devicetree @ vger . kernel . org
Cc: Rob Herring, Shawn Guo, Sascha Hauer, Fabio Estevam,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Remove the sky2 ethernet device node from the pcie controller which was
invalid to begin with.
The original intent was to allow the bootloader to populate the MAC via
dt but this requires the PCI bus topology to be complete in dt as well
and as these boards have an expansion connector that topology is dynamic
and can't be represented here.
Signed-off-by: Tim Harvey <tharvey-UMMOYl/HMS+akBO8gow8eQ@public.gmane.org>
---
arch/arm/boot/dts/imx6q-gw5400-a.dts | 4 ----
arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 4 ----
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 4 ----
3 files changed, 12 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-gw5400-a.dts b/arch/arm/boot/dts/imx6q-gw5400-a.dts
index 8e84713..5b066c0 100644
--- a/arch/arm/boot/dts/imx6q-gw5400-a.dts
+++ b/arch/arm/boot/dts/imx6q-gw5400-a.dts
@@ -347,10 +347,6 @@
&pcie {
reset-gpio = <&gpio1 29 GPIO_ACTIVE_LOW>;
status = "okay";
-
- eth1: sky2@8 { /* MAC/PHY on bus 8 */
- compatible = "marvell,sky2";
- };
};
&ssi1 {
diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
index a208e7e..420a2f6 100644
--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
@@ -342,10 +342,6 @@
pinctrl-0 = <&pinctrl_pcie>;
reset-gpio = <&gpio1 29 GPIO_ACTIVE_LOW>;
status = "okay";
-
- eth1: sky2@8 { /* MAC/PHY on bus 8 */
- compatible = "marvell,sky2";
- };
};
&pwm2 {
diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
index 968fda9..e742153 100644
--- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
@@ -379,10 +379,6 @@
pinctrl-0 = <&pinctrl_pcie>;
reset-gpio = <&gpio1 29 GPIO_ACTIVE_LOW>;
status = "okay";
-
- eth1: sky2@8 { /* MAC/PHY on bus 8 */
- compatible = "marvell,sky2";
- };
};
&pwm1 {
--
2.7.4
--
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 1/2] leds: Add driver for Qualcomm LPG
From: Jacek Anaszewski @ 2017-04-03 20:38 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Pavel Machek, Rob Herring, Richard Purdie,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170403190032.GX20094@minitux>
On 04/03/2017 09:00 PM, Bjorn Andersson wrote:
> On Fri 31 Mar 02:28 PDT 2017, Jacek Anaszewski wrote:
>
>> Hi Bjorn and Pavel,
>>
>> On 03/30/2017 09:43 AM, Pavel Machek wrote:
>>> Hi!
>>>
>>>>>> There is a binding for ti,lp55xx, but there's nothing I can reuse from
>>>>>> that binding...because it's completely different hardware.
>>>>>
>>>>> Agreed, if you drop the pattern stuff from the binding, at least for now.
>>>>
>>>> I do not have a strong preference to expose these knobs in devicetree
>>>> and I do fear that finding some common "pattern" bindings that suits
>>>> everyone will be very difficult.
>>>>
>>>> So I'll drop them from the binding for now.
>>>
>>> Ok.
>>>
>>>>> If you want driver merged quickly, I believe the best way would be to
>>>>> leave out pattern support for now. We can merge the basic driver
>>>>> easily to 4.12.
>>>>>
>>>>
>>>> I'm not that much in a hurry and would rather see that we resolve any
>>>> outstanding issues with the implementation of the pattern handling.
>>>
>>> Ok, good.
>>>
>>>> But regardless of this we still have the problem that the typical
>>>> Qualcomm PMIC has 8 LPG-blocks and any triple could be driving a
>>>> RGB-LED. So we would have to create some sort of in-driver-wrapper
>>>> around any three instances exposing them as a single LED to the user.
>>>
>>> Yes, I believe we should do the wrapping. In N900 case,
>>>
>>>> I rather expose the individual channels and make sure that when we
>>>> trigger a blink operation or enable a pattern (i.e. the two operations
>>>> that do require synchronization) we will perform that synchronization
>>>> under the hood.
>>>
>>> First, we need a way to tell userspace which LEDs are synchronized,
>>> because otherwise it will be confusing.
>>
>> There is one year old discussion [0] about the possible approaches
>> to RGB sub-LEDs synchronization problem and patterns in general.
>> My last message with API design proposal has been left unanswered.
>>
>> Probably we continue that discussion here.
>>
>> Generally Bjorn's drivers touch two yet to be addressed issues:
>> - RGB LED support
>> - Generic support for patterns
>>
>> It is likely that both issues can be solved by utilizing trigger
>> mechanism. The possible solution to the problem Bjorn tried to
>> address with /sys/class/leds/<led>/pattern comma separated list
>> could be a trigger with adjustable number of pattern intervals.
>>
>> The trigger once activated would create a directory with the
>> number of files corresponding to the number of requested intervals,
>> and then user could write an interval value by writing it to the
>> corresponding file. Somehow related approach has been implemented
>> for USB port LED trigger:
>>
>> 0f247626cbbf ('usb: core: Introduce a USB port LED trigger")
>>
>> In both RGB and pattern approaches we should assess
>> if it is acceptable to provide a pattern for trigger name,
>> e.g. blink-pattern-{num_intervals}.
>>
>> If so, then "echo transition-pattern-15" would create a directory
>> e.g. transition_intervals with files interval_0 to interval_14,
>> that could be adjusted by userspace.
>>
>
> Having a RGB-trigger that proxy a accepts a userspace request of a
> brightness-tripple and sets the brightness on the individual associated
> LEDs sounds reasonable - but should probably be generalized to any
> number of LEDs.
>
> A slightly related matter is the question on how to use a single LED for
> multiple trigger sources, e.g. how do I get a single LED to show
> activity of two MMCs?.
You would have to add a dedicated trigger, similar to usb port trigger,
I mentioned in the previous message.
>
> For the patterns I don't know how a trigger for this would look like,
> how would setting the pattern of a trigger be propagated down to the
> hardware?
We'd need a new op and API similar to blink_set()/led_blink_set().
>>> Second, there are more issues than just patterns with the RGB
>>> LED. Most important is ability to set particular colors. You want to
>>> set the RGB LED to "white", but that does not mean you can set
>>> red=green=blue=1.0. You want color to look the same on LCD and on the
>>> LED, which means coefficients for white and some kind of function for
>>> brightness-to-PWM conversion.
>>
>> Shouldn't we leave that entirely to the userspace? Can we come up
>> with coefficients that will guarantee the same result on all existing
>> LCD devices?
>>
>
> How about we just force user space perform the 3 writes and save us the
> cost of another trigger in that case? Configuring the brightness of 3
> LEDs is not board specific - and even with a RGB-interface we still need
> to specify which RGB-LED should be controlled.
This is what we have now, so we can live with it. Addition of a new
RGB trigger would be an improvement of the existing state.
--
Best regards,
Jacek Anaszewski
--
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 1/2] leds: Add driver for Qualcomm LPG
From: Jacek Anaszewski @ 2017-04-03 20:38 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Pavel Machek, Rob Herring, Richard Purdie,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170403182158.GV20094@minitux>
On 04/03/2017 08:21 PM, Bjorn Andersson wrote:
> On Sun 02 Apr 05:54 PDT 2017, Jacek Anaszewski wrote:
>
>> On 03/31/2017 11:28 AM, Jacek Anaszewski wrote:
>>> Hi Bjorn and Pavel,
>>>
>>> On 03/30/2017 09:43 AM, Pavel Machek wrote:
> [..]
>>> In both RGB and pattern approaches we should assess
>>> if it is acceptable to provide a pattern for trigger name,
>>> e.g. blink-pattern-{num_intervals}.
>>
>> Actually we could achieve the goal by listing all available pattern
>> configurations for given LED class device, so in case of Qualcomm LPG
>> driver we could have transition-pattern-1 to transition-pattern-15
>> listed after executing "cat trigger".
>>
>
> There's a common pattern-table of 24 (or 64) entries, that is shared
> among the 8 LPGs (each LPG simply has to indices pointing into the
> shared table). Each entry in the table holds a value between 0 and 511.
> So that's a lot of "available pattern configurations".
By "available pattern configurations" I meant the number of possible
"pattern resolution" options, E.g. an equivalent of
echo "40 71 12" > pattern
would be
echo transition-pattern-3 > trigger
and then pattern_intervals directory with three files would
be created: interval_1, interval_2, interval_3.
In the next steps the user would have to write 40, 71 and 12
to interval_(1, 2, 3) respectively.
Now it is clear that initialization of such a trigger would
be cumbersome. One file accepting space separated list of values
should be fine.
> Unless you go with the path Qualcomm did in their downstream driver,
> where the table is filled statically from DeviceTree and each LPG is
> statically configured with some range from the table. But I don't like
> this and as far as I can tell neither do you guys.
Right, what we're trying to implement is flexible sysfs interface.
> And lastly the request is to create a common interface for userspace to
> control patterns among different LED hardware and I do not see how this
> would be acceptable to the LP55xx users.
For that we will certainly need some additions to the LED Trigger core.
We will need to limit usage of certain type of triggers only among
specified LED class devices, to allow assigning them to pattern engines.
We will also need a new op, similarly to existing blink_set().
The question is whether we will be providing software fallbacks,
and to what extent.
> Perhaps I'm not getting what you're proposing?
Yeah, after going through Documentation/leds/leds-lp55xx.txt and friends
it looks like we will need really sophisticated mechanism.
I'm not sure if providing generic interface for all use cases
documented there makes sense.
>> In case of RGB trigger we would have qcom-rgb among other triggers
>> listed in a result of executing "cat trigger". Then qcom-rgb-1 LED class
>> device could appear in /sys/class/leds, which would expose files
>> red-led-name, green-led-name and blue-led-name. Once all files are
>> initialized with appropriate LED class device names the RGB brightness
>> could be updated synchronously in all involved LEDs by executing
>> e.g. "echo 1 > update_color". Of course all LEDs that set qcom-rgb
>> trigger would have to avoid changing device state on write to
>> their brightness file.
>>
>
> I don't see that the brightness of the individual LEDs is the problem,
> writing individual colors to the 3 LEDs in a serial fashion isn't
> user-noticeable. What is a problem is if you start a pulse of some
> combined color it's important to synchronize the starting of the pattern
> generator, of you will have a color that shifts over time - or in the
> case of blink where the colors get out of sync.
I had exactly these use cases on mind.
> And as I said, I suggest that we just make it possible to configure any
> LPG channel to be grouped with any others and within a group we always
> synchronize the pattern-generator when enabling any LED.
IMHO it would be useful to have also specialized RGB trigger. Then we
could call led_rgb_event() from any place in kernel and be sure that
all groups of three R,G,B LED class devices, registered on that trigger,
will get new brightness.
We have two concepts here: trigger and grouping LED class device into
a single one. In the latter case such a device could be registered on
any trigger from current mainline and all grouped LEDs would get the
same brightness (e.g. as a result of backlight event).
> The issue left open is that we expose 3 independent LEDs to userspace
> and it seems desired to expose it as a single "RGB" LED. Providing a
> "RGB trigger" that any LED in the system can be associated with and then
> have that trigger wrap the individual LEDs sounds like a reasonable path
> forward. But if we're not going to do things like color "calibration" it
> feels like we're replacing the 3 writes in userspace with a single write
> and then 3 calls in the kernel; i.e. the only win in my view is some
> conceptual benefit.
You have one syscall vs three syscalls. The synchronization is the main
target here.
>> I wonder if I'm not missing some vital constraints here that could
>> make this design unfeasible.
>>
>
> Regardless of how we expose RGBs to userspace, the 8 LPG hardware blocks
> are independent of each other. The fact that they end up controlling
> something that is perceived by the human eye as some mixed color is to
> me a matter of system integration, and as such should not convolute the
> implementation of the individual instances.
--
Best regards,
Jacek Anaszewski
--
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] serial: imx: support an enable-gpio
From: Rob Herring @ 2017-04-03 20:25 UTC (permalink / raw)
To: Fabio Estevam
Cc: Uwe Kleine-König,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sascha Hauer
In-Reply-To: <CAOMZO5A4e7H-6feNN-cTABOKv+CUCU9Em_yFMhorZwXfeA-h0w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Apr 3, 2017 at 10:01 AM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Uwe,
>
> On Wed, Jul 13, 2016 at 6:01 AM, Uwe Kleine-König
> <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
>> A part of my machine looks as follows (simplified):
>>
>> ,------------------------.
>> | ,---------. |
>> | | imx25 o--RX----◁---o---
>> | | o--GPIO--' |
>> | `---------' |
>> `------------------------'
>>
>> that is, there is a driver on the RX line that must be enabled before
>> the UART can be used. (That is necessary because the default mux of the
>> RX pad after reset is an output.)
>>
>> To represent this in the device tree I do:
>>
>> pinctrl_uart5: uart5 {
>> fsl,pins = <
>> ...
>> MX25_PAD_LBA__UART5_RXD 0x00000000
>> MX25_PAD_CS5__GPIO_3_21 0x00002001
>> ...
>> };
>>
>> &uart5 {
>> pinctrl-names = "default";
>> pinctrl-0 = <&pinctrl_uart5>;
>>
>> enable-gpio = <&gpio3 21 GPIO_ACTIVE_LOW>;
enable-gpios
I imagine you already know this needs documentation. Make it common please.
>> ...
>> };
>>
>> This way it's ensured that the gpio is only enabled when the LBA pad is
>> muxed as RX (together with the bootloader that sets the GPIO high).
>>
>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>
> Since this is not imx serial specific it could be made more generic.
>
> What about extending
> Documentation/devicetree/bindings/serial/slave-device.txt to handle
> this GPIO, or maybe a regulator?
This is more like a phy than a device you talk to. It could also be
something like an RS-232 xcvr enable (no one has done that already?).
I think it belongs in the uart's node. You could additionally have an
enable-gpios for a slave device.
Rob
--
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