Patch "MFD/OF: document MFD devices and handle simple-mfd" has been added to the 4.1-stable tree
This is a note to let you know that I've just added the patch titled
MFD/OF: document MFD devices and handle simple-mfd
to the 4.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mfd-of-document-mfd-devices-and-handle-simple-mfd.patch
and it can be found in the queue-4.1 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 22869a9eca4ea5b534538d160b68c7aef44e378a Mon Sep 17 00:00:00 2001
From: Linus Walleij
Date: Tue, 3 Mar 2015 09:52:20 +0100
Subject: MFD/OF: document MFD devices and handle simple-mfd
From: Linus Walleij
commit 22869a9eca4ea5b534538d160b68c7aef44e378a upstream.
This defines a new compatible option for MFD devices "simple-mfd" that will
make the OF core spawn child devices for all subnodes of that MFD device.
It is optional but handy for things like syscon and possibly other
simpler MFD devices.
Since there was no file to put the documentation in, I took this opportunity
to make a small writeup on MFD devices and add the compatible definition
there.
Suggested-by: Lee Jones
Acked-by: Lee Jones
Acked-by: Antoine Tenart
Acked-by: Alexandre Belloni
Cc: Arnd Bergmann
Cc: Devicetree
Cc: Rob Herring
Cc: Benjamin Herrenschmidt
Cc: Grant Likely
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Linus Walleij
Cc: Henrik Juul Pedersen
Signed-off-by: Greg Kroah-Hartman
---
Documentation/devicetree/bindings/mfd/mfd.txt | 41 ++
drivers/of/platform.c |1
2 files changed, 42 insertions(+)
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/mfd.txt
@@ -0,0 +1,41 @@
+Multi-Function Devices (MFD)
+
+These devices comprise a nexus for heterogeneous hardware blocks containing
+more than one non-unique yet varying hardware functionality.
+
+A typical MFD can be:
+
+- A mixed signal ASIC on an external bus, sometimes a PMIC (Power Management
+ Integrated Circuit) that is manufactured in a lower technology node (rough
+ silicon) that handles analog drivers for things like audio amplifiers, LED
+ drivers, level shifters, PHY (physical interfaces to things like USB or
+ ethernet), regulators etc.
+
+- A range of memory registers containing "miscellaneous system registers" also
+ known as a system controller "syscon" or any other memory range containing a
+ mix of unrelated hardware devices.
+
+Optional properties:
+
+- compatible : "simple-mfd" - this signifies that the operating system should
+ consider all subnodes of the MFD device as separate devices akin to how
+ "simple-bus" inidicates when to see subnodes as children for a simple
+ memory-mapped bus. For more complex devices, when the nexus driver has to
+ probe registers to figure out what child devices exist etc, this should not
+ be used. In the latter case the child devices will be determined by the
+ operating system.
+
+Example:
+
+foo@1000 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0x01000 0x1000>;
+
+ led@08.0 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x01>;
+ label = "myled";
+ default-state = "on";
+ };
+};
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -25,6 +25,7 @@
const struct of_device_id of_default_bus_match_table[] = {
{ .compatible = "simple-bus", },
+ { .compatible = "simple-mfd", },
#ifdef CONFIG_ARM_AMBA
{ .compatible = "arm,amba-bus", },
#endif /* CONFIG_ARM_AMBA */
Patches currently in stable-queue which might be from linus.wall...@linaro.org
are
queue-4.1/iio-st_accel-fix-interrupt-handling-on-lis3lv02.patch
queue-4.1/mfd-of-document-mfd-devices-and-handle-simple-mfd.patch
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MAINTAINERS: update DT binding doc locations
On Friday 06 November 2015 01:11 AM, Rob Herring wrote: > After the recent moving of DT binding documents, some maintainers entries > are stale. Update them to the new locations. > > In bindings/fb/, there were only 2 files and I'm assuming the FB > maintainers don't want to be copied on all of bindings/display/. So I've > dropped them. > > Reported-by: Thierry Reding > Cc: Thierry Reding > Cc: Jianwei Wang > Cc: Alison Wang > Cc: Philipp Zabel > Cc: Mark Yao > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Cc: Jean-Christophe Plagniol-Villard > Cc: Tomi Valkeinen > Cc: James Hogan > Cc: Hans de Goede > Cc: Vineet Gupta For arc bits: Acked-by: Vineet Gupta > Signed-off-by: Rob Herring > --- > ... > > @@ -10072,6 +10072,7 @@ M:Vineet Gupta > S: Supported > F: arch/arc/ > F: Documentation/devicetree/bindings/arc/* > +F: Documentation/devicetree/bindings/interrupt-controller/snps,arc* > F: drivers/tty/serial/arc_uart.c > T: git git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/5] ARM: dts: AM4372: add entry for qspi mmap region
Hi,
Rob Herring writes:
> On Tue, Nov 03, 2015 at 03:36:14PM +0530, Vignesh R wrote:
>> Add qspi memory mapped region entries for AM43xx based SoCs. Also,
>> update the binding documents for the controller to document this change.
>>
>> Signed-off-by: Vignesh R
>
> Acked-by: Rob Herring
>
>> ---
>> Documentation/devicetree/bindings/spi/ti_qspi.txt | 5 +++--
>> arch/arm/boot/dts/am4372.dtsi | 4 +++-
>> 2 files changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt
>> b/Documentation/devicetree/bindings/spi/ti_qspi.txt
>> index f05dd631bef1..05488970060b 100644
>> --- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
>> +++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
>> @@ -17,9 +17,10 @@ Recommended properties:
>>
>> Example:
>>
>> +For am4372:
>> qspi: qspi@4b30 {
>> -compatible = "ti,dra7xxx-qspi";
>> -reg = <0x4790 0x100>, <0x3000 0x3ff>;
>> +compatible = "ti,am4372-qspi";
>> +reg = <0x4790 0x100>, <0x3000 0x400>;
>> reg-names = "qspi_base", "qspi_mmap";
>> #address-cells = <1>;
>> #size-cells = <0>;
and how does the user for this look like ? Don't you need to give this a
proper 'ranges' binding ?
--
balbi
signature.asc
Description: PGP signature
Re: [PATCH RESEND 03/16] Documentation: dt-bindings: hwmon: add TI LMU HWMON binding information
On 11/6/2015 10:57 AM, Rob Herring wrote: On Mon, Nov 02, 2015 at 02:24:22PM +0900, Milo Kim wrote: Hardware fault monitoring driver is used in LM3633 and LM3697 device. Just 'compatible' property is required to describe the driver. Cc: devicetree@vger.kernel.org Cc: Guenter Roeck Cc: Jean Delvare Cc: Lee Jones Cc: lm-sens...@lm-sensors.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Milo Kim Acked-by: Rob Herring Thanks for your review, Rob. HWMON maintainer, Guenter suggested moving LMU HWMON driver to MFD as the sysfs attributes because it has no sensor data like temperature or voltage. So I'll move this property to mfd/ti-lmu.txt in the next patch. Best regards, Milo -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] thermal: mediatek: Add cpu power cooling model.
Cc'ing Javi (which you should have as he wrote the power-thing for cpu-cooling). On 05-11-15, 19:10, dawei chien wrote: > This is because our platform currently only support mt8173_cpufreq.c, so > that I only add static power model for our owner IC. Bindings are (normally) supposed to be general than a platform specific. > Please understanding that I wouldn't give a DT binding document since I > will remove static power table on next version, but I can try to explain > it. Then just don't add things in the first place. > As far as I know, static power is somewhat leakage of CPU clusters, so > that we hardly to find a formula, which can suitable all kinds of CPUs > since leakage is different. In ARM IPA framework, static power only need > to be defined by who register cpufreq_power_cooling_register. The > voltage/power table is just one way to present leakage power of CPUs. The bindings don't fix the values for static power, but just provides a field for platforms to use. Everyone can then send its own power figures. Why do you thing it can't be generalized? > Actually, static power is optional since dynamic power is much more than > static power. Maybe, we should still capture it. @Javi ? -- viresh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] pinctrl: qcom: ipq4019: Add IPQ4019 pinctrl support
> On Nov 5, 2015, at 8:34 PM, Rob Herring wrote: > > On Thu, Nov 05, 2015 at 04:07:52PM -0600, Matthew McClintock wrote: >> From: Varadarajan Narayanan >> >> Add pinctrl driver support for IPQ4019 platform >> >> Signed-off-by: Sricharan R >> Signed-off-by: Mathieu Olivari >> Signed-off-by: Varadarajan Narayanan >> Signed-off-by: Matthew McClintock >> --- >> .../bindings/pinctrl/qcom,ipq4019-pinctrl.txt | 116 ++ >> drivers/pinctrl/qcom/Kconfig |8 + >> drivers/pinctrl/qcom/Makefile |1 + >> drivers/pinctrl/qcom/pinctrl-ipq4019.c | 1280 >> >> 4 files changed, 1405 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt >> create mode 100644 drivers/pinctrl/qcom/pinctrl-ipq4019.c >> >> diff --git >> a/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt >> b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt >> new file mode 100644 >> index 000..045c5aa >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt >> @@ -0,0 +1,116 @@ >> +Qualcomm Atheros IPQ4019 TLMM block >> + >> +Required properties: >> +- compatible: "qcom,ipq4019-pinctrl" > > Perhaps the name should have TLMM in it. Whatever that stands for. Sure, this was a holdover from Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt mostly. Will elaborate on v2 though. -M -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] thermal: mediatek: Add cpu power cooling model
On 05-11-15, 19:09, dawei chien wrote: > Thank you for your kindly explaining, now I could understand what I > miss, I will send device tree binding on next version such like > following description. > > --- a/Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt > +++ b/Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt > @@ -10,6 +10,17 @@ Required properties: > Please refer to > Documentation/devicetree/bindings/clk/clock-bindings.txt for > generic clock consumer properties. > - proc-supply: Regulator for Vproc of CPU cluster. > +- dynamic-power-coefficient: > + Usage: optional > + Value type: > + Definition: A u32 value that represents an indicative > + running time dynamic power coefficient in > + fundamental units of mW/MHz/uVolt^2. > + The dynamic energy consumption of the CPU > + is proportional to the square of the > + Voltage (V) and the clock frequency (f). > + Pdyn = dynamic-power-coefficient * V^2 * f > + where voltage is in uV, frequency is in MHz. Please check with Punit if he is planning to add the same.. > Thank you for your kindly explaining, Now I know I should develop and > test on mainline branch since this is where I try to add code. > > However, please understanding currently mt8173_cpufreq.c is not ready > for OPPV2 in mainline as far, that's the reason why currently I can't > reuse OPPV2 and extend for static power table. My propose is for adding > CPU cooling device for our own product. Firstly, we don't care. You are pushing something to mainline, you have to get it tested someway on mainline. Secondly, there are *almost* no changes required to the mtk cpufreq driver for OPPV2. Just update your DT in a similar way it is done for one of the exynos platforms and it should just work fine. -- viresh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] pinctrl: qcom: ipq4019: Add IPQ4019 pinctrl support
On Thu, Nov 05, 2015 at 04:07:52PM -0600, Matthew McClintock wrote: > From: Varadarajan Narayanan > > Add pinctrl driver support for IPQ4019 platform > > Signed-off-by: Sricharan R > Signed-off-by: Mathieu Olivari > Signed-off-by: Varadarajan Narayanan > Signed-off-by: Matthew McClintock > --- > .../bindings/pinctrl/qcom,ipq4019-pinctrl.txt | 116 ++ > drivers/pinctrl/qcom/Kconfig |8 + > drivers/pinctrl/qcom/Makefile |1 + > drivers/pinctrl/qcom/pinctrl-ipq4019.c | 1280 > > 4 files changed, 1405 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt > create mode 100644 drivers/pinctrl/qcom/pinctrl-ipq4019.c > > diff --git > a/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt > b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt > new file mode 100644 > index 000..045c5aa > --- /dev/null > +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt > @@ -0,0 +1,116 @@ > +Qualcomm Atheros IPQ4019 TLMM block > + > +Required properties: > +- compatible: "qcom,ipq4019-pinctrl" Perhaps the name should have TLMM in it. Whatever that stands for. > +- reg: Should be the base address and length of the TLMM block. > +- interrupts: Should be the parent IRQ of the TLMM block. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] mtd: arasan: Add device tree binding documentation
On Fri, Nov 6, 2015 at 5:19 AM, Rob Herring wrote: > On Thu, Nov 05, 2015 at 08:18:42AM +0530, Punnaiah Choudary Kalluri wrote: >> This patch adds the dts binding document for arasan nand flash >> controller. >> >> Signed-off-by: Punnaiah Choudary Kalluri >> --- >> Changes in v4: >> - Added num-cs property >> - Added clock support >> Changes in v3: >> - None >> Changes in v2: >> - None >> --- >> .../devicetree/bindings/mtd/arasan_nfc.txt | 34 >> ++ >> 1 file changed, 34 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nfc.txt >> >> diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt >> b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt >> new file mode 100644 >> index 000..02e1ce3 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt >> @@ -0,0 +1,34 @@ >> +Arasan Nand Flash Controller with ONFI 3.1 support >> + >> +Required properties: >> +- compatible: Should be "arasan,nfc-v3p10" > > There should also be a chip specific property. Vendors are known to > integrate IP blocks in different and interesting ways. This IP used in xilinx Zynq UltraScale+ MPSoC and we have not observed any deviations to the original IP as of today. We will add chip specific property if we observe any deviation to the original IP spec. Regards, Punnaiah > > Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] crypto: rockchip/crypto - add DT bindings documentation
On Fri, Nov 06, 2015 at 09:17:24AM +0800, Zain Wang wrote:
> Add DT bindings documentation for the rk3288 crypto drivers.
>
> Signed-off-by: Zain Wang
Acked-by: Rob Herring
> ---
>
> Changde in v2:
> - None
>
> Changed in v1:
> - remove the _crypto suffix
> - use "rockchip,rk3288-crypto" instead of "rockchip,rk3288"
> - remove the description of status
>
> .../devicetree/bindings/crypto/rockchip-crypto.txt | 29
> ++
> 1 file changed, 29 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
>
> diff --git a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> new file mode 100644
> index 000..d27e203
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
> @@ -0,0 +1,29 @@
> +Rockchip Electronics And Security Accelerator
> +
> +Required properties:
> +- compatible: Should be "rockchip,rk3288-crypto"
> +- reg: base physical address of the engine and length of memory mapped
> + region
> +- interrupts: interrupt number
> +- clocks: reference to the clocks about crypto
> +- clock-names: "aclk" used to clock data
> +"hclk" used to clock data
> +"srst" used to clock crypto accelerator
> +"apb_pclk" used to clock dma
> +
> +Examples:
> +
> + crypto: cypto-controller@ff8a {
> + compatible = "rockchip,rk3288-crypto";
> + reg = <0xff8a 0x4000>;
> + interrupts = ;
> + clocks = <&cru ACLK_CRYPTO>,
> + <&cru HCLK_CRYPTO>,
> + <&cru SCLK_CRYPTO>,
> + <&cru ACLK_DMAC1>;
> + clock-names = "aclk",
> + "hclk",
> + "sclk",
> + "apb_pclk";
> + status = "okay";
> + };
> --
> 1.9.1
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] devicetree: mfd: Add binding for the TI LM3533
On Fri, Oct 30, 2015 at 04:50:38PM -0700, Bjorn Andersson wrote: > Add the binding for the Texas Instruments LM3533 lighting power > solution. > > Signed-off-by: Bjorn Andersson Acked-by: Rob Herring > --- > > Changes since v2: > - Drop vendor prefix of vendor properties > - Specify unit of various properties > - Fix reference paths > > Changes since v1: > - Added unit to boost-freq and als-resistance (as the frequency now comes with > a unit specifier I changed it to be expressed in kHz) > > Documentation/devicetree/bindings/mfd/lm3533.txt | 184 > +++ > 1 file changed, 184 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/lm3533.txt > > diff --git a/Documentation/devicetree/bindings/mfd/lm3533.txt > b/Documentation/devicetree/bindings/mfd/lm3533.txt > new file mode 100644 > index ..963cee153a4d > --- /dev/null > +++ b/Documentation/devicetree/bindings/mfd/lm3533.txt > @@ -0,0 +1,184 @@ > +Texas Instruments LM3533 binding > + > +This binding describes the Texas Instruments LM3533, a lighting power > solution > +for smartphone handsets. The common properties are described directly in the > +node, while each individual component are described in an optional subnode. > + > +- compatible: > + Usage: required > + Value type: > + Definition: must be: > + "ti,lm3533" > + > +- reg: > + Usage: required > + Value type: > + Definition: i2c address of the LM3533 chip > + > +- als-supply: > + Usage: optional > + Value type: > + Definition: reference to regulator powering the V_als input; as > + specified in "../regulator/regulator.txt" > + > +- hwen-gpios: > + Usage: required > + Value type: > + Definition: reference to gpio pin connected to the HWEN input; as > + specified in "../gpio/gpio.txt" > + > +- ti,boost-freq-hz: > + Usage: required > + Value type: > + Definition: switch-frequency of the boost converter, must be either: > + 50 or 100 > + > +- ti,boost-ovp-mv: > + Usage: required > + Value type: > + Definition: over-voltage protection limit, in mV. Must be one of: > + 16000, 24000, 32000 or 4 > + > +- #address-cells: > + Usage: required > + Value type: > + Definition: must be 1 > + > +- #size-cells: > + Usage: required > + Value type: > + Definition: must be 0 > + > += ALS SUBNODE > +The ambient light sensor subnode must be named "als", it carries the light > +sensor related properties. > + > +- ti,als-resistance-ohm: > + Usage: required (unless ti,pwm-mode is specified) > + Value type: > + Definition: specifies the resistor value (R_als), in Ohm. Valid values > + ranges from 20 to 1574 Ohm. > + > +- ti,pwm-mode: > + Usage: optional > + Value type: > + Definition: specifies, if present, that the als should operate in PWM > + mode - rather than analog mode > + > += BACKLIGHT NODES > +Backlight subnodes must be named "backlight", they carry the backlight > related > +properties. > + > +- reg: > + Usage: required > + Value type: > + Definition: specifies which of the two backlights this node corresponds > + to > + > +- default-brightness: > + Usage: optional > + Value type: <32> > + Definition: specifies the default brightness for the backlight, in > + units of brightness [0-255] > + > +- label: > + Usage: required > + Value type: > + Definition: specifies a name of this backlight > + > +- led-max-microamp: > + Usage: required > + Value type: > + Definition: specifies the max current for this backlight, in uA, as > + described in "../leds/common.txt" > + > +- ti,pwm-zones: > + Usage: optional > + Value type: > + Definition: lists the ALS zones to be PWM controlled for this backlight, > + the values in the list are in the range [0 - 4] > + > += LED NODES > +LED subnodes must be named "led", they carry the LED related properties. > + > +- reg: > + Usage: required > + Value type: > + Definition: specifies which of the four LEDs this node corresponds to > + > +- linux,default-trigger: > + Usage: optional > + Value type: > + Definition: specifies the default trigger for the LED, as described in > + "../leds/common.txt" > + > +- label: > + Usage: required > + Value type: > + Definition: specifies a name of this LED, as described in > + "../leds/common.txt" > + > +- led-max-microamp: > + Usage: required > + Value type: > + Definition: specifies the max current for this LED, in uA, as described > + in "../leds/common.txt" > + > +- ti,pwm-zones: > + Usage: optional > + Value type: > + Definition: lists the ALS zones to be PWM controlled for this LED, the > +
Re: [PATCH v2 05/13] Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM bridge driver
On Sat, Oct 31, 2015 at 08:56:01PM +0800, Chris Zhong wrote:
> From: Liu Ying
>
> This patch adds device tree bindings for Synopsys DesignWare MIPI DSI
> host controller DRM bridge driver.
>
> Signed-off-by: Liu Ying
> Signed-off-by: Chris Zhong
> ---
>
> Changes in v2: None
>
> .../devicetree/bindings/drm/bridge/dw_mipi_dsi.txt | 76
> ++
Move to bindings/display/bridge/
> 1 file changed, 76 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
>
> diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
> b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
> new file mode 100644
> index 000..bb87466
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
> @@ -0,0 +1,76 @@
> +Device-Tree bindings for Synopsys DesignWare MIPI DSI host controller
> +
> +The controller is a digital core that implements all protocol functions
> +defined in the MIPI DSI specification, providing an interface between
> +the system and the MIPI DPHY, and allowing communication with a MIPI DSI
> +compliant display.
> +
> +Required properties:
> + - #address-cells: Should be <1>.
> + - #size-cells: Should be <0>.
> + - compatible: The first compatible string should be "fsl,imx6q-mipi-dsi"
> + for i.MX6q/sdl SoCs. For other SoCs, please refer to their specific
> + device tree binding documentations. A common compatible string
> + "snps,dw-mipi-dsi" should be appended for all SoCs.
> + - reg: Represent the physical address range of the controller.
> + - interrupts: Represent the controller's interrupt to the CPU(s).
> + - clocks, clock-names: Phandles to the controller's pll reference
> + clock(ref), configuration clock(cfg) and APB clock(pclk), as
> + described in [1].
> +
> +For more required properties, please refer to relevant device tree binding
> +documentations which describe the controller embedded in specific SoCs.
> +
> +Required sub-nodes:
> + - A node to represent a DSI peripheral as described in [2].
> +
> +For more required sub-nodes, please refer to relevant device tree binding
> +documentations which describe the controller embedded in specific SoCs.
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +[2] Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
This is now in bindings/display/mipi-dsi-bus.txt
> +
> +example:
> + gpr: iomuxc-gpr@020e {
> + /* ... */
> + };
> +
> + mipi_dsi: mipi@021e {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,imx6q-mipi-dsi", "snps,dw-mipi-dsi";
> + reg = <0x021e 0x4000>;
> + interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
> + gpr = <&gpr>;
> + clocks = <&clks IMX6QDL_CLK_MIPI_CORE_CFG>,
> + <&clks IMX6QDL_CLK_MIPI_CORE_CFG>,
> + <&clks IMX6QDL_CLK_MIPI_IPG>;
> + clock-names = "ref", "cfg", "pclk";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + mipi_mux_0: endpoint {
> + remote-endpoint = <&ipu1_di0_mipi>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + mipi_mux_1: endpoint {
> + remote-endpoint = <&ipu1_di1_mipi>;
> + };
> + };
> + };
> +
> + panel {
> + compatible = "truly,tft480800-16-e-dsi";
> + reg = <0>;
> + /* ... */
> + };
> + };
> --
> 2.6.2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 08/13] Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver
On Sat, Oct 31, 2015 at 08:56:04PM +0800, Chris Zhong wrote:
> add device tree bindings for rk3288 specific Synopsys DW MIPI DSI driver
>
> Signed-off-by: Chris Zhong
> ---
>
> Changes in v2: None
>
> .../bindings/video/dw_mipi_dsi_rockchip.txt| 56
> ++
> 1 file changed, 56 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/video/dw_mipi_dsi_rockchip.txt
>
> diff --git a/Documentation/devicetree/bindings/video/dw_mipi_dsi_rockchip.txt
> b/Documentation/devicetree/bindings/video/dw_mipi_dsi_rockchip.txt
> new file mode 100644
> index 000..4dea804
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/dw_mipi_dsi_rockchip.txt
Please move to bindings/display/rockchip/
> @@ -0,0 +1,56 @@
> +Rockchip specific extensions to the Synopsys Designware MIPI DSI
> +
> +
> +Required properties:
> +- compatible: "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi".
> +- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
> +- ports: contain a port node with endpoint definitions as defined in [1].
> + For vopb,set the reg = <0> and set the reg = <1> for vopl.
> +
> +For more required properties, please refer to [2].
> +
> +[1] Documentation/devicetree/bindings/media/video-interfaces.txt
> +[2] Documentation/devicetree/bindings/drm/bridge/dw_mipi_dsi.txt
This needs to be updated too.
> +
> +Example:
> + mipi_dsi: mipi@ff96 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi";
> + reg = <0xff96 0x4000>;
> + interrupts = ;
> + clocks = <&cru SCLK_MIPI_24M>, <&cru PCLK_MIPI_DSI0>;
> + clock-names = "ref", "pclk";
> + rockchip,grf = <&grf>;
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + mipi_in: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + mipi_in_vopb: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&vopb_out_mipi>;
> + };
> + mipi_in_vopl: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&vopl_out_mipi>;
> + };
> + };
> + };
> +
> + panel {
> + compatible ="boe,tv080wum-nl0";
> + reg = <0>;
> +
> + enable-gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_en>;
> + backlight = <&backlight>;
> + status = "okay";
> + };
> + };
> --
> 2.6.2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 1/2] Documentation: bridge: Add documentation for ps8640 DT properties
On Mon, Nov 02, 2015 at 10:09:25AM +0800, Jitao Shi wrote:
> Add documentation for DT properties supported by
> ps8640 DSI-eDP converter.
>
> Signed-off-by: Jitao Shi
Acked-by: Rob Herring
> ---
> .../devicetree/bindings/display/bridge/ps8640.txt | 43
>
> 1 file changed, 43 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/ps8640.txt
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.txt
> b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
> new file mode 100644
> index 000..7edc547
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
> @@ -0,0 +1,43 @@
> +ps8640-bridge bindings
> +
> +Required properties:
> + - compatible: "parade,ps8640"
> + - reg: first page address of the bridge.
> + - sleep-gpios: OF device-tree gpio specification for PD_ pin.
> + - reset-gpios: OF device-tree gpio specification for reset pin.
> + - mode-sel-gpios: OF device-tree gpio specification for mode-sel pin.
> + - vdd12-supply: OF device-tree regulator specification for 1.2V power.
> + - vdd33-supply: OF device-tree regulator specification for 3.3V power.
> + - ports: The device node can contain video interface port nodes per
> + the video-interfaces bind[1]. For port@0,set the reg = <0> as
> + ps8640 dsi in and port@1,set the reg = <1> as ps8640 eDP out.
> +
> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> + edp-bridge@18 {
> + compatible = "parade,ps8640";
> + reg = <0x18>;
> + sleep-gpios = <&pio 116 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&pio 115 GPIO_ACTIVE_HIGH>;
> + mode-sel-gpios = <&pio 92 GPIO_ACTIVE_HIGH>;
> + ps8640-1v2-supply = <&ps8640_fixed_1v2>;
> + ps8640-3v3-supply = <&mt6397_vgp2_reg>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + ps8640_in: endpoint {
> + remote-endpoint = <&dsi0_out>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + ps8640_out: endpoint {
> + remote-endpoint = <&panel_in>;
> + };
> + };
> + };
> + };
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] ARM: dts: rockchip: Add Crypto drivers for rk3288
the subject should be add the node/info for crypto...
在 2015年11月06日 09:17, Zain Wang 写道:
Add Crypto drivers for rk3288 including crypto controller and dma clk.
Signed-off-by: Zain Wang
---
Changed in v2:
- None
Changed in v1:
- remove the _crypto suffix
- use "rockchip,rk3288-crypto" instead of "rockchip,rk3288"
arch/arm/boot/dts/rk3288.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 6a79c9c..7b7914e 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -170,6 +170,21 @@
};
};
+ crypto: cypto-controller@ff8a {
+ compatible = "rockchip,rk3288-crypto";
+ reg = <0xff8a 0x4000>;
+ interrupts = ;
+ clocks = <&cru ACLK_CRYPTO>,
+<&cru HCLK_CRYPTO>,
+<&cru SCLK_CRYPTO>,
+<&cru ACLK_DMAC1>;
+ clock-names = "aclk",
+ "hclk",
+ "sclk",
+ "apb_pclk";
I guess you can do this:
clocks = <&cru ACLK_CRYPTO>, <&cru HCLK_CRYPTO>, <&cru SCLK_CRYPTO>, <&cru
ACLK_DMAC1>;
clock-names = "aclk", "hclk", "sclk", "apb_pclk";
+ status = "okay";
+ };
+
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
--
Thanks,
Caesar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 01/16] Documentation: dt-bindings: mfd: add TI LMU device binding information
On Mon, Nov 02, 2015 at 02:24:20PM +0900, Milo Kim wrote:
> This patch describes overall binding for TI LMU MFD devices.
>
> Cc: devicetree@vger.kernel.org
> Cc: Lee Jones
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Milo Kim
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/mfd/ti-lmu.txt | 282
> +++
> 1 file changed, 282 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/ti-lmu.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/ti-lmu.txt
> b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
> new file mode 100644
> index 000..7ccf07e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt
> @@ -0,0 +1,282 @@
> +TI LMU(Lighting Management Unit) device tree bindings
> +
> +TI LMU driver supports lighting devices belows.
> +
> + Name Child nodes
> + -- -
> + LM3532 Backlight
> + LM3631 Backlight and regulator
> + LM3632 Backlight and regulator
> + LM3633 Backlight, LED and HWMON
> + LM3695 Backlight
> + LM3697 Backlight and HWMON
> +
> +Required properties:
> + - compatible: Should be one of lists below.
> +"ti,lm3532"
> +"ti,lm3631"
> +"ti,lm3632"
> +"ti,lm3633"
> +"ti,lm3695"
> +"ti,lm3697"
> + - reg: I2C slave address.
> + 0x11 is LM3632
> + 0x29 is LM3631
> + 0x36 is LM3633, LM3697
> + 0x38 is LM3532
> + 0x63 is LM3695
> +
> +Optional properties:
> + - enable-gpios: A GPIO specifier for hardware enable pin.
> +
> +Required node:
> + - backlight: All LMU devices have backlight child nodes.
> + For the properties, please refer to [1].
> +
> +Optional nodes:
> + - hwmon: Hardware fault monitoring driver for LM3633 and LM3697.
> + For the property, please refer to [2].
> + - leds: LED properties for LM3633. Please refer to [3].
> + - regulators: Regulator properties for LM3631 and LM3632.
> + Please refer to [4].
> +
> +[1] Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt
> +[2] Documentation/devicetree/bindings/hwm/ti-lmu-hwmon.txt
> +[3] Documentation/devicetree/bindings/leds/leds-lm3633.txt
> +[4] Documentation/devicetree/bindings/regulator/lm363x-regulator.txt
> +
> +Examples:
> +
> +LM3532 has a backlight device. External GPIO is used for enabling LM3532.
> +
> +lm3532@38 {
> + compatible = "ti,lm3532";
> + reg = <0x38>;
> +
> + enable-gpios = <&pioC 2 GPIO_ACTIVE_HIGH>;
> +
> + backlight {
> + compatible = "ti,lm3532-backlight";
> +
> + lcd {
> + hvled1-used;
> + hvled2-used;
> + hvled3-used;
> +
> + ramp-up-msec = <30>;
> + ramp-down-msec = <0>;
> +
> + backlight-max-microamp = <5000>;
> + };
> + };
> +};
> +
> +LM3631 has 5 regulators with one backlight device.
> +
> +lm3631@29 {
> + compatible = "ti,lm3631";
> + reg = <0x29>;
> +
> + regulators {
> + compatible = "ti,lm363x-regulator";
> +
> + vboost {
> + regulator-name = "lcd_boost";
> + regulator-min-microvolt = <450>;
> + regulator-max-microvolt = <635>;
> + regulator-always-on;
> + };
> +
> + vcont {
> + regulator-name = "lcd_vcont";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> + };
> +
> + voref {
> + regulator-name = "lcd_voref";
> + regulator-min-microvolt = <400>;
> + regulator-max-microvolt = <600>;
> + };
> +
> + vpos {
> + regulator-name = "lcd_vpos";
> + regulator-min-microvolt = <400>;
> + regulator-max-microvolt = <600>;
> + regulator-boot-on;
> + };
> +
> + vneg {
> + regulator-name = "lcd_vneg";
> + regulator-min-microvolt = <400>;
> + regulator-max-microvolt = <600>;
> + regulator-boot-on;
> + };
> + };
> +
> + backlight {
> + compatible = "ti,lm3631-backlight";
> +
> + lcd {
> + backlight-name = "lcd_bl";
> + hvled1-used;
> + hvled2-used;
> +
> + ramp-up-msec = <300>;
> + };
> + };
> +};
> +
> +LM3632 has 3 regulators with one backlight device. External GPIO is
> +used for enabling LM3632.
> +
> +lm3632@11 {
> + compatible = "ti,lm3632";
> + reg = <0x11>;
> +
> + enable-
Re: [PATCH RESEND 03/16] Documentation: dt-bindings: hwmon: add TI LMU HWMON binding information
On Mon, Nov 02, 2015 at 02:24:22PM +0900, Milo Kim wrote: > Hardware fault monitoring driver is used in LM3633 and LM3697 device. > Just 'compatible' property is required to describe the driver. > > Cc: devicetree@vger.kernel.org > Cc: Guenter Roeck > Cc: Jean Delvare > Cc: Lee Jones > Cc: lm-sens...@lm-sensors.org > Cc: linux-ker...@vger.kernel.org > Signed-off-by: Milo Kim Acked-by: Rob Herring > --- > Documentation/devicetree/bindings/hwmon/ti-lmu-hwmon.txt | 12 > 1 file changed, 12 insertions(+) > create mode 100644 Documentation/devicetree/bindings/hwmon/ti-lmu-hwmon.txt > > diff --git a/Documentation/devicetree/bindings/hwmon/ti-lmu-hwmon.txt > b/Documentation/devicetree/bindings/hwmon/ti-lmu-hwmon.txt > new file mode 100644 > index 000..99cb241 > --- /dev/null > +++ b/Documentation/devicetree/bindings/hwmon/ti-lmu-hwmon.txt > @@ -0,0 +1,12 @@ > +TI LMU Hardware Monotoring device tree bindings > + > +LMU HWON driver monitors hardware fault situation of LMU devices, > +LM3633 and LM3697. > + > +Required properties: > + - compatible: Should be one of lists below. > +"ti,lm3633-hwmon" > +"ti,lm3697-hwmon" > + > +Examples: Please refer to ti-lmu dt-bindings. > + Documentation/devicetree/bindings/mfd/ti-lmu.txt > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/5] PM / OPP: Add {opp-microvolt|opp-microamp|turbo-mode|opp-suspend}- binding
On 05-11-15, 17:33, Rob Herring wrote: > On Wed, Nov 4, 2015 at 9:19 PM, Viresh Kumar wrote: > > On 04-11-15, 21:02, Rob Herring wrote: > >> > +- turbo-mode-: Named turbo-mode property. Similar to > >> > opp-microvolt- > >> > + property, but for turbo mode instead. > >> > + > >> > - opp-suspend: Marks the OPP to be used during device suspend. Only one > >> > OPP in > >> >the table should have this. > >> > > >> > +- opp-suspend-: Named opp-suspend property. Similar to > >> > + opp-microvolt- property, but for suspend opp instead. > >> > + > >> > >> I don't think these last 2 make sense. turbo-mode is a flag that the > >> mode has restrictions such as other cores have to be idle or something. > >> Similarly, opp-suspend should not vary by . > > > > Based on what version of the hardware you are running, via > > opp-supported-hw property, the platform can enable a different set of > > OPPs. And in that case we may want to select different OPPs marked as > > turbo or suspend freq. That's what I thought at least. > > > > For example, on version A of the hardware we have following available > > frequencies: 800, 1000, 1100, 1200 MHz. Where 800 MHz is the suspend > > freq and 1200 is the turbo one. > > > > But on a slightly different version of hardware B, we have two more > > OPPs available: 700 and 1400 MHz. And in that case we want the suspend > > freq to be 700 and turbo OPP to be only 1400 MHz. > > But different frequencies are different OPP nodes (since that is the > unit address now), so it is not going to hurt to set turbo-mode on > both 1200 and 1400. Yeah, but in that case 1200 *may* not be a turbo frequency anymore, as the voltage constraints might have changed. So turbo frequency is something that should be used only in small bursts, as they are consume lot of power. They aren't available to be used freely. They may also have thermal side effects.. In a similar way, for suspend-freq, we may or may not want the lowest frequency to be used during suspend and so that can change as well. And we shouldn't have suspend-freq set for two OPP nodes. -- viresh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288
I guess the subject:
"crypto: rockchip: "
Maybe better.
在 2015年11月06日 09:17, Zain Wang 写道:
The names registered are:
ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
You can alloc tags above in your case.
And other algorithms and platforms will be added later on.
Signed-off-by: Zain Wang
---
Changed in v2:
- remove some part about hash
- add weak key detection
- changed some variate's type
Changde in v1:
- modify some variate's name
- modify some variate's type
- modify some return value
- remove or modify some print info
- use more dev_xxx in probe
- modify the prio of cipher
[...]
+static int rk_crypto_remove(struct platform_device *pdev)
+{
+ struct crypto_info_t *crypto_tmp = platform_get_drvdata(pdev);
+
+ rk_crypto_unregister();
+ tasklet_kill(&crypto_tmp->crypto_tasklet);
+ free_irq(crypto_tmp->irq, crypto_tmp);
+ crypto_p = NULL;
+
+ return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id crypto_of_id_table[] = {
+ { .compatible = "rockchip,rk3288-crypto" },
+ {}
+};
+#endif /* CONFIG_OF */
I see the rk3368/ rk32xx SoCs the crypto seem the same IP.
So,
I guess we should put the "of_device_id" before the device probe since
we should can compatible for more SoCs.
Others, for example the commit need a bit change.
+
+static struct platform_driver crypto_driver = {
+ .probe = rk_crypto_probe,
+ .remove = rk_crypto_remove,
+ .driver = {
+ .name = "rockchip,rk3288-crypto",
+ .of_match_table = of_match_ptr(crypto_of_id_table),
+ },
+};
+
+module_platform_driver(crypto_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Zain Wang");
diff --git a/drivers/crypto/rockchip/rk3288_crypto.h
b/drivers/crypto/rockchip/rk3288_crypto.h
new file mode 100644
index 000..cf4cd18
--- /dev/null
+++ b/drivers/crypto/rockchip/rk3288_crypto.h
@@ -0,0 +1,222 @@
+#ifndef __RK3288_CRYPTO_H__
+#define __RK3288_CRYPTO_H__
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define _SBF(v, f) ((v) << (f))
+
+/* Crypto control registers*/
+#define RK_CRYPTO_INTSTS 0x
+#define RK_CRYPTO_PKA_DONE_INT BIT(5)
+#define RK_CRYPTO_HASH_DONE_INTBIT(4)
+#define RK_CRYPTO_HRDMA_ERR_INTBIT(3)
+#define RK_CRYPTO_HRDMA_DONE_INT BIT(2)
+#define RK_CRYPTO_BCDMA_ERR_INTBIT(1)
+#define RK_CRYPTO_BCDMA_DONE_INT BIT(0)
+
+#define RK_CRYPTO_INTENA 0x0004
+#define RK_CRYPTO_PKA_DONE_ENA BIT(5)
+#define RK_CRYPTO_HASH_DONE_ENABIT(4)
+#define RK_CRYPTO_HRDMA_ERR_ENABIT(3)
+#define RK_CRYPTO_HRDMA_DONE_ENA BIT(2)
+#define RK_CRYPTO_BCDMA_ERR_ENABIT(1)
+#define RK_CRYPTO_BCDMA_DONE_ENA BIT(0)
+
+#define RK_CRYPTO_CTRL 0x0008
+#define RK_CRYPTO_WRITE_MASK (0x << 16)
+#define RK_CRYPTO_TRNG_FLUSH BIT(9)
+#define RK_CRYPTO_TRNG_START BIT(8)
+#define RK_CRYPTO_PKA_FLUSHBIT(7)
+#define RK_CRYPTO_HASH_FLUSH BIT(6)
+#define RK_CRYPTO_BLOCK_FLUSH BIT(5)
+#define RK_CRYPTO_PKA_STARTBIT(4)
+#define RK_CRYPTO_HASH_START BIT(3)
+#define RK_CRYPTO_BLOCK_START BIT(2)
+#define RK_CRYPTO_TDES_START BIT(1)
+#define RK_CRYPTO_AES_STARTBIT(0)
+
+#define RK_CRYPTO_CONF 0x000c
+/* HASH Receive DMA Address Mode: fix | increment */
+#define RK_CRYPTO_HR_ADDR_MODE BIT(8)
+/* Block Transmit DMA Address Mode: fix | increment */
+#define RK_CRYPTO_BT_ADDR_MODE BIT(7)
+/* Block Receive DMA Address Mode: fix | increment */
+#define RK_CRYPTO_BR_ADDR_MODE BIT(6)
+#define RK_CRYPTO_BYTESWAP_HRFIFO BIT(5)
+#define RK_CRYPTO_BYTESWAP_BTFIFO BIT(4)
+#define RK_CRYPTO_BYTESWAP_BRFIFO BIT(3)
+/* AES = 0 OR DES = 1 */
+#define RK_CRYPTO_DESSEL BIT(2)
+#define RK_CYYPTO_HASHINSEL_INDEPENDENT_SOURCE _SBF(0x00, 0)
+#define RK_CYYPTO_HASHINSEL_BLOCK_CIPHER_INPUT _SBF(0x01, 0)
+#define RK_CYYPTO_HASHINSEL_BLOCK_CIPHER_OUTPUT_SBF(0x02, 0)
+
+/* Block Receiving DMA Start Address Register */
+#define RK_CRYPTO_BRDMAS 0x0010
+/* Block Transmitting DMA Start Address Register */
+#define RK_CRYPTO_BTDMAS 0x0014
+/* Block Receiving DMA Length Register */
+#define RK_CRYPTO_BRDMAL 0x0018
+/* Hash Receiving DMA Start Address Register */
+#define RK_CRYPTO_HRDMAS 0x001c
+/* Hash Receiving DMA Length Register */
+#define RK_CRYPTO_HRDMAL 0x0020
+
+/* AES registers */
+#define RK_CRYPTO_AES_CTRL 0x0080
+#define RK_CRYPTO_AES_BYTESWAP_CNT BIT(11)
+#define RK_CRYPTO_AES_BYTESWAP_KEY BIT(10)
+#define RK_CRYPTO_AES_BYTESWAP_IV BIT(9)
+#define RK_CRYPTO_AES_BYTESWAP
Re: [PATCH V2 0/5] PM / OPP: opp-supported-hw and -name bindings
On 05-11-15, 23:31, Rafael J. Wysocki wrote: > So this clearly is a new feature and it clearly missed the merge window > boundary > for v4.4. I can queue it up for v4.5. No issues as the relevant code is also going to get merged in 4.5 :) -- viresh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/4] Crypto: add crypto accelerator support for rk3288
Hi 在 2015年11月06日 09:17, Zain Wang 写道: This commit support three cipher(AES/DES/DES3) and two chainmode(ecb/cbc), and the more algorithms and new hash drivers will be added later on. Changed in v2: - remove some part about hash - add weak key detection - changed some variate's type Changed in v1: - modify some variate's name - modify some variate's type - modify some return value - remove or modify some print info - use more dev_xxx in probe - modify the prio of cipher - add Kconfig Zain Wang (4): Crypto: Crypto driver support aes/des/des3 for rk3288 clk: rockchip: set an id for crypto clk ARM: dts: rockchip: Add Crypto drivers for rk3288 crypto: rockchip/crypto - add DT bindings documentation I guess the series patchs order should be: pacth 1/4 dt-binds/ patch 2/4 clk id patch 3/4 crypto driver patch 4/4 dts .../devicetree/bindings/crypto/rockchip-crypto.txt | 29 ++ arch/arm/boot/dts/rk3288.dtsi | 15 + drivers/clk/rockchip/clk-rk3288.c | 2 +- drivers/crypto/Kconfig | 11 + drivers/crypto/Makefile| 1 + drivers/crypto/rockchip/Makefile | 3 + drivers/crypto/rockchip/rk3288_crypto.c| 380 +++ drivers/crypto/rockchip/rk3288_crypto.h| 222 + drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 511 + include/dt-bindings/clock/rk3288-cru.h | 1 + 10 files changed, 1174 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/crypto/rockchip-crypto.txt create mode 100644 drivers/crypto/rockchip/Makefile create mode 100644 drivers/crypto/rockchip/rk3288_crypto.c create mode 100644 drivers/crypto/rockchip/rk3288_crypto.h create mode 100644 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c -- Thanks, Caesar -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] clk: rockchip: set an id for crypto clk
set an id for crypto clk, so that it can be called in other part.
Signed-off-by: Zain Wang
---
Changed in v2:
- None
Changed in v1:
- define SCLK_CRYPTO in rk3288-cru.h
- use SCLK_CRYPTO instead of SRST_CRYPTO
drivers/clk/rockchip/clk-rk3288.c | 2 +-
include/dt-bindings/clock/rk3288-cru.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 9040878..3fceda1 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -295,7 +295,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
RK3288_CLKGATE_CON(0), 4, GFLAGS),
GATE(0, "c2c_host", "aclk_cpu_src", 0,
RK3288_CLKGATE_CON(13), 8, GFLAGS),
- COMPOSITE_NOMUX(0, "crypto", "aclk_cpu_pre", 0,
+ COMPOSITE_NOMUX(SCLK_CRYPTO, "crypto", "aclk_cpu_pre", 0,
RK3288_CLKSEL_CON(26), 6, 2, DFLAGS,
RK3288_CLKGATE_CON(5), 4, GFLAGS),
GATE(0, "aclk_bus_2pmu", "aclk_cpu_pre", CLK_IGNORE_UNUSED,
diff --git a/include/dt-bindings/clock/rk3288-cru.h
b/include/dt-bindings/clock/rk3288-cru.h
index c719aac..30dcd60 100644
--- a/include/dt-bindings/clock/rk3288-cru.h
+++ b/include/dt-bindings/clock/rk3288-cru.h
@@ -86,6 +86,7 @@
#define SCLK_USBPHY480M_SRC122
#define SCLK_PVTM_CORE 123
#define SCLK_PVTM_GPU 124
+#define SCLK_CRYPTO125
#define SCLK_MAC 151
#define SCLK_MACREF_OUT152
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] ARM: dts: rockchip: Add Crypto drivers for rk3288
Add Crypto drivers for rk3288 including crypto controller and dma clk.
Signed-off-by: Zain Wang
---
Changed in v2:
- None
Changed in v1:
- remove the _crypto suffix
- use "rockchip,rk3288-crypto" instead of "rockchip,rk3288"
arch/arm/boot/dts/rk3288.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 6a79c9c..7b7914e 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -170,6 +170,21 @@
};
};
+ crypto: cypto-controller@ff8a {
+ compatible = "rockchip,rk3288-crypto";
+ reg = <0xff8a 0x4000>;
+ interrupts = ;
+ clocks = <&cru ACLK_CRYPTO>,
+<&cru HCLK_CRYPTO>,
+<&cru SCLK_CRYPTO>,
+<&cru ACLK_DMAC1>;
+ clock-names = "aclk",
+ "hclk",
+ "sclk",
+ "apb_pclk";
+ status = "okay";
+ };
+
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288
The names registered are:
ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
You can alloc tags above in your case.
And other algorithms and platforms will be added later on.
Signed-off-by: Zain Wang
---
Changed in v2:
- remove some part about hash
- add weak key detection
- changed some variate's type
Changde in v1:
- modify some variate's name
- modify some variate's type
- modify some return value
- remove or modify some print info
- use more dev_xxx in probe
- modify the prio of cipher
drivers/crypto/Kconfig | 11 +
drivers/crypto/Makefile| 1 +
drivers/crypto/rockchip/Makefile | 3 +
drivers/crypto/rockchip/rk3288_crypto.c| 380 +++
drivers/crypto/rockchip/rk3288_crypto.h| 222 +
drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 511 +
6 files changed, 1128 insertions(+)
create mode 100644 drivers/crypto/rockchip/Makefile
create mode 100644 drivers/crypto/rockchip/rk3288_crypto.c
create mode 100644 drivers/crypto/rockchip/rk3288_crypto.h
create mode 100644 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 2569e04..d1e42cf 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -498,4 +498,15 @@ config CRYPTO_DEV_SUN4I_SS
To compile this driver as a module, choose M here: the module
will be called sun4i-ss.
+config CRYPTO_DEV_ROCKCHIP
+ tristate "Rockchip's Cryptographic Engine driver"
+
+ select CRYPTO_AES
+ select CRYPTO_DES
+ select CRYPTO_BLKCIPHER
+
+ help
+ This driver interfaces with the hardware crypto accelerator.
+ Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
+
endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index c3ced6f..713de9d 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
+obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rockchip/
diff --git a/drivers/crypto/rockchip/Makefile b/drivers/crypto/rockchip/Makefile
new file mode 100644
index 000..7051c6c
--- /dev/null
+++ b/drivers/crypto/rockchip/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rk_crypto.o
+rk_crypto-objs := rk3288_crypto.o \
+ rk3288_crypto_ablkcipher.o \
diff --git a/drivers/crypto/rockchip/rk3288_crypto.c
b/drivers/crypto/rockchip/rk3288_crypto.c
new file mode 100644
index 000..c2a419b
--- /dev/null
+++ b/drivers/crypto/rockchip/rk3288_crypto.c
@@ -0,0 +1,380 @@
+/*
+ *Crypto acceleration support for Rockchip RK3288
+ *
+ * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Zain Wang
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * Some ideas are from marvell-cesa.c and s5p-sss.c driver.
+ */
+
+#include "rk3288_crypto.h"
+#include
+#include
+#include
+#include
+#include
+
+struct crypto_info_t *crypto_p;
+
+static int rk_crypto_enable_clk(struct crypto_info_t *dev)
+{
+ int err;
+
+ err = clk_prepare_enable(dev->sclk);
+ if (err) {
+ dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'sclk'\n",
+ __func__, __LINE__);
+ goto err_return;
+ }
+ err = clk_prepare_enable(dev->aclk);
+ if (err) {
+ dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'aclk'\n",
+ __func__, __LINE__);
+ goto err_aclk;
+ }
+ err = clk_prepare_enable(dev->hclk);
+ if (err) {
+ dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'hclk'\n",
+ __func__, __LINE__);
+ goto err_hclk;
+ }
+
+ err = clk_prepare_enable(dev->dmaclk);
+ if (err) {
+ dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'dmaclk'\n",
+ __func__, __LINE__);
+ goto err_dmaclk;
+ }
+ return err;
+err_dmaclk:
+ clk_disable_unprepare(dev->hclk);
+err_hclk:
+ clk_disable_unprepare(dev->aclk);
+err_aclk:
+ clk_disable_unprepare(dev->sclk);
+err_return:
+ return err;
+}
+
+static void rk_crypto_disable_clk(struct crypto_info_t *dev)
+{
+ clk_disable_unprepare(dev->dmaclk);
+ clk_disable_unprepare(dev->hclk);
+ clk_disable_unprepare(dev->aclk);
+ clk_disable_unprepare(dev->sclk);
+}
+
+static int check_alignment(struct scatterlist *sg_src,
+ struct scatterlist *sg_dst,
+ int align_mask)
+{
+ int in, out, align;
+
+ in = IS_
[PATCH v2 4/4] crypto: rockchip/crypto - add DT bindings documentation
Add DT bindings documentation for the rk3288 crypto drivers.
Signed-off-by: Zain Wang
---
Changde in v2:
- None
Changed in v1:
- remove the _crypto suffix
- use "rockchip,rk3288-crypto" instead of "rockchip,rk3288"
- remove the description of status
.../devicetree/bindings/crypto/rockchip-crypto.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
diff --git a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
new file mode 100644
index 000..d27e203
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
@@ -0,0 +1,29 @@
+Rockchip Electronics And Security Accelerator
+
+Required properties:
+- compatible: Should be "rockchip,rk3288-crypto"
+- reg: base physical address of the engine and length of memory mapped
+ region
+- interrupts: interrupt number
+- clocks: reference to the clocks about crypto
+- clock-names: "aclk" used to clock data
+ "hclk" used to clock data
+ "srst" used to clock crypto accelerator
+ "apb_pclk" used to clock dma
+
+Examples:
+
+ crypto: cypto-controller@ff8a {
+ compatible = "rockchip,rk3288-crypto";
+ reg = <0xff8a 0x4000>;
+ interrupts = ;
+ clocks = <&cru ACLK_CRYPTO>,
+<&cru HCLK_CRYPTO>,
+<&cru SCLK_CRYPTO>,
+<&cru ACLK_DMAC1>;
+ clock-names = "aclk",
+ "hclk",
+ "sclk",
+ "apb_pclk";
+ status = "okay";
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] Crypto: add crypto accelerator support for rk3288
This commit support three cipher(AES/DES/DES3) and two chainmode(ecb/cbc), and the more algorithms and new hash drivers will be added later on. Changed in v2: - remove some part about hash - add weak key detection - changed some variate's type Changed in v1: - modify some variate's name - modify some variate's type - modify some return value - remove or modify some print info - use more dev_xxx in probe - modify the prio of cipher - add Kconfig Zain Wang (4): Crypto: Crypto driver support aes/des/des3 for rk3288 clk: rockchip: set an id for crypto clk ARM: dts: rockchip: Add Crypto drivers for rk3288 crypto: rockchip/crypto - add DT bindings documentation .../devicetree/bindings/crypto/rockchip-crypto.txt | 29 ++ arch/arm/boot/dts/rk3288.dtsi | 15 + drivers/clk/rockchip/clk-rk3288.c | 2 +- drivers/crypto/Kconfig | 11 + drivers/crypto/Makefile| 1 + drivers/crypto/rockchip/Makefile | 3 + drivers/crypto/rockchip/rk3288_crypto.c| 380 +++ drivers/crypto/rockchip/rk3288_crypto.h| 222 + drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 511 + include/dt-bindings/clock/rk3288-cru.h | 1 + 10 files changed, 1174 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/crypto/rockchip-crypto.txt create mode 100644 drivers/crypto/rockchip/Makefile create mode 100644 drivers/crypto/rockchip/rk3288_crypto.c create mode 100644 drivers/crypto/rockchip/rk3288_crypto.h create mode 100644 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 04/50] powerpc/powernv: Cleanup on pnv_pci_ioda_controller_ops
On Fri, Nov 06, 2015 at 09:28:20AM +1100, Daniel Axtens wrote:
>Gavin Shan writes:
>
>> This cleans up on pnv_pci_ioda_controller_ops struct to use tab
>> instead of space indent of statement to avoid complains from
>> scripts/checkpatch.pl. No logical changes introduced.
>
>Oh, that was my code :/ Sorry I missed that, thanks for cleaning it up!
>
>Reviewed-by: Daniel Axtens
>
nah, that's fine, Daniel. You might be saying: I didn't review your code
carefully enough, which leaves me the chance to clean it up :-)
Thanks,
Gavin
>>
>> Signed-off-by: Gavin Shan
>> ---
>> arch/powerpc/platforms/powernv/pci-ioda.c | 18 +-
>> 1 file changed, 9 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
>> b/arch/powerpc/platforms/powernv/pci-ioda.c
>> index 2e2bedb..aa3645c 100644
>> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
>> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>> @@ -3064,17 +3064,17 @@ static void pnv_pci_ioda_shutdown(struct
>> pci_controller *hose)
>> }
>>
>> static const struct pci_controller_ops pnv_pci_ioda_controller_ops = {
>> - .dma_dev_setup = pnv_pci_dma_dev_setup,
>> +.dma_dev_setup = pnv_pci_dma_dev_setup,
>> #ifdef CONFIG_PCI_MSI
>> - .setup_msi_irqs = pnv_setup_msi_irqs,
>> - .teardown_msi_irqs = pnv_teardown_msi_irqs,
>> +.setup_msi_irqs = pnv_setup_msi_irqs,
>> +.teardown_msi_irqs = pnv_teardown_msi_irqs,
>> #endif
>> - .enable_device_hook = pnv_pci_enable_device_hook,
>> - .window_alignment = pnv_pci_window_alignment,
>> - .reset_secondary_bus = pnv_pci_reset_secondary_bus,
>> - .dma_set_mask = pnv_pci_ioda_dma_set_mask,
>> - .dma_get_required_mask = pnv_pci_ioda_dma_get_required_mask,
>> - .shutdown = pnv_pci_ioda_shutdown,
>> +.enable_device_hook = pnv_pci_enable_device_hook,
>> +.window_alignment = pnv_pci_window_alignment,
>> +.reset_secondary_bus= pnv_pci_reset_secondary_bus,
>> +.dma_set_mask = pnv_pci_ioda_dma_set_mask,
>> +.dma_get_required_mask = pnv_pci_ioda_dma_get_required_mask,
>> +.shutdown = pnv_pci_ioda_shutdown,
>> };
>>
>> static void __init pnv_pci_init_ioda_phb(struct device_node *np,
>> --
>> 2.1.0
>>
>> ___
>> Linuxppc-dev mailing list
>> linuxppc-...@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 4/4] ARM: dts: Add Ethernet chip to SMDK5410
On 05.11.2015 21:03, Pavel Fedin wrote: > The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO > initialization is required. > > Signed-off-by: Pavel Fedin > --- > arch/arm/boot/dts/exynos5410-smdk5410.dts | 41 > +++ > arch/arm/boot/dts/exynos5410.dtsi | 6 + > 2 files changed, 47 insertions(+) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/4] drivers: exynos-srom: Add support for bank configuration
On 05.11.2015 21:03, Pavel Fedin wrote: > Implement handling properties in subnodes and adding child devices to the > system. Child devices will not be added if configuration fails. > > Since the driver now does more than suspend-resume support, dependency on > CONFIG_PM is removed. > > Signed-off-by: Pavel Fedin > --- > arch/arm/mach-exynos/Kconfig | 2 +- > drivers/soc/samsung/Kconfig | 2 +- > drivers/soc/samsung/exynos-srom.c | 61 > +-- > 3 files changed, 61 insertions(+), 4 deletions(-) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/4] ARM: dts: Add SROMc to Exynos 5410
On 05.11.2015 21:03, Pavel Fedin wrote: > This machine uses own SoC device tree file, add missing part. > > Signed-off-by: Pavel Fedin > --- > arch/arm/boot/dts/exynos5410.dtsi | 5 + > 1 file changed, 5 insertions(+) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 1/4] Documentation: dt-bindings: Describe SROMc configuration
On 05.11.2015 21:03, Pavel Fedin wrote: > Add documentation for new subnode properties, allowing bank configuration. > Based on u-boot implementation, but heavily reworked. > > Also, fix size of SROMc mapping in the example. > > Signed-off-by: Pavel Fedin > --- > .../bindings/arm/samsung/exynos-srom.txt | 71 > +- > 1 file changed, 69 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt > b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt > index 33886d5..cce5c1f 100644 > --- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt > +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt > @@ -5,8 +5,75 @@ Required properties: > > - reg: offset and length of the register set > > -Example: > +Optional properties: > +The SROM controller can be used to attach external peripherals. In this case > +extra properties, describing the bus behind it, should be specified as below: > + > +- #address-cells: Must be set to 2 to allow memory address translation > + > +- #size-cells: Must be set to 1 to allow CS address passing > + > +- ranges: Must be set up to reflect the memory layout with four integer > values > + per bank: > + 0 > + > +Sub-nodes: > +The actual device nodes should be added as subnodes to the SROMc node. These > +subnodes, except regular device specification, should contain the following > +properties, describing configuration of the relevant SROM bank: > + > +Required properties: > +- reg: bank number, base address (relative to start of the bank) and size of > + the memory mapped for the device. Note that base address will be > + typically 0 as this is the start of the bank. > + > +- samsung,srom-timing : array of 6 integers, specifying bank timings in the > +following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs. > +Each value is specified in cycles and has the > following > +meaning and valid range: > +Tacp : Page mode access cycle at Page mode (0 - 15) > +Tcah : Address holding time after CSn (0 - 15) > +Tcoh : Chip selection hold on OEn (0 - 15) > +Tacc : Access cycle (0 - 32) All of the manuals have error here. Probably it can be either: 1-32 or 0-31. I would bet on 0-31, what do you think? Rest looks good: Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 10/50] powerpc/powernv: Simplify pnv_ioda_setup_pe_seg()
On Fri, Nov 06, 2015 at 09:56:06AM +1100, Daniel Axtens wrote:
>Gavin Shan writes:
>
>> The original implementation of pnv_ioda_setup_pe_seg() configures
>> IO and M32 segments by separate logics, which can be merged by
>> by caching @segmap, @seg_size, @win in advance. This shouldn't
>> cause any behavioural changes.
>>
>> Signed-off-by: Gavin Shan
>> ---
>> arch/powerpc/platforms/powernv/pci-ioda.c | 62
>> ++-
>> 1 file changed, 28 insertions(+), 34 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
>> b/arch/powerpc/platforms/powernv/pci-ioda.c
>> index 7ee7cfe..553d3f3 100644
>> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
>> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
>> @@ -2752,8 +2752,10 @@ static void pnv_ioda_setup_pe_seg(struct
>> pci_controller *hose,
>> struct pnv_phb *phb = hose->private_data;
>> struct pci_bus_region region;
>> struct resource *res;
>> -int i, index;
>> -int rc;
>> +unsigned int segsize;
>> +int *segmap, index, i;
>> +uint16_t win;
>> +int64_t rc;
>
>Good catch! Opal return codes are 64 bit and that should be explicit
>in the type. However, I seem to remember that we preferred a different
>type for 64 bit ints in the kernel. I think it's s64, and there are some
>other uses of that in pci_ioda.c for return codes.
>
Both int64_t and s64 are fine. I used s64 for the OPAL return value, but
Alexey likes "int64_t", which is ok to me as well. I won't change it back
to s64 :-)
>(I'm actually surprised that's not picked up as a compiler
>warning. Maybe that's something to look at in future.)
>
Indeed, I didn't see a warning from gcc.
>The rest of the patch looks good on casual inspection - to be sure I'll
>test the entire series on a machine. (hopefully, time permitting!)
>
I run scripts/checkpatch.pl on the patchset. Only one warning came from
[PATCH 44/50], but I won't bother to change that as the warning was
brought by original code. If you want to test this patchset, you need
run it on Tuleta where the hotpluggable PCI slots are supported.
Thanks,
Gavin
>>
>> /*
>> * NOTE: We only care PCI bus based PE for now. For PCI
>> @@ -2770,23 +2772,9 @@ static void pnv_ioda_setup_pe_seg(struct
>> pci_controller *hose,
>> if (res->flags & IORESOURCE_IO) {
>> region.start = res->start - phb->ioda.io_pci_base;
>> region.end = res->end - phb->ioda.io_pci_base;
>> -index = region.start / phb->ioda.io_segsize;
>> -
>> -while (index < phb->ioda.total_pe_num &&
>> - region.start <= region.end) {
>> -phb->ioda.io_segmap[index] = pe->pe_number;
>> -rc = opal_pci_map_pe_mmio_window(phb->opal_id,
>> -pe->pe_number, OPAL_IO_WINDOW_TYPE, 0,
>> index);
>> -if (rc != OPAL_SUCCESS) {
>> -pr_err("%s: OPAL error %d when mapping
>> IO "
>> - "segment #%d to PE#%d\n",
>> - __func__, rc, index,
>> pe->pe_number);
>> -break;
>> -}
>> -
>> -region.start += phb->ioda.io_segsize;
>> -index++;
>> -}
>> +segsize = phb->ioda.io_segsize;
>> +segmap = phb->ioda.io_segmap;
>> +win = OPAL_IO_WINDOW_TYPE;
>> } else if ((res->flags & IORESOURCE_MEM) &&
>> !pnv_pci_is_mem_pref_64(res->flags)) {
>> region.start = res->start -
>> @@ -2795,23 +2783,29 @@ static void pnv_ioda_setup_pe_seg(struct
>> pci_controller *hose,
>> region.end = res->end -
>> hose->mem_offset[0] -
>> phb->ioda.m32_pci_base;
>> -index = region.start / phb->ioda.m32_segsize;
>> -
>> -while (index < phb->ioda.total_pe_num &&
>> - region.start <= region.end) {
>> -phb->ioda.m32_segmap[index] = pe->pe_number;
>> -rc = opal_pci_map_pe_mmio_window(phb->opal_id,
>> -pe->pe_number, OPAL_M32_WINDOW_TYPE, 0,
>> index);
>> -if (rc != OPAL_SUCCESS) {
>> -pr_err("%s: OPAL error %d when mapping
>> M32 "
>> - "segment#%d to PE#%d",
>> - __func__, rc, index,
>> pe->pe_number);
>> -break;
>> -}
>> +segsize = phb->ioda.m32_segsize;
>>
Re: [PATCH v2 5/5] ARM: dts: AM4372: add entry for qspi mmap region
On Tue, Nov 03, 2015 at 03:36:14PM +0530, Vignesh R wrote:
> Add qspi memory mapped region entries for AM43xx based SoCs. Also,
> update the binding documents for the controller to document this change.
>
> Signed-off-by: Vignesh R
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/spi/ti_qspi.txt | 5 +++--
> arch/arm/boot/dts/am4372.dtsi | 4 +++-
> 2 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt
> b/Documentation/devicetree/bindings/spi/ti_qspi.txt
> index f05dd631bef1..05488970060b 100644
> --- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
> +++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
> @@ -17,9 +17,10 @@ Recommended properties:
>
> Example:
>
> +For am4372:
> qspi: qspi@4b30 {
> - compatible = "ti,dra7xxx-qspi";
> - reg = <0x4790 0x100>, <0x3000 0x3ff>;
> + compatible = "ti,am4372-qspi";
> + reg = <0x4790 0x100>, <0x3000 0x400>;
> reg-names = "qspi_base", "qspi_mmap";
> #address-cells = <1>;
> #size-cells = <0>;
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index 0447c04a40cc..1b2c545f3f2c 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -962,7 +962,9 @@
>
> qspi: qspi@4790 {
> compatible = "ti,am4372-qspi";
> - reg = <0x4790 0x100>;
> + reg = <0x4790 0x100>,
> + <0x3000 0x400>;
> + reg-names = "qspi_base", "qspi_mmap";
> #address-cells = <1>;
> #size-cells = <0>;
> ti,hwmods = "qspi";
> --
> 2.6.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/3] mtd: arasan: Add device tree binding documentation
On Thu, Nov 05, 2015 at 08:18:42AM +0530, Punnaiah Choudary Kalluri wrote: > This patch adds the dts binding document for arasan nand flash > controller. > > Signed-off-by: Punnaiah Choudary Kalluri > --- > Changes in v4: > - Added num-cs property > - Added clock support > Changes in v3: > - None > Changes in v2: > - None > --- > .../devicetree/bindings/mtd/arasan_nfc.txt | 34 > ++ > 1 file changed, 34 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nfc.txt > > diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > new file mode 100644 > index 000..02e1ce3 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt > @@ -0,0 +1,34 @@ > +Arasan Nand Flash Controller with ONFI 3.1 support > + > +Required properties: > +- compatible: Should be "arasan,nfc-v3p10" There should also be a chip specific property. Vendors are known to integrate IP blocks in different and interesting ways. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 03/50] powerpc/pci: Cleanup on struct pci_controller_ops
On Fri, Nov 06, 2015 at 09:32:57AM +1100, Daniel Axtens wrote: >Gavin Shan writes: > >> Each PHB has one instance of "struct pci_controller_ops", which >> includes various callbacks called by PCI subsystem. In the definition >> of this struct, some callbacks have explicit names for its arguments, >> but the left don't have. >> >> This adds all explicit names of the arguments to the callbacks in >> "struct pci_controller_ops" so that the code looks consistent. > >Thank you very much for doing this - I should have done it the first >time I created pci_controller_ops. > >They all look good, with one nit-pick: > >> -void(*shutdown)(struct pci_controller *); >> +void(*shutdown)(struct pci_controller *hose); > >I think we're trying to move from hose to phb in new code. > Nope, We don't have the movement as I explained in previous reply: hose for pci_controller while phb represents pnv_phb on PowerNV platform. >Once that is fixed: > Reviewed-by: Daniel Axtens > Thanks, Gavin > >> }; >> >> /* >> -- >> 2.1.0 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in >> the body of a message to majord...@vger.kernel.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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 1/3] Documentation: dt: Add devicetree bindings for NI USRP E3xx pinconf
Signed-off-by: Moritz Fischer
---
.../devicetree/bindings/pinctrl/pinctrl-e3xx.txt | 27 ++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-e3xx.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-e3xx.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-e3xx.txt
new file mode 100644
index 000..2bfbd21
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-e3xx.txt
@@ -0,0 +1,27 @@
+USRP E3xx Pincontrol bindings
+
+The pins of the NI Ettus Research USRP E3xx idle image can be configured for
different
+daughterboard configurations. This pinmux is implemented in an FPGA as soft
core.
+
+Required properties:
+- compatible: Must be one of the following:
+ - "ettus,pinctrl-e3xx-1.0"
+- clocks: The clock driving the pinmux
+
+Example:
+
+ e3xx_pinctrl: e3xx-pinctrl@40200a00 {
+ compatible = "ettus,e3xx-pinctrl-1.0";
+ reg = <0x40200a00 0x1000>;
+ clocks = <&clkc 15>;
+
+ foo_state: pinconf {
+ conf {
+ pins = E31X_LED_RX1_RX;
+ output-low;
+ };
+ };
+ };
+
+Note: Constants that facilitate creation of devicetree files are available in
+ include/dt-bindings/pinctrl/pinctrl-e3xx.h
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/9] dt-bindings: rockchip-thermal: Support the RK3368 SoCs compatible
On Thu, Nov 05, 2015 at 01:17:57PM +0800, Caesar Wang wrote: > This patchset attempts to new compatible for thermal founding > on RK3368 SoCs. > > Signed-off-by: Caesar Wang Acked-by: Rob Herring > --- > > Changes in v2: None > Changes in v1: > - %s/thermal/rockchip-thermal in subject. > > Documentation/devicetree/bindings/thermal/rockchip-thermal.txt | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt > b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt > index b38200d..0dfa60d 100644 > --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt > +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt > @@ -1,7 +1,9 @@ > * Temperature Sensor ADC (TSADC) on rockchip SoCs > > Required properties: > -- compatible : "rockchip,rk3288-tsadc" > +- compatible : should be "rockchip,-tsadc" > + "rockchip,rk3288-tsadc": found on RK3288 SoCs > + "rockchip,rk3368-tsadc": found on RK3368 SoCs > - reg : physical base address of the controller and length of memory mapped > region. > - interrupts : The interrupt number to the cpu. The interrupt specifier > format > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 0/3] Adding support for NI Ettus Research USRP E3XX pinconf
Hi all, I've been hacking on this pinctrl driver to control pins on our FPGA idle image to use different daughterboards using different pin configurations. I send this as an RFC because it's still pretty early stage, and while it seems to work fine I'm unsure about some of the semantics (as always, there will probably other changes required). I'm planning to use this pinctrl driver to set pins to either input (do nothing, default), or output with a value of (1 or 0). Can I use the 'output-low', 'output-high' bindings to achieve this, or am I supposed to implement a gpio controller to do this kind of stuff? I'm not sure if I'm using the pinctrl framework correctly to achieve this, any suggestions on how to change a pin from output to input, as the bindings documentation explicitly states 'input-enable' does *not* affect output. Thanks for your help & feedback, Moritz Moritz Fischer (3): Documentation: dt: Add devicetree bindings for NI USRP E3xx pinconf pinctrl: e3xx: Adding support for NI Ettus Research USRP E3xx pinconf ARM: e3xx: Add header file for pinctrl constants .../devicetree/bindings/pinctrl/pinctrl-e3xx.txt | 27 ++ drivers/pinctrl/Kconfig| 11 + drivers/pinctrl/Makefile | 1 + drivers/pinctrl/pinctrl-e3xx.c | 403 + include/dt-bindings/pinctrl/pinctrl-e3xx.h | 142 5 files changed, 584 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-e3xx.txt create mode 100644 drivers/pinctrl/pinctrl-e3xx.c create mode 100644 include/dt-bindings/pinctrl/pinctrl-e3xx.h -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 10/17] phy: Add driver for rockchip Display Port PHY
Hi,
A few updates:
On Tue, Nov 03, 2015 at 05:13:48PM -0800, Brian Norris wrote:
> On Wed, Nov 04, 2015 at 08:48:38AM +0800, Yakir Yang wrote:
> > On 11/03/2015 12:38 PM, Brian Norris wrote:
> > >On Thu, Oct 29, 2015 at 09:58:38AM +0800, Yakir Yang wrote:
> > >(FYI, I came across this by inspection when comparing Heiko's
> > >'somewhat-stable' branch [1] with this series. The former brings up eDP
> > >fine on veyron-jaq, whereas this one doesn't yet, even with the above
> > >change. Still debugging the issue.)
Some time after the above comment, I managed to kill the panel on my
Jaq :( I think the wiring around the hinge was a bit flaky, and it
finally went out for good.
> > Hmm... I'm not sure whether your eDP screen have the hotplug signal, so I
>
> I believe hotplug is hooked up but...
>
> > think you can try to add "analogix,force-hpd" flag into
> > rk3288-veyron-jaq.dts
> >
> > &edp {
> > analogix,need-force-hpd;
> > }
>
> ...already tried, just in case. No luck.
However, now when testing a different Jaq device, now this series +
Heiko's DTS updates + the "analogix,force-hpd" (i.e., [1]) works fine,
modulo a few log warnings, some of which are probably expected (for
instance, I believe the EDID is known not-so-helpful). Snippets:
[3.170176] rockchip-dp ff97.dp: AUX CH command reply failed!
[3.178058] rockchip-dp ff97.dp: AUX CH command reply failed!
[3.184166] rockchip-dp ff97.dp: unable to handle edid
and later:
[3.953300] rockchip-dp ff97.dp: EDID data does not include any
extensions.
[3.966731] rockchip-dp ff97.dp: EDID data does not include any
extensions.
[3.979409] rockchip-dp ff97.dp: EDID data does not include any
extensions.
[3.998730] rockchip-dp ff97.dp: Link Training Clock Recovery success
[4.007046] rockchip-dp ff97.dp: Link Training success!
[4.115040] rockchip-dp ff97.dp: Timeout of video streamclk ok
[4.121211] rockchip-dp ff97.dp: unable to config video
[4.127616] rockchip-dp ff97.dp: EDID data does not include any
extensions.
So, I'll chalk that earlier failure up to a hardware failure (or
possibly a still yet-undiagnosed hardware difference; my new Jaq has
some small differences from the previous unit).
Also, it's still not real clear why HPD isn't working upstream (and we
have to use the "force-hpd" property), when it appears to work on our
downstream Chrome OS tree.
Finally, I'll leave you with some small bits I've noticed from exploring
this issue on Jaq:
* The Chrome OS driver for this IP has a much longer timeout in (the
equivalent of) analogix_dp_detect_hpd; it polls in 10-20 ms intervals
(rather than 10-11 us) and takes something around 60 to 120 ms to
notice the panel.
* AFAICT, the Chrome OS driver never actually used the HPD interrupt;
it was only polling the HPD status bit. So I can't claim that the
functionality that Yakir is supporting here has ever been tested on
these platforms. (Now, I'm not sure this is extremely important,
since we still can fall back to polled status checks; see
drm_kms_helper_poll_init().)
That's all I've got for now.
Regards,
Brian
[1] https://github.com/mmind/linux-rockchip/commits/tmp/analogixdp-veyron
plus this diff:
diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
index 5c97e3153526..e77ae4c5531e 100644
--- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
@@ -88,6 +88,18 @@
};
};
+&backlight {
+ power-supply = <&backlight_regulator>;
+};
+
+&panel {
+ power-supply = <&panel_regulator>;
+};
+
+&edp {
+ analogix,need-force-hpd;
+};
+
&rk808 {
pinctrl-names = "default";
pinctrl-0 = <&pmic_int_l &dvs_1 &dvs_2>;
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
index c82c22f3d0e1..994189f49db5 100644
--- a/drivers/phy/phy-rockchip-dp.c
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -22,7 +22,7 @@
#define GRF_SOC_CON12 0x0274
-#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK BIT(4)
+#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK BIT(20)
#define GRF_EDP_REF_CLK_SEL_INTER BIT(4)
#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK BIT(21)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 3/3] ARM: e3xx: Add header file for pinctrl constants
This new header file defines pincontrol constants for USRP E3xx to use from E3xx's DTS file for pincontrol properties option. Signed-off-by: Moritz Fischer --- include/dt-bindings/pinctrl/pinctrl-e3xx.h | 142 + 1 file changed, 142 insertions(+) create mode 100644 include/dt-bindings/pinctrl/pinctrl-e3xx.h diff --git a/include/dt-bindings/pinctrl/pinctrl-e3xx.h b/include/dt-bindings/pinctrl/pinctrl-e3xx.h new file mode 100644 index 000..7b35ad2 --- /dev/null +++ b/include/dt-bindings/pinctrl/pinctrl-e3xx.h @@ -0,0 +1,142 @@ +/* + * Copyright (C) 2015 National Instruments Corp + * + * This header provides constants for USRP E3xx pinctrl bindings + * + * This program 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; version 2 of the License. + * + * 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. + */ + + +#ifndef _DT_BINDINGS_PINCTRL_E3XX_H +#define _DT_BINDINGS_PINCTRL_E3XX_H + +/* Pin names for the E31x usecase */ +#define E31X_TX_BANDSEL_2 "DB_1" +#define E31X_RX1B_BANDSEL_0"DB_3" +#define E31X_RX1B_BANDSEL_1"DB_5" +#define E31X_VCTXRX2_V2"DB_7" +#define E31X_TX_ENABLE1A "DB_9" +#define E31X_TX_ENABLE2A "DB_11" +#define E31X_TX_BANDSEL_0 "DB_12" +#define E31X_TX_ENABLE1B "DB_13" +#define E31X_TX_ENABLE2B "DB_15" +#define E31X_RX1C_BANDSEL_0"DB_17" +#define E31X_RX1C_BANDSEL_1"DB_19" +#define E31X_VCTXRX2_V1"DB_21" +#define E31X_VCTXRX1_V2"DB_23" +#define E31X_VCTXRX1_V1"DB_25" +#define E31X_VCRX1_V1 "DB_27" +#define E31X_VCRX1_V2 "DB_29" +#define E31X_VCRX2_V1 "DB_31" +#define E31X_VCRX2_V2 "DB_33" +#define E31X_CAT_CTRL_IN2 "DB_35" +#define E31X_CAT_CTRL_IN3 "DB_37" +#define E31X_CAT_CTRL_OUT0 "DB_39" +#define E31X_CAT_CTRL_OUT1 "DB_41" +#define E31X_CAT_CTRL_OUT2 "DB_43" +#define E31X_CAT_CTRL_OUT3 "DB_45" +/* pin 47 is nc */ +/* pin 49 is nc */ +/* pin 51 is nc */ +/* pin 53 is nc */ +/* pin 55 is nc */ +/* pin 57 is nc */ +/* pin 59 is nc */ +/* pin 61 is nc */ +/* pin 63 is nc */ +/* pin 65 is nc */ +#define E31X_CAT_TXNRX "DB_67" +#define E31X_CAT_ENABLE"DB_69" +#define E31X_CAT_ENAGC "DB_71" +/* pin 73 is nc */ +#define E31X_CAT_P0_D5 "DB_75" +#define E31X_CAT_P0_D7 "DB_77" +#define E31X_CAT_P0_D3 "DB_79" +#define E31X_CAT_P0_D9 "DB_81" +#define E31X_CAT_P0_D1 "DB_83" +#define E31X_CAT_P0_D6 "DB_85" +#define E31X_CAT_P0_D0 "DB_87" +#define E31X_CAT_P0_D2 "DB_89" +#define E31X_CAT_P0_D4 "DB_91" +#define E31X_CAT_P0_D11"DB_93" +#define E31X_CAT_P0_D10"DB_95" +#define E31X_CAT_P0_D8 "DB_97" +#define E31X_CAT_RX_FRAME "DB_99" +#define E31X_CAT_DATA_CLK "DB_101" +/* pin 103 is nc */ +/* pin 105 is nc */ +#define E31X_RX2_BANDSEL_2 "DB_107" +#define E31X_RX2_BANDSEL_1 "DB_109" +#define E31X_RX2_BANDSEL_0 "DB_111" +#define E31X_RX2C_BANDSEL_1"DB_113" +#define E31X_RX2C_BANDSEL_0"DB_115" +#define E31X_RX2B_BANDSEL_0"DB_117" +#define E31X_RX2B_BANDSEL_1"DB_119" + +/* pin 2 is nc */ +/* pin 4 is nc */ +#define E31X_RX1_BANDSEL_0 "DB_6" +#define E31X_RX1_BANDSEL_1 "DB_8" +#define E31X_RX1_BANDSEL_2 "DB_10" +#define E31X_TX_BANDSEL_1 "DB_14" +#define E31X_DB_SCL"DB_16" +#define E31X_DB_SCA"DB_18" +#define E31X_TUNE_DAC_SYNC_N "DB_20" +#define E31X_TUNE_DAC_SCLK "DB_22" +#define E31X_TUNE_DAC_SDIN "DB_24" +/* pin 26 is nc */ +/* pin 28 is nc */ +#define E31X_VCTCXO_TO_MB "DB_30" +/* pin 32 is nc */ +/* pin 34 is nc */ +/* pin 36 is nc */ +/* pin 38 is nc */ +#define E31X_CAT_CTRL_OUT4 "DB_40" +#define E31X_CAT_CTRL_OUT5 "DB_42" +#define E31X_CAT_CTRL_OUT6 "DB_44" +#define E31X_CAT_CTRL_OUT7 "DB_46" +#define E31X_CAT_RESET "DB_48" +#define E31X_CAT_CS"DB_50" +#define E31X_CAT_SCLK "DB_52" +#define E31X_CAT_MOSI "DB_54" +#define E31X_CAT_MISO "DB_56" +#define E31X_CAT_CTRL_IN0 "DB_58" +#define E31X_CAT_CTRL_IN1 "DB_60" +/* pin 62 is nc */ +/* pin 64 is nc */ +/* pin 66 is nc */ +/* pin 68 is nc */ +#define E31X_CAT_BBCLK_OUT "DB_70" +/* pin 72 is nc */ +#define E31X_CAT_SYNC "DB_74" +#define E31X_CAT_P1_D11"DB_78" +#define E31X_CAT_P1_D1 "DB_80" +#define E31X_CAT_P1_D3 "DB_82" +#define E31X_CAT_P1_D0 "DB_84" +#define E31X_CAT_P1_D5 "DB_86" +#define E31X_CAT_P1_D2 "DB_88" +#define E31X_CAT_P1_D4 "DB_90" +#define E31X_C
[RFC 2/3] pinctrl: e3xx: Adding support for NI Ettus Research USRP E3xx pinconf
The USRP E3XX series requires pinctrl to configure the idle state
FPGA image for minimizing power consumption.
This is required since different daughtercards have different uses
for pins on a common connector.
Signed-off-by: Moritz Fischer
---
drivers/pinctrl/Kconfig| 11 ++
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-e3xx.c | 403 +
3 files changed, 415 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-e3xx.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index b422e4e..fb2e195 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -101,6 +101,17 @@ config PINCTRL_DIGICOLOR
select PINMUX
select GENERIC_PINCONF
+config PINCTRL_E3XX
+ bool "NI Ettus Research USRP E3xx pinctrl driver"
+ depends on OF
+ select PINCONF
+ select GENERIC_PINCONF
+ help
+ Say Y here to support Ettus Research E3xx pinctrl driver, which is
used for
+ the NI Ettus Research USRP E3xx family of embedded SDRs, including
E310
+ and E330.
+ This driver requires the pinctrl framework.
+
config PINCTRL_LANTIQ
bool
depends on LANTIQ
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 738cb49..799f3ac 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_PINCTRL_AT91)+= pinctrl-at91.o
obj-$(CONFIG_PINCTRL_AT91PIO4) += pinctrl-at91-pio4.o
obj-$(CONFIG_PINCTRL_AMD) += pinctrl-amd.o
obj-$(CONFIG_PINCTRL_DIGICOLOR)+= pinctrl-digicolor.o
+obj-$(CONFIG_PINCTRL_E3XX) += pinctrl-e3xx.o
obj-$(CONFIG_PINCTRL_FALCON) += pinctrl-falcon.o
obj-$(CONFIG_PINCTRL_MESON)+= meson/
obj-$(CONFIG_PINCTRL_PALMAS) += pinctrl-palmas.o
diff --git a/drivers/pinctrl/pinctrl-e3xx.c b/drivers/pinctrl/pinctrl-e3xx.c
new file mode 100644
index 000..55576fd
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-e3xx.c
@@ -0,0 +1,403 @@
+/*
+ * Copyright (c) 2015 National Instruments Corp.
+ *
+ * Pinctrl Driver for Ettus Research E3XX series daughterboards
+ *
+ * This program 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; version 2 of the License.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "pinctrl-utils.h"
+#include "core.h"
+
+#define E3XX_NUM_DB_PINS 120
+#define E3XX_PINS_PER_REG 32
+
+#define E3XX_DDR_OFFSET 0x00
+#define E3XX_OUT_OFFSET 0x20
+
+static const struct pinctrl_pin_desc e3xx_pins[] = {
+ /* pin0 doesn't exist */
+ PINCTRL_PIN(1, "DB_1"),
+ PINCTRL_PIN(2, "DB_2"),
+ PINCTRL_PIN(3, "DB_3"),
+ PINCTRL_PIN(4, "DB_4"),
+ PINCTRL_PIN(5, "DB_5"),
+ PINCTRL_PIN(6, "DB_6"),
+ PINCTRL_PIN(7, "DB_7"),
+ PINCTRL_PIN(8, "DB_8"),
+ PINCTRL_PIN(9, "DB_9"),
+ PINCTRL_PIN(10, "DB_10"),
+ PINCTRL_PIN(11, "DB_11"),
+ PINCTRL_PIN(12, "DB_12"),
+ PINCTRL_PIN(13, "DB_13"),
+ PINCTRL_PIN(14, "DB_14"),
+ PINCTRL_PIN(15, "DB_15"),
+ PINCTRL_PIN(16, "DB_16"),
+ PINCTRL_PIN(17, "DB_17"),
+ PINCTRL_PIN(18, "DB_18"),
+ PINCTRL_PIN(19, "DB_19"),
+ PINCTRL_PIN(20, "DB_20"),
+ PINCTRL_PIN(21, "DB_21"),
+ PINCTRL_PIN(22, "DB_22"),
+ PINCTRL_PIN(23, "DB_23"),
+ PINCTRL_PIN(24, "DB_24"),
+ PINCTRL_PIN(25, "DB_25"),
+ PINCTRL_PIN(26, "DB_26"),
+ PINCTRL_PIN(27, "DB_27"),
+ PINCTRL_PIN(28, "DB_28"),
+ PINCTRL_PIN(29, "DB_29"),
+ PINCTRL_PIN(30, "DB_30"),
+ PINCTRL_PIN(31, "DB_31"),
+ PINCTRL_PIN(32, "DB_32"),
+ PINCTRL_PIN(33, "DB_33"),
+ PINCTRL_PIN(34, "DB_34"),
+ PINCTRL_PIN(35, "DB_35"),
+ PINCTRL_PIN(36, "DB_36"),
+ PINCTRL_PIN(37, "DB_37"),
+ PINCTRL_PIN(38, "DB_38"),
+ PINCTRL_PIN(39, "DB_39"),
+ PINCTRL_PIN(40, "DB_40"),
+ PINCTRL_PIN(41, "DB_41"),
+ PINCTRL_PIN(42, "DB_42"),
+ PINCTRL_PIN(43, "DB_43"),
+ PINCTRL_PIN(44, "DB_44"),
+ PINCTRL_PIN(45, "DB_45"),
+ PINCTRL_PIN(46, "DB_46"),
+ PINCTRL_PIN(47, "DB_47"),
+ PINCTRL_PIN(48, "DB_48"),
+ PINCTRL_PIN(49, "DB_49"),
+ PINCTRL_PIN(50, "DB_50"),
+ PINCTRL_PIN(52, "DB_52"),
+ PINCTRL_PIN(53, "DB_53"),
+ PINCTRL_PIN(54, "DB_54"),
+ PINCTRL_PIN(55, "DB_55"),
+ PINCTRL_PIN(56, "DB_56"),
+ PINCTRL_PIN(57, "DB_57"),
+ PINCTRL_PIN(58, "DB_58"),
+ PINCTRL_PIN(59, "DB_59"),
+ PINCTRL_PIN(60, "DB_60"),
+ PINCTRL_PIN(61, "DB_61"),
+
Re: [PATCH v7 02/50] powerpc/pci: Override pcibios_setup_bridge()
On Fri, Nov 06, 2015 at 09:27:42AM +1100, Daniel Axtens wrote:
>Gavin Shan writes:
>
>>
>> +void pcibios_setup_bridge(struct pci_bus *bus, unsigned long type)
>> +{
>> +struct pci_controller *hose = pci_bus_to_host(bus);
>Very much a nit-pick, but I thought we were trying to move towards using
>phb instead of hose in new code?
>
Take PowerNV platform as an example, "hose" means "struct pci_controller",
but "phb" means "struct pnv_phb". We don't have the movement to use "phb"
to represent "struct pci_controller".
>Apart from that this looks good. I would probably have merged it with
>the previous patch, but I know Alexey has been suggesting a lot of
>splitting and merging previously, so whatever he prefers here is OK.
>
I'd like to keep them separate as they're for different subsystem:
PCI generic subsystem and PowerPC subsystem. Separate maintainers
for them can pick them as they will.
>> +
>> +if (hose->controller_ops.setup_bridge)
>> +hose->controller_ops.setup_bridge(bus, type);
>> +}
>> +
>> void pcibios_reset_secondary_bus(struct pci_dev *dev)
>> {
>> struct pci_controller *phb = pci_bus_to_host(dev->bus);
>> --
>> 2.1.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majord...@vger.kernel.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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/5] PM / OPP: Add {opp-microvolt|opp-microamp|turbo-mode|opp-suspend}- binding
On Wed, Nov 4, 2015 at 9:19 PM, Viresh Kumar wrote: > On 04-11-15, 21:02, Rob Herring wrote: >> > +- turbo-mode-: Named turbo-mode property. Similar to >> > opp-microvolt- >> > + property, but for turbo mode instead. >> > + >> > - opp-suspend: Marks the OPP to be used during device suspend. Only one >> > OPP in >> >the table should have this. >> > >> > +- opp-suspend-: Named opp-suspend property. Similar to >> > + opp-microvolt- property, but for suspend opp instead. >> > + >> >> I don't think these last 2 make sense. turbo-mode is a flag that the >> mode has restrictions such as other cores have to be idle or something. >> Similarly, opp-suspend should not vary by . > > Based on what version of the hardware you are running, via > opp-supported-hw property, the platform can enable a different set of > OPPs. And in that case we may want to select different OPPs marked as > turbo or suspend freq. That's what I thought at least. > > For example, on version A of the hardware we have following available > frequencies: 800, 1000, 1100, 1200 MHz. Where 800 MHz is the suspend > freq and 1200 is the turbo one. > > But on a slightly different version of hardware B, we have two more > OPPs available: 700 and 1400 MHz. And in that case we want the suspend > freq to be 700 and turbo OPP to be only 1400 MHz. But different frequencies are different OPP nodes (since that is the unit address now), so it is not going to hurt to set turbo-mode on both 1200 and 1400. Rob > > -- > viresh -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 10/50] powerpc/powernv: Simplify pnv_ioda_setup_pe_seg()
Gavin Shan writes:
> The original implementation of pnv_ioda_setup_pe_seg() configures
> IO and M32 segments by separate logics, which can be merged by
> by caching @segmap, @seg_size, @win in advance. This shouldn't
> cause any behavioural changes.
>
> Signed-off-by: Gavin Shan
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 62
> ++-
> 1 file changed, 28 insertions(+), 34 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 7ee7cfe..553d3f3 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -2752,8 +2752,10 @@ static void pnv_ioda_setup_pe_seg(struct
> pci_controller *hose,
> struct pnv_phb *phb = hose->private_data;
> struct pci_bus_region region;
> struct resource *res;
> - int i, index;
> - int rc;
> + unsigned int segsize;
> + int *segmap, index, i;
> + uint16_t win;
> + int64_t rc;
Good catch! Opal return codes are 64 bit and that should be explicit
in the type. However, I seem to remember that we preferred a different
type for 64 bit ints in the kernel. I think it's s64, and there are some
other uses of that in pci_ioda.c for return codes.
(I'm actually surprised that's not picked up as a compiler
warning. Maybe that's something to look at in future.)
The rest of the patch looks good on casual inspection - to be sure I'll
test the entire series on a machine. (hopefully, time permitting!)
Regards,
Daniel
>
> /*
>* NOTE: We only care PCI bus based PE for now. For PCI
> @@ -2770,23 +2772,9 @@ static void pnv_ioda_setup_pe_seg(struct
> pci_controller *hose,
> if (res->flags & IORESOURCE_IO) {
> region.start = res->start - phb->ioda.io_pci_base;
> region.end = res->end - phb->ioda.io_pci_base;
> - index = region.start / phb->ioda.io_segsize;
> -
> - while (index < phb->ioda.total_pe_num &&
> -region.start <= region.end) {
> - phb->ioda.io_segmap[index] = pe->pe_number;
> - rc = opal_pci_map_pe_mmio_window(phb->opal_id,
> - pe->pe_number, OPAL_IO_WINDOW_TYPE, 0,
> index);
> - if (rc != OPAL_SUCCESS) {
> - pr_err("%s: OPAL error %d when mapping
> IO "
> -"segment #%d to PE#%d\n",
> -__func__, rc, index,
> pe->pe_number);
> - break;
> - }
> -
> - region.start += phb->ioda.io_segsize;
> - index++;
> - }
> + segsize = phb->ioda.io_segsize;
> + segmap = phb->ioda.io_segmap;
> + win = OPAL_IO_WINDOW_TYPE;
> } else if ((res->flags & IORESOURCE_MEM) &&
> !pnv_pci_is_mem_pref_64(res->flags)) {
> region.start = res->start -
> @@ -2795,23 +2783,29 @@ static void pnv_ioda_setup_pe_seg(struct
> pci_controller *hose,
> region.end = res->end -
> hose->mem_offset[0] -
> phb->ioda.m32_pci_base;
> - index = region.start / phb->ioda.m32_segsize;
> -
> - while (index < phb->ioda.total_pe_num &&
> -region.start <= region.end) {
> - phb->ioda.m32_segmap[index] = pe->pe_number;
> - rc = opal_pci_map_pe_mmio_window(phb->opal_id,
> - pe->pe_number, OPAL_M32_WINDOW_TYPE, 0,
> index);
> - if (rc != OPAL_SUCCESS) {
> - pr_err("%s: OPAL error %d when mapping
> M32 "
> -"segment#%d to PE#%d",
> -__func__, rc, index,
> pe->pe_number);
> - break;
> - }
> + segsize = phb->ioda.m32_segsize;
> + segmap = phb->ioda.m32_segmap;
> + win = OPAL_M32_WINDOW_TYPE;
> + } else {
> + continue;
> + }
>
> - region.start += phb->ioda.m32_segsize;
> - index++;
> + index = region.start / segsize;
> + while (index < phb->ioda.total_pe_num &&
> +region.start <= region.end) {
> + segmap[index] = pe->pe_number;
> + rc = opal_pci_map_pe_mmio_window(phb-
Re: [PATCH v7 03/50] powerpc/pci: Cleanup on struct pci_controller_ops
Gavin Shan writes: > Each PHB has one instance of "struct pci_controller_ops", which > includes various callbacks called by PCI subsystem. In the definition > of this struct, some callbacks have explicit names for its arguments, > but the left don't have. > > This adds all explicit names of the arguments to the callbacks in > "struct pci_controller_ops" so that the code looks consistent. Thank you very much for doing this - I should have done it the first time I created pci_controller_ops. They all look good, with one nit-pick: > - void(*shutdown)(struct pci_controller *); > + void(*shutdown)(struct pci_controller *hose); I think we're trying to move from hose to phb in new code. Once that is fixed: Reviewed-by: Daniel Axtens Regards, Daniel > }; > > /* > -- > 2.1.0 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html signature.asc Description: PGP signature
Re: [PATCH v7 04/50] powerpc/powernv: Cleanup on pnv_pci_ioda_controller_ops
Gavin Shan writes:
> This cleans up on pnv_pci_ioda_controller_ops struct to use tab
> instead of space indent of statement to avoid complains from
> scripts/checkpatch.pl. No logical changes introduced.
Oh, that was my code :/ Sorry I missed that, thanks for cleaning it up!
Reviewed-by: Daniel Axtens
>
> Signed-off-by: Gavin Shan
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
> b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 2e2bedb..aa3645c 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -3064,17 +3064,17 @@ static void pnv_pci_ioda_shutdown(struct
> pci_controller *hose)
> }
>
> static const struct pci_controller_ops pnv_pci_ioda_controller_ops = {
> - .dma_dev_setup = pnv_pci_dma_dev_setup,
> + .dma_dev_setup = pnv_pci_dma_dev_setup,
> #ifdef CONFIG_PCI_MSI
> - .setup_msi_irqs = pnv_setup_msi_irqs,
> - .teardown_msi_irqs = pnv_teardown_msi_irqs,
> + .setup_msi_irqs = pnv_setup_msi_irqs,
> + .teardown_msi_irqs = pnv_teardown_msi_irqs,
> #endif
> - .enable_device_hook = pnv_pci_enable_device_hook,
> - .window_alignment = pnv_pci_window_alignment,
> - .reset_secondary_bus = pnv_pci_reset_secondary_bus,
> - .dma_set_mask = pnv_pci_ioda_dma_set_mask,
> - .dma_get_required_mask = pnv_pci_ioda_dma_get_required_mask,
> - .shutdown = pnv_pci_ioda_shutdown,
> + .enable_device_hook = pnv_pci_enable_device_hook,
> + .window_alignment = pnv_pci_window_alignment,
> + .reset_secondary_bus= pnv_pci_reset_secondary_bus,
> + .dma_set_mask = pnv_pci_ioda_dma_set_mask,
> + .dma_get_required_mask = pnv_pci_ioda_dma_get_required_mask,
> + .shutdown = pnv_pci_ioda_shutdown,
> };
>
> static void __init pnv_pci_init_ioda_phb(struct device_node *np,
> --
> 2.1.0
>
> ___
> Linuxppc-dev mailing list
> linuxppc-...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 02/50] powerpc/pci: Override pcibios_setup_bridge()
Gavin Shan writes:
>
> +void pcibios_setup_bridge(struct pci_bus *bus, unsigned long type)
> +{
> + struct pci_controller *hose = pci_bus_to_host(bus);
Very much a nit-pick, but I thought we were trying to move towards using
phb instead of hose in new code?
Apart from that this looks good. I would probably have merged it with
the previous patch, but I know Alexey has been suggesting a lot of
splitting and merging previously, so whatever he prefers here is OK.
> +
> + if (hose->controller_ops.setup_bridge)
> + hose->controller_ops.setup_bridge(bus, type);
> +}
> +
> void pcibios_reset_secondary_bus(struct pci_dev *dev)
> {
> struct pci_controller *phb = pci_bus_to_host(dev->bus);
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
signature.asc
Description: PGP signature
Re: [PATCH v4 1/2] watchdog: imx2_wdt: add external reset support via 'ext-reset-output' dt prop
On Thu, Nov 05, 2015 at 04:19:21PM -0500, Akshay Bhat wrote:
> From: Tim Harvey
>
> The IMX6 watchdog supports assertion of a signal (WDOG_B) which
> can be pinmux'd to an external pin. This is typically used for boards that
> have PMIC's in control of the IMX6 power rails. In fact, failure to use
> such an external reset on boards with external PMIC's can result in various
> hangs due to the IMX6 not being fully reset [1] as well as the board failing
> to reset because its PMIC has not been reset to provide adequate voltage for
> the CPU when coming out of reset at 800Mhz.
>
> This uses a new device-tree property 'ext-reset-output' to indicate the
> board has such a reset and to cause the watchdog to be configured to assert
> WDOG_B instead of an internal reset both on a watchdog timeout and in
> system_restart.
>
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333689.html
>
> Cc: Lucas Stach
> Signed-off-by: Tim Harvey
> ---
> .../devicetree/bindings/watchdog/fsl-imx-wdt.txt | 2 ++
> drivers/watchdog/imx2_wdt.c | 20
> ++--
> 2 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> index 8dab6fd..9b89b3a 100644
> --- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
> @@ -9,6 +9,8 @@ Optional property:
properties ?
> - big-endian: If present the watchdog device's registers are implemented
>in big endian mode, otherwise in native mode(same with CPU), for more
>detail please see: Documentation/devicetree/bindings/regmap/regmap.txt.
> +- ext-reset-output: If present the watchdog device is configured to assert
> its
Should that have a vendor prefix ? Also, not sure if "-output"
has any real value in the property name. "fsl,external-reset", maybe ?
> + external reset (WDOG_B) instead of issuing a software reset.
>
> Examples:
>
> diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
> index 29ef719..84bfec4 100644
> --- a/drivers/watchdog/imx2_wdt.c
> +++ b/drivers/watchdog/imx2_wdt.c
> @@ -41,6 +41,8 @@
>
> #define IMX2_WDT_WCR 0x00/* Control Register */
> #define IMX2_WDT_WCR_WT (0xFF << 8) /* -> Watchdog Timeout
> Field */
> +#define IMX2_WDT_WCR_WDA (1 << 5)/* -> External Reset WDOG_B */
> +#define IMX2_WDT_WCR_SRS (1 << 4)/* -> Software Reset Signal */
> #define IMX2_WDT_WCR_WRE (1 << 3)/* -> WDOG Reset Enable */
> #define IMX2_WDT_WCR_WDE (1 << 2)/* -> Watchdog Enable */
> #define IMX2_WDT_WCR_WDZST (1 << 0)/* -> Watchdog timer Suspend */
> @@ -65,6 +67,7 @@ struct imx2_wdt_device {
> struct timer_list timer;/* Pings the watchdog when closed */
> struct watchdog_device wdog;
> struct notifier_block restart_handler;
> + bool ext_reset;
> };
>
> static bool nowayout = WATCHDOG_NOWAYOUT;
> @@ -90,6 +93,13 @@ static int imx2_restart_handler(struct notifier_block
> *this, unsigned long mode,
> struct imx2_wdt_device *wdev = container_of(this,
> struct imx2_wdt_device,
> restart_handler);
> +
> + /* Use internal reset or external - not both */
> + if (wdev->ext_reset)
> + wcr_enable |= IMX2_WDT_WCR_SRS; /* do not assert int reset */
> + else
> + wcr_enable |= IMX2_WDT_WCR_WDA; /* do not assert ext-reset */
> +
> /* Assert SRS signal */
> regmap_write(wdev->regmap, IMX2_WDT_WCR, wcr_enable);
> /*
> @@ -119,8 +129,12 @@ static inline void imx2_wdt_setup(struct watchdog_device
> *wdog)
> val |= IMX2_WDT_WCR_WDZST;
> /* Strip the old watchdog Time-Out value */
> val &= ~IMX2_WDT_WCR_WT;
> - /* Generate reset if WDOG times out */
> - val &= ~IMX2_WDT_WCR_WRE;
> + /* Generate internal chip-level reset if WDOG times out */
> + if (!wdev->ext_reset)
> + val &= ~IMX2_WDT_WCR_WRE;
> + /* Or if external-reset assert WDOG_B reset only on time-out */
> + else
> + val |= IMX2_WDT_WCR_WRE;
I don't really understand what this means. Normally I would hope that a watchdog
only generates a reset if/when it times out.
> /* Keep Watchdog Disabled */
> val &= ~IMX2_WDT_WCR_WDE;
> /* Set the watchdog's Time-Out value */
> @@ -267,6 +281,8 @@ static int __init imx2_wdt_probe(struct platform_device
> *pdev)
> regmap_read(wdev->regmap, IMX2_WDT_WRSR, &val);
> wdog->bootstatus = val & IMX2_WDT_WRSR_TOUT ? WDIOF_CARDRESET : 0;
>
> + wdev->ext_reset = of_property_read_bool(pdev->dev.of_node,
> + "ext-reset-output");
> wdog->timeout = clamp_t(unsigned, timeout, 1, IM
[PATCH 4/5] qcom: ipq4019: Add basic board/dts support for IPQ4019 SoC
Add initial dts files and SoC support for IPQ4019
Signed-off-by: Varadarajan Narayanan
---
arch/arm/boot/dts/qcom-ipq4019.dtsi | 108
1 file changed, 108 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom-ipq4019.dtsi
diff --git a/arch/arm/boot/dts/qcom-ipq4019.dtsi
b/arch/arm/boot/dts/qcom-ipq4019.dtsi
new file mode 100644
index 000..157a9ca
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019.dtsi
@@ -0,0 +1,108 @@
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only 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.
+ */
+
+/dts-v1/;
+
+#include "skeleton.dtsi"
+#include
+#include
+
+/ {
+ model = "Qualcomm Technologies, Inc. IPQ4019";
+ compatible = "qcom,ipq4019";
+ interrupt-parent = <&intc>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x0>;
+ clocks = <&gcc GCC_APPS_CLK_SRC>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x1>;
+ clocks = <&gcc GCC_APPS_CLK_SRC>;
+ };
+
+ cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x2>;
+ clocks = <&gcc GCC_APPS_CLK_SRC>;
+ };
+
+ cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x3>;
+ clocks = <&gcc GCC_APPS_CLK_SRC>;
+ };
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ compatible = "simple-bus";
+
+ intc: interrupt-controller@b00 {
+ compatible = "qcom,msm-qgic2";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x0b00 0x1000>,
+ <0x0b002000 0x1000>;
+ };
+
+ gcc: clock-controller@180 {
+ compatible = "qcom,gcc-ipq4019";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ reg = <0x180 0x6>;
+ };
+
+ tlmm: pinctrl@0x0100 {
+ compatible = "qcom,ipq4019-pinctrl";
+ reg = <0x0100 0x30>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = <0 208 0>;
+ };
+
+ serial@78af000 {
+ compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+ reg = <0x78af000 0x200>;
+ interrupts = <0 107 0>;
+ status = "disabled";
+ clocks = <&gcc GCC_BLSP1_UART1_APPS_CLK>,
+ <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ };
+
+ serial@78b {
+ compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
+ reg = <0x78b 0x200>;
+ interrupts = <0 108 0>;
+ status = "disabled";
+ clocks = <&gcc GCC_BLSP1_UART2_APPS_CLK>,
+ <&gcc GCC_BLSP1_AHB_CLK>;
+ clock-names = "core", "iface";
+ };
+ };
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] dts: ipq4019: Add support for IPQ4019 DK01 board
Initial board support dts files for DK01 board.
Signed-off-by: Senthilkumar N L
Signed-off-by: Varadarajan Narayanan
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c1.dts | 22 +++
arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi | 49 +
3 files changed, 72 insertions(+)
create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c1.dts
create mode 100644 arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bb8fa02..445340d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -491,6 +491,7 @@ dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8074-dragonboard.dtb \
qcom-apq8084-ifc6540.dtb \
qcom-apq8084-mtp.dtb \
+ qcom-ipq4019-ap.dk01.1-c1.dtb \
qcom-ipq8064-ap148.dtb \
qcom-msm8660-surf.dtb \
qcom-msm8960-cdp.dtb \
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c1.dts
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c1.dts
new file mode 100644
index 000..0d92f1b
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1-c1.dts
@@ -0,0 +1,22 @@
+/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ */
+
+#include "qcom-ipq4019-ap.dk01.1.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. IPQ40xx/AP-DK01.1-C1";
+
+};
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
new file mode 100644
index 000..7448058
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
@@ -0,0 +1,49 @@
+/* Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ */
+
+#include "qcom-ipq4019.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. IPQ4019/AP-DK01.1";
+ compatible = "qcom,ipq4019";
+
+ soc {
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <1 2 0xf08>,
+<1 3 0xf08>,
+<1 4 0xf08>,
+<1 1 0xf08>;
+ clock-frequency = <4800>;
+ };
+
+ pinctrl@0x0100 {
+ serial_pins: serial_pinmux {
+ mux {
+ pins = "gpio60", "gpio61";
+ function = "blsp_uart0";
+ bias-disable;
+ };
+ };
+ };
+
+ serial@78af000 {
+ pinctrl-0 = <&serial_pins>;
+ pinctrl-names = "default";
+ status = "ok";
+ };
+ };
+};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] pinctrl: qcom: ipq4019: Add IPQ4019 pinctrl support
From: Varadarajan Narayanan Add pinctrl driver support for IPQ4019 platform Signed-off-by: Sricharan R Signed-off-by: Mathieu Olivari Signed-off-by: Varadarajan Narayanan Signed-off-by: Matthew McClintock --- .../bindings/pinctrl/qcom,ipq4019-pinctrl.txt | 116 ++ drivers/pinctrl/qcom/Kconfig |8 + drivers/pinctrl/qcom/Makefile |1 + drivers/pinctrl/qcom/pinctrl-ipq4019.c | 1280 4 files changed, 1405 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt create mode 100644 drivers/pinctrl/qcom/pinctrl-ipq4019.c diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt new file mode 100644 index 000..045c5aa --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt @@ -0,0 +1,116 @@ +Qualcomm Atheros IPQ4019 TLMM block + +Required properties: +- compatible: "qcom,ipq4019-pinctrl" +- reg: Should be the base address and length of the TLMM block. +- interrupts: Should be the parent IRQ of the TLMM block. +- interrupt-controller: Marks the device node as an interrupt controller. +- #interrupt-cells: Should be two. +- gpio-controller: Marks the device node as a GPIO controller. +- #gpio-cells : Should be two. +The first cell is the gpio pin number and the +second cell is used for optional parameters. + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +The pin configuration nodes act as a container for an abitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + pins, function, bias-disable, bias-pull-down, bias-pull,up, drive-strength. + +Non-empty subnodes must specify the 'pins' property. +Note that not all properties are valid for all pins. + + +Valid values for qcom,pins are: + gpio0-gpio70 +Supports mux, bias and drive-strength + +sdio_cd, sdio_clk, sdio_cmd, sdio_data1, sdio_data1, sdio_data1, sdio_data1, +sdio_data5, sdio_data6, sdio_data7 + +Valid values for qcom,function are: +smart0, jtag, audio0, mdio0, wcss0_dbg18, wcss1_dbg18, qdss_tracedata_a, mdc, +wcss0_dbg19, wcss1_dbg19, blsp_uart1, wifi0_uart, wifi1_uart, smart1, +wcss0_dbg20, wcss1_dbg20, wifi0_uart0, wifi1_uart0, wcss0_dbg21, wcss1_dbg21, +blsp_i2c0, wcss0_dbg22, wcss1_dbg22, wcss0_dbg23, wcss1_dbg23, blsp_i2c1, +wcss0_dbg24, wcss1_dbg24, wcss0_dbg25, wcss1_dbg25, pcie_rst, wcss0_dbg26, +wcss1_dbg26, pcie_clk0, wcss0_dbg27, wcss1_dbg27, led0, blsp_uart0, led1, +chip_irq0, wifi0_uart1, wifi1_uart1, wcss0_dbg28, wcss1_dbg28, chip_rst, +audio_spdifout, sdio1, rgmii2, sdio2, rgmii3, sdio3, rgmii_rx, sdio_clk, +wcss0_dbg29, wcss1_dbg29, wcss0_dbg16, wcss1_dbg16, audio1, wcss0_dbg17, +wcss1_dbg17, sdio_cd, rgmii0, sdio0, rgmii1, rgmii_txc, audio_td1, sdio_cmd, +audio_td2, sdio4, audio_td3, sdio5, audio_pwm0, sdio6, audio_pwm1, sdio7, +rgmii_rxc, audio_pwm2, rgmii_tx, audio_pwm3, wcss0_dbg30, wcss1_dbg30, +wcss0_dbg31, wcss1_dbg31, rmii00, led2, rmii01, wifi0_wci, wifi1_wci, +rmii0_tx, rmii0_rx, pcie_clk1, led3, pcie_wakeup, rmii0_refclk, +wifi0_rfsilient0, wifi1_rfsilient0, smart2, led4, wifi0_cal, wifi1_cal, +wifi_wci0, rmii0_dv, wifi_wci1, rmii1_refclk, blsp_spi1, led5, rmii10, +blsp_spi0, led6, rmii11, led7, rmii1_dv, led8, rmii1_tx, aud_pin, led9, +rmii1_rx, led10, wifi0_rfsilient1, wifi1_rfsilient1, led11, qpic_pad, +qdss_cti_trig_in_a0, mdio1, audio2, dbg_out, wcss0_dbg, wcss1_dbg, atest_char3, +pmu0, wcss0_dbg0, wcss1_dbg0, atest_char2, pmu1, wcss0_dbg1, wcss1_dbg1, +atest_char1, wcss0_dbg2, wcss1_dbg2, qpic_pad4, atest_char0, wcss0_dbg3, +wcss1_dbg3, qpic_pad5, smart3, wcss0_dbg14, wcss1_dbg14, qpic_pad6, +wcss0_dbg15, wcss1_dbg15, qdss_tracectl_a, qpic_pad7, atest_char, wcss0_dbg4, +wcss1_dbg4, qdss_traceclk_a, qpic_pad8, wcs
Re: [PATCH V2 0/5] PM / OPP: opp-supported-hw and -name bindings
On Thursday, November 05, 2015 07:11:51 AM Viresh Kumar wrote:
> Hi Rafael,
>
> All the bindings are Reviewed by Stephen now and Rob didn't had a
> problem with them (though he didn't Ack them separately yet) :)
>
> The first patch enables us to select only a subset of OPPs from the
> bigger table, based on what version of the hardware we are running on.
>
> The second one enables us to select slightly different values for
> multiple properties, based on what kind of hardware they are running on.
>
> The third one removes an (unused) binding, which is replaced by the
> second patch with a better solution.
>
> The fourth patch is based on what Stephen suggested (and then reviewed)
> in the earlier series, and the 5th one updates the existing users of
> these bindings for it.
>
> Viresh Kumar (5):
> PM / OPP: Add "opp-supported-hw" binding
> PM / OPP: Add
> {opp-microvolt|opp-microamp|turbo-mode|opp-suspend}- binding
> PM / OPP: Remove 'operating-points-names' binding
> PM / OPP: Rename OPP nodes as opp@
> ARM: dts: exynos4412: Rename OPP nodes as opp@
>
> Documentation/devicetree/bindings/opp/opp.txt | 143
> +++---
> arch/arm/boot/dts/exynos4412.dtsi | 28 ++---
> 2 files changed, 118 insertions(+), 53 deletions(-)
So this clearly is a new feature and it clearly missed the merge window boundary
for v4.4. I can queue it up for v4.5.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/2] watchdog: imx2_wdt: add external reset support via 'ext-reset-output' dt prop
From: Tim Harvey
The IMX6 watchdog supports assertion of a signal (WDOG_B) which
can be pinmux'd to an external pin. This is typically used for boards that
have PMIC's in control of the IMX6 power rails. In fact, failure to use
such an external reset on boards with external PMIC's can result in various
hangs due to the IMX6 not being fully reset [1] as well as the board failing
to reset because its PMIC has not been reset to provide adequate voltage for
the CPU when coming out of reset at 800Mhz.
This uses a new device-tree property 'ext-reset-output' to indicate the
board has such a reset and to cause the watchdog to be configured to assert
WDOG_B instead of an internal reset both on a watchdog timeout and in
system_restart.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333689.html
Cc: Lucas Stach
Signed-off-by: Tim Harvey
---
.../devicetree/bindings/watchdog/fsl-imx-wdt.txt | 2 ++
drivers/watchdog/imx2_wdt.c | 20 ++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
index 8dab6fd..9b89b3a 100644
--- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt
@@ -9,6 +9,8 @@ Optional property:
- big-endian: If present the watchdog device's registers are implemented
in big endian mode, otherwise in native mode(same with CPU), for more
detail please see: Documentation/devicetree/bindings/regmap/regmap.txt.
+- ext-reset-output: If present the watchdog device is configured to assert its
+ external reset (WDOG_B) instead of issuing a software reset.
Examples:
diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 29ef719..84bfec4 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -41,6 +41,8 @@
#define IMX2_WDT_WCR 0x00/* Control Register */
#define IMX2_WDT_WCR_WT(0xFF << 8) /* -> Watchdog Timeout
Field */
+#define IMX2_WDT_WCR_WDA (1 << 5)/* -> External Reset WDOG_B */
+#define IMX2_WDT_WCR_SRS (1 << 4)/* -> Software Reset Signal */
#define IMX2_WDT_WCR_WRE (1 << 3)/* -> WDOG Reset Enable */
#define IMX2_WDT_WCR_WDE (1 << 2)/* -> Watchdog Enable */
#define IMX2_WDT_WCR_WDZST (1 << 0)/* -> Watchdog timer Suspend */
@@ -65,6 +67,7 @@ struct imx2_wdt_device {
struct timer_list timer;/* Pings the watchdog when closed */
struct watchdog_device wdog;
struct notifier_block restart_handler;
+ bool ext_reset;
};
static bool nowayout = WATCHDOG_NOWAYOUT;
@@ -90,6 +93,13 @@ static int imx2_restart_handler(struct notifier_block *this,
unsigned long mode,
struct imx2_wdt_device *wdev = container_of(this,
struct imx2_wdt_device,
restart_handler);
+
+ /* Use internal reset or external - not both */
+ if (wdev->ext_reset)
+ wcr_enable |= IMX2_WDT_WCR_SRS; /* do not assert int reset */
+ else
+ wcr_enable |= IMX2_WDT_WCR_WDA; /* do not assert ext-reset */
+
/* Assert SRS signal */
regmap_write(wdev->regmap, IMX2_WDT_WCR, wcr_enable);
/*
@@ -119,8 +129,12 @@ static inline void imx2_wdt_setup(struct watchdog_device
*wdog)
val |= IMX2_WDT_WCR_WDZST;
/* Strip the old watchdog Time-Out value */
val &= ~IMX2_WDT_WCR_WT;
- /* Generate reset if WDOG times out */
- val &= ~IMX2_WDT_WCR_WRE;
+ /* Generate internal chip-level reset if WDOG times out */
+ if (!wdev->ext_reset)
+ val &= ~IMX2_WDT_WCR_WRE;
+ /* Or if external-reset assert WDOG_B reset only on time-out */
+ else
+ val |= IMX2_WDT_WCR_WRE;
/* Keep Watchdog Disabled */
val &= ~IMX2_WDT_WCR_WDE;
/* Set the watchdog's Time-Out value */
@@ -267,6 +281,8 @@ static int __init imx2_wdt_probe(struct platform_device
*pdev)
regmap_read(wdev->regmap, IMX2_WDT_WRSR, &val);
wdog->bootstatus = val & IMX2_WDT_WRSR_TOUT ? WDIOF_CARDRESET : 0;
+ wdev->ext_reset = of_property_read_bool(pdev->dev.of_node,
+ "ext-reset-output");
wdog->timeout = clamp_t(unsigned, timeout, 1, IMX2_WDT_MAX_TIME);
if (wdog->timeout != timeout)
dev_warn(&pdev->dev, "Initial timeout out of range! Clamped
from %u to %u\n",
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2 V2] ls2080a/dts: Add little endian property for GPIO IP block
On Thu, Nov 05, 2015 at 10:42:21AM +0800, Liu Gang wrote: > The GPIO block for ls2080a platform has little endian registers, > the GPIO driver needs this property to read/write registers by > right interface. > > Signed-off-by: Liu Gang Acked-by: Rob Herring > --- > V2 changes: No > > Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt | 3 +++ > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 4 > 2 files changed, 7 insertions(+) > > diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt > b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt > index f2455c5..c836dab 100644 > --- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt > +++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt > @@ -10,6 +10,9 @@ Required properties: >the second cell is used to specify the gpio polarity: >0 = active high >1 = active low > +- little-endian : Should be set if the GPIO has little endian > + registers. No the property means the GPIO > + registers are big endian mode. > > Example: > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi > b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi > index e81cd48..0099205 100644 > --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi > +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi > @@ -277,6 +277,7 @@ > reg = <0x0 0x230 0x0 0x1>; > interrupts = <0 36 0x4>; /* Level high type */ > gpio-controller; > + little-endian; > #gpio-cells = <2>; > interrupt-controller; > #interrupt-cells = <2>; > @@ -287,6 +288,7 @@ > reg = <0x0 0x231 0x0 0x1>; > interrupts = <0 36 0x4>; /* Level high type */ > gpio-controller; > + little-endian; > #gpio-cells = <2>; > interrupt-controller; > #interrupt-cells = <2>; > @@ -297,6 +299,7 @@ > reg = <0x0 0x232 0x0 0x1>; > interrupts = <0 37 0x4>; /* Level high type */ > gpio-controller; > + little-endian; > #gpio-cells = <2>; > interrupt-controller; > #interrupt-cells = <2>; > @@ -307,6 +310,7 @@ > reg = <0x0 0x233 0x0 0x1>; > interrupts = <0 37 0x4>; /* Level high type */ > gpio-controller; > + little-endian; > #gpio-cells = <2>; > interrupt-controller; > #interrupt-cells = <2>; > -- > 2.1.0.27.g96db324 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/2] ARM: dts: ventana: Add ext-reset support
From: Tim Harvey
The Gateworks Ventana boards have a PMIC that can be used to regulate the
CPU voltage rails for DVFS support. In order to ensure this PMIC is properly
reset the watchdog needs to be configured to assert its external reset
signal.
Additionally the pad used for WDOG_B needs to be configured which we add to
iomux.
Cc: Markus Pargmann
Signed-off-by: Tim Harvey
---
arch/arm/boot/dts/imx6qdl-gw51xx.dtsi | 12
arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 12
arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 13 +
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 17 +
arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 12
arch/arm/boot/dts/imx6qdl-gw552x.dtsi | 12
6 files changed, 78 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
index 7b31fdb..d81bd72 100644
--- a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
@@ -210,6 +210,12 @@
status = "okay";
};
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ ext-reset-output;
+};
+
&iomuxc {
imx6qdl-gw51xx {
pinctrl_enet: enetgrp {
@@ -328,5 +334,11 @@
MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x1b0b0
/* OTG_PWR_EN */
>;
};
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT8__WDOG1_B 0x1b0b0
+ >;
+ };
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
index 1b66328..0d8f201 100644
--- a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
@@ -326,6 +326,12 @@
status = "okay";
};
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ ext-reset-output;
+};
+
&iomuxc {
imx6qdl-gw52xx {
pinctrl_audmux: audmuxgrp {
@@ -501,5 +507,11 @@
MX6QDL_PAD_NANDF_CS1__SD3_VSELECT 0x170f9
>;
};
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT8__WDOG1_B 0x1b0b0
+ >;
+ };
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
index 7c51839..36f9ec6 100644
--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
@@ -332,7 +332,14 @@
status = "okay";
};
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ ext-reset-output;
+};
+
&iomuxc {
+
imx6qdl-gw53xx {
pinctrl_audmux: audmuxgrp {
fsl,pins = <
@@ -508,5 +515,11 @@
MX6QDL_PAD_NANDF_CS1__SD3_VSELECT 0x170f9
>;
};
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT8__WDOG1_B 0x1b0b0
+ >;
+ };
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
index 929e0b3..0c1150f 100644
--- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
@@ -425,6 +425,17 @@
status = "okay";
};
+&wdog1 {
+ status = "disabled";
+};
+
+&wdog2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ ext-reset-output;
+ status = "okay";
+};
+
&iomuxc {
imx6qdl-gw54xx {
pinctrl_audmux: audmuxgrp {
@@ -600,5 +611,11 @@
MX6QDL_PAD_NANDF_CS1__SD3_VSELECT 0x170f9
>;
};
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_DAT3__WDOG2_B0x1b0b0
+ >;
+ };
};
};
diff --git a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
index 741f3d5..883e577 100644
--- a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
@@ -227,6 +227,12 @@
status = "okay";
};
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ ext-reset-output;
+};
+
&iomuxc {
imx6qdl-gw51xx {
pinctrl_flexcan1: flexcan1grp {
@@ -309,5 +315,11 @@
MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
>;
};
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX6QDL_PAD_DISP0_DAT8__WDOG1_B 0x1b0b0
+ >;
+ };
[PATCH v4 0/2] imx6: Implement external watchdog reset
[Rebase to next-20151105 and re-sending work done by Tim Harvey] The IMX6 watchdog supports assertion of a signal (WDOG_B) which can be pinmux'd to an external pin. This is typically used for boards that have PMIC's in control of the IMX6 power rails. In fact, failure to use such an external reset on boards with external PMIC's can result in various hangs due to the IMX6 not being fully reset [1] as well as the board failing to reset because its PMIC has not been reset to provide adequate voltate for the CPU when comming out of reset at 800Mhz when it was at 400Mhz prior to reset. This adds a new device-tree property 'ext-reset-output' to fsl-imx-wdt in order to indicate the board has such a reset and to cause the watchdog to be configured to assert WDOG_B instead of an internal reset both on a watchdog timeout and in system_restart. The second patch adds the watchdog configuration and pinmux for Gateworks Ventana boards. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333689.html Changes: v3->v4: - Rebase and test against linux-next tag next-20151105 History: v1: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/347168.html v2: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348761.html v3: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/360188.html Tim Harvey (2): watchdog: imx2_wdt: add external reset support via 'ext-reset-output' dt prop ARM: dts: ventana: Add ext-reset support .../devicetree/bindings/watchdog/fsl-imx-wdt.txt | 2 ++ arch/arm/boot/dts/imx6qdl-gw51xx.dtsi| 12 arch/arm/boot/dts/imx6qdl-gw52xx.dtsi| 12 arch/arm/boot/dts/imx6qdl-gw53xx.dtsi| 13 + arch/arm/boot/dts/imx6qdl-gw54xx.dtsi| 17 + arch/arm/boot/dts/imx6qdl-gw551x.dtsi| 12 arch/arm/boot/dts/imx6qdl-gw552x.dtsi| 12 drivers/watchdog/imx2_wdt.c | 20 ++-- 8 files changed, 98 insertions(+), 2 deletions(-) -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MAINTAINERS: update DT binding doc locations
On Thu, Nov 05, 2015 at 01:41:15PM -0600, Rob Herring wrote: > After the recent moving of DT binding documents, some maintainers entries > are stale. Update them to the new locations. > > In bindings/fb/, there were only 2 files and I'm assuming the FB > maintainers don't want to be copied on all of bindings/display/. So I've > dropped them. > > Reported-by: Thierry Reding > Cc: Thierry Reding > Cc: Jianwei Wang > Cc: Alison Wang > Cc: Philipp Zabel > Cc: Mark Yao > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Cc: Jean-Christophe Plagniol-Villard > Cc: Tomi Valkeinen > Cc: James Hogan > Cc: Hans de Goede > Cc: Vineet Gupta > Signed-off-by: Rob Herring Acked-by: James Hogan [metag] Thanks! James > @@ -6855,6 +6854,7 @@ S: Supported > F: arch/metag/ > F: Documentation/metag/ > F: Documentation/devicetree/bindings/metag/ > +F: Documentation/devicetree/bindings/interrupt-controller/img,* > F: drivers/clocksource/metag_generic.c > F: drivers/irqchip/irq-metag.c > F: drivers/irqchip/irq-metag-ext.c signature.asc Description: Digital signature
Re: [PATCH RESEND 1/4] dt-bindings: add SMP enable-method for Broadcom NSP
Hi Rob, On 15-11-05 12:48 PM, Rob Herring wrote: On Thu, Nov 05, 2015 at 12:51:18AM -0500, Kapil Hali wrote: Add a compatible string "brcm,bcm-nsp-smp" for Broadcom's Northstar Plus CPU to the 32-bit ARM CPU device tree binding documentation file and create a new binding documentation for Northstar Plus CPU pen-release mechanism. Signed-off-by: Kapil Hali --- .../bindings/arm/bcm/brcm,nsp-cpu-method.txt | 36 ++ Documentation/devicetree/bindings/arm/cpus.txt | 1 + 2 files changed, 37 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt new file mode 100644 index 000..8506da7 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt @@ -0,0 +1,36 @@ +Broadcom Northstar Plus SoC CPU Enable Method +- +This binding defines the enable method used for starting secondary +CPUs in the following Broadcom SoCs: + BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312 + +The enable method is specified by defining the following required +properties in the "cpus" device tree node: + - enable-method = "brcm,bcm-nsp-smp"; This is supposed to be per core. + - secondary-boot-reg = <...>; What happens with more than 2 cores? I'm pretty sure nothing - all of these SoCs have 1 or 2 cores. Regards, Scott -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 1/4] dt-bindings: add SMP enable-method for Broadcom NSP
On Thu, Nov 05, 2015 at 12:51:18AM -0500, Kapil Hali wrote:
> Add a compatible string "brcm,bcm-nsp-smp" for Broadcom's
> Northstar Plus CPU to the 32-bit ARM CPU device tree binding
> documentation file and create a new binding documentation for
> Northstar Plus CPU pen-release mechanism.
>
> Signed-off-by: Kapil Hali
> ---
> .../bindings/arm/bcm/brcm,nsp-cpu-method.txt | 36
> ++
> Documentation/devicetree/bindings/arm/cpus.txt | 1 +
> 2 files changed, 37 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
>
> diff --git
> a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
> b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
> new file mode 100644
> index 000..8506da7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
> @@ -0,0 +1,36 @@
> +Broadcom Northstar Plus SoC CPU Enable Method
> +-
> +This binding defines the enable method used for starting secondary
> +CPUs in the following Broadcom SoCs:
> + BCM58522, BCM58525, BCM58535, BCM58622, BCM58623, BCM58625, BCM88312
> +
> +The enable method is specified by defining the following required
> +properties in the "cpus" device tree node:
> + - enable-method = "brcm,bcm-nsp-smp";
This is supposed to be per core.
> + - secondary-boot-reg = <...>;
What happens with more than 2 cores?
> +The secondary-boot-reg property is a u32 value that specifies the
> +physical address of the register used to request the ROM holding pen
> +code release a secondary CPU.
> +
> +Example:
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + enable-method = "brcm,bcm-nsp-smp";
> + secondary-boot-reg = <0x042c>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + next-level-cache = <&L2>;
> + reg = <0>;
> + };
> +
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a9";
> + next-level-cache = <&L2>;
> + reg = <1>;
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
> b/Documentation/devicetree/bindings/arm/cpus.txt
> index 91e6e5c..6abe3f3 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -191,6 +191,7 @@ nodes to be present and contain the properties described
> below.
> "allwinner,sun8i-a23"
> "arm,psci"
> "brcm,brahma-b15"
> + "brcm,bcm-nsp-smp"
> "marvell,armada-375-smp"
> "marvell,armada-380-smp"
> "marvell,armada-390-smp"
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] watchdog: add Alphascale asm9260-wdt driver
On Thu, Nov 05, 2015 at 10:06:56AM +0100, Oleksij Rempel wrote:
> Add WD support for Alphascale asm9260 SoC. This driver
> provide support for different function modes:
> - HW mode to trigger SoC reset on timeout
> - SW mode do soft reset if needed
> - DEBUG mode
>
> Optional support for stopping watchdog. If reset binding are not provided
> this driver will work in nowayout mode.
>
> Signed-off-by: Oleksij Rempel
> ---
> .../bindings/watchdog/alphascale-asm9260.txt | 39 ++
It is preferred that bindings are a separate patch.
> drivers/watchdog/Kconfig | 9 +
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/asm9260_wdt.c | 415
> +
> 4 files changed, 464 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/watchdog/alphascale-asm9260.txt
> create mode 100644 drivers/watchdog/asm9260_wdt.c
>
> diff --git
> a/Documentation/devicetree/bindings/watchdog/alphascale-asm9260.txt
> b/Documentation/devicetree/bindings/watchdog/alphascale-asm9260.txt
> new file mode 100644
> index 000..6e54d1f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/alphascale-asm9260.txt
> @@ -0,0 +1,39 @@
> +Alphascale asm9260 Watchdog timer
> +
> +Required properties:
> +
> +- compatible : should be "alphascale,asm9260-wdt".
> +- reg : Specifies base physical address and size of the registers.
> +- clocks : the clocks feeding the watchdog timer. See clock-bindings.txt
> +- clock-names : should be set to
> + "mod" - source for tick counter.
> + "ahb" - ahb gate.
> +
> +Optional properties:
> +- resets : phandle pointing to the system reset controller with correct
> + reset line index for watchdog controller reset. This propertie is
s/propertie/property/
> + required if you need to disable "nowayout" and it neened only with
> + CONFIG_WATCHDOG_NOWAYOUT=n.
The DT cannot depend on certain kernel configs.
> + Without reseting this WD controller, it is not possible to stop
s/reseting/resetting/
> + counter.
> +- reset-names : should be set to "wdt_rst" if "resets" is used.
> +- timeout-sec : shall contain the default watchdog timeout in seconds,
> + if unset, the default timeout is 30 seconds.
> +- alphascale,mode : tree modes are supported
s/tree/three/
> + "hw" - hw reset (defaul).
s/defaul/default/
> + "sw" - sw reset.
> + "debug" - no action is taken.
Seems like this should be a generic wdog property.
> +
> +Example:
> +
> +watchdog0: watchdog@80048000 {
> + compatible = "alphascale,asm9260-wdt";
> + reg = <0x80048000 0x10>;
> + clocks = <&acc CLKID_SYS_WDT>, <&acc CLKID_AHB_WDT>;
> + clock-names = "mod", "ahb";
> + interrupts = <55>;
> + resets = <&rst WDT_RESET>;
> + reset-names = "wdt_rst";
> + timeout-sec = <30>;
> + alphascale,mode = "hw";
> +};
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index c68edc1..cc5f675 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -173,6 +173,15 @@ config ARM_SP805_WATCHDOG
> ARM Primecell SP805 Watchdog timer. This will reboot your system when
> the timeout is reached.
>
> +config ASM9260_WATCHDOG
> + tristate "Alphascale ASM9260 watchdog"
> + depends on MACH_ASM9260
> + depends on OF
> + select WATCHDOG_CORE
> + help
> + Watchdog timer embedded into Alphascale asm9260 chips. This will
> reboot your
> + system when the timeout is reached.
> +
> config AT91RM9200_WATCHDOG
> tristate "AT91RM9200 watchdog"
> depends on SOC_AT91RM9200 && MFD_SYSCON
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 0c616e3..bd7b0cd 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
>
> # ARM Architecture
> obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
> +obj-$(CONFIG_ASM9260_WATCHDOG) += asm9260_wdt.o
> obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
> obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
> obj-$(CONFIG_CADENCE_WATCHDOG) += cadence_wdt.o
> diff --git a/drivers/watchdog/asm9260_wdt.c b/drivers/watchdog/asm9260_wdt.c
> new file mode 100644
> index 000..9f2c321
> --- /dev/null
> +++ b/drivers/watchdog/asm9260_wdt.c
> @@ -0,0 +1,415 @@
> +/*
> + * Watchdog driver for Alphascale ASM9260.
> + *
> + * Copyright (c) 2014 Oleksij Rempel
> + *
> + * Licensed under GPLv2 or later.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define CLOCK_FREQ 100
> +
> +/* Watchdog Mode register */
> +#define HW_WDMOD 0x00
> +/* Wake interrupt. Set by HW, can't be cleared. */
> +#define BM_MOD_WDINT BIT(3)
> +/* This bit set if timeout reached. Cleared by SW. */
> +
Re: [PATCH 2/7] doc:bindings:Document for mtcmos regulator on hi6220 SoC
On Thu, Nov 05, 2015 at 09:34:43PM +0800, Chen Feng wrote:
> Add Document for mtcmos driver on hi6220 SoC
>
> Signed-off-by: Chen Feng
> Signed-off-by: Fei Wang
> ---
> .../bindings/regulator/hisilicon,hi6220-mtcmos.txt | 32
> ++
> 1 file changed, 32 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/regulator/hisilicon,hi6220-mtcmos.txt
>
> diff --git
> a/Documentation/devicetree/bindings/regulator/hisilicon,hi6220-mtcmos.txt
> b/Documentation/devicetree/bindings/regulator/hisilicon,hi6220-mtcmos.txt
> new file mode 100644
> index 000..bb06e1b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/hisilicon,hi6220-mtcmos.txt
> @@ -0,0 +1,32 @@
> +Hi6220 mtcmos Voltage regulators
> +
> +Required parent device properties:
> +- compatible: Must be "hisilicon,hi6220-mtcmos-driver"
What does "driver" refer to?
> +- hisilicon,mtcmos-steady-us: The time to wait for power steady
Wouldn't regulator-enable-ramp-delay be equivalent?
> +- hisilicon,mtcmos-sc-on-base: address of mtcmos on hi6220 SoC
> +
> +Required child device properties:
> +- regulator-name: The name of mtcmos
> +- hisilicon,ctrl-regs: Offset of ctrl-regs
> +- hisilicon,ctrl-data: The bit to ctrl the regulator
> +
> +Example:
> +mtcmos {
> +compatible = "hisilicon,hi6220-mtcmos-driver";
> +hisilicon,mtcmos-steady-us = <10>;
> +hisilicon,mtcmos-sc-on-base = <0xf780>;
> +hisilicon,mtcmos-acpu-on-base = <0xf65a>;
> +
> +mtcmos1: regulator@a1{
> +regulator-name = "G3D_PD_VDD";
> +regulator-compatible = "mtcmos1";
regulator-compatible is deprecated. Please drop.
> +hisilicon,ctrl-regs = <0x830 0x834 0x83c>;
> +hisilicon,ctrl-data = <1 0x1>;
> +};
> +mtcmos2: regulator@a2{
> +regulator-name = "SOC_MED";
> +regulator-compatible = "mtcmos2";
> +hisilicon,ctrl-regs = <0x830 0x834 0x83c>;
> +hisilicon,ctrl-data = <2 0x1>;
> +};
> +};
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 0/4] SMP support for Broadcom NSP
On 11/05/2015 10:34 AM, Russell King - ARM Linux wrote:
> On Thu, Nov 05, 2015 at 12:51:17AM -0500, Kapil Hali wrote:
>> Hi,
>>
>> This series adds SMP support for Broadcom's Northstar Plus SoC.
>>
>> There are similar SMP enablement methods for many ARMv7 bsed SoCs.
>> BCM NSP SoC, has a typical such mechanism - after power-on, the
>> secondary core is held in a standby state, primary core provides a
>> startup address for the secondary core and wakes it up. Booting of
>> the secondary core is serialized using pen_release global variable.
>
> Why do you need the pen_release stuff? The above implies that you
> have only one secondary core, and you can control when it comes out
> of standby state.
>
> Please, don't assume that the pen_release stuff is any kind of recommended
> or standardised system. It isn't. It's a hack for ARMs evaluation
> platforms.
>
I tried to remove the pen code because I also thought/hoped that it is
useless, but the 2. CPU did not boot any more after I removed it. I do
not know the internals of SoC, but it looks like this is needed.
I described it here:
http://www.spinics.net/lists/arm-kernel/msg452178.html
I removed this comparison and the jump afterwards ("cmp r7, r0") and
the 2. CPU did not boot any more. Is this pen stuff some kind of
workaround for some bug in the silicon?
Hauke
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/10] of: Add vendor prefix for General Electric Company
On Thu, Nov 05, 2015 at 01:13:41PM -0500, Akshay Bhat wrote: > This patch adds vendor prefix for General Electric Company > > Signed-off-by: Akshay Bhat > --- > 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 2b3c5ac..71dcbd5 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -87,6 +87,7 @@ fcs Fairchild Semiconductor > firefly Firefly > focaltechFocalTech Systems Co.,Ltd > fsl Freescale Semiconductor > +ge General Electric Company This is short too, but it is well known and the stock ticker so: Acked-by: Rob Herring > GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc. > gef GE Fanuc Intelligent Platforms Embedded Systems, Inc. > geniatechGeniatech, Inc. > -- > 2.6.2 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/10] of: Add vendor prefix for Advantech Corporation
On Thu, Nov 05, 2015 at 01:13:35PM -0500, Akshay Bhat wrote: > This patch adds vendor prefix for Advantech Corporation. > > Website: http://www.advantech.com/ > Signed-off-by: Akshay Bhat > --- > 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 55df1d4..2b3c5ac 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -10,6 +10,7 @@ ad Avionic Design GmbH > adapteva Adapteva, Inc. > adh AD Holdings Plc. > adi Analog Devices, Inc. > +adv Advantech Corporation adv is a bit short. I think it would be better to go with "advantech". Rob > aeroflexgaisler Aeroflex Gaisler AB > al Annapurna Labs > allwinnerAllwinner Technology Co., Ltd. > -- > 2.6.2 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/4] of: overlay: add per overlay sysfs attributes
Hi Rob,
> On Nov 5, 2015, at 21:52 , Rob Herring wrote:
>
> On Thu, Oct 22, 2015 at 11:15 AM, Pantelis Antoniou
> wrote:
>> Hi Rob,
>>
>>> On Oct 22, 2015, at 00:52 , Rob Herring wrote:
>>>
>>> On Wed, Oct 21, 2015 at 2:37 PM, Pantelis Antoniou
>>> wrote:
Hi Rob,
> On Oct 21, 2015, at 00:54 , Rob Herring wrote:
>
> On Tue, Oct 20, 2015 at 4:11 PM, Pantelis Antoniou
> wrote:
>> Hi Rob,
>>
>>> On Oct 21, 2015, at 00:04 , Rob Herring wrote:
>>>
>>> On Tue, Oct 20, 2015 at 2:13 PM, Pantelis Antoniou
>>> wrote:
* A per overlay can_remove sysfs attribute that reports whether
the overlay can be removed or not due to another overlapping overlay.
* A target sysfs attribute listing the target of each fragment,
in a group named after the name of the fragment.
>
> [...]
>
@@ -255,6 +278,17 @@ err_fail:
return -EINVAL;
}
+static ssize_t target_show(struct kobject *kobj,
+ struct fragment_attribute *fattr, char *buf)
+{
+ struct of_overlay_info *ovinfo = fattr->ovinfo;
+
+ return snprintf(buf, PAGE_SIZE, "%s\n",
+ of_node_full_name(ovinfo->target));
>>>
>>> This can be a link to the node itself, can't it?
>>>
>>
>> Yes. Do you want it like this?
>
> Yes, hence the suggestion. Unless you see some reason why not.
>
Nope, can’t be done. The sysfs API only allows linking one kobj to another.
The kobj is the overlay but the target is in the fragment attribute group.
>>>
>>> Can't we make the fragments kobj's as well?
>>>
>>
>> We could, but it break the mental model of what a kobj should represent.
>> An overlay is an object which can be address, a fragment is never directly
>> exposed.
>
> But you are exposing fragments as there is a directory for each one.
>
> Overlays are just logical collections of fragments. You could go as
> far to say overlays don't need to be exposed at all and only fragments
> need to be (not that we should). We already have overlays and nodes as
> kobjs, so I don't think fragments as kobjs breaks the mental model.
>
I disagree; fragments are merely an internal implementation detail, namely that
an overlay
is comprised of a collection of fragments.
Being able to address fragments individually, which is what making a fragment a
kobj does,
conceptually, is not making sense.
We are being driven to consider having them as kobjs as a consequence of the
gaps in the
sysfs internal kernel API, that is that we can only make links between kobjs’
only not in
arbitrary points from one sysfs directory to another.
>> TBH a link attribute is indeed better than a path attribute, but marginally
>> so.
>> It’s not worth the trouble IMO.
>
> It is just an ABI we have to support forever…
>
I don’t think that’s that a big deal IMO. Following a link is no different than
reading the path attribute.
> Rob
Regards
— Pantelis
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] dt-bindings: sound: Add DT bindings for Broadcom Cygnus audio
Hi Mark, On 11/4/2015 6:07 AM, Mark Brown wrote: On Mon, Nov 02, 2015 at 02:11:23PM -0800, Simran Rai wrote: +- channel-group: Surround sound grouping that controls which channel + outputs belong to a group, specifically useful in Multi-channel + Interfaces grouping of serial port. In multi-channel stereo, use + "2_0", in 3.1 multi-channel grouping, use "3_1" and in 5.1 + multi-channel grouping, use "5_1". I don't really understand what this means or why this is not runtime configured. By runtime configured, do you mean passing the channel grouping through machine file? Is there any specific callback that I can use? I will implement your suggestions from other patches too and send out next revision by early next week. Thanks, Simran -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 3/4] of: overlay: add per overlay sysfs attributes
On Thu, Oct 22, 2015 at 11:15 AM, Pantelis Antoniou
wrote:
> Hi Rob,
>
>> On Oct 22, 2015, at 00:52 , Rob Herring wrote:
>>
>> On Wed, Oct 21, 2015 at 2:37 PM, Pantelis Antoniou
>> wrote:
>>> Hi Rob,
>>>
On Oct 21, 2015, at 00:54 , Rob Herring wrote:
On Tue, Oct 20, 2015 at 4:11 PM, Pantelis Antoniou
wrote:
> Hi Rob,
>
>> On Oct 21, 2015, at 00:04 , Rob Herring wrote:
>>
>> On Tue, Oct 20, 2015 at 2:13 PM, Pantelis Antoniou
>> wrote:
>>> * A per overlay can_remove sysfs attribute that reports whether
>>> the overlay can be removed or not due to another overlapping overlay.
>>>
>>> * A target sysfs attribute listing the target of each fragment,
>>> in a group named after the name of the fragment.
[...]
>>> @@ -255,6 +278,17 @@ err_fail:
>>> return -EINVAL;
>>> }
>>>
>>> +static ssize_t target_show(struct kobject *kobj,
>>> + struct fragment_attribute *fattr, char *buf)
>>> +{
>>> + struct of_overlay_info *ovinfo = fattr->ovinfo;
>>> +
>>> + return snprintf(buf, PAGE_SIZE, "%s\n",
>>> + of_node_full_name(ovinfo->target));
>>
>> This can be a link to the node itself, can't it?
>>
>
> Yes. Do you want it like this?
Yes, hence the suggestion. Unless you see some reason why not.
>>>
>>> Nope, can’t be done. The sysfs API only allows linking one kobj to another.
>>> The kobj is the overlay but the target is in the fragment attribute group.
>>
>> Can't we make the fragments kobj's as well?
>>
>
> We could, but it break the mental model of what a kobj should represent.
> An overlay is an object which can be address, a fragment is never directly
> exposed.
But you are exposing fragments as there is a directory for each one.
Overlays are just logical collections of fragments. You could go as
far to say overlays don't need to be exposed at all and only fragments
need to be (not that we should). We already have overlays and nodes as
kobjs, so I don't think fragments as kobjs breaks the mental model.
> TBH a link attribute is indeed better than a path attribute, but marginally
> so.
> It’s not worth the trouble IMO.
It is just an ABI we have to support forever...
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] MAINTAINERS: update DT binding doc locations
After the recent moving of DT binding documents, some maintainers entries are stale. Update them to the new locations. In bindings/fb/, there were only 2 files and I'm assuming the FB maintainers don't want to be copied on all of bindings/display/. So I've dropped them. Reported-by: Thierry Reding Cc: Thierry Reding Cc: Jianwei Wang Cc: Alison Wang Cc: Philipp Zabel Cc: Mark Yao Cc: Benjamin Gaignard Cc: Vincent Abriou Cc: Jean-Christophe Plagniol-Villard Cc: Tomi Valkeinen Cc: James Hogan Cc: Hans de Goede Cc: Vineet Gupta Signed-off-by: Rob Herring --- MAINTAINERS | 19 ++- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 9f6685f..e2aa973 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3577,7 +3577,7 @@ S:Maintained F: drivers/gpu/drm/drm_panel.c F: drivers/gpu/drm/panel/ F: include/drm/drm_panel.h -F: Documentation/devicetree/bindings/panel/ +F: Documentation/devicetree/bindings/display/panel/ INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets) M: Daniel Vetter @@ -3609,15 +3609,15 @@ M: Alison Wang L: dri-de...@lists.freedesktop.org S: Supported F: drivers/gpu/drm/fsl-dcu/ -F: Documentation/devicetree/bindings/video/fsl,dcu.txt -F: Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt +F: Documentation/devicetree/bindings/display/fsl,dcu.txt +F: Documentation/devicetree/bindings/display/panel/nec,nl4827hc19_05b.txt DRM DRIVERS FOR FREESCALE IMX M: Philipp Zabel L: dri-de...@lists.freedesktop.org S: Maintained F: drivers/gpu/drm/imx/ -F: Documentation/devicetree/bindings/drm/imx/ +F: Documentation/devicetree/bindings/display/imx/ DRM DRIVERS FOR NVIDIA TEGRA M: Thierry Reding @@ -3630,7 +3630,7 @@ F:drivers/gpu/drm/tegra/ F: drivers/gpu/host1x/ F: include/linux/host1x.h F: include/uapi/drm/tegra_drm.h -F: Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt +F: Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt DRM DRIVERS FOR RENESAS M: Laurent Pinchart @@ -3647,7 +3647,7 @@ M:Mark Yao L: dri-de...@lists.freedesktop.org S: Maintained F: drivers/gpu/drm/rockchip/ -F: Documentation/devicetree/bindings/video/rockchip* +F: Documentation/devicetree/bindings/display/rockchip* DRM DRIVERS FOR STI M: Benjamin Gaignard @@ -3656,7 +3656,7 @@ L:dri-de...@lists.freedesktop.org T: git http://git.linaro.org/people/benjamin.gaignard/kernel.git S: Maintained F: drivers/gpu/drm/sti -F: Documentation/devicetree/bindings/gpu/st,stih4xx.txt +F: Documentation/devicetree/bindings/display/st,stih4xx.txt DSBR100 USB FM RADIO DRIVER M: Alexey Klimov @@ -4342,7 +4342,6 @@ Q: http://patchwork.kernel.org/project/linux-fbdev/list/ T: git git://git.kernel.org/pub/scm/linux/kernel/git/plagnioj/linux-fbdev.git S: Maintained F: Documentation/fb/ -F: Documentation/devicetree/bindings/fb/ F: drivers/video/ F: include/video/ F: include/linux/fb.h @@ -6855,6 +6854,7 @@ S:Supported F: arch/metag/ F: Documentation/metag/ F: Documentation/devicetree/bindings/metag/ +F: Documentation/devicetree/bindings/interrupt-controller/img,* F: drivers/clocksource/metag_generic.c F: drivers/irqchip/irq-metag.c F: drivers/irqchip/irq-metag-ext.c @@ -9443,7 +9443,7 @@ SIMPLEFB FB DRIVER M: Hans de Goede L: linux-fb...@vger.kernel.org S: Maintained -F: Documentation/devicetree/bindings/video/simple-framebuffer.txt +F: Documentation/devicetree/bindings/display/simple-framebuffer.txt F: drivers/video/fbdev/simplefb.c F: include/linux/platform_data/simplefb.h @@ -10072,6 +10072,7 @@ M: Vineet Gupta S: Supported F: arch/arc/ F: Documentation/devicetree/bindings/arc/* +F: Documentation/devicetree/bindings/interrupt-controller/snps,arc* F: drivers/tty/serial/arc_uart.c T: git git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IIO device indexing issue
On 04/11/15 18:53, Vesa Jääskeläinen wrote:
> On 04/11/15 11:38, Lars-Peter Clausen wrote:
>> On 11/02/2015 07:47 PM, Vesa Jääskeläinen wrote:
>>> Hi,
>>>
>>> When we were using kernel 3.2 and with that board files we just got IIO
>>> devices with static order so that we knew exactly what iio:device0 is.
>>>
>>> Now with device tree that order is not so static anymore especially when
>>> using device overlays (have not yet tried that thou). If there would be
>>> deferred probe for the device then if we have multiple iio:device's then
>>> those could in theory be in any order.
>>>
>>> In example libiio uses iio device index to open the IIO device. So the
>>> problem is to know what iio:device is what.
>>>
>>> If we look files under /sys/bus/iio/iio:deviceX. They do not reveal what
>>> device this is (especially if there are multiple device of same type). There
>>> does not seem to be a way to give custom name for the iio device from device
>>> tree that could have been used as a cue.
>>>
>>> Device tree aliases kinda sounded a good idea to try. Eg. define adc0 alias
>>> and then link it to actual device node in tree.
>>>
>>> Aliases could be found under /proc/device-tree/aliases. Looking at it shows
>>> what device tree node it is. However there does not seem to be actual link
>>> from any /proc/device-tree entries to kernel drivers exposed under sysfs.
>>> And even the path components in device tree are not in same format as in
>>> sysfs. So there is no 1:1 mapping possible here.
>>>
>>> IIO devices in /sys/bus/iio/iio:deviceX seem to be symlinks to actual
>>> devices under /sys/devices and from there is physical path to the device and
>>> under that the IIO device with the same name as is under /sys/bus/iio.
>>>
>>> So in theory we could make a mapping configuration file that specifies
>>> logical name for iio device and then physical parent path for the device and
>>> then find under it iio:device* files to determine what is the iio device
>>> index for this physical device. Then open IIO device with that index in
>>> example with libiio. Sounds a bit complex?
>>>
>>> So did we miss something on how this should be defined/accessed or is there
>>> a slight issue here on how to identify iio devices?
>>>
>>> Don't know how device tree overlays affect this if we first load device tree
>>> overlay with some configuration and then unload it and load another one with
>>> different configuration.
>> Hi,
>>
>> Yes, excellent analysis. This is a real issue. As you said there is no
>> guarantee that the IIO device numbers are stable, they are assigned in the
>> order the devices are registered. If the device are registered in a
>> different order for whatever reason the numbers will change. You can use
>> readlink on the IIO device in /sys/bus/iio/devices to get its position in
>> the global device topology and be able to tell what the parent device is,
>> but this path might not be completely stable either though. E.g. if your
>> device is on a I2C bus and the number of the I2C bus is dynamically assigned
>> it might change when the probe order changes.
>>
>> Alias seem to be one way to solve this issue. The big question remains is
>> how to communicate the alias to userspace. For other device classes the
>> alias index is used as the device index e.g. a device with alias i2c0 ends
>> up being the i2c adapter with index 0. But with IIO where we support a wide
>> range of different devices that does not really work. E.g. what to do if you
>> have adc0 and dac0 as aliases for different devices. So you'd need a
>> different way to expose the alias.
>>
>> Some bindings also use the "label" property to assign a unique name to node.
>> But again the same issue how to expose that information to applications.
>>
> To continue from this "label" property idea I was wondering if we
> would add it as new optional(?) file node for IIO devices.>
> One could then specify it like:
>
> tscadc: tscadc@44e0d000 {
> compatible = "ti,am3359-tscadc";
> ...
> am335x_adc: adc {
> compatible = "ti,am3359-adc";
> ...
> label = "Port A";
> };
> };
>
> And this would generate file /sys/bus/iio/iio:deviceX/label with
> contents of "Port A".
>
> Then during the application startup it would just need to scan all
> devices under /sys/bus/iio and determine what labelled device it
> wants to use.
>
> It would be up to device's developer to determine what labels to use
> in their designs. This would not break ABI and would be just an
> extension for it.
>
> One could also auto-assign label "am335x_adc" in this case too. But
> if you include existing arch device tree then changing label in top
> level is kinda a bit annoying as you would then need to duplicate all
> properties with another label and disable arch device tree's
> settings. Could cause also conflict if there are references elsewhere
> to existing arch nodes.
>
> Having following in device's device tree file would allow one to
> override label or just
Re: [PATCH 2/2] iio: health: Add driver for the TI AFE4404 heart monitor
Lars, Hartmut, Peter, This is becoming a really involved ABI discussion so I'd like some input on this if any of you have the time. I'm going to be busy now until at least the weekend... On 04/11/15 21:17, Andrew F. Davis wrote: > On 11/04/2015 01:40 PM, Jonathan Cameron wrote: >> On 02/11/15 20:37, Andrew F. Davis wrote: >>> On 11/01/2015 02:52 PM, Jonathan Cameron wrote: On 31/10/15 16:31, Andrew F. Davis wrote: > Add driver for the TI AFE4404 heart rate monitor and pulse oximeter. > This device detects reflected LED light fluctuations and presents an ADC > value to the user space for further signal processing. > > Data sheet located here: > http://www.ti.com/product/AFE4404/datasheet > > Signed-off-by: Andrew F. Davis Hi Andrew, Good to see this resurface. It's a fascinating little device. Anyhow, most of the interesting bit in here is unsuprisingly concerned with the interface. I know we went round a few loops of this before but it still feels like we haven't worked out to handle it well. I would like as much input as we can get on this as inevitablly it will have repercussions outside this driver. Your approach of hammering out descriptive sysfs attributes is a good starting point but we need to work towards a formal description that can be generalised. Whilst there are not many similar devices out there to this one, I suspect there are a few and more may well show up in future. >>> >>> Yeah, I'm working on brining up drivers for them now :) >> cool >>> The escence of my rather roundabout response inline is that I'm suggesting adding a new channel type to represent light transmission, taking the analogous case of proximity devices in which we are looking at light reflection. I've also taken the justification we use for illuminance vs intensity readings for two sensor ALS sensors as a precident for having compound channels of a different type to the 'raw' data that feeds them. Hence I propose something along the lines of: in_intensityX_raw (raw channel value with the led on) in_intensityX_ambient_raw (raw channel value with the led off) >>> >>> I'm not sure, I know it may be too late for a lot of drivers but putting >>> the 'X' >>> against the 'intensity' works for devices like ADCs/DACs with a simple list >>> of numeric channels, but for any other device with named channels this will >>> become very inconsistent, especially when adding modified channels and >>> differential channels. >> Sadly its ABI now so we can't realistically change it. We can extend, we >> can't >> replace (we we can over the course of a lot of years but that's a nightmare). >> >>> >>> For example: >>> >>> in_intensity5_name_ambient-2_mean_raw >> The oddity here is that in your case the device in interacting with a >> stimulus >> output. Normally the index reflects an actual sensor. We are kind of >> bludgeoning >> it in. The only equivalently nasty case I know of is touch screens where >> different >> resistances are being connected - from a generic point of view those are a >> nightmare >> as well (as every implementation does it differently). > > Yeah, this part really doesn't fit the mold for this subsystem, or > any really, hwmon, input, were also considered, but the plan is still > to attempt to shoehorn it in to this one, so hopefully you can bear with me > on all these oddities :) Much as it irritates my sense of neat and tidy I guess that if we do end up with an ABI for this that we don't like later it isn't the end of the world as I doubt we'll be inundated with hundreds of these sensors. However, lets keep the naming within reason to how we would naturally extend the ABI. Having thought more on these differential channels, do we really need to have them explicitly as differential channels at all? Perhaps we are better off with in_intensity0_led1_raw in_intensity1_ambient_raw in_intensity2_transmitted_led1_raw in_intensity3_led2_raw in_intensity4_ambient_raw in_intensity5_transmitted_led2_raw in_intenisty6_led3_raw in_intenisty7_ambient_raw in_intensity8_transmitted_led3_raw in_intensity9_transmitted_led1_meanfiltered_raw (and it does want to be explicitly meanfiltered and not mean which would imply the mean over all time) in_intensity10_transmitted_led2_meanfiltered_raw It's simple, descriptive and almost fits in the current ABI - you could even blugeon it in easily enough except for the mean filtered case. In many ways this is your naming proposal after all. I really don't like the mean filtered case. My suggestion on that long term is we need to handle 'copies' of channels that are filtered. These do occur elsewhere. I'm increasingly coming around to thinking we need additional descriptive elements in additional attributes to specifically indicate this channel is a filtered version of this othe
Re: [PATCH 2/6] ARM: dts: imx: Add Advantech BA-16 Qseven module
Hi Lucas,
Thanks for the feedback :) I have submitted a v2 patch incorporating
your feedback.
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-November/383276.html
On 11/02/2015 03:57 AM, Lucas Stach wrote:
Am Donnerstag, den 29.10.2015, 19:16 -0400 schrieb Akshay Bhat:
There is a suspiciously high number of always-on regulators in the list
above. Are they really required to be powered on always, or are we
lacking supplies on some of the devices below?
Agree, many of them do not need be always-on, fixed in v2
+ };
+ };
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ imx6q-ba16 {
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_4__GPIO1_IO040x8000
/* uSDHC2 CD */
+ MX6QDL_PAD_NANDF_CS0__GPIO6_IO11 0x8000
/* uSDHC4 CD */
+ MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x8000
/* uSDHC4 SDIO PWR */
+ MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x8000
/* uSDHC4 SDIO WP */
+ MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x8000
/* uSDHC4 SDIO LED */
+ MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x8000
/* SPI1 CS */
+ MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x8000
/* PCIe Reset */
+ MX6QDL_PAD_GPIO_5__GPIO1_IO050x8000
/* PCIe Wake */
+ MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x130b0
/* FEC CLK */
+ MX6QDL_PAD_ENET_TX_EN__GPIO1_IO28 0x8000
/* FEC Reset */
+ MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x8000
/* GPIO0 */
+ MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x8000
/* GPIO1 */
+ MX6QDL_PAD_NANDF_D2__GPIO2_IO02 0x8000
/* GPIO2 */
+ MX6QDL_PAD_NANDF_D3__GPIO2_IO03 0x8000
/* GPIO3 */
+ MX6QDL_PAD_NANDF_D4__GPIO2_IO04 0x8000
/* GPIO4 */
+ MX6QDL_PAD_NANDF_D5__GPIO2_IO05 0x8000
/* GPIO5 */
+ MX6QDL_PAD_NANDF_D6__GPIO2_IO06 0x8000
/* GPIO6 */
+ MX6QDL_PAD_NANDF_D7__GPIO2_IO07 0x8000
/* GPIO7 */
+ MX6QDL_PAD_NANDF_CLE__GPIO6_IO07 0x8000
/* CAM_PWDN */
+ MX6QDL_PAD_GPIO_2__GPIO1_IO020x8000
/* CAM_RST */
+ MX6QDL_PAD_GPIO_9__WDOG1_B 0x8000
/* Watchdog out */
+ MX6QDL_PAD_GPIO_16__GPIO7_IO11 0x8000
/* HUB_RESET */
+ MX6QDL_PAD_GPIO_18__GPIO7_IO13 0x8000
/* PMIC Interrupt */
+ MX6QDL_PAD_GPIO_19__GPIO4_IO05 0x8000
/* AR8033 Interrupt */
+ MX6QDL_PAD_KEY_ROW2__GPIO4_IO11 0x8000
/* SUS_S3_OUT */
+ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x8000
/* BLEN_OUT */
+ MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x8000
/* LVDS_PPEN_OUT */
+ MX6QDL_PAD_KEY_COL2__GPIO4_IO10 0x8000
/* RTC_INT */
Please don't overuse the hog group but add pins that are related to a
specific device to the pinmux group of that device. USDHC, SPI, PCIe,
FEC are the obvious examples from the list above.
Makes sense, have moved many of the entries from hog group into their
relevant groups in v2. There are a couple more which can be moved but
are dependent on new device tree nodes/drivers that I am yet to submit.
+
+&pcie {
+ power-on-gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
There is no such thing as a power-on-gpio in mainline Linux.
Good catch, was a left over from 3.14 kernel. Fixed in v2.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 01/10] of: Add vendor prefix for Advantech Corporation
This patch adds vendor prefix for Advantech Corporation. Website: http://www.advantech.com/ Signed-off-by: Akshay Bhat --- 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 55df1d4..2b3c5ac 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -10,6 +10,7 @@ adAvionic Design GmbH adapteva Adapteva, Inc. adhAD Holdings Plc. adiAnalog Devices, Inc. +advAdvantech Corporation aeroflexgaislerAeroflex Gaisler AB al Annapurna Labs allwinner Allwinner Technology Co., Ltd. -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 10/10] ARM: dts: imx6q-ba16: Cleanup pinctrl and LDO
Incorporate feedback from Lucas Stash
- Move entries from pinctrl_hog to relevant groups
- Remove unused PCIe power-on-gpio entry
- Remove always-on from regulators that do not need to be always-on
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/imx6q-ba16.dtsi | 85 +--
1 file changed, 55 insertions(+), 30 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-ba16.dtsi
b/arch/arm/boot/dts/imx6q-ba16.dtsi
index 3d47039..d0c4568 100644
--- a/arch/arm/boot/dts/imx6q-ba16.dtsi
+++ b/arch/arm/boot/dts/imx6q-ba16.dtsi
@@ -2,7 +2,7 @@
* Support for imx6 based Advantech DMS-BA16 Qseven module
*
* Copyright 2015 Timesys Corporation.
- * Copyright 2015 GE Healthcare.
+ * Copyright 2015 General Electric Company
*
* The code contained herein is licensed under the GNU General Public
* License. You may obtain a copy of the GNU General Public License
@@ -73,6 +73,8 @@
};
backlight {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_display>;
compatible = "pwm-backlight";
pwms = <&pwm1 0 500>;
brightness-levels = < 0 1 2 3 4 5 6 7 8 9
@@ -176,6 +178,8 @@
pmic@58 {
compatible = "dlg,da9063";
reg = <0x58>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic>;
interrupt-parent = <&gpio7>;
interrupts = <13 IRQ_TYPE_LEVEL_LOW>;
@@ -245,43 +249,31 @@
vdd_ldo5: ldo5 {
regulator-min-microvolt = <90>;
regulator-max-microvolt = <360>;
- regulator-always-on;
- regulator-boot-on;
};
vdd_ldo6: ldo6 {
regulator-min-microvolt = <90>;
regulator-max-microvolt = <360>;
- regulator-always-on;
- regulator-boot-on;
};
vdd_ldo7: ldo7 {
regulator-min-microvolt = <90>;
regulator-max-microvolt = <360>;
- regulator-always-on;
- regulator-boot-on;
};
vdd_ldo8: ldo8 {
regulator-min-microvolt = <90>;
regulator-max-microvolt = <360>;
- regulator-always-on;
- regulator-boot-on;
};
vdd_ldo9: ldo9 {
regulator-min-microvolt = <95>;
regulator-max-microvolt = <360>;
- regulator-always-on;
- regulator-boot-on;
};
vdd_ldo10: ldo10 {
regulator-min-microvolt = <90>;
regulator-max-microvolt = <360>;
- regulator-always-on;
- regulator-boot-on;
};
vdd_ldo11: ldo11 {
@@ -301,16 +293,6 @@
imx6q-ba16 {
pinctrl_hog: hoggrp {
fsl,pins = <
- MX6QDL_PAD_GPIO_4__GPIO1_IO040x8000
/* uSDHC2 CD */
- MX6QDL_PAD_NANDF_CS0__GPIO6_IO11 0x8000
/* uSDHC4 CD */
- MX6QDL_PAD_NANDF_CS1__GPIO6_IO14 0x8000
/* uSDHC4 SDIO PWR */
- MX6QDL_PAD_NANDF_CS2__GPIO6_IO15 0x8000
/* uSDHC4 SDIO WP */
- MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x8000
/* uSDHC4 SDIO LED */
- MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x8000
/* SPI1 CS */
- MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x8000
/* PCIe Reset */
- MX6QDL_PAD_GPIO_5__GPIO1_IO050x8000
/* PCIe Wake */
- MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x130b0
/* FEC CLK */
- MX6QDL_PAD_ENET_TX_EN__GPIO1_IO28 0x8000
/* FEC Reset */
MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x8000
/* GPIO0 */
MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x8000
/* GPIO1 */
MX6QDL_PAD_NANDF_D2__GPIO2_IO02 0x8000
/* GPIO2 */
@@ -321,17 +303,44 @@
MX6QDL_PAD_NANDF_D7__GPIO2_IO07 0x8000
/* GPIO7 */
MX6QDL_PAD_NANDF_CLE__GPIO6_IO07
[PATCH v2 00/10] ARM: dts: Add Advantech board support
This series aims to add Advantech BA-16 module (iMX6 based) and GE board support. Patches 7 to 10 correspond to the v2 changes. This series has been tested against linux-next tag next-20151105. Modifications: v1->v2: - Move entries from pinctrl_hog to relevant groups as suggested by Lucas Stash - Remove unused PCIe power-on-gpio entry as suggested by Lucas Stash - Remove always-on from regulators that do not need to be always-on as suggested by Lucas Stash - Enable support for mma8453 - Add vendor prefix for General Electric Company as suggested by Martin Donnelly - Update Copyright information as suggest by Martin Donnelly History: [v1]: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/381872.html Akshay Bhat (8): of: Add vendor prefix for Advantech Corporation ARM: dts: imx: Add support for Advantech/GE B450v3 ARM: dts: imx: Add support for Advantech/GE B650v3 ARM: dts: imx: Add support for Advantech/GE B850v3 of: Add vendor prefix for General Electric Company ARM: dts: imx: Update vendor info for GE Bx50v3 boards ARM: dts: imx: Add mma8453 support ARM: dts: imx6q-ba16: Cleanup pinctrl and LDO Justin Waters (2): ARM: dts: imx: Add Advantech BA-16 Qseven module ARM: dts: imx: Add support for Advantech/GE Bx50v3 .../devicetree/bindings/vendor-prefixes.txt| 2 + arch/arm/boot/dts/Makefile | 3 + arch/arm/boot/dts/imx6q-b450v3.dts | 75 +++ arch/arm/boot/dts/imx6q-b650v3.dts | 74 +++ arch/arm/boot/dts/imx6q-b850v3.dts | 122 + arch/arm/boot/dts/imx6q-ba16.dtsi | 584 + arch/arm/boot/dts/imx6q-bx50v3.dtsi| 211 7 files changed, 1071 insertions(+) create mode 100644 arch/arm/boot/dts/imx6q-b450v3.dts create mode 100644 arch/arm/boot/dts/imx6q-b650v3.dts create mode 100644 arch/arm/boot/dts/imx6q-b850v3.dts create mode 100644 arch/arm/boot/dts/imx6q-ba16.dtsi create mode 100644 arch/arm/boot/dts/imx6q-bx50v3.dtsi -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/10] ARM: dts: imx: Add support for Advantech/GE B450v3
Add support for Advantech/GE B450v3 board.
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-b450v3.dts | 75 ++
2 files changed, 76 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-b450v3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 30bbc37..b3330fe 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -310,6 +310,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-wandboard-revb1.dtb \
imx6q-apf6dev.dtb \
imx6q-arm2.dtb \
+ imx6q-b450v3.dtb \
imx6q-cm-fx6.dtb \
imx6q-cubox-i.dtb \
imx6q-dfi-fs700-m60.dtb \
diff --git a/arch/arm/boot/dts/imx6q-b450v3.dts
b/arch/arm/boot/dts/imx6q-b450v3.dts
new file mode 100644
index 000..d63d9e1
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-b450v3.dts
@@ -0,0 +1,75 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 GE Healthcare.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6q-bx50v3.dtsi"
+
+/ {
+ model = "Advantech MX6Q B450V3 QSeven Board";
+ compatible = "adv,imx6q-b450v3", "adv,imx6q-ba16", "fsl,imx6q";
+
+ chosen {
+ stdout-path = &uart3;
+ };
+};
+
+&ldb {
+ 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>;
+ status = "okay";
+
+ lvds0: lvds-channel@0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: G121X1-L03 {
+ clock-frequency = <6500>;
+ hactive = <1024>;
+ vactive = <768>;
+ hback-porch = <320>;
+ hfront-porch = <0>;
+ vback-porch = <0>;
+ vfront-porch = <38>;
+ hsync-len = <1>;
+ vsync-len = <1>;
+ };
+ };
+ };
+
+ lvds1: lvds-channel@1 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing1>;
+ timing1: G121X1-L03 {
+ clock-frequency = <6500>;
+ hactive = <1024>;
+ vactive = <768>;
+ hback-porch = <320>;
+ hfront-porch = <0>;
+ vback-porch = <0>;
+ vfront-porch = <38>;
+ hsync-len = <1>;
+ vsync-len = <1>;
+ };
+ };
+ };
+
+};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 06/10] ARM: dts: imx: Add support for Advantech/GE B850v3
Add support for Advantech/GE B850v3 board.
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-b850v3.dts | 122 +
2 files changed, 123 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-b850v3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e2df9f8..7ad1eb8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -312,6 +312,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-arm2.dtb \
imx6q-b450v3.dtb \
imx6q-b650v3.dtb \
+ imx6q-b850v3.dtb \
imx6q-cm-fx6.dtb \
imx6q-cubox-i.dtb \
imx6q-dfi-fs700-m60.dtb \
diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts
b/arch/arm/boot/dts/imx6q-b850v3.dts
new file mode 100644
index 000..be6c0da
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-b850v3.dts
@@ -0,0 +1,122 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 GE Healthcare.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6q-bx50v3.dtsi"
+
+/ {
+ model = "Advantech MX6Q B850V3 QSeven Board";
+ compatible = "adv,imx6q-b850v3", "adv,imx6q-ba16", "fsl,imx6q";
+
+ chosen {
+ stdout-path = &uart3;
+ };
+};
+
+&ldb {
+ 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>;
+ fsl,dual-channel;
+ status = "okay";
+
+ lvds0: lvds-channel@0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: stdp4028 {
+ clock-frequency = <137143857>;
+ hactive = <1920>;
+ vactive = <1080>;
+ hback-porch = <100>;
+ hfront-porch = <40>;
+ vback-porch = <30>;
+ vfront-porch = <3>;
+ hsync-len = <10>;
+ vsync-len = <2>;
+ };
+ };
+ };
+};
+
+&i2c2 {
+ pca9547_ddc: mux@70 {
+ compatible = "nxp,pca9547";
+ reg = <0x70>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mux_i2c11: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0>;
+ };
+
+ mux_i2c12: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1>;
+ };
+
+ mux_i2c13: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2>;
+ };
+
+ mux_i2c14: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3>;
+ };
+
+ mux_i2c15: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4>;
+ };
+
+ mux_i2c16: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x5>;
+ };
+
+ mux_i2c17: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x6>;
+ };
+
+ mux_i2c18: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x7>;
+ };
+ };
+};
+
+&hdmi {
+ ddc-i2c-bus = <&mux_i2c11>;
+};
+
+&mux_i2c3 {
+ ads7830_2: ads7830@4a {
+ compatible = "ti,ads7830";
+ reg = <0x4a>;
+ };
+};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/10] ARM: dts: imx: Add support for Advantech/GE B650v3
Add support for Advantech/GE B650v3 board.
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-b650v3.dts | 74 ++
2 files changed, 75 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-b650v3.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b3330fe..e2df9f8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -311,6 +311,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-apf6dev.dtb \
imx6q-arm2.dtb \
imx6q-b450v3.dtb \
+ imx6q-b650v3.dtb \
imx6q-cm-fx6.dtb \
imx6q-cubox-i.dtb \
imx6q-dfi-fs700-m60.dtb \
diff --git a/arch/arm/boot/dts/imx6q-b650v3.dts
b/arch/arm/boot/dts/imx6q-b650v3.dts
new file mode 100644
index 000..29cbdb0
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-b650v3.dts
@@ -0,0 +1,74 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 GE Healthcare.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+
+#include "imx6q-bx50v3.dtsi"
+
+/ {
+ model = "Advantech MX6Q B650V3 QSeven Board";
+ compatible = "adv,imx6q-b650v3", "adv,imx6q-ba16", "fsl,imx6q";
+
+ chosen {
+ stdout-path = &uart3;
+ };
+};
+
+&ldb {
+ 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>;
+ status = "okay";
+
+ lvds0: lvds-channel@0 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing0>;
+ timing0: G121X1-L03 {
+ clock-frequency = <6500>;
+ hactive = <1024>;
+ vactive = <768>;
+ hback-porch = <320>;
+ hfront-porch = <0>;
+ vback-porch = <0>;
+ vfront-porch = <38>;
+ hsync-len = <1>;
+ vsync-len = <1>;
+ };
+ };
+ };
+
+ lvds1: lvds-channel@1 {
+ fsl,data-mapping = "spwg";
+ fsl,data-width = <24>;
+ status = "okay";
+
+ display-timings {
+ native-mode = <&timing1>;
+ timing1: G121X1-L03 {
+ clock-frequency = <6500>;
+ hactive = <1024>;
+ vactive = <768>;
+ hback-porch = <320>;
+ hfront-porch = <0>;
+ vback-porch = <0>;
+ vfront-porch = <38>;
+ hsync-len = <1>;
+ vsync-len = <1>;
+ };
+ };
+ };
+};
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/10] ARM: dts: imx: Update vendor info for GE Bx50v3 boards
Update vendor and copyright info for GE Bx50v3 boards
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/imx6q-b450v3.dts | 4 ++--
arch/arm/boot/dts/imx6q-b650v3.dts | 4 ++--
arch/arm/boot/dts/imx6q-b850v3.dts | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-b450v3.dts
b/arch/arm/boot/dts/imx6q-b450v3.dts
index d63d9e1..efe9c1e 100644
--- a/arch/arm/boot/dts/imx6q-b450v3.dts
+++ b/arch/arm/boot/dts/imx6q-b450v3.dts
@@ -1,6 +1,6 @@
/*
* Copyright 2015 Timesys Corporation.
- * Copyright 2015 GE Healthcare.
+ * Copyright 2015 General Electric Company
*
* The code contained herein is licensed under the GNU General Public
* License. You may obtain a copy of the GNU General Public License
@@ -16,7 +16,7 @@
/ {
model = "Advantech MX6Q B450V3 QSeven Board";
- compatible = "adv,imx6q-b450v3", "adv,imx6q-ba16", "fsl,imx6q";
+ compatible = "ge,imx6q-b450v3", "adv,imx6q-ba16", "fsl,imx6q";
chosen {
stdout-path = &uart3;
diff --git a/arch/arm/boot/dts/imx6q-b650v3.dts
b/arch/arm/boot/dts/imx6q-b650v3.dts
index 29cbdb0..d40efa9 100644
--- a/arch/arm/boot/dts/imx6q-b650v3.dts
+++ b/arch/arm/boot/dts/imx6q-b650v3.dts
@@ -1,6 +1,6 @@
/*
* Copyright 2015 Timesys Corporation.
- * Copyright 2015 GE Healthcare.
+ * Copyright 2015 General Electric Company
*
* The code contained herein is licensed under the GNU General Public
* License. You may obtain a copy of the GNU General Public License
@@ -16,7 +16,7 @@
/ {
model = "Advantech MX6Q B650V3 QSeven Board";
- compatible = "adv,imx6q-b650v3", "adv,imx6q-ba16", "fsl,imx6q";
+ compatible = "ge,imx6q-b650v3", "adv,imx6q-ba16", "fsl,imx6q";
chosen {
stdout-path = &uart3;
diff --git a/arch/arm/boot/dts/imx6q-b850v3.dts
b/arch/arm/boot/dts/imx6q-b850v3.dts
index be6c0da..a77f392 100644
--- a/arch/arm/boot/dts/imx6q-b850v3.dts
+++ b/arch/arm/boot/dts/imx6q-b850v3.dts
@@ -1,6 +1,6 @@
/*
* Copyright 2015 Timesys Corporation.
- * Copyright 2015 GE Healthcare.
+ * Copyright 2015 General Electric Company
*
* The code contained herein is licensed under the GNU General Public
* License. You may obtain a copy of the GNU General Public License
@@ -16,7 +16,7 @@
/ {
model = "Advantech MX6Q B850V3 QSeven Board";
- compatible = "adv,imx6q-b850v3", "adv,imx6q-ba16", "fsl,imx6q";
+ compatible = "ge,imx6q-b850v3", "adv,imx6q-ba16", "fsl,imx6q";
chosen {
stdout-path = &uart3;
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/10] ARM: dts: imx: Add support for Advantech/GE Bx50v3
From: Justin Waters
Advantech has 3 carrier boards (B450v3, B650v3, B850v3) which use
the Advantech BA-16 module (based on iMX6D). This file has the
devicetree entries that are common to all 3 boards.
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/imx6q-bx50v3.dtsi | 206
1 file changed, 206 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-bx50v3.dtsi
diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
new file mode 100644
index 000..e9d97ee
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
@@ -0,0 +1,206 @@
+/*
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 GE Healthcare.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "imx6q-ba16.dtsi"
+
+/ {
+ regulators {
+ /* regulator for wl18xx on sdhc4 */
+ wl18xx_vmmc: regulator@6 {
+ compatible = "regulator-fixed";
+ regulator-name = "vwl1807";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&pca9539 3 GPIO_ACTIVE_HIGH>;
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
+
+ reg_wlan: regulator@7 {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V_wlan";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ regulator-boot-on;
+ gpio = <&gpio6 14 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ sound {
+ compatible = "fsl,imx6q-ba16-sgtl5000",
+"fsl,imx-audio-sgtl5000";
+ model = "imx6q-ba16-sgtl5000";
+ ssi-controller = <&ssi1>;
+ audio-codec = <&codec>;
+ audio-routing =
+ "MIC_IN", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT";
+ mux-int-port = <1>;
+ mux-ext-port = <4>;
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mclk: clock@0 {
+ compatible = "fixed-clock";
+ reg = <0>;
+ #clock-cells = <0>;
+ clock-frequency = <2200>;
+ };
+ };
+};
+
+&i2c1 {
+ pca9547: mux@70 {
+ compatible = "nxp,pca9547";
+ reg = <0x70>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mux_i2c3: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x0>;
+
+ ads7830: ads7830@48 {
+ compatible = "ti,ads7830";
+ reg = <0x48>;
+ };
+ };
+
+ mux_i2c4: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1>;
+
+ eeprom: eeprom@50 {
+ compatible = "atmel,24c08";
+ reg = <0x50>;
+ };
+
+ mpl3115: mpl3115@60 {
+ compatible = "fsl,mpl3115";
+ reg = <0x60>;
+ };
+ };
+
+ mux_i2c5: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x2>;
+ };
+
+ mux_i2c6: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x3>;
+
+ codec: sgtl5000@0a {
+ compatible = "fsl,sgtl5000";
+ reg = <0x0a>;
+ clocks = <&mclk>;
+ VDDA-supply = <®_1p8v>;
+ VDDIO-supply = <®_3p3v>;
+ };
+ };
+
+ mux_i2c7: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4>;
+
+ pca9539: pca9539@74 {
+ compatible = "nxp,pca9539";
+
[PATCH v2 09/10] ARM: dts: imx: Add mma8453 support
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/imx6q-bx50v3.dtsi | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
index e9d97ee..2715cd9 100644
--- a/arch/arm/boot/dts/imx6q-bx50v3.dtsi
+++ b/arch/arm/boot/dts/imx6q-bx50v3.dtsi
@@ -1,6 +1,6 @@
/*
* Copyright 2015 Timesys Corporation.
- * Copyright 2015 GE Healthcare.
+ * Copyright 2015 General Electric Company
*
* The code contained herein is licensed under the GNU General Public
* License. You may obtain a copy of the GNU General Public License
@@ -79,6 +79,11 @@
compatible = "ti,ads7830";
reg = <0x48>;
};
+
+ mma8453: mma8453@1c {
+ compatible = "fsl,mma8453";
+ reg = <0x1c>;
+ };
};
mux_i2c4: i2c@1 {
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 02/10] ARM: dts: imx: Add Advantech BA-16 Qseven module
From: Justin Waters
Add support for Advantech BA-16 module based on iMX6D processor
http://www2.advantech.com/products/medical_computing_system/dms-ba16/mod_64aa1566-169c-483d-97c8-c2c22c163fc3.aspx
Signed-off-by: Akshay Bhat
---
arch/arm/boot/dts/imx6q-ba16.dtsi | 559 ++
1 file changed, 559 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-ba16.dtsi
diff --git a/arch/arm/boot/dts/imx6q-ba16.dtsi
b/arch/arm/boot/dts/imx6q-ba16.dtsi
new file mode 100644
index 000..3d47039
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-ba16.dtsi
@@ -0,0 +1,559 @@
+/*
+ * Support for imx6 based Advantech DMS-BA16 Qseven module
+ *
+ * Copyright 2015 Timesys Corporation.
+ * Copyright 2015 GE Healthcare.
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "imx6q.dtsi"
+#include
+
+/ {
+ memory {
+ reg = <0x1000 0x4000>;
+ };
+
+ clocks {
+ clk24m: clk24m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2400>;
+ };
+ };
+
+ regulators {
+ compatible = "simple-bus";
+
+ reg_usb_otg_vbus: regulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ reg_usb_h1_vbus: regulator@2 {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ reg_1p8v: regulator@3 {
+ compatible = "regulator-fixed";
+ regulator-name = "1P8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator@4 {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+ };
+
+ lvds_ppen: regulator@5 {
+ compatible = "regulator-fixed";
+ regulator-name = "lvds_ppen";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ gpio = <&gpio3 22 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+ };
+
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm1 0 500>;
+ 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 101 102 103 104 105 106 107 108 109
+110 111 112 113 114 115 116 117 118 119
+120 121 122 123 124 125 126 127 128 129
+130 131 132 133 134 135 136 137 138 139
+140 141 142 143 144 145 146 147 148 149
+150 151 152 153 154 155 156 157 158 159
+160 161 162 163 164 165 166 167 168 169
+170 171 172 173 174 175 176 177 178 179
+180 181 182 183 184 185 186 187 188 189
+190 191 192 193 194 195 196 197 198 199
+200 201 202 203 204 205 206 207 208 209
+210 211 212 213 214 215 216 217 218 219
+
[PATCH v2 07/10] of: Add vendor prefix for General Electric Company
This patch adds vendor prefix for General Electric Company Signed-off-by: Akshay Bhat --- 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 2b3c5ac..71dcbd5 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -87,6 +87,7 @@ fcs Fairchild Semiconductor fireflyFirefly focaltech FocalTech Systems Co.,Ltd fslFreescale Semiconductor +ge General Electric Company GEFanucGE Fanuc Intelligent Platforms Embedded Systems, Inc. gefGE Fanuc Intelligent Platforms Embedded Systems, Inc. geniatech Geniatech, Inc. -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] dt-bindings: phy: Add NVIDIA Tegra XUSB pad controller binding
On Thu, Nov 5, 2015 at 1:55 AM, Jon Hunter wrote: >> +UTMI ports: >> +--- >> + >> +Required properties: >> +- status: Defines the operation status of the port. Valid values are: >> + - "disabled": the port is disabled >> + - "okay": the port is enabled >> +- mode: A string that determines the mode in which to run the port. Valid >> + values are: >> + - "host": for USB host mode >> + - "device": for USB device mode >> + - "otg": for USB OTG mode >> + >> +Optional properties: >> +- nvidia,internal: A boolean property whose presence determines that a port >> + is internal. In the absence of this property the port is considered to be >> + external. >> +- vbus-supply: phandle to a regulator supplying the VBUS voltage. >> + >> +ULPI ports: >> +--- >> + >> +Optional properties: >> +- status: Defines the operation status of the port. Valid values are: >> + - "disabled": the port is disabled >> + - "okay": the port is enabled >> +- nvidia,internal: A boolean property whose presence determines that a port >> + is internal. In the absence of this property the port is considered to be >> + external. >> + >> +HSIC ports: >> +--- >> + >> +Required properties: >> +- status: Defines the operation status of the port. Valid values are: >> + - "disabled": the port is disabled >> + - "okay": the port is enabled >> + >> +Super-speed USB ports: >> +-- >> + >> +Required properties: >> +- status: Defines the operation status of the port. Valid values are: >> + - "disabled": the port is disabled >> + - "okay": the port is enabled >> +- nvidia,port: A single cell that specifies the physical port number to map >> + this super-speed USB port to. The range of valid port numbers varies with >> + the SoC generation: >> + - 0-2: for Tegra124 and Tegra132 > > I am a bit confused by what nvidia,port property is used for. Is this to > program XUSB_PADCTL_SS_PORT_MAP_0? If so then I think that this should > be an optional property because if you want to use the usb3 ports for > usb3, then we should not need to specify this here. "nvidia,port" is used to program XUSB_PADCTL_SS_PORT_MAP and is definitely required. It specifies the UTMI port to which the SS port is mapped to. For example, Nyan-Big has 3 UTMI ports (0, 1 (internal), and 2) and 2 SS ports (0 and 1). SS port 0 is mapped to the same physical port as UTMI port 0 and SS port 1 is mapped to the same physical port as UTMI port 2. > Also the XHCI has 3 usb2 ports and 2 usb3 ports and so when you have > port numbers 0-2 I am not sure what you are referring too. The port numbers correspond tot he UTMI ports, so 3 UTMI ports = possible port values of 0 - 2. Maybe "port" isn't the best name here? -Andrew -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC
On 11/05/2015 04:14 AM, Mark Brown wrote:
On Wed, Nov 04, 2015 at 09:35:26AM -0600, Andrew F. Davis wrote:
Something I just noticed, when I remove this table, module loading stops
working, even with 'MODULE_ALIAS("platform:tps65912-regulator");'. It
looks like when DT is enabled platform_uevent (drivers/base/platform.c:787)
only sends out the OF MODALIAS event then returns, not sending out the
platform event, is this desired behavior? If so then I will need this
table even though I still create the device and match it on platform
name as you suggested.
That sounds like a bug to me, it'll have broken a bunch of existing
devices.
Most OF drivers have the OF MODALIAS.
'platform_uevent' can only emit one MODALIAS string per device (only
the last emitted one seems to count), so for any device with
'dev->of_node' set it will be the OF MODALIAS string. So I need
that table (to generate the OF MODALIAS) or this sub-device module
will not be loaded.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-acpi] [PATCH v8 5/5] Watchdog: introduce ARM SBSA watchdog driver
Hi Timur On 6 November 2015 at 01:59, Timur Tabi wrote: > On 11/05/2015 10:41 AM, Guenter Roeck wrote: >> >> >> Ultimately, you'll have to decide if you want a simple driver accepted, or >> a complex driver hanging in the review queue forever. > > > Please note that I did post such a driver back in May: > > http://www.spinics.net/lists/linux-watchdog/msg06567.html > > Officially I withdrew it in favor of Fu's, but the decision which driver to > pick up is not mine to make. I can resubmit driver if you'd like. I totally can not agree with "make WS1 as backup", and that not a SBSA watchdog dirver, because that just have one stage And the short timeout is useless for kexec/kdump in real practice. > > -- > Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the > Code Aurora Forum, a Linux Foundation Collaborative Project. -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-acpi] [PATCH v8 5/5] Watchdog: introduce ARM SBSA watchdog driver
On 11/05/2015 10:41 AM, Guenter Roeck wrote: Ultimately, you'll have to decide if you want a simple driver accepted, or a complex driver hanging in the review queue forever. Please note that I did post such a driver back in May: http://www.spinics.net/lists/linux-watchdog/msg06567.html Officially I withdrew it in favor of Fu's, but the decision which driver to pick up is not mine to make. I can resubmit driver if you'd like. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] ASoC: da7218: Add bindings documentation for DA7218 audio codec
On November 05, 2015 14:59, Mark Brown wrote:
> > +- dlg,ldo-lvl : Required internal LDO voltage (mV) level
> > + [<1050>, <1100>, <1200>, <1400>]
>
> Why would this ever be anything other than the minimum voltage, and
> might we not want to vary it at runtime?
Normally you are correct and you'll want minimum voltage for the digital engine
but there may be the possibility for certain platform scenarios that to meet
timings a higher voltage is required. Would prefer to leave this in in case it
is required in the future. As a side, the default setting is the lowest voltage,
if this binding is not provided.
>
> > +- dlg,biquad-cfg : List of data & address pairs to configure BiQuad filters
> > + [ < {data1} {addr1} {data2} {addr2} ... >; ]
> > +- dlg,st-biquad-cfg : List of data & address pairs to configure Sidetone
> > + BiQuad filters
> > + [ < {data1} {addr1} {data2} {addr2} ... >; ]
>
> These look like DSP coefficients which I would therefore expect to be
> configurable at runtime via a binary control rather than specified in
> the DT - why are they in the DT?
The expectation was these would be set once and left for a platform, which is
why I added them to the DT. However there's no reason they couldn't be moved
to binary control. Having looked at other codecs, I assume SND_SOC_BYTES* would
be the preferred method for setting this kind of data?
N�r��yb�X��ǧv�^�){.n�+���z��z��z)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
Re: [Linaro-acpi] [PATCH v8 5/5] Watchdog: introduce ARM SBSA watchdog driver
Hi Guenter, Great thanks for that you are still reviewing this patchset, thanks for your patient. On 6 November 2015 at 00:41, Guenter Roeck wrote: > On 11/05/2015 07:00 AM, Fu Wei wrote: >> >> Hi Timur, >> >> On 5 November 2015 at 22:40, Timur Tabi wrote: >>> >>> Fu Wei wrote: Did you really read the "Note" above OK, let me paste it again and again: SBSA 2.3 Page 23 : If a larger watch period is required then the compare value can be programmed directly into the compare value register. >>> >>> >>> >>> Well, okay. Sorry, I should have read what you pasted more closely. But >>> I >> >> >> Thanks for reading it again. >> >>> think that means during initialization, not during the WS0 timeout. >> >> >> I really don't see SBSA say "during initialization, not during the WS0 >> timeout", >> please point it out the page number and the line number in SBSA spec. >> maybe I miss it? >> Thanks for your help in advance. >> >>> >>> Anyway, I still don't like the fact that you're programming WCV in the >> >> >> "you don't like" doesn't mean "it is wrong" or "we can't do this", so >> I will keep this way unless we have better idea to extend second stage >> timeout. >> >>> interrupt handler, but I'm not going to make a big deal about it any >>> more. >> >> >> Deal, Thanks a lot. >> > > The problem with your driver, as I see it, is that dealing with WS0/WS1 > and pretimeout makes the driver so complex that, at least for my part, > I am very wary about it. The driver could long since have been accepted > if it were not for that. Besides that, I really believe that any system > designer > using the highest permitted frequency should be willing to live with the > consequences, and not force the implementation of a a complex driver. yes, comparing with those "one stage" watchdogs driver, I admit my SBSA driver is a little complex this complex come from : (1) In SBSA spec, there are two stage. because of these two stages, I looked for the solution in the kernel, then I found "pretimeout". I have explained a lot why I decide to use pretimeout which is existing concept in Linux kernel I just tried to introduce a existing concept into watchdog framework. Maybe people will say, there is only two or one drivers use that, but it doesn't mean we can't have more in the future. Maybe people will say, let's do this when we have more two stages watchdog. But if I need this now, why not just make it this time. if we use this driver as one stage watchdog, it violates the SBSA spec, and it can not be call SBSA watchdog driver. (2) in SBSA watchdog, WOR is a 32bit register, we have a timeout limitation. first of all, according to kernel documentation, Documentation/watchdog/watchdog-api.txt - Pretimeouts: Some watchdog timers can be set to have a trigger go off before the actual time they will reset the system. This can be done with an NMI, interrupt, or other mechanism. This allows Linux to record useful information (like panic information and kernel coredumps) before it resets. --- So I decide to use panic() in first timeout handler, then we can use kdump But in the real practice, 10s is not enough for kexec(let alone kdump), even we can have 100s, 200s, it is not enough for a real server which has huge ram to finish kdump. So I decide to reprogram WCV for longer timer value. except this two point, there is not more complex than other watchdog drivers. And for these two complex point, I have explained the reason. And this driver has been test on two platforms Foundation model Seattle and will be more. And this driver has been test with kdump, and works. > > Ultimately, you'll have to decide if you want a simple driver accepted, or > a complex driver hanging in the review queue forever. I have tried to simplify this driver, and I understand why we need a simple driver, and why you are wary about it. Even we want "simple" driver, but we can't ignore the SBSA watchdog feature in the spec. If I can find a better way to solve these two complex point to make this driver simple, I will absolutely do it. But before we get better solution, I can not make a "simple" non-SBSA watchdog driver to be accepted just for "my driver be accepted". at least I need to convince myself: my driver is not just a simple driver, but also a right driver for target device. Maybe it will take a very long time, but at least for now, I believe I am doing the right way. If you have suggestion to make this driver simple, I absolutely listen to it and try to do it just like previous review. Again, I appreciate your help and review very much. :-) > > Thanks, > Guenter > -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- To unsubscribe from this l
Re: [Linaro-acpi] [PATCH v8 5/5] Watchdog: introduce ARM SBSA watchdog driver
On 11/05/2015 07:00 AM, Fu Wei wrote: Hi Timur, On 5 November 2015 at 22:40, Timur Tabi wrote: Fu Wei wrote: Did you really read the "Note" above OK, let me paste it again and again: SBSA 2.3 Page 23 : If a larger watch period is required then the compare value can be programmed directly into the compare value register. Well, okay. Sorry, I should have read what you pasted more closely. But I Thanks for reading it again. think that means during initialization, not during the WS0 timeout. I really don't see SBSA say "during initialization, not during the WS0 timeout", please point it out the page number and the line number in SBSA spec. maybe I miss it? Thanks for your help in advance. Anyway, I still don't like the fact that you're programming WCV in the "you don't like" doesn't mean "it is wrong" or "we can't do this", so I will keep this way unless we have better idea to extend second stage timeout. interrupt handler, but I'm not going to make a big deal about it any more. Deal, Thanks a lot. The problem with your driver, as I see it, is that dealing with WS0/WS1 and pretimeout makes the driver so complex that, at least for my part, I am very wary about it. The driver could long since have been accepted if it were not for that. Besides that, I really believe that any system designer using the highest permitted frequency should be willing to live with the consequences, and not force the implementation of a a complex driver. Ultimately, you'll have to decide if you want a simple driver accepted, or a complex driver hanging in the review queue forever. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/5] ARM: dts: DRA7: add entry for qspi mmap region
On Tue, Nov 03, 2015 at 03:36:13PM +0530, Vignesh R wrote:
> Add qspi memory mapped region entries for DRA7xx based SoCs. Also,
> update the binding documents for the controller to document this change.
>
> Signed-off-by: Vignesh R
You don't really need an example for every possibility, but
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/spi/ti_qspi.txt | 13 +
> arch/arm/boot/dts/dra7.dtsi | 6 --
> 2 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt
> b/Documentation/devicetree/bindings/spi/ti_qspi.txt
> index 601a360531a5..f05dd631bef1 100644
> --- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
> +++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
> @@ -26,3 +26,16 @@ qspi: qspi@4b30 {
> spi-max-frequency = <2500>;
> ti,hwmods = "qspi";
> };
> +
> +For dra7xx:
> +qspi: qspi@4b30 {
> + compatible = "ti,dra7xxx-qspi";
> + reg = <0x4b30 0x100>, <0x4a002558 0x4>,
> + <0x5c00 0x400>;
> + reg-names = "qspi_base", "qspi_ctrlmod",
> + "qspi_mmap";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + spi-max-frequency = <4800>;
> + ti,hwmods = "qspi";
> +};
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index e289c706d27d..13c2f10ec217 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -1108,8 +1108,10 @@
>
> qspi: qspi@4b30 {
> compatible = "ti,dra7xxx-qspi";
> - reg = <0x4b30 0x100>;
> - reg-names = "qspi_base";
> + reg = <0x4b30 0x100>, <0x4a002558 0x4>,
> + <0x5c00 0x400>;
> + reg-names = "qspi_base", "qspi_ctrlmod",
> + "qspi_mmap";
> #address-cells = <1>;
> #size-cells = <0>;
> ti,hwmods = "qspi";
> --
> 2.6.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] watchdog: add Alphascale asm9260-wdt driver
On 11/05/2015 01:06 AM, Oleksij Rempel wrote:
Add WD support for Alphascale asm9260 SoC. This driver
provide support for different function modes:
- HW mode to trigger SoC reset on timeout
- SW mode do soft reset if needed
- DEBUG mode
Optional support for stopping watchdog. If reset binding are not provided
this driver will work in nowayout mode.
In general, this is considered to be orthogonal: If the user doesn't want
nowayout, and if the watchdog can not be stopped, other drivers issue a warning
that the watchdog was not stopped, and that the system will likely restart.
Signed-off-by: Oleksij Rempel
---
.../bindings/watchdog/alphascale-asm9260.txt | 39 ++
drivers/watchdog/Kconfig | 9 +
drivers/watchdog/Makefile | 1 +
drivers/watchdog/asm9260_wdt.c | 415 +
4 files changed, 464 insertions(+)
create mode 100644
Documentation/devicetree/bindings/watchdog/alphascale-asm9260.txt
create mode 100644 drivers/watchdog/asm9260_wdt.c
diff --git a/Documentation/devicetree/bindings/watchdog/alphascale-asm9260.txt
b/Documentation/devicetree/bindings/watchdog/alphascale-asm9260.txt
new file mode 100644
index 000..6e54d1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/alphascale-asm9260.txt
@@ -0,0 +1,39 @@
+Alphascale asm9260 Watchdog timer
+
+Required properties:
+
+- compatible : should be "alphascale,asm9260-wdt".
+- reg : Specifies base physical address and size of the registers.
+- clocks : the clocks feeding the watchdog timer. See clock-bindings.txt
+- clock-names : should be set to
+ "mod" - source for tick counter.
+ "ahb" - ahb gate.
+
+Optional properties:
+- resets : phandle pointing to the system reset controller with correct
+ reset line index for watchdog controller reset. This propertie is
+ required if you need to disable "nowayout" and it neened only with
+ CONFIG_WATCHDOG_NOWAYOUT=n.
+ Without reseting this WD controller, it is not possible to stop
+ counter.
+- reset-names : should be set to "wdt_rst" if "resets" is used.
+- timeout-sec : shall contain the default watchdog timeout in seconds,
+ if unset, the default timeout is 30 seconds.
+- alphascale,mode : tree modes are supported
+ "hw" - hw reset (defaul).
+ "sw" - sw reset.
+ "debug" - no action is taken.
+
+Example:
+
+watchdog0: watchdog@80048000 {
+ compatible = "alphascale,asm9260-wdt";
+ reg = <0x80048000 0x10>;
+ clocks = <&acc CLKID_SYS_WDT>, <&acc CLKID_AHB_WDT>;
+ clock-names = "mod", "ahb";
+ interrupts = <55>;
+ resets = <&rst WDT_RESET>;
+ reset-names = "wdt_rst";
+ timeout-sec = <30>;
+ alphascale,mode = "hw";
+};
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index c68edc1..cc5f675 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -173,6 +173,15 @@ config ARM_SP805_WATCHDOG
ARM Primecell SP805 Watchdog timer. This will reboot your system when
the timeout is reached.
+config ASM9260_WATCHDOG
+ tristate "Alphascale ASM9260 watchdog"
+ depends on MACH_ASM9260
+ depends on OF
+ select WATCHDOG_CORE
+ help
+ Watchdog timer embedded into Alphascale asm9260 chips. This will
reboot your
+ system when the timeout is reached.
+
config AT91RM9200_WATCHDOG
tristate "AT91RM9200 watchdog"
depends on SOC_AT91RM9200 && MFD_SYSCON
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 0c616e3..bd7b0cd 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
# ARM Architecture
obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
+obj-$(CONFIG_ASM9260_WATCHDOG) += asm9260_wdt.o
obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
obj-$(CONFIG_CADENCE_WATCHDOG) += cadence_wdt.o
diff --git a/drivers/watchdog/asm9260_wdt.c b/drivers/watchdog/asm9260_wdt.c
new file mode 100644
index 000..9f2c321
--- /dev/null
+++ b/drivers/watchdog/asm9260_wdt.c
@@ -0,0 +1,415 @@
+/*
+ * Watchdog driver for Alphascale ASM9260.
+ *
+ * Copyright (c) 2014 Oleksij Rempel
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
I don't see any module parameters. Is this include needed ?
+#include
+#include
+#include
+#include
+#include
Is this include needed ?
+#include
+
+#define CLOCK_FREQ 100
+
+/* Watchdog Mode register */
+#define HW_WDMOD 0x00
+/* Wake interrupt. Set by HW, can't be cleared. */
+#define BM_MOD_WDINT BIT(3)
+/* This bit set if timeout reached. Cleared by SW. */
+#define BM_MOD_WDTOF BIT(2)
+/* HW Reset on timeout */
+#define BM_MOD_WDRESET BIT(1)
+/* WD
Re: [PATCH v2 1/5] spi: introduce mmap read support for spi flash devices
On Thu, Nov 05, 2015 at 05:59:36PM +0530, Vignesh R wrote: > On 11/04/2015 08:09 PM, Mark Brown wrote: > > It's a bit worrying that this doesn't sync with the message queue except > > via the mutex: this means that we might be out of order with respect to > > any asynchronous transfers that are happening on the device. I'm not > > sure that this is a practical problem, though there is some risk of > > unfair scheduling that would have to be under extreme load and it might > > make sense to prioritise reads anyway. > Since mmap interface is used only by mtd flash drivers and since almost > all mtd flash devices use synchronous transfers (spi_sync()), IMO, there > wont be out of order problem wrt mtd flashes. > But mmap read might delay transfers queued for non mtd flash devices. It > is difficult to wait for all transfers already queued to be pumped out > by __spi_pump_messages() and then do the mmap transfer. Do you have any > thoughts on how to sync with message queue? Like I say I think it probably doesn't matter. The main issue would be with other devices sharing the bus with a flash chip. signature.asc Description: PGP signature
Re: [PATCH 6/7] regulator: hisilicon: Add hi655x pmic voltage regulator driver
On Thu, Nov 05, 2015 at 09:34:47PM +0800, Chen Feng wrote:
> +config REGULATOR_HI6220_MTCMOS
> +bool "Hisilicon Hi6220 mtcmos support"
> +depends on ARCH_HISI
> +help
> + This driver provides support for the mtcmos regulators of Hi6220
> Soc.
> +
The Kconfig and Makefile updates for MCTMOS should have been in the
patch adding the driver for that.
> +config REGULATOR_HI655X
> +bool "HiSilicon Hi655x PMIC voltage regulator support"
> +depends on ARCH_HISI
For both of these we should have an || COMPILE_TEST and there's no need
for either to be bool I can see, they should be tristate.
> +static int hi655x_is_enabled(struct regulator_dev *rdev)
> +{
> + unsigned int value = 0;
> +
> + struct hi655x_regulator *regulator = rdev_get_drvdata(rdev);
> + struct hi655x_regulator_ctrl_regs *ctrl_regs = ®ulator->ctrl_regs;
> +
> + regmap_read(rdev->regmap, ctrl_regs->status_reg, &value);
> + return (value & BIT(regulator->ctrl_mask));
> +}
Use the standard regmap helpers, don't open code them.
> +static int hi655x_set_voltage(struct regulator_dev *rdev,
> + int min_uV, int max_uV, unsigned *selector)
Use the standard helpers, including one of the map_voltage()s and
set_voltage_sel_regmap(), don't open code them.
> +static unsigned int hi655x_map_mode(unsigned int mode)
> +{
> + /* hi655x pmic on hi6220 SoC only support normal mode */
> + if (mode == REGULATOR_MODE_NORMAL)
> + return REGULATOR_MODE_NORMAL;
> + else
> + return -EINVAL;
> +}
If the device only has one mode it should not have any mode operations,
they're only meaningful if there are multiple modes to set and they are
optional.
signature.asc
Description: PGP signature
Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
On Thu, Nov 05, 2015 at 10:43:19AM +, Adam Thomson wrote:
> +/* ALC */
> +static void da7218_alc_calib(struct snd_soc_codec *codec)
> +{
> + struct da7218_priv *da7218 = snd_soc_codec_get_drvdata(codec);
> + u8 calib_ctrl;
> + int i = 0;
> + bool calibrated = false;
> +
> + /* Bypass cache so it saves current settings */
> + regcache_cache_bypass(da7218->regmap, true);
What ensures that nothing else is running at the same time this is?
> +static int da7218_mic_lvl_det_sw_put(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol)
> +{
Why is this a user visible control?
> + /* Default all mixers off */
> + snd_soc_write(codec, DA7218_DROUTING_OUTDAI_1L, 0);
> + snd_soc_write(codec, DA7218_DROUTING_OUTDAI_1R, 0);
> + snd_soc_write(codec, DA7218_DROUTING_OUTDAI_2L, 0);
> + snd_soc_write(codec, DA7218_DROUTING_OUTDAI_2R, 0);
> + snd_soc_write(codec, DA7218_DROUTING_OUTFILT_1L, 0);
> + snd_soc_write(codec, DA7218_DROUTING_OUTFILT_1R, 0);
> + snd_soc_write(codec, DA7218_DROUTING_ST_OUTFILT_1L, 0);
> + snd_soc_write(codec, DA7218_DROUTING_ST_OUTFILT_1R, 0);
We generally just use the device defaults, why change them?
signature.asc
Description: PGP signature
Re: [Linaro-acpi] [PATCH v8 5/5] Watchdog: introduce ARM SBSA watchdog driver
Hi Timur, On 5 November 2015 at 22:40, Timur Tabi wrote: > Fu Wei wrote: >> >> Did you really read the "Note" above OK, let me paste it again >> and again: >> >> SBSA 2.3 Page 23 : >> If a larger watch period is required then the compare value can be >> programmed directly into the compare value register. > > > Well, okay. Sorry, I should have read what you pasted more closely. But I Thanks for reading it again. > think that means during initialization, not during the WS0 timeout. I really don't see SBSA say "during initialization, not during the WS0 timeout", please point it out the page number and the line number in SBSA spec. maybe I miss it? Thanks for your help in advance. > > Anyway, I still don't like the fact that you're programming WCV in the "you don't like" doesn't mean "it is wrong" or "we can't do this", so I will keep this way unless we have better idea to extend second stage timeout. > interrupt handler, but I'm not going to make a big deal about it any more. Deal, Thanks a lot. > > > -- > Sent by an employee of the Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of the > Code Aurora Forum, hosted by The Linux Foundation. -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v5 01/12] dt-bindings: drm/mediatek: Add Mediatek display subsystem dts binding
Am Mittwoch, den 04.11.2015, 21:28 -0600 schrieb Rob Herring: > On Wed, Nov 04, 2015 at 12:44:58PM +0100, Philipp Zabel wrote: > > From: CK Hu > > > > Add device tree binding documentation for the display subsystem in > > Mediatek MT8173 SoCs. > > > > Signed-off-by: CK Hu > > Signed-off-by: Philipp Zabel > > If this wasn't an RFC, I'd ack it. :) One thing you missed below though. Alright, thanks for your help in sorting these bindings out. [...] > > diff --git > > a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > > b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > > new file mode 100644 > > index 000..cc3d884 > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt [...] > > +DISP function blocks > > + > > + > > +A display stream starts at a source function block that reads pixel data > > from > > +memory and ends with a sink function block that drives pixels on a display > > +interface, or writes pixels back to memory. All DISP function blocks have > > +their own register space, interrupt, and clock gate. The blocks that can > > +access memory additionally have to list the IOMMU and local arbiter they > > are > > +connected to. > > + > > +For a description of the display interface sink function blocks, see > > +Documentation/devicetree/bindings/drm/mediatek/mediatek,dsi.txt and > > +Documentation/devicetree/bindings/drm/mediatek/mediatek,dpi.txt. > > Need to update these paths. Will do. regards Philipp -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ASoC: da7218: Add bindings documentation for DA7218 audio codec
On Thu, Nov 05, 2015 at 10:43:15AM +, Adam Thomson wrote:
> +- dlg,ldo-lvl : Required internal LDO voltage (mV) level
> + [<1050>, <1100>, <1200>, <1400>]
Why would this ever be anything other than the minimum voltage, and
might we not want to vary it at runtime?
> +- dlg,biquad-cfg : List of data & address pairs to configure BiQuad filters
> + [ < {data1} {addr1} {data2} {addr2} ... >; ]
> +- dlg,st-biquad-cfg : List of data & address pairs to configure Sidetone
> + BiQuad filters
> + [ < {data1} {addr1} {data2} {addr2} ... >; ]
These look like DSP coefficients which I would therefore expect to be
configurable at runtime via a binary control rather than specified in
the DT - why are they in the DT?
signature.asc
Description: PGP signature
Re: [RFC v5 02/12] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
Hi Daniel,
Am Donnerstag, den 05.11.2015, 02:49 +0800 schrieb Daniel Kurtz:
> Hi Philipp,
>
> A bunch of review comments inline.
A bunch indeed. Thank you for the feedback.
> On Wed, Nov 4, 2015 at 7:44 PM, Philipp Zabel wrote:
[...]
> > +struct mtk_drm_crtc {
> > + struct drm_crtc base;
> > + unsigned intpipe;
>
> There is one pipe too many :-)
> I think this one is not used."
>
> > + boolenabled;
> > + struct mtk_crtc_ddp_context *ctx;
>
> I think you should be able to just embed the "mtk_crtc_ddp_context"
> right into mtk_drm_crtc.
> Or maybe just get rid of mtk_crtc_ddp_context completely and just use
> mtk_drm_crtc eveywhere.
I'll combine them and get rid of the superfluous pipe.
[...]
> > +static void mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *crtc)
> > +{
[...]
> > + /* disp_mtcmos */
> > + ret = pm_runtime_get_sync(drm->dev);
> > + if (ret < 0)
> > + DRM_ERROR("Failed to enable power domain: %d\n", ret);
> > +
> > + mtk_ddp_clock_on(ctx->mutex_dev);
> > + mtk_crtc_ddp_power_on(ctx);
>
> get_sync(), clock_on() and ddp_power_on() really can fail; we are just
> ignoring errors here.
> Since they can fail, shouldn't they be moved out of the atomic
> "->enable()" path into the ->check() path that is allowed to fail?
You suggest I move them into atomic_check?
To me it sounds like this should not be called from check, but from the
drm_mode_config_funcs atomic_commit callback, right after calling
drm_atomic_helper_prepare_planes. But there is no prepare equivalent to
drm_atomic_helper_commit_modeset_enables.
> > +
> > + DRM_INFO("mediatek_ddp_ddp_path_setup\n");
> > + for (i = 0; i < (ctx->ddp_comp_nr - 1); i++) {
>
> nit: the inner () are not necessary.
Will remove those.
> > + mtk_ddp_add_comp_to_path(ctx->config_regs, ctx->pipe,
> > +ctx->ddp_comp[i].funcs->comp_id,
> > +ctx->ddp_comp[i+1].funcs->comp_id);
> > + mtk_ddp_add_comp_to_mutex(ctx->mutex_dev, ctx->pipe,
> > + ctx->ddp_comp[i].funcs->comp_id,
> > +
> > ctx->ddp_comp[i+1].funcs->comp_id);
> > + }
>
> Do you really have to do this here in the enable path? This looks
> like something that should be done in bind()?
>
> Perhaps all we really need here is to walk the path and write to
> DISP_REG_MUTEX_EN at the end of mtk_ddp_add_comp_to_mutex().
> By the way, where are those bits cleared in the disable path?
Disabling or changing the path is not implemented, the currently static
setup could well be moved into bind().
[...]
> > +static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *crtc)
> > +{
[...]
> > + pm_runtime_put_sync(drm->dev);
>
> Why sync?
I can think of no reason, will use the async version here.
[...]
> > +static void mtk_drm_crtc_disable(struct drm_crtc *crtc)
> > +{
> > + struct mtk_drm_crtc *mtk_crtc = to_mtk_crtc(crtc);
> > + struct mtk_crtc_state *state = to_mtk_crtc_state(crtc->state);
> > +
> > + DRM_INFO("mtk_drm_crtc_disable %d\n", crtc->base.id);
> > + if (WARN_ON(!mtk_crtc->enabled))
> > + return;
> > +
> > + mtk_crtc_ddp_hw_fini(mtk_crtc);
> > + mtk_crtc->do_flush = false;
> > + if (state->event)
> > + mtk_drm_crtc_finish_page_flip(mtk_crtc);
>
> It is a bit awkward to send the page flip event before the actual page
> flip has completed (in this case, for a page flip that you are
> canceling by disabling the crtc).
> Would it be better to wait for vblank here in crtc_disable instead?
Yes, I will wait for vblank here instead.
[...]
> > +static void mtk_drm_crtc_atomic_begin(struct drm_crtc *crtc,
> > + struct drm_crtc_state *old_crtc_state)
> > +{
> > + struct mtk_crtc_state *state = to_mtk_crtc_state(crtc->state);
> > +
> > + if (state->base.event) {
> > + state->base.event->pipe = drm_crtc_index(crtc);
> > + WARN_ON(drm_crtc_vblank_get(crtc) != 0);
> > + state->event = state->base.event;
> > + state->base.event = NULL;
>
> Hmm. Why are we "stealing" event from drm_crtc_state and handing it
> over to the wrapper mtk_crtc_state?
> Won't we still be able to retrieve state->base.event later when we
> need it in the mtk_drm_crtc_finish_page_flip?
Hmm, good point. I'll try that.
[...]
> > +static void mtk_crtc_ddp_irq(struct mtk_crtc_ddp_context *ctx)
>
> ==> So, this is the part of the driver that makes me the most nervous.
> Why are we writing the actual hardware registers in the *vblank
> interrupt handler*?!
> Every other display controller that I've ever seen has shadow
> registers that are used to stage a page flip at the next vblank.
> Are you sur
Re: [PATCH 5/7] regulator: add driver for mtcmos voltage regulator on hi6220 SoC
On Thu, Nov 05, 2015 at 09:34:46PM +0800, Chen Feng wrote:
> Add driver to support mtcmos on hi6220
I just noticed that these patches are all being posted to the IOMMU list
- that seems a bit odd?
> +static int hi6220_mtcmos_is_on(struct hi6220_mtcmos *mtcmos,
> +unsigned int regs, unsigned int mask, int shift)
> +{
> + unsigned int ret;
> +
> + ret = readl(mtcmos->sc_on_regs + regs);
> + ret &= (mask << shift);
> +
> + return ret;
> +}
> +
> +static int hi6220_mtcmos_is_enabled(struct regulator_dev *rdev)
> +{
> + int ret;
> + struct hi6220_mtcmos_info *sreg = rdev_get_drvdata(rdev);
> + struct platform_device *pdev =
> + container_of(rdev->dev.parent, struct platform_device, dev);
> + struct hi6220_mtcmos *mtcmos = platform_get_drvdata(pdev);
> + struct hi6220_mtcmos_ctrl_regs *ctrl_regs = &sreg->ctrl_regs;
> + struct hi6220_mtcmos_ctrl_data *ctrl_data = &sreg->ctrl_data;
> +
> + ret = hi6220_mtcmos_is_on(mtcmos, ctrl_regs->status_reg,
> + ctrl_data->mask, ctrl_data->shift);
> + return ret;
> +}
That's a *lot* of code for checking if a single bit is set, the same
thinng applies to the rest of the driver. Unless this is for some
reason very performance critical I'd recommend just using regmap-mmio
and the regmap helpers, that will enable you to remove almost all the
code here. Even if you can't do that at least removing the extra level
of helper function would help.
> + sc_on_regs = of_get_property(np, "hisilicon,mtcmos-sc-on-base", NULL);
> + if (sc_on_regs) {
> + regs = ioremap(be32_to_cpu(*sc_on_regs), SZ_4K);
> + mtcmos->sc_on_regs = regs;
> + } else
> + return -ENODEV;
{ } on both sides of the if statement. You should also use normal
reg resource specifiers for register blocks the you need rather than
open coding some custom properties with absolute addresses.
> + for (i = 0; i < HI6220_RG_MAX; i++) {
> + init_data = hi6220_mtcmos_matches[i].init_data;
> + if (!init_data)
> + continue;
No, you should register all regulators on the device not just those with
init_data - you should just let the core do the DT parsing for you using
the standard of_match feature in the regulator_desc.
> + mtcmos->rdev[i] = regulator_register(&sreg->rdesc, &config);
> + if (IS_ERR(mtcmos->rdev[i])) {
devm_regulator_register().
> +static const struct of_device_id of_hi6220_mtcmos_match_tbl[] = {
> + { .compatible = "hisilicon,hi6220-mtcmos-driver", },
Why is -driver part of the compatible?
> + .driver = {
> + .name = "hisi_hi6220_mtcmos",
Linux generally uses - not _ in names.
> +static int __init hi6220_mtcmos_init(void)
> +{
> + return platform_driver_register(&mtcmos_driver);
> +}
> +
> +static void __exit hi6220_mtcmos_exit(void)
> +{
> + platform_driver_unregister(&mtcmos_driver);
> +}
> +
> +fs_initcall(hi6220_mtcmos_init);
Why is this at fs_initcall?!
signature.asc
Description: PGP signature
Re: [PATCH V2 1/3] dma: add Qualcomm Technologies HIDMA management driver
Rob Herring wrote:
I'm saying document it as "qcom,-hidma-mgmt" and when you have
the part number update the binding. Meanwhile push on the powers that
be to decide on a part number.
Got it. But we should we do about this:
static const struct of_device_id qcom_hidma_mgmt_match[] = {
{ .compatible = "qcom,hidma-mgmt-1.0", },
{},
};
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
