* [PATCH v13 4/5] Documentation: tee subsystem and op-tee driver
From: Jens Wiklander @ 2016-11-18 14:51 UTC (permalink / raw)
To: Greg Kroah-Hartman, Arnd Bergmann, Olof Johansson, Andrew Morton,
Wei Xu
Cc: linux-kernel, linux-arm-kernel, devicetree, Al Viro,
valentin.manea, jean-michel.delorme, emmanuel.michel, javier,
Jason Gunthorpe, Mark Rutland, Michal Simek, Rob Herring,
Will Deacon, Nishanth Menon, Andrew F. Davis, broonie,
Jens Wiklander
In-Reply-To: <1479480700-554-1-git-send-email-jens.wiklander@linaro.org>
Acked-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
---
Documentation/00-INDEX | 2 +
Documentation/tee.txt | 118 +++++++++++++++++++++++++++++++++++++++++++++++++
MAINTAINERS | 1 +
3 files changed, 121 insertions(+)
create mode 100644 Documentation/tee.txt
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 3acc4f1..4a5a887 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -436,6 +436,8 @@ sysrq.txt
- info on the magic SysRq key.
target/
- directory with info on generating TCM v4 fabric .ko modules
+tee.txt
+ - info on the TEE subsystem and drivers
this_cpu_ops.txt
- List rationale behind and the way to use this_cpu operations.
thermal/
diff --git a/Documentation/tee.txt b/Documentation/tee.txt
new file mode 100644
index 0000000..7185993
--- /dev/null
+++ b/Documentation/tee.txt
@@ -0,0 +1,118 @@
+TEE subsystem
+This document describes the TEE subsystem in Linux.
+
+A TEE (Trusted Execution Environment) is a trusted OS running in some
+secure environment, for example, TrustZone on ARM CPUs, or a separate
+secure co-processor etc. A TEE driver handles the details needed to
+communicate with the TEE.
+
+This subsystem deals with:
+
+- Registration of TEE drivers
+
+- Managing shared memory between Linux and the TEE
+
+- Providing a generic API to the TEE
+
+The TEE interface
+=================
+
+include/uapi/linux/tee.h defines the generic interface to a TEE.
+
+User space (the client) connects to the driver by opening /dev/tee[0-9]* or
+/dev/teepriv[0-9]*.
+
+- TEE_IOC_SHM_ALLOC allocates shared memory and returns a file descriptor
+ which user space can mmap. When user space doesn't need the file
+ descriptor any more, it should be closed. When shared memory isn't needed
+ any longer it should be unmapped with munmap() to allow the reuse of
+ memory.
+
+- TEE_IOC_VERSION lets user space know which TEE this driver handles and
+ the its capabilities.
+
+- TEE_IOC_OPEN_SESSION opens a new session to a Trusted Application.
+
+- TEE_IOC_INVOKE invokes a function in a Trusted Application.
+
+- TEE_IOC_CANCEL may cancel an ongoing TEE_IOC_OPEN_SESSION or TEE_IOC_INVOKE.
+
+- TEE_IOC_CLOSE_SESSION closes a session to a Trusted Application.
+
+There are two classes of clients, normal clients and supplicants. The latter is
+a helper process for the TEE to access resources in Linux, for example file
+system access. A normal client opens /dev/tee[0-9]* and a supplicant opens
+/dev/teepriv[0-9].
+
+Much of the communication between clients and the TEE is opaque to the
+driver. The main job for the driver is to receive requests from the
+clients, forward them to the TEE and send back the results. In the case of
+supplicants the communication goes in the other direction, the TEE sends
+requests to the supplicant which then sends back the result.
+
+OP-TEE driver
+=============
+
+The OP-TEE driver handles OP-TEE [1] based TEEs. Currently it is only the ARM
+TrustZone based OP-TEE solution that is supported.
+
+Lowest level of communication with OP-TEE builds on ARM SMC Calling
+Convention (SMCCC) [2], which is the foundation for OP-TEE's SMC interface
+[3] used internally by the driver. Stacked on top of that is OP-TEE Message
+Protocol [4].
+
+OP-TEE SMC interface provides the basic functions required by SMCCC and some
+additional functions specific for OP-TEE. The most interesting functions are:
+
+- OPTEE_SMC_FUNCID_CALLS_UID (part of SMCCC) returns the version information
+ which is then returned by TEE_IOC_VERSION
+
+- OPTEE_SMC_CALL_GET_OS_UUID returns the particular OP-TEE implementation, used
+ to tell, for instance, a TrustZone OP-TEE apart from an OP-TEE running on a
+ separate secure co-processor.
+
+- OPTEE_SMC_CALL_WITH_ARG drives the OP-TEE message protocol
+
+- OPTEE_SMC_GET_SHM_CONFIG lets the driver and OP-TEE agree on which memory
+ range to used for shared memory between Linux and OP-TEE.
+
+The GlobalPlatform TEE Client API [5] is implemented on top of the generic
+TEE API.
+
+Picture of the relationship between the different components in the
+OP-TEE architecture.
+
+ User space Kernel Secure world
+ ~~~~~~~~~~ ~~~~~~ ~~~~~~~~~~~~
+ +--------+ +-------------+
+ | Client | | Trusted |
+ +--------+ | Application |
+ /\ +-------------+
+ || +----------+ /\
+ || |tee- | ||
+ || |supplicant| \/
+ || +----------+ +-------------+
+ \/ /\ | TEE Internal|
+ +-------+ || | API |
+ + TEE | || +--------+--------+ +-------------+
+ | Client| || | TEE | OP-TEE | | OP-TEE |
+ | API | \/ | subsys | driver | | Trusted OS |
+ +-------+----------------+----+-------+----+-----------+-------------+
+ | Generic TEE API | | OP-TEE MSG |
+ | IOCTL (TEE_IOC_*) | | SMCCC (OPTEE_SMC_CALL_*) |
+ +-----------------------------+ +------------------------------+
+
+RPC (Remote Procedure Call) are requests from secure world to kernel driver
+or tee-supplicant. An RPC is identified by a special range of SMCCC return
+values from OPTEE_SMC_CALL_WITH_ARG. RPC messages which are intended for the
+kernel are handled by the kernel driver. Other RPC messages will be forwarded to
+tee-supplicant without further involvement of the driver, except switching
+shared memory buffer representation.
+
+References:
+[1] https://github.com/OP-TEE/optee_os
+[2] http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
+[3] drivers/tee/optee/optee_smc.h
+[4] drivers/tee/optee/optee_msg.h
+[5] http://www.globalplatform.org/specificationsdevice.asp look for
+ "TEE Client API Specification v1.0" and click download.
diff --git a/MAINTAINERS b/MAINTAINERS
index 84348f2..e50120e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10660,6 +10660,7 @@ S: Maintained
F: include/linux/tee_drv.h
F: include/uapi/linux/tee.h
F: drivers/tee/
+F: Documentation/tee.txt
THUNDERBOLT DRIVER
M: Andreas Noever <andreas.noever@gmail.com>
--
1.9.1
^ permalink raw reply related
* [PATCH v13 5/5] arm64: dt: hikey: Add optee node
From: Jens Wiklander @ 2016-11-18 14:51 UTC (permalink / raw)
To: Greg Kroah-Hartman, Arnd Bergmann, Olof Johansson, Andrew Morton,
Wei Xu
Cc: linux-kernel, linux-arm-kernel, devicetree, Al Viro,
valentin.manea, jean-michel.delorme, emmanuel.michel, javier,
Jason Gunthorpe, Mark Rutland, Michal Simek, Rob Herring,
Will Deacon, Nishanth Menon, Andrew F. Davis, broonie,
Jerome Forissier, Jens Wiklander
In-Reply-To: <1479480700-554-1-git-send-email-jens.wiklander@linaro.org>
From: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
---
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index dba3c13..89c1539 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -406,6 +406,13 @@
};
};
};
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
};
&uart2 {
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] soc/tegra: Implement Tegra186 PMC support
From: Rob Herring @ 2016-11-18 14:53 UTC (permalink / raw)
To: Thierry Reding
Cc: Mark Rutland, Stephen Warren, Alexandre Courbot, Jon Hunter,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161117171636.20580-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Nov 17, 2016 at 06:16:36PM +0100, Thierry Reding wrote:
> From: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> The power management controller on Tegra186 has changed in backwards-
> incompatible ways with respect to earlier generations. This implements a
> new driver that supports inversion of the PMU interrupt as well as the
> "recovery", "bootloader" and "forced-recovery" reboot commands.
>
> Signed-off-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> .../bindings/arm/tegra/nvidia,tegra186-pmc.txt | 34 +++++
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/soc/tegra/Makefile | 2 +-
> drivers/soc/tegra/pmc-tegra186.c | 169 +++++++++++++++++++++
> 3 files changed, 204 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt
> create mode 100644 drivers/soc/tegra/pmc-tegra186.c
^ permalink raw reply
* Re: [PATCH v2 5/8] dt-bindings: mfd: Provide human readable defines for TPS65217 interrupts
From: Lee Jones @ 2016-11-18 14:53 UTC (permalink / raw)
To: Milo Kim
Cc: bcousson-rdvid1DuHRBWk0Htik3J/w, Tony Lindgren,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Robert Nelson
In-Reply-To: <20161028123702.21849-6-woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, 28 Oct 2016, Milo Kim wrote:
> TPS65217 supports three interrupt sources. This patch enables assigning
> each IRQ number in the charger and power button node. Then corresponding
> IRQ will be requested by each driver.
>
> Signed-off-by: Milo Kim <woogyom.kim-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> include/dt-bindings/mfd/tps65217.h | 26 ++++++++++++++++++++++++++
> 1 file changed, 26 insertions(+)
> create mode 100644 include/dt-bindings/mfd/tps65217.h
>
> diff --git a/include/dt-bindings/mfd/tps65217.h b/include/dt-bindings/mfd/tps65217.h
> new file mode 100644
> index 0000000..cafb9e6
> --- /dev/null
> +++ b/include/dt-bindings/mfd/tps65217.h
> @@ -0,0 +1,26 @@
> +/*
> + * This header provides macros for TI TPS65217 DT bindings.
> + *
> + * Copyright (C) 2016 Texas Instruments
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program 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 program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __DT_BINDINGS_TPS65217_H__
> +#define __DT_BINDINGS_TPS65217_H__
> +
> +#define TPS65217_IRQ_USB 0
> +#define TPS65217_IRQ_AC 1
> +#define TPS65217_IRQ_PB 2
What are "AC" and "PB". Seeing as these are meant to be "human
readable", let's make them more human friendly.
> +#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] dt-bindings: max77620: add documentation for MPOK property
From: Rob Herring @ 2016-11-18 14:54 UTC (permalink / raw)
To: Venkat Reddy Talla
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A,
lgirdwood-Re5JQEeQqe8AvxtiuMwx3w, broonie-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
ldewangan-DDmLM1+adcrQT0dZR+AlfA, svelpula-DDmLM1+adcrQT0dZR+AlfA
In-Reply-To: <1479405276-26452-2-git-send-email-vreddytalla-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
On Thu, Nov 17, 2016 at 11:24:36PM +0530, Venkat Reddy Talla wrote:
> Adding documentation for maxim,power-ok-control dts property
>
> Signed-off-by: Venkat Reddy Talla <vreddytalla-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> ---
> Changes from V1:
> None
> ---
> Documentation/devicetree/bindings/mfd/max77620.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
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
* [RESEND PATCH] ARM: dts: stm32f469-disco: Fix memory size from 8MB to 16MB
From: Bruno Meirelles Herrera @ 2016-11-18 14:58 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, mcoquelin.stm32, alexandre.torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, Bruno Herrera
From: Bruno Herrera <bruherrera@gmail.com>
This patch fix memory size to support 16MB of external SDRAM.
Signed-off-by: Bruno Herrera <bruherrera@gmail.com>
---
arch/arm/boot/dts/stm32f469-disco.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
index 75f4303..fda12a4 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -58,7 +58,7 @@
};
memory {
- reg = <0x00000000 0x800000>;
+ reg = <0x00000000 0x1000000>;
};
aliases {
--
2.9.3 (Apple Git-75)
^ permalink raw reply related
* Re: [PATCH 1/7] ARM: dts: am335x-icev2: Add Industrial input support
From: Andrew F. Davis @ 2016-11-18 15:00 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren; +Cc: linux-omap, devicetree, linux-kernel
In-Reply-To: <20161007144428.16671-1-afd@ti.com>
ping?
^ permalink raw reply
* Re: [RFC 1/6] drm/etnaviv: add binding for the gc320 found in ti socs
From: Robert Nelson @ 2016-11-18 15:07 UTC (permalink / raw)
To: Lucas Stach
Cc: Russell King - ARM Linux, Nishanth Menon,
tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org, devicetree,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Julien, Christian Gmeiner, Tomi Valkeinen
In-Reply-To: <1479476068.20533.19.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On Fri, Nov 18, 2016 at 7:34 AM, Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> Am Freitag, den 18.11.2016, 12:13 +0000 schrieb Russell King - ARM
> Linux:
>> On Thu, Nov 17, 2016 at 08:53:38PM -0600, Nishanth Menon wrote:
>> > >diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> > >index a6799b0..ce51270 100644
>> > >--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> > >+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
>> > >@@ -653,6 +653,7 @@ static int etnaviv_pdev_remove(struct platform_device *pdev)
>> > > static const struct of_device_id dt_match[] = {
>> > > { .compatible = "fsl,imx-gpu-subsystem" },
>> > > { .compatible = "marvell,dove-gpu-subsystem" },
>> > >+ { .compatible = "ti,gc320-gpu-subsystem" },
>>
>> We need to get away from this ever-increasing set of compatible
>> strings here, as this is not long-term maintainable.
>>
>> What we should have is a common compatible which describes that
>> the node is compatible with this driver, and then use SoC specific
>> compatible strings later if we need to (eg, because of some GPU
>> subsystem SoC specifics.)
>>
>> So, I'd suggest that we update the documentation and add:
>>
>> "vivante,gc-gpu-subsystem"
>>
>> as a common compatible now, and if necessary move on to more specific
>> compatibles if we need to later.
>>
>> Also, I'd strongly suggest that no compatibles should contain the ID
>> number of the GPU core for exactly the same reason - Vivante GPU cores
>> vary according to features, and we don't want to end up with a long
>> list of specific compatibles (eg)
>> "ti,gc2000-and-gc320-and-gc355-gpu-subsystem" because TI
>> decides to integrate a 3d, 2d and VG core.
>>
> All of the above sounds sensible and I would prefer if the patches are
> reworked to take those things into account.
Thanks for reviewing guys, the "vivante,gc-gpu-subsystem" will work
perfectly fine for me, as the etnaviv driver does a great job at auto
detecting the hardware..
Regards,
--
Robert Nelson
https://rcn-ee.com/
--
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/7] ARM: dts: am335x-icev2: Add Industrial input support
From: Tony Lindgren @ 2016-11-18 15:08 UTC (permalink / raw)
To: Andrew F. Davis
Cc: Benoît Cousson, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <7095f8b0-efdb-6187-7580-43e8a0fa2cf3-l0cyMroinI0@public.gmane.org>
* Andrew F. Davis <afd-l0cyMroinI0@public.gmane.org> [161118 07:00]:
> ping?
Sorry somehow I missed this series, looks good to me so applying
to omap-for-v4.10/dt thanks.
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [RESEND PATCH v1] ARM: dts: stm32f429: Add missing USART3 pin config to STM32F469I-DISCO board
From: Bruno Meirelles Herrera @ 2016-11-18 15:10 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, mcoquelin.stm32, alexandre.torgue
Cc: devicetree, linux-kernel, linux-arm-kernel, Bruno Herrera
Including new STM32 maintainer. Rebased at stm32-dt-for-v4.10-1 and
stm32-dt-for-v4.10-2 branches. It fix the port/pin initialization in
case boot-loader does not configure/initialize the pins.
Fixing line wrapping from last patch
This patch adds USART3 pin configuration on PB10/PA11 pins
for STM32F469I-DISCO board.
Signed-off-by: Bruno Herrera <bruherrera@gmail.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 13 +++++++++++++
arch/arm/boot/dts/stm32f469-disco.dts | 2 ++
2 files changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index e4dae0e..1b8b105 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -316,6 +316,19 @@
};
};
+ usart3_pins_a: usart3@0 {
+ pins1 {
+ pinmux = <STM32F429_PB10_FUNC_USART3_TX>;
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins2 {
+ pinmux = <STM32F429_PB11_FUNC_USART3_RX>;
+ bias-disable;
+ };
+ };
+
usbotg_hs_pins_a: usbotg_hs@0 {
pins {
pinmux = <STM32F429_PH4_FUNC_OTG_HS_ULPI_NXT>,
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
index 8877c00..75f4303 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -79,5 +79,7 @@
};
&usart3 {
+ pinctrl-0 = <&usart3_pins_a>;
+ pinctrl-names = "default";
status = "okay";
};
--
2.9.3 (Apple Git-75)
^ permalink raw reply related
* Re: [PATCH v2 5/8] dt-bindings: mfd: Provide human readable defines for TPS65217 interrupts
From: Tony Lindgren @ 2016-11-18 15:10 UTC (permalink / raw)
To: Lee Jones
Cc: Milo Kim, bcousson, linux-omap, devicetree, linux-arm-kernel,
linux-kernel, Robert Nelson
In-Reply-To: <20161118145353.GE2301@dell.home>
* Lee Jones <lee.jones@linaro.org> [161118 06:51]:
> On Fri, 28 Oct 2016, Milo Kim wrote:
>
> > TPS65217 supports three interrupt sources. This patch enables assigning
> > each IRQ number in the charger and power button node. Then corresponding
> > IRQ will be requested by each driver.
> >
> > Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
> > ---
> > include/dt-bindings/mfd/tps65217.h | 26 ++++++++++++++++++++++++++
> > 1 file changed, 26 insertions(+)
> > create mode 100644 include/dt-bindings/mfd/tps65217.h
> >
> > diff --git a/include/dt-bindings/mfd/tps65217.h b/include/dt-bindings/mfd/tps65217.h
> > new file mode 100644
> > index 0000000..cafb9e6
> > --- /dev/null
> > +++ b/include/dt-bindings/mfd/tps65217.h
> > @@ -0,0 +1,26 @@
> > +/*
> > + * This header provides macros for TI TPS65217 DT bindings.
> > + *
> > + * Copyright (C) 2016 Texas Instruments
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program 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 program. If not, see <http://www.gnu.org/licenses/>.
> > + */
> > +
> > +#ifndef __DT_BINDINGS_TPS65217_H__
> > +#define __DT_BINDINGS_TPS65217_H__
> > +
> > +#define TPS65217_IRQ_USB 0
> > +#define TPS65217_IRQ_AC 1
> > +#define TPS65217_IRQ_PB 2
>
> What are "AC" and "PB". Seeing as these are meant to be "human
> readable", let's make them more human friendly.
Good idea. Milo, please do an incremental single follow-up patch as
I already have applied this and the dts changes using it.
Regards,
Tony
^ permalink raw reply
* [PATCH 1/2] backlight: arcxcnn: add support for ArticSand devices
From: Olimpiu Dejeu @ 2016-11-18 15:17 UTC (permalink / raw)
To: robh-DgEjT+Ai2ygdnm+yROfE0A
Cc: lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
jingoohan1-Re5JQEeQqe8AvxtiuMwx3w, Olimpiu Dejeu
Re-submission of arcxcnn backlight driver addressing the naming convention
concerns raised by Rob H.
Signed-off-by: Olimpiu Dejeu <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
---
drivers/video/backlight/Kconfig | 7 +
drivers/video/backlight/Makefile | 1 +
drivers/video/backlight/arcxcnn_bl.c | 541 +++++++++++++++++++++++++++++++++++
include/linux/i2c/arcxcnn.h | 67 +++++
4 files changed, 616 insertions(+)
create mode 100644 drivers/video/backlight/arcxcnn_bl.c
create mode 100644 include/linux/i2c/arcxcnn.h
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 5ffa4b4..4e1d2ad 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -460,6 +460,13 @@ config BACKLIGHT_BD6107
help
If you have a Rohm BD6107 say Y to enable the backlight driver.
+config BACKLIGHT_ARCXCNN
+ tristate "Backlight driver for the Arctic Sands ARCxCnnnn family"
+ depends on I2C
+ help
+ If you have an ARCxCnnnn family backlight say Y to enable
+ the backlight driver.
+
endif # BACKLIGHT_CLASS_DEVICE
endif # BACKLIGHT_LCD_SUPPORT
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 16ec534..8905129 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -55,3 +55,4 @@ obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
obj-$(CONFIG_BACKLIGHT_TOSA) += tosa_bl.o
obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
obj-$(CONFIG_BACKLIGHT_WM831X) += wm831x_bl.o
+obj-$(CONFIG_BACKLIGHT_ARCXCNN) += arcxcnn_bl.o
diff --git a/drivers/video/backlight/arcxcnn_bl.c b/drivers/video/backlight/arcxcnn_bl.c
new file mode 100644
index 0000000..1dad680
--- /dev/null
+++ b/drivers/video/backlight/arcxcnn_bl.c
@@ -0,0 +1,541 @@
+/*
+ * Backlight driver for ArcticSand ARC_X_C_0N_0N Devices
+ *
+ * Copyright 2016 ArcticSand, Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/i2c.h>
+#include <linux/backlight.h>
+#include <linux/err.h>
+#include <linux/of.h>
+#include <linux/pwm.h>
+#include <linux/regulator/consumer.h>
+
+#include "linux/i2c/arcxcnn.h"
+
+#define ARCXCNN_CMD (0x00) /* Command Register */
+#define ARCXCNN_CMD_STDBY (0x80) /* I2C Standby */
+#define ARCXCNN_CMD_RESET (0x40) /* Reset */
+#define ARCXCNN_CMD_BOOST (0x10) /* Boost */
+#define ARCXCNN_CMD_OVP_MASK (0x0C) /* --- Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_XXV (0x0C) /* <rsvrd> Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_20V (0x08) /* 20v Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_24V (0x04) /* 24v Over Voltage Threshold */
+#define ARCXCNN_CMD_OVP_31V (0x00) /* 31.4v Over Voltage Threshold */
+#define ARCXCNN_CMD_EXT_COMP (0x01) /* part (0) or full (1) external comp */
+
+#define ARCXCNN_CONFIG (0x01) /* Configuration */
+#define ARCXCNN_STATUS1 (0x02) /* Status 1 */
+#define ARCXCNN_STATUS2 (0x03) /* Status 2 */
+#define ARCXCNN_FADECTRL (0x04) /* Fading Control */
+#define ARCXCNN_ILED_CONFIG (0x05) /* ILED Configuration */
+
+#define ARCXCNN_LEDEN (0x06) /* LED Enable Register */
+#define ARCXCNN_LEDEN_ISETEXT (0x80) /* Full-scale current set externally */
+#define ARCXCNN_LEDEN_MASK (0x3F) /* LED string enables */
+#define ARCXCNN_LEDEN_LED1 (0x01)
+#define ARCXCNN_LEDEN_LED2 (0x02)
+#define ARCXCNN_LEDEN_LED3 (0x04)
+#define ARCXCNN_LEDEN_LED4 (0x08)
+#define ARCXCNN_LEDEN_LED5 (0x10)
+#define ARCXCNN_LEDEN_LED6 (0x20)
+
+#define ARCXCNN_WLED_ISET_LSB (0x07) /* LED ISET LSB (in upper nibble) */
+#define ARCXCNN_WLED_ISET_MSB (0x08) /* LED ISET MSB (8 bits) */
+
+#define ARCXCNN_DIMFREQ (0x09)
+#define ARCXCNN_COMP_CONFIG (0x0A)
+#define ARCXCNN_FILT_CONFIG (0x0B)
+#define ARCXCNN_IMAXTUNE (0x0C)
+
+#define DEFAULT_BL_NAME "arctic_bl"
+#define MAX_BRIGHTNESS 4095
+
+static int s_no_reset_on_remove;
+module_param_named(noreset, s_no_reset_on_remove, int, 0644);
+MODULE_PARM_DESC(noreset, "No reset on module removal");
+
+static int s_ibright = 60;
+module_param_named(ibright, s_ibright, int, 0644);
+MODULE_PARM_DESC(ibright, "Initial brightness (when no plat data)");
+
+static int s_iledstr = 0x3F;
+module_param_named(iledstr, s_iledstr, int, 0644);
+MODULE_PARM_DESC(iledstr, "Initial LED String (when no plat data)");
+
+static int s_retries = 2; /* 1 == only one try */
+module_param_named(retries, s_retries, int, 0644);
+MODULE_PARM_DESC(retries, "I2C retries attempted");
+
+enum arcxcnn_brightness_ctrl_mode {
+ PWM_BASED = 1,
+ REGISTER_BASED,
+};
+
+struct arcxcnn;
+
+struct arcxcnn {
+ char chipname[64];
+ enum arcxcnn_chip_id chip_id;
+ enum arcxcnn_brightness_ctrl_mode mode;
+ struct i2c_client *client;
+ struct backlight_device *bl;
+ struct device *dev;
+ struct arcxcnn_platform_data *pdata;
+ struct pwm_device *pwm;
+ struct regulator *supply; /* regulator for VDD input */
+};
+
+static int arcxcnn_write_byte(struct arcxcnn *lp, u8 reg, u8 data)
+{
+ s32 ret = -1;
+ int att;
+
+ for (att = 0; att < s_retries; att++) {
+ ret = i2c_smbus_write_byte_data(lp->client, reg, data);
+ if (ret >= 0)
+ return 0;
+ }
+ return ret;
+}
+
+static u8 arcxcnn_read_byte(struct arcxcnn *lp, u8 reg)
+{
+ int val;
+ int att;
+
+ for (att = 0; att < s_retries; att++) {
+ val = i2c_smbus_read_byte_data(lp->client, reg);
+ if (val >= 0)
+ return (u8)val;
+ }
+ return 0;
+}
+
+static int arcxcnn_update_bit(struct arcxcnn *lp, u8 reg, u8 mask, u8 data)
+{
+ int ret, att;
+ u8 tmp;
+
+ for (att = 0, ret = -1; att < s_retries; att++) {
+ ret = i2c_smbus_read_byte_data(lp->client, reg);
+ if (ret >= 0)
+ break;
+ }
+ if (ret < 0) {
+ dev_err(lp->dev, "failed to read 0x%.2x\n", reg);
+ return ret;
+ }
+
+ tmp = (u8)ret;
+ tmp &= ~mask;
+ tmp |= data & mask;
+
+ return arcxcnn_write_byte(lp, reg, tmp);
+}
+
+static int arcxcnn_set_brightness(struct arcxcnn *lp, u32 brightness)
+{
+ int ret;
+ u8 val;
+
+ val = (brightness & 0xF) << 4;
+ ret = arcxcnn_write_byte(lp, ARCXCNN_WLED_ISET_LSB, val);
+ if (ret < 0)
+ return ret;
+ val = (brightness >> 4);
+ ret = arcxcnn_write_byte(lp, ARCXCNN_WLED_ISET_MSB, val);
+ return ret;
+}
+
+static int arcxcnn_bl_update_status(struct backlight_device *bl)
+{
+ struct arcxcnn *lp = bl_get_data(bl);
+ u32 brightness = bl->props.brightness;
+
+ if (bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
+ brightness = 0;
+
+ /* set brightness */
+ if (lp->mode == PWM_BASED)
+ ; /* via pwm */
+ else if (lp->mode == REGISTER_BASED)
+ arcxcnn_set_brightness(lp, brightness);
+
+ /* set power-on/off/save modes */
+ if (bl->props.power == 0)
+ /* take out of standby */
+ arcxcnn_update_bit(lp, ARCXCNN_CMD, ARCXCNN_CMD_STDBY, 0);
+ else
+ /* 1-3 == power save, 4 = off
+ * place in low-power standby mode
+ */
+ arcxcnn_update_bit(lp, ARCXCNN_CMD,
+ ARCXCNN_CMD_STDBY, ARCXCNN_CMD_STDBY);
+ return 0;
+}
+
+static const struct backlight_ops arcxcnn_bl_ops = {
+ .options = BL_CORE_SUSPENDRESUME,
+ .update_status = arcxcnn_bl_update_status,
+};
+
+static int arcxcnn_backlight_register(struct arcxcnn *lp)
+{
+ struct backlight_device *bl;
+ struct backlight_properties props;
+ struct arcxcnn_platform_data *pdata = lp->pdata;
+ const char *name = pdata->name ? : DEFAULT_BL_NAME;
+
+ memset(&props, 0, sizeof(props));
+ props.type = BACKLIGHT_PLATFORM;
+ props.max_brightness = MAX_BRIGHTNESS;
+
+ if (pdata->initial_brightness > props.max_brightness)
+ pdata->initial_brightness = props.max_brightness;
+
+ props.brightness = pdata->initial_brightness;
+
+ bl = devm_backlight_device_register(lp->dev, name, lp->dev, lp,
+ &arcxcnn_bl_ops, &props);
+ if (IS_ERR(bl))
+ return PTR_ERR(bl);
+
+ lp->bl = bl;
+
+ return 0;
+}
+
+static ssize_t arcxcnn_get_chip_id(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct arcxcnn *lp = dev_get_drvdata(dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%s\n", lp->chipname);
+}
+
+static ssize_t arcxcnn_get_led_str(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct arcxcnn *lp = dev_get_drvdata(dev);
+
+ return scnprintf(buf, PAGE_SIZE, "%02X\n", lp->pdata->led_str);
+}
+
+static ssize_t arcxcnn_set_led_str(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t len)
+{
+ struct arcxcnn *lp = dev_get_drvdata(dev);
+ unsigned long ledstr;
+
+ if (kstrtoul(buf, 0, &ledstr))
+ return 0;
+
+ if (ledstr != lp->pdata->led_str) {
+ /* don't allow 0 for ledstr, use power to turn all off */
+ if (ledstr == 0)
+ return 0;
+ lp->pdata->led_str = ledstr & 0x3F;
+ arcxcnn_update_bit(lp, ARCXCNN_LEDEN,
+ ARCXCNN_LEDEN_MASK, lp->pdata->led_str);
+ }
+ return len;
+}
+
+static ssize_t arcxcnn_get_bl_ctl_mode(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct arcxcnn *lp = dev_get_drvdata(dev);
+ char *strmode = NULL;
+
+ if (lp->mode == PWM_BASED)
+ strmode = "pwm based";
+ else if (lp->mode == REGISTER_BASED)
+ strmode = "register based";
+
+ return scnprintf(buf, PAGE_SIZE, "%s\n", strmode);
+}
+
+static DEVICE_ATTR(chip_id, 0444, arcxcnn_get_chip_id, NULL);
+static DEVICE_ATTR(led_str, 0664, arcxcnn_get_led_str, arcxcnn_set_led_str);
+static DEVICE_ATTR(bl_ctl_mode, 0444, arcxcnn_get_bl_ctl_mode, NULL);
+
+static struct attribute *arcxcnn_attributes[] = {
+ &dev_attr_chip_id.attr,
+ &dev_attr_led_str.attr,
+ &dev_attr_bl_ctl_mode.attr,
+ NULL,
+};
+
+static const struct attribute_group arcxcnn_attr_group = {
+ .attrs = arcxcnn_attributes,
+};
+
+#ifdef CONFIG_OF
+static int arcxcnn_parse_dt(struct arcxcnn *lp)
+{
+ struct device *dev = lp->dev;
+ struct device_node *node = dev->of_node;
+ u32 prog_val, num_entry, sources[6];
+ int ret;
+
+ if (!node) {
+ dev_err(dev, "no platform data.\n");
+ return -EINVAL;
+ }
+ lp->pdata->led_config_0_set = false;
+ lp->pdata->led_config_1_set = false;
+ lp->pdata->dim_freq_set = false;
+ lp->pdata->comp_config_set = false;
+ lp->pdata->filter_config_set = false;
+ lp->pdata->trim_config_set = false;
+
+ ret = of_property_read_string(node, "label", &lp->pdata->name);
+ if (ret < 0)
+ lp->pdata->name = NULL;
+
+ ret = of_property_read_u32(node, "default-brightness", &prog_val);
+ if (ret < 0)
+ prog_val = s_ibright;
+ lp->pdata->initial_brightness = prog_val;
+ if (lp->pdata->initial_brightness > MAX_BRIGHTNESS)
+ lp->pdata->initial_brightness = MAX_BRIGHTNESS;
+
+ ret = of_property_read_u32(node, "arc,led-config-0", &prog_val);
+ if (ret == 0) {
+ lp->pdata->led_config_0 = (u8)prog_val;
+ lp->pdata->led_config_0_set = true;
+ }
+ ret = of_property_read_u32(node, "arc,led-config-1", &prog_val);
+ if (ret == 0) {
+ lp->pdata->led_config_1 = (u8)prog_val;
+ lp->pdata->led_config_1_set = true;
+ }
+ ret = of_property_read_u32(node, "arc,dim-freq", &prog_val);
+ if (ret == 0) {
+ lp->pdata->dim_freq = (u8)prog_val;
+ lp->pdata->dim_freq_set = true;
+ }
+ ret = of_property_read_u32(node, "arc,comp-config", &prog_val);
+ if (ret == 0) {
+ lp->pdata->comp_config = (u8)prog_val;
+ lp->pdata->comp_config_set = true;
+ }
+ ret = of_property_read_u32(node, "arc,filter-config", &prog_val);
+ if (ret == 0) {
+ lp->pdata->filter_config = (u8)prog_val;
+ lp->pdata->filter_config_set = true;
+ }
+ ret = of_property_read_u32(node, "arc,trim-config", &prog_val);
+ if (ret == 0) {
+ lp->pdata->trim_config = (u8)prog_val;
+ lp->pdata->trim_config_set = true;
+ }
+ ret = of_property_count_u32_elems(node, "led-sources");
+ if (ret < 0)
+ lp->pdata->led_str = 0x3F;
+ else {
+ num_entry = ret;
+ if (num_entry > 6)
+ num_entry = 6;
+
+ ret = of_property_read_u32_array(node, "led-sources", sources,
+ num_entry);
+ if (ret < 0) {
+ dev_err(dev, "led-sources node is invalid.\n");
+ return -EINVAL;
+ }
+
+ lp->pdata->led_str = 0;
+ while (num_entry > 0)
+ lp->pdata->led_str |= (1 << sources[--num_entry]);
+ }
+ return 0;
+}
+#else
+static int arcxcnn_parse_dt(struct arcxcnn *lp)
+{
+ return -EINVAL;
+}
+#endif
+
+static int arcxcnn_probe(struct i2c_client *cl, const struct i2c_device_id *id)
+{
+ struct arcxcnn *lp;
+ int ret;
+ u8 regval;
+ u16 chipid;
+
+ if (!i2c_check_functionality(cl->adapter, I2C_FUNC_SMBUS_BYTE_DATA))
+ return -EIO;
+
+ lp = devm_kzalloc(&cl->dev, sizeof(*lp), GFP_KERNEL);
+ if (!lp)
+ return -ENOMEM;
+
+ lp->client = cl;
+ lp->dev = &cl->dev;
+ lp->chip_id = id->driver_data;
+ lp->pdata = dev_get_platdata(&cl->dev);
+
+ if (!lp->pdata) {
+ lp->pdata = devm_kzalloc(lp->dev,
+ sizeof(*lp->pdata), GFP_KERNEL);
+ if (!lp->pdata)
+ return -ENOMEM;
+
+ /* no platform data, parse the device-tree for info. if there
+ * is no device tree entry, we are being told we exist because
+ * user-land said so, so make up the info we need
+ */
+ ret = arcxcnn_parse_dt(lp);
+ if (ret < 0) {
+ /* no device tree, use defaults based on module params
+ */
+ lp->pdata->led_config_0_set = false;
+ lp->pdata->led_config_1_set = false;
+ lp->pdata->dim_freq_set = false;
+ lp->pdata->comp_config_set = false;
+ lp->pdata->filter_config_set = false;
+ lp->pdata->trim_config_set = false;
+
+ lp->pdata->name = NULL;
+ lp->pdata->initial_brightness = s_ibright;
+ lp->pdata->led_str = s_iledstr;
+ }
+ }
+
+ if (lp->pdata->dim_freq_set)
+ lp->mode = PWM_BASED;
+ else
+ lp->mode = REGISTER_BASED;
+
+ i2c_set_clientdata(cl, lp);
+
+ /* read device ID */
+ regval = arcxcnn_read_byte(lp, 0x1E);
+ chipid = regval;
+ chipid <<= 8;
+ regval = arcxcnn_read_byte(lp, 0x1F);
+ chipid |= regval;
+
+ /* make sure it belongs to this driver
+ * TODO - handle specific ids
+ */
+ if (chipid != 0x02A5) {
+ #if 1
+ dev_info(&cl->dev, "Chip Id is %04X\n", chipid);
+ #else
+ dev_err(&cl->dev, "%04X is not ARC2C\n", chipid);
+ return -ENODEV;
+ #endif
+ }
+ /* reset the device */
+ arcxcnn_write_byte(lp, ARCXCNN_CMD, ARCXCNN_CMD_RESET);
+
+ /* set initial brightness */
+ arcxcnn_set_brightness(lp, lp->pdata->initial_brightness);
+
+ /* if fadectrl set in DT, set the value directly, else leave default */
+ if (lp->pdata->led_config_0_set)
+ arcxcnn_write_byte(lp, ARCXCNN_FADECTRL,
+ lp->pdata->led_config_0);
+
+ /* if iled config set in DT, set the value, else internal mode */
+ if (lp->pdata->led_config_1_set)
+ arcxcnn_write_byte(lp, ARCXCNN_ILED_CONFIG,
+ lp->pdata->led_config_1);
+ else
+ arcxcnn_write_byte(lp, ARCXCNN_ILED_CONFIG, 0x57);
+
+ /* other misc DT settings */
+ if (lp->pdata->dim_freq_set)
+ arcxcnn_write_byte(lp, ARCXCNN_FADECTRL, lp->pdata->dim_freq);
+ if (lp->pdata->comp_config_set)
+ arcxcnn_write_byte(lp, ARCXCNN_COMP_CONFIG,
+ lp->pdata->comp_config);
+ if (lp->pdata->filter_config_set)
+ arcxcnn_write_byte(lp, ARCXCNN_FILT_CONFIG,
+ lp->pdata->filter_config);
+ if (lp->pdata->trim_config_set)
+ arcxcnn_write_byte(lp, ARCXCNN_IMAXTUNE,
+ lp->pdata->trim_config);
+
+ /* set initial LED Strings */
+ arcxcnn_update_bit(lp, ARCXCNN_LEDEN,
+ ARCXCNN_LEDEN_MASK, lp->pdata->led_str);
+
+ snprintf(lp->chipname, sizeof(lp->chipname),
+ "%s-%04X", id->name, chipid);
+
+ ret = arcxcnn_backlight_register(lp);
+ if (ret) {
+ dev_err(lp->dev,
+ "failed to register backlight. err: %d\n", ret);
+ return ret;
+ }
+
+ ret = sysfs_create_group(&lp->dev->kobj, &arcxcnn_attr_group);
+ if (ret) {
+ dev_err(lp->dev, "failed to register sysfs. err: %d\n", ret);
+ return ret;
+ }
+
+ backlight_update_status(lp->bl);
+ return 0;
+}
+
+static int arcxcnn_remove(struct i2c_client *cl)
+{
+ struct arcxcnn *lp = i2c_get_clientdata(cl);
+
+ if (!s_no_reset_on_remove) {
+ /* disable all strings */
+ arcxcnn_write_byte(lp, ARCXCNN_LEDEN, 0x00);
+ /* reset the device */
+ arcxcnn_write_byte(lp, ARCXCNN_CMD, ARCXCNN_CMD_RESET);
+ }
+ lp->bl->props.brightness = 0;
+ backlight_update_status(lp->bl);
+ if (lp->supply)
+ regulator_disable(lp->supply);
+ sysfs_remove_group(&lp->dev->kobj, &arcxcnn_attr_group);
+
+ return 0;
+}
+
+static const struct of_device_id arcxcnn_dt_ids[] = {
+ { .compatible = "arc,arc2c0608" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, arcxcnn_dt_ids);
+
+/* Note that the device/chip ID is not fixed in silicon so
+ * auto-probing of these devices on the bus is most likely
+ * not possible, use device tree to set i2c bus address
+ */
+static const struct i2c_device_id arcxcnn_ids[] = {
+ {"arc2c0608", ARC2C0608},
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, arcxcnn_ids);
+
+static struct i2c_driver arcxcnn_driver = {
+ .driver = {
+ .name = "arcxcnn_bl",
+ .of_match_table = of_match_ptr(arcxcnn_dt_ids),
+ },
+ .probe = arcxcnn_probe,
+ .remove = arcxcnn_remove,
+ .id_table = arcxcnn_ids,
+};
+
+module_i2c_driver(arcxcnn_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Brian Dodge <bdodge09-1ViLX0X+lBJBDgjK7y7TUQ@public.gmane.org>");
+MODULE_DESCRIPTION("ARCXCNN Backlight driver");
diff --git a/include/linux/i2c/arcxcnn.h b/include/linux/i2c/arcxcnn.h
new file mode 100644
index 0000000..1c681dd
--- /dev/null
+++ b/include/linux/i2c/arcxcnn.h
@@ -0,0 +1,67 @@
+/*
+ * Backlight driver for ArcticSand ARC2C0608 Backlight Devices
+ *
+ * Copyright 2016 ArcticSand, Inc.
+ *
+ * Licensed under the GPL-2 or later.
+ */
+
+#ifndef _ARCXCNN_H
+#define _ARCXCNN_H
+
+enum arcxcnn_chip_id {
+ ARC2C0608
+};
+
+enum arcxcnn_brightness_source {
+ ARCXCNN_PWM_ONLY,
+ ARCXCNN_I2C_ONLY = 2,
+};
+
+#define ARCXCNN_MAX_PROGENTRIES 48 /* max a/v pairs for custom */
+
+/**
+ * struct arcxcnn_platform_data
+ * @name : Backlight driver name. If it is not defined, default name is set.
+ * @initial_brightness : initial value of backlight brightness
+ * @led_str : initial LED string enables, upper bit is global on/off
+ * @led_config_0 : fading speed (period between intensity steps)
+ * @led_config_1 : misc settings, see datasheet
+ * @dim_freq : pwm dimming frequency if in pwm mode
+ * @comp_config : misc config, see datasheet
+ * @filter_config: RC/PWM filter config, see datasheet
+ * @trim_config : full scale current trim, see datasheet
+ * @led_config_0_set : the value in led_config_0 is valid
+ * @led_config_1_set : the value in led_config_1 is valid
+ * @dim_freq_set : the value in dim_freq is valid
+ * @comp_config_set : the value in comp_config is valid
+ * @filter_config_set : the value in filter_config is valid
+ * @trim_config_set : the value in trim_config is valid
+ *
+ * the _set flags are used to indicate that the value was explicitly set
+ * in the device tree or platform data. settings not set are left as default
+ * power-on default values of the chip except for led_str and led_config_1
+ * which are set by the driver (led_str is specified indirectly in the
+ * device tree via "led-sources")
+ */
+struct arcxcnn_platform_data {
+ const char *name;
+ u16 initial_brightness;
+ u8 led_str;
+
+ u8 led_config_0;
+ u8 led_config_1;
+ u8 dim_freq;
+ u8 comp_config;
+ u8 filter_config;
+ u8 trim_config;
+
+ bool led_config_0_set;
+ bool led_config_1_set;
+ bool dim_freq_set;
+ bool comp_config_set;
+ bool filter_config_set;
+ bool trim_config_set;
+};
+
+#endif
--
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
* [PATCH 2/2] backlight: arcxcnn: devicetree bindings for ArticSand devices
From: Olimpiu Dejeu @ 2016-11-18 15:17 UTC (permalink / raw)
To: robh
Cc: lee.jones, linux-kernel, linux-fbdev, devicetree, jingoohan1,
Olimpiu Dejeu
Re-submission of arcxcnn backlight driver addressing the naming convention
concerns raised by Rob H. Note that all the device tree properties are
determined by the board design or IC EPROM settings and are not intended
to be user adjustable.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Olimpiu Dejeu <olimpiu@arcticsand.com>
---
.../bindings/leds/backlight/arcxcnn_bl.txt | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
new file mode 100644
index 0000000..a7b6ff2
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
@@ -0,0 +1,33 @@
+Binding for ArcticSand arc2c0608 LED driver
+
+Required properties:
+- compatible: should be "arc,arc2c0608"
+- reg: slave address
+
+Optional properties:
+- default-brightness: brightness value on boot, value from: 0-4095
+- label: The name of the backlight device
+ See Documentation/devicetree/bindings/leds/common.txt
+- led-sources: List of enabled channels from 0 to 5.
+ See Documentation/devicetree/bindings/leds/common.txt
+
+- arc,led-config-0: setting for register ILED_CONFIG_0
+- arc,led-config-1: setting for register ILED_CONFIG_1
+- arc,dim-freq: PWM mode frequence setting (bits [3:0] used)
+- arc,comp-config: setting for register CONFIG_COMP
+- arc,filter-config: setting for register FILTER_CONFIG
+- arc,trim-config: setting for register IMAXTUNE
+
+Note: Optional properties not specified will default to values in IC EPROM
+
+Example:
+
+arc2c0608@30 {
+ compatible = "arc,arc2c0608";
+ reg = <0x30>;
+ default-brightness = <500>;
+ label = "lcd-backlight";
+ linux,default-trigger = "backlight";
+ led-sources = <0 1 2 5>;
+};
+
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH v2 1/7] dt-bindings: document devicetree bindings for mux-gpio
From: Rob Herring @ 2016-11-18 15:35 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, Wolfram Sang, Mark Rutland, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Arnd Bergmann, Greg Kroah-Hartman, linux-i2c, devicetree,
linux-iio
In-Reply-To: <1479419289-17553-2-git-send-email-peda@axentia.se>
On Thu, Nov 17, 2016 at 10:48:03PM +0100, Peter Rosin wrote:
> ---
> .../devicetree/bindings/misc/mux-gpio.txt | 79 ++++++++++++++++++++++
> 1 file changed, 79 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/mux-gpio.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/mux-gpio.txt b/Documentation/devicetree/bindings/misc/mux-gpio.txt
> new file mode 100644
> index 000000000000..73699a37824f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/mux-gpio.txt
> @@ -0,0 +1,79 @@
> +GPIO-based multiplexer controller bindings
> +
> +Define what GPIO pins are used to control a multiplexer. Or several
> +multiplexers, if the same pins control more than one multiplexer.
I think this makes sense in your case, but I think it is too complicated
for a non-shared case. Perhaps mux-gpios should be used directly (i.e.
in the adc-mux node) and control-muxes only used for the shared case.
Part of me feels like you are working around in DT the GPIO subsystem
limitation that it can't share GPIO lines. Either this could be fixed
in some way in the GPIO subsystem, or the mux subsys could deal with it.
You just have to look up if you already have a mux registered for the
same GPIOs. Of course, that may make the mux subsys pretty much GPIO
only, but I'm having a hard time thinking how you would have shared
muxes that are not GPIO controlled. Any other control would be
integrated into the mux itself.
> +
> +Required properties:
> +- compatible : "mux-gpio"
> +- mux-gpios : list of gpios used to control the multiplexer, least
> + significant bit first.
> +
> +Optional properties:
> +- idle-state : if present, the state the mux will have when idle.
Needs some detail on what the value is. One bit per gpio? One cell per
gpio?
> +
> +Example:
> + control_mux: control-adc-mux {
> + compatible = "mux-gpio";
> +
> + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>,
> + <&pioA 1 GPIO_ACTIVE_HIGH>;
> + };
> +
> + adc-mux {
> + compatible = "iio-mux";
> + io-channels = <&adc 0>;
> + io-channel-names = "parent";
> +
> + control-muxes = <&control_mux>;
This is a common name? It should be in a common mux binding doc.
> + control-mux-names = "mux";
I think this can be dropped at least until you have more than 1.
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + sync-1@0 {
> + reg = <0>;
> + };
> +
> + in@1 {
> + reg = <1>;
> + };
> +
> + out@2 {
> + reg = <2>;
> + };
> +
> + sync-2@3 {
> + reg = <3>;
> + };
> + };
> +
> + i2c-mux {
> + compatible = "i2c-mux-simple,mux-locked";
> + i2c-parent = <&i2c1>;
> +
> + control-muxes = <&control_mux>;
> + control-mux-names = "mux";
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + i2c@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ssd1307: oled@3c {
> + /* ... */
> + };
> + };
> +
> + i2c@3 {
> + reg = <3>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pca9555: pca9555@20 {
> + /* ... */
> + };
> + };
> + };
> --
> 2.1.4
>
^ permalink raw reply
* Re: [PATCH v2 2/3] hwmon: ltc2990: add devicetree binding
From: Tom Levens @ 2016-11-18 15:36 UTC (permalink / raw)
To: Rob Herring
Cc: Tom Levens, linux-0h96xk9xTtrk1uMJSBkQmQ, jdelvare-IBi9RG/b67k,
mark.rutland-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-hwmon-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161118145035.ir46ohk5uqaln6kp@rob-hp-laptop>
Hi Rob,
Thanks for taking the time to look at this patch.
On Fri, 18 Nov 2016, Rob Herring wrote:
> On Thu, Nov 17, 2016 at 01:10:15PM +0100, Tom Levens wrote:
>> Add a devicetree binding for the ltc2990 hwmon driver.
>>
>> Signed-off-by: Tom Levens <tom.levens-vJEk5272eHo@public.gmane.org>
>> ---
>> .../devicetree/bindings/hwmon/ltc2990.txt | 28 ++++++++++++++++++++
>> 1 files changed, 28 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/hwmon/ltc2990.txt
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/ltc2990.txt b/Documentation/devicetree/bindings/hwmon/ltc2990.txt
>> new file mode 100644
>> index 0000000..e4040e0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/ltc2990.txt
>> @@ -0,0 +1,28 @@
>> +ltc2990
>> +
>> +Required properties:
>> +- compatible: Must be "lltc,ltc2990"
>> +- reg: I2C slave address
>> +
>> +Optional properties:
>> +- lltc,mode:
>
> What determines the mode? If this is something a user will want to
> control, then it should be a sysfs attr rather than DT prop. If the
> board design dictates then DT is the right place.
It is based on the external connections of the chip. So, I would say that
it is board specific.
> 'mode' is a bit vague, 'lltc,meas-mode' perhaps.
Sure thing.
There is also one question which came up in the thread for the patch 3 of
this patchset. The full mode for this chip is actually made of two logical
values which are written to the bits 4..3 and 2..0 of the register. This
version of the patch only configures one of the values, but for the next
version we would like to configure both. While combining them into a
single integer value would be possible, they are defined as two values in
the datasheet. Therefore, I propose using an array, such as:
lltc,meas-mode = <7 3>;
This would set the mode[2..0]=7 and mode[4..3]=3.
What do you think of this? Or should this be split into two properties?
However, in this case I struggle come up with names for the properties.
The datasheet, helpfully, calls both the fields "mode" and there is no
clear difference in their function as both control which measurements are
available.
Thanks,
>> +A Sets the chip's measurement mode, defaults to <6> if unset.
>> +
>> + The following measurements are available in each mode:
>> +
>> + 0: V1, V2, TR2
>> + 1: V1-V2, TR2
>> + 2: V1-V2, V3, V4
>> + 3: TR1, V3, V4
>> + 4: TR1, V3-V4
>> + 5: TR1, TR2
>> + 6: V1-V2, V3-V4
>> + 7: V1, V2, V3, V4
>> +
>> +Example:
>> +
>> +ltc2990@4c {
>> + compatible = "lltc,ltc2990";
>> + reg = <0x4c>;
>> + lltc,mode = <7>;
>> +};
>> --
>> 1.7.1
>>
>
--
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 1/4] Documentation: pv88080: Move binding document
From: Rob Herring @ 2016-11-18 15:38 UTC (permalink / raw)
To: Eric Jeong
Cc: DEVICETREE, LINUX-KERNEL, Mark Rutland, Alexandre Courbot,
LINUX-GPIO, Lee Jones, Liam Girdwood, Linus Walleij, Mark Brown,
Support Opensource
In-Reply-To: <8d6dc516374bf2c1cf0841aa68a888bca33413a0.1479429347.git.eric.jeong@diasemi.com>
On Fri, Nov 18, 2016 at 09:35:46AM +0900, Eric Jeong wrote:
>
> From: Eric Jeong <eric.jeong.opensource@diasemi.com>
>
> The change is to move pv88080 binding document
> from the regulator directory to mfd binding directory
> for PV88080 PMIC MFD support.
> And, GPIO properties are added.
>
>
> Signed-off-by: Eric Jeong <eric.jeong.opensource@diasemi.com>
>
> ---
> This patch applies against linux-next and next-20161117
>
> Hi,
>
> Change since PATCH V2
> - Added property and description for gpio
>
> Change since PATCH V1
> - Patch separated from PATCH V1
>
> Regards,
> Eric Jeong, Dialog Semiconductor Ltd.
>
>
> .../bindings/{regulator => mfd}/pv88080.txt | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
> rename Documentation/devicetree/bindings/{regulator => mfd}/pv88080.txt (79%)
>
> diff --git a/Documentation/devicetree/bindings/regulator/pv88080.txt b/Documentation/devicetree/bindings/mfd/pv88080.txt
> similarity index 79%
> rename from Documentation/devicetree/bindings/regulator/pv88080.txt
> rename to Documentation/devicetree/bindings/mfd/pv88080.txt
> index e6e4b9c8..7e24f95 100644
> --- a/Documentation/devicetree/bindings/regulator/pv88080.txt
> +++ b/Documentation/devicetree/bindings/mfd/pv88080.txt
> @@ -1,4 +1,4 @@
> -* Powerventure Semiconductor PV88080 Voltage Regulator
> +* Powerventure Semiconductor PV88080 PMIC
>
> Required properties:
> - compatible: Must be one of the following, depending on the
> @@ -16,8 +16,15 @@ Required properties:
> standard binding for regulators; see regulator.txt.
> BUCK1, BUCK2, BUCK3 and HVBUCK.
>
> +- gpio-controller: Marks the device node as a GPIO controller.
> +- #gpio-cells: Should be 2. See gpio.txt in this directory
> + for a description of the cells format.
> +
> Optional properties:
> +- ngpios : Number of in-use slots of available slots for GPIO.
> + Maximum is 2.
> - Any optional property defined in regulator.txt
> + and gpio.txt for more information.
>
> Example:
>
> @@ -27,6 +34,13 @@ Example:
> interrupt-parent = <&gpio>;
> interrupts = <24 24>;
>
> + gpioex {
gpio-controller {
> + compatible = "pvs,pv88080-gpio";
Is this documented?
> + gpio-controller;
> + #gpio-cells = <2>;
> + ngpios = <2>;
> + };
> +
> regulators {
> BUCK1 {
> regulator-name = "buck1";
> --
> end-of-patch for PATCH V3
>
^ permalink raw reply
* RE: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Gabriele Paoloni @ 2016-11-18 16:18 UTC (permalink / raw)
To: Arnd Bergmann, linux-arm-kernel@lists.infradead.org
Cc: mark.rutland@arm.com, benh@kernel.crashing.org,
catalin.marinas@arm.com, liviu.dudau@arm.com, Linuxarm,
lorenzo.pieralisi@arm.com, xuwei (O), Jason Gunthorpe,
linux-serial@vger.kernel.org, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, minyard@acm.org, will.deacon@arm.com,
John Garry, zourongrong@gmail.com, robh+dt@kernel.org
In-Reply-To: <2271602.GoSoby0zHK@wuerfel>
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@arndb.de]
> Sent: 18 November 2016 13:43
> To: linux-arm-kernel@lists.infradead.org
> Cc: Gabriele Paoloni; mark.rutland@arm.com; benh@kernel.crashing.org;
> catalin.marinas@arm.com; liviu.dudau@arm.com; Linuxarm;
> lorenzo.pieralisi@arm.com; xuwei (O); Jason Gunthorpe; linux-
> serial@vger.kernel.org; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; minyard@acm.org; will.deacon@arm.com; John
> Garry; zourongrong@gmail.com; robh+dt@kernel.org; bhelgaas@go og
> le.com; kantyzc@163.com; zhichang.yuan02@gmail.com; Thomas Petazzoni;
> linux-kernel@vger.kernel.org; Yuanzhichang; olof@lixom.net
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
>
> On Friday, November 18, 2016 12:53:08 PM CET Gabriele Paoloni wrote:
> > From: Arnd Bergmann [mailto:arnd@arndb.de]
> > > On Friday, November 18, 2016 12:07:28 PM CET Gabriele Paoloni
> wrote:
> > > > > I think there is no need to change a) here, we have
> PCIBIOS_MIN_IO
> > > > > today and even if we don't need it, there is no obvious
> downside.
> > > > > I would also argue that we can ignore b) for the discussion of
> > > > > the HiSilicon LPC driver, we just need to assign some range
> > > > > of logical addresses to each domain.
> > > > >
> > > > > That means solving c) is the important problem here, and it
> > > > > shouldn't be so hard. We can do this either with a single
> > > > > special domain as in the v5 patch series, or by generalizing it
> > > > > so that any I/O space mapping gets looked up through the device
> > > > > pointer of the bus master.
> > > >
> > > > I am not very on the "generalized" multi-domain solution...
> > > > Currently the IO accessors prototypes have an unsigned long addr
> > > > as input parameter. If we live in a multi-domain IO system
> > > > how can we distinguish inside the accessor which domain addr
> > > > belongs to?
> > >
> > > The easiest change compared to the v5 code would be to walk
> > > a linked list of 'struct extio_ops' structures rather than
> > > assuming there is only ever one of them. I think one of the
> > > earlier versions actually did this.
> >
> > Right but if my understanding is correct if we live in a multi-
> > domain I/O space world when you have an input addr in the I/O
> > accessors this addr can be duplicated (for example for the standard
> > PCI IO domain and for our special LPC domain).
> > So effectively even if you walk a linked list there is a problem
> > of disambiguation...am I right?
>
> No, unlike the PCI memory space, the PIO addresses are not
> usually distinct, i.e. every PCI bus has its own 64K I/O
> addresses starting at zero. We linearize them into the
> Linux I/O space using the per-domain io_offset value.
I am going to summarize my understanding here below:
It seems to me that what is linearized is the virtual address
space associated to the IO address space. This address space
goes from PCI_IOBASE to (PCI_IOBASE + IO_SPACE_LIMIT).
The I/O accessors perform rd/wr operation on this address
space using a port IO token.
Each token map into a cpu physical address range
Each cpu physical address range maps to a bus address range
if the bus controller specifies a range property.
Devices under a bus controller specify the bus addresses that
they operate on in their reg property.
So each device can use the same bus addresses under two
separate bus controllers as long as the bus controller
use the range properties to map the same bus range to different
cpu address range.
>
> For the ISA/LPC spaces there are only 4k of addresses, they
> the bus addresses always overlap, but we can trivially
> figure out the bus address from Linux I/O port number
> by subtracting the start of the range.
Are you saying that our LPC controller should specify a
range property to map bus addresses into a cpu address range?
>
> > > Another option the IA64 approach mentioned in another subthread
> > > today, looking up the operations based on an index from the
> > > upper bits of the port number. If we do this, we probably
> > > want to do that for all PIO access and replace the entire
> > > virtual address remapping logic with that. I think Bjorn
> > > in the past argued in favor of such an approach, while I
> > > advocated the current scheme for simplicity based on how
> > > every I/O space these days is just memory mapped (which now
> > > turned out to be false, both on powerpc and arm64).
> >
> > This seems really complex...I am a bit worried that possibly
> > we end up in having the maintainers saying that it is not worth
> > to re-invent the world just for this special LPC device...
>
> It would clearly be a rather invasive change, but the
> end-result isn't necessarily more complex than what we
> have today, as we'd kill off the crazy pci_pio_to_address()
> and pci_address_to_pio() hacks in address translation.
I have to look better into this...can you provide me a reference
to the Bjorn argument in favor of this approach?
>
> > To be honest with you I would keep things simple for this
> > LPC and introduce more complex reworks later if more devices
> > need to be introduced.
> >
> > What if we stick on a single domain now where we introduce a
> > reserved threshold for the IO space (say INDIRECT_MAX_IO).
>
> I said having a single domain is fine, but I still don't
> like the idea of reserving low port numbers for this hack,
> it would mean that the numbers change for everyone else.
I don't get this much...I/O tokens that are passed to the I/O
accessors are not fixed anyway and they vary depending on the order
of adding ranges to io_range_list...so I don't see a big issue
with this...
>
> > We define INDIRECT_MAX_IO as 0 in "include/linux/extio.h" and
> > we define INDIRECT_MAX_IO as 0x1000 in "arch/arm64/include/asm/io.h"
> >
> > So effectively this threshold can change according to the
> > architecture and so far we only define it for ARM64 as we need
> > it for ARM64...
>
> I liked the idea of having it done in asm-generic/io.h (in an ifdef)
> and lib/*.c under an as someone suggested earlier. There is nothing
> ARM64 specific in the implementation.
Correct and ideally if the INDIRECT_MAX_IO approach was taken then we
should define INDIRECT_MAX_IO for any architecture that can support the
special LPC devices. We would define it for ARM64 just because LPC
is used in our case under ARM64; the idea was to leave other architecture
to define their own ones as needed...but probably this is wrong and
we should have defined this for all the architectures.
Many thanks
Gab
>
> Arnd
^ permalink raw reply
* Re: [PATCH v8] mwifiex: parse device tree node for PCIe
From: Kalle Valo @ 2016-11-18 16:21 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Cathy Luo,
Nishant Sarmukadam, rajatja-hpIqsD4AKlfQT0dZR+AlfA,
briannorris-hpIqsD4AKlfQT0dZR+AlfA,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA, Xinming Hu
In-Reply-To: <1479472624-22340-1-git-send-email-akarwar-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
Amitkumar Karwar <akarwar-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org> writes:
> From: Xinming Hu <huxm-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
>
> This patch derives device tree node from pcie bus layer framework.
> Device tree bindings file has been renamed(marvell-sd8xxx.txt ->
> marvell-8xxx.txt) to accommodate PCIe changes.
>
> Signed-off-by: Xinming Hu <huxm-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
> Signed-off-by: Rajat Jain <rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> Signed-off-by: Amitkumar Karwar <akarwar-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
[...]
> @@ -10,6 +10,8 @@ Required properties:
> - compatible : should be one of the following:
> * "marvell,sd8897"
> * "marvell,sd8997"
> + * "pci11ab,2b42"
> + * "pci1b4b,2b42"
Are these correct? In v6 Rob said:
"I think I already said this, but you have the vendor and product IDs
reversed."
https://patchwork.kernel.org/patch/9390225/
--
Kalle Valo
--
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/3] dt-bindings: Add Macnica Americas vendor prefix
From: Dinh Nguyen @ 2016-11-18 16:25 UTC (permalink / raw)
To: Dinh Nguyen
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Dinh Nguyen,
Rob Herring, Mark Rutland,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20161101153632.6844-1-dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Hi Rob,
On Tue, Nov 1, 2016 at 10:36 AM, Dinh Nguyen <dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Add a vendor prefix for the Macnica company.
> http://http://www.macnica.com
>
> Signed-off-by: Dinh Nguyen <dinguyen-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index f0a48ea..81674f2 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -158,6 +158,7 @@ lg LG Corporation
> linux Linux-specific binding
> lltc Linear Technology Corporation
> lsi LSI Corp. (LSI Logic)
> +macnica Macnica Americas
> marvell Marvell Technology Group Ltd.
> maxim Maxim Integrated Products
> meas Measurement Specialties
> --
> 2.8.3
Just a gentle ping.
Thanks,
Dinh
--
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] clk: qcom: smd-rpm: Add msm8974 clocks
From: Bjorn Andersson @ 2016-11-18 16:32 UTC (permalink / raw)
To: Georgi Djakov
Cc: Michael Turquette, Stephen Boyd, linux-clk, devicetree,
linux-kernel, linux-arm-msm, linux-soc
In-Reply-To: <3c57fe94-e6b3-d884-9c80-aa26e5ef9fde@linaro.org>
On Thu 17 Nov 07:53 PST 2016, Georgi Djakov wrote:
> On 11/15/2016 08:54 AM, Bjorn Andersson wrote:
> >This adds all RPM based clocks for msm8974 except cxo and gfx3d_clk_src.
> >
> >Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> >---
> > .../devicetree/bindings/clock/qcom,rpmcc.txt | 1 +
> > drivers/clk/qcom/clk-smd-rpm.c | 71 ++++++++++++++++++++++
> > include/dt-bindings/clock/qcom,rpmcc.h | 40 +++++++++++-
> > 3 files changed, 110 insertions(+), 2 deletions(-)
> >
> >diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> >index 87d3714b956a..a7235e9e1c97 100644
> >--- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> >+++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> >@@ -11,6 +11,7 @@ Required properties :
> > compatible "qcom,rpmcc" should be also included.
> >
> > "qcom,rpmcc-msm8916", "qcom,rpmcc"
> >+ "qcom,rpmcc-msm8974", "qcom,rpmcc"
> > "qcom,rpmcc-apq8064", "qcom,rpmcc"
> >
> > - #clock-cells : shall contain 1
> >diff --git a/drivers/clk/qcom/clk-smd-rpm.c b/drivers/clk/qcom/clk-smd-rpm.c
> >index a27013dbc0aa..b8fcac6f2f87 100644
> >--- a/drivers/clk/qcom/clk-smd-rpm.c
> >+++ b/drivers/clk/qcom/clk-smd-rpm.c
> >@@ -462,8 +462,79 @@ static const struct rpm_smd_clk_desc rpm_clk_msm8916 = {
> > .num_clks = ARRAY_SIZE(msm8916_clks),
> > };
> >
> >+/* msm8974 */
> >+DEFINE_CLK_SMD_RPM(msm8974, pnoc_clk, pnoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 0);
> >+DEFINE_CLK_SMD_RPM(msm8974, snoc_clk, snoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 1);
> >+DEFINE_CLK_SMD_RPM(msm8974, cnoc_clk, cnoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 2);
> >+DEFINE_CLK_SMD_RPM(msm8974, mmssnoc_ahb_clk, mmssnoc_ahb_a_clk, QCOM_SMD_RPM_BUS_CLK, 3);
> >+DEFINE_CLK_SMD_RPM(msm8974, bimc_clk, bimc_a_clk, QCOM_SMD_RPM_MEM_CLK, 0);
> >+DEFINE_CLK_SMD_RPM(msm8974, gfx3d_clk_src, gfx3d_a_clk_src, QCOM_SMD_RPM_MEM_CLK, 1);
> >+DEFINE_CLK_SMD_RPM(msm8974, ocmemgx_clk, ocmemgx_a_clk, QCOM_SMD_RPM_MEM_CLK, 2);
> >+DEFINE_CLK_SMD_RPM_QDSS(msm8974, qdss_clk, qdss_a_clk, QCOM_SMD_RPM_MISC_CLK, 1);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_d0, cxo_d0_a, 1);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_d1, cxo_d1_a, 2);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_a0, cxo_a0_a, 4);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_a1, cxo_a1_a, 5);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_a2, cxo_a2_a, 6);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, diff_clk, diff_a_clk, 7);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, div_clk1, div_a_clk1, 11);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, div_clk2, div_a_clk2, 12);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_d0_pin, cxo_d0_a_pin, 1);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_d1_pin, cxo_d1_a_pin, 2);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_a0_pin, cxo_a0_a_pin, 4);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_a1_pin, cxo_a1_a_pin, 5);
> >+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_a2_pin, cxo_a2_a_pin, 6);
> >+
> >+static struct clk_smd_rpm *msm8974_clks[] = {
> >+ [RPM_SMD_PNOC_CLK] = &msm8974_pnoc_clk,
> >+ [RPM_SMD_PNOC_A_CLK] = &msm8974_pnoc_a_clk,
> >+ [RPM_SMD_SNOC_CLK] = &msm8974_snoc_clk,
> >+ [RPM_SMD_SNOC_A_CLK] = &msm8974_snoc_a_clk,
> >+ [RPM_SMD_CNOC_CLK] = &msm8974_cnoc_clk,
> >+ [RPM_SMD_CNOC_A_CLK] = &msm8974_cnoc_a_clk,
> >+ [RPM_SMD_MMSSNOC_AHB_CLK] = &msm8974_mmssnoc_ahb_clk,
> >+ [RPM_SMD_MMSSNOC_AHB_A_CLK] = &msm8974_mmssnoc_ahb_a_clk,
> >+ [RPM_SMD_BIMC_CLK] = &msm8974_bimc_clk,
> >+ [RPM_SMD_BIMC_A_CLK] = &msm8974_bimc_a_clk,
> >+ [RPM_SMD_OCMEMGX_CLK] = &msm8974_ocmemgx_clk,
> >+ [RPM_SMD_OCMEMGX_A_CLK] = &msm8974_ocmemgx_a_clk,
> >+ [RPM_SMD_QDSS_CLK] = &msm8974_qdss_clk,
> >+ [RPM_SMD_QDSS_A_CLK] = &msm8974_qdss_a_clk,
> >+ [RPM_SMD_CXO_D0] = &msm8974_cxo_d0,
> >+ [RPM_SMD_CXO_D0_A] = &msm8974_cxo_d0_a,
> >+ [RPM_SMD_CXO_D1] = &msm8974_cxo_d1,
> >+ [RPM_SMD_CXO_D1_A] = &msm8974_cxo_d1_a,
> >+ [RPM_SMD_CXO_A0] = &msm8974_cxo_a0,
> >+ [RPM_SMD_CXO_A0_A] = &msm8974_cxo_a0_a,
> >+ [RPM_SMD_CXO_A1] = &msm8974_cxo_a1,
> >+ [RPM_SMD_CXO_A1_A] = &msm8974_cxo_a1_a,
> >+ [RPM_SMD_CXO_A2] = &msm8974_cxo_a2,
>
> There are some extra tabs above. Otherwise looks fine:
> Tested-by: Georgi Djakov <georgi.djakov@linaro.org>
>
Doesn't look like I can blame this on the tools...I'll send an update.
Thanks for taking a look!
Regards,
Bjorn
^ permalink raw reply
* [PATCH v2] clk: qcom: smd-rpmcc: Add msm8974 clocks
From: Bjorn Andersson @ 2016-11-18 16:33 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: linux-clk, devicetree, linux-kernel, linux-arm-msm, linux-soc,
Georgi Djakov
This adds all RPM based clocks for msm8974, except cxo and
gfx3d_clk_src.
Tested-by: Georgi Djakov <georgi.djakov@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
Changes since v1:
- Fixed the screwed up indentation
.../devicetree/bindings/clock/qcom,rpmcc.txt | 1 +
drivers/clk/qcom/clk-smd-rpm.c | 71 ++++++++++++++++++++++
include/dt-bindings/clock/qcom,rpmcc.h | 40 +++++++++++-
3 files changed, 110 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
index 87d3714b956a..a7235e9e1c97 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
@@ -11,6 +11,7 @@ Required properties :
compatible "qcom,rpmcc" should be also included.
"qcom,rpmcc-msm8916", "qcom,rpmcc"
+ "qcom,rpmcc-msm8974", "qcom,rpmcc"
"qcom,rpmcc-apq8064", "qcom,rpmcc"
- #clock-cells : shall contain 1
diff --git a/drivers/clk/qcom/clk-smd-rpm.c b/drivers/clk/qcom/clk-smd-rpm.c
index a27013dbc0aa..c1c1e7b5be64 100644
--- a/drivers/clk/qcom/clk-smd-rpm.c
+++ b/drivers/clk/qcom/clk-smd-rpm.c
@@ -462,8 +462,79 @@ static const struct rpm_smd_clk_desc rpm_clk_msm8916 = {
.num_clks = ARRAY_SIZE(msm8916_clks),
};
+/* msm8974 */
+DEFINE_CLK_SMD_RPM(msm8974, pnoc_clk, pnoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 0);
+DEFINE_CLK_SMD_RPM(msm8974, snoc_clk, snoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 1);
+DEFINE_CLK_SMD_RPM(msm8974, cnoc_clk, cnoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 2);
+DEFINE_CLK_SMD_RPM(msm8974, mmssnoc_ahb_clk, mmssnoc_ahb_a_clk, QCOM_SMD_RPM_BUS_CLK, 3);
+DEFINE_CLK_SMD_RPM(msm8974, bimc_clk, bimc_a_clk, QCOM_SMD_RPM_MEM_CLK, 0);
+DEFINE_CLK_SMD_RPM(msm8974, gfx3d_clk_src, gfx3d_a_clk_src, QCOM_SMD_RPM_MEM_CLK, 1);
+DEFINE_CLK_SMD_RPM(msm8974, ocmemgx_clk, ocmemgx_a_clk, QCOM_SMD_RPM_MEM_CLK, 2);
+DEFINE_CLK_SMD_RPM_QDSS(msm8974, qdss_clk, qdss_a_clk, QCOM_SMD_RPM_MISC_CLK, 1);
+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_d0, cxo_d0_a, 1);
+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_d1, cxo_d1_a, 2);
+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_a0, cxo_a0_a, 4);
+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_a1, cxo_a1_a, 5);
+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, cxo_a2, cxo_a2_a, 6);
+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, diff_clk, diff_a_clk, 7);
+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, div_clk1, div_a_clk1, 11);
+DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8974, div_clk2, div_a_clk2, 12);
+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_d0_pin, cxo_d0_a_pin, 1);
+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_d1_pin, cxo_d1_a_pin, 2);
+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_a0_pin, cxo_a0_a_pin, 4);
+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_a1_pin, cxo_a1_a_pin, 5);
+DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8974, cxo_a2_pin, cxo_a2_a_pin, 6);
+
+static struct clk_smd_rpm *msm8974_clks[] = {
+ [RPM_SMD_PNOC_CLK] = &msm8974_pnoc_clk,
+ [RPM_SMD_PNOC_A_CLK] = &msm8974_pnoc_a_clk,
+ [RPM_SMD_SNOC_CLK] = &msm8974_snoc_clk,
+ [RPM_SMD_SNOC_A_CLK] = &msm8974_snoc_a_clk,
+ [RPM_SMD_CNOC_CLK] = &msm8974_cnoc_clk,
+ [RPM_SMD_CNOC_A_CLK] = &msm8974_cnoc_a_clk,
+ [RPM_SMD_MMSSNOC_AHB_CLK] = &msm8974_mmssnoc_ahb_clk,
+ [RPM_SMD_MMSSNOC_AHB_A_CLK] = &msm8974_mmssnoc_ahb_a_clk,
+ [RPM_SMD_BIMC_CLK] = &msm8974_bimc_clk,
+ [RPM_SMD_BIMC_A_CLK] = &msm8974_bimc_a_clk,
+ [RPM_SMD_OCMEMGX_CLK] = &msm8974_ocmemgx_clk,
+ [RPM_SMD_OCMEMGX_A_CLK] = &msm8974_ocmemgx_a_clk,
+ [RPM_SMD_QDSS_CLK] = &msm8974_qdss_clk,
+ [RPM_SMD_QDSS_A_CLK] = &msm8974_qdss_a_clk,
+ [RPM_SMD_CXO_D0] = &msm8974_cxo_d0,
+ [RPM_SMD_CXO_D0_A] = &msm8974_cxo_d0_a,
+ [RPM_SMD_CXO_D1] = &msm8974_cxo_d1,
+ [RPM_SMD_CXO_D1_A] = &msm8974_cxo_d1_a,
+ [RPM_SMD_CXO_A0] = &msm8974_cxo_a0,
+ [RPM_SMD_CXO_A0_A] = &msm8974_cxo_a0_a,
+ [RPM_SMD_CXO_A1] = &msm8974_cxo_a1,
+ [RPM_SMD_CXO_A1_A] = &msm8974_cxo_a1_a,
+ [RPM_SMD_CXO_A2] = &msm8974_cxo_a2,
+ [RPM_SMD_CXO_A2_A] = &msm8974_cxo_a2_a,
+ [RPM_SMD_DIFF_CLK] = &msm8974_diff_clk,
+ [RPM_SMD_DIFF_A_CLK] = &msm8974_diff_a_clk,
+ [RPM_SMD_DIV_CLK1] = &msm8974_div_clk1,
+ [RPM_SMD_DIV_A_CLK1] = &msm8974_div_a_clk1,
+ [RPM_SMD_DIV_CLK2] = &msm8974_div_clk2,
+ [RPM_SMD_DIV_A_CLK2] = &msm8974_div_a_clk2,
+ [RPM_SMD_CXO_D0_PIN] = &msm8974_cxo_d0_pin,
+ [RPM_SMD_CXO_D0_A_PIN] = &msm8974_cxo_d0_a_pin,
+ [RPM_SMD_CXO_D1_PIN] = &msm8974_cxo_d1_pin,
+ [RPM_SMD_CXO_D1_A_PIN] = &msm8974_cxo_d1_a_pin,
+ [RPM_SMD_CXO_A0_PIN] = &msm8974_cxo_a0_pin,
+ [RPM_SMD_CXO_A0_A_PIN] = &msm8974_cxo_a0_a_pin,
+ [RPM_SMD_CXO_A1_PIN] = &msm8974_cxo_a1_pin,
+ [RPM_SMD_CXO_A1_A_PIN] = &msm8974_cxo_a1_a_pin,
+ [RPM_SMD_CXO_A2_PIN] = &msm8974_cxo_a2_pin,
+ [RPM_SMD_CXO_A2_A_PIN] = &msm8974_cxo_a2_a_pin,
+};
+
+static const struct rpm_smd_clk_desc rpm_clk_msm8974 = {
+ .clks = msm8974_clks,
+ .num_clks = ARRAY_SIZE(msm8974_clks),
+};
static const struct of_device_id rpm_smd_clk_match_table[] = {
{ .compatible = "qcom,rpmcc-msm8916", .data = &rpm_clk_msm8916 },
+ { .compatible = "qcom,rpmcc-msm8974", .data = &rpm_clk_msm8974 },
{ }
};
MODULE_DEVICE_TABLE(of, rpm_smd_clk_match_table);
diff --git a/include/dt-bindings/clock/qcom,rpmcc.h b/include/dt-bindings/clock/qcom,rpmcc.h
index 5924cdb71336..96b63c00249e 100644
--- a/include/dt-bindings/clock/qcom,rpmcc.h
+++ b/include/dt-bindings/clock/qcom,rpmcc.h
@@ -14,7 +14,7 @@
#ifndef _DT_BINDINGS_CLK_MSM_RPMCC_H
#define _DT_BINDINGS_CLK_MSM_RPMCC_H
-/* apq8064 */
+/* RPM clocks */
#define RPM_PXO_CLK 0
#define RPM_PXO_A_CLK 1
#define RPM_CXO_CLK 2
@@ -38,7 +38,7 @@
#define RPM_SFPB_CLK 20
#define RPM_SFPB_A_CLK 21
-/* msm8916 */
+/* SMD RPM clocks */
#define RPM_SMD_XO_CLK_SRC 0
#define RPM_SMD_XO_A_CLK_SRC 1
#define RPM_SMD_PCNOC_CLK 2
@@ -65,5 +65,41 @@
#define RPM_SMD_RF_CLK1_A_PIN 23
#define RPM_SMD_RF_CLK2_PIN 24
#define RPM_SMD_RF_CLK2_A_PIN 25
+#define RPM_SMD_PNOC_CLK 26
+#define RPM_SMD_PNOC_A_CLK 27
+#define RPM_SMD_CNOC_CLK 28
+#define RPM_SMD_CNOC_A_CLK 29
+#define RPM_SMD_MMSSNOC_AHB_CLK 30
+#define RPM_SMD_MMSSNOC_AHB_A_CLK 31
+#define RPM_SMD_GFX3D_CLK_SRC 32
+#define RPM_SMD_GFX3D_A_CLK_SRC 33
+#define RPM_SMD_OCMEMGX_CLK 34
+#define RPM_SMD_OCMEMGX_A_CLK 35
+#define RPM_SMD_CXO_D0 36
+#define RPM_SMD_CXO_D0_A 37
+#define RPM_SMD_CXO_D1 38
+#define RPM_SMD_CXO_D1_A 39
+#define RPM_SMD_CXO_A0 40
+#define RPM_SMD_CXO_A0_A 41
+#define RPM_SMD_CXO_A1 42
+#define RPM_SMD_CXO_A1_A 43
+#define RPM_SMD_CXO_A2 44
+#define RPM_SMD_CXO_A2_A 45
+#define RPM_SMD_DIV_CLK1 46
+#define RPM_SMD_DIV_A_CLK1 47
+#define RPM_SMD_DIV_CLK2 48
+#define RPM_SMD_DIV_A_CLK2 49
+#define RPM_SMD_DIFF_CLK 50
+#define RPM_SMD_DIFF_A_CLK 51
+#define RPM_SMD_CXO_D0_PIN 52
+#define RPM_SMD_CXO_D0_A_PIN 53
+#define RPM_SMD_CXO_D1_PIN 54
+#define RPM_SMD_CXO_D1_A_PIN 55
+#define RPM_SMD_CXO_A0_PIN 56
+#define RPM_SMD_CXO_A0_A_PIN 57
+#define RPM_SMD_CXO_A1_PIN 58
+#define RPM_SMD_CXO_A1_A_PIN 59
+#define RPM_SMD_CXO_A2_PIN 60
+#define RPM_SMD_CXO_A2_A_PIN 61
#endif
--
2.5.0
^ permalink raw reply related
* Re: [RFC 2/6] drm/etnaviv: allow building etnaviv on omap devices
From: Rob Herring @ 2016-11-18 16:33 UTC (permalink / raw)
To: Robert Nelson
Cc: tony-4v6yS6AI5VpBDgjK7y7TUQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Christian Gmeiner, Russell King, Lucas Stach
In-Reply-To: <20161118024436.13447-2-robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Nov 17, 2016 at 08:44:32PM -0600, Robert Nelson wrote:
> Signed-off-by: Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Christian Gmeiner <christian.gmeiner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: Russell King <rmk+kernel-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> CC: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
> drivers/gpu/drm/etnaviv/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig
> index 2cde7a5..b776f41 100644
> --- a/drivers/gpu/drm/etnaviv/Kconfig
> +++ b/drivers/gpu/drm/etnaviv/Kconfig
> @@ -2,7 +2,7 @@
> config DRM_ETNAVIV
> tristate "ETNAVIV (DRM support for Vivante GPU IP cores)"
> depends on DRM
> - depends on ARCH_MXC || ARCH_DOVE
> + depends on ARCH_MXC || ARCH_DOVE || ARCH_OMAP2PLUS
Why not just drop this line. Then it will get better build testing, too.
> select SHMEM
> select TMPFS
> select IOMMU_API
> --
> 2.10.2
>
> --
> 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
--
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 V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-11-18 16:34 UTC (permalink / raw)
To: Gabriele Paoloni
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org,
catalin.marinas-5wv7dgnIgG8@public.gmane.org,
liviu.dudau-5wv7dgnIgG8@public.gmane.org, Linuxarm,
lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org, xuwei (O),
Jason Gunthorpe,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
minyard-HInyCGIudOg@public.gmane.org,
will.deacon-5wv7dgnIgG8@public.gmane.org, John Garry, zourongrong
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F921858@lhreml507-mbx>
On Friday, November 18, 2016 4:18:07 PM CET Gabriele Paoloni wrote:
> From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> > On Friday, November 18, 2016 12:53:08 PM CET Gabriele Paoloni wrote:
> > > From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> > > > On Friday, November 18, 2016 12:07:28 PM CET Gabriele Paoloni
> > > > The easiest change compared to the v5 code would be to walk
> > > > a linked list of 'struct extio_ops' structures rather than
> > > > assuming there is only ever one of them. I think one of the
> > > > earlier versions actually did this.
> > >
> > > Right but if my understanding is correct if we live in a multi-
> > > domain I/O space world when you have an input addr in the I/O
> > > accessors this addr can be duplicated (for example for the standard
> > > PCI IO domain and for our special LPC domain).
> > > So effectively even if you walk a linked list there is a problem
> > > of disambiguation...am I right?
> >
> > No, unlike the PCI memory space, the PIO addresses are not
> > usually distinct, i.e. every PCI bus has its own 64K I/O
> > addresses starting at zero. We linearize them into the
> > Linux I/O space using the per-domain io_offset value.
>
> I am going to summarize my understanding here below:
>
> It seems to me that what is linearized is the virtual address
> space associated to the IO address space. This address space
> goes from PCI_IOBASE to (PCI_IOBASE + IO_SPACE_LIMIT).
>
> The I/O accessors perform rd/wr operation on this address
> space using a port IO token.
>
> Each token map into a cpu physical address range
> Each cpu physical address range maps to a bus address range
> if the bus controller specifies a range property.
>
> Devices under a bus controller specify the bus addresses that
> they operate on in their reg property.
>
> So each device can use the same bus addresses under two
> separate bus controllers as long as the bus controller
> use the range properties to map the same bus range to different
> cpu address range.
Sounds all correct to me so far, yes.
> > For the ISA/LPC spaces there are only 4k of addresses, they
> > the bus addresses always overlap, but we can trivially
> > figure out the bus address from Linux I/O port number
> > by subtracting the start of the range.
>
> Are you saying that our LPC controller should specify a
> range property to map bus addresses into a cpu address range?
No. There is not CPU address associated with it, because it's
not memory mapped.
Instead, we need to associate a bus address with a logical
Linux port number, both in of_address_to_resource and
in inb()/outb().
> > > > Another option the IA64 approach mentioned in another subthread
> > > > today, looking up the operations based on an index from the
> > > > upper bits of the port number. If we do this, we probably
> > > > want to do that for all PIO access and replace the entire
> > > > virtual address remapping logic with that. I think Bjorn
> > > > in the past argued in favor of such an approach, while I
> > > > advocated the current scheme for simplicity based on how
> > > > every I/O space these days is just memory mapped (which now
> > > > turned out to be false, both on powerpc and arm64).
> > >
> > > This seems really complex...I am a bit worried that possibly
> > > we end up in having the maintainers saying that it is not worth
> > > to re-invent the world just for this special LPC device...
> >
> > It would clearly be a rather invasive change, but the
> > end-result isn't necessarily more complex than what we
> > have today, as we'd kill off the crazy pci_pio_to_address()
> > and pci_address_to_pio() hacks in address translation.
>
> I have to look better into this...can you provide me a reference
> to the Bjorn argument in favor of this approach?
The thread seems to have been pci: Introduce pci_register_io_range()
helper function, e.g. in https://lkml.org/lkml/2014/7/8/969
> > > To be honest with you I would keep things simple for this
> > > LPC and introduce more complex reworks later if more devices
> > > need to be introduced.
> > >
> > > What if we stick on a single domain now where we introduce a
> > > reserved threshold for the IO space (say INDIRECT_MAX_IO).
> >
> > I said having a single domain is fine, but I still don't
> > like the idea of reserving low port numbers for this hack,
> > it would mean that the numbers change for everyone else.
>
> I don't get this much...I/O tokens that are passed to the I/O
> accessors are not fixed anyway and they vary depending on the order
> of adding ranges to io_range_list...so I don't see a big issue
> with this...
On machines with a legacy devices behind the PCI bridge,
there may still be a reason to have the low I/O port range
reserved for the primary bus, e.g. to get a VGA text console
to work.
On powerpc, this is called the "primary" PCI host, i.e. the
only one that is allowed to have an ISA bridge.
Arnd
--
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 v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver
From: Bjorn Andersson @ 2016-11-18 16:40 UTC (permalink / raw)
To: Vinod Koul
Cc: Peter Griffin, linux-arm-kernel, linux-kernel, kernel, ohad,
patrice.chotard, lee.jones, dmaengine, devicetree,
linux-remoteproc
In-Reply-To: <20161117095252.GC2698@localhost>
On Thu 17 Nov 01:52 PST 2016, Vinod Koul wrote:
> On Wed, Nov 16, 2016 at 10:36:46PM -0800, Bjorn Andersson wrote:
> > On Sun 13 Nov 21:18 PST 2016, Vinod Koul wrote:
> >
> > > On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> > > > >
> > > > > As you now make changes to the entire remoteproc Kconfig file, rather
> > > > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > > > > without providing Linus with a messy merge conflict.
> > > > >
> > > > > So the remoteproc parts now has to go through my tree.
> > > >
> > > > OK, I think the best approach is for Vinod to create an immutable
> > > > branch with the entire fdma series on, and then both of you merge that branch into
> > > > your respective trees.
> > >
> > > my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
> > > tag, please do let me know
> > >
> >
> > Hi Vinod,
> >
> > It looks like you reverted the wrong Kconfig fix, the one I objected to
> > was the change in drivers/remoteproc, not the one in drivers/dma.
> >
> > The ST_FMDA depends on functions exposed by REMOTEPROC and
> > ST_SLIM_REMOTEPROC, the latter in turn depends on REMOTEPROC, which you
> > guys made user selectable - and as such should not be selected - but I
> > think we should move forward and get everything merged and then we can
> > go back and figure out how this should be addressed (or left alone?).
> >
> > I have merged "topic/st_fdma" into rproc-next, so that I can fix up the
> > now broken drivers/remoteproc/Kconfig.
> >
> > We do however both need to revert the revert or there will be link
> > errors if you build the dma driver with remoteproc=n. If you do this I
> > can merge the topic once more and we'll keep the set of changes in sync.
>
> Oops my bad, thanks for letting me know. I have reverted this now and
> pushing out. Please do let me know if this was fine
>
Thanks for the update Vinod, I've merged in your updated branch into
mine, so now we should be good.
Regards,
Bjorn
^ permalink raw reply
* Re: [RFC 6/6] ARM: dts: am57xx-beagle-x15-common: enable etnaviv
From: Rob Herring @ 2016-11-18 16:42 UTC (permalink / raw)
To: Nishanth Menon
Cc: Robert Nelson, tony-4v6yS6AI5VpBDgjK7y7TUQ,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Julien,
Tomi Valkeinen
In-Reply-To: <e69a797c-bec3-2243-5c19-9d7633092369-l0cyMroinI0@public.gmane.org>
On Thu, Nov 17, 2016 at 08:56:18PM -0600, Nishanth Menon wrote:
> On 11/17/2016 08:44 PM, Robert Nelson wrote:
> again.. a short commit message at least please? :)
>
> > Signed-off-by: Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > CC: Julien <jboulnois-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > CC: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
> > CC: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
> > CC: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> > ---
> > arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
> > index 6df7829..3bc47be 100644
> > --- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
> > +++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
> > @@ -97,6 +97,12 @@
> > #cooling-cells = <2>;
> > };
> >
> > + gpu-subsystem {
> A) do we want to make things clear that this is gpu subsystem for gc320?
No.
> B) How about other platforms that could equally reuse?
Better yet, get rid of this nonsense. You are defining a wrapper to
group 1 nodes. Yes, I know this is what the driver wants, but you should
be able to make it deal with this situation and only have a gc320 node.
> > + compatible = "ti,gc320-gpu-subsystem";
> > + cores = <&bb2d>;
> > + status = "okay";
> > + };
> > +
--
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