[PATCH] ARM64: Add new Xilinx ZynqMP SoC
Initial version of device tree for Xilinx ZynqMP SoC.
Signed-off-by: Michal Simek
Acked-by: Sören Brinkmann
---
arch/arm64/Kconfig | 5 +
arch/arm64/boot/dts/Makefile| 1 +
arch/arm64/boot/dts/xilinx/Makefile | 5 +
arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts | 46 +
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 301
arch/arm64/configs/defconfig| 1 +
6 files changed, 359 insertions(+)
create mode 100644 arch/arm64/boot/dts/xilinx/Makefile
create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
create mode 100644 arch/arm64/boot/dts/xilinx/zynqmp.dtsi
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1b8e97331ffb..9f805cf2e0b0 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -228,6 +228,11 @@ config ARCH_XGENE
help
This enables support for AppliedMicro X-Gene SOC Family
+config ARCH_ZYNQMP
+ bool "Xilinx ZynqMP Family"
+ help
+ This enables support for Xilinx ZynqMP Family
+
endmenu
menu "Bus support"
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index e0350caf049e..ff088ec6ca5f 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -5,5 +5,6 @@ dts-dirs += cavium
dts-dirs += exynos
dts-dirs += freescale
dts-dirs += mediatek
+dts-dirs += xilinx
subdir-y := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/xilinx/Makefile
b/arch/arm64/boot/dts/xilinx/Makefile
new file mode 100644
index ..ae16427f6a4a
--- /dev/null
+++ b/arch/arm64/boot/dts/xilinx/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_ZYNQMP) += zynqmp-ep108.dtb
+
+always := $(dtb-y)
+subdir-y := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
new file mode 100644
index ..121a47fb4043
--- /dev/null
+++ b/arch/arm64/boot/dts/xilinx/zynqmp-ep108.dts
@@ -0,0 +1,46 @@
+/*
+ * dts file for Xilinx ZynqMP ep108 development board
+ *
+ * (c) Copyright 2014 - 2015, Xilinx, Inc.
+ *
+ * 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; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+/dts-v1/;
+
+/include/ "zynqmp.dtsi"
+
+/ {
+ model = "ZynqMP EP108";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x0 0x4000>;
+ };
+};
+
+&gem0 {
+ status = "okay";
+ phy-handle = <&phy0>;
+ phy-mode = "rgmii-id";
+ phy0: phy@0{
+ reg = <0>;
+ max-speed = <100>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
new file mode 100644
index ..d8402fd2dffa
--- /dev/null
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -0,0 +1,301 @@
+/*
+ * dts file for Xilinx ZynqMP
+ *
+ * (c) Copyright 2014 - 2015, Xilinx, Inc.
+ *
+ * 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; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+/ {
+ compatible = "xlnx,zynqmp";
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x0>;
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x1>;
+ };
+
+ cpu@2 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x2>;
+ };
+
+ cpu@3 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ device_type = "cpu";
+ enable-method = "psci";
+ reg = <0x3>;
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = <0 143 4>,
+<0 144 4>,
+
Re: [PATCH v5] thermal: Add QPNP PMIC temperature alarm driver
On Mon, 2015-02-23 at 16:51 -0400, Eduardo Valentin wrote: > On Thu, Feb 05, 2015 at 07:12:56PM +0200, Ivan T. Ivanov wrote: > > Add support for the temperature alarm peripheral found inside > > Qualcomm plug-and-play (QPNP) PMIC chips. The temperature alarm > > peripheral outputs a pulse on an interrupt line whenever the > > thermal over temperature stage value changes. > > > > Register a thermal sensor. The temperature reported by this thermal > > sensor device should reflect the actual PMIC die temperature if an > > ADC is present on the given PMIC. If no ADC is present, then the > > reported temperature should be estimated from the over temperature > > stage value. > > > > Cc: David Collins > > Signed-off-by: Ivan T. Ivanov > > Applying to my -linus branch. Thank you. Ivan -- 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 PATCH 1/3] eeprom: Add a simple EEPROM framework
Thanks Stephen for the comments.
On 23/02/15 23:11, Stephen Boyd wrote:
On 02/22/15 16:57, Rob Herring wrote:
On Sun, Feb 22, 2015 at 8:32 AM, Maxime Ripard
wrote:
On Fri, Feb 20, 2015 at 04:01:55PM -0600, Rob Herring wrote:
[...]
+= Data consumers =
+
+Required properties:
+
+eeproms: List of phandle and data cell specifier triplet, one triplet
+for each data cell the device might be interested in. The
+triplet consists of the phandle to the eeprom provider, then
+the offset in byte within that storage device, and the length
+in byte of the data we care about.
The problem with this is it assumes you know who the consumer is and
that it is a DT node. For example, how would you describe a serial
number?
Correct me if I miss understood.
Is serial number any different?
Am hoping that the eeprom consumer would be aware of offset and size of
serial number in the eeprom
Cant the consumer do:
eeprom-consumer {
eeproms = <&at24 0 4>;
eeprom-names = "device-serial-number";
Yes, but who is "eeprom-consumer"?
Any device that should lookup values in one of the EEPROM.
DT nodes generally describe a h/w block, but it this case, the
consumer depends on the OS, not the h/w.
Not really, or at least, not more than any similar binding we
currently have.
The fact that a MAC-address for the first ethernet chip is stored at a
given offset in a given eeprom has nothing to do with the OS.
So MAC address would be a valid use to link to a h/w device, but there
are certainly cases that don't correspond to a device.
I'm not saying you can't describe where things are, but I don't
think you should imply who is the consumer and doing so is
unnecessarily complicated.
If you only take the case of a serial number, indeed. If you take
other usage into account, you can't really do without it.
Also, the layout of EEPROM is likely very much platform specific.
Indeed, which is why it should be in the DT.
Agreed. I'm not saying the layout should not be.
Some could have a more complex structure perhaps with key ids and
linked list structure.
Then just request the size of the whole list, and parse it afterwards
in your driver?
I would do something more simple that is just a list of keys and their
location like this:
device-serial-number = ;
key1 = ;
key2 = ;
I'm sorry, but what's the difference?
It can describe the layout completely whether the fields are tied to a
h/w device or not.
What I would like to see here is the entire layout described covering
both types of fields.
I was thinking the DT might be like this on the provider side:
qfprom@100 {
reg = <0x100 0x1000>;
ranges = <0 0x100 0x1000>;
compatible = "qcom,qfprom-msm8960"
pvs-data: pvs-data@40 {
compatible = "qcom,pvs-a";
These compatibles could be optional. As it might not be required for
devices which are simple and do not require any special interpretation
of eeprom data.
reg = <0x40 0x20>,
#eeprom-cells = <0>;
Do we still need eeprom-cells if we are moving to use reg property here?
};
tsens-data: tmdata@10 {
compatible = "qcom,tsens-data-msm8960";
reg = <0x10 4>, <0x16 4>;
#eeprom-cells = <0>;
};
serial-number: serial@50 {
compatible = "qcom,serial-msm8960";
reg = <0x50 4>, <0x60 4>;
#eeprom-cells = <0>;
};
};
and then on the consumer side:
device {
eeproms = <&serial-number>;
eeprom-names = "soc-rev-id";
};
Yes, this looks good, and Sasha was also recommending something on these
lines too. Also this addresses the use cases like serial number too.
This would solve a problem where the consumer device is some standard
off-the-shelf IP block that needs to get some SoC specific calibration
data from the eeprom. I may want to interpret the bits differently
depending on which eeprom is connected to my SoC. Sometimes that data
format may be the same across many variations of the SoC (e.g. the
qcom,pvs-a node) or it may be completely different for a given SoC (e.g.
qcom,serial-msm8960 node). I imagine for other SoCs out there it could
be different depending on which eeprom the board manufacturer decides to
wire onto their board and how they choose to program the data.
So this is where I think the eeprom-cells and offset + length starts to
fall apart. It forces us to make up a bunch of different compatible
strings for our consumer device just so that we can parse the eeprom
that we decided to use for some SoC/board specific data. Instead I'd
like to see some framework that expresses exactly which eeprom is on my
board and how to interpret the bits in a way that doesn't require me to
keep refining the compatible string for my generic IP block.
I worry that if we put all those details in DT we'll end up having to
describe individual bits
Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene
Hi Rob, On Mon, Feb 23, 2015 at 10:09 PM, Rob Herring wrote: > On Mon, Feb 23, 2015 at 6:07 AM, Christoffer Dall > wrote: >> On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: >>> On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall >>> wrote: >>> > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: >>> >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar >>> >> wrote: >>> >> > In APM X-Gene, GIC register space is 64K aligned while the sizes >>> >> > mentioned >>> >> > in the dt are 4K aligned. This breaks KVM when kernel is built with >>> >> > 64K page >>> >> > size due to size alignment checking in vgic driver for VCPU Control and >>> >> > VCPU register. >>> >> > >>> >> > This patch corrects the sizes to be inline with the hardware spec. >>> >> >>> >> This does not make sense. The GIC regions are still only 4 or 8KB and >>> >> the h/w description should reflect that. For implementations using >>> >> gic-400 and the addressing decode trick, the rest of the register >>> >> range is also not safe to access given it is multiple mapped. Also, >>> >> this wastes virtual space, but I guess we don't care on 64-bit. >>> >> >>> >> KVM should be fixed to only check base address alignment. Size >>> >> alignment does not matter (if it does, then you need to fix all >>> >> register blocks). >>> >> >>> > It matters if you want to ensure that the 64K page you are assigning to >>> > a guest for the GIC virtual CPU interface contains only GIC virtual CPU >>> > mappings, and not other random stuff that the guest is not allowed to >>> > touch. >>> >>> Good point. >>> >>> > How else should this be enforced? >>> >>> Rely on correct h/w design? You'll have to repeat this every time you >>> want to do pass-thru of a device. >>> >>> What do you do if 64K mapping is not supported? Fallback to emulation >>> of the CPU interface? >> >> Agree with Peter on these two points. >> >>> >>> Are there other DTSs that need to be fixed? >>> >> Not sure really, AMD Seattle works with 64K pages IIRC. > > Well, looks we have been inconsistent here: > > arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- reg = <0x0 > 0xe111 0 0x1000>, > arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 > 0xe112f000 0 0x2000>, > arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 > 0xe114 0 0x1>, > arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 > 0xe116 0 0x1>; > > arch/arm64/boot/dts/arm/juno.dts- reg = <0x0 0x2c01 0 > 0x1000>, > arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c02f000 0 > 0x2000>, > arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c04f000 0 > 0x2000>, > arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c06f000 0 > 0x2000>; > > If we are going to use 64K sizes, can we have some consistency here > please. Which ranges really need 64KB sizes? It should only be the > VCPU interface. right? Why does XGene need 128K? If XGene is doing > address swizzling, then the CPU and VCPU base addresses are wrong. > Seattle is also wrong for the VCPU, but no one has noticed because we > don't use the DIR register IIRC. > > XGene should also add an "arm,gic-400" compatible string or something > XGene specific if in fact it is not GIC-400. X-Gene has gic-400 as an interrupt controller. Only thing is GIC pages are mapped at 64K boundary (with 64K page size) Hence CPU, VCPU interfaces has a size of 128K (2GIC pages) Regarding GICC_DIR, yes there is a problem which needs to be solved since the first page size is 64K. In XEN we already have a small fix to access GICC_DIR with 64K page offset instead of standard 4K. I remember a small discussion in this regard in past (http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266468.html) which was deferred at that time. Once this patch is accepted we can post RFC patch to address GICC_DIR and discuss further. > > I think perhaps we need a specific compatible property to indicate a > GIC-400 with address swizzling. While we could get away with using the > aliased addresses, that seems to be hard to get right and we may > regret not doing it in the long term. It would indicate at least it is > 64K page safe for example. > > Rob Thanks, Pranav -- 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/8] arm64: exynos5433: Enable ARMv8 based Exynos5433 (SoC) support
This patch adds the necessary Kconfig entries to enable support for the ARMv8 based Exynos5433 SoC. Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Chanwoo Choi Acked-by: Inki Dae --- arch/arm64/Kconfig | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 1b8e973..d83cea0 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -154,6 +154,17 @@ config ARCH_EXYNOS help This enables support for Samsung Exynos SoC family +config ARCH_EXYNOS5433 + bool "ARMv8 based Samsung Exynos5433" + select ARCH_EXYNOS + select COMMON_CLK_SAMSUNG + select HAVE_S3C_RTC if RTC_CLASS + select PINCTRL + select PINCTRL_EXYNOS + + help + This enables support for Samsung Exynos5433 SoC family + config ARCH_EXYNOS7 bool "ARMv8 based Samsung Exynos7" select ARCH_EXYNOS -- 1.8.5.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
[PATCH v4 2/8] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
Octal core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433 supports
PSCI (Power State Coordination Interface) v0.1.
This patch includes following dt node to support Exynos5433 SoC:
1. Octa core for big.LITTLE architecture
- Cortex-A53 LITTLE Quad-core
- Cortex-A57 big Quad-core
- Support PSCI v0.1
2. clock controller node:
- CMU_TOP : clocks for IMEM/FSYS/G3D/GSCL/HEVC/MSCL/G2D/MFC/PERIC/PERIS
- CMU_CPIF : clocks for LLI (Low Latency Interface)
- CMU_MIF : clocks for DRAM Memory Controller
- CMU_PERIC : clocks for UART/I2C/SPI/I2S/PCM/SPDIF/PWM/SLIMBUS
- CMU_PERIS : clocks for PMU/TMU/MCT/WDT/RTC/SECKEY/TZPC
- CMU_FSYS : clocks for USB/UFS/SDMMC/TSI/PDMA
- CMU_G2D : clocks for G2D/MDMA
- CMU_DISP : clocks for DECON/HDMI/DSIM/MIXER
- CMU_AUD : clocks for Cortex-A5/BUS/AUDIO
- CMU_BUS{0|1|2} : clocks for global data buses and global peripheral buses
- CMU_G3D : clocks for 3D Graphics Engine
- CMU_GSCL : clocks for GSCALER
- CMU_APOLLO: clocks for Cortex-A53 Quad-core processor.
- CMU_ATLAS : clocks for Cortex-A57 Quad-core processor,
CoreSight and L2 cache controller.
- CMU_MSCL : clocks for M2M (Memory to Memory) scaler and JPEG IPs.
- CMU_MFC : clocks for MFC (Multi-Format Codec) IP.
- CMU_HEVC : clocks for HEVC(High Efficiency Video Codec) decoder IP.
- CMU_ISP : clocks for FIMC-ISP/DRC/SCLC/DIS/3DNR IPs.
- CMU_CAM0 : clocks for MIPI_CSIS{0|1}/FIMC_LITE_{A|B|D}/FIMC_3AA{0|1} IPs.
- CMU_CAM1 : clocks for COrtex-A5/MIPI_CSIS2/FIMC_LITE_C/FIMC-FD IPs.
3. pinctrl node for GPIO:
- alive/aud/cpif/ese/finger/fsys/imem/nfc/peric/touch pad
4. HS (High-Speed) I2C device
5. Serial device
6. ARCH timer (arm,armv8-timer)
7. Interrupt controller (arm,gic-400)
Cc: Kukjin Kim
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Arnd Bergmann
Cc: Olof Johansson
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 698 +
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 696
2 files changed, 1394 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
new file mode 100644
index 000..c56bbf8
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
@@ -0,0 +1,698 @@
+/*
+ * Samsung's Exynos5433 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's Exynos5433 SoC pin-mux and pin-config options are listed as device
+ * tree nodes are listed in this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+&pinctrl_alive {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ interrupt-parent = <&gic>;
+ interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
+<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>;
+ #interrupt-cells = <2>;
+ };
+
+ gpa1: gpa1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ interrupt-parent = <&gic>;
+ interrupts = <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>,
+<0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>;
+ #interrupt-cells = <2>;
+ };
+
+ gpa2: gpa2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpa3: gpa3 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+};
+
+&pinctrl_aud {
+ gpz0: gpz0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpz1: gpz1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ i2s0_bus: i2s0-bus {
+ samsung,pins = "gpz0-0", "gpz0-1", "gpz0-2", "gpz0-3",
+ "gpz0-4", "gpz0-5", "gpz0-6";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <1>;
+ samsung,pin-drv = <0>;
+ };
+
+ pcm0_bus: pcm0-bus {
+ samsung,pins = "gpz1-0", "gpz1-1", "gpz1-2", "gpz1-3";
+ samsung,pin-function = <3>;
+
[PATCH v4 7/8] arm64: dts: exynos: Add ADMA dt node for Exynos5433 SoC
From: Inha Song
This patch adds ADMA (Advanced DMA) device tree node for Exynos5433 SoC.
In Exynos5433 SoC, ADMA is used for I2S audio interface.
Cc: Kukjin Kim
Signed-off-by: Inha Song
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 1c68d9e..6becaca 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -462,6 +462,17 @@
#dma-channels = <8>;
#dma-requests = <32>;
};
+
+ adma: adma@1142 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x1142 0x1000>;
+ interrupts = <0 73 0>;
+ clocks = <&cmu_aud CLK_ACLK_DMAC>;
+ clock-names = "apb_pclk";
+ #dma-cells = <1>;
+ #dma-channels = <8>;
+ #dma-requests = <32>;
+ };
};
serial_0: serial@14c1 {
--
1.8.5.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
[PATCH v4 3/8] arm64: dts: exynos: Add MSHC dt node for Exynos5433
From: Jaehoon Chung
This patch adds MSHC (Mobile Storage Host Controller) dt node for Exynos5433
SoC. MSHC is an interface between the system the SD/MMC card.
Cc: Kukjin Kim
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Arnd Bergmann
Cc: Olof Johansson
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Jaehoon Chung
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 42 ++
1 file changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 6b30123..81f428e 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -52,6 +52,9 @@
i2c9 = &hsi2c_9;
i2c10 = &hsi2c_10;
i2c11 = &hsi2c_11;
+ mshc0 = &mshc_0;
+ mshc1 = &mshc_1;
+ mshc2 = &mshc_2;
};
cpus {
@@ -683,6 +686,45 @@
status = "disabled";
};
+ mshc_0: mshc@1554 {
+ compatible = "samsung,exynos7-dw-mshc-smu";
+ interrupts = <0 225 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1554 0x2000>;
+ clocks = <&cmu_fsys CLK_ACLK_MMC0>,
+<&cmu_fsys CLK_SCLK_MMC0>;
+ clock-names = "biu", "ciu";
+ fifo-depth = <0x40>;
+ status = "disabled";
+ };
+
+ mshc_1: mshc@1555 {
+ compatible = "samsung,exynos7-dw-mshc-smu";
+ interrupts = <0 226 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1555 0x2000>;
+ clocks = <&cmu_fsys CLK_ACLK_MMC1>,
+<&cmu_fsys CLK_SCLK_MMC1>;
+ clock-names = "biu", "ciu";
+ fifo-depth = <0x40>;
+ status = "disabled";
+ };
+
+ mshc_2: mshc@1556 {
+ compatible = "samsung,exynos7-dw-mshc-smu";
+ interrupts = <0 227 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1556 0x2000>;
+ clocks = <&cmu_fsys CLK_ACLK_MMC2>,
+<&cmu_fsys CLK_SCLK_MMC2>;
+ clock-names = "biu", "ciu";
+ fifo-depth = <0x40>;
+ status = "disabled";
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <1 13 0xff04>,
--
1.8.5.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
[PATCH v4 8/8] arm64: dts: exynos: Add I2S dt node for Exynos5433 SoC
From: Inha Song
This patch adds I2S device tree node for Exynos5433 SoC.
In Exynos5433 SoC, I2S0 is used for audio interface.
Signed-off-by: Inha Song
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 6becaca..0776b6d 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -511,6 +511,23 @@
status = "disabled";
};
+ i2s0: i2s0@1144 {
+ compatible = "samsung,exynos7-i2s";
+ reg = <0x1144 0x100>;
+ dmas = <&adma 0 &adma 2>;
+ dma-names = "tx", "rx";
+ interrupts = <0 70 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cmu_aud CLK_PCLK_AUD_I2S>,
+<&cmu_aud CLK_SCLK_AUD_I2S>,
+<&cmu_aud CLK_SCLK_I2S_BCLK>;
+ clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s0_bus>;
+ status = "disabled";
+ };
+
pinctrl_alive: pinctrl@1058 {
compatible = "samsung,exynos5433-pinctrl";
reg = <0x1058 0x1000>;
--
1.8.5.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
[PATCH v4 6/8] arm64: dts: exynos: Add RTC and ADC dt node for Exynos5433 SoC
This patch adds RTC (Real Time Clock) dt node for Exynos5433 SoC and adds
ADC dt node for Exynos5433 SoC. The c1b501564c98a94b4(iio: adc: exynos_adc:
Add support for exynos7) commit supports the ADC for Exynos7. Exynos5433's ADC
IP is the same with Exynos7's ADC IP. Exynos5433 has a little different from
ADCv2 on ADC_CON2 register. Exynos5433 don't contain OSEL/ESEL /HIGHF of
ADC_CON2.
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 84be8e2..1c68d9e 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -852,6 +852,24 @@
clocks = <&xxti>;
};
+ rtc: rtc@1059 {
+ compatible = "samsung,exynos3250-rtc";
+ reg = <0x1059 0x100>;
+ interrupts = <0 385 0>, <0 386 0>;
+ status = "disabled";
+ };
+
+ adc: adc@14d1 {
+ compatible = "samsung,exynos7-adc";
+ reg = <0x14d1 0x100>;
+ interrupts = <0 438 0>;
+ clock-names = "adc";
+ clocks = <&cmu_peric CLK_PCLK_ADCIF>;
+ #io-channel-cells = <1>;
+ io-channel-ranges;
+ status = "disabled";
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <1 13 0xff04>,
--
1.8.5.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
[PATCH v4 4/8] arm64: dts: exynos: Add SPI/PDMA dt node for Exynos5433
This patch adds SPI (Serial Peripheral Interface) dt node for Exynos5433 SoC.
SPI transfers serial data by using various peripherals. SPI includes
8-bit/16-bit/32-bit shift registers to transmit and receive data. PDMA is used
for SPI communication.
Cc: Kukjin Kim
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Arnd Bergmann
Cc: Olof Johansson
Cc: Catalin Marinas
Cc: Will Deacon
Signed-off-by: Chanwoo Choi
Acked-by: Inki Dae
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 119 +
1 file changed, 119 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 81f428e..1b18fd3 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -55,6 +55,11 @@
mshc0 = &mshc_0;
mshc1 = &mshc_1;
mshc2 = &mshc_2;
+ spi0 = &spi_0;
+ spi1 = &spi_1;
+ spi2 = &spi_2;
+ spi3 = &spi_3;
+ spi4 = &spi_4;
};
cpus {
@@ -430,6 +435,35 @@
interrupts = <1 9 0xf04>;
};
+ amba {
+ compatible = "arm,amba-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pdma0: pdma@1561 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x1561 0x1000>;
+ interrupts = <0 228 0>;
+ clocks = <&cmu_fsys CLK_PDMA0>;
+ clock-names = "apb_pclk";
+ #dma-cells = <1>;
+ #dma-channels = <8>;
+ #dma-requests = <32>;
+ };
+
+ pdma1: pdma@1560 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0x1560 0x1000>;
+ interrupts = <0 246 0>;
+ clocks = <&cmu_fsys CLK_PDMA1>;
+ clock-names = "apb_pclk";
+ #dma-cells = <1>;
+ #dma-channels = <8>;
+ #dma-requests = <32>;
+ };
+ };
+
serial_0: serial@14c1 {
compatible = "samsung,exynos5433-uart";
reg = <0x14c1 0x100>;
@@ -530,6 +564,91 @@
interrupts = <0 442 0>;
};
+ spi_0: spi@14d2 {
+ compatible = "samsung,exynos7-spi";
+ reg = <0x14d2 0x100>;
+ interrupts = <0 432 0>;
+ dmas = <&pdma0 9>, <&pdma0 8>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cmu_peric CLK_PCLK_SPI0>,
+<&cmu_top CLK_SCLK_SPI0_PERIC>;
+ clock-names = "spi", "spi_busclk0";
+ samsung,spi-src-clk = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi0_bus>;
+ status = "disabled";
+ };
+
+ spi_1: spi@14d3 {
+ compatible = "samsung,exynos7-spi";
+ reg = <0x14d3 0x100>;
+ interrupts = <0 433 0>;
+ dmas = <&pdma0 11>, <&pdma0 10>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cmu_peric CLK_PCLK_SPI1>,
+<&cmu_top CLK_SCLK_SPI1_PERIC>;
+ clock-names = "spi", "spi_busclk0";
+ samsung,spi-src-clk = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_bus>;
+ status = "disabled";
+ };
+
+ spi_2: spi@14d4 {
+ compatible = "samsung,exynos7-spi";
+ reg = <0x14d4 0x100>;
+ interrupts = <0 434 0>;
+ dmas = <&pdma0 13>, <&pdma0 12>;
+ dma-names = "tx", "rx";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&cmu_peric CLK_PCLK_SPI2>,
+<&cmu_top CLK_SCLK_SPI2_PERIC>;
+ clock-names = "spi", "spi_busclk0";
+ samsung,spi-src-clk = <0>;
+ pinctrl-names = "default";
+
[PATCH v4 5/8] arm64: dts: exynos: Add PMU dt node for Exynos5433
This patch adds PMU (Power Management Unit) dt node for Exynos5433 SoC and
set the source clock for CLKOUT register as xxti .
Cc: Kukjin Kim
Signed-off-by: Chanwoo Choi
[ideal.song: Add the setting of CLKOUT register]
Signed-off-by: Inha Song
Acked-by: Inki Dae
---
Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 +
arch/arm64/boot/dts/exynos/exynos5433.dtsi| 8
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index 67b2113..a87fc43 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -10,6 +10,7 @@ Properties:
- "samsung,exynos5260-pmu" - for Exynos5260 SoC.
- "samsung,exynos5410-pmu" - for Exynos5410 SoC,
- "samsung,exynos5420-pmu" - for Exynos5420 SoC.
+ - "samsung,exynos5433-pmu" - for Exynos5433 SoC.
- "samsung,exynos7-pmu" - for Exynos7 SoC.
second value must be always "syscon".
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 1b18fd3..84be8e2 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -844,6 +844,14 @@
status = "disabled";
};
+ pmu_system_controller: system-controller@105c {
+ compatible = "samsung,exynos5433-pmu", "syscon";
+ reg = <0x105c 0x5008>;
+ #clock-cells = <1>;
+ clock-names = "clkout16";
+ clocks = <&xxti>;
+ };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <1 13 0xff04>,
--
1.8.5.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
[PATCH v4 0/8] arm64: Add the support for new Exynos5433 SoC
This patchset adds new 64-bit Exynos5433 Samsung SoC which contains quad
Cortex-A57 and quad Cortex-A53. It is desigend with the 20nm low power process.
This patchset is based on Linux 4.0-rc1.
Depends on:
- This patch-set has the dependency on Exynos5433 clock driver[1][2] and
pinctrl driver[3].
The Exynos5433 clock controller patch-set[1][2] was merged by Sylwester Nawrocki
and Exynos5433's pinctrl patch[3] receviced the acked message by Tomasz Figa.
(http://git.linuxtv.org/cgit.cgi/snawrocki/samsung.git/,
branch:for-v3.20/clk/next)
[1] [PATCH v5 00/13] clk: samsung: Add the support for exynos5433 clocks
- https://lkml.org/lkml/2015/2/2/368
[2] [PATCH v3 0/9] clk: samsung: Add clocks for remaining domains of Exynos5433
- https://lkml.org/lkml/2015/2/2/784
[3] [PATCH v4] pinctrl: exynos: Add support for Exynos5433
- https://lkml.org/lkml/2015/2/23/728
Changelog:
Changes from v3:
(https://lkml.org/lkml/2015/2/12/65)
- Rebased it on Linux 4.0-rc1.
- Remove ARM_GIC and ARM_AMBA dependency because CONFIG_ARM64 already included
them.
Changes from v2:
(https://lkml.org/lkml/2014/12/2/134)
: Fix the range of GICC memory map (0x1000 -> 0x2000)
: Fix address space of 'range' property under 'soc' node
: Add ADMA / I2S dt node for sound playback/capture
- Select ARM_AMBA/ARM_GIC/HAVE_S3C_RTC for Exynos5433 in arch/arm64/Kconfig
- Send separate patch-set for Exynos5433 clock controller[1][2] and pinctrl[3]
Changes from v1:
(https://lkml.org/lkml/2014/11/27/92)
- Merge two patches (patch2, patch3) to solve incomplete description
- Exynos5433 Clock driver
: Fix wrong register and code clean by using space instead of tab
: Add CLK_IGNORE_UNUSED flag to pclk_sysreg_* clock for accessing system
control register
: Remove duplicate definition on the patch for CMU_BUS{0|1|2} domain
- Exynos5433 SoC DTS
: Remove un-supported properties of arch_timer
: Remove 'clock-frequency' property from 'cpus' dt node
: Fix interrupt type from edge rising triggering to level high triggering
because Cortex-A53/A57 use level triggering.
: Fix defult address-size/size-celss from 1 to 2 because Exynos5433 is 64-bit
SoC
: Modify 'fin_pll' dt node to remove un-needed and ugly code
: Move 'chipid' dt node under 'soc'
: Use lowercase on all case in exynos5433.dtsi
: Add PSCI dt node for secondary cpu boot
: Add 'samsung,exynos5433' compatible to MCT dt node
- Divide pinctrl patch from this patchset
- Add new following patches:
: clocksource: exynos_mct: Add the support for Exynos 64bit SoC
: arm64: Enable Exynos5433 SoC in the defconfig
Chanwoo Choi (5):
arm64: exynos5433: Enable ARMv8 based Exynos5433 (SoC) support
arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
arm64: dts: exynos: Add SPI/PDMA dt node for Exynos5433
arm64: dts: exynos: Add PMU dt node for Exynos5433
arm64: dts: exynos: Add RTC and ADC dt node for Exynos5433 SoC
Inha Song (2):
arm64: dts: exynos: Add ADMA dt node for Exynos5433 SoC
arm64: dts: exynos: Add I2S dt node for Exynos5433 SoC
Jaehoon Chung (1):
arm64: dts: exynos: Add MSHC dt node for Exynos5433
.../devicetree/bindings/arm/samsung/pmu.txt| 1 +
arch/arm64/Kconfig | 11 +
arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 698
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 911 +
4 files changed, 1621 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi
--
1.8.5.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 v4 02/10] mtd: st_spi_fsm: Fetch boot device locations from DT match tables
On Tue, Feb 10, 2015 at 03:46:34PM +0800, Lee Jones wrote: > On Thu, 05 Feb 2015, Brian Norris wrote: > > On Wed, Jan 21, 2015 at 03:24:20PM +, Lee Jones wrote: > > > To trim down on the amount of properties used by this driver and to > > > conform > > > to the newly agreed method of acquiring syscfg registers/offsets, we now > > > obtain this information using match tables. > > > > Where did this agreement happen? Are you only referring to the previous > > patch? > > I think your interpretation of the above text and my intentions are > not the same. To be clear: I'm simply asking what do you mean by "agreed method". I never agreed to syscfg registers/offsets. So who did? Are you agreeing with yourself? > I have no idea why there is a different configuration > depending on if we booted from SPI NOR or not and hence can not answer > your query below. Seriously? That's all you can come up with? Sheesh. And you wonder why I called you out on not understanding the code that you're sending me. > The description above is pertaining to the > different/new way in which we obtain and request syscfg registers. OK. So you're dealing with the "how" but not the "why." That is not a reasonable way to develop good code. > In previous incarnations of this patchset, we were defining new vendor > specific properties in order to request and register and the mask: > > st,boot-device-reg = <0x958>; > st,boot-device-spi = <0x1a>; > > ... this is not optimal, as DT properties should only be created if > there are no other way to obtain platform specific information. As > there are few supported platforms and this configuration does not > change through variants, we are now supplying it via static tables, > which can be obtained easily using the DT match framework. I understand what you're doing with syscfg and these register offsets. But if you follow the code as to what they're actually producing, you see that it yields the 'booted_from_spi' boolean. That's a pretty simple concept. Now, unless you were able to provide an additional enlightening viewpoint, then the following paragraph likely all holds true: > > Also, I realized that all this boot device / syscfg gymnastics is just > > for one simple fact; your driver is trying to hide the fact that your > > system can't reliably handle 4-byte addressing for the boot device. Even > > if you try your best at toggling 4-byte addressing before/after each > > read/write/erase, you still are vulnerable to power cuts during the > > operation. This is a bad design, and we have consistently agreed that we > > aren't going to work around that in Linux. > > > > Better solutions: hook up a reset line to your flash; improve your boot > > ROM / bootloader to handle 4-byte addressing for large flash. > > You have reached the boundaries of my knowledge on this. Perhaps > Angus (BCC'ed) would be kind enough to assist. And so we have also reached the boundaries of my willingness to review your code. There's a significant technical point here that drove you to define several new DT compatible strings. I propose (and am now more convinced) that this is not actually necessary. But apparently you are not equipped to have a discussion about this. I'm tempted to: git rm drivers/mtd/devices/st_spi_fsm.c (Along with the appropriate Kconfig and Makefile entries, of course.) > > What's the possibility of dropping all this 4-byte address toggling > > shenanigans? This will be a blocker to merging with spi-nor.c. Brian -- 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 2/2] ARM: shmobile: silk: add SDHI0/1 DT support
Hi Sergei,
On Sun, Feb 22, 2015 at 6:54 AM, Sergei Shtylyov
wrote:
> Hello.
>
> On 02/22/2015 03:45 AM, Magnus Damm wrote:
>
>>> Define the SILK board dependent parts of the SDHI0 (connected to SDIO
>>> Wi-Fi
>>> chip) and SDHI1 (connected to micro-SD slot) device nodes along with
>>> the
>>> necessary voltage regulators.
>
>
>>> Based on the original patch by Vladimir Barinov
>>> .
>
>
>>> Signed-off-by: Sergei Shtylyov
>
>
>> Thanks for your patch. One question - above you write that SDHI1 is
>> micro-SD...
>
>
>Yes, have double-checked now.
>
>
>>> @@ -100,3 +159,25 @@
>>> non-removable;
>>> status = "okay";
>>> };
>>> +
>>> +&sdhi0 {
>>> + pinctrl-0 = <&sdhi0_pins>;
>>> + pinctrl-names = "default";
>>> +
>>> + vmmc-supply = <&vcc_sdhi0>;
>>> + vqmmc-supply = <&vccq_sdhi0>;
>>> + cd-gpios = <&gpio6 6 GPIO_ACTIVE_LOW>;
>>> + wp-gpios = <&gpio6 7 GPIO_ACTIVE_LOW>;
>>> + status = "okay";
>>> +};
>>> +
>>> +&sdhi1 {
>>> + pinctrl-0 = <&sdhi1_pins>;
>>> + pinctrl-names = "default";
>>> +
>>> + vmmc-supply = <&vcc_sdhi1>;
>>> + vqmmc-supply = <&vccq_sdhi1>;
>>> + cd-gpios = <&gpio6 14 GPIO_ACTIVE_LOW>;
>>> + wp-gpios = <&gpio6 15 GPIO_ACTIVE_LOW>;
>>> + status = "okay";
>>> +};
>
>
>> ... however here the WP signal is assigned.
>
>
>> I believe micro-SD doesn't use the WP signal, so either I'm wrong or
>> the patch needs to be updated to reflect reality. =)
>
>
>Both seem correct: SD1_WP signal is just tied to VCCQ_SD1. Do you think
> we should still drop it?
If the signal is not exposed to the card connector then I believe the
correct approach is to omit it. So yes, please drop it.
>> Also, I doubt that an on-board SDIO module makes use of CD and/or WP
>> signals?
>
>Those two are tied to VCCQ_SD0 as well. Do you think we should drop them?
Since the on-board SDIO chip does not support hotplug and cannot be
write-protected I think those should be dropped too.
Thanks,
/ magnus
--
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/7] OPP: Redefine bindings to overcome shortcomings
On 24 February 2015 at 04:06, Kevin Hilman wrote: > Viresh Kumar writes: >> +Optional properties: >> +- shared-opp: Indicates that device nodes using this OPP descriptor's >> phandle >> + switch their DVFS state together, i.e. they share clock lines. > > ... or shared voltage rail? The point is that they switch their frequencies together. Which means, sharing voltage rail + PLLs .. How do we write it properly ? >> + Missing property means devices have independent clock lines, but they >> share OPPs. > > huh? missing 'shared-opp' property means they share OPPs? -ECONFUSED. Right. s/OPPs/OPP tables .. Makes sense now ? > Maybe I missed some of the discussion of why this property is needed, > but I'm left wondering why it's needed explicitly. With the OPPs as So that same OPP tables can be shared across CPUs which don't share voltage rails.. For example, Krait. We only need to define single set of tables and all CPUs will point to it. But this property would be missing in that case as CPUs don't change their DVFS state together. > part of the CPU nodes, shouldnt' the "shared" nature of the OPP be > easily derived from the clock and or regulator (opp-supply) property of > the CPU nodes? IOW, if two CPU nodes share a clock and/or a regulator, > the framework should know it's "shared". So you missed all earlier discussions :), there were lots of concerns around that. And the best solution we found out is to do it this way.. - There can be multiple clocks/regulators present in CPU's DT node and that makes it complex. - There are cases where immediate clock parents of CPUs are different but somewhere higher in the hierarchy they have a common ancestor, which is responsible for rate change. And so it would be difficult to find out if they share clock/regulator or not.. - People wanted it to be some static data instead of trying to find with help of some algorithms.. > Or, were there other reasons besides clocks/regulators why this property > was needed (if so, the documentation doesn't describe them.) I am not sure if we need to mention anything else.. But yes, please let me know if it can be improved a bit. -- 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] mtd:spi-nor: Add Altera EPCQ Driver
On Mon, Feb 23, 2015 at 09:30:09AM +0800, Viet Nga Dao wrote: > Hi, > It has been nearly 2 weeks since i submitted this patch. Could you > please help to review? Those two weeks were during the merge window, so I wasn't queueing anything up. And there are things that have waited longer, anyway. My time is unfortunately finite. I'll get to your patch eventually. > On Tue, Feb 17, 2015 at 9:33 AM, Viet Nga Dao wrote: > > Hi Brian, > > Could you please help me to review through this 2nd version? > > > > On Wed, Feb 11, 2015 at 12:53 PM, Viet Nga Dao wrote: > >> From: Viet Nga Dao > >> > >> Altera EPCQ Controller is a soft IP which enables access to Altera EPCQ and > >> EPCS flash chips. This patch adds driver for these devices. > >> > >> Signed-off-by: VIET NGA DAO > >> > >> --- > >> v2: > >> - Change to spi_nor structure > >> - Add lock and unlock functions for spi_nor > >> - Simplify the altera_epcq_lock function > >> - Replace reg by compatible in device tree ... Brian -- 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] clocksource: mips-gic: Allow GIC clock to be specified in device-tree
As an alternative to the "clock-frequency" property, allow the GIC
timer operating clock to be specified in the device-tree instead.
This is useful on systems which use common clock or where the GIC
is not fixed to a particular frequency and is instead, for example,
derived from the CPU clock.
Signed-off-by: Andrew Bresticker
Cc: James Hogan
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
---
.../devicetree/bindings/interrupt-controller/mips-gic.txt | 5 +
drivers/clocksource/mips-gic-timer.c | 10 +-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/mips-gic.txt
b/Documentation/devicetree/bindings/interrupt-controller/mips-gic.txt
index 5a65478..aae4c38 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/mips-gic.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/mips-gic.txt
@@ -27,8 +27,13 @@ Optional properties:
Required properties for timer sub-node:
- compatible : Should be "mti,gic-timer".
- interrupts : Interrupt for the GIC local timer.
+
+Optional properties for timer sub-node:
+- clocks : GIC timer operating clock.
- clock-frequency : Clock frequency at which the GIC timers operate.
+Note that one of clocks or clock-frequency must be specified.
+
Example:
gic: interrupt-controller@1bdc {
diff --git a/drivers/clocksource/mips-gic-timer.c
b/drivers/clocksource/mips-gic-timer.c
index 3bd31b1..1809f52 100644
--- a/drivers/clocksource/mips-gic-timer.c
+++ b/drivers/clocksource/mips-gic-timer.c
@@ -5,6 +5,7 @@
*
* Copyright (C) 2012 MIPS Technologies, Inc. All rights reserved.
*/
+#include
#include
#include
#include
@@ -146,11 +147,18 @@ void __init gic_clocksource_init(unsigned int frequency)
static void __init gic_clocksource_of_init(struct device_node *node)
{
+ struct clk *clk;
+
if (WARN_ON(!gic_present || !node->parent ||
!of_device_is_compatible(node->parent, "mti,gic")))
return;
- if (of_property_read_u32(node, "clock-frequency", &gic_frequency)) {
+ clk = of_clk_get(node, 0);
+ if (!IS_ERR(clk)) {
+ gic_frequency = clk_get_rate(clk);
+ clk_put(clk);
+ } else if (of_property_read_u32(node, "clock-frequency",
+ &gic_frequency)) {
pr_err("GIC frequency not specified.\n");
return;
}
--
2.2.0.rc0.207.ga3a616c
--
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/2] pinctrl: Add Pistachio SoC pin control binding document
Add a device-tree binding document for the pin controller present on the IMG Pistachio SoC. Signed-off-by: Damien Horsley Signed-off-by: Andrew Bresticker Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala --- .../bindings/pinctrl/img,pistachio-pinctrl.txt | 217 + 1 file changed, 217 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/img,pistachio-pinctrl.txt diff --git a/Documentation/devicetree/bindings/pinctrl/img,pistachio-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/img,pistachio-pinctrl.txt new file mode 100644 index 000..9660d68 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/img,pistachio-pinctrl.txt @@ -0,0 +1,217 @@ +Imagination Technologies Pistachio SoC pin controller += + +The Pistachio pin controller is a combined GPIO controller, (GPIO) interrupt +controller, and pinmux + pinconf device. Pistachio has 99 pins, 90 of which +are MFIOs which can be configured as GPIOs. The 90 GPIOs are divided into +6 banks of up to 16 GPIOs each. The GPIO banks are represented as sub-nodes +of the pad controller node. + +Please refer to pinctrl-bindings.txt, ../gpio/gpio.txt, and +../interrupt-controller/interrupts.txt for generic information regarding +pin controller, GPIO, and interrupt bindings. + +Required properties for pin controller node: + + - compatible: "img,pistachio-pinctrl". + - reg: Address range of the pinctrl registers. + +Required properties for GPIO bank sub-nodes: + + - interrupts: Interrupt line for the GPIO bank. + - gpio-controller: Indicates the device is a GPIO controller. + - #gpio-cells: Must be two. The first cell is the GPIO pin number and the + second cell indicates the polarity. See for + a list of possible values. + - interrupt-controller: Indicates the device is an interrupt controller. + - #interrupt-cells: Must be two. The first cell is the GPIO pin number and + the second cell encodes the interrupt flags. See +for a list of valid flags. + +Note that the GPIO bank sub-nodes *must* be listed in order. + +Required properties for pin configuration sub-nodes: + + - pins: List of pins to which the configuration applies. See below for a + list of possible pins. + +Optional properties for pin configuration sub-nodes: + + - function: Mux function for the specified pins. This is not applicable for + non-MFIO pins. See below for a list of valid functions for each pin. + - bias-high-impedance: Enable high-impedance mode. + - bias-pull-up: Enable weak pull-up. + - bias-pull-down: Enable weak pull-down. + - bias-bus-hold: Enable bus-keeper mode. + - drive-strength: Drive strength in mA. Supported values: 2, 4, 8, 12. + - input-schmitt-enable: Enable Schmitt trigger. + - input-schmitt-disable: Disable Schmitt trigger. + - slew-rate: Slew rate control. 0 for slow, 1 for fast. + +PinFunctions +---- +mfio0 spim1 +mfio1 spim1, spim0, uart1 +mfio2 spim1, spim0, uart1 +mfio3 spim1 +mfio4 spim1 +mfio5 spim1 +mfio6 spim1 +mfio7 spim1 +mfio8 spim0 +mfio9 spim0 +mfio10 spim0 +mfio11 spis +mfio12 spis +mfio13 spis +mfio14 spis +mfio15 sdhost, mips_trace_clk, mips_trace_data +mfio16 sdhost, mips_trace_dint, mips_trace_data +mfio17 sdhost, mips_trace_trigout, mips_trace_data +mfio18 sdhost, mips_trace_trigin, mips_trace_data +mfio19 sdhost, mips_trace_dm, mips_trace_data +mfio20 sdhost, mips_trace_probe_n, mips_trace_data +mfio21 sdhost, mips_trace_data +mfio22 sdhost, mips_trace_data +mfio23 sdhost +mfio24 sdhost +mfio25 sdhost +mfio26 sdhost +mfio27 sdhost +mfio28 i2c0, spim0 +mfio29 i2c0, spim0 +mfio30 i2c1, spim0 +mfio31 i2c1, spim1 +mfio32 i2c2 +mfio33 i2c2 +mfio34 i2c3 +mfio35 i2c3 +mfio36 i2s_out, audio_clk_in +mfio37 i2s_out, debug_raw_cca_ind +mfio38 i2s_out, debug_ed_sec20_cca_ind +mfio39 i2s_out, debug_ed_sec40_cca_ind +mfio40 i2s_out, debug_agc_done_0 +mfio41 i2s_out, debug_agc_done_1 +mfio42 i2s_out, debug_ed_cca_ind +mfio43 i2s_out, debug_s2l_done +mfio44 i2s_out +mfio45 i2s_dac_clk, audio_sync +mfio46 audio_trigger +mfio47 i2s_in +mfio48 i2s_in +mfio49 i2s_in +mfio50 i2s_in +mfio51 i2s_in +mfio52 i2s_in +mfio53 i2s_in +mfio54 i2s_in, spdif_in +mfio55 uart0, spim0, spim1 +mfio56 uart0, spim0, spim1 +mfio57 uart0, spim
[PATCH 2/2] pinctrl: Add Pistachio SoC pin control driver
Add a driver for the pin controller present on the IMG Pistachio SoC.
This driver provides pinmux and pinconfig operations as well as GPIO
and IRQ chips for the GPIO banks.
Signed-off-by: Damien Horsley
Signed-off-by: Govindraj Raja
Signed-off-by: Andrew Bresticker
---
drivers/pinctrl/Kconfig |6 +
drivers/pinctrl/Makefile|1 +
drivers/pinctrl/pinctrl-pistachio.c | 1513 +++
3 files changed, 1520 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-pistachio.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index ee9f44a..c0194a1 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -126,6 +126,12 @@ config PINCTRL_SIRF
select PINMUX
select GPIOLIB_IRQCHIP
+config PINCTRL_PISTACHIO
+ def_bool y if MACH_PISTACHIO
+ select PINMUX
+ select GENERIC_PINCONF
+ select GPIOLIB_IRQCHIP
+
config PINCTRL_ST
bool
depends on OF
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 0475206..a01ab9a 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_PINCTRL_BCM281XX)+= pinctrl-bcm281xx.o
obj-$(CONFIG_PINCTRL_FALCON) += pinctrl-falcon.o
obj-$(CONFIG_PINCTRL_MESON)+= meson/
obj-$(CONFIG_PINCTRL_PALMAS) += pinctrl-palmas.o
+obj-$(CONFIG_PINCTRL_PISTACHIO)+= pinctrl-pistachio.o
obj-$(CONFIG_PINCTRL_ROCKCHIP) += pinctrl-rockchip.o
obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o
obj-$(CONFIG_PINCTRL_SIRF) += sirf/
diff --git a/drivers/pinctrl/pinctrl-pistachio.c
b/drivers/pinctrl/pinctrl-pistachio.c
new file mode 100644
index 000..e9ea5e6
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-pistachio.c
@@ -0,0 +1,1513 @@
+/*
+ * Pistachio SoC pinctrl driver
+ *
+ * Copyright (C) 2014 Imagination Technologies Ltd.
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pinctrl-utils.h"
+
+#define PADS_SCHMITT_EN0 0x000
+#define PADS_SCHMITT_EN_REG(pin) (PADS_SCHMITT_EN0 + 0x4 * ((pin) / 32))
+#define PADS_SCHMITT_EN_BIT(pin) BIT((pin) % 32)
+
+#define PADS_PU_PD00x040
+#define PADS_PU_PD_REG(pin)(PADS_PU_PD0 + 0x4 * ((pin) / 16))
+#define PADS_PU_PD_SHIFT(pin) (2 * ((pin) % 16))
+#define PADS_PU_PD_MASK0x3
+#define PADS_PU_PD_HIGHZ 0x0
+#define PADS_PU_PD_UP 0x1
+#define PADS_PU_PD_DOWN0x2
+#define PADS_PU_PD_BUS 0x3
+
+#define PADS_FUNCTION_SELECT0 0x0c0
+#define PADS_FUNCTION_SELECT1 0x0c4
+#define PADS_FUNCTION_SELECT2 0x0c8
+#define PADS_SCENARIO_SELECT 0x0f8
+
+#define PADS_SLEW_RATE00x100
+#define PADS_SLEW_RATE_REG(pin)(PADS_SLEW_RATE0 + 0x4 * ((pin)
/ 32))
+#define PADS_SLEW_RATE_BIT(pin)BIT((pin) % 32)
+
+#define PADS_DRIVE_STRENGTH0 0x120
+#define PADS_DRIVE_STRENGTH_REG(pin) \
+ (PADS_DRIVE_STRENGTH0 + 0x4 * ((pin) / 16))
+#define PADS_DRIVE_STRENGTH_SHIFT(pin) (2 * ((pin) % 16))
+#define PADS_DRIVE_STRENGTH_MASK 0x3
+#define PADS_DRIVE_STRENGTH_2MA0x0
+#define PADS_DRIVE_STRENGTH_4MA0x1
+#define PADS_DRIVE_STRENGTH_8MA0x2
+#define PADS_DRIVE_STRENGTH_12MA 0x3
+
+#define GPIO_BANK_BASE(bank) (0x200 + 0x24 * (bank))
+
+#define GPIO_BIT_EN0x00
+#define GPIO_OUTPUT_EN 0x04
+#define GPIO_OUTPUT0x08
+#define GPIO_INPUT 0x0c
+#define GPIO_INPUT_POLARITY0x10
+#define GPIO_INTERRUPT_TYPE0x14
+#define GPIO_INTERRUPT_TYPE_LEVEL 0x0
+#define GPIO_INTERRUPT_TYPE_EDGE 0x1
+#define GPIO_INTERRUPT_EDGE0x18
+#define GPIO_INTERRUPT_EDGE_SINGLE 0x0
+#define GPIO_INTERRUPT_EDGE_DUAL 0x1
+#define GPIO_INTERRUPT_EN 0x1c
+#define GPIO_INTERRUPT_STATUS 0x20
+
+struct pistachio_function {
+ const char *name;
+ const char * const *groups;
+ unsigned int ngroups;
+ const int *scenarios;
+ unsigned int nscenarios;
+ unsigned int scenario_reg;
+ unsigned int scenario_shift;
+ unsigned int scenario_mask;
+};
+
+struct pistachio_pin_group {
+ const char *name;
+ unsigned int pin;
+ int mux_option[3];
+ int mux_reg;
+ int mux_shift;
+ int mux_mask;
+};
+
+struct pistachio_gpio_bank {
+ struct pistachio_pinctrl
[PATCH 0/2] pinctrl: Support for IMG Pistachio
This series adds support for the pin and GPIO controllers on the IMG Pistachio SoC. Pistachio's pin controller manages 99 pins, 90 of which are MFIOs which can be muxed between multiple functions or used as GPIOs. The GPIO control for the 90 MFIOs is broken up into banks of 16. While this driver supports only Pistachio, it should hopefully be easy to extend it to support future IMG SoCs. Test on an IMG Pistachio BuB. Based on 4.0-rc1 + my series adding Pistachio platform support [1], which introduces the MACH_PISTACHIO Kconfig symbol. A branch with this series and the dependent patches is available at [2]. I'd like this to go through the MIPS tree with Linus'/Alex's ACKs if possible. Cc: Ezequiel Garcia Cc: James Hartley Cc: James Hogan [1] https://lkml.org/lkml/2015/2/23/694 [2] https://github.com/abrestic/linux/tree/pistachio-pinctrl-v1 Andrew Bresticker (2): pinctrl: Add Pistachio SoC pin control binding document pinctrl: Add Pistachio SoC pin control driver .../bindings/pinctrl/img,pistachio-pinctrl.txt | 217 +++ drivers/pinctrl/Kconfig|6 + drivers/pinctrl/Makefile |1 + drivers/pinctrl/pinctrl-pistachio.c| 1513 4 files changed, 1737 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/img,pistachio-pinctrl.txt create mode 100644 drivers/pinctrl/pinctrl-pistachio.c -- 2.2.0.rc0.207.ga3a616c -- 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 4/5] MIPS: Add support for the IMG Pistachio SoC
Add initial support for boards based on the Imagination Pistachio SoC. Pistachio is based on a dual-core MIPS interAptiv CPU and will boot using device-tree. Signed-off-by: Andrew Bresticker --- arch/mips/Kbuild.platforms | 1 + arch/mips/Kconfig | 27 ++ arch/mips/include/asm/mach-pistachio/gpio.h | 21 + arch/mips/include/asm/mach-pistachio/irq.h | 18 arch/mips/pistachio/Makefile| 1 + arch/mips/pistachio/Platform| 8 ++ arch/mips/pistachio/init.c | 131 arch/mips/pistachio/irq.c | 28 ++ arch/mips/pistachio/time.c | 52 +++ 9 files changed, 287 insertions(+) create mode 100644 arch/mips/include/asm/mach-pistachio/gpio.h create mode 100644 arch/mips/include/asm/mach-pistachio/irq.h create mode 100644 arch/mips/pistachio/Makefile create mode 100644 arch/mips/pistachio/Platform create mode 100644 arch/mips/pistachio/init.c create mode 100644 arch/mips/pistachio/irq.c create mode 100644 arch/mips/pistachio/time.c diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms index e5fc463..2298baa 100644 --- a/arch/mips/Kbuild.platforms +++ b/arch/mips/Kbuild.platforms @@ -23,6 +23,7 @@ platforms += netlogic platforms += paravirt platforms += pmcs-msp71xx platforms += pnx833x +platforms += pistachio platforms += ralink platforms += rb532 platforms += sgi-ip22 diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index c7a1690..343b238 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -352,6 +352,33 @@ config MACH_LOONGSON1 the ICT (Institute of Computing Technology) and the Chinese Academy of Sciences. +config MACH_PISTACHIO + bool "IMG Pistachio SoC based boards" + select ARCH_REQUIRE_GPIOLIB + select BOOT_ELF32 + select BOOT_RAW + select CEVT_R4K + select CLKSRC_MIPS_GIC + select COMMON_CLK + select CSRC_R4K + select DMA_MAYBE_COHERENT + select IRQ_CPU + select LIBFDT + select MFD_SYSCON + select MIPS_CPU_SCACHE + select MIPS_GIC + select PINCTRL + select REGULATOR + select SYS_HAS_CPU_MIPS32_R2 + select SYS_SUPPORTS_32BIT_KERNEL + select SYS_SUPPORTS_LITTLE_ENDIAN + select SYS_SUPPORTS_MIPS_CPS + select SYS_SUPPORTS_MULTITHREADING + select SYS_SUPPORTS_ZBOOT + select USE_OF + help + This enables support for the IMG Pistachio SoC platform. + config MIPS_MALTA bool "MIPS Malta board" select ARCH_MAY_HAVE_PC_FDC diff --git a/arch/mips/include/asm/mach-pistachio/gpio.h b/arch/mips/include/asm/mach-pistachio/gpio.h new file mode 100644 index 000..6c1649c --- /dev/null +++ b/arch/mips/include/asm/mach-pistachio/gpio.h @@ -0,0 +1,21 @@ +/* + * Pistachio IRQ setup + * + * Copyright (C) 2014 Google, Inc. + * + * 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. + */ + +#ifndef __ASM_MACH_PISTACHIO_GPIO_H +#define __ASM_MACH_PISTACHIO_GPIO_H + +#include + +#define gpio_get_value __gpio_get_value +#define gpio_set_value __gpio_set_value +#define gpio_cansleep __gpio_cansleep +#define gpio_to_irq__gpio_to_irq + +#endif /* __ASM_MACH_PISTACHIO_GPIO_H */ diff --git a/arch/mips/include/asm/mach-pistachio/irq.h b/arch/mips/include/asm/mach-pistachio/irq.h new file mode 100644 index 000..b94a09a --- /dev/null +++ b/arch/mips/include/asm/mach-pistachio/irq.h @@ -0,0 +1,18 @@ +/* + * Pistachio IRQ setup + * + * Copyright (C) 2014 Google, Inc. + * + * 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. + */ + +#ifndef __ASM_MACH_PISTACHIO_IRQ_H +#define __ASM_MACH_PISTACHIO_IRQ_H + +#define NR_IRQS 256 + +#include_next + +#endif /* __ASM_MACH_PISTACHIO_IRQ_H */ diff --git a/arch/mips/pistachio/Makefile b/arch/mips/pistachio/Makefile new file mode 100644 index 000..32189c6 --- /dev/null +++ b/arch/mips/pistachio/Makefile @@ -0,0 +1 @@ +obj-y += init.o irq.o time.o diff --git a/arch/mips/pistachio/Platform b/arch/mips/pistachio/Platform new file mode 100644 index 000..d80cd61 --- /dev/null +++ b/arch/mips/pistachio/Platform @@ -0,0 +1,8 @@ +# +# IMG Pistachio SoC +# +platform-$(CONFIG_MACH_PISTACHIO) += pistachio/ +cflags-$(CONFIG_MACH_PISTACHIO)+= \ + -I$(srctree)/arch/mips/include/asm/mach-pistachio +load-$(CONFIG_MACH_PISTACHIO) += 0x8040 +zload-$(CONFIG_MACH_PISTACHIO) += 0x8100 diff --git a/arch/mips/pistachio/init.c b/arch/mips/pistachio/init.c new file mode 100644 index 000..0c3bd72
[PATCH 3/5] MIPS: Document Pistachio boot protocol and device-tree bindings
The Pistachio SoC boots only with device-tree. Document the required
properties and nodes as well as the boot protocol between the bootlaoder
and the kernel.
Signed-off-by: Andrew Bresticker
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
---
.../devicetree/bindings/mips/img/pistachio.txt | 40 ++
1 file changed, 40 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mips/img/pistachio.txt
diff --git a/Documentation/devicetree/bindings/mips/img/pistachio.txt
b/Documentation/devicetree/bindings/mips/img/pistachio.txt
new file mode 100644
index 000..18522b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/img/pistachio.txt
@@ -0,0 +1,40 @@
+Imagination Pistachio SoC
+=
+
+Required properties:
+
+ - compatible: Must include "img,pistachio".
+
+CPU nodes:
+--
+A "cpus" node is required. Required properties:
+ - #address-cells: Must be 1.
+ - #size-cells: Must be 0.
+A CPU sub-node is also required for at least CPU 0. Since the topology may
+be probed via CPS, it is not necessary to specify secondary CPUs. Required
+propertis:
+ - device_type: Must be "cpu".
+ - compatible: Must be "mti,interaptiv".
+ - reg: CPU number.
+ - clocks: Must include the CPU clock. See ../../clock/clock-bindings.txt for
+ details on clock bindings.
+Example:
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "mti,interaptiv";
+ reg = <0>;
+ clocks = <&clk_core CLK_MIPS>;
+ };
+ };
+
+
+Boot protocol:
+--
+The bootloader must pass the following arguments to the kernel:
+ - $a0: 0x0.
+ - $a1: 0x.
+ - $a2: Physical address of the flattened device-tree blob.
--
2.2.0.rc0.207.ga3a616c
--
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 2/5] MIPS: Allow platforms to specify the decompressor load address
Platforms which use raw zboot images may need to link the image at a fixed address if there is no other way to communicate the load address to the bootloader. Allow the per-platform Kbuild files to specify an optional zboot image load address (zload-y) and fall back to calc_vmlinuz_load_addr if unset. Signed-off-by: Andrew Bresticker Cc: Lars-Peter Clausen --- arch/mips/boot/compressed/Makefile | 6 -- arch/mips/jz4740/Platform | 1 + 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/mips/boot/compressed/Makefile b/arch/mips/boot/compressed/Makefile index 61af6b6..82d0b13 100644 --- a/arch/mips/boot/compressed/Makefile +++ b/arch/mips/boot/compressed/Makefile @@ -12,6 +12,8 @@ # Author: Wu Zhangjin # +include $(srctree)/arch/mips/Kbuild.platforms + # set the default size of the mallocing area for decompressing BOOT_HEAP_SIZE := 0x40 @@ -66,8 +68,8 @@ $(obj)/piggy.o: $(obj)/dummy.o $(obj)/vmlinux.bin.z FORCE # Calculate the load address of the compressed kernel image hostprogs-y := calc_vmlinuz_load_addr -ifeq ($(CONFIG_MACH_JZ4740),y) -VMLINUZ_LOAD_ADDRESS := 0x8060 +ifneq ($(zload-y),) +VMLINUZ_LOAD_ADDRESS := $(zload-y) else VMLINUZ_LOAD_ADDRESS = $(shell $(obj)/calc_vmlinuz_load_addr \ $(obj)/vmlinux.bin $(VMLINUX_LOAD_ADDRESS)) diff --git a/arch/mips/jz4740/Platform b/arch/mips/jz4740/Platform index ba91be9..c41d300 100644 --- a/arch/mips/jz4740/Platform +++ b/arch/mips/jz4740/Platform @@ -1,3 +1,4 @@ platform-$(CONFIG_MACH_JZ4740) += jz4740/ cflags-$(CONFIG_MACH_JZ4740) += -I$(srctree)/arch/mips/include/asm/mach-jz4740 load-$(CONFIG_MACH_JZ4740) += 0x8001 +zload-$(CONFIG_MACH_JZ4740)+= 0x8060 -- 2.2.0.rc0.207.ga3a616c -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] MIPS: Initial IMG Pistachio SoC support
This series adds basic support for the Imagination Technologies Pistachio
SoC. Pistachio will boot using device-tree only. v4.0-rc1 already includes
support for several of the peripherals on Pistachio, including MMC, SPI,
I2C, DMA, watchdog timer, PWM, and IR. Clock and pinctrl support for
Pistachio is coming soon, as well as an initial device-tree and support
for USB and ethernet.
Patches 1 and 2 are cleanups in preparation for adding Pistachio support,
with patch 1 having been posted by Kevin late last year [1]. Patch 3
documents Pistachio's required device-tree properties/nodes and its boot
protocol. Patch 4 adds support for Pistachio itself and finally patch 5
adds a defconfig for Pistachio.
Boot tested on an IMG Pistachio BuB ("bring-up board") and build tested
for all other affected platforms. Based on v4.0-rc1. A tree with these
changes is available at [2].
Cc: Ezequiel Garcia
Cc: James Hartley
Cc: James Hogan
[1] http://patchwork.linux-mips.org/patch/8837/
[2] https://github.com/abrestic/linux/tree/pistachio-platform-v1
Andrew Bresticker (3):
MIPS: Allow platforms to specify the decompressor load address
MIPS: Document Pistachio boot protocol and device-tree bindings
MIPS: Add support for the IMG Pistachio SoC
Govindraj Raja (1):
MIPS: pistachio: Add an initial defconfig
Kevin Cernekee (1):
MIPS: Create a common
.../devicetree/bindings/mips/img/pistachio.txt | 40 +++
arch/mips/Kbuild.platforms | 1 +
arch/mips/Kconfig | 27 ++
arch/mips/boot/compressed/Makefile | 6 +-
arch/mips/configs/pistachio_defconfig | 336 +
arch/mips/include/asm/mach-ar7/war.h | 24 --
arch/mips/include/asm/mach-ath25/war.h | 25 --
arch/mips/include/asm/mach-ath79/war.h | 24 --
arch/mips/include/asm/mach-au1x00/war.h| 24 --
arch/mips/include/asm/mach-bcm3384/war.h | 24 --
arch/mips/include/asm/mach-bcm47xx/war.h | 24 --
arch/mips/include/asm/mach-bcm63xx/war.h | 24 --
arch/mips/include/asm/mach-cobalt/war.h| 24 --
arch/mips/include/asm/mach-dec/war.h | 24 --
arch/mips/include/asm/mach-emma2rh/war.h | 24 --
arch/mips/include/asm/mach-generic/war.h | 24 ++
arch/mips/include/asm/mach-jazz/war.h | 24 --
arch/mips/include/asm/mach-jz4740/war.h| 24 --
arch/mips/include/asm/mach-lantiq/war.h| 23 --
arch/mips/include/asm/mach-lasat/war.h | 24 --
arch/mips/include/asm/mach-loongson/war.h | 24 --
arch/mips/include/asm/mach-loongson1/war.h | 24 --
arch/mips/include/asm/mach-netlogic/war.h | 25 --
arch/mips/include/asm/mach-paravirt/war.h | 25 --
arch/mips/include/asm/mach-pistachio/gpio.h| 21 ++
arch/mips/include/asm/mach-pistachio/irq.h | 18 ++
arch/mips/include/asm/mach-pnx833x/war.h | 24 --
arch/mips/include/asm/mach-ralink/war.h| 24 --
arch/mips/include/asm/mach-tx39xx/war.h| 24 --
arch/mips/include/asm/mach-vr41xx/war.h| 24 --
arch/mips/jz4740/Platform | 1 +
arch/mips/pistachio/Makefile | 1 +
arch/mips/pistachio/Platform | 8 +
arch/mips/pistachio/init.c | 131
arch/mips/pistachio/irq.c | 28 ++
arch/mips/pistachio/time.c | 52
36 files changed, 692 insertions(+), 532 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mips/img/pistachio.txt
create mode 100644 arch/mips/configs/pistachio_defconfig
delete mode 100644 arch/mips/include/asm/mach-ar7/war.h
delete mode 100644 arch/mips/include/asm/mach-ath25/war.h
delete mode 100644 arch/mips/include/asm/mach-ath79/war.h
delete mode 100644 arch/mips/include/asm/mach-au1x00/war.h
delete mode 100644 arch/mips/include/asm/mach-bcm3384/war.h
delete mode 100644 arch/mips/include/asm/mach-bcm47xx/war.h
delete mode 100644 arch/mips/include/asm/mach-bcm63xx/war.h
delete mode 100644 arch/mips/include/asm/mach-cobalt/war.h
delete mode 100644 arch/mips/include/asm/mach-dec/war.h
delete mode 100644 arch/mips/include/asm/mach-emma2rh/war.h
create mode 100644 arch/mips/include/asm/mach-generic/war.h
delete mode 100644 arch/mips/include/asm/mach-jazz/war.h
delete mode 100644 arch/mips/include/asm/mach-jz4740/war.h
delete mode 100644 arch/mips/include/asm/mach-lantiq/war.h
delete mode 100644 arch/mips/include/asm/mach-lasat/war.h
delete mode 100644 arch/mips/include/asm/mach-loongson/war.h
delete mode 100644 arch/mips/include/asm/mach-loongson1/war.h
delete mode 100644 arch/mips/include/asm/mach-netlogic/war.h
delete mode 100644 arch/mips/include/asm/mach-paravirt/war.h
create mode 100644 arch/mips/include/asm/mach-pistachio/gpio.h
create mod
[PATCH 5/5] MIPS: pistachio: Add an initial defconfig
From: Govindraj Raja Add a defconfig for Pistachio which enables drivers for all the currently supported peripherals on the SoC. Signed-off-by: Govindraj Raja Signed-off-by: Andrew Bresticker --- arch/mips/configs/pistachio_defconfig | 336 ++ 1 file changed, 336 insertions(+) create mode 100644 arch/mips/configs/pistachio_defconfig diff --git a/arch/mips/configs/pistachio_defconfig b/arch/mips/configs/pistachio_defconfig new file mode 100644 index 000..f22e92e --- /dev/null +++ b/arch/mips/configs/pistachio_defconfig @@ -0,0 +1,336 @@ +CONFIG_MACH_PISTACHIO=y +CONFIG_MIPS_MT_SMP=y +CONFIG_MIPS_CPS=y +# CONFIG_COMPACTION is not set +CONFIG_DEFAULT_MMAP_MIN_ADDR=32768 +CONFIG_ZSMALLOC=y +CONFIG_NR_CPUS=4 +CONFIG_PREEMPT_VOLUNTARY=y +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_DEFAULT_HOSTNAME="localhost" +CONFIG_SYSVIPC=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_IKCONFIG=m +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=18 +CONFIG_CGROUPS=y +CONFIG_CGROUP_FREEZER=y +CONFIG_CGROUP_SCHED=y +CONFIG_CFS_BANDWIDTH=y +CONFIG_NAMESPACES=y +CONFIG_USER_NS=y +CONFIG_BLK_DEV_INITRD=y +# CONFIG_RD_BZIP2 is not set +# CONFIG_RD_LZMA is not set +# CONFIG_RD_LZO is not set +# CONFIG_RD_LZ4 is not set +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_EMBEDDED=y +# CONFIG_COMPAT_BRK is not set +CONFIG_PROFILING=y +CONFIG_CC_STACKPROTECTOR_STRONG=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +CONFIG_MODULE_FORCE_UNLOAD=y +CONFIG_PARTITION_ADVANCED=y +CONFIG_PM_DEBUG=y +CONFIG_PM_ADVANCED_DEBUG=y +CONFIG_CPU_IDLE=y +# CONFIG_MIPS_CPS_CPUIDLE is not set +CONFIG_NET=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_NET_KEY=m +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +CONFIG_IP_ADVANCED_ROUTER=y +CONFIG_IP_MULTIPLE_TABLES=y +CONFIG_IP_ROUTE_MULTIPATH=y +CONFIG_IP_ROUTE_VERBOSE=y +CONFIG_IP_MROUTE=y +CONFIG_IP_PIMSM_V1=y +CONFIG_IP_PIMSM_V2=y +CONFIG_SYN_COOKIES=y +CONFIG_INET_AH=m +CONFIG_INET_ESP=m +CONFIG_INET_IPCOMP=m +CONFIG_INET_XFRM_MODE_TRANSPORT=m +CONFIG_INET_XFRM_MODE_TUNNEL=m +CONFIG_INET_XFRM_MODE_BEET=m +# CONFIG_INET_DIAG is not set +CONFIG_TCP_CONG_ADVANCED=y +# CONFIG_TCP_CONG_BIC is not set +# CONFIG_TCP_CONG_WESTWOOD is not set +# CONFIG_TCP_CONG_HTCP is not set +CONFIG_TCP_CONG_LP=m +CONFIG_TCP_MD5SIG=y +CONFIG_IPV6=y +CONFIG_INET6_AH=m +CONFIG_INET6_ESP=m +CONFIG_INET6_XFRM_MODE_TRANSPORT=m +CONFIG_INET6_XFRM_MODE_TUNNEL=m +CONFIG_INET6_XFRM_MODE_BEET=m +CONFIG_IPV6_SIT=m +CONFIG_NETWORK_SECMARK=y +CONFIG_NETFILTER=y +# CONFIG_BRIDGE_NETFILTER is not set +CONFIG_NF_CONNTRACK=y +CONFIG_NF_CT_NETLINK=y +CONFIG_NETFILTER_XT_MARK=m +CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y +CONFIG_NETFILTER_XT_TARGET_DSCP=y +CONFIG_NETFILTER_XT_TARGET_NFLOG=y +CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y +CONFIG_NETFILTER_XT_TARGET_SECMARK=y +CONFIG_NETFILTER_XT_TARGET_TCPMSS=m +CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y +CONFIG_NETFILTER_XT_MATCH_DSCP=y +CONFIG_NETFILTER_XT_MATCH_POLICY=y +CONFIG_NETFILTER_XT_MATCH_STATE=y +CONFIG_NF_CONNTRACK_IPV4=y +CONFIG_NF_NAT_IPV4=m +CONFIG_IP_NF_IPTABLES=y +CONFIG_IP_NF_FILTER=y +CONFIG_IP_NF_TARGET_REJECT=y +CONFIG_IP_NF_MANGLE=y +CONFIG_NF_CONNTRACK_IPV6=m +CONFIG_NF_NAT_IPV6=m +CONFIG_IP6_NF_IPTABLES=m +CONFIG_IP6_NF_MATCH_IPV6HEADER=m +CONFIG_IP6_NF_FILTER=m +CONFIG_IP6_NF_TARGET_REJECT=m +CONFIG_IP6_NF_MANGLE=m +CONFIG_BRIDGE=m +CONFIG_VLAN_8021Q=m +CONFIG_NET_SCHED=y +CONFIG_NET_SCH_HTB=m +CONFIG_NET_SCH_CODEL=m +CONFIG_NET_SCH_FQ_CODEL=m +CONFIG_NET_CLS_U32=m +CONFIG_CLS_U32_MARK=y +CONFIG_BT=m +CONFIG_BT_RFCOMM=m +CONFIG_BT_HCIBTUSB=m +CONFIG_BT_HCIBFUSB=m +CONFIG_BT_HCIVHCI=m +CONFIG_CFG80211=m +CONFIG_NL80211_TESTMODE=y +CONFIG_CFG80211_DEBUGFS=y +CONFIG_CFG80211_WEXT=y +CONFIG_MAC80211=m +CONFIG_MAC80211_LEDS=y +CONFIG_MAC80211_DEBUGFS=y +CONFIG_MAC80211_DEBUG_MENU=y +CONFIG_MAC80211_VERBOSE_DEBUG=y +CONFIG_RFKILL=y +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +CONFIG_DEBUG_DEVRES=y +CONFIG_CONNECTOR=y +CONFIG_MTD=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_M25P80=y +CONFIG_MTD_SPI_NOR=y +CONFIG_MTD_UBI=y +CONFIG_MTD_UBI_BLOCK=y +CONFIG_ZRAM=m +CONFIG_BLK_DEV_LOOP=y +CONFIG_SCSI=y +CONFIG_BLK_DEV_SD=y +CONFIG_BLK_DEV_SR=m +CONFIG_SCSI_SPI_ATTRS=y +CONFIG_MD=y +CONFIG_BLK_DEV_DM=y +CONFIG_DM_CRYPT=y +CONFIG_DM_VERITY=y +CONFIG_NETDEVICES=y +CONFIG_TUN=m +CONFIG_VETH=m +# CONFIG_NET_VENDOR_MARVELL is not set +# CONFIG_NET_VENDOR_MICREL is not set +# CONFIG_NET_VENDOR_MICROCHIP is not set +# CONFIG_NET_VENDOR_NATSEMI is not set +# CONFIG_NET_VENDOR_SEEQ is not set +# CONFIG_NET_VENDOR_SMSC is not set +CONFIG_STMMAC_ETH=y +# CONFIG_NET_VENDOR_VIA is not set +CONFIG_PPP=m +CONFIG_PPP_ASYNC=m +CONFIG_USB_PEGASUS=m +CONFIG_USB_RTL8150=m +CONFIG_USB_RTL8152=m +CONFIG_USB_NET_DM9601=m +CONFIG_USB_NET_SMSC75XX=m +CONFIG_USB_NET_SMSC95XX=m +CONFIG_USB_NET_MCS7830=m +# CONFIG_USB_NET_CDC_SUBSET is not set +# CONFIG_USB_NET_ZAURUS is not set +CONFIG_LIBERTAS_THINFIRM=m +CONFIG_USB_NET_RNDIS_WLAN=m +CONFIG_MAC80211_HWSIM=m +CONFIG_HOSTAP=m +CONFIG_HOSTAP_FIRMWARE=y +CONFIG_HOSTAP_FIRMWARE
[PATCH 1/5] MIPS: Create a common
From: Kevin Cernekee 11 platforms require at least one of these workarounds to be enabled; 22 platforms do not. In the latter case we can fall back to a generic version. Note that this also deletes an orphaned reference to RM9000_CDEX_SMP_WAR. Suggested-by: Arnd Bergmann Signed-off-by: Kevin Cernekee Signed-off-by: Andrew Bresticker --- Changes from Kevin's v6: - Left cavium-octeon's war.h in-tact --- arch/mips/include/asm/mach-ar7/war.h | 24 arch/mips/include/asm/mach-ath25/war.h | 25 - arch/mips/include/asm/mach-ath79/war.h | 24 arch/mips/include/asm/mach-au1x00/war.h| 24 arch/mips/include/asm/mach-bcm3384/war.h | 24 arch/mips/include/asm/mach-bcm47xx/war.h | 24 arch/mips/include/asm/mach-bcm63xx/war.h | 24 arch/mips/include/asm/mach-cobalt/war.h| 24 arch/mips/include/asm/mach-dec/war.h | 24 arch/mips/include/asm/mach-emma2rh/war.h | 24 arch/mips/include/asm/mach-generic/war.h | 24 arch/mips/include/asm/mach-jazz/war.h | 24 arch/mips/include/asm/mach-jz4740/war.h| 24 arch/mips/include/asm/mach-lantiq/war.h| 23 --- arch/mips/include/asm/mach-lasat/war.h | 24 arch/mips/include/asm/mach-loongson/war.h | 24 arch/mips/include/asm/mach-loongson1/war.h | 24 arch/mips/include/asm/mach-netlogic/war.h | 25 - arch/mips/include/asm/mach-paravirt/war.h | 25 - arch/mips/include/asm/mach-pnx833x/war.h | 24 arch/mips/include/asm/mach-ralink/war.h| 24 arch/mips/include/asm/mach-tx39xx/war.h| 24 arch/mips/include/asm/mach-vr41xx/war.h| 24 23 files changed, 24 insertions(+), 530 deletions(-) delete mode 100644 arch/mips/include/asm/mach-ar7/war.h delete mode 100644 arch/mips/include/asm/mach-ath25/war.h delete mode 100644 arch/mips/include/asm/mach-ath79/war.h delete mode 100644 arch/mips/include/asm/mach-au1x00/war.h delete mode 100644 arch/mips/include/asm/mach-bcm3384/war.h delete mode 100644 arch/mips/include/asm/mach-bcm47xx/war.h delete mode 100644 arch/mips/include/asm/mach-bcm63xx/war.h delete mode 100644 arch/mips/include/asm/mach-cobalt/war.h delete mode 100644 arch/mips/include/asm/mach-dec/war.h delete mode 100644 arch/mips/include/asm/mach-emma2rh/war.h create mode 100644 arch/mips/include/asm/mach-generic/war.h delete mode 100644 arch/mips/include/asm/mach-jazz/war.h delete mode 100644 arch/mips/include/asm/mach-jz4740/war.h delete mode 100644 arch/mips/include/asm/mach-lantiq/war.h delete mode 100644 arch/mips/include/asm/mach-lasat/war.h delete mode 100644 arch/mips/include/asm/mach-loongson/war.h delete mode 100644 arch/mips/include/asm/mach-loongson1/war.h delete mode 100644 arch/mips/include/asm/mach-netlogic/war.h delete mode 100644 arch/mips/include/asm/mach-paravirt/war.h delete mode 100644 arch/mips/include/asm/mach-pnx833x/war.h delete mode 100644 arch/mips/include/asm/mach-ralink/war.h delete mode 100644 arch/mips/include/asm/mach-tx39xx/war.h delete mode 100644 arch/mips/include/asm/mach-vr41xx/war.h diff --git a/arch/mips/include/asm/mach-ar7/war.h b/arch/mips/include/asm/mach-ar7/war.h deleted file mode 100644 index 99071e5..000 --- a/arch/mips/include/asm/mach-ar7/war.h +++ /dev/null @@ -1,24 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" in the main directory of this archive - * for more details. - * - * Copyright (C) 2002, 2004, 2007 by Ralf Baechle - */ -#ifndef __ASM_MIPS_MACH_AR7_WAR_H -#define __ASM_MIPS_MACH_AR7_WAR_H - -#define R4600_V1_INDEX_ICACHEOP_WAR0 -#define R4600_V1_HIT_CACHEOP_WAR 0 -#define R4600_V2_HIT_CACHEOP_WAR 0 -#define R5432_CP0_INTERRUPT_WAR0 -#define BCM1250_M3_WAR 0 -#define SIBYTE_1956_WAR0 -#define MIPS4K_ICACHE_REFILL_WAR 0 -#define MIPS_CACHE_SYNC_WAR0 -#define TX49XX_ICACHE_INDEX_INV_WAR0 -#define ICACHE_REFILLS_WORKAROUND_WAR 0 -#define R1_LLSC_WAR0 -#define MIPS34K_MISSED_ITLB_WAR0 - -#endif /* __ASM_MIPS_MACH_AR7_WAR_H */ diff --git a/arch/mips/include/asm/mach-ath25/war.h b/arch/mips/include/asm/mach-ath25/war.h deleted file mode 100644 index e3a5250..000 --- a/arch/mips/include/asm/mach-ath25/war.h +++ /dev/null @@ -1,25 +0,0 @@ -/* - * This file is subject to the terms and conditions of the GNU General Public - * License. See the file "COPYING" i
[PATCH v6 5/5] Documentation: Add device tree bindings document for max77843
Add document describing device tree bindings for max77843 MFD.
Drivers: MFD core, regulator, extcon, charger and fuelgauge.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: Lee Jones
Cc: Sebastian Reichel
Cc: Dmitry Torokhov
Signed-off-by: Jaewon Kim
Signed-off-by: Beomho Seo
---
Documentation/devicetree/bindings/mfd/max77843.txt | 110
1 file changed, 110 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/max77843.txt
diff --git a/Documentation/devicetree/bindings/mfd/max77843.txt
b/Documentation/devicetree/bindings/mfd/max77843.txt
new file mode 100644
index 000..76426ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77843.txt
@@ -0,0 +1,110 @@
+Maxim MAX77843 multi-function device
+
+MAX77843 is a Multi-Function Device with the following submodules:
+- PMIC : 2 SAFEOUT LDOs for USB device
+- CHARGER : Li+ battery charger with Fuel Gauge
+- MUIC : Micro USB Interface Controller
+- HAPTIC : Motor Controller for tactile feedback
+
+It is interfaced to host controller using I2C.
+
+Required properties:
+- compatible : Must be "maxim,max77843".
+- reg : I2C slave address of PMIC block.
+- interrupts : I2C line for main SoCs.
+- interrupt-parent : The parent of interrupt controller.
+
+Optional properties:
+- regulators : The regulators of max77843 have to be instantiated under subnode
+ named "regulators" using the following format.
+
+ [*]refer : Documentation/devicetree/bindings/regulator/regulator.txt
+
+ regulators {
+ SAFEOUT {
+ regulator-name = "SAFEOUT";
+ };
+ }
+
+ List of valid regulator names:
+ - SAFEOUT1, SAFEOUT2, CHARGER.
+
+- max77843-muic : This properties used by extcon consumers.
+ Required properties:
+ - compatible : Must be "maxim,max77842-muic".
+
+- max77843-charger : There battery charger of MAX77843 have to be instantiated
+ under sub-node named "max77843-charger" using the following format.
+ Required properties:
+ - compatible : Must be "maxim,max77842-charger".
+ - maxim,fast-charge-uamp : Fast charge current levels are
+ 100 mA to 3150 mA programmed by I2C per 100 mA.
+ - maxim,top-off-uamp : Top off current threshold levels are
+ 125 mA to 650 mA programmed by I2C per 75 mA.
+ - maxim,input-uamp-limit : Input current limit levels are
+ 100 mA to 3533 mA programmed by I2C per 33 mA.
+
+- max77843-fuelgauge : There fuelgauge of MAX77843 have to be instantiated
+ under sub-node named "max77843-fuelgauge" using the following format.
+ Required properties:
+ - compatible : Must be "maxim,max77842-fuelgauge".
+
+- max77843-haptic : The MAX77843 haptic device provides the tactile feedback
+ to the user by using PWM(Pulse Width Modulation) signal.
+ Required properties:
+ - compatible : Must be "maxim,max77843-hpatic".
+ - haptic-supply : Power supply for the haptic motor.
+ [*] refer Documentation/devicetree/
+ bindings/regulator/regulator.txt
+ - pwms : phandle for the PWM(Pulse Width Modulation) device.
+ PWM properties should be named "pwms".
+ [*] refer Documentation/devicetree/bindings/pwm/pwm.txt
+
+Example:
+ max77843@66 {
+ compatible = "samsung,max77843";
+ reg = <0x66>;
+ interrupt-parent = <&gpa1>;
+ interrupts = <5 2>;
+
+ regulators {
+ SAFEOUT1 {
+ regulator-name = "SAFEOUT1";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <495>;
+ };
+ SAFEOUT2 {
+ regulator-name = "SAFEOUT2";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <495>;
+ };
+ CHARGER {
+ regulator-name = "CHARGER";
+ regulator-min-microamp = <10>;
+ regulator-max-microamp = <315>;
+ };
+ };
+
+ haptic {
+ compatible = "maxim,max77843-haptic";
+ haptic-supply = <&haptic_supply>;
+ pwms = <&pwm 0 4 0>;
+ pwm-names = "haptic";
+ };
+
+ max77843-muic {
+ compatible = "maxim,max77843-muic";
+ };
+
+ max77843-charger {
+ compatible = "maxim,max7
[PATCH v6 4/5] Input: add haptic drvier on max77843
This patch adds support for haptic driver on max77843
MFD(Multi Function Device) with PMIC, MUIC, LED, CHARGER.
This driver supports external pwm and LRA(Linear Resonant Actuator) motor.
And it supports ff-memless interface from inpu framework.
Cc: Dmitry Torokhov
Signed-off-by: Jaewon Kim
---
drivers/input/misc/Kconfig | 12 ++
drivers/input/misc/Makefile |1 +
drivers/input/misc/max77843-haptic.c | 358 ++
3 files changed, 371 insertions(+)
create mode 100644 drivers/input/misc/max77843-haptic.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 6deb8da..aa8c072 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -165,6 +165,18 @@ config INPUT_MAX77693_HAPTIC
To compile this driver as module, choose M here: the
module will be called max77693-haptic.
+config INPUT_MAX77843_HAPTIC
+tristate "MAXIM MAX77843 haptic controller support"
+depends on MFD_MAX77843 && PWM
+select INPUT_FF_MEMLESS
+help
+ This option enables support for the haptic controller on
+ MAXIM MAX77843 chip. The driver supports ff-memless interface
+ from input framework.
+
+ To compile this driver as module, choose M here: the
+ module will be called max77843-haptic.
+
config INPUT_MAX8925_ONKEY
tristate "MAX8925 ONKEY support"
depends on MFD_MAX8925
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 403a1a5..75b5884 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_INPUT_KEYSPAN_REMOTE)+= keyspan_remote.o
obj-$(CONFIG_INPUT_KXTJ9) += kxtj9.o
obj-$(CONFIG_INPUT_M68K_BEEP) += m68kspkr.o
obj-$(CONFIG_INPUT_MAX77693_HAPTIC)+= max77693-haptic.o
+obj-$(CONFIG_INPUT_MAX77843_HAPTIC)+= max77843-haptic.o
obj-$(CONFIG_INPUT_MAX8925_ONKEY) += max8925_onkey.o
obj-$(CONFIG_INPUT_MAX8997_HAPTIC) += max8997_haptic.o
obj-$(CONFIG_INPUT_MC13783_PWRBUTTON) += mc13783-pwrbutton.o
diff --git a/drivers/input/misc/max77843-haptic.c
b/drivers/input/misc/max77843-haptic.c
new file mode 100644
index 000..0005d0a
--- /dev/null
+++ b/drivers/input/misc/max77843-haptic.c
@@ -0,0 +1,358 @@
+/*
+ * MAXIM MAX77693 Haptic device driver
+ *
+ * Copyright (C) 2015 Samsung Electronics
+ * Author: Jaewon Kim
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define MAX_MAGNITUDE_SHIFT16
+
+enum max77843_haptic_motor_type {
+ MAX77843_HAPTIC_ERM = 0,
+ MAX77843_HAPTIC_LRA,
+};
+
+enum max77843_haptic_pwm_divisor {
+ MAX77843_HAPTIC_PWM_DIVISOR_32 = 0,
+ MAX77843_HAPTIC_PWM_DIVISOR_64,
+ MAX77843_HAPTIC_PWM_DIVISOR_128,
+ MAX77843_HAPTIC_PWM_DIVISOR_256,
+};
+
+struct max77843_haptic {
+ struct regmap *regmap_haptic;
+ struct device *dev;
+ struct input_dev *input_dev;
+ struct pwm_device *pwm_dev;
+ struct regulator *motor_reg;
+ struct work_struct work;
+ struct mutex mutex;
+
+ unsigned int magnitude;
+ unsigned int pwm_duty;
+
+ bool active;
+ bool suspended;
+
+ enum max77843_haptic_motor_type type;
+ enum max77843_haptic_pwm_divisor pwm_divisor;
+};
+
+static int max77843_haptic_set_duty_cycle(struct max77843_haptic *haptic)
+{
+ int delta = (haptic->pwm_dev->period + haptic->pwm_duty) / 2;
+ int error;
+
+ error = pwm_config(haptic->pwm_dev, delta, haptic->pwm_dev->period);
+ if (error) {
+ dev_err(haptic->dev, "failed to configure pwm: %d\n", error);
+ return error;
+ }
+
+ return 0;
+}
+
+static int max77843_haptic_bias(struct max77843_haptic *haptic, bool on)
+{
+ int error;
+
+ error = regmap_update_bits(haptic->regmap_haptic,
+ MAX77843_SYS_REG_MAINCTRL1,
+ MAX77843_MAINCTRL1_BIASEN_MASK,
+ on << MAINCTRL1_BIASEN_SHIFT);
+ if (error) {
+ dev_err(haptic->dev, "failed to %s bias: %d\n",
+ on ? "enable" : "disable", error);
+ return error;
+ }
+
+ return 0;
+}
+
+static int max77843_haptic_config(struct max77843_haptic *haptic, bool enable)
+{
+ unsigned int value;
+ int error;
+
+ value = ((haptic->type << MCONFIG_MODE_SHIFT) |
+ (enable << MCONFIG_MEN_SHIFT) |
+ (haptic->pwm_divisor << MCONFIG_PDIV_SHIFT));
+
+ error = regmap_write(haptic->regmap_haptic,
+ MAX77843_HAP_REG_MCONFIG, value)
[PATCH v6 3/5] power: max77843_battery: Add Max77843 fuel gauge device driver
From: Beomho Seo
This patch adds device driver of max77843 fuel gauge.
The driver support for battery fuel gauge in Maxim Max77843.
It is fuel-gauge systems for lithuum-ion batteries in handled and
portable devices.
Cc: Sebastian Reichel
Signed-off-by: Beomho Seo
---
drivers/power/Kconfig|9 ++
drivers/power/Makefile |1 +
drivers/power/max77843_battery.c | 286 ++
3 files changed, 296 insertions(+)
create mode 100644 drivers/power/max77843_battery.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 994793d..555e436 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -212,6 +212,15 @@ config BATTERY_MAX17042
with MAX17042. This driver also supports max17047/50 chips which are
improved version of max17042.
+config BATTERY_MAX77843
+ tristate "Maxim MAX77843 Fuel Gauge"
+ depends on MFD_MAX77843
+ help
+ This adds support for battery fuel gauge in Maxim MAX77843. It is
+ fuel-gauge for a lithium-ion batteries with a single cell and can be
+ found in portable devices. The MAX17040 is configured to operate with
+ a single lithium cell.
+
config BATTERY_Z2
tristate "Z2 battery driver"
depends on I2C && MACH_ZIPIT2
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index ed69cea..59e3945 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_BATTERY_DA9030) += da9030_battery.o
obj-$(CONFIG_BATTERY_DA9052) += da9052-battery.o
obj-$(CONFIG_BATTERY_MAX17040) += max17040_battery.o
obj-$(CONFIG_BATTERY_MAX17042) += max17042_battery.o
+obj-$(CONFIG_BATTERY_MAX77843) += max77843_battery.o
obj-$(CONFIG_BATTERY_Z2) += z2_battery.o
obj-$(CONFIG_BATTERY_RT5033) += rt5033_battery.o
obj-$(CONFIG_BATTERY_S3C_ADC) += s3c_adc_battery.o
diff --git a/drivers/power/max77843_battery.c b/drivers/power/max77843_battery.c
new file mode 100644
index 000..0c59a16
--- /dev/null
+++ b/drivers/power/max77843_battery.c
@@ -0,0 +1,286 @@
+/*
+ * Fuel gauge driver for Maxim MAX77843
+ *
+ * Copyright (C) 2015 Samsung Electronics, Co., Ltd.
+ * Author: Beomho Seo
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published bythe Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+struct max77843_battery {
+ struct device *dev;
+ struct max77843 *max77843;
+ struct i2c_client *client;
+ struct regmap *regmap;
+ struct power_supply psy;
+};
+
+static int max77843_battery_get_capacity(struct max77843_battery *battery)
+{
+ struct regmap *regmap = battery->regmap;
+ int ret, val;
+ unsigned int reg_data;
+
+ ret = regmap_read(regmap, MAX77843_FG_REG_SOCREP, ®_data);
+ if (ret) {
+ dev_err(battery->dev, "Failed to read fuelgauge register\n");
+ return ret;
+ }
+
+ val = reg_data >> 8;
+
+ return val;
+}
+
+static int max77843_battery_get_energy_prop(struct max77843_battery *battery,
+ enum power_supply_property psp)
+{
+ struct regmap *regmap = battery->regmap;
+ unsigned int reg;
+ int ret, val;
+ unsigned int reg_data;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_ENERGY_FULL:
+ reg = MAX77843_FG_REG_FULLCAP;
+ break;
+ case POWER_SUPPLY_PROP_ENERGY_NOW:
+ reg = MAX77843_FG_REG_REMCAP_REP;
+ break;
+ case POWER_SUPPLY_PROP_ENERGY_AVG:
+ reg = MAX77843_FG_REG_REMCAP_AV;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ ret = regmap_read(regmap, reg, ®_data);
+ if (ret) {
+ dev_err(battery->dev, "Failed to read fuelgauge register\n");
+ return ret;
+ }
+
+ val = reg_data;
+
+ return val;
+}
+
+static int max77843_battery_get_current_prop(struct max77843_battery *battery,
+ enum power_supply_property psp)
+{
+ struct regmap *regmap = battery->regmap;
+ unsigned int reg;
+ int ret, val;
+ unsigned int reg_data;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_CURRENT_NOW:
+ reg = MAX77843_FG_REG_CURRENT;
+ break;
+ case POWER_SUPPLY_PROP_CURRENT_AVG:
+ reg = MAX77843_FG_REG_AVG_CURRENT;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ ret = regmap_read(regmap, reg, ®_data);
+ if (ret) {
+ dev_err(battery->dev, "Failed to read fuelgauge register\n");
+ return ret;
+ }
+
+ val = reg_data;
+ if (val & 0x8000) {
+ /* Negative */
+ val = ~val & 0x;
+ val++;
+ val
[PATCH v6 2/5] power: max77843_charger: Add Max77843 charger device driver
From: Beomho Seo
This patch adds device driver of max77843 charger. This driver provide
initialize each charging mode(e.g. fast charge, top-off mode and constant
charging mode so on.). Additionally, control charging parameters to use
i2c interface.
Cc: Sebastian Reichel
Signed-off-by: Beomho Seo
---
drivers/power/Kconfig|7 +
drivers/power/Makefile |1 +
drivers/power/max77843_charger.c | 508 ++
3 files changed, 516 insertions(+)
create mode 100644 drivers/power/max77843_charger.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 27b751b..994793d 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -337,6 +337,13 @@ config CHARGER_MAX77693
help
Say Y to enable support for the Maxim MAX77693 battery charger.
+config CHARGER_MAX77843
+ tristate "Maxim MAX77843 battery charger driver"
+ depends on MFD_MAX77843
+ help
+ Say Y to enable support for the battery charger control sysfs and
+ platform data of MAX77843
+
config CHARGER_MAX8997
tristate "Maxim MAX8997/MAX8966 PMIC battery charger driver"
depends on MFD_MAX8997 && REGULATOR_MAX8997
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 36f9e0d..ed69cea 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -53,6 +53,7 @@ obj-$(CONFIG_CHARGER_GPIO)+= gpio-charger.o
obj-$(CONFIG_CHARGER_MANAGER) += charger-manager.o
obj-$(CONFIG_CHARGER_MAX14577) += max14577_charger.o
obj-$(CONFIG_CHARGER_MAX77693) += max77693_charger.o
+obj-$(CONFIG_CHARGER_MAX77843) += max77843_charger.o
obj-$(CONFIG_CHARGER_MAX8997) += max8997_charger.o
obj-$(CONFIG_CHARGER_MAX8998) += max8998_charger.o
obj-$(CONFIG_CHARGER_BQ2415X) += bq2415x_charger.o
diff --git a/drivers/power/max77843_charger.c b/drivers/power/max77843_charger.c
new file mode 100644
index 000..392eebc1a
--- /dev/null
+++ b/drivers/power/max77843_charger.c
@@ -0,0 +1,508 @@
+/*
+ * Charger driver for Maxim MAX77843
+ *
+ * Copyright (C) 2015 Samsung Electronics, Co., Ltd.
+ * Author: Beomho Seo
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published bythe Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+struct max77843_charger_info {
+ u32 fast_charge_uamp;
+ u32 top_off_uamp;
+ u32 input_uamp_limit;
+};
+
+struct max77843_charger {
+ struct device *dev;
+ struct max77843 *max77843;
+ struct i2c_client *client;
+ struct regmap *regmap;
+ struct power_supply psy;
+
+ struct max77843_charger_info*info;
+};
+
+static int max77843_charger_get_max_current(struct max77843_charger *charger)
+{
+ struct regmap *regmap = charger->regmap;
+ int ret, val = 0;
+ unsigned int reg_data;
+
+ ret = regmap_read(regmap, MAX77843_CHG_REG_CHG_CNFG_09, ®_data);
+ if (ret) {
+ dev_err(charger->dev,
+ "Failed to read max current register: %d\n", ret);
+ return ret;
+ }
+
+ if (reg_data <= 0x03) {
+ val = MAX77843_CHG_INPUT_CURRENT_LIMIT_MIN;
+ } else if (reg_data >= 0x78) {
+ val = MAX77843_CHG_INPUT_CURRENT_LIMIT_MAX;
+ } else {
+ val = reg_data / 3;
+ if (reg_data % 3 == 0)
+ val *= 10;
+ else if (reg_data % 3 == 1)
+ val = val * 10 + 33000;
+ else
+ val = val * 10 + 67000;
+ }
+
+ return val;
+}
+
+static int max77843_charger_get_now_current(struct max77843_charger *charger)
+{
+ struct regmap *regmap = charger->regmap;
+ int ret, val = 0;
+ unsigned int reg_data;
+
+ ret = regmap_read(regmap, MAX77843_CHG_REG_CHG_CNFG_02, ®_data);
+ if (ret) {
+ dev_err(charger->dev,
+ "Failed to read charge current register: %d\n", ret);
+ return ret;
+ }
+
+ reg_data &= MAX77843_CHG_FAST_CHG_CURRENT_MASK;
+
+ if (reg_data <= 0x02)
+ val = MAX77843_CHG_FAST_CHG_CURRENT_MIN;
+ else if (reg_data >= 0x3f)
+ val = MAX77843_CHG_FAST_CHG_CURRENT_MAX;
+ else
+ val = reg_data * MAX77843_CHG_FAST_CHG_CURRENT_STEP;
+
+ return val;
+}
+
+static int max77843_charger_get_online(struct max77843_charger *charger)
+{
+ struct regmap *regmap = charger->regmap;
+ int ret, val = 0;
+ unsigned int reg_data;
+
+ ret = regmap_read(regmap, MAX77843_CHG_REG_CHG_INT_OK, ®_data);
+ if (ret) {
+ dev_err(charger->dev,
+ "Failed to read charger status: %d\n", ret);
+ return ret;
+ }
+
+ if (reg_data & MAX77843
[PATCH v6 0/5] Add new MFD driver for MAX77843
This patch series adds MAX77843(Multi Function Device) driver. The MAX77843 includes MUIC(Micro USB Interface Controller), Li+ Charger with Fuel Gauge, 2 safeout LDOs for USB device and haptic controller using PWM. It is interfaced to host controller using I2C. Changes in v6: HAPTIC - fixed a situation where holding a mutex return. Changes in v5: MFD Core - Use bracket in complex define. - Delete unnecessary letter '++' Charger - fix Kconfig merge conflict with Kernel version4.0 Changes in v4: MFD Core - Fix indentation - Add haptic register define in header HAPTIC - Add haptic driver Changes in v3: MFD Core - Fix wrong description and indentation in header. - Remove unnecessary variable. Regulator - Use ARRAY_SIZE() instead of define. Changes in v2: MFD Core - Fix charger regmap handle and typo. MUIC - Cleanup enum list. - Set path before send excon event. - Fix variable names and typos for readability. Charger - Remove unnecessary header. - Chnage error message more readable. - Remove unnecessary lines. Fuelgauge - Fix regmap_config and use regmap_read. - Add i2c_unregister_device function on *_remove function. - Fix typo in Kconfig. Doc - Remove unnecessary lines. - Add example of charger regulator. Beomho Seo (2): power: max77843_charger: Add Max77843 charger device driver power: max77843_battery: Add Max77843 fuel gauge device driver Jaewon Kim (3): mfd: max77843: Add max77843 MFD driver core driver Input: add haptic drvier on max77843 Documentation: Add device tree bindings document for max77843 Documentation/devicetree/bindings/mfd/max77843.txt | 110 + drivers/input/misc/Kconfig | 12 + drivers/input/misc/Makefile|1 + drivers/input/misc/max77843-haptic.c | 358 ++ drivers/mfd/Kconfig| 14 + drivers/mfd/Makefile |1 + drivers/mfd/max77843.c | 248 ++ drivers/power/Kconfig | 16 + drivers/power/Makefile |2 + drivers/power/max77843_battery.c | 286 +++ drivers/power/max77843_charger.c | 508 include/linux/mfd/max77843-private.h | 454 + 12 files changed, 2010 insertions(+) create mode 100644 Documentation/devicetree/bindings/mfd/max77843.txt create mode 100644 drivers/input/misc/max77843-haptic.c create mode 100644 drivers/mfd/max77843.c create mode 100644 drivers/power/max77843_battery.c create mode 100644 drivers/power/max77843_charger.c create mode 100644 include/linux/mfd/max77843-private.h -- 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
[PATCH v6 1/5] mfd: max77843: Add max77843 MFD driver core driver
This patch adds MAX77843 core/irq driver to support PMIC,
MUIC(Micro USB Interface Controller), Charger, Fuel Gauge,
LED and Haptic device.
Cc: Lee Jones
Signed-off-by: Jaewon Kim
Signed-off-by: Beomho Seo
---
drivers/mfd/Kconfig | 14 ++
drivers/mfd/Makefile |1 +
drivers/mfd/max77843.c | 248 +++
include/linux/mfd/max77843-private.h | 454 ++
4 files changed, 717 insertions(+)
create mode 100644 drivers/mfd/max77843.c
create mode 100644 include/linux/mfd/max77843-private.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 38356e3..f2fd5e5 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -455,6 +455,20 @@ config MFD_MAX77693
additional drivers must be enabled in order to use the functionality
of the device.
+config MFD_MAX77843
+ bool "Maxim Semiconductor MAX77843 PMIC Support"
+ depends on I2C=y
+ select MFD_CORE
+ select REGMAP_I2C
+ select REGMAP_IRQ
+ help
+ Say yes here to add support for Maxim Semiconductor MAX77843.
+ This is companion Power Management IC with LEDs, Haptic, Charger,
+ Fuel Gauge, MUIC(Micro USB Interface Controller) controls on chip.
+ This driver provides common support for accessing the device;
+ additional drivers must be enabled in order to use the functionality
+ of the device.
+
config MFD_MAX8907
tristate "Maxim Semiconductor MAX8907 PMIC Support"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 19f3d74..b8ac555 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -117,6 +117,7 @@ obj-$(CONFIG_MFD_DA9150)+= da9150-core.o
obj-$(CONFIG_MFD_MAX14577) += max14577.o
obj-$(CONFIG_MFD_MAX77686) += max77686.o
obj-$(CONFIG_MFD_MAX77693) += max77693.o
+obj-$(CONFIG_MFD_MAX77843) += max77843.o
obj-$(CONFIG_MFD_MAX8907) += max8907.o
max8925-objs := max8925-core.o max8925-i2c.o
obj-$(CONFIG_MFD_MAX8925) += max8925.o
diff --git a/drivers/mfd/max77843.c b/drivers/mfd/max77843.c
new file mode 100644
index 000..2d8b3cc
--- /dev/null
+++ b/drivers/mfd/max77843.c
@@ -0,0 +1,248 @@
+/*
+ * max77843.c - MFD core driver for the Maxim MAX77843
+ *
+ * Copyright (C) 2015 Samsung Electronics
+ * Author: Jaewon Kim
+ * Author: Beomho Seo
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static const struct mfd_cell max77843_devs[] = {
+ {
+ .name = "max77843-muic",
+ .of_compatible = "maxim,max77843-muic",
+ }, {
+ .name = "max77843-regulator",
+ .of_compatible = "maxim,max77843-regulator",
+ }, {
+ .name = "max77843-charger",
+ .of_compatible = "maxim,max77843-charger"
+ }, {
+ .name = "max77843-fuelgauge",
+ .of_compatible = "maxim,max77843-fuelgauge",
+ }, {
+ .name = "max77843-haptic",
+ .of_compatible = "maxim,max77843-haptic",
+ },
+};
+
+static const struct regmap_config max77843_charger_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = MAX77843_CHG_REG_END,
+};
+
+static const struct regmap_config max77843_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = MAX77843_SYS_REG_END,
+};
+
+static const struct regmap_irq max77843_irqs[] = {
+ /* TOPSYS interrupts */
+ { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSUVLO_INT, },
+ { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_SYSOVLO_INT, },
+ { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TSHDN_INT, },
+ { .reg_offset = 0, .mask = MAX77843_SYS_IRQ_TM_INT, },
+};
+
+static const struct regmap_irq_chip max77843_irq_chip = {
+ .name = "max77843",
+ .status_base= MAX77843_SYS_REG_SYSINTSRC,
+ .mask_base = MAX77843_SYS_REG_SYSINTMASK,
+ .mask_invert= false,
+ .num_regs = 1,
+ .irqs = max77843_irqs,
+ .num_irqs = ARRAY_SIZE(max77843_irqs),
+};
+
+/* Charger and Charger regulator use same regmap. */
+static int max77843_chg_init(struct max77843 *max77843)
+{
+ int ret;
+
+ max77843->i2c_chg = i2c_new_dummy(max77843->i2c->adapter, I2C_ADDR_CHG);
+ if (!max77843->i2c_chg) {
+ dev_err(&max77843->i2c->dev,
+ "Cannot allocate I2C device for Charger\n");
+ return PTR_ERR(max77843->i2c_chg);
+ }
+ i2c_set_clientdata(max77843->i2
Re: [PATCH v4 4/5] Input: add haptic drvier on max77843
Hi Dmitry Torokhov,
On 02/24/2015 02:26 AM, Dmitry Torokhov wrote:
Hi Jaew9on,
On Mon, Feb 23, 2015 at 05:09:50PM +0900, Jaewon Kim wrote:
This patch adds support for haptic driver on max77843
MFD(Multi Function Device) with PMIC, MUIC, LED, CHARGER.
This driver supports external pwm and LRA(Linear Resonant Actuator) motor.
And it supports ff-memless interface from inpu framework.
Cc: Dmitry Torokhov
Signed-off-by: Jaewon Kim
...
+static void max77843_haptic_play_work(struct work_struct *work)
+{
+ struct max77843_haptic *haptic =
+ container_of(work, struct max77843_haptic, work);
+ int error;
+
+ mutex_lock(&haptic->mutex);
+
+ if (haptic->suspended)
+ mutex_unlock(&haptic->mutex);
Huh?
This code prevent to play haptic when entering suspend state.
But I forgot return.
I will add return 0 in version 6.
+
+ error = max77843_haptic_set_duty_cycle(haptic);
+ if (error) {
+ dev_err(haptic->dev, "failed to set duty cycle: %d\n", error);
+ return;
Here you are leaving with the mutex held.
Okay, I will add mutex_unlock().
+ }
+
+ if (haptic->magnitude) {
+ error = max77843_haptic_enable(haptic);
+ if (error)
+ dev_err(haptic->dev,
+ "cannot enable haptic: %d\n", error);
+ } else {
+ max77843_haptic_disable(haptic);
+ if (error)
+ dev_err(haptic->dev,
+ "cannot disable haptic: %d\n", error);
+ }
+
+ mutex_unlock(&haptic->mutex);
+}
+
The rest seems quite reasonable.
Thanks.
Thanks to review my patch.
Thanks,
Jaewon Kim
--
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 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip
On Friday, February 20, 2015 10:31:44 AM Mark Rutland wrote: > [...] [cut] > Given all of the above I'll go back to the IRQF_SHARED_TIMER_OK approach > you proposed, along with documentation updates and comments at usage > sites to make it clear when it is valid to use. > > Thank you for bearing with me so far. No prob. :-) Actually, there's one more approach possible. Thomas might not like it, but here it goes anyway for consideration. What about making it possible to provide a special irqaction to be called while suspended for the shared IRQF_NO_SUSPEND interrupts. Say we have a "suspended_action" pointer in struct irq_desc in addition to "action" and we swap them in suspend_device_irq() if desc->no_suspend_depth is nonzero and "suspended_action" is not NULL (and then back in resume_irq()). Then, the platform might supply "suspended_action" that will do the right thing for the IRQ. So the requirement would be to have "suspended_action" set to start with and then the WARN_ON() in irq_pm_install_action() may check if that is present and only trigger the warning if it isn't. Thoughs? 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
Re: [PATCH 0/2] Add R8A7794 GPIO DT support
On Tue, Feb 24, 2015 at 07:00:33AM +0900, Simon Horman wrote: > On Sun, Feb 22, 2015 at 01:10:19AM +0300, Sergei Shtylyov wrote: > > Hello. > > > >Here's the set of 2 patches against Simon Horman's 'renesas.git' repo, > > 'renesas-devel-20150220-v3.19' tag. Here we add the GPIO device tree support > > for the R8A7794 SoC. It depends on the R8A7794 PFC/MMCIF device tree patches > > posted recently in order to apply. > > > > [1/2] ARM: shmobile: r8a7794: add GPIO clocks > > [2/2] ARM: shmobile: r8a7794: add GPIO DT support > > Thanks, I have queued these up with Geert's Acks. Sorry, I was too hasty again. I have dropped these pending the dependencies being queued up. -- 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 PATCH 1/3] eeprom: Add a simple EEPROM framework
On 02/22/15 16:57, Rob Herring wrote:
> On Sun, Feb 22, 2015 at 8:32 AM, Maxime Ripard
> wrote:
>> On Fri, Feb 20, 2015 at 04:01:55PM -0600, Rob Herring wrote:
>>> [...]
>>>
>> += Data consumers =
>> +
>> +Required properties:
>> +
>> +eeproms: List of phandle and data cell specifier triplet, one triplet
>> +for each data cell the device might be interested in. The
>> +triplet consists of the phandle to the eeprom provider, then
>> +the offset in byte within that storage device, and the length
>> +in byte of the data we care about.
>
> The problem with this is it assumes you know who the consumer is and
> that it is a DT node. For example, how would you describe a serial
> number?
Correct me if I miss understood.
Is serial number any different?
Am hoping that the eeprom consumer would be aware of offset and size of
serial number in the eeprom
Cant the consumer do:
eeprom-consumer {
eeproms = <&at24 0 4>;
eeprom-names = "device-serial-number";
>>> Yes, but who is "eeprom-consumer"?
>> Any device that should lookup values in one of the EEPROM.
>>
>>> DT nodes generally describe a h/w block, but it this case, the
>>> consumer depends on the OS, not the h/w.
>> Not really, or at least, not more than any similar binding we
>> currently have.
>>
>> The fact that a MAC-address for the first ethernet chip is stored at a
>> given offset in a given eeprom has nothing to do with the OS.
> So MAC address would be a valid use to link to a h/w device, but there
> are certainly cases that don't correspond to a device.
>
>>> I'm not saying you can't describe where things are, but I don't
>>> think you should imply who is the consumer and doing so is
>>> unnecessarily complicated.
>> If you only take the case of a serial number, indeed. If you take
>> other usage into account, you can't really do without it.
>>
>>> Also, the layout of EEPROM is likely very much platform specific.
>> Indeed, which is why it should be in the DT.
> Agreed. I'm not saying the layout should not be.
>
>>> Some could have a more complex structure perhaps with key ids and
>>> linked list structure.
>> Then just request the size of the whole list, and parse it afterwards
>> in your driver?
>>
>>> I would do something more simple that is just a list of keys and their
>>> location like this:
>>>
>>> device-serial-number = ;
>>> key1 = ;
>>> key2 = ;
>> I'm sorry, but what's the difference?
> It can describe the layout completely whether the fields are tied to a
> h/w device or not.
>
> What I would like to see here is the entire layout described covering
> both types of fields.
>
I was thinking the DT might be like this on the provider side:
qfprom@100 {
reg = <0x100 0x1000>;
ranges = <0 0x100 0x1000>;
compatible = "qcom,qfprom-msm8960"
pvs-data: pvs-data@40 {
compatible = "qcom,pvs-a";
reg = <0x40 0x20>,
#eeprom-cells = <0>;
};
tsens-data: tmdata@10 {
compatible = "qcom,tsens-data-msm8960";
reg = <0x10 4>, <0x16 4>;
#eeprom-cells = <0>;
};
serial-number: serial@50 {
compatible = "qcom,serial-msm8960";
reg = <0x50 4>, <0x60 4>;
#eeprom-cells = <0>;
};
};
and then on the consumer side:
device {
eeproms = <&serial-number>;
eeprom-names = "soc-rev-id";
};
This would solve a problem where the consumer device is some standard
off-the-shelf IP block that needs to get some SoC specific calibration
data from the eeprom. I may want to interpret the bits differently
depending on which eeprom is connected to my SoC. Sometimes that data
format may be the same across many variations of the SoC (e.g. the
qcom,pvs-a node) or it may be completely different for a given SoC (e.g.
qcom,serial-msm8960 node). I imagine for other SoCs out there it could
be different depending on which eeprom the board manufacturer decides to
wire onto their board and how they choose to program the data.
So this is where I think the eeprom-cells and offset + length starts to
fall apart. It forces us to make up a bunch of different compatible
strings for our consumer device just so that we can parse the eeprom
that we decided to use for some SoC/board specific data. Instead I'd
like to see some framework that expresses exactly which eeprom is on my
board and how to interpret the bits in a way that doesn't require me to
keep refining the compatible string for my generic IP block.
I worry that if we put all those details in DT we'll end up having to
describe individual bits like serial-number-bit-2, serial-number-bit-3,
etc. because sometimes these pieces of data are scattered all around the
eeprom and aren't contiguous or aligned on a byte boundary. It may be
easier to just have a way to express that this
Re: [PATCH v6 0/7] PCI: get DMA configuration from parent device
On 02/23/2015 05:15 PM, Bjorn Helgaas wrote: On Mon, Feb 23, 2015 at 4:08 PM, Murali Karicheri wrote: On 02/11/2015 11:58 AM, Murali Karicheri wrote: On 02/11/2015 11:54 AM, Murali Karicheri wrote: On 02/06/2015 01:36 PM, Murali Karicheri wrote: On 02/06/2015 12:53 PM, Bjorn Helgaas wrote: On Fri, Feb 6, 2015 at 9:28 AM, Murali Karicheri wrote: On 02/06/2015 10:15 AM, Catalin Marinas wrote: On Thu, Feb 05, 2015 at 09:52:52PM +, Murali Karicheri wrote: This patch add an important capability to PCI driver on Keystone. I hope to have this merged to the upstream branch so that it is available for v3.20. It's very late for 3.20 and the code hasn't been in linux-next at all (but it's not me who's merging this code), unless you can squeeze it in as a bug-fix. This is in fact a bug fix as PCI on Keystone is broken without this. Oh, sorry, I didn't realize that this was so urgent. I guess I read "this adds an important capability" in the cover letter and concluded that it was new functionality. Bjorn, Thanks for responding. Let me give you some context on this without which my explanation won't be complete. For using PCI driver on Keystone, I had submitted patches related to machine and DTS to the arm mailing list to enable the driver on Keystone. Subsequenty one of the patch from my series was Nack-ed and I was asked to implememented in a different way and started this series. You can refer to the discussion of this at http://www.gossamer-threads.com/lists/linux/kernel/2024591 The PCI driver enablement on Keystone is still a working in progress and I am trying to get it fully functional on the upstream. Another missing piece is the SerDes phy driver patch. We have started working on the other part (SerDes phy driver) already as the initial one was not accepted. So it is fine if we are too late for the v3.20 merge window to merge this series and this can be applied to the next branch for v3.21. Anyway, if it's broken, presumably PCI on Keystone *did* work at one point. Can you identify the commit that broke it and requires these fixes, so we can figure out how far the fixes need to be backported? I am trying to get this driver enabled on Keystone by adding the missing pieces as described above. So I guess we don't have to back port anything here. If I merge it, I would like to get into my for-linus branch and get a little time in -next before asking Linus to pull it. The merge window is a little wrinkle there -- I don't like to add new things to the mix during the window. But if it's an important fix we can still get it in before the final v3.20. Please apply this to next branch for v3.21. It currently apply cleanly to v3.19-rc7. If you want me rebase to another branch, let me know I can apply and send you an updated patch. Bjorn, Arnd, I am assuming, Bjorn is going to merge this to his next branch for v3.21. If not, it might have to be merged through the arm soc? There are a couple of Tested-by and Acked-by received after v7. Do you want me to post v8 with these updated in the patches? FYI. These are the updates. Series was 1) Tested-by: Suravee Suthikulpanit (on AMD Seattle platform w/ PCI Generic Host controller) 2) Acked-by: Will Deacon 3) Reviewed-by: Catalin Marinas Bjorn, I haven't seen a reply from my above email. As soon as you are ready to pull this to v4.1 next (originally requested for v3.21 as per above email)branch, please let me know and I can send you an updated version rebased to your next branch and with the above acks. My "next" and "for-linus" branches will be based on v4.0-rc1, so that's the ideal base for patches. I don't expect any significant changes that would require a rebase, so unless something in your patches themselves has changed since you last posted them, you don't need to repost them just for a rebase. Bjorn, Thanks for the response. Nothing from my side except for the above acks/tested-by/reviewed-by Murali Bjorn -- Murali Karicheri Linux Kernel, Texas Instruments -- 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/7] OPP: Redefine bindings to overcome shortcomings
Viresh Kumar writes: > Current OPP (Operating performance point) DT bindings are proven to be > insufficient at multiple instances. > > There had been multiple band-aid approaches to get them fixed (The latest one > being: http://www.mail-archive.com/devicetree@vger.kernel.org/msg53398.html). > For obvious reasons Rob rejected them and shown the right path forward. > > The shortcomings we are trying to solve here: > > - Getting clock sharing information between CPUs. Single shared clock vs > independent clock per core vs shared clock per cluster. > > - Support for turbo modes > > - Support for intermediate frequencies or OPPs we can switch to. > > - Other per OPP settings: transition latencies, disabled status, etc.? > > - Expandability of OPPs in future. > > This patch introduces new bindings "operating-points-v2" to get these problems > solved. Refer to the bindings for more details. > > Signed-off-by: Viresh Kumar [...] > +* OPP Descriptor Node > + > +This describes the OPPs belonging to a device. This node can have following > +properties: > + > +Required properties: > +- compatible: Allow OPPs to express their compatibility. It should be: > + "operating-points-v2". > +- OPP nodes: One or more OPP nodes describing frequency-voltage pairs. Their > + name isn't significant but their phandles can be used to reference an OPP. > + > +Optional properties: > +- shared-opp: Indicates that device nodes using this OPP descriptor's phandle > + switch their DVFS state together, i.e. they share clock lines. ... or shared voltage rail? > + Missing property means devices have independent clock lines, but they > share OPPs. huh? missing 'shared-opp' property means they share OPPs? -ECONFUSED. Maybe I missed some of the discussion of why this property is needed, but I'm left wondering why it's needed explicitly. With the OPPs as part of the CPU nodes, shouldnt' the "shared" nature of the OPP be easily derived from the clock and or regulator (opp-supply) property of the CPU nodes? IOW, if two CPU nodes share a clock and/or a regulator, the framework should know it's "shared". Or, were there other reasons besides clocks/regulators why this property was needed (if so, the documentation doesn't describe them.) Kevin -- 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 0/7] PCI: get DMA configuration from parent device
On Mon, Feb 23, 2015 at 4:08 PM, Murali Karicheri wrote: > On 02/11/2015 11:58 AM, Murali Karicheri wrote: >> >> On 02/11/2015 11:54 AM, Murali Karicheri wrote: >>> >>> On 02/06/2015 01:36 PM, Murali Karicheri wrote: On 02/06/2015 12:53 PM, Bjorn Helgaas wrote: > > On Fri, Feb 6, 2015 at 9:28 AM, Murali Karicheri > wrote: >> >> On 02/06/2015 10:15 AM, Catalin Marinas wrote: >>> >>> >>> On Thu, Feb 05, 2015 at 09:52:52PM +, Murali Karicheri wrote: This patch add an important capability to PCI driver on Keystone. I hope to have this merged to the upstream branch so that it is available for v3.20. >>> >>> >>> It's very late for 3.20 and the code hasn't been in linux-next at all >>> (but it's not me who's merging this code), unless you can squeeze >>> it in >>> as a bug-fix. >> >> >> This is in fact a bug fix as PCI on Keystone is broken without this. > > > Oh, sorry, I didn't realize that this was so urgent. I guess I read > "this adds an important capability" in the cover letter and concluded > that it was new functionality. Bjorn, Thanks for responding. Let me give you some context on this without which my explanation won't be complete. For using PCI driver on Keystone, I had submitted patches related to machine and DTS to the arm mailing list to enable the driver on Keystone. Subsequenty one of the patch from my series was Nack-ed and I was asked to implememented in a different way and started this series. You can refer to the discussion of this at http://www.gossamer-threads.com/lists/linux/kernel/2024591 The PCI driver enablement on Keystone is still a working in progress and I am trying to get it fully functional on the upstream. Another missing piece is the SerDes phy driver patch. We have started working on the other part (SerDes phy driver) already as the initial one was not accepted. So it is fine if we are too late for the v3.20 merge window to merge this series and this can be applied to the next branch for v3.21. > > Anyway, if it's broken, presumably PCI on Keystone *did* work at one > point. Can you identify the commit that broke it and requires these > fixes, so we can figure out how far the fixes need to be backported? > I am trying to get this driver enabled on Keystone by adding the missing pieces as described above. So I guess we don't have to back port anything here. > If I merge it, I would like to get into my for-linus branch and get a > little time in -next before asking Linus to pull it. The merge window > is a little wrinkle there -- I don't like to add new things to the mix > during the window. But if it's an important fix we can still get it > in before the final v3.20. Please apply this to next branch for v3.21. It currently apply cleanly to v3.19-rc7. If you want me rebase to another branch, let me know I can apply and send you an updated patch. >>> Bjorn, Arnd, >>> >>> I am assuming, Bjorn is going to merge this to his next branch for >>> v3.21. If not, it might have to be merged through the arm soc? There are >>> a couple of Tested-by and Acked-by received after v7. Do you want me to >>> post v8 with these updated in the patches? >> >> FYI. >> >> These are the updates. >> Series was >> >> 1) Tested-by: Suravee Suthikulpanit >> (on AMD Seattle platform w/ PCI Generic Host controller) >> 2) Acked-by: Will Deacon >> 3) Reviewed-by: Catalin Marinas >> > Bjorn, > > I haven't seen a reply from my above email. As soon as you are ready to pull > this to v4.1 next (originally requested for v3.21 as per above email)branch, > please let me know and I can send you an updated version rebased to your > next branch and with the above acks. My "next" and "for-linus" branches will be based on v4.0-rc1, so that's the ideal base for patches. I don't expect any significant changes that would require a rebase, so unless something in your patches themselves has changed since you last posted them, you don't need to repost them just for a rebase. Bjorn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/7] PCI: get DMA configuration from parent device
On 02/11/2015 11:58 AM, Murali Karicheri wrote: On 02/11/2015 11:54 AM, Murali Karicheri wrote: On 02/06/2015 01:36 PM, Murali Karicheri wrote: On 02/06/2015 12:53 PM, Bjorn Helgaas wrote: On Fri, Feb 6, 2015 at 9:28 AM, Murali Karicheri wrote: On 02/06/2015 10:15 AM, Catalin Marinas wrote: On Thu, Feb 05, 2015 at 09:52:52PM +, Murali Karicheri wrote: This patch add an important capability to PCI driver on Keystone. I hope to have this merged to the upstream branch so that it is available for v3.20. It's very late for 3.20 and the code hasn't been in linux-next at all (but it's not me who's merging this code), unless you can squeeze it in as a bug-fix. This is in fact a bug fix as PCI on Keystone is broken without this. Oh, sorry, I didn't realize that this was so urgent. I guess I read "this adds an important capability" in the cover letter and concluded that it was new functionality. Bjorn, Thanks for responding. Let me give you some context on this without which my explanation won't be complete. For using PCI driver on Keystone, I had submitted patches related to machine and DTS to the arm mailing list to enable the driver on Keystone. Subsequenty one of the patch from my series was Nack-ed and I was asked to implememented in a different way and started this series. You can refer to the discussion of this at http://www.gossamer-threads.com/lists/linux/kernel/2024591 The PCI driver enablement on Keystone is still a working in progress and I am trying to get it fully functional on the upstream. Another missing piece is the SerDes phy driver patch. We have started working on the other part (SerDes phy driver) already as the initial one was not accepted. So it is fine if we are too late for the v3.20 merge window to merge this series and this can be applied to the next branch for v3.21. Anyway, if it's broken, presumably PCI on Keystone *did* work at one point. Can you identify the commit that broke it and requires these fixes, so we can figure out how far the fixes need to be backported? I am trying to get this driver enabled on Keystone by adding the missing pieces as described above. So I guess we don't have to back port anything here. If I merge it, I would like to get into my for-linus branch and get a little time in -next before asking Linus to pull it. The merge window is a little wrinkle there -- I don't like to add new things to the mix during the window. But if it's an important fix we can still get it in before the final v3.20. Please apply this to next branch for v3.21. It currently apply cleanly to v3.19-rc7. If you want me rebase to another branch, let me know I can apply and send you an updated patch. Bjorn, Arnd, I am assuming, Bjorn is going to merge this to his next branch for v3.21. If not, it might have to be merged through the arm soc? There are a couple of Tested-by and Acked-by received after v7. Do you want me to post v8 with these updated in the patches? FYI. These are the updates. Series was 1) Tested-by: Suravee Suthikulpanit (on AMD Seattle platform w/ PCI Generic Host controller) 2) Acked-by: Will Deacon 3) Reviewed-by: Catalin Marinas Bjorn, I haven't seen a reply from my above email. As soon as you are ready to pull this to v4.1 next (originally requested for v3.21 as per above email)branch, please let me know and I can send you an updated version rebased to your next branch and with the above acks. Thanks and regards, Murali If you want to send a updated series with these, please let me know. Thanks and regards, Murali Murali Thanks Murali Bjorn -- Murali Karicheri Linux Kernel, Texas Instruments -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] arm: msm: Use timer DT node for qcom watchdog config
On 02/23/15 13:35, Arnd Bergmann wrote:
> On Friday 20 February 2015 18:19:33 Mathieu Olivari wrote:
>> This change is done as a follow-up to the following thread:
>> https://lkml.org/lkml/2014/10/1/436
>>
>> qcom-wdt is currently assuming the presence of a dedicated node in DT
>> to gets its configuration. However, on msm architecture, the watchdog is
>> usually part of the timer block. So this patch-set is changing the driver
>> and slightly enhancing the timer DT bindings to provide the relevant clocks
>> and interrupts.
>>
>> Mathieu Olivari (3):
>> watchdog: qcom: use timer devicetree binding
>> ARM: qcom: add description of KPSS WDT for IPQ8064
>> ARM: msm: add watchdog entries to DT timer binding doc
>>
>> Documentation/devicetree/bindings/arm/msm/timer.txt | 16 +---
>> arch/arm/boot/dts/qcom-ipq8064.dtsi | 14 +-
>> drivers/watchdog/qcom-wdt.c | 21
>> +++--
>> 3 files changed, 41 insertions(+), 10 deletions(-)
>>
>>
> What about the binding document in
> Documentation/devicetree/bindings/watchdog/qcom-wdt.txt?
>
>
We can rewrite it for platforms starting with msm8974 and beyond or
delete it and write a new binding. It's a similar hardware block split
out from the timers and then made to use a SPI instead of a PPI for the
interrupt sources. We also lost the CPU remapping feature so there is
really only one watchdog instead of 2 per cpu. Oh and the register
offsets are different, but otherwise the registers are the same.
---8<-
From: Stephen Boyd
Subject: [PATCH] Documentation: qcom-wdt: Update binding for individual block
On msm8974 and beyond the KPSS watchdog is split out of the timer
block and made to be a single instance instead of per-cpu. Let's
update the binding to reflect this and replace the binding that
is handled by the qcom,kpss-timer binding.
Signed-off-by: Stephen Boyd
---
Documentation/devicetree/bindings/watchdog/qcom-wdt.txt | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/watchdog/qcom-wdt.txt
b/Documentation/devicetree/bindings/watchdog/qcom-wdt.txt
index 4726924d034e..78b92bec4c3a 100644
--- a/Documentation/devicetree/bindings/watchdog/qcom-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/qcom-wdt.txt
@@ -2,14 +2,10 @@ Qualcomm Krait Processor Sub-system (KPSS) Watchdog
---
Required properties :
-- compatible : shall contain only one of the following:
-
- "qcom,kpss-wdt-msm8960"
- "qcom,kpss-wdt-apq8064"
- "qcom,kpss-wdt-ipq8064"
-
+- compatible : shall contain "qcom,kpss-wdt"
- reg : shall contain base register location and length
- clocks : shall contain the input clock
+- interrupts : shall contain the bark and bite interrupts in that order
Optional properties :
- timeout-sec : shall contain the default watchdog timeout in seconds,
@@ -17,8 +13,9 @@ Optional properties :
Example:
watchdog@208a038 {
- compatible = "qcom,kpss-wdt-ipq8064";
- reg = <0x0208a038 0x40>;
+ compatible = "qcom,kpss-wdt";
+ reg = <0xf9017000 0x1000>;
+ interrupts = <0 3 0>, <0 4 0>;
clocks = <&sleep_clk>;
timeout-sec = <10>;
};
--
Qualcomm Innovation Center, Inc. is a member of 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 2/2] ARM: shmobile: silk: add SDHI0/1 DT support
On Sun, Feb 22, 2015 at 05:54:13PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 02/22/2015 03:45 AM, Magnus Damm wrote:
>
> >>Define the SILK board dependent parts of the SDHI0 (connected to SDIO Wi-Fi
> >>chip) and SDHI1 (connected to micro-SD slot) device nodes along with the
> >>necessary voltage regulators.
>
> >>Based on the original patch by Vladimir Barinov
> >>.
>
> >>Signed-off-by: Sergei Shtylyov
>
> >Thanks for your patch. One question - above you write that SDHI1 is
> >micro-SD...
>
>Yes, have double-checked now.
>
> >>@@ -100,3 +159,25 @@
> >> non-removable;
> >> status = "okay";
> >> };
> >>+
> >>+&sdhi0 {
> >>+ pinctrl-0 = <&sdhi0_pins>;
> >>+ pinctrl-names = "default";
> >>+
> >>+ vmmc-supply = <&vcc_sdhi0>;
> >>+ vqmmc-supply = <&vccq_sdhi0>;
> >>+ cd-gpios = <&gpio6 6 GPIO_ACTIVE_LOW>;
> >>+ wp-gpios = <&gpio6 7 GPIO_ACTIVE_LOW>;
> >>+ status = "okay";
> >>+};
> >>+
> >>+&sdhi1 {
> >>+ pinctrl-0 = <&sdhi1_pins>;
> >>+ pinctrl-names = "default";
> >>+
> >>+ vmmc-supply = <&vcc_sdhi1>;
> >>+ vqmmc-supply = <&vccq_sdhi1>;
> >>+ cd-gpios = <&gpio6 14 GPIO_ACTIVE_LOW>;
> >>+ wp-gpios = <&gpio6 15 GPIO_ACTIVE_LOW>;
> >>+ status = "okay";
> >>+};
>
> >... however here the WP signal is assigned.
>
> >I believe micro-SD doesn't use the WP signal, so either I'm wrong or
> >the patch needs to be updated to reflect reality. =)
>
>Both seem correct: SD1_WP signal is just tied to VCCQ_SD1. Do you think
> we should still drop it?
>
> >Also, I doubt that an on-board SDIO module makes use of CD and/or WP signals?
>
>Those two are tied to VCCQ_SD0 as well. Do you think we should drop them?
I am holding off on queuing this up until some consensus is reached.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Add R8A7794 GPIO DT support
On Sun, Feb 22, 2015 at 01:10:19AM +0300, Sergei Shtylyov wrote: > Hello. > >Here's the set of 2 patches against Simon Horman's 'renesas.git' repo, > 'renesas-devel-20150220-v3.19' tag. Here we add the GPIO device tree support > for the R8A7794 SoC. It depends on the R8A7794 PFC/MMCIF device tree patches > posted recently in order to apply. > > [1/2] ARM: shmobile: r8a7794: add GPIO clocks > [2/2] ARM: shmobile: r8a7794: add GPIO DT support Thanks, I have queued these up with Geert's Acks. -- 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] ARM: shmobile: r8a7794: add SDHI DT support
On Mon, Feb 23, 2015 at 12:16:47PM +0100, Geert Uytterhoeven wrote: > On Sat, Feb 21, 2015 at 11:26 PM, Sergei Shtylyov > wrote: > > Define the generic R8A7794 parts of the SDHI[012] device nodes. > > > > Based on the orginal patch by Shinobu Uehara > > . > > > > Signed-off-by: Sergei Shtylyov > > Acked-by: Geert Uytterhoeven Thanks, I have queued this up. -- 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 v5] thermal: Add QPNP PMIC temperature alarm driver
On Thu, Feb 05, 2015 at 07:12:56PM +0200, Ivan T. Ivanov wrote:
> Add support for the temperature alarm peripheral found inside
> Qualcomm plug-and-play (QPNP) PMIC chips. The temperature alarm
> peripheral outputs a pulse on an interrupt line whenever the
> thermal over temperature stage value changes.
>
> Register a thermal sensor. The temperature reported by this thermal
> sensor device should reflect the actual PMIC die temperature if an
> ADC is present on the given PMIC. If no ADC is present, then the
> reported temperature should be estimated from the over temperature
> stage value.
>
> Cc: David Collins
> Signed-off-by: Ivan T. Ivanov
Applying to my -linus branch.
Thanks.
> ---
>
> Changes since v4:
>
> - Reorder IRQ platform get and IIO channel get, this
> fixes error exit path.
>
> - Reorder IRQ request and sensor register calls, this
> simplify error exit path.
>
> v4: https://lkml.org/lkml/2015/2/2/413
>
> .../bindings/thermal/qcom-spmi-temp-alarm.txt | 57
> drivers/thermal/Kconfig| 11 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/qcom-spmi-temp-alarm.c | 309
> +
> 4 files changed, 378 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/thermal/qcom-spmi-temp-alarm.txt
> create mode 100644 drivers/thermal/qcom-spmi-temp-alarm.c
>
> diff --git
> a/Documentation/devicetree/bindings/thermal/qcom-spmi-temp-alarm.txt
> b/Documentation/devicetree/bindings/thermal/qcom-spmi-temp-alarm.txt
> new file mode 100644
> index 000..290ec06
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/qcom-spmi-temp-alarm.txt
> @@ -0,0 +1,57 @@
> +Qualcomm QPNP PMIC Temperature Alarm
> +
> +QPNP temperature alarm peripherals are found inside of Qualcomm PMIC chips
> +that utilize the Qualcomm SPMI implementation. These peripherals provide an
> +interrupt signal and status register to identify high PMIC die temperature.
> +
> +Required properties:
> +- compatible: Should contain "qcom,spmi-temp-alarm".
> +- reg: Specifies the SPMI address and length of the controller's
> + registers.
> +- interrupts: PMIC temperature alarm interrupt.
> +- #thermal-sensor-cells: Should be 0. See thermal.txt for a description.
> +
> +Optional properties:
> +- io-channels: Should contain IIO channel specifier for the ADC channel,
> + which report chip die temperature.
> +- io-channel-names: Should contain "thermal".
> +
> +Example:
> +
> + pm8941_temp: thermal-alarm@2400 {
> + compatible = "qcom,spmi-temp-alarm";
> + reg = <0x2400 0x100>;
> + interrupts = <0 0x24 0 IRQ_TYPE_EDGE_RISING>;
> + #thermal-sensor-cells = <0>;
> +
> + io-channels = <&pm8941_vadc VADC_DIE_TEMP>;
> + io-channel-names = "thermal";
> + };
> +
> + thermal-zones {
> + pm8941 {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = <&pm8941_temp>;
> +
> + trips {
> + passive {
> + temperature = <105>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> + alert {
> + temperature = <125000>;
> + hysteresis = <2000>;
> + type = "hot";
> + };
> + crit {
> + temperature = <145000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> + };
> +
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index af40db0..30aee81 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -299,4 +299,15 @@ depends on ARCH_STI && OF
> source "drivers/thermal/st/Kconfig"
> endmenu
>
> +config QCOM_SPMI_TEMP_ALARM
> + tristate "Qualcomm SPMI PMIC Temperature Alarm"
> + depends on OF && SPMI && IIO
> + select REGMAP_SPMI
> + help
> + This enables a thermal sysfs driver for Qualcomm plug-and-play (QPNP)
> + PMIC devices. It shows up in sysfs as a thermal sensor with multiple
> + trip points. The temperature reported by the thermal sensor reflects
> the
> + real time die temperature if an ADC is present or an estimate of the
> + temperature based upon the over temperature stage value.
> +
> endif
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index fa0dc48..1fe8665 100644
> --- a/drivers/thermal/Makefile
> +++ b/d
Re: [rtc-linux] [PATCH 2/2] rtc: mediatek: Add MT63xx RTC driver
On Wed, 28 Jan 2015 17:27:56 +0800 Eddie Huang wrote:
> From: Tianping Fang
>
> Add Mediatek MT63xx RTC driver
There are a couple of checkpatch warnings which should be addressed,
please:
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#150:
new file mode 100644
WARNING: DT compatible string "mediatek,mt6397-rtc" appears un-documented --
check ./Documentation/devicetree/bindings/
#488: FILE: drivers/rtc/rtc-mt6397.c:334:
+ { .compatible = "mediatek,mt6397-rtc", },
>
> ...
>
> +static u16 rtc_read(struct mt6397_rtc *rtc, u32 offset)
> +{
> + u32 rdata = 0;
> + u32 addr = rtc->addr_base + offset;
> +
> + if (offset < rtc->addr_range)
> + regmap_read(rtc->regmap, addr, &rdata);
> +
> + return (u16)rdata;
> +}
> +
> +static void rtc_write(struct mt6397_rtc *rtc, u32 offset, u32 data)
> +{
> + u32 addr;
> +
> + addr = rtc->addr_base + offset;
> +
> + if (offset < rtc->addr_range)
> + regmap_write(rtc->regmap, addr, data);
> +}
regmap_read() and regmap_write() can return errors. There is no
checking for this.
> +static void rtc_write_trigger(struct mt6397_rtc *rtc)
> +{
> + rtc_write(rtc, RTC_WRTGR, 1);
> + while (rtc_read(rtc, RTC_BBPU) & RTC_BBPU_CBUSY)
> + cpu_relax();
> +}
> +
>
> ...
>
> +static int mtk_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alm)
> +{
> + struct rtc_time *tm = &alm->time;
> + struct mt6397_rtc *rtc = dev_get_drvdata(dev);
> + u16 irqen, pdn2;
> +
> + mutex_lock(&rtc->lock);
> + irqen = rtc_read(rtc, RTC_IRQ_EN);
> + pdn2 = rtc_read(rtc, RTC_PDN2);
> + tm->tm_sec = rtc_read(rtc, RTC_AL_SEC);
> + tm->tm_min = rtc_read(rtc, RTC_AL_MIN);
> + tm->tm_hour = rtc_read(rtc, RTC_AL_HOU) & RTC_AL_HOU_MASK;
> + tm->tm_mday = rtc_read(rtc, RTC_AL_DOM) & RTC_AL_DOM_MASK;
> + tm->tm_mon = rtc_read(rtc, RTC_AL_MTH) & RTC_AL_MTH_MASK;
> + tm->tm_year = rtc_read(rtc, RTC_AL_YEA);
> + mutex_unlock(&rtc->lock);
> +
> + alm->enabled = !!(irqen & RTC_IRQ_EN_AL);
> + alm->pending = !!(pdn2 & RTC_PDN2_PWRON_ALARM);
> +
> + tm->tm_year += RTC_MIN_YEAR_OFFSET;
> + tm->tm_mon--;
> +
> + return 0;
> +}
> +
> +static int mtk_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alm)
> +{
> + struct rtc_time *tm = &alm->time;
> + struct mt6397_rtc *rtc = dev_get_drvdata(dev);
> + u16 irqen;
> +
> + tm->tm_year -= RTC_MIN_YEAR_OFFSET;
> + tm->tm_mon++;
> +
> + if (alm->enabled) {
> + mutex_lock(&rtc->lock);
> + rtc_write(rtc, RTC_AL_YEA, tm->tm_year);
> + rtc_write(rtc, RTC_AL_MTH, (rtc_read(rtc, RTC_AL_MTH) &
> + RTC_NEW_SPARE3) | tm->tm_mon);
> + rtc_write(rtc, RTC_AL_DOM, (rtc_read(rtc, RTC_AL_DOM) &
> + RTC_NEW_SPARE1) | tm->tm_mday);
> + rtc_write(rtc, RTC_AL_HOU, (rtc_read(rtc, RTC_AL_HOU) &
> + RTC_NEW_SPARE_FG_MASK) | tm->tm_hour);
> + rtc_write(rtc, RTC_AL_MIN, tm->tm_min);
> + rtc_write(rtc, RTC_AL_SEC, tm->tm_sec);
> + rtc_write(rtc, RTC_AL_MASK, RTC_AL_MASK_DOW);
> + rtc_write_trigger(rtc);
> + irqen = rtc_read(rtc, RTC_IRQ_EN) | RTC_IRQ_EN_ONESHOT_AL;
> + rtc_write(rtc, RTC_IRQ_EN, irqen);
> + rtc_write_trigger(rtc);
> + mutex_unlock(&rtc->lock);
> + }
> +
> + return 0;
> +}
This all looks a bit racy. Wouldn't it be better if the testing of and
modification of ->enabled and ->pending were protected by the mutex?
>
> ...
>
> +static int mtk_rtc_probe(struct platform_device *pdev)
> +{
> + struct mt6397_chip *mt6397_chip = dev_get_drvdata(pdev->dev.parent);
> + struct mt6397_rtc *rtc;
> + u32 reg[2];
> + int ret = 0;
> +
> + rtc = devm_kzalloc(&pdev->dev, sizeof(struct mt6397_rtc), GFP_KERNEL);
> + if (!rtc)
> + return -ENOMEM;
> +
> + ret = of_property_read_u32_array(pdev->dev.of_node, "reg", reg, 2);
> + if (ret) {
> + dev_err(&pdev->dev, "couldn't read rtc base address!\n");
> + return -EINVAL;
> + }
> + rtc->addr_base = reg[0];
> + rtc->addr_range = reg[1];
> + rtc->regmap = mt6397_chip->regmap;
> + rtc->dev = &pdev->dev;
> + mutex_init(&rtc->lock);
> +
> + platform_set_drvdata(pdev, rtc);
> +
> + rtc->rtc_dev = rtc_device_register("mt6397-rtc", &pdev->dev,
> + &mtk_rtc_ops, THIS_MODULE);
> + if (IS_ERR(rtc->rtc_dev)) {
> + dev_err(&pdev->dev, "register rtc device failed\n");
> + return PTR_ERR(rtc->rtc_dev);
> + }
> +
> + rtc->irq = platform_get_irq(pdev, 0);
> + if (rtc->irq < 0) {
> + ret = rtc->irq;
> + goto out_rtc;
> + }
> +
> + ret = devm_request_threaded_irq(&pdev->dev, rtc->irq, NULL,
> + rtc_irq_handler_th
Re: [PATCH v3 3/3] Linn Ethernet packet sniffer driver
From: Stathis Voukelatos Date: Mon, 23 Feb 2015 14:26:22 + > Driver for the Ethernet Mii packet sniffer H/W module found in > the IMG Pistachio SoC. > > Signed-off-by: Stathis Voukelatos You really have to explain what this thing does, how it is used, what APIs are made use of to maniulate this device, etc. Nobody knows what the packet sniffer module by your company is. I also anticipate that once you describe adequately how this thing behaves I won't like it, and I'll prefer that you integrate support for your device using an exising facility such as AF_PACKET, extending it if need be. I am very far away from applying this series at this point, it needs a lot more work and explanations. -- 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 2/3] Packet sniffer core framework
From: Stathis Voukelatos Date: Mon, 23 Feb 2015 14:26:21 + > + spin_lock_irqsave(&priv->lock, flags); > + /* Stop the hardware */ > + sch->stop(sch); > + /* Set the new command pattern */ > + ret = sch->set_pattern(sch, skb->data, skb->len / 2); > + /* Restart the hardware */ > + sch->start(sch); > + spin_unlock_irqrestore(&priv->lock, flags); These comments are excessive. When someone calls ops->stop() what are they supposed to think the thing does? Open a can of tuna? Mow the lawn? Wash the dishes? No, it stops the thing. Everyone understands that and you don't have to explicitly say it. Saying "stop the hardware" does not add anything to the source code that is not already implicitly there. They just take up space and keep more useful information from being displayed at once on the screen. Please remove all of these things. Thanks. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] arm: msm: Use timer DT node for qcom watchdog config
On Friday 20 February 2015 18:19:33 Mathieu Olivari wrote: > This change is done as a follow-up to the following thread: > https://lkml.org/lkml/2014/10/1/436 > > qcom-wdt is currently assuming the presence of a dedicated node in DT > to gets its configuration. However, on msm architecture, the watchdog is > usually part of the timer block. So this patch-set is changing the driver > and slightly enhancing the timer DT bindings to provide the relevant clocks > and interrupts. > > Mathieu Olivari (3): > watchdog: qcom: use timer devicetree binding > ARM: qcom: add description of KPSS WDT for IPQ8064 > ARM: msm: add watchdog entries to DT timer binding doc > > Documentation/devicetree/bindings/arm/msm/timer.txt | 16 +--- > arch/arm/boot/dts/qcom-ipq8064.dtsi | 14 +- > drivers/watchdog/qcom-wdt.c | 21 > +++-- > 3 files changed, 41 insertions(+), 10 deletions(-) > > What about the binding document in Documentation/devicetree/bindings/watchdog/qcom-wdt.txt? Arnd -- 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 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip
On Mon, 23 Feb 2015 18:14:48 + Mark Rutland wrote: [...] > > This is because irq_may_run [1], which is called to decide whether we > > should handle this irq or just wake the system up [2], will always > > return true if at least one of the shared action has tagged the irq > > line as a wakeup source. > > I assume you mean we return false in this case (having triggered the > wakeup within irq_pm_check_wakeup, which returned true), but otherwise > agreed. Yep, I meant 'return false'. > > I can envisage problems if the irq handler of a wakeup device can't be > run safely until resume time, though I'm not sure if that happens in > practice given the device is necessarily going to be active. Isn't that the purpose of the IRQF_NO_SUSPEND_SAFE/IRQF_SHARED_TIMER_OK/IRQF_SHARED_WAKEUP_SIBLING_OK flag ? > > > Sorry for summarizing things you most likely already know, but I want > > to be sure I'm actually understanding it correctly. > > > > Now, let's look at how this could be solved. > > Here is a proposal [3] that does the following: > > This would be a lot easier to follow/review as an RFC post to the > mailing list. Yep, that was the plan, just wanted to make sure I had correctly understood the problem before posting an RFC. > Otherwise I have some high-level comments on the stuff > below, which I think matches the shape of what we discussed on IRC. > > > 1/ prevent a system wakeup when at least one of the action handler > > has set the IRQF_NO_SUSPEND flag > > We might need to add some logic to enable_irq_wake and > irq_pm_install_action to prevent some of the horrible mismatch cases we > can get here (e.g. if we have a wakeup handler, a IRQF_NO_SUSPEND > handler, and another handler which is neither). We may need to > reconsider temporarily stashing the other potential interrupts. Actually if we force users to pass the IRQF_XXX_SAFE (I'm tired writing all the potential names :-)), when mixing IRQF_NO_SUSPEND and !IRQF_NO_SUSPEND handlers, we shouldn't bother deactivating normal handlers (those without IRQF_NO_SUSPEND), 'cause they claimed they could safely be called in suspended state. > > Do we perhaps need an IRQF_SHARED_WAKEUP_SIBLING_OK for timer drivers to > assert their handlers are safe for the whole suspend period rather than > just the period they expect to be enabled for? Or do those always > happen to be safe in practice? I thought they were always safe... > > > 2/ Add a few helpers to deal with system wakeup from drivers code > > The irq_pm_force_wakeup part looks like what I had in mind. > > > 3/ Rework the at91 RTC driver to show how such weird cases could be > > handled > > It might be simpler to do this with a PM notifier within the driver > rather than having to traverse all the irq_descs, though perhaps not. I'm not sure to understand that one. Where am I traversing irq_descs (irq_to_desc, which is called when testing wakeup_armed status, is a direct table indexing operation) ? Moreover, I'm not sure when the PM_POST_SUSPEND event is sent, and testing the WAKEUP_ARMED flag should be safe in all cases, right ? > > > Of course, I'll need the IRQF_SHARED_TIMER_OK patch to prevent the > > WARN_ON backtrace. > > That should be fine; it's backed up in the list archive ;) > > > Please, let me know if I missed anything important, share your opinion > > on this proposal, and feel free to propose any other solution. > > Hopefully the above covers that! Yes it does. Thanks for the review. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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: [v3,5/8] watchdog: st_wdt: Add new driver for ST's LPC Watchdog
On Wed, Feb 18, 2015 at 11:49:11AM +, Lee Jones wrote: > Signed-off-by: David Paris > Signed-off-by: Lee Jones Reviewed-by: Guenter Roeck -- 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/5] ARM: dts: pxa: add pwri2c to pxa device-tree
Robert Jarzmik writes: > Robert Jarzmik writes: > >> pxa27x variant has 2 I2C busses on the SoC : >> - the casual I2C >> - the power I2C, normally driving power regulators, and capable of >> receiving orders on core frequency modifications >> >> Add the missing pwri2c to pxa27x description. >> >> Signed-off-by: Robert Jarzmik > > Hi Rob, Mark, Sergei, > > I'd like to queue that into the pxa/dt tree next week. > Could I have a "Reviewed-by" ? Queued in pxa/dt. Cheers. -- Robert -- 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 3/3] ARM: msm: add watchdog entries to DT timer binding doc
On Fri, Feb 20, 2015 at 06:19:36PM -0800, Mathieu Olivari wrote: > The watchdog has been reworked to use the same DT node as the timer. > This change is updating the device tree doc accordingly. > > Signed-off-by: Mathieu Olivari Acked-by: Guenter Roeck -- 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 2/3] ARM: qcom: add description of KPSS WDT for IPQ8064
On Fri, Feb 20, 2015 at 06:19:35PM -0800, Mathieu Olivari wrote: > Add the watchdog related entries to the Krait Processor Sub-system > (KPSS) timer IPQ8064 devicetree section. Also, add a fixed-clock > description of SLEEP_CLK, which will do for now. > > Signed-off-by: Josh Cartwright > Signed-off-by: Mathieu Olivari Acked-by: Guenter Roeck -- 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/3] watchdog: qcom: use timer devicetree binding
On Fri, Feb 20, 2015 at 06:19:34PM -0800, Mathieu Olivari wrote: > MSM watchdog configuration happens in the same register block as the > timer, so we'll use the same binding as the existing timer. > > The qcom-wdt will now be probed when devicetree has an entry compatible > with "qcom,kpss-timer" or "qcom-scss-timer". > > Signed-off-by: Mathieu Olivari Acked-by: Guenter Roeck -- 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] ARM: bcm2835: Add header file for pinctrl constants
On 02/22/2015 09:59 AM, Charles Keepax wrote: This patch adds a header file for the constants used in pincontrol configuration for the bcm2835. This seems like a duplicate of the following series: https://lkml.org/lkml/2015/1/16/402 [PATCH 0/4] ARM: bcm2835: DT improvements [PATCH 1/4] dt-bindings: Add vendor prefix for Raspberry Pi [PATCH 2/4] dt-bindings: Add root properties for Raspberry Pi B and B+ [PATCH 3/4] ARM: bcm2835: Add header file for pinctrl constants https://lkml.org/lkml/2015/1/16/405 [PATCH 4/4] ARM: bcm2835: Use pinctrl header Lee, are you planning on applying one/both/some of these? -- 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] ARM: bcm2835: Add header file for pinctrl constants
On 02/22/2015 01:13 PM, Arnd Bergmann wrote: On Sunday 22 February 2015 16:59:56 Charles Keepax wrote: + +/* IRQ Flags */ +#define BCM2835_PIN_IRQ_RISING 1 +#define BCM2835_PIN_IRQ_FALLING2 +#define BCM2835_PIN_IRQ_EDGE (BCM2835_PIN_IRQ_RISING | \ +BCM2835_PIN_IRQ_FALLING) +#define BCM2835_PIN_IRQ_LOW4 +#define BCM2835_PIN_IRQ_HIGH 8 Are these different from the standard definitions? +/* Pin Function Settings */ +#define BCM2835_PIN_FUNC_GPIO_IN 0 +#define BCM2835_PIN_FUNC_GPIO_OUT 1 +#define BCM2835_PIN_FUNC_ALT5 2 +#define BCM2835_PIN_FUNC_ALT4 3 +#define BCM2835_PIN_FUNC_ALT0 4 +#define BCM2835_PIN_FUNC_ALT1 5 +#define BCM2835_PIN_FUNC_ALT2 6 +#define BCM2835_PIN_FUNC_ALT3 7 Why are these required? They don't seem to be used by any driver, which leads me to suspect that they are just the hardware numbers. In that case, don't add any syntactical sugar like that and just use the hardware numbers directly. What's with the strange mapping of numbers anyway? Especially given that the number->semantics meaning is a little non-linear it seems like using #defines/... to document what the numbers mean seems reasonable. It allows easily validating the DT files without having to go look up the meaning of the numbers in the documentation. -- 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 RESEND 4/4] ARM: bcm2835: Use pinctrl header
On 02/21/2015 04:39 AM, Stefan Wahren wrote: Stephen Warren hat am 9. Februar 2015 um 19:09 geschrieben: On 01/29/2015 11:10 AM, Stefan Wahren wrote: This patch converts all bcm2835 dts and dtsi files to use the pinctrl header file. The series, Reviewed-by: Stephen Warren Sorry for taking a while with this. Fine, but is this series already applied? It doesn't look like it. I was under the impression that Lee was applying bcm2835 patches now, hence why I simply gave my reviewed-by tag rather than doing anything else. Lee, can you comment? -- 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/3] watchdog: qcom: use timer devicetree binding
On 02/20/15 18:19, Mathieu Olivari wrote: > MSM watchdog configuration happens in the same register block as the > timer, so we'll use the same binding as the existing timer. > > The qcom-wdt will now be probed when devicetree has an entry compatible > with "qcom,kpss-timer" or "qcom-scss-timer". > > Signed-off-by: Mathieu Olivari > Reviewed-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of 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 2/3] ARM: qcom: add description of KPSS WDT for IPQ8064
On 02/20/15 18:19, Mathieu Olivari wrote: > Add the watchdog related entries to the Krait Processor Sub-system > (KPSS) timer IPQ8064 devicetree section. Also, add a fixed-clock > description of SLEEP_CLK, which will do for now. > > Signed-off-by: Josh Cartwright > Signed-off-by: Mathieu Olivari > Reviewed-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of 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 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
Hi Peter, > On Feb 23, 2015, at 20:39 , Peter Hurley wrote: > > Hi Pantelis, > > On 02/19/2015 01:44 PM, Pantelis Antoniou wrote: >> Hi Tony, >> >>> On Feb 19, 2015, at 20:36 , Tony Lindgren wrote: >>> >>> * Pantelis Antoniou [150219 10:32]: > On Feb 19, 2015, at 20:16 , Tony Lindgren wrote: > > Uhh I don't like the idea of duplicating the i2c-omap.c driver under > arch/arm.. And in general we should initialize things later rather > than earlier. > > What's stopping doing these quirk checks later on time with just > a regular device driver, something like drivers/misc/bbone-quirks.c? > We have no choice; we are way early in the boot process, right after the device tree unflattening step. >>> >>> To me it seems the dt patching part should be done with minimal >>> code before any driver like features.. >>> >> >> The way it’s done right now is with minimal code. Reading the EEPROM >> is required. >> I’ve toyed with the idea of using early platform devices but the omap-i2c driver would need some tender love and care to make it work, and I didn’t want to get bogged down with i2c driver details at this point. >>> >>> ..so how about just parse a kernel cmdline for the quirks to apply >>> based on a version string or similar? That can be easily populated >>> by u-boot or set manually with setenv. >>> >>> That leaves out the need for tinkering with i2c super early in >>> the kernel for revision detection. >>> >> >> You assume there’s going to be a bootloader… > > So does this patch. > Proof of concept, first iteration… The beaglebone is just the prototype stage. >> diff --git a/arch/arm/mach-omap2/am33xx-dt-quirks.c >> b/arch/arm/mach-omap2/am33xx-dt-quirks.c > [...] >> + * Note that we rely on the bootloader setting up the muxes >> + * (which is the case for u-boot). > > Regards, > Peter Hurley > 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: [PATCHv3] mvebu: add Linksys WRT1900AC (Mamba) support
Hi Gregory, On Mon, 23 Feb 2015 19:32:53 +0100, Gregory CLEMENT wrote: ... @@ -0,0 +1,348 @@ +/* + * Device Tree file for the Linksys WRT1900AC (Mamba). + * + * Note: this board is shipped with a new generation boot loader that + * remaps internal registers at 0xf100. Therefore, if earlyprintk + * is used, the CONFIG_DEBUG_MVEBU_UART_ALTERNATE option should be This symbol name has been removed and DEBUG_MVEBU_UART0_ALTERNATE would be used instead. Besides this, Acked-by: Gregory CLEMENT You don't have to resend a new version for this, I can amend your patch while applying it. So unless there is new comments I will add your patch to the mvebu tree in a couple of days. I knew I will forget something - this has been noted by Andrew back then :) Thank you for taking care of this. Best, Imre -- 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 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
Hi Pantelis, On 02/19/2015 01:44 PM, Pantelis Antoniou wrote: > Hi Tony, > >> On Feb 19, 2015, at 20:36 , Tony Lindgren wrote: >> >> * Pantelis Antoniou [150219 10:32]: On Feb 19, 2015, at 20:16 , Tony Lindgren wrote: Uhh I don't like the idea of duplicating the i2c-omap.c driver under arch/arm.. And in general we should initialize things later rather than earlier. What's stopping doing these quirk checks later on time with just a regular device driver, something like drivers/misc/bbone-quirks.c? >>> >>> We have no choice; we are way early in the boot process, right after >>> the device tree unflattening step. >> >> To me it seems the dt patching part should be done with minimal >> code before any driver like features.. >> > > The way it’s done right now is with minimal code. Reading the EEPROM > is required. > >>> I’ve toyed with the idea of using early platform devices but the omap-i2c >>> driver >>> would need some tender love and care to make it work, and I didn’t want to >>> get >>> bogged down with i2c driver details at this point. >> >> ..so how about just parse a kernel cmdline for the quirks to apply >> based on a version string or similar? That can be easily populated >> by u-boot or set manually with setenv. >> >> That leaves out the need for tinkering with i2c super early in >> the kernel for revision detection. >> > > You assume there’s going to be a bootloader… So does this patch. > diff --git a/arch/arm/mach-omap2/am33xx-dt-quirks.c > b/arch/arm/mach-omap2/am33xx-dt-quirks.c [...] > + * Note that we rely on the bootloader setting up the muxes > + * (which is the case for u-boot). Regards, Peter Hurley -- 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: [PATCHv3] mvebu: add Linksys WRT1900AC (Mamba) support
Hi Imre,
On 16/02/2015 13:31, Imre Kaloz wrote:
> The Linksys WRT1900AC (Mamba) is a router that has
>
> - 2 mini-PCIe slots with Marvell 88W8864 radios
> - 1 USB 3.0 port
> - 1 USB 2.0/eSATAp port
> - 2 Ethernet interfaces connected to a 88E6172 switch (1x WAN + 4x LAN)
> - 128MB NAND flash
> - 256MB RAM
>
> Signed-off-by: Imre Kaloz
> ---
> Changes since v2:
> * added tlc59116 leds
> * added an extra partition for the unused space
> * added serial console pinout
> * renamed the dts to armada-xp-linksys-mamba.dts
>
> Changes since v1:
> * add dual license
> * lower SPI speed to meet the chip's maximum
> * pinctrl cleanups based on Andrew Lunn's suggestions
> ---
> arch/arm/boot/dts/Makefile| 1 +
> arch/arm/boot/dts/armada-xp-linksys-mamba.dts | 348
> ++
> 2 files changed, 349 insertions(+)
> create mode 100644 arch/arm/boot/dts/armada-xp-linksys-mamba.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 91bd5bd..a84063f 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -541,6 +541,7 @@ dtb-$(CONFIG_MACH_ARMADA_XP) += \
> armada-xp-db.dtb \
> armada-xp-gp.dtb \
> armada-xp-lenovo-ix4-300d.dtb \
> + armada-xp-linksys-mamba.dtb \
> armada-xp-matrix.dtb \
> armada-xp-netgear-rn2120.dtb \
> armada-xp-openblocks-ax3-4.dtb \
> diff --git a/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> new file mode 100644
> index 000..0a3d1d6
> --- /dev/null
> +++ b/arch/arm/boot/dts/armada-xp-linksys-mamba.dts
> @@ -0,0 +1,348 @@
> +/*
> + * Device Tree file for the Linksys WRT1900AC (Mamba).
> + *
> + * Note: this board is shipped with a new generation boot loader that
> + * remaps internal registers at 0xf100. Therefore, if earlyprintk
> + * is used, the CONFIG_DEBUG_MVEBU_UART_ALTERNATE option should be
This symbol name has been removed and DEBUG_MVEBU_UART0_ALTERNATE would
be used instead.
Besides this,
Acked-by: Gregory CLEMENT
You don't have to resend a new version for this, I can amend
your patch while applying it. So unless there is new comments
I will add your patch to the mvebu tree in a couple of days.
Thanks,
Gregory
> + * used.
> + *
> + * Copyright (C) 2014 Imre Kaloz
> + *
> + * Based on armada-xp-axpwifiap.dts:
> + *
> + * Copyright (C) 2013 Marvell
> + *
> + * Thomas Petazzoni
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without
> + * any warranty of any kind, whether express or implied.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include
> +#include
> +#include "armada-xp-mv78230.dtsi"
> +
> +/ {
> + model = "Linksys WRT1900AC";
> + compatible = "linksys,mamba", "marvell,armadaxp-mv78230",
> + "marvell,armadaxp", "marvell,armada-370-xp";
> +
> + chosen {
> + bootargs = "console=ttyS0,115200";
> + stdout-path = &uart0;
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x 0x 0x 0x1000>; /* 256MB */
> + };
> +
> + soc {
> + ranges = + MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10>;
> +
> + pcie-controller {
> + status = "okay";
> +
> + /* Etron EJ168 USB 3.0 controller */
> + pcie@1,0 {
Re: [PATCH v4 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip
On Mon, Feb 23, 2015 at 05:00:57PM +, Boris Brezillon wrote: > Hi Mark, > > Thanks for the clarification, and sorry if I've been a bit harsh to you > in my previous answer, but this whole shared irq thing is starting to > drive me crazy. No worries. Having lost a few days exploring the core and call sites, and having seen how widesrpead IRQF_NO_SUSPEND misuse is, it's beginning to grate on me too. [...] > On at91 platforms, irq line 1 is shared by a timer (PIT) and some > devices that can register themselves as wakeup sources (especially the > RTC IP). > I doubt at91 users will agree on dropping either of these features (the > timer or the wakeup on RTC/UART/...), so, can we try to find a solution > that would both make irq, DT and at91 guys happy (that doesn't sound > like an easy task :-)) ? >From the DT side, I think all the necessary information is there. We know how the interrupts are wired, so nothing needs to change w.r.t. the topology description. I hope that we have sufficient information to when a device may operate and raise interrupts during suspend. So the fun part is how we solve this within Linux. > The whole problem here is that we can't have both IRQF_NO_SUSPEND flag > set on one of the shared action and others that are configuring the irq > as a wakeup source, because it would always lead to the system being > woken up (even when the only thing we were supposed to do is handle the > timer event). > > This is because irq_may_run [1], which is called to decide whether we > should handle this irq or just wake the system up [2], will always > return true if at least one of the shared action has tagged the irq > line as a wakeup source. I assume you mean we return false in this case (having triggered the wakeup within irq_pm_check_wakeup, which returned true), but otherwise agreed. I can envisage problems if the irq handler of a wakeup device can't be run safely until resume time, though I'm not sure if that happens in practice given the device is necessarily going to be active. > Sorry for summarizing things you most likely already know, but I want > to be sure I'm actually understanding it correctly. > > Now, let's look at how this could be solved. > Here is a proposal [3] that does the following: This would be a lot easier to follow/review as an RFC post to the mailing list. Otherwise I have some high-level comments on the stuff below, which I think matches the shape of what we discussed on IRC. > 1/ prevent a system wakeup when at least one of the action handler > has set the IRQF_NO_SUSPEND flag We might need to add some logic to enable_irq_wake and irq_pm_install_action to prevent some of the horrible mismatch cases we can get here (e.g. if we have a wakeup handler, a IRQF_NO_SUSPEND handler, and another handler which is neither). We may need to reconsider temporarily stashing the other potential interrupts. Do we perhaps need an IRQF_SHARED_WAKEUP_SIBLING_OK for timer drivers to assert their handlers are safe for the whole suspend period rather than just the period they expect to be enabled for? Or do those always happen to be safe in practice? > 2/ Add a few helpers to deal with system wakeup from drivers code The irq_pm_force_wakeup part looks like what I had in mind. > 3/ Rework the at91 RTC driver to show how such weird cases could be > handled It might be simpler to do this with a PM notifier within the driver rather than having to traverse all the irq_descs, though perhaps not. > Of course, I'll need the IRQF_SHARED_TIMER_OK patch to prevent the > WARN_ON backtrace. That should be fine; it's backed up in the list archive ;) > Please, let me know if I missed anything important, share your opinion > on this proposal, and feel free to propose any other solution. Hopefully the above covers that! Mark. -- 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: [PATCHv2 13/15] ARM: mvebu: add core support for Armada 39x
Hi Thomas,
On 20/02/2015 18:04, Thomas Petazzoni wrote:
> This commit adds the core support for Armada 39x, which is quite
> simple:
>
> - a new Kconfig option which selects the appropriate clock and
>pinctrl drivers as well as other common features (GIC, L2 cache,
>SMP, etc.)
>
> - a new DT_MACHINE_START which references the top-level compatible
>strings supported for the Marvell Armada 39x.
>
> - a new SMP enable-method. The mechanism to enable CPUs for Armada
>39x appears to be the same as Armada 38x. However, we do not want
>to use marvell,armada-380-smp in the Device Tree, in the case of
>the discovery of a subtle difference in the future, which would
>require changing the Device Tree. And the enable-method isn't a
>compatible string: you can't specify several values and expect a
>fallback on the second string if the first one isn't
>supported. Therefore, we simply declare the SMP enable method
>"marvell,armada-390-smp" as doing the same thing as the
>"marvell,armada-380-smp" one.
>
> Signed-off-by: Thomas Petazzoni
> ---
> arch/arm/mach-mvebu/Kconfig | 14 ++
> arch/arm/mach-mvebu/board-v7.c | 14 ++
> arch/arm/mach-mvebu/platsmp-a9.c | 2 ++
> 3 files changed, 30 insertions(+)
>
> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> index c1e4567..9747316 100644
> --- a/arch/arm/mach-mvebu/Kconfig
> +++ b/arch/arm/mach-mvebu/Kconfig
> @@ -64,6 +64,20 @@ config MACH_ARMADA_38X
> Say 'Y' here if you want your kernel to support boards based
> on the Marvell Armada 380/385 SoC with device tree.
>
> +config MACH_ARMADA_39X
> + bool "Marvell Armada 39x boards" if ARCH_MULTI_V7
As you don't select it by default we should update the mvebu_v7_defconfig
with this symbol.
Thanks,
Gregory
> + select ARM_GIC
> + select ARMADA_39X_CLK
> + select CACHE_L2X0
> + select HAVE_ARM_SCU
> + select HAVE_ARM_TWD if SMP
> + select HAVE_SMP
> + select MACH_MVEBU_V7
> + select PINCTRL_ARMADA_39X
> + help
> + Say 'Y' here if you want your kernel to support boards based
> + on the Marvell Armada 39x SoC with device tree.
> +
> config MACH_ARMADA_XP
> bool "Marvell Armada XP boards" if ARCH_MULTI_V7
> select ARMADA_XP_CLK
> diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
> index 31b66f2..afee908 100644
> --- a/arch/arm/mach-mvebu/board-v7.c
> +++ b/arch/arm/mach-mvebu/board-v7.c
> @@ -232,3 +232,17 @@ DT_MACHINE_START(ARMADA_38X_DT, "Marvell Armada 380/385
> (Device Tree)")
> .restart= mvebu_restart,
> .dt_compat = armada_38x_dt_compat,
> MACHINE_END
> +
> +static const char * const armada_39x_dt_compat[] __initconst = {
> + "marvell,armada390",
> + "marvell,armada398",
> + NULL,
> +};
> +
> +DT_MACHINE_START(ARMADA_39X_DT, "Marvell Armada 39x (Device Tree)")
> + .l2c_aux_val= 0,
> + .l2c_aux_mask = ~0,
> + .init_irq = mvebu_init_irq,
> + .restart= mvebu_restart,
> + .dt_compat = armada_39x_dt_compat,
> +MACHINE_END
> diff --git a/arch/arm/mach-mvebu/platsmp-a9.c
> b/arch/arm/mach-mvebu/platsmp-a9.c
> index 2ec1a42..df0a9cc 100644
> --- a/arch/arm/mach-mvebu/platsmp-a9.c
> +++ b/arch/arm/mach-mvebu/platsmp-a9.c
> @@ -110,3 +110,5 @@ CPU_METHOD_OF_DECLARE(mvebu_armada_375_smp,
> "marvell,armada-375-smp",
> &mvebu_cortex_a9_smp_ops);
> CPU_METHOD_OF_DECLARE(mvebu_armada_380_smp, "marvell,armada-380-smp",
> &armada_38x_smp_ops);
> +CPU_METHOD_OF_DECLARE(mvebu_armada_390_smp, "marvell,armada-390-smp",
> + &armada_38x_smp_ops);
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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: [PATCHv2 10/15] clk: mvebu: extend common code to allow an optional refclk
Hi Mike,
On 20/02/2015 19:21, Mike Turquette wrote:
> Quoting Thomas Petazzoni (2015-02-20 09:04:29)
>> The Armada 39x, contrary to its predecessor, has a configurable
>> reference clock frequency, of either 25 Mhz, or 40 Mhz. For the
>> previous SoCs, it was fixed to 25 Mhz and described directly as such
>> in the Device Tree.
>>
>> For Armada 39x, we need to read certain registers to know whether the
>> frequency is 25 or 40 Mhz. Therefore, this commit extends the common
>> mvebu clock code to allow the SoC-specific code to say it wants to
>> register a reference clock, by giving a non-NULL ->get_refclk_freq()
>> function pointer in its coreclk_soc_desc structure.
>>
>> Signed-off-by: Thomas Petazzoni
>
> Looks fine to me. I'll apply after -rc1 drops.
What about the other clock related patch: "clk: mvebu: add Marvell
Armada 39x driver" ? Will you apply it too, or do you expect a pull request
for the mvebu related clocks ?
Thanks,
Gregory
>
> Regards,
> Mike
>
>> ---
>> drivers/clk/mvebu/common.c | 17 +
>> drivers/clk/mvebu/common.h | 1 +
>> 2 files changed, 18 insertions(+)
>>
>> diff --git a/drivers/clk/mvebu/common.c b/drivers/clk/mvebu/common.c
>> index 0d4d121..15b370f 100644
>> --- a/drivers/clk/mvebu/common.c
>> +++ b/drivers/clk/mvebu/common.c
>> @@ -121,6 +121,11 @@ void __init mvebu_coreclk_setup(struct device_node *np,
>>
>> /* Allocate struct for TCLK, cpu clk, and core ratio clocks */
>> clk_data.clk_num = 2 + desc->num_ratios;
>> +
>> + /* One more clock for the optional refclk */
>> + if (desc->get_refclk_freq)
>> + clk_data.clk_num += 1;
>> +
>> clk_data.clks = kzalloc(clk_data.clk_num * sizeof(struct clk *),
>> GFP_KERNEL);
>> if (WARN_ON(!clk_data.clks)) {
>> @@ -162,6 +167,18 @@ void __init mvebu_coreclk_setup(struct device_node *np,
>> WARN_ON(IS_ERR(clk_data.clks[2+n]));
>> };
>>
>> + /* Register optional refclk */
>> + if (desc->get_refclk_freq) {
>> + const char *name = "refclk";
>> + of_property_read_string_index(np, "clock-output-names",
>> + 2 + desc->num_ratios, &name);
>> + rate = desc->get_refclk_freq(base);
>> + clk_data.clks[2 + desc->num_ratios] =
>> + clk_register_fixed_rate(NULL, name, NULL,
>> + CLK_IS_ROOT, rate);
>> + WARN_ON(IS_ERR(clk_data.clks[2 + desc->num_ratios]));
>> + }
>> +
>> /* SAR register isn't needed anymore */
>> iounmap(base);
>>
>> diff --git a/drivers/clk/mvebu/common.h b/drivers/clk/mvebu/common.h
>> index 783b563..f0de6c8 100644
>> --- a/drivers/clk/mvebu/common.h
>> +++ b/drivers/clk/mvebu/common.h
>> @@ -30,6 +30,7 @@ struct coreclk_soc_desc {
>> u32 (*get_tclk_freq)(void __iomem *sar);
>> u32 (*get_cpu_freq)(void __iomem *sar);
>> void (*get_clk_ratio)(void __iomem *sar, int id, int *mult, int
>> *div);
>> + u32 (*get_refclk_freq)(void __iomem *sar);
>> bool (*is_sscg_enabled)(void __iomem *sar);
>> u32 (*fix_sscg_deviation)(u32 system_clk);
>> const struct coreclk_ratio *ratios;
>> --
>> 2.1.0
>>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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] Input: bcm-keypad: add device tree bindings
Hi Scott, On Sun, Feb 15, 2015 at 09:17:51PM -0800, Dmitry Torokhov wrote: > On Sat, Feb 14, 2015 at 08:49:15AM -0800, Scott Branden wrote: > > On 15-02-09 04:51 PM, Dmitry Torokhov wrote: > > >On Mon, Feb 09, 2015 at 04:07:40PM -0800, Scott Branden wrote: > > >>+ > > >>+- col-debounce-filter-period: The debounce period for the Column filter. > > >>+ > > >>+ KEYPAD_DEBOUNCE_1_ms= 0 > > >>+ KEYPAD_DEBOUNCE_2_ms= 1 > > >>+ KEYPAD_DEBOUNCE_4_ms= 2 > > >>+ KEYPAD_DEBOUNCE_8_ms= 3 > > > > > >>+ KEYPAD_DEBOUNCE_16_ms = 4 > > >>+ KEYPAD_DEBOUNCE_32_ms = 5 > > >>+ KEYPAD_DEBOUNCE_64_ms = 6 > > >>+ KEYPAD_DEBOUNCE_128_ms = 7 > > >>+ > > >>+- status-debounce-filter-period: The debounce period for the Status > > >>filter. > > >>+ > > >>+ KEYPAD_DEBOUNCE_1_ms= 0 > > >>+ KEYPAD_DEBOUNCE_2_ms= 1 > > >>+ KEYPAD_DEBOUNCE_4_ms= 2 > > >>+ KEYPAD_DEBOUNCE_8_ms= 3 > > >>+ KEYPAD_DEBOUNCE_16_ms = 4 > > >>+ KEYPAD_DEBOUNCE_32_ms = 5 > > >>+ KEYPAD_DEBOUNCE_64_ms = 6 > > >>+ KEYPAD_DEBOUNCE_128_ms = 7 > > > > > >I could swear device-specific properties should be in form of > > >, to ensure it won't clash with changes on > > >subsystem level later on. Device-tree folks, what say you? > > I see examples with and without vendor-prefix. > > qcom,pm8xxx-keypad.txt does not have prefixes > > st-keyscan.txt does have a prefix > > > > I can't find any documented guidelines for this. > > As I mentioned I'll try to get clarification on this. I have chatted with a couple of people on this and it is acceptable to omit vendor prefix in bindings when we are using a specific driver like we have here (i.e. when driver's compatible string already includes vendor prefix). Vendor prefixes on properties are required when we augment a generic driver's binding. So the above 2 entries are fine as is. Thanks. -- Dmitry -- 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 v9 4/5] ARM: dts: imx6sl: Add power-domain information to gpc node
The PGC that is part of GPC controls isolation and power sequencing of the
power domains. The PU power domain will be handled by the generic pm domain
framework. It needs a phandle to the PU regulator to turn off power when
the domain is disabled and a list of clocks to be enabled during powerup
for reset propagation.
Signed-off-by: Philipp Zabel
---
arch/arm/boot/dts/imx6sl.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 36ab8e0..79d2007 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -604,6 +604,10 @@
compatible = "fsl,imx6sl-gpc", "fsl,imx6q-gpc";
reg = <0x020dc000 0x4000>;
interrupts = <0 89 IRQ_TYPE_LEVEL_HIGH>;
+ pu-supply = <®_pu>;
+ clocks = <&clks IMX6SL_CLK_GPU2D_OVG>,
+<&clks IMX6SL_CLK_GPU2D_PODF>;
+ #power-domain-cells = <1>;
};
gpr: iomuxc-gpr@020e {
--
2.1.4
--
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 v9 1/5] Documentation: Add device tree bindings for Freescale i.MX GPC
The i.MX6 contains a power controller that controls power gating and
sequencing for the SoC's power domains.
Signed-off-by: Philipp Zabel
---
Changes since v8:
- Updated example with IRQ_TYPE_... and IMX6QDL_CLK_... defines
---
.../devicetree/bindings/power/fsl,imx-gpc.txt | 59 ++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
new file mode 100644
index 000..65cc034
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/fsl,imx-gpc.txt
@@ -0,0 +1,59 @@
+Freescale i.MX General Power Controller
+===
+
+The i.MX6Q General Power Control (GPC) block contains DVFS load tracking
+counters and Power Gating Control (PGC) for the CPU and PU (GPU/VPU) power
+domains.
+
+Required properties:
+- compatible: Should be "fsl,imx6q-gpc" or "fsl,imx6sl-gpc"
+- reg: should be register base and length as documented in the
+ datasheet
+- interrupts: Should contain GPC interrupt request 1
+- pu-supply: Link to the LDO regulator powering the PU power domain
+- clocks: Clock phandles to devices in the PU power domain that need
+ to be enabled during domain power-up for reset propagation.
+- #power-domain-cells: Should be 1, see below:
+
+The gpc node is a power-controller as documented by the generic power domain
+bindings in Documentation/devicetree/bindings/power/power_domain.txt.
+
+Example:
+
+ gpc: gpc@020dc000 {
+ compatible = "fsl,imx6q-gpc";
+ reg = <0x020dc000 0x4000>;
+ interrupts = <0 89 IRQ_TYPE_LEVEL_HIGH>,
+<0 90 IRQ_TYPE_LEVEL_HIGH>;
+ pu-supply = <®_pu>;
+ clocks = <&clks IMX6QDL_CLK_GPU3D_CORE>,
+<&clks IMX6QDL_CLK_GPU3D_SHADER>,
+<&clks IMX6QDL_CLK_GPU2D_CORE>,
+<&clks IMX6QDL_CLK_GPU2D_AXI>,
+<&clks IMX6QDL_CLK_OPENVG_AXI>,
+<&clks IMX6QDL_CLK_VPU_AXI>;
+ #power-domain-cells = <1>;
+ };
+
+
+Specifying power domain for IP modules
+==
+
+IP cores belonging to a power domain should contain a 'power-domains' property
+that is a phandle pointing to the gpc device node and a DOMAIN_INDEX specifying
+the power domain the device belongs to.
+
+Example of a device that is part of the PU power domain:
+
+ vpu: vpu@0204 {
+ reg = <0x0204 0x3c000>;
+ /* ... */
+ power-domains = <&gpc 1>;
+ /* ... */
+ };
+
+The following DOMAIN_INDEX values are valid for i.MX6Q:
+ARM_DOMAIN 0
+PU_DOMAIN 1
+The following additional DOMAIN_INDEX value is valid for i.MX6SL:
+DISPLAY_DOMAIN 2
--
2.1.4
--
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 v9 3/5] ARM: dts: imx6qdl: Add power-domain information to gpc node
The PGC that is part of GPC controls isolation and power sequencing of the
power domains. The PU power domain will be handled by the generic pm domain
framework. It needs a phandle to the PU regulator to turn off power when
the domain is disabled, and a list of phandles to all clocks that must be
enabled during powerup for reset propagation.
Signed-off-by: Philipp Zabel
---
arch/arm/boot/dts/imx6qdl.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index d6c69ec..7ab00a4 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -695,6 +695,14 @@
reg = <0x020dc000 0x4000>;
interrupts = <0 89 IRQ_TYPE_LEVEL_HIGH>,
<0 90 IRQ_TYPE_LEVEL_HIGH>;
+ pu-supply = <®_pu>;
+ clocks = <&clks IMX6QDL_CLK_GPU3D_CORE>,
+<&clks IMX6QDL_CLK_GPU3D_SHADER>,
+<&clks IMX6QDL_CLK_GPU2D_CORE>,
+<&clks IMX6QDL_CLK_GPU2D_AXI>,
+<&clks IMX6QDL_CLK_OPENVG_AXI>,
+<&clks IMX6QDL_CLK_VPU_AXI>;
+ #power-domain-cells = <1>;
};
gpr: iomuxc-gpr@020e {
--
2.1.4
--
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 v9 5/5] ARM: dts: imx6qdl: Allow disabling the PU regulator, add a enable ramp delay
The PU regulator is enabled during boot, but not necessarily always-on. It can be disabled by the generic pm domain framework when the PU power domain is shut down. The ramp delay of 150 us might be a bit conservative, the value is taken from the Freescale kernel. Signed-off-by: Philipp Zabel --- Changes since v8: - Removed regulator-boot-on, this depends on the bootloader --- arch/arm/boot/dts/imx6qdl.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi index 7ab00a4..4b12ac0 100644 --- a/arch/arm/boot/dts/imx6qdl.dtsi +++ b/arch/arm/boot/dts/imx6qdl.dtsi @@ -598,7 +598,7 @@ regulator-name = "vddpu"; regulator-min-microvolt = <725000>; regulator-max-microvolt = <145>; - regulator-always-on; + regulator-enable-ramp-delay = <150>; anatop-reg-offset = <0x140>; anatop-vol-bit-shift = <9>; anatop-vol-bit-width = <5>; -- 2.1.4 -- 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 v9 0/5] i.MX6 PU power domain support
this is a rebased and updated version of the series I sent previously: http://www.spinics.net/lists/arm-kernel/msg360709.html Changes since v8: - Updated DT documentation example with IRQ_TYPE_... and IMX6QDL_CLK_... defines - Made PU regulator optional to support i.MX6SX, suggested by Robin Gong - Removed regulator_enable() call in the probe function, stopped disabling the regulator in imx6q_pm_pu_power_off() - the regulator framework will disable unused regulators. - Changed the GPC driver to enable pu power if CONFIG_PM is not enabled, as some bootloaders disable pu power on boot. regards Philipp Philipp Zabel (6): Documentation: Add device tree bindings for Freescale i.MX GPC ARM: imx6: gpc: Add PU power domain for GPU/VPU ARM: dts: imx6qdl: Add power-domain information to gpc node ARM: dts: imx6sl: Add power-domain information to gpc node ARM: dts: imx6qdl: Allow disabling the PU regulator, add a enable ramp delay ARM: imx6: gpc: Allow PU regulator bypass .../devicetree/bindings/power/fsl,imx-gpc.txt | 59 ++ arch/arm/boot/dts/imx6qdl.dtsi | 10 +- arch/arm/boot/dts/imx6sl.dtsi | 4 + arch/arm/mach-imx/Kconfig | 1 + arch/arm/mach-imx/gpc.c| 216 + 5 files changed, 289 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpc.txt -- 2.1.4 -- 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 v9 2/5] ARM: imx6: gpc: Add PU power domain for GPU/VPU
When generic pm domain support is enabled, the PGC can be used
to completely gate power to the PU power domain containing GPU3D,
GPU2D, and VPU cores.
This code triggers the PGC powerdown sequence to disable the GPU/VPU
isolation cells and gate power and then disables the PU regulator.
To reenable, the reverse powerup sequence is triggered after the PU
regulator is enabled again.
The GPU and VPU devices in the PU power domain temporarily need
to be clocked during powerup, so that the reset machinery can work.
[Avoid explicit regulator enabling in probe, unless !PM]
Signed-off-by: Markus Pargmann
Signed-off-by: Philipp Zabel
---
Changes since v8:
- Made PU regulator optional to support i.MX6SX, suggested by
Robin Gong
- Removed regulator_enable() call in the probe function, stopped
disabling the regulator in imx6q_pm_pu_power_off() - the regulator
framework will disable unused regulators.
- Enable pu power if CONFIG_PM is not enabled, as some bootloaders
disable pu power on boot, causing it to stay always disabled.
---
arch/arm/mach-imx/Kconfig | 1 +
arch/arm/mach-imx/gpc.c | 213 ++
2 files changed, 214 insertions(+)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index e8627e0..d988d41 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -50,6 +50,7 @@ config HAVE_IMX_ANATOP
config HAVE_IMX_GPC
bool
+ select PM_GENERIC_DOMAINS if PM
config HAVE_IMX_MMDC
bool
diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index 745caa1..029f59c 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -10,15 +10,25 @@
* http://www.gnu.org/copyleft/gpl.html
*/
+#include
+#include
#include
#include
#include
#include
#include
+#include
+#include
+#include
#include
#include "common.h"
+#include "hardware.h"
+#define GPC_CNTR 0x000
#define GPC_IMR1 0x008
+#define GPC_PGC_GPU_PDN0x260
+#define GPC_PGC_GPU_PUPSCR 0x264
+#define GPC_PGC_GPU_PDNSCR 0x268
#define GPC_PGC_CPU_PDN0x2a0
#define GPC_PGC_CPU_PUPSCR 0x2a4
#define GPC_PGC_CPU_PDNSCR 0x2a8
@@ -27,6 +37,18 @@
#define IMR_NUM4
+#define GPU_VPU_PUP_REQBIT(1)
+#define GPU_VPU_PDN_REQBIT(0)
+
+#define GPC_CLK_MAX6
+
+struct pu_domain {
+ struct generic_pm_domain base;
+ struct regulator *reg;
+ struct clk *clk[GPC_CLK_MAX];
+ int num_clks;
+};
+
static void __iomem *gpc_base;
static u32 gpc_wake_irqs[IMR_NUM];
static u32 gpc_saved_imrs[IMR_NUM];
@@ -170,3 +192,194 @@ void __init imx_gpc_init(void)
gic_arch_extn.irq_unmask = imx_gpc_irq_unmask;
gic_arch_extn.irq_set_wake = imx_gpc_irq_set_wake;
}
+
+#ifdef CONFIG_PM_GENERIC_DOMAINS
+
+static void _imx6q_pm_pu_power_off(struct generic_pm_domain *genpd)
+{
+ int iso, iso2sw;
+ u32 val;
+
+ /* Read ISO and ISO2SW power down delays */
+ val = readl_relaxed(gpc_base + GPC_PGC_GPU_PDNSCR);
+ iso = val & 0x3f;
+ iso2sw = (val >> 8) & 0x3f;
+
+ /* Gate off PU domain when GPU/VPU when powered down */
+ writel_relaxed(0x1, gpc_base + GPC_PGC_GPU_PDN);
+
+ /* Request GPC to power down GPU/VPU */
+ val = readl_relaxed(gpc_base + GPC_CNTR);
+ val |= GPU_VPU_PDN_REQ;
+ writel_relaxed(val, gpc_base + GPC_CNTR);
+
+ /* Wait ISO + ISO2SW IPG clock cycles */
+ ndelay((iso + iso2sw) * 1000 / 66);
+}
+
+static int imx6q_pm_pu_power_off(struct generic_pm_domain *genpd)
+{
+ struct pu_domain *pu = container_of(genpd, struct pu_domain, base);
+
+ _imx6q_pm_pu_power_off(genpd);
+
+ if (pu->reg)
+ regulator_disable(pu->reg);
+
+ return 0;
+}
+
+static int imx6q_pm_pu_power_on(struct generic_pm_domain *genpd)
+{
+ struct pu_domain *pu = container_of(genpd, struct pu_domain, base);
+ int i, ret, sw, sw2iso;
+ u32 val;
+
+ if (pu->reg)
+ ret = regulator_enable(pu->reg);
+ if (pu->reg && ret) {
+ pr_err("%s: failed to enable regulator: %d\n", __func__, ret);
+ return ret;
+ }
+
+ /* Enable reset clocks for all devices in the PU domain */
+ for (i = 0; i < pu->num_clks; i++)
+ clk_prepare_enable(pu->clk[i]);
+
+ /* Gate off PU domain when GPU/VPU when powered down */
+ writel_relaxed(0x1, gpc_base + GPC_PGC_GPU_PDN);
+
+ /* Read ISO and ISO2SW power down delays */
+ val = readl_relaxed(gpc_base + GPC_PGC_GPU_PUPSCR);
+ sw = val & 0x3f;
+ sw2iso = (val >> 8) & 0x3f;
+
+ /* Request GPC to power up GPU/VPU */
+ val = readl_relaxed(gpc_base + GPC_CNTR);
+ val |= GPU_VPU_PUP_REQ;
+ writel_relaxed(val, gpc_base + GPC_CNTR);
+
+ /* Wait ISO + ISO2SW IPG clock cycles */
+ ndelay((sw + sw2iso)
Re: [PATCH v4 4/5] Input: add haptic drvier on max77843
Hi Jaew9on,
On Mon, Feb 23, 2015 at 05:09:50PM +0900, Jaewon Kim wrote:
> This patch adds support for haptic driver on max77843
> MFD(Multi Function Device) with PMIC, MUIC, LED, CHARGER.
>
> This driver supports external pwm and LRA(Linear Resonant Actuator) motor.
> And it supports ff-memless interface from inpu framework.
>
> Cc: Dmitry Torokhov
> Signed-off-by: Jaewon Kim
...
> +static void max77843_haptic_play_work(struct work_struct *work)
> +{
> + struct max77843_haptic *haptic =
> + container_of(work, struct max77843_haptic, work);
> + int error;
> +
> + mutex_lock(&haptic->mutex);
> +
> + if (haptic->suspended)
> + mutex_unlock(&haptic->mutex);
Huh?
> +
> + error = max77843_haptic_set_duty_cycle(haptic);
> + if (error) {
> + dev_err(haptic->dev, "failed to set duty cycle: %d\n", error);
> + return;
Here you are leaving with the mutex held.
> + }
> +
> + if (haptic->magnitude) {
> + error = max77843_haptic_enable(haptic);
> + if (error)
> + dev_err(haptic->dev,
> + "cannot enable haptic: %d\n", error);
> + } else {
> + max77843_haptic_disable(haptic);
> + if (error)
> + dev_err(haptic->dev,
> + "cannot disable haptic: %d\n", error);
> + }
> +
> + mutex_unlock(&haptic->mutex);
> +}
> +
The rest seems quite reasonable.
Thanks.
--
Dmitry
--
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] clk: Provide an always-on clock domain framework
Quoting Lee Jones (2015-02-18 08:15:00)
> Much h/w contain clocks which if turned off would prove fatal. The
> only way to recover is to restart the board(s). This driver takes
> references to clocks which are required to be always-on in order to
> prevent the common clk framework from trying to turn them off during
> the clk_disabled_unused() procedure.
>
> Signed-off-by: Lee Jones
> ---
> drivers/clk/Makefile| 1 +
> drivers/clk/clkdomain.c | 63
> +
> 2 files changed, 64 insertions(+)
> create mode 100644 drivers/clk/clkdomain.c
>
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index d5fba5b..d9e2718 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -3,6 +3,7 @@ obj-$(CONFIG_HAVE_CLK) += clk-devres.o
> obj-$(CONFIG_CLKDEV_LOOKUP)+= clkdev.o
> obj-$(CONFIG_COMMON_CLK) += clk.o
> obj-$(CONFIG_COMMON_CLK) += clk-divider.o
> +obj-$(CONFIG_COMMON_CLK) += clkdomain.o
> obj-$(CONFIG_COMMON_CLK) += clk-fixed-factor.o
> obj-$(CONFIG_COMMON_CLK) += clk-fixed-rate.o
> obj-$(CONFIG_COMMON_CLK) += clk-gate.o
> diff --git a/drivers/clk/clkdomain.c b/drivers/clk/clkdomain.c
> new file mode 100644
> index 000..8c83f99
> --- /dev/null
> +++ b/drivers/clk/clkdomain.c
Naming is hard. I'm not sure clkdomain.c is the best expression. Maybe
clk-alwon.c? I see ALWON used alot amongst hardware people who live in a
world of eight-character naming limitations.
> @@ -0,0 +1,63 @@
> +/*
> + * ST Clock Domain
> + *
> + * Copyright (C) 2015 STMicroelectronics – All Rights Reserved
> + *
> + * Author: Lee Jones
> + *
> + * 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; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include
If this header still existed I would berate you mercilessly. Luckily for
you it no longer exists and only causes a compile error ;-)
> +#include
> +#include
> +#include
> +#include
> +
> +static void ao_clock_domain_hog_clock(struct platform_device *pdev, int
> index)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct clk *clk;
> + int ret;
> +
> + clk = of_clk_get(np, index);
> + if (IS_ERR(clk)) {
> + dev_warn(&pdev->dev, "Failed get clock %s[%d]: %li\n",
> +np->full_name, index, PTR_ERR(clk));
> + return;
> + }
> +
> + ret = clk_prepare_enable(clk);
> + if (ret)
> + dev_warn(&pdev->dev, "Failed to enable clock: %s\n",
> clk->name);
> +}
> +
> +static int ao_clock_domain_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + int nclks, i;
> +
> + nclks = of_count_phandle_with_args(np, "clocks", "#clock-cells");
Minor nitpick: please use of_clk_get_parent_count. I spent a solid 5
minutes writing that function and I need people to use it so I can get a
return on my investment.
Otherwise the patch looks good. I believe that this method is targeting
always-on clock in a production environment, which is different from the
CLK_IGNORE_UNUSED stuff which typically is helpful while bringing up new
hardware or dealing with a platform that has incomplete driver support.
I wonder if there is a clever way for existing clock providers
(expressed in DT) to use this without having to create a separate node
of clocks with the "always-on-clk-domain" flag. Possibly the common
clock binding could declare some always-on flag that is standardized?
Then the framework core could use this code easily. Not sure if that is
a good idea though...
Regards,
Mike
> +
> + for (i = 0; i < nclks; i++)
> + ao_clock_domain_hog_clock(pdev, i);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id ao_clock_domain_match[] = {
> + { .compatible = "always-on-clk-domain" },
> + { },
> +};
> +
> +static struct platform_driver ao_clock_domain_driver = {
> + .probe = ao_clock_domain_probe,
> + .driver = {
> + .name = "always-on-clk-domain",
> + .of_match_table = ao_clock_domain_match,
> + },
> +};
> +module_platform_driver(ao_clock_domain_driver);
> --
> 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: [PATCHv2 05/15] ARM: mvebu: add stdout-path to all armada-*.dts
On Fri, Feb 20, 2015 at 05:04:24PM +, Thomas Petazzoni wrote:
> This commit adds the stdout-path property in /chosen for all Armada
> boards that were not yet carrying this property.
>
> Signed-off-by: Thomas Petazzoni
> ---
> arch/arm/boot/dts/armada-370-db.dts | 1 +
> arch/arm/boot/dts/armada-370-mirabox.dts | 1 +
> arch/arm/boot/dts/armada-370-netgear-rn102.dts | 1 +
> arch/arm/boot/dts/armada-370-netgear-rn104.dts | 1 +
> arch/arm/boot/dts/armada-370-rd.dts | 1 +
> arch/arm/boot/dts/armada-375-db.dts | 1 +
> arch/arm/boot/dts/armada-388-db.dts | 1 +
> arch/arm/boot/dts/armada-388-rd.dts | 1 +
> arch/arm/boot/dts/armada-xp-axpwifiap.dts| 1 +
> arch/arm/boot/dts/armada-xp-db.dts | 1 +
> arch/arm/boot/dts/armada-xp-gp.dts | 1 +
> arch/arm/boot/dts/armada-xp-matrix.dts | 1 +
> arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 1 +
> arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 1 +
> 14 files changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/armada-370-db.dts
> b/arch/arm/boot/dts/armada-370-db.dts
> index e993c46..286bedd 100644
> --- a/arch/arm/boot/dts/armada-370-db.dts
> +++ b/arch/arm/boot/dts/armada-370-db.dts
> @@ -56,6 +56,7 @@
>
> chosen {
> bootargs = "console=ttyS0,115200 earlyprintk";
> + stdout-path = &uart0;
stdout-path can now take a config too (including the rate), which will
avoid any reliance on the serial core choosing the right rate by
default.
If you have an alias serial0, this could be:
stdout-path = "serial0:115200n8";
Otherwise you can use the full path instead of serial0.
That's documented in Documentation/devicetree/bindings/chosen.txt
Mark.
--
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 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip
Hi Mark, Thanks for the clarification, and sorry if I've been a bit harsh to you in my previous answer, but this whole shared irq thing is starting to drive me crazy. On Fri, 20 Feb 2015 15:16:56 + Mark Rutland wrote: [...] > > An IRQ cannot be shared between a device with IRQF_NO_SUSPEND and a > device that wishes to operate as a wakeup device, because the semantics > don't align. One wishes to handle IRQs continuously and one wants to > abort suspend at the first IRQ (waiting until part-way through the > resume before handling it). > > So those devices above which wish to operate as wakeup devices are > either irrelevant or unsalvageable with the current approaches. > > The flag or demux chip only happens to mask the problem in the absence > of strict sanity checking. > > If you want to be able to share the line then you will need to > fundamentally rework the way wakeup interrupts work in order to be able > to decide when you've encountered a real wakeup event. Okay, I'll try to summarize the discussion we had on IRC regarding this aspect. On at91 platforms, irq line 1 is shared by a timer (PIT) and some devices that can register themselves as wakeup sources (especially the RTC IP). I doubt at91 users will agree on dropping either of these features (the timer or the wakeup on RTC/UART/...), so, can we try to find a solution that would both make irq, DT and at91 guys happy (that doesn't sound like an easy task :-)) ? The whole problem here is that we can't have both IRQF_NO_SUSPEND flag set on one of the shared action and others that are configuring the irq as a wakeup source, because it would always lead to the system being woken up (even when the only thing we were supposed to do is handle the timer event). This is because irq_may_run [1], which is called to decide whether we should handle this irq or just wake the system up [2], will always return true if at least one of the shared action has tagged the irq line as a wakeup source. Sorry for summarizing things you most likely already know, but I want to be sure I'm actually understanding it correctly. Now, let's look at how this could be solved. Here is a proposal [3] that does the following: 1/ prevent a system wakeup when at least one of the action handler has set the IRQF_NO_SUSPEND flag 2/ Add a few helpers to deal with system wakeup from drivers code 3/ Rework the at91 RTC driver to show how such weird cases could be handled Of course, I'll need the IRQF_SHARED_TIMER_OK patch to prevent the WARN_ON backtrace. Please, let me know if I missed anything important, share your opinion on this proposal, and feel free to propose any other solution. [1]http://lxr.free-electrons.com/source/kernel/irq/chip.c#L348 [2]http://lxr.free-electrons.com/source/kernel/irq/chip.c#L386 [3]http://code.bulix.org/gboee1-87936 -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- 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 7/8] hwmon: pwm-fan: Read PWM FAN configuration from device tree
On Mon, Feb 23, 2015 at 05:51:22PM +0100, Lukasz Majewski wrote:
> Hi Guenter,
>
> > On Mon, Feb 23, 2015 at 05:13:36PM +0100, Lukasz Majewski wrote:
> > > Hi Guenter,
> > >
> > [ ... ]
> >
> > > >
> > > > If devicetree is not configured, of_property_count_elems_of_size
> > > > returns -ENOSYS, which is returned, causing the driver to fail
> > > > loading.
> > >
> > > Has of_property_count_elems_of_size() returns -ENOSYS?
> > >
> > > Maybe something has changed, but in my linux-vanila (3.19-rc4)
> > > at ./drivers/of/base.c it returns -EINVAL, -ENODATA or number of
> > > elements.
> > >
> > > Have I missed something?
> > >
> > Hi Lukasz,
> >
> > Yes, you have. Check include/linux/of.h, line 484, in latest mainline.
>
> Ok. Now I got it.
>
> The above situation shouldn't happen if I put of_find_property() check
> on the very beginning of this function (it returns NULL when DT support
> is not compiled).
>
Correct.
> The function would look as follows:
>
> int
> pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx
> *ctx)
> {
> struct device_node *np = dev->of_node;
> int num, i, ret;
>
> if (!of_find_property(np, "cooling-levels", NULL))
> return 0;
>
> ret = of_property_count_u32_elems(np, "cooling-levels");
> if (ret <= 0) {
> dev_err(dev, "Wrong data!\n");
> return ret;
This should probably be something like
return ret ? : -EINVAL;
or ret == 0 is not an error, and you should not display an error message
in that case.
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: [PATCHv2 05/15] ARM: mvebu: add stdout-path to all armada-*.dts
Dear Rob Herring, On Mon, 23 Feb 2015 10:50:26 -0600, Rob Herring wrote: > Not exactly, stdout-path allows for removing "console" from the > command line. earlyprintk is a debug/developer option, so it should > not be in a default command line IMO. > > So bootargs should be removed entirely. Ok, will be in v3, rebased on top of 4.0-rc1. I also noticed another issue in the patch series: missing Armada 375 UART aliases. I'll fix that up as well when sending v3. Thanks for the feedback! Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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 7/8] hwmon: pwm-fan: Read PWM FAN configuration from device tree
Hi Guenter,
> On Mon, Feb 23, 2015 at 05:13:36PM +0100, Lukasz Majewski wrote:
> > Hi Guenter,
> >
> [ ... ]
>
> > >
> > > If devicetree is not configured, of_property_count_elems_of_size
> > > returns -ENOSYS, which is returned, causing the driver to fail
> > > loading.
> >
> > Has of_property_count_elems_of_size() returns -ENOSYS?
> >
> > Maybe something has changed, but in my linux-vanila (3.19-rc4)
> > at ./drivers/of/base.c it returns -EINVAL, -ENODATA or number of
> > elements.
> >
> > Have I missed something?
> >
> Hi Lukasz,
>
> Yes, you have. Check include/linux/of.h, line 484, in latest mainline.
Ok. Now I got it.
The above situation shouldn't happen if I put of_find_property() check
on the very beginning of this function (it returns NULL when DT support
is not compiled).
The function would look as follows:
int
pwm_fan_of_get_cooling_data(struct device *dev, struct pwm_fan_ctx
*ctx)
{
struct device_node *np = dev->of_node;
int num, i, ret;
if (!of_find_property(np, "cooling-levels", NULL))
return 0;
ret = of_property_count_u32_elems(np, "cooling-levels");
if (ret <= 0) {
dev_err(dev, "Wrong data!\n");
return ret;
}
num = ret;
ctx->pwm_fan_cooling_levels = devm_kzalloc(dev, num *
sizeof(u32), GFP_KERNEL);
if (!ctx->pwm_fan_cooling_levels)
return -ENOMEM;
ret = of_property_read_u32_array(np, "cooling-levels",
ctx->pwm_fan_cooling_levels,
num);
if (ret) {
dev_err(dev, "Property 'cooling-levels' cannot be
read!\n");
return ret;
}
for (i = 0; i < num; i++) {
if (ctx->pwm_fan_cooling_levels[i] > MAX_PWM) {
dev_err(dev, "PWM fan state[%d]:%d > %d\n", i,
ctx->pwm_fan_cooling_levels[i],
MAX_PWM);
return -EINVAL;
}
}
ctx->pwm_fan_max_state = num - 1;
return 0;
}
>
> Guenter
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
--
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] of: add helper for getting endpoint node of specific identifiers
On Sun, Feb 22, 2015 at 7:41 PM, Hyungwon Hwang wrote:
> When there are multiple ports or multiple endpoints in a port, they have to be
> distinguished by the value of reg property. It is common. The drivers can get
> the specific endpoint in the specific port via this function. Now the drivers
> have to implement this code in themselves or have to force the order of dt
> nodes
> to get the right node.
>
> Signed-off-by: Hyungwon Hwang
Acked-by: Rob Herring
I'm not applying as there is no user, so apply this patch along with a
user of the function.
Rob
> ---
> Changes for v2:
> - Add the empty verion of the new function
> - Remove the unnecessary type casting from signed int to unsigned int
> drivers/of/base.c| 33 +
> include/linux/of_graph.h | 8
> 2 files changed, 41 insertions(+)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index 0a8aeb8..8f6bc41 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -2156,6 +2156,39 @@ struct device_node *of_graph_get_next_endpoint(const
> struct device_node *parent,
> EXPORT_SYMBOL(of_graph_get_next_endpoint);
>
> /**
> + * of_graph_get_endpoint_by_regs() - get endpoint node of specific
> identifiers
> + * @parent: pointer to the parent device node
> + * @port_reg: identifier (value of reg property) of the parent port node
> + * @reg: identifier (value of reg property) of the endpoint node
> + *
> + * Return: An 'endpoint' node pointer which is identified by reg and at the
> same
> + * is the child of a port node identified by port_reg. reg and port_reg are
> + * ignored when they are -1.
> + */
> +struct device_node *of_graph_get_endpoint_by_regs(
> + const struct device_node *parent, int port_reg, int reg)
> +{
> + struct of_endpoint endpoint;
> + struct device_node *node, *prev_node = NULL;
> +
> + while (1) {
> + node = of_graph_get_next_endpoint(parent, prev_node);
> + of_node_put(prev_node);
> + if (!node)
> + break;
> +
> + of_graph_parse_endpoint(node, &endpoint);
> + if (((port_reg == -1) || (endpoint.port == port_reg)) &&
> + ((reg == -1) || (endpoint.id == reg)))
> + return node;
> +
> + prev_node = node;
> + }
> +
> + return NULL;
> +}
> +
> +/**
> * of_graph_get_remote_port_parent() - get remote port's parent node
> * @node: pointer to a local endpoint device_node
> *
> diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
> index befef42..e859eb7 100644
> --- a/include/linux/of_graph.h
> +++ b/include/linux/of_graph.h
> @@ -31,6 +31,8 @@ int of_graph_parse_endpoint(const struct device_node *node,
> struct of_endpoint *endpoint);
> struct device_node *of_graph_get_next_endpoint(const struct device_node
> *parent,
> struct device_node *previous);
> +struct device_node *of_graph_get_endpoint_by_regs(
> + const struct device_node *parent, int port_reg, int reg);
> struct device_node *of_graph_get_remote_port_parent(
> const struct device_node *node);
> struct device_node *of_graph_get_remote_port(const struct device_node *node);
> @@ -49,6 +51,12 @@ static inline struct device_node
> *of_graph_get_next_endpoint(
> return NULL;
> }
>
> +struct device_node *of_graph_get_endpoint_by_regs(
> + const struct device_node *parent, int port_reg, int reg)
> +{
> + return NULL;
> +}
> +
> static inline struct device_node *of_graph_get_remote_port_parent(
> const struct device_node *node)
> {
> --
> 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 1/6] ASoC: max98088: Document DT bindings
Hello Sylwester, On 02/20/2015 01:12 PM, Sylwester Nawrocki wrote: > On 20/02/15 01:36, Andreas Färber wrote: >> So it seems the mclk is not always set up properly by the kernel, >> relying on firmware. Who's in charge of setting that clock up? >>> > >>> > Right, it seems audio is only working due the firmware doing some previous >>> > setup. Probably it works on every boot if you have "sound init" as a part >>> > of >>> > the u-boot boot commands? >> >> Indeed it does, 24 MHz without the reparenting patch, and sound working. > > You can have parent of the CLKOUT clock set by the clk core if it is > specified in device tree in the PMU (the clkout clock supplier) device > node. > > Similarly as we did for the Odroix U3: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/exynos4412-odroid-common.dtsi#n39 > > Relying on the clk_set_rate() to set the parent clock is not optimal > IMO. Presumably you need to set select stable parent clock for clkout > like XXTI. But I'm not very familiar with exyno5250 and that might be > something different. > Thanks a lot for your suggestion. I'll drop Tushar's patch to allow clkout to be reparent during set_rate then and change his DTS patch to set a default parent for CLKOUT using "assigned-clock-parents". Best regards, Javier -- 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: [PATCHv2 05/15] ARM: mvebu: add stdout-path to all armada-*.dts
On Mon, Feb 23, 2015 at 10:00 AM, Gregory CLEMENT wrote: > Hi Thomas, > > On 20/02/2015 18:04, Thomas Petazzoni wrote: >> This commit adds the stdout-path property in /chosen for all Armada >> boards that were not yet carrying this property. > > I though the main motivation for using the stdout-path property was > for removing the earlyprintk in the command line. Arnd told that there > should be a mean to use stdout-path instead of earlyprintk. > > So what about going further and removing "earlyprintk" in the same time? Not exactly, stdout-path allows for removing "console" from the command line. earlyprintk is a debug/developer option, so it should not be in a default command line IMO. So bootargs should be removed entirely. 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] arm64: dts: Fix GIC reg sizes for APM X-Gene
On Mon, Feb 23, 2015 at 6:07 AM, Christoffer Dall wrote: > On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote: >> On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall >> wrote: >> > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote: >> >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar >> >> wrote: >> >> > In APM X-Gene, GIC register space is 64K aligned while the sizes >> >> > mentioned >> >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 64K >> >> > page >> >> > size due to size alignment checking in vgic driver for VCPU Control and >> >> > VCPU register. >> >> > >> >> > This patch corrects the sizes to be inline with the hardware spec. >> >> >> >> This does not make sense. The GIC regions are still only 4 or 8KB and >> >> the h/w description should reflect that. For implementations using >> >> gic-400 and the addressing decode trick, the rest of the register >> >> range is also not safe to access given it is multiple mapped. Also, >> >> this wastes virtual space, but I guess we don't care on 64-bit. >> >> >> >> KVM should be fixed to only check base address alignment. Size >> >> alignment does not matter (if it does, then you need to fix all >> >> register blocks). >> >> >> > It matters if you want to ensure that the 64K page you are assigning to >> > a guest for the GIC virtual CPU interface contains only GIC virtual CPU >> > mappings, and not other random stuff that the guest is not allowed to >> > touch. >> >> Good point. >> >> > How else should this be enforced? >> >> Rely on correct h/w design? You'll have to repeat this every time you >> want to do pass-thru of a device. >> >> What do you do if 64K mapping is not supported? Fallback to emulation >> of the CPU interface? > > Agree with Peter on these two points. > >> >> Are there other DTSs that need to be fixed? >> > Not sure really, AMD Seattle works with 64K pages IIRC. Well, looks we have been inconsistent here: arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- reg = <0x0 0xe111 0 0x1000>, arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 0xe112f000 0 0x2000>, arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 0xe114 0 0x1>, arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0 0xe116 0 0x1>; arch/arm64/boot/dts/arm/juno.dts- reg = <0x0 0x2c01 0 0x1000>, arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c02f000 0 0x2000>, arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c04f000 0 0x2000>, arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c06f000 0 0x2000>; If we are going to use 64K sizes, can we have some consistency here please. Which ranges really need 64KB sizes? It should only be the VCPU interface. right? Why does XGene need 128K? If XGene is doing address swizzling, then the CPU and VCPU base addresses are wrong. Seattle is also wrong for the VCPU, but no one has noticed because we don't use the DIR register IIRC. XGene should also add an "arm,gic-400" compatible string or something XGene specific if in fact it is not GIC-400. I think perhaps we need a specific compatible property to indicate a GIC-400 with address swizzling. While we could get away with using the aliased addresses, that seems to be hard to get right and we may regret not doing it in the long term. It would indicate at least it is 64K page safe for example. 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 v2 2/2] input: Add support for ChipOne icn8318 based touchscreens
The ChipOne icn8318 is an i2c capacitive touchscreen controller typically
used in cheap android tablets, this commit adds a driver for it.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Fix spurious events after a close + open of the evdev node.
---
.../bindings/input/touchscreen/chipone_icn8318.txt | 46 +++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
MAINTAINERS| 7 +
drivers/input/touchscreen/Kconfig | 13 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/chipone_icn8318.c| 316 +
6 files changed, 384 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
create mode 100644 drivers/input/touchscreen/chipone_icn8318.c
diff --git
a/Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
b/Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
new file mode 100644
index 000..b405493
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
@@ -0,0 +1,46 @@
+* ChipOne icn8318 I2C touchscreen controller
+
+Required properties:
+ - compatible: "chipone,icn8318"
+ - reg : I2C slave address of the chip (0x40)
+ - interrupt-parent : a phandle pointing to the interrupt controller
+ serving the interrupt for this chip
+ - interrupts: interrupt specification for the icn8318 interrupt
+ - wake-gpios: GPIO specification for the WAKE input
+ - touchscreen-size-x: horizontal resolution of touchscreen (in pixels)
+ - touchscreen-size-y: vertical resolution of touchscreen (in pixels)
+
+Optional properties:
+ - pinctrl-names : should be "default"
+ - pinctrl-0:: a phandle pointing to the pin settings for the
+ control gpios
+ - touchscreen-fuzz-x: horizontal noise value of the absolute input
+ device (in pixels)
+ - touchscreen-fuzz-y: vertical noise value of the absolute input
+ device (in pixels)
+ - touchscreen-inverted-x : X axis is inverted (boolean)
+ - touchscreen-inverted-y : Y axis is inverted (boolean)
+ - touchscreen-swap-x-y : X and Y axis are swapped (boolean)
+ Swapping is done after inverting the axis
+
+Example:
+
+i2c@ {
+ /* ... */
+
+ chipone_icn8318@40 {
+ compatible = "chipone,icn8318";
+ reg = <0x40>;
+ interrupt-parent = <&pio>;
+ interrupts = <9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
+ pinctrl-names = "default";
+ pinctrl-0 = <&ts_wake_pin_p66>;
+ wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ touchscreen-inverted-x;
+ touchscreen-swap-x-y;
+ };
+
+ /* ... */
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index cc8848f..a4cb25e 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -35,6 +35,7 @@ capella Capella Microsystems, Inc
cavium Cavium, Inc.
cdns Cadence Design Systems Inc.
chipidea Chipidea, Inc
+chiponeChipOne
chipspark ChipSPARK
chrp Common Hardware Reference Platform
chunghwa Chunghwa Picture Tubes Ltd.
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..d39304c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2512,6 +2512,13 @@ L: linux-...@vger.kernel.org
S: Maintained
F: drivers/usb/chipidea/
+CHIPONE ICN8318 I2C TOUCHSCREEN DRIVER
+M: Hans de Goede
+L: linux-in...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
+F: drivers/input/touchscreen/chipone_icn8318.c
+
CHROME HARDWARE PLATFORM SUPPORT
M: Olof Johansson
S: Maintained
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 5891752..19ca23e 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -140,6 +140,19 @@ config TOUCHSCREEN_BU21013
To compile this driver as a module, choose M here: the
module will be called bu21013_ts.
+config TOUCHSCREEN_CHIPONE_ICN8318
+ tristate "chipone icn8318 touchscreen controller"
+ depends on GPIOLIB
+ depends on I2C
+ depends on OF
+ help
+ Say Y here if you have a ChipOne icn8318 based I2C touchscreen.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called chipone_icn8318.
+
config TOUCHSCREEN_CY8CTMG110
tristate "cy8ctmg110
[PATCH v2 1/2] touchscreen devicetree binding: Add touchscreen-swap-x-y property
On devices with a native portrait screen a landscape touchscreen / digitizer may be used, this happens e.g. on ebook readers. In this case the X and Y axis of the touchscreen are swapped compared to the screen. Add a touchscreen-swap-x-y property which drivers can use to see if they need to swap the axis to make the touchscreen coordinates match the screen coordinates. Signed-off-by: Hans de Goede --- Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt index d8e0616..12401a1 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt @@ -16,6 +16,8 @@ Optional properties for Touchscreens: controller) - touchscreen-inverted-x : X axis is inverted (boolean) - touchscreen-inverted-y : Y axis is inverted (boolean) + - touchscreen-swap-x-y: X and Y axis are swapped (boolean) + Swapping is done after inverting the axis Deprecated properties for Touchscreens: - x-size : deprecated name for touchscreen-size-x -- 2.3.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
[PATCH v2] drivers/base: cacheinfo: validate device node for all the caches
On architectures that depend on DT for obtaining cache hierarcy, we need
to validate the device node for all the cache indices, failing to do so
might result in wrong information being exposed to the userspace.
This is quite possible on initial/incomplete versions of the device
trees. In such cases, it's better to bail out if all the required device
nodes are not present.
This patch adds checks for the validation of device node for all the
caches and doesn't initialise the cacheinfo if there's any error.
Cc: Greg Kroah-Hartman
Reported-by: Mark Rutland
Acked-by: Mark Rutland
Signed-off-by: Sudeep Holla
---
drivers/base/cacheinfo.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
v1->v2:
- Updated log information as suggested by Mark
- Added Mark's ACK
Hi Greg,
Can you please pick this fix for the next rc ?
Without this there's possibility that erroneous information is exposed
to userspace on architecture depending on DT especially if DT lacks
cache hierarcy information.
Regards,
Sudeep
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 6e64563361f0..9c2ba1c97c42 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -62,15 +62,21 @@ static int cache_setup_of_node(unsigned int cpu)
return -ENOENT;
}
- while (np && index < cache_leaves(cpu)) {
+ while (index < cache_leaves(cpu)) {
this_leaf = this_cpu_ci->info_list + index;
if (this_leaf->level != 1)
np = of_find_next_cache_node(np);
else
np = of_node_get(np);/* cpu node itself */
+ if (!np)
+ break;
this_leaf->of_node = np;
index++;
}
+
+ if (index != cache_leaves(cpu)) /* not all OF nodes populated */
+ return -ENOENT;
+
return 0;
}
@@ -189,8 +195,11 @@ static int detect_cache_attributes(unsigned int cpu)
* will be set up here only if they are not populated already
*/
ret = cache_shared_cpu_map_setup(cpu);
- if (ret)
+ if (ret) {
+ pr_warn("Unable to detect cache hierarcy from DT for CPU %d\n",
+ cpu);
goto free_ci;
+ }
return 0;
free_ci:
--
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 v4 7/8] hwmon: pwm-fan: Read PWM FAN configuration from device tree
On Mon, Feb 23, 2015 at 05:13:36PM +0100, Lukasz Majewski wrote: > Hi Guenter, > [ ... ] > > > > If devicetree is not configured, of_property_count_elems_of_size > > returns -ENOSYS, which is returned, causing the driver to fail > > loading. > > Has of_property_count_elems_of_size() returns -ENOSYS? > > Maybe something has changed, but in my linux-vanila (3.19-rc4) > at ./drivers/of/base.c it returns -EINVAL, -ENODATA or number of > elements. > > Have I missed something? > Hi Lukasz, Yes, you have. Check include/linux/of.h, line 484, in latest mainline. 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 2/2] input: Add support for ChipOne icn8318 based touchscreens
Hi,
On 23-02-15 16:28, Hans de Goede wrote:
The ChipOne icn8318 is an i2c capacitive touchscreen controller typically
used in cheap android tablets, this commit adds a driver for it.
Signed-off-by: Hans de Goede
And just when I think I'm done I discover there are spurious evdev events being
send after a close + open of the evdev node. I'll send a v2 of this set fixing
this
shortly.
Regards,
Hans
---
.../bindings/input/touchscreen/chipone_icn8318.txt | 46 +++
.../devicetree/bindings/vendor-prefixes.txt| 1 +
MAINTAINERS| 7 +
drivers/input/touchscreen/Kconfig | 13 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/chipone_icn8318.c| 307 +
6 files changed, 375 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
create mode 100644 drivers/input/touchscreen/chipone_icn8318.c
diff --git
a/Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
b/Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
new file mode 100644
index 000..b405493
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
@@ -0,0 +1,46 @@
+* ChipOne icn8318 I2C touchscreen controller
+
+Required properties:
+ - compatible: "chipone,icn8318"
+ - reg : I2C slave address of the chip (0x40)
+ - interrupt-parent : a phandle pointing to the interrupt controller
+ serving the interrupt for this chip
+ - interrupts: interrupt specification for the icn8318 interrupt
+ - wake-gpios: GPIO specification for the WAKE input
+ - touchscreen-size-x: horizontal resolution of touchscreen (in pixels)
+ - touchscreen-size-y: vertical resolution of touchscreen (in pixels)
+
+Optional properties:
+ - pinctrl-names : should be "default"
+ - pinctrl-0:: a phandle pointing to the pin settings for the
+ control gpios
+ - touchscreen-fuzz-x: horizontal noise value of the absolute input
+ device (in pixels)
+ - touchscreen-fuzz-y: vertical noise value of the absolute input
+ device (in pixels)
+ - touchscreen-inverted-x : X axis is inverted (boolean)
+ - touchscreen-inverted-y : Y axis is inverted (boolean)
+ - touchscreen-swap-x-y : X and Y axis are swapped (boolean)
+ Swapping is done after inverting the axis
+
+Example:
+
+i2c@ {
+ /* ... */
+
+ chipone_icn8318@40 {
+ compatible = "chipone,icn8318";
+ reg = <0x40>;
+ interrupt-parent = <&pio>;
+ interrupts = <9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
+ pinctrl-names = "default";
+ pinctrl-0 = <&ts_wake_pin_p66>;
+ wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ touchscreen-inverted-x;
+ touchscreen-swap-x-y;
+ };
+
+ /* ... */
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index cc8848f..a4cb25e 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -35,6 +35,7 @@ capella Capella Microsystems, Inc
caviumCavium, Inc.
cdns Cadence Design Systems Inc.
chipidea Chipidea, Inc
+chiponeChipOne
chipspark ChipSPARK
chrp Common Hardware Reference Platform
chunghwa Chunghwa Picture Tubes Ltd.
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..d39304c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2512,6 +2512,13 @@ L: linux-...@vger.kernel.org
S:Maintained
F:drivers/usb/chipidea/
+CHIPONE ICN8318 I2C TOUCHSCREEN DRIVER
+M: Hans de Goede
+L: linux-in...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
+F: drivers/input/touchscreen/chipone_icn8318.c
+
CHROME HARDWARE PLATFORM SUPPORT
M:Olof Johansson
S:Maintained
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 5891752..19ca23e 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -140,6 +140,19 @@ config TOUCHSCREEN_BU21013
To compile this driver as a module, choose M here: the
module will be called bu21013_ts.
+config TOUCHSCREEN_CHIPONE_ICN8318
+ tristate "chipone icn8318 touchscreen controller"
+ depends on GPIOLIB
+ depends on I2C
+ depends on OF
+ help
+ Say Y here if you have a ChipOne icn8318 based I2C touchscreen.
+
+ If unsure, say N.
Re: [PATCH v4 7/8] hwmon: pwm-fan: Read PWM FAN configuration from device tree
Hi Guenter,
> On 02/18/2015 02:07 AM, Lukasz Majewski wrote:
> > This patch provides code for reading PWM FAN configuration data via
> > device tree. The pwm-fan can work with full speed when configuration
> > is not provided. However, errors are propagated when wrong DT
> > bindings are found.
> > Additionally the struct pwm_fan_ctx has been extended.
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > Changes for v2:
> > - Rename pwm_fan_max_states to pwm_fan_cooling_levels
> > - Moving pwm_fan_of_get_cooling_data() call after setting end
> > enabling PWM FAN
> > - pwm_fan_of_get_cooling_data() now can fail - preserving old
> > behaviour
> > - Remove unnecessary dev_err() call
> > Changes for v3:
> > - Patch's headline has been reedited
> > - pwm_fan_of_get_cooling_data() return code is now being checked.
> > - of_property_count_elems_of_size() is now used instead
> > of_find_property()
> > - More verbose patch description added
> > Changes for v4:
> > - dev_err() has been removed from pwm_fan_of_get_cooling_data()
> > - Returning -EINVAL when "cooling-levels" are defined in DT, but
> > doesn't have the value
> > ---
> > drivers/hwmon/pwm-fan.c | 52
> > - 1 file changed,
> > 51 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
> > index bd42d39..82cd06a 100644
> > --- a/drivers/hwmon/pwm-fan.c
> > +++ b/drivers/hwmon/pwm-fan.c
> > @@ -30,7 +30,10 @@
> > struct pwm_fan_ctx {
> > struct mutex lock;
> > struct pwm_device *pwm;
> > - unsigned char pwm_value;
> > + unsigned int pwm_value;
> > + unsigned int pwm_fan_state;
> > + unsigned int pwm_fan_max_state;
> > + unsigned int *pwm_fan_cooling_levels;
> > };
> >
> > static int __set_pwm(struct pwm_fan_ctx *ctx, unsigned long pwm)
> > @@ -100,6 +103,48 @@ static struct attribute *pwm_fan_attrs[] = {
> >
> > ATTRIBUTE_GROUPS(pwm_fan);
> >
> > +int pwm_fan_of_get_cooling_data(struct device *dev, struct
> > pwm_fan_ctx *ctx) +{
> > + struct device_node *np = dev->of_node;
> > + int num, i, ret;
> > +
> > + ret = of_property_count_elems_of_size(np, "cooling-levels",
> > + sizeof(u32));
> > +
> > + if (ret == -EINVAL)
> > + return 0;
>
> The function returns -EINVAL if there is no such property,
> but also if prop->length % elem_size != 0. The latter _would_
> be an error.
>
> Overall I don't entirely understand why you do not call
> of_find_property first. If that returns NULL, you would know for sure
> that the property does not exist, and you would not have to second
> guess the returned error from of_property_count_elems_of_size.
For sake of readability I will at v5 first check of_find_property() and
if it is correct, then I will call of_property_count_u32_elems().
>
> On a side note, there is of_property_count_u32_elems() to count
> properties of size u32.
>
> > +
> > + if (ret <= 0) {
> > + dev_err(dev, "Wrong data!\n");
> > + return ret ? ret : -EINVAL;
> > + }
>
> If devicetree is not configured, of_property_count_elems_of_size
> returns -ENOSYS, which is returned, causing the driver to fail
> loading.
Has of_property_count_elems_of_size() returns -ENOSYS?
Maybe something has changed, but in my linux-vanila (3.19-rc4)
at ./drivers/of/base.c it returns -EINVAL, -ENODATA or number of
elements.
Have I missed something?
>
> > +
> > + num = ret;
> > + ctx->pwm_fan_cooling_levels = devm_kzalloc(dev, num *
> > sizeof(u32),
> > + GFP_KERNEL);
> > + if (!ctx->pwm_fan_cooling_levels)
> > + return -ENOMEM;
> > +
> > + ret = of_property_read_u32_array(np, "cooling-levels",
> > +
> > ctx->pwm_fan_cooling_levels, num);
> > + if (ret) {
> > + dev_err(dev, "Property 'cooling-levels' cannot be
> > read!\n");
> > + return ret;
> > + }
> > +
> > + for (i = 0; i < num; i++) {
> > + if (ctx->pwm_fan_cooling_levels[i] > MAX_PWM) {
> > + dev_err(dev, "PWM fan state[%d]:%d >
> > %d\n", i,
> > + ctx->pwm_fan_cooling_levels[i],
> > MAX_PWM);
> > + return -EINVAL;
> > + }
> > + }
> > +
> > + ctx->pwm_fan_max_state = num - 1;
> > +
> > + return 0;
> > +}
> > +
> > static int pwm_fan_probe(struct platform_device *pdev)
> > {
> > struct device *hwmon;
> > @@ -145,6 +190,11 @@ static int pwm_fan_probe(struct
> > platform_device *pdev) pwm_disable(ctx->pwm);
> > return PTR_ERR(hwmon);
> > }
> > +
> > + ret = pwm_fan_of_get_cooling_data(&pdev->dev, ctx);
> > + if (ret)
> > + return ret;
I think that here is the confusing part. Please compare this patch with
the following one.
Here we configure ctx struct via DT. If of_property_count_u32_elems()
returns -EINVAL, then we consider that "cooling-levels" wasn't defined
in DT and return with 0. Other error codes a
Re: [PATCHv2 06/15] devicetree: bindings: add DT binding for the Marvell Armada 39x SoC family
Hi Thomas, On 20/02/2015 18:04, Thomas Petazzoni wrote: > The Marvell Armada 39x is a family of two SoCs: the Armada 390 and the > Armada 398, with a slightly different number of interfaces. This > commit introduces the Device Tree binding that documents the top-level > compatible strings for Armada 39x based platforms. > > Signed-off-by: Thomas Petazzoni Acked-by: Gregory CLEMENT Thanks, Gregory > --- > Documentation/devicetree/bindings/arm/armada-39x.txt | 20 > > 1 file changed, 20 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/armada-39x.txt > > diff --git a/Documentation/devicetree/bindings/arm/armada-39x.txt > b/Documentation/devicetree/bindings/arm/armada-39x.txt > new file mode 100644 > index 000..53d4ff9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/arm/armada-39x.txt > @@ -0,0 +1,20 @@ > +Marvell Armada 39x Platforms Device Tree Bindings > +- > + > +Boards with a SoC of the Marvell Armada 39x family shall have the > +following property: > + > +Required root node property: > + > + - compatible: must contain "marvell,armada390" > + > +In addition, boards using the Marvell Armada 398 SoC shall have the > +following property before the previous one: > + > +Required root node property: > + > +compatible: must contain "marvell,armada398" > + > +Example: > + > +compatible = "marvell,a398-db", "marvell,armada398", "marvell,armada390"; > -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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: [PATCHv2 05/15] ARM: mvebu: add stdout-path to all armada-*.dts
Hi Thomas,
On 20/02/2015 18:04, Thomas Petazzoni wrote:
> This commit adds the stdout-path property in /chosen for all Armada
> boards that were not yet carrying this property.
I though the main motivation for using the stdout-path property was
for removing the earlyprintk in the command line. Arnd told that there
should be a mean to use stdout-path instead of earlyprintk.
So what about going further and removing "earlyprintk" in the same time?
Thanks,
Gregory
>
> Signed-off-by: Thomas Petazzoni
> ---
> arch/arm/boot/dts/armada-370-db.dts | 1 +
> arch/arm/boot/dts/armada-370-mirabox.dts | 1 +
> arch/arm/boot/dts/armada-370-netgear-rn102.dts | 1 +
> arch/arm/boot/dts/armada-370-netgear-rn104.dts | 1 +
> arch/arm/boot/dts/armada-370-rd.dts | 1 +
> arch/arm/boot/dts/armada-375-db.dts | 1 +
> arch/arm/boot/dts/armada-388-db.dts | 1 +
> arch/arm/boot/dts/armada-388-rd.dts | 1 +
> arch/arm/boot/dts/armada-xp-axpwifiap.dts| 1 +
> arch/arm/boot/dts/armada-xp-db.dts | 1 +
> arch/arm/boot/dts/armada-xp-gp.dts | 1 +
> arch/arm/boot/dts/armada-xp-matrix.dts | 1 +
> arch/arm/boot/dts/armada-xp-netgear-rn2120.dts | 1 +
> arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 1 +
> 14 files changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/armada-370-db.dts
> b/arch/arm/boot/dts/armada-370-db.dts
> index e993c46..286bedd 100644
> --- a/arch/arm/boot/dts/armada-370-db.dts
> +++ b/arch/arm/boot/dts/armada-370-db.dts
> @@ -56,6 +56,7 @@
>
> chosen {
> bootargs = "console=ttyS0,115200 earlyprintk";
> + stdout-path = &uart0;
> };
>
> memory {
> diff --git a/arch/arm/boot/dts/armada-370-mirabox.dts
> b/arch/arm/boot/dts/armada-370-mirabox.dts
> index b10ceb4..ec77b86 100644
> --- a/arch/arm/boot/dts/armada-370-mirabox.dts
> +++ b/arch/arm/boot/dts/armada-370-mirabox.dts
> @@ -52,6 +52,7 @@
>
> chosen {
> bootargs = "console=ttyS0,115200 earlyprintk";
> + stdout-path = &uart0;
> };
>
> memory {
> diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts
> b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
> index 7c5c4ff..8c786cf 100644
> --- a/arch/arm/boot/dts/armada-370-netgear-rn102.dts
> +++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
> @@ -54,6 +54,7 @@
>
> chosen {
> bootargs = "console=ttyS0,115200 earlyprintk";
> + stdout-path = &uart0;
> };
>
> memory {
> diff --git a/arch/arm/boot/dts/armada-370-netgear-rn104.dts
> b/arch/arm/boot/dts/armada-370-netgear-rn104.dts
> index 1de53b5..1d64532 100644
> --- a/arch/arm/boot/dts/armada-370-netgear-rn104.dts
> +++ b/arch/arm/boot/dts/armada-370-netgear-rn104.dts
> @@ -54,6 +54,7 @@
>
> chosen {
> bootargs = "console=ttyS0,115200 earlyprintk";
> + stdout-path = &uart0;
> };
>
> memory {
> diff --git a/arch/arm/boot/dts/armada-370-rd.dts
> b/arch/arm/boot/dts/armada-370-rd.dts
> index 6ae36a3..f40d35b 100644
> --- a/arch/arm/boot/dts/armada-370-rd.dts
> +++ b/arch/arm/boot/dts/armada-370-rd.dts
> @@ -65,6 +65,7 @@
>
> chosen {
> bootargs = "console=ttyS0,115200 earlyprintk";
> + stdout-path = &uart0;
> };
>
> memory {
> diff --git a/arch/arm/boot/dts/armada-375-db.dts
> b/arch/arm/boot/dts/armada-375-db.dts
> index 0440891..033665c 100644
> --- a/arch/arm/boot/dts/armada-375-db.dts
> +++ b/arch/arm/boot/dts/armada-375-db.dts
> @@ -56,6 +56,7 @@
>
> chosen {
> bootargs = "console=ttyS0,115200 earlyprintk";
> + stdout-path = &uart0;
> };
>
> memory {
> diff --git a/arch/arm/boot/dts/armada-388-db.dts
> b/arch/arm/boot/dts/armada-388-db.dts
> index af6c74e..c56ccd74 100644
> --- a/arch/arm/boot/dts/armada-388-db.dts
> +++ b/arch/arm/boot/dts/armada-388-db.dts
> @@ -55,6 +55,7 @@
>
> chosen {
> bootargs = "console=ttyS0,115200 earlyprintk";
> + stdout-path = &uart0;
> };
>
> memory {
> diff --git a/arch/arm/boot/dts/armada-388-rd.dts
> b/arch/arm/boot/dts/armada-388-rd.dts
> index d99baac..e17edbb 100644
> --- a/arch/arm/boot/dts/armada-388-rd.dts
> +++ b/arch/arm/boot/dts/armada-388-rd.dts
> @@ -56,6 +56,7 @@
>
> chosen {
> bootargs = "console=ttyS0,115200 earlyprintk";
> + stdout-path = &uart0;
> };
>
> memory {
> diff --git a/arch/arm/boot/dts/armada-xp-axpwifiap.dts
> b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
> index c1fbab2..a7fd474 100644
> --- a/arch/arm/boot/dts/armada-xp-axpwifiap.dts
> +++ b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
> @@ -60,6 +60,7 @@
>
> chosen {
> bootargs = "console=ttyS0,115200 earlyprintk";
> + stdout-path = &uart0;
> };
>
> memory {
> diff --git a/arch/arm/
Re: [PATCH] mfd: arizona: Move useful defines into a dt-binding include
On Wed, Feb 18, 2015 at 5:03 AM, Charles Keepax wrote: > Move parts of linux/mfd/arizona/pdata.h and gpio.h into a new file in > the dt-binding directory for use by device tree bindings. This also > makes gpio.h redundant so remove it in the process. > > Signed-off-by: Charles Keepax > --- > include/dt-bindings/mfd/arizona.h | 109 > + > include/linux/mfd/arizona/gpio.h | 96 > include/linux/mfd/arizona/pdata.h | 46 +--- > sound/soc/codecs/arizona.c|1 - > 4 files changed, 110 insertions(+), 142 deletions(-) > create mode 100644 include/dt-bindings/mfd/arizona.h > delete mode 100644 include/linux/mfd/arizona/gpio.h > > diff --git a/include/dt-bindings/mfd/arizona.h > b/include/dt-bindings/mfd/arizona.h > new file mode 100644 > index 000..f2a4821 > --- /dev/null > +++ b/include/dt-bindings/mfd/arizona.h > @@ -0,0 +1,109 @@ > +/* > + * Device Tree defines for Arizona devices > + * > + * Copyright 2014 Wolfson Microelectronics. PLC. > + * > + * Author: Charles Keepax > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > + > +#ifndef _DT_BINDINGS_MFD_ARIZONA_H > +#define _DT_BINDINGS_MFD_ARIZONA_H > + > +#define ARIZONA_GP_FN_TXLRCLK0x00 > +#define ARIZONA_GP_FN_GPIO 0x01 These are all register offsets? If so, I don't think they belong in dts files. > +#define ARIZONA_GP_FN_IRQ1 0x02 > +#define ARIZONA_GP_FN_IRQ2 0x03 > +#define ARIZONA_GP_FN_OPCLK 0x04 > +#define ARIZONA_GP_FN_FLL1_OUT 0x05 > +#define ARIZONA_GP_FN_FLL2_OUT 0x06 > +#define ARIZONA_GP_FN_PWM1 0x08 > +#define ARIZONA_GP_FN_PWM2 0x09 > +#define ARIZONA_GP_FN_SYSCLK_UNDERCLOCKED0x0A > +#define ARIZONA_GP_FN_ASYNCCLK_UNDERCLOCKED 0x0B > +#define ARIZONA_GP_FN_FLL1_LOCK 0x0C > +#define ARIZONA_GP_FN_FLL2_LOCK 0x0D > +#define ARIZONA_GP_FN_FLL1_CLOCK_OK 0x0F > +#define ARIZONA_GP_FN_FLL2_CLOCK_OK 0x10 > +#define ARIZONA_GP_FN_HEADPHONE_DET 0x12 > +#define ARIZONA_GP_FN_MIC_DET0x13 > +#define ARIZONA_GP_FN_WSEQ_STATUS0x15 > +#define ARIZONA_GP_FN_CIF_ADDRESS_ERROR 0x16 > +#define ARIZONA_GP_FN_ASRC1_LOCK 0x1A > +#define ARIZONA_GP_FN_ASRC2_LOCK 0x1B > +#define ARIZONA_GP_FN_ASRC_CONFIG_ERROR 0x1C > +#define ARIZONA_GP_FN_DRC1_SIGNAL_DETECT 0x1D > +#define ARIZONA_GP_FN_DRC1_ANTICLIP 0x1E > +#define ARIZONA_GP_FN_DRC1_DECAY 0x1F > +#define ARIZONA_GP_FN_DRC1_NOISE 0x20 > +#define ARIZONA_GP_FN_DRC1_QUICK_RELEASE 0x21 > +#define ARIZONA_GP_FN_DRC2_SIGNAL_DETECT 0x22 > +#define ARIZONA_GP_FN_DRC2_ANTICLIP 0x23 > +#define ARIZONA_GP_FN_DRC2_DECAY 0x24 > +#define ARIZONA_GP_FN_DRC2_NOISE 0x25 > +#define ARIZONA_GP_FN_DRC2_QUICK_RELEASE 0x26 > +#define ARIZONA_GP_FN_MIXER_DROPPED_SAMPLE 0x27 > +#define ARIZONA_GP_FN_AIF1_CONFIG_ERROR 0x28 > +#define ARIZONA_GP_FN_AIF2_CONFIG_ERROR 0x29 > +#define ARIZONA_GP_FN_AIF3_CONFIG_ERROR 0x2A > +#define ARIZONA_GP_FN_SPK_TEMP_SHUTDOWN 0x2B > +#define ARIZONA_GP_FN_SPK_TEMP_WARNING 0x2C > +#define ARIZONA_GP_FN_UNDERCLOCKED 0x2D > +#define ARIZONA_GP_FN_OVERCLOCKED0x2E > +#define ARIZONA_GP_FN_DSP_IRQ1 0x35 > +#define ARIZONA_GP_FN_DSP_IRQ2 0x36 > +#define ARIZONA_GP_FN_ASYNC_OPCLK0x3D > +#define ARIZONA_GP_FN_BOOT_DONE 0x44 > +#define ARIZONA_GP_FN_DSP1_RAM_READY 0x45 > +#define ARIZONA_GP_FN_SYSCLK_ENA_STATUS 0x4B > +#define ARIZONA_GP_FN_ASYNCCLK_ENA_STATUS0x4C > + > +#define ARIZONA_GPN_DIR 0x8000 /* GPN_DIR */ > +#define ARIZONA_GPN_DIR_MASK 0x8000 /* GPN_DIR */ > +#define ARIZONA_GPN_DIR_SHIFT15 /* GPN_DIR */ > +#define ARIZONA_GPN_DIR_WIDTH 1 /* GPN_DIR */ Similarly, how do you intend to use these in dts files? Rob > +#define ARIZONA_GPN_PU 0x4000 /* GPN_PU */ > +#define ARIZONA_GPN_PU_MASK 0x4000 /* GPN_PU */ > +#define ARIZONA_GPN_PU_SHIFT 14 /* GPN_PU */ > +#define ARIZONA_GPN_PU_WIDTH 1 /* GPN_PU */ > +#define ARIZONA_GPN_PD 0x2000 /* GPN_PD */ > +#define ARIZONA_GPN_PD_MASK 0x2000 /* GPN_PD */ > +#define ARIZONA_GPN_PD_SHIFT
Re: [PATCH v2] mfd: arizona: Move useful defines into a dt-binding include
On Sat, Feb 21, 2015 at 12:17:57PM +, Charles Keepax wrote: > Move parts of linux/mfd/arizona/pdata.h and gpio.h into a new file in > the dt-binding directory for use by device tree bindings. This also > makes gpio.h redundant so remove it in the process. Acked-by: Mark Brown signature.asc Description: Digital signature
Re: [PATCH v4 4/4] phy: add phy-hi6220-usb
Hi,
On Sun, Feb 22, 2015 at 11:10:36AM +0800, zhangfei wrote:
> >>+static void hi6220_start_peripheral(struct hi6220_priv *priv, bool on)
> >>+{
> >>+ struct usb_otg *otg = priv->phy.otg;
> >>+
> >>+ if (!otg->gadget)
> >>+ return;
> >>+
> >>+ if (on)
> >>+ usb_gadget_connect(otg->gadget);
> >>+ else
> >>+ usb_gadget_disconnect(otg->gadget);
> >
> >why is the PHY fiddling with pullups ?
>
> We use this to enable/disable otg gadget mode.
> >>>
> >>>I got that, but the pullups don't belong to the PHY, they belong to the
> >>>gadget.
> >>>
> The gpio_id & gpio_vbus are used to distinguish otg gadget mode or
> host mode.
> When micro usb or otg device attached to otg, gpio_vbus falling down.
> And gpio_id = 1 is micro usb, gpio_id = 0 is otg device.
> >>>
> >>>all of that I understood clearly :-)
> >>>
> So when micro usb attached, we enable gadget mode; while micro usb
> detached, we disable gadget mode, and dwc2 will automatically set to
> host mode.
> >>>
> >>>that's all fine, I'm concerned about letting the PHY fiddle with
> >>>something it doesn't own. If I am to change pullups rules in udc-core,
> >>>this is likely to break down miserably and I don't want to have to go
> >>>through that.
> >>
> >>Thanks for the clarifying.
> >
> >no problem.
> >
> >>How about using usb_gadget_vbus_connect/disconnect, which are used in many
> >>files under drivers/usb/phy.
> >>There is no vbus_session in dwc2/gadget.c, I thought it would be same as
> >>pullup.
> >>
> >>However, usb_gadget_vbus_connect still need para gadget, where should we put
> >>this file, drivers/usb/phy or drivers/phy
> >
> >drivers/phy, if the framework misses anything you need, it's a great
> >opportunity to give back to the community by extending the framework.
>
> Sorry, I am a little confused.
> I need some concrete suggestion for the next step of this patch, which is
> required for the community board, hikey board.
>
> Do you mean in the future we need use hsotg->phy instead of hsotg->uphy.
> struct phy *phy;
> struct usb_phy *uphy;
yes, we need to move everybody to use struct phy, instead of struct
usb_phy.
> usb_phy has many members that struct phy does not have, including otg.
> struct usb_otg *otg;
> Is that mean we need port such member from usb_phy to phy.
This means we have a little ground work to do before we can add your phy
driver to that framework, right ? As I said, if the framework is missing
anything, work with Kishon (generic phy maintainer) to add those missing
pieces generically.
> Besides, are you ok with using usb_gadget_vbus_connect/disconnect.
>
> >
> >Scratching one's own itch kinda thing...
> >
> >>+static void hi6220_detect_work(struct work_struct *work)
> >>+{
> >>+ struct hi6220_priv *priv =
> >>+ container_of(work, struct hi6220_priv, work.work);
> >>+ int gpio_id, gpio_vbus;
> >>+ enum usb_otg_state state;
> >>+
> >>+ if (!gpio_is_valid(priv->gpio_id) ||
> >>!gpio_is_valid(priv->gpio_vbus))
> >>+ return;
> >>+
> >>+ gpio_id = gpio_get_value_cansleep(priv->gpio_id);
> >>+ gpio_vbus = gpio_get_value_cansleep(priv->gpio_vbus);
> >
> >looks like this should be using extcon
> Not used extcon before.
> However, we need gpio_vbus interrupt.
> Checked phy-tahvo.c and phy-omap-otg.c, not find extcon related with
> interrupt.
> Will investigate tomorrow.
> >>>
> >>>drivers/extcon/extcon-gpio.c
> >>I think there is no need to use extcon, gpio is clear enough.
> >>extcon-gpio.c even do not support dt.
> >
> >well, add DT. The whole idea of free software is that we improve on
> >things we already have. EXTCON is *the* API to handle such things.
>
> I think I am still not understanding extcon-gpio, not sure why need
> use this API here.
because extcon is the API to use for external connectors. The same way
you use regulator framework to control that single GPIO tied to an
enable signal of a fixed regulator, you use extcon when you need to read
that gpio signal tied to id pin of the USB connector.
> Here two gpio requires, one gpio as interrupt, in the interrupt
> handler, we detect the gpio status judging the otg status.
> extcon-gpio.c use the interrupt, then can we also use the gpio
> interrupt. Using extcon-gpio is used for saving gpio_request?
extcon is used to hide gpio_request from dwc2. dwc2 only knows about
extcon, not gpios. extcon will request the gpio and use it as interrupt
source. When an IRQ fires, it will read the gpio state and decide if it
should broadcast a message to tell dwc2 to become host or peripheral.
> >Quite frankly, though, Roger Quadros (now in Cc) has been working to get
> >DT support on extcon-gpio, so perhaps wait for that and base your
> >patches on top of his.
> >
>
Re: [PATCH RFC 2/3] power: mxs_power: add driver for mxs power subsystem
On Fri, Feb 20, 2015 at 11:57:41AM +0100, Stefan Wahren wrote:
> > power: power@80044000 {
> > compatible = "fsl,imx28-power"; /* handled by mxs_power.c */
> > #address-cells = <1>;
> > #size-cells = <1>;
> > reg = <0x80044000 0x2000>;
> > interrupts = <6>;
> > switching-frequency = <2400>; /* new property */
> > ranges;
> >
> > reg_vddd: regulator@80044040 {
> > reg = <0x80044040 0x10>,
> > <0x80044010 0x10>,
> > <0x800440c0 0x10>;
> > reg-names = "base-address",
> > "v5ctrl-address",
> > "status-address";
> > compatible = "fsl,imx28-vddd"; /* handled by mxs-regulator.c */
> > regulator-name = "vddd";
> > regulator-min-microvolt = <135>;
> > regulator-max-microvolt = <155>;
> > vddd-supply = <®_vdda>;
> > };
> >
> > reg_vdda: regulator@80044050 {
> > reg = <0x80044050 0x10>,
> > <0x80044010 0x10>,
> > <0x800440c0 0x10>;
> > reg-names = "base-address",
> > "v5ctrl-address",
> > "status-address";
> > compatible = "fsl,imx28-vdda"; /* handled by mxs-regulator.c */
> > regulator-name = "vdda";
> > regulator-min-microvolt = <1725000>;
> > regulator-max-microvolt = <195>;
> > vdda-supply = <®_vddio>;
> > };
> >
> > reg_vddio: regulator@80044060 {
> > reg = <0x80044060 0x10>,
> > <0x80044010 0x10>,
> > <0x800440c0 0x10>;
> > reg-names = "base-address",
> > "v5ctrl-address",
> > "status-address";
> > compatible = "fsl,imx28-vddio"; /* handled by mxs-regulator.c */
> > regulator-name = "vddio";
> > regulator-min-microvolt = <300>;
> > regulator-max-microvolt = <3575000>;
> > regulator-microvolt-offset = <8>;
> > };
> > };
> >
> > Please correct me if i'm wrong.
> >
> > Stefan
>
> Gentle Ping.
The binding looks ok to me. It would be nice to get an ACK of a DT
binding maintainer, though.
-- Sebastian
signature.asc
Description: Digital signature
Re: [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework
Thankyou for the comments.
On 23/02/15 15:04, Mark Brown wrote:
On Thu, Feb 19, 2015 at 05:08:28PM +, Srinivas Kandagatla wrote:
.../devicetree/bindings/eeprom/eeprom.txt | 48
drivers/Kconfig| 2 +
drivers/Makefile | 1 +
drivers/eeprom/Kconfig | 19 ++
drivers/eeprom/Makefile| 9 +
drivers/eeprom/core.c | 290 +
include/linux/eeprom-consumer.h| 73 ++
include/linux/eeprom-provider.h| 51
This seems to have a bunch of different things in it - there's some
binding, there's some framework code, there's some user code for the
framework... splitting it up more would probably help with review.
I'd at least make sure the framework is split from the DT code, that
will cut down on the bulk and help make sure the framework isn't too DT
tied.
Yes I agree, will make sure that I split it into different patches in
next version.
+ if (read)
+ rc = regmap_bulk_read(eeprom->regmap, offset,
+ buf, count/eeprom->stride);
+ else
+ rc = regmap_bulk_write(eeprom->regmap, offset,
+ buf, count/eeprom->stride);
+
+ if (IS_ERR_VALUE(rc))
+ return 0;
+
+ return count;
+}
+static ssize_t bin_attr_eeprom_read(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *attr,
+ char *buf, loff_t offset, size_t count)
+{
+ return bin_attr_eeprom_read_write(kobj, buf, offset, count, true);
+}
I'm not sure the factoring out is actually helping the clarity here TBH.
ok.
+int eeprom_unregister(struct eeprom_device *eeprom)
+{
+ device_del(&eeprom->edev);
+
+ mutex_lock(&eeprom_list_mutex);
+ list_del(&eeprom->list);
+ mutex_unlock(&eeprom_list_mutex);
+
+ return 0;
+}
+EXPORT_SYMBOL(eeprom_unregister);
Here we return having dropped the lock without doing anything else with
the eeprom, meaning the caller could delete it.
+ mutex_lock(&eeprom_list_mutex);
+
+ list_for_each_entry(e, &eeprom_list, list) {
+ if (args.np == e->edev.of_node) {
+ eeprom = e;
+ break;
+ }
+ }
+ mutex_unlock(&eeprom_list_mutex);
Here we iterate the list, find the relevant eeprom and drop the lock
while still holding a reference to the eeprom we just found. This means
that a removal could race with us and free the eeprom underneath us.
I'm also not seeing anything stopping or even noticing a device being
removed with a cell active on it.
As suggested by Stephen Boyd reference counting on eeprom should ensure
safe removal of eeprom.
+/**
+ * eeprom_cell_get(): Get eeprom cell of device form a given index.
+ *
+ * @dev: Device that will be interacted with
+ * @index: Index of the eeprom cell.
+ *
+ * The return value will be an ERR_PTR() on error or a valid pointer
+ * to a struct eeprom_cell. The eeprom_cell will be freed by the
+ * eeprom_cell_put().
+ */
+struct eeprom_cell *eeprom_cell_get(struct device *dev, int index);
Normally the kerneldoc goes with the function definition, not the
prototype.
Thats true, will fix it in next version.
--
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: [resend PATCH v3 4/4] usb: phy: add phy-hi6220-usb
On Wed, Feb 11, 2015 at 11:10:31AM +0200, Baruch Siach wrote: > Hi Peter, Felipe, > > > > new drivers only on drivers/phy/, sorry. > > > > This driver has many USB dependencies, like otg, gadget. I don't know it > > can use generic phy currently. > > I would like to remind you the thread at > http://thread.gmane.org/gmane.linux.kernel/1858137. I have a USB PHY driver > here that depends on notify_connect/notify_disconnect, which are not > currently > provided by the generic phy infrastructure (drivers/phy/). What would be > acceptable solution for this case? work with Kishon (generic phy maintainer) to add missing pieces you need. -- balbi signature.asc Description: Digital signature
