Re: [alsa-devel] [PATCH 00/11] Add AXD Audio Processing IP driver
On Tue, Oct 28, 2014 at 10:13:48PM +0800, Greg Kroah-Hartman wrote: On Tue, Oct 28, 2014 at 01:18:28PM +, Qais Yousef wrote: On 10/28/2014 11:55 AM, Clemens Ladisch wrote: Qais Yousef wrote: AXD Audio Processing IP performs audio decoding, encoding, mixing, equalisation, synchronisation and playback. What exactly do you mean with synchronisation and playback? Synchronisation refers to accurate audio playout relative to a master clock source including compensation of drift between the master clock source and the playout clock of the audio hardware. Hence allowing synchronised audio playout across multiple independent devices. Playback simple refers to the fact that AXD is capable of managing audio playout hardware like I2S and SPDIF interfaces. It doesn't fit in alsa subsystem but I Cced them to confirm. ... because those two words sound like something that a sound card could do. The problem mainly stems from the fact that we take a variety of compressed audio as input and we could perform audio encoding. The problem with the compressed audio is that the range of decoders and configuration supported in alsa is limited and there's no support for taking raw pcm and producing compressed output. I'm not an expert on alsa but when I looked it looked like there's more infra structure required. The following not supported points from Documentation/sound/alsa/compress_offload.txt affect us: - Volume control/routing is not handled by this API. Devices exposing a compressed data interface will be considered as regular ALSA devices; volume changes and routing information will be provided with regular ALSA kcontrols. - Embedded audio effects. Such effects should be enabled in the same manner, no matter if the input was PCM or compressed. - Encoding/decoding acceleration is not supported as mentioned above. It is possible to route the output of a decoder to a capture stream, or even implement transcoding capabilities. This routing would be enabled with ALSA kcontrols. So instead you created a one-off api just for this hardware? Ick, no, please work with the audio developers to incorporate it into the standard Linux audio apis so that everyone can benifit and not require special userspace programs to drive this hardware. I think it more a case of I want it do this by method A, ...nah thats not what is availble in ALSA so let me redo the whole stack rather than model my driver to use ALSA -- ~Vinod -- 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: [alsa-devel] [PATCH 00/11] Add AXD Audio Processing IP driver
On Wed, Oct 29, 2014 at 10:50:19AM +0800, Greg Kroah-Hartman wrote: On Tue, Oct 28, 2014 at 03:05:16PM +, Qais Yousef wrote: On 10/28/2014 02:13 PM, Greg Kroah-Hartman wrote: On Tue, Oct 28, 2014 at 01:18:28PM +, Qais Yousef wrote: On 10/28/2014 11:55 AM, Clemens Ladisch wrote: Qais Yousef wrote: AXD Audio Processing IP performs audio decoding, encoding, mixing, equalisation, synchronisation and playback. What exactly do you mean with synchronisation and playback? Synchronisation refers to accurate audio playout relative to a master clock source including compensation of drift between the master clock source and the playout clock of the audio hardware. Hence allowing synchronised audio playout across multiple independent devices. Playback simple refers to the fact that AXD is capable of managing audio playout hardware like I2S and SPDIF interfaces. It doesn't fit in alsa subsystem but I Cced them to confirm. ... because those two words sound like something that a sound card could do. The problem mainly stems from the fact that we take a variety of compressed audio as input and we could perform audio encoding. The problem with the compressed audio is that the range of decoders and configuration supported in alsa is limited and there's no support for taking raw pcm and producing compressed output. I'm not an expert on alsa but when I looked it looked like there's more infra structure required. The following not supported points from Documentation/sound/alsa/compress_offload.txt affect us: - Volume control/routing is not handled by this API. Devices exposing a compressed data interface will be considered as regular ALSA devices; volume changes and routing information will be provided with regular ALSA kcontrols. - Embedded audio effects. Such effects should be enabled in the same manner, no matter if the input was PCM or compressed. - Encoding/decoding acceleration is not supported as mentioned above. It is possible to route the output of a decoder to a capture stream, or even implement transcoding capabilities. This routing would be enabled with ALSA kcontrols. So instead you created a one-off api just for this hardware? Ick, no, please work with the audio developers to incorporate it into the standard Linux audio apis so that everyone can benifit and not require special userspace programs to drive this hardware. thanks, greg k-h OK. I'll wait to hear from alsa developers to see the extent of work required. I can't see it being trivial though. Would it be possible for this to be accepted into staging until this is resolved? If you are willing to abide by the staging rules: - incremental patches only doing one thing at a time - never break the build - constantly moving forward to getting merged (i.e. no new features being added) I think it will be easier for you to do the work outside of the tree as you are going to be changing the API, which is not going to be easy to do in an incremental patch series. And yes, this isn't going to be a trivial amount of work, sorry. I am not sure if it can fit into staging model. The whole design of driver would need rework and all the infrastructure added here for exposing stuff to usermode will be thrown away, so this driver would simply need an major overhaul. If this was ALSA driver and we would need to plumb it for acceptance then would have made sense in include, but thats not the fact today Thanks -- ~Vinod -- 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: [alsa-devel] [PATCH 03/11] drivers: char: add AXD Audio Processing IP driver
On Tue, Oct 28, 2014 at 11:26:21AM +, Qais Yousef wrote: + +/* Register I/F */ +#define AXD_REG_VERSION 0x +#define AXD_REG_CONFIG0 0x0004 +#define AXD_REG_CONFIG1 0x0008 +#define AXD_REG_CONFIG2 0x000C +#define AXD_REG_CONFIG3 0x0010 +#define AXD_REG_BUFFER_BASE 0x0014 +#define AXD_REG_DEBUG_MASK 0x0018 +/* 0x1c reserved */ +#define AXD_REG_INPUT0_CONTROL 0x0020 +#define AXD_REG_INPUT0_GAIN 0x0024 +#define AXD_REG_INPUT0_UPMIX 0x0028 +#define AXD_REG_INPUT1_CONTROL 0x0030 +#define AXD_REG_INPUT1_GAIN 0x0034 +#define AXD_REG_INPUT1_UPMIX 0x0038 +#define AXD_REG_INPUT2_CONTROL 0x0040 +#define AXD_REG_INPUT2_GAIN 0x0044 +#define AXD_REG_INPUT2_UPMIX 0x0048 +#define AXD_REG_INPUT0_MUTE 0x0050 +#define AXD_REG_INPUT1_MUTE 0x0054 +#define AXD_REG_INPUT2_MUTE 0x0058 +#define AXD_REG_MIXER_CONTROL 0x0080 +#define AXD_REG_EQ_CTRL_GAIN 0x0084 +#define AXD_REG_EQ_BAND0 0x0088 +#define AXD_REG_EQ_BAND1 0x008C +#define AXD_REG_EQ_BAND2 0x0090 +#define AXD_REG_EQ_BAND3 0x0094 +#define AXD_REG_EQ_BAND4 0x0098 +#define AXD_REG_MUX0 0x00B0 +#define AXD_REG_MUX1 0x00B4 +#define AXD_REG_MUX2 0x00B8 +#define AXD_REG_OUTPUT0_CONTROL 0x00D0 +#define AXD_REG_OUTPUT0_DOWNMIX 0x00D4 +#define AXD_REG_OUTPUT0_EQCTRL 0x00D8 +#define AXD_REG_OUTPUT0_EQBAND0 0x00DC +#define AXD_REG_OUTPUT0_EQBAND1 0x00E0 +#define AXD_REG_OUTPUT0_EQBAND2 0x00E4 +#define AXD_REG_OUTPUT0_EQBAND3 0x00E8 +#define AXD_REG_OUTPUT0_EQBAND4 0x00EC +#define AXD_REG_OUTPUT1_CONTROL 0x00F0 +#define AXD_REG_OUTPUT1_DOWNMIX 0x00F4 +#define AXD_REG_OUTPUT1_EQCTRL 0x00F8 +#define AXD_REG_OUTPUT1_EQBAND0 0x00FC +#define AXD_REG_OUTPUT1_EQBAND1 0x0100 +#define AXD_REG_OUTPUT1_EQBAND2 0x0104 +#define AXD_REG_OUTPUT1_EQBAND3 0x0108 +#define AXD_REG_OUTPUT1_EQBAND4 0x010C +#define AXD_REG_OUTPUT2_CONTROL 0x0110 +#define AXD_REG_OUTPUT2_DOWNMIX 0x0114 +#define AXD_REG_OUTPUT2_EQCTRL 0x0118 +#define AXD_REG_OUTPUT2_EQBAND0 0x011C +#define AXD_REG_OUTPUT2_EQBAND1 0x0120 +#define AXD_REG_OUTPUT2_EQBAND2 0x0124 +#define AXD_REG_OUTPUT2_EQBAND3 0x0128 +#define AXD_REG_OUTPUT2_EQBAND4 0x012c +#define AXD_REG_DEC0_AAC_VERSION 0x0200 +#define AXD_REG_DEC0_AAC_CHANNELS0x0204 +#define AXD_REG_DEC0_AAC_PROFILE 0x0208 +#define AXD_REG_DEC0_AAC_STREAM_TYPE 0x020C +#define AXD_REG_DEC0_AAC_SAMPLERATE 0x0210 +#define AXD_REG_DEC1_AAC_VERSION
Re: [PATCH 0/3] ARM: mediatek: Add driver for Mediatek I2C controller
Dear Sirs, Missed the first paragraph, sorry for extra mail. This series is the first version of Mediatek SoCs I2C controller common bus driver, it is Request for Comment. Because the clock driver for mediatek SoC is not ready yet(still work in progress), so I delete the related clock code in dtsi file for now. Best Regards, Xudong On Wed, 2014-10-29 at 13:37 +0800, Xudong Chen wrote: This driver is based on 3.18-rc1 Hongzhou's gpio patch. MTK I2C HW has some limitation. 1. If the i2c_msg number is more than one, STOP will be issued instead of RS(Repeat Start) between each message. Such as: START + ADDR + DATA_n + STOP + START + ADDR + DATA_n + STOP ... 2. Mediatek I2C controller support WRRD(write then read) mode, in WRRD mode the Repeat Start will be issued between 2 messages. In this driver if 2 messages is first write then read, the driver will combine 2 messages using Write-Read mode so the RS will be issued between the 2 messages. Ex: W/R/R, driver will combine first W/R and then R. The data series will be: START + WriteADDR + DATA + RS + ReadADDR + DATA + STOP + START + ReadADDR + DATA + STOP. 3. Due to HW limitation, in this version the max transfer data length is 255 in one message. If want to transfer more than 255 bytes, HW needs the SW driver to split the data. Take 600 bytes for example, the data need to be divided into 3 parts 255 + 255 + 90. The data series will be: START + ADDR + DATA_255 + RS + ADDR + DATA_255 + RS + ADDR + DATA_90 + STOP instead of START + ADDR + DATA_900 + STOP. We haven't implement this yet, we will do this in the separate patch. MT8135 can control I2C pins on PMIC(MT6397) by setting the i2c registers in MT8135 side. In this case, driver should set OFFSET_PATH_DIR bit first, the operation on other registers are still the same. Xudong Chen (3): dt-bindings: Add I2C bindings for mt65xx/mt81xx. ARM: mediatek: Add I2C node for mt8135 and mt8127 I2C: mediatek: Add driver for MediaTek I2C controller .../devicetree/bindings/i2c/i2c-mt6577.txt | 37 ++ arch/arm/boot/dts/mt8127.dtsi | 27 + arch/arm/boot/dts/mt8135.dtsi | 51 ++ drivers/i2c/busses/Kconfig | 9 + drivers/i2c/busses/Makefile| 1 + drivers/i2c/busses/i2c-mt65xx.c| 728 + 6 files changed, 853 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mt6577.txt create mode 100644 drivers/i2c/busses/i2c-mt65xx.c -- 1.8.1.1.dirty -- 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] mtd: atmel_nand: make PMECC lookup table and offset property optional
Hi,
Just a ping for this patch.
Best Regards,
Josh Wu
On 10/11/2014 6:01 PM, Josh Wu wrote:
From: Josh Wu josh...@atmel.com
If there is no PMECC lookup table stored in ROM, or lookup table offset is
not specified, PMECC driver should build it in DDR by itself.
That make the PMECC driver work for some board which doesn't has PMECC
lookup table in ROM.
The PMECC use the BCH algorithm, so based on the build_gf_tables()
function in lib/bch.c, we can build the Galois Field lookup table.
For more information can refer to section 5.4 of PMECC controller
application note:
http://www.atmel.com/images/doc11127.pdf
Signed-off-by: Josh Wu josh...@atmel.com
Cc: devicetree@vger.kernel.org
---
v1 - v2:
make create_lookup_table() static.
v2 - v3:
rewrite the build_gf_tables() function based on lib/bch.c.
add error handling in create_lookup_table().
.../devicetree/bindings/mtd/atmel-nand.txt | 6 +-
drivers/mtd/nand/atmel_nand.c | 81 --
drivers/mtd/nand/atmel_nand_ecc.h | 4 ++
3 files changed, 85 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index 6edc3b6..1fe6dde 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -5,7 +5,9 @@ Required properties:
- reg : should specify localbus address and size used for the chip,
and hardware ECC controller if available.
If the hardware ECC is PMECC, it should contain address and size for
- PMECC, PMECC Error Location controller and ROM which has lookup tables.
+ PMECC and PMECC Error Location controller.
+ The PMECC lookup table address and size in ROM is optional. If not
+ specified, driver will build it in runtime.
- atmel,nand-addr-offset : offset for the address latch.
- atmel,nand-cmd-offset : offset for the command latch.
- #address-cells, #size-cells : Must be present if the device has sub-nodes
@@ -27,7 +29,7 @@ Optional properties:
are: 512, 1024.
- atmel,pmecc-lookup-table-offset : includes two offsets of lookup table in
ROM
for different sector size. First one is for sector size 512, the next is for
- sector size 1024.
+ sector size 1024. If not specified, driver will build the table in runtime.
- nand-bus-width : 8 or 16 bus width if not present 8
- nand-on-flash-bbt: boolean to enable on flash bbt option if not present
false
- Nand Flash Controller(NFC) is a slave driver under Atmel nand flash
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 19d1e9d..5c1423a 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -127,6 +127,7 @@ struct atmel_nand_host {
boolhas_pmecc;
u8 pmecc_corr_cap;
u16 pmecc_sector_size;
+ boolhas_no_lookup_table;
u32 pmecc_lookup_table_offset;
u32 pmecc_lookup_table_offset_512;
u32 pmecc_lookup_table_offset_1024;
@@ -1112,12 +1113,66 @@ static int pmecc_choose_ecc(struct atmel_nand_host
*host,
return 0;
}
+static inline int deg(unsigned int poly)
+{
+ /* polynomial degree is the most-significant bit index */
+ return fls(poly) - 1;
+}
+
+static int build_gf_tables(int mm, unsigned int poly,
+ int16_t *index_of, int16_t *alpha_to)
+{
+ unsigned int i, x = 1;
+ const unsigned int k = 1 deg(poly);
+ unsigned int nn = (1 mm) - 1;
+
+ /* primitive polynomial must be of degree m */
+ if (k != (1u mm))
+ return -EINVAL;
+
+ for (i = 0; i nn; i++) {
+ alpha_to[i] = x;
+ index_of[x] = i;
+ if (i (x == 1))
+ /* polynomial is not primitive (a^i=1 with 0i2^m-1) */
+ return -EINVAL;
+ x = 1;
+ if (x k)
+ x ^= poly;
+ }
+ alpha_to[nn] = 1;
+ index_of[0] = 0;
+
+ return 0;
+}
+
+static uint16_t *create_lookup_table(struct device *dev, int sector_size)
+{
+ int degree = (sector_size == 512) ?
+ PMECC_GF_DIMENSION_13 :
+ PMECC_GF_DIMENSION_14;
+ unsigned int poly = (sector_size == 512) ?
+ PMECC_GF_13_PRIMITIVE_POLY :
+ PMECC_GF_14_PRIMITIVE_POLY;
+ int table_size = (sector_size == 512) ?
+ PMECC_LOOKUP_TABLE_SIZE_512 :
+ PMECC_LOOKUP_TABLE_SIZE_1024;
+
+ int16_t *addr = devm_kzalloc(dev, 2 * table_size * sizeof(uint16_t),
+ GFP_KERNEL);
+ if (addr build_gf_tables(degree, poly, addr, addr + table_size))
+ return NULL;
+
+
Re: [PATCH v2 2/2] ARM: shmobile: lager: enable USB3.0
On Fri, Oct 24, 2014 at 7:41 PM, Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com wrote: Since the PHY of USB3.0 and EHCI/OHCI ch2 are the same, the USB3.0 driver cannot use the phy driver when the EHCI/OHCI ch2 already used it: phy phy-e6590100.usb-phy.3: phy init failed -- -16 xhci-hcd: probe of ee00.usb failed with error -16 If so, we have to unbind the EHCI/OHCI ch2, and then we have to bind the USB3.0 driver as the following: echo :02:02.0 /sys/bus/pci/drivers/ehci-pci/unbind echo :02:01.0 /sys/bus/pci/drivers/ohci-pci/unbind echo ee00.usb /sys/bus/platform/drivers/xhci-hcd/bind Note that there will be pinctrl-related error messages if both internal PCI and USB3.0 are enabled but they should be just ignored: sh-pfc e606.pfc: pin GP_5_22 already requested by ee0d.pci; cannot claim for ee00.usb sh-pfc e606.pfc: pin-182 (ee00.usb) status -22 ata1: SATA link down (SStatus 0 SControl 300) sh-pfc e606.pfc: could not request pin 182 (GP_5_22) from group usb2 on device sh-pfc Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com --- arch/arm/boot/dts/r8a7790-lager.dts |6 ++ 1 file changed, 6 insertions(+) Hi Shimoda-san, Thanks for your patch. I'm fine with this patch as a first step, but I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0? Is the current order just based on device init order? In my mind the expected behavior would be to always use USB 3.0 if it happens to be available in the hardware, specified in the DTS, enabled by the kernel configuration and firmware is loadable. Or does some case exist where it is better to use USB 2.0? I suspect no. So I wonder if you have any plans how to make USB 3.0 enabled by default on Lager? 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: [RFC Patch] gpio: add GPIO hogging mechanism
Sorry for the delay in reviewing. Adding Jiri and Pantelis who might
want to extend over this patch and thus will likely have interesting
comments to make.
On Wed, Oct 22, 2014 at 5:09 AM, Benoit Parrot bpar...@ti.com wrote:
Based on Boris Brezillion work this is a reworked patch
of his initial GPIO hogging mechanism.
This patch provides a way to initally configure specific GPIO
when the gpio controller is probe.
Typo nit: s/probe/probed
The actual DT scanning to collect the GPIO specific data is performed
as part of the gpiochip_add().
The purpose of this is to allows specific GPIOs to be configured
without any driver specific code.
This particularly usueful because board design are getting
s/suseful/useful
increassingly complex and given SoC pins can now have upward
s/increassingly/increasingly
of 10 mux values a lot of connections are now dependent on
external IO muxes to switch various modes and combination.
Specific drivers should not necessarily need to be aware of
what accounts to a specific board implementation. This board level
description should be best kept as part of the dts file.
Signed-off-by: Benoit Parrot bpar...@ti.com
---
Documentation/devicetree/bindings/gpio/gpio.txt | 33 +
drivers/gpio/gpiolib-of.c | 99
+
drivers/gpio/gpiolib.c | 81
include/linux/of_gpio.h | 11 +++
4 files changed, 224 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt
b/Documentation/devicetree/bindings/gpio/gpio.txt
index 3fb8f53..a9700d8 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
Note: changes to DT bindings documentation should generally come as a
separate patch.
@@ -103,6 +103,26 @@ Every GPIO controller node must contain both an empty
gpio-controller
property, and a #gpio-cells integer property, which indicates the number of
cells in a gpio-specifier.
+It might contain GPIO hog definitions. GPIO hogging is a mechanism providing
+automatic GPIO request and configuration as part of the gpio-controller's
+driver probe function.
+
+Each GPIO hog definition is represented as a child node of the GPIO
controller.
+Required properties:
+- gpios: store the gpio information (id, flags, ...). Shall contain the
+ number of cells specified in its parent node (GPIO controller node).
If would be nice to be able to specify several GPIO references to that
they can be all set to the same configuration in one row instead of
requiring one node each.
+- input: a property specifying to set the GPIO direction as input.
+- output-high: a property specifying to set the GPIO direction to output with
+ the value high.
+- output-low: a property specifying to set the GPIO direction to output with
+ the value low.
Wouldn't a direction property taking one of the values input,
output-low or output-high be easier to parse and generally
clearer?
+
+Optional properties:
+- line-name: the GPIO label name. If not present the node name is used.
I guess we also could use this for naming the GPIO during its export
if we decide to allow this in a near-future patch.
+
+A GPIO controller can request GPIO hogs using the gpio-hogs property, which
+encodes a list of requested GPIO hogs.
+
Example of two SOC GPIO banks defined as gpio-controller nodes:
qe_pio_a: gpio-controller@1400 {
@@ -110,6 +130,19 @@ Example of two SOC GPIO banks defined as gpio-controller
nodes:
reg = 0x1400 0x18;
gpio-controller;
#gpio-cells = 2;
+ gpio-hogs = line_b;
+
+ /* line_a hog is defined but not enabled in this example*/
+ line_a: line_a {
+ gpios = 5 0;
+ input;
+ };
+
+ line_b: line_b {
+ gpios = 6 0;
+ output-low;
+ line-name = foo-bar-gpio;
+ };
I think it might be good to group the hog nodes such as to allow
complex configurations to be set in one go, à la pinmux:
gpio-controller;
#gpio-cells = 2;
+ gpio-hogs = line_b;
+
+ line_a: line_a {
+ line_a {
+ gpios = 5 0;
+ input;
+ };
+ line_c {
+ gpios = 7 0;
+ inputl
+ };
+ };
+
+ line_b: line_b {
+ line_b {
+ gpios = 6 0;
+ output-low;
+ line-name = foo-bar-gpio;
+ };
+ };
Here if you want to enable the first
Re: [PATCH RFC V3 2/3] mxs: add driver for ocotp in i.MX23 and i.MX28
Hi Ezequiel, Am 28.10.2014 um 18:17 schrieb Ezequiel Garcia: On 10/20/2014 11:44 AM, Arnd Bergmann wrote: On Saturday 18 October 2014 10:32:51 Stefan Wahren wrote: This patch brings readonly support for the On Chip OTP cells in the i.MX23 and i.MX28 processor. The driver uses files (one for each cell) in sysfs as interface. Signed-off-by: Stefan Wahren stefan.wah...@i2se.com --- drivers/misc/Kconfig | 13 ++ drivers/misc/Makefile|1 + drivers/misc/fsl_ocotp.c | 332 ++ 3 files changed, 346 insertions(+) create mode 100644 drivers/misc/fsl_ocotp.c diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index b841180..7455efa 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -515,6 +515,19 @@ config VEXPRESS_SYSCFG bus. System Configuration interface is one of the possible means of generating transactions on this bus. +config FSL_OCOTP +tristate Freescale MXS On-Chip OTP Memory Support +depends on ARCH_MXS SYSFS +help + If you say Y here, you will get support for a readonly + SysFS interface for the One Time Programmable memory pages that + are stored on the Freescale i.MX23/i.MX28 processor. + + To compile this driver as a module, choose M here: the module + will be called fsl_ocotp. + + If unsure, it is safe to say N. I think this needs to be an MTD driver, not a misc driver, and it should use the proper MTD interfaces instead of introducing an incompatible set of interfaces. Are you sure MTD is the right place? Recently an eFuse driver was merged in drivers/soc/tegra/fuse: http://lxr.free-electrons.com/source/drivers/soc/tegra/fuse/fuse-tegra.c Isn't this a similar device? the i.MX28 Reference manual speak also of eFuses and this driver looks more familiar to me. From my point of view it's important to keep the structure of 40 OTP register a 32 bits. It doesn't make sense to merge them all together in a blob of 1280 bits and a userspace tool needs to separate it again. Thanks for the hint. BR Stefan -- 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 02/11] irqchip: brcmstb-l2: Eliminate dependency on ARM code
On Tuesday 28 October 2014 20:58:49 Kevin Cernekee wrote: The irq-brcmstb-l2 driver has a single dependency on the ARM code, the do_bad_IRQ macro. Expand this macro in-place so that the driver can be built on non-ARM platforms. Signed-off-by: Kevin Cernekee cerne...@gmail.com Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] regulator: act8865: Convert poweroff-source DT property to system-power-controller
Signed-off-by: Romain Perier romain.per...@gmail.com
---
Documentation/devicetree/bindings/regulator/act8865-regulator.txt | 4 ++--
drivers/regulator/act8865-regulator.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
index 01a5b07..dad6358 100644
--- a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
@@ -6,8 +6,8 @@ Required properties:
- reg: I2C slave address
Optional properties:
-- poweroff-source: Telling whether or not this pmic is controlling
- the system power. See Documentation/devicetree/bindings/power/poweroff.txt .
+- system-power-controller: Telling whether or not this pmic is controlling
+ the system power. See
Documentation/devicetree/bindings/power/power-controller.txt .
Any standard regulator properties can be used to configure the single
regulator.
diff --git a/drivers/regulator/act8865-regulator.c
b/drivers/regulator/act8865-regulator.c
index 76301ed..435aba1 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -365,7 +365,7 @@ static int act8865_pmic_probe(struct i2c_client *client,
return ret;
}
- if (of_system_has_poweroff_source(dev-of_node)) {
+ if (of_is_system_power_controller(dev-of_node)) {
if (!pm_power_off) {
act8865_i2c_client = client;
act8865-off_reg = off_reg;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] poweroff-source DT property renaming
The goal of this serie is to rename the property poweroff-source to system-power-controller and to fix things incrementally. Changes and explanations since v1: - The first patch defines of_is_system_power_controller which is compatible with both vendor,system-power-controller and system-power-controller properties. Also, It keeps the old helper function of_system_has_poweroff_source for source compatibility until everything is renamed (in this way, bisections are not broken and change is made atomically between each commit) Note: the property poweroff-source itself is not used in dts files yet. Before this patch tps65910 was broken due to missing backward compatibility with vendor,system-power-controller. As the old helper uses the new one, it works again. - act8865 and tps65910 are ported to the new helper function - The last commit removes the olf helper which was only used for source compatibility Romain Perier (4): of: Rename poweroff-source property to system-power-controller regulator: act8865: Convert poweroff-source DT property to system-power-controller mfd: tps65910: Convert poweroff-source DT property to system-power-controller of: Remove of_system_has_poweroff_source helper function .../devicetree/bindings/power/power-controller.txt | 18 .../devicetree/bindings/power/poweroff.txt | 18 .../bindings/regulator/act8865-regulator.txt | 4 +-- drivers/mfd/tps65910.c | 2 +- drivers/of/base.c | 34 ++ drivers/regulator/act8865-regulator.c | 2 +- include/linux/of.h | 12 ++-- 7 files changed, 58 insertions(+), 32 deletions(-) create mode 100644 Documentation/devicetree/bindings/power/power-controller.txt delete mode 100644 Documentation/devicetree/bindings/power/poweroff.txt -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] mfd: tps65910: Convert poweroff-source DT property to system-power-controller
Signed-off-by: Romain Perier romain.per...@gmail.com --- drivers/mfd/tps65910.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/tps65910.c b/drivers/mfd/tps65910.c index b8dca8a..77a7f78 100644 --- a/drivers/mfd/tps65910.c +++ b/drivers/mfd/tps65910.c @@ -423,7 +423,7 @@ static struct tps65910_board *tps65910_parse_dt(struct i2c_client *client, board_info-irq = client-irq; board_info-irq_base = -1; - board_info-pm_off = of_system_has_poweroff_source(np); + board_info-pm_off = of_is_system_power_controller(np); return board_info; } -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 4/4] of: Remove of_system_has_poweroff_source helper function
It was only used as backward compatibility to avoid broken
bisections, until all dependent drivers use the new helper
function.
Signed-off-by: Romain Perier romain.per...@gmail.com
---
include/linux/of.h | 4
1 file changed, 4 deletions(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index e7177b3..229798b 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -912,9 +912,5 @@ extern int of_resolve_phandles(struct device_node *tree);
bool of_is_system_power_controller(const struct device_node *np);
-static inline bool of_system_has_poweroff_source(const struct device_node *np)
-{
- return of_is_system_power_controller(np);
-}
#endif /* _LINUX_OF_H */
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] of: Rename poweroff-source property to system-power-controller
As discussed on the mailing list, it makes more sense to rename this property
to system-power-controller. Problem being that the word source usually tends
to be used for inputs and that is out of control of the OS. The poweroff
capability is an output which simply turns the system-power off. Also, this
property might be used by drivers which power-off the system and power back on
subsequent RTC alarms. This seems to suggest to remove poweroff from the
property name and to choose system-power-controller as the more generic name.
This patchs adds the required renaming changes and defines an helper function
which is compatible with both properties, the old one prefixed by a vendor name
and the new one without any prefix.
Signed-off-by: Romain Perier romain.per...@gmail.com
---
.../devicetree/bindings/power/power-controller.txt | 18
.../devicetree/bindings/power/poweroff.txt | 18
drivers/of/base.c | 34 ++
include/linux/of.h | 10 ++-
4 files changed, 55 insertions(+), 25 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/power-controller.txt
delete mode 100644 Documentation/devicetree/bindings/power/poweroff.txt
diff --git a/Documentation/devicetree/bindings/power/power-controller.txt
b/Documentation/devicetree/bindings/power/power-controller.txt
new file mode 100644
index 000..942f955
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/power-controller.txt
@@ -0,0 +1,18 @@
+* Generic system power control capability
+
+Power-management integrated circuits or miscellaneous harware components are
+sometimes able to control the system power. The device driver associated to
these
+components might needs to define this capability, which tells to the kernel how
+to switch off the system. The corresponding driver must have the standard
+property system-power-controller in its device node. This property marks the
+device as able to controller the system-power. In order to test if this
property
+is found programmatically, use the helper function
of_is_system_power_controller
+from of.h .
+
+Example:
+
+act8846: act8846@5 {
+compatible = active-semi,act8846;
+status = okay;
+system-power-controller;
+}
diff --git a/Documentation/devicetree/bindings/power/poweroff.txt
b/Documentation/devicetree/bindings/power/poweroff.txt
deleted file mode 100644
index 845868b..000
--- a/Documentation/devicetree/bindings/power/poweroff.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-* Generic Poweroff capability
-
-Power-management integrated circuits or miscellaneous harware components are
-sometimes able to control the system power. The device driver associated to
these
-components might needs to define poweroff capability, which tells to the kernel
-how to switch off the system. The corresponding driver must have the standard
-property poweroff-source in its device node. This property marks the device
as
-able to shutdown the system. In order to test if this property is found
-programmatically, use the helper function of_system_has_poweroff_source from
-of.h .
-
-Example:
-
-act8846: act8846@5 {
-compatible = active-semi,act8846;
-status = okay;
-poweroff-source;
-}
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 74ab1b8..438e405 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2260,3 +2260,37 @@ struct device_node *of_graph_get_remote_port(const
struct device_node *node)
return of_get_next_parent(np);
}
EXPORT_SYMBOL(of_graph_get_remote_port);
+
+/**
+ * of_is_system_power_controller() - Tells if the property for controlling
system
+ * power is found in device_node.
+ * @np: Pointer to the given device_node
+ *
+ * Return: true if present false otherwise
+ */
+bool of_is_system_power_controller(const struct device_node *np)
+{
+ struct property *pp;
+ unsigned long flags;
+ char *sep;
+ bool found = false;
+
+ raw_spin_lock_irqsave(devtree_lock, flags);
+ for_each_property_of_node(np, pp) {
+ if (of_prop_cmp(pp-name, system-power-controller) == 0) {
+ found = true;
+ break;
+ }
+ /* Backward compatibility with previous property
vendor,system-power-controller,
+* we just check that an non-empty vendor-prefix exists here
+*/
+ sep = strchr(pp-name, ',');
+ if (sep sep - pp-name of_prop_cmp(sep + 1,
system-power-controller) == 0) {
+ found = true;
+ break;
+ }
+ }
+ raw_spin_unlock_irqrestore(devtree_lock, flags);
+ return found;
+}
+EXPORT_SYMBOL(of_is_system_power_controller);
diff --git a/include/linux/of.h b/include/linux/of.h
index 868fdad..e7177b3 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -910,15 +910,11 @@ static
Re: [PATCH 04/11] irqchip: Remove ARM dependency for bcm7120-l2 and brcmstb-l2
On Tuesday 28 October 2014 20:58:51 Kevin Cernekee wrote: This can compile for MIPS (or anything else) now. Signed-off-by: Kevin Cernekee cerne...@gmail.com It's a silent symbol, so the dependency is obviously not needed, Acked-by: Arnd Bergmann a...@arndb.de -- 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 v8 7/8] of: spi: Export single device registration method and accessors
Hello Pantelis,
I've pointed to this already, but anyway:
On 28/10/14 21:36, ext Pantelis Antoniou wrote:
Dynamically inserting spi device nodes requires the use of a single
device registration method. Rework and export it.
Methods to lookup a device/master using a device node are added
as well, of_find_spi_master_by_node() of_find_spi_device_by_node().
Signed-off-by: Pantelis Antoniou pantelis.anton...@konsulko.com
---
drivers/spi/spi.c | 256
+-
1 file changed, 158 insertions(+), 98 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index ebcb33d..f81d799 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1220,6 +1220,123 @@ err_init_queue:
/*-*/
#if defined(CONFIG_OF)
+
+static struct spi_device *
+of_register_spi_device(struct spi_master *master, struct device_node *node)
During the test Wladislav has found that node is actually not used,
+{
+ struct spi_device *spi;
+ struct device_node *nc;
but non-initialized nc is used further in the code.
Should not nc be a parameter of the function instead of a local variable?
+ int rc;
+ u32 value;
+
+ /* Alloc an spi_device */
+ spi = spi_alloc_device(master);
+ if (!spi) {
+ dev_err(master-dev, spi_device alloc error for %s\n,
+ nc-full_name);
+ rc = -ENOMEM;
+ goto err_out;
+ }
+
+ /* Select device driver */
+ rc = of_modalias_node(nc, spi-modalias,
+ sizeof(spi-modalias));
+ if (rc 0) {
+ dev_err(master-dev, cannot find modalias for %s\n,
+ nc-full_name);
+ goto err_out;
+ }
+
+ /* Device address */
+ rc = of_property_read_u32(nc, reg, value);
+ if (rc) {
+ dev_err(master-dev, %s has no valid 'reg' property (%d)\n,
+ nc-full_name, rc);
+ goto err_out;
+ }
+ spi-chip_select = value;
+
+ /* Mode (clock phase/polarity/etc.) */
+ if (of_find_property(nc, spi-cpha, NULL))
+ spi-mode |= SPI_CPHA;
+ if (of_find_property(nc, spi-cpol, NULL))
+ spi-mode |= SPI_CPOL;
+ if (of_find_property(nc, spi-cs-high, NULL))
+ spi-mode |= SPI_CS_HIGH;
+ if (of_find_property(nc, spi-3wire, NULL))
+ spi-mode |= SPI_3WIRE;
+ if (of_find_property(nc, spi-lsb-first, NULL))
+ spi-mode |= SPI_LSB_FIRST;
+
+ /* Device DUAL/QUAD mode */
+ if (!of_property_read_u32(nc, spi-tx-bus-width, value)) {
+ switch (value) {
+ case 1:
+ break;
+ case 2:
+ spi-mode |= SPI_TX_DUAL;
+ break;
+ case 4:
+ spi-mode |= SPI_TX_QUAD;
+ break;
+ default:
+ dev_warn(master-dev,
+ spi-tx-bus-width %d not supported\n,
+ value);
+ break;
+ }
+ }
+
+ if (!of_property_read_u32(nc, spi-rx-bus-width, value)) {
+ switch (value) {
+ case 1:
+ break;
+ case 2:
+ spi-mode |= SPI_RX_DUAL;
+ break;
+ case 4:
+ spi-mode |= SPI_RX_QUAD;
+ break;
+ default:
+ dev_warn(master-dev,
+ spi-rx-bus-width %d not supported\n,
+ value);
+ break;
+ }
+ }
+
+ /* Device speed */
+ rc = of_property_read_u32(nc, spi-max-frequency, value);
+ if (rc) {
+ dev_err(master-dev, %s has no valid 'spi-max-frequency'
property (%d)\n,
+ nc-full_name, rc);
+ goto err_out;
+ }
+ spi-max_speed_hz = value;
+
+ /* IRQ */
+ spi-irq = irq_of_parse_and_map(nc, 0);
+
+ /* Store a pointer to the node in the device structure */
+ of_node_get(nc);
+ spi-dev.of_node = nc;
+
+ /* Register the new device */
+ request_module(%s%s, SPI_MODULE_PREFIX, spi-modalias);
+ rc = spi_add_device(spi);
+ if (rc) {
+ dev_err(master-dev, spi_device register error %s\n,
+ nc-full_name);
+ goto err_out;
+ }
+
+ return spi;
+
+err_out:
+ spi_dev_put(spi);
+ return ERR_PTR(rc);
+}
+
/**
* of_register_spi_devices() - Register child devices onto the SPI bus
* @master: Pointer to spi_master device
@@ -1229,120 +1346,63 @@ err_init_queue:
*/
static void of_register_spi_devices(struct spi_master *master)
{
- struct spi_device *spi;
struct
Re: [PATCH 05/11] irqchip: bcm7120-l2: Make sure all register accesses use base+offset
On Tuesday 28 October 2014 20:58:52 Kevin Cernekee wrote:
irq_gc_lock(gc);
/* Save the current mask and the interrupt forward mask */
- b-saved_mask = __raw_readl(b-base) | b-irq_fwd_mask;
+ b-saved_mask = __raw_readl(b-base + IRQEN) | b-irq_fwd_mask;
if (b-can_wake) {
reg = b-saved_mask | gc-wake_active;
- __raw_writel(reg, b-base);
+ __raw_writel(reg, b-base + IRQEN);
}
irq_gc_unlock(gc);
}
@@ -81,7 +81,7 @@ static void bcm7120_l2_intc_resume(struct irq_data *d)
/* Restore the saved mask */
irq_gc_lock(gc);
- __raw_writel(b-saved_mask, b-base);
+ __raw_writel(b-saved_mask, b-base + IRQEN);
irq_gc_unlock(gc);
You should really change this one too, to use fixed-endian accessors.
__raw_writel can't safely be used in drivers, and it will break
big-endian kernels running on ARM BRCMSTB.
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 06/11] irqchip: bcm7120-l2: Use irq_reg_* accessors
On Tuesday 28 October 2014 20:58:53 Kevin Cernekee wrote: This keeps things consistent between the core bcm7120-l2 driver and the helpers in generic-chip.c. Signed-off-by: Kevin Cernekee cerne...@gmail.com --- Ah, you did. Nevermind my comment to patch 5 then ;-) Acked-by: Arnd Bergmann a...@arndb.de -- 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 08/11] irqchip: bcm7120-l2: Fix missing nibble in gc-unused mask
On Tuesday 28 October 2014 20:58:55 Kevin Cernekee wrote: This mask should have been 0x_, not 0x0fff_. The change should not have an effect on current users (STB) because bits 31:27 are unused. Signed-off-by: Kevin Cernekee cerne...@gmail.com Acked-by: Arnd Bergmann a...@arndb.de -- 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 07/11] irqchip: brcmstb-l2: Use irq_reg_* accessors
On Tuesday 28 October 2014 20:58:54 Kevin Cernekee wrote: This change was just made on bcm7120-l2, so let's keep things consistent between the two drivers. Signed-off-by: Kevin Cernekee cerne...@gmail.com Acked-by: Arnd Bergmann a...@arndb.de -- 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 10/11] irqchip: bcm7120-l2: Extend driver to support 64+ bit controllers
On Tuesday 28 October 2014 20:58:57 Kevin Cernekee wrote: Most implementations of the bcm7120-l2 controller only have a single 32-bit enable word + 32-bit status word. But some instances have added more enable/status pairs in order to support 64+ IRQs (which are all ORed into one parent IRQ input). Make the following changes to allow the driver to support this: - Extend DT bindings so that multiple words can be specified for the reg property, various masks, etc. - Add loops to the probe/handle functions to deal with each word separately - Allocate 1 generic-chip for every 32 IRQs, so we can still use the clr/set helper functions - Update the documentation Signed-off-by: Kevin Cernekee cerne...@gmail.com You should probably specify a 'big-endian' DT property for the driver to check. If you have both LE and BE versions of this device, we must make sure that we use the correct accessors. As long as we don't need to build a kernel that supports both (if I understand you correctly, the ARM SoCs use a LE instance of this device, while the MIPS SoCs use a BE version) you can still decide at compile-time which one you want, but please add the runtime check now, so if we ever get a new combination we can handle it at runtime with a more complex driver implementation. If I read your code right, you have decided to use one IRQ domain per register set, rather than one domain for all of them. I don't know which of the two ways is better here, but it would be good if you could explain in the patch description why you did it like this. 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 11/11] irqchip: Decouple bcm7120-l2 from brcmstb-l2
On Tuesday 28 October 2014 20:58:58 Kevin Cernekee wrote: Some chips, such as BCM6328, only require the former driver. Some BCM7xxx STB configurations only require the latter driver. Treat them as two separate entities, and update the mach-bcm dependencies to reflect the change. Signed-off-by: Kevin Cernekee cerne...@gmail.com Acked-by: Arnd Bergmann a...@arndb.de 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 05/11] irqchip: bcm7120-l2: Make sure all register accesses use base+offset
On Wednesday 29 October 2014 08:46:00 Arnd Bergmann wrote:
On Tuesday 28 October 2014 20:58:52 Kevin Cernekee wrote:
irq_gc_lock(gc);
/* Save the current mask and the interrupt forward mask */
- b-saved_mask = __raw_readl(b-base) | b-irq_fwd_mask;
+ b-saved_mask = __raw_readl(b-base + IRQEN) | b-irq_fwd_mask;
if (b-can_wake) {
reg = b-saved_mask | gc-wake_active;
- __raw_writel(reg, b-base);
+ __raw_writel(reg, b-base + IRQEN);
}
irq_gc_unlock(gc);
}
@@ -81,7 +81,7 @@ static void bcm7120_l2_intc_resume(struct irq_data *d)
/* Restore the saved mask */
irq_gc_lock(gc);
- __raw_writel(b-saved_mask, b-base);
+ __raw_writel(b-saved_mask, b-base + IRQEN);
irq_gc_unlock(gc);
You should really change this one too, to use fixed-endian accessors.
__raw_writel can't safely be used in drivers, and it will break
big-endian kernels running on ARM BRCMSTB.
As you already fix this in patch 6, please disregard my comment above,
your patch looks ok.
Acked-by: Arnd Bergmann a...@arndb.de
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] ARM: dts: socfpga: fpga bridges bindings docs
Hi!
On Tue, Oct 28, 2014 at 04:19:03PM -0500, atull wrote:
On Fri, 24 Oct 2014, Steffen Trumtrar wrote:
Hi!
Hi,
I see that my documentation sucks and needs cleanup. I'll try to
answer some of the flames and get a more coherent version out soon.
On Thu, Oct 23, 2014 at 06:51:06PM -0500, at...@opensource.altera.com wrote:
From: Alan Tull at...@opensource.altera.com
(...)
diff --git
a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
new file mode 100644
index 000..bc24a2e
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
@@ -0,0 +1,53 @@
+Altera FPGA/HPS Bridge Driver
+
+This driver manages a bridge between a FPGA and a host processor system
(HPS).
+User space can enable or disable the bridge by writing a 1 or a 0,
+respectively, to its enable file under bridge's entry in
+/sys/class/fpga-bridge. Typically, one disables the bridges before
+reprogramming the FPGA. Once the FPGA is reprogrammed, the bridges are
+reenabled.
+
NAK.
This is all linux specific and doesn't belong here.
Right. This stuff shouldn't be in this document. While I was squashing
patches and cleaning up for posting on the mailing list, I added a sysfs
document and forgot to clean up my DT bindings documents.
+Required properties:
+
+ - compatible : should contain one of:
+ altr,socfpga-hps2fpga-bridge
+ altr,socfpga-lwhps2fpga-bridge
+ altr,socfpga-fpga2hps-bridge
+
+ - clocks : clocks used by this module
+
+ - altr,l3-syscon : phandle of the l3 interconnect module
+
L3 shouldn't be a syscon.
L3 is actually a good candidate for syscon. Lots of registers, each one
affects a different hardware block.
Have you tried dumping the regmap in the debugfs if L3
is a syscon? Doesn't work.
Is that a bug in regmap or is that because the register in L3 that
I am actully interested in here is write-only (ugh)?
That is not a bug in regmap. It is because you only have a register at 0x4008,
than one at 0x4104, that one at 0x5008, etc (values from memory, so might
be wrong)
Of course regmap tries to read from the whole register range if specified as
syscon. Which it can't.
So, that shouldn't be a problem though, as I already cooked up a driver for
the L3 with all the ranges specified. The only thing I need to figure out
before I will post it, is how to nicely handle the WO remap register.
I think regmap might be able to handle this itself, but am not sure yet.
+Optional properties:
+ - label : name that you want this bridge to show up as under
+/sys/class/fpga-bridge. Default is brdevice# if
this is
+not specified.
+
Why? Linux-specific.
That was a convience for the user. I can take that out and won't miss it.
+ - init-val : 0 if driver should disable bridge at startup
+1 if driver should enable bridge at startup
+driver leaves bridge in current state if property not
+specified.
+
Configuration in the DT? Really?
+Example:
+ hps_fpgabridge0: fpgabridge@0 {
+ compatible = altr,socfpga-hps2fpga-bridge;
+ label = hps2fpga;
+ altr,l3-syscon = l3regs;
+ clocks = l4_main_clk;
+ init-val = 1;
+ };
+
+ hps_fpgabridge1: fpgabridge@1 {
+ compatible = altr,socfpga-lwhps2fpga-bridge;
+ label = lwhps2fpga;
+ altr,l3-syscon = l3regs;
+ clocks = l4_main_clk;
+ init-val = 0;
+ };
+
+ hps_fpgabridge2: fpgabridge@2 {
+ compatible = altr,socfpga-fpga2hps-bridge;
+ label = fpga2hps;
+ altr,l3-syscon = l3regs;
+ clocks = l4_main_clk;
+ };
The bridges are the buses into the FPGA. This has to be accomodated.
The bridges have two specified memory ranges: one the address space
of the bus, the second the register space for configuration.
This binding does NOT correctly describe the hardware. Sorry.
OK that was outdated. More cleanup needed. How about this type of
binding? Here's an actual use case for something that has multiple
pieces of soft IP in the FPGA (sysid, gpio). I eliminated a few.
*snippet of DT*
sopc@0 {
device_type = soc;
ranges;
#address-cells = 0x1;
#size-cells = 0x1;
compatible = ALTR,avalon, simple-bus;
bus-frequency = 0x0;
bridge@0xc000 {
compatible = altr,bridge-14.0, simple-bus;
reg = 0xc000 0x2000 0xff20 0x20;
reg-names = axi_h2f, axi_h2f_lw;
clocks = 0x2 0x2 0x2;
Re: [PATCH V3 0/4] MIPS: GIC device-tree support
On Tuesday 28 October 2014 17:12:38 Andrew Bresticker wrote: This series add support for mapping and routing GIC interrupts as well as setting up the GIC timer through device-tree. Patches 1 adds the mti vendor prefix, patch 2 adds the GIC binding document, and patches 3 and 4 add device-tree support for the GIC irqchip and clocksource drivers, respectively. Based on next-20141028, which includes part 1 [0] and part 2 [1] of my GIC cleanup series. Looks all good to me, Acked-by: Arnd Bergmann a...@arndb.de -- 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] Documentation: gpio: guidelines for bindings
Now that ACPI supports named GPIO properties, either through ACPI 5.1 or
the per-driver ACPI GPIO mappings, we can be more narrow about the way
GPIOs should be specified in Device Tree bindings.
This patch updates the GPIO DT bindings documentation to highlight the
following rules for new GPIO bindings:
- All new bindings must have a meaningful name (e.g. the gpios
property must not be used)
- The only suffix allowed is -gpios, no matter the number of
descriptors in the property
- GPIOs can only be grouped under the same property when they serve the
same purpose, a case that should remain exceptional (e.g. bit-banged
data lines).
Signed-off-by: Alexandre Courbot acour...@nvidia.com
CC: Linus Walleij linus.wall...@linaro.org
CC: Arnd Bergmann a...@arndb.de
CC: Rafael J. Wysocki r...@rjwysocki.net
CC: Mika Westerberg mika.westerb...@linux.intel.com
---
Changes since v1:
- Rewritten in OS-neutral manner.
Documentation/devicetree/bindings/gpio/gpio.txt | 40 -
1 file changed, 26 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt
b/Documentation/devicetree/bindings/gpio/gpio.txt
index 3fb8f53071b8..b9bd1d64cfa6 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -13,13 +13,22 @@ properties, each containing a 'gpio-list':
gpio-specifier : Array of #gpio-cells specifying specific gpio
(controller specific)
-GPIO properties should be named [name-]gpios. The exact
-meaning of each gpios property must be documented in the device tree
-binding for each device.
+GPIO properties should be named [name-]gpios, with name being the purpose
+of this GPIO for the device. While a non-existent name is considered valid
+for compatibility reasons (resolving to the gpios property), it is not
allowed
+for new bindings.
-For example, the following could be used to describe GPIO pins used
-as chip select lines; with chip selects 0, 1 and 3 populated, and chip
-select 2 left empty:
+GPIO properties can contain one or more GPIO phandles, but only in exceptional
+cases should they contain more than one. If your device uses several GPIOs with
+distinct functions, reference each of them under its own property, giving it a
+meaningful name. The only case where an array of GPIOs is accepted is when
+several GPIOs serve the same function (e.g. a parallel data line).
+
+The exact purpose of each gpios property must be documented in the device tree
+binding of the device.
+
+The following example could be used to describe GPIO pins used as device enable
+and bit-banged data signals:
gpio1: gpio1 {
gpio-controller
@@ -30,10 +39,12 @@ select 2 left empty:
#gpio-cells = 1;
};
[...]
-chipsel-gpios = gpio1 12 0,
-gpio1 13 0,
-0, /* holes are permitted, means no GPIO 2 */
-gpio2 2;
+
+ enable-gpios = gpio2 2;
+ data-gpios = gpio1 12 0,
+gpio1 13 0,
+gpio1 14 0,
+gpio1 15 0;
Note that gpio-specifier length is controller dependent. In the
above example, gpio1 uses 2 cells to specify a gpio, while gpio2
@@ -42,16 +53,17 @@ only uses one.
gpio-specifier may encode: bank, pin position inside the bank,
whether pin is open-drain and whether pin is logically inverted.
Exact meaning of each specifier cell is controller specific, and must
-be documented in the device tree binding for the device.
+be documented in the device tree binding for the device. Use the macros
+defined in include/dt-bindings/gpio/gpio.h whenever possible:
Example of a node using GPIOs:
node {
- gpios = qe_pio_e 18 0;
+ enable-gpios = qe_pio_e 18 GPIO_ACTIVE_HIGH;
};
-In this example gpio-specifier is 18 0 and encodes GPIO pin number,
-and GPIO flags as accepted by the qe_pio_e gpio-controller.
+GPIO_ACTIVE_HIGH is 0, so in this example gpio-specifier is 18 0 and encodes
+GPIO pin number, and GPIO flags as accepted by the qe_pio_e gpio-controller.
1.1) GPIO specifier best practices
--
--
2.1.2
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 7/8] of: spi: Export single device registration method and accessors
Hi Alexander,
On Oct 29, 2014, at 09:44 , Alexander Sverdlin alexander.sverd...@nsn.com
wrote:
Hello Pantelis,
I've pointed to this already, but anyway:
On 28/10/14 21:36, ext Pantelis Antoniou wrote:
Dynamically inserting spi device nodes requires the use of a single
device registration method. Rework and export it.
Methods to lookup a device/master using a device node are added
as well, of_find_spi_master_by_node() of_find_spi_device_by_node().
Signed-off-by: Pantelis Antoniou pantelis.anton...@konsulko.com
---
drivers/spi/spi.c | 256
+-
1 file changed, 158 insertions(+), 98 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index ebcb33d..f81d799 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1220,6 +1220,123 @@ err_init_queue:
/*-*/
#if defined(CONFIG_OF)
+
+static struct spi_device *
+of_register_spi_device(struct spi_master *master, struct device_node *node)
During the test Wladislav has found that node is actually not used,
Ugh.
+{
+struct spi_device *spi;
+struct device_node *nc;
but non-initialized nc is used further in the code.
Should not nc be a parameter of the function instead of a local variable?
Yes, my mistake. Updated patch follows.
+int rc;
+u32 value;
+
+/* Alloc an spi_device */
+spi = spi_alloc_device(master);
+if (!spi) {
+dev_err(master-dev, spi_device alloc error for %s\n,
+nc-full_name);
+rc = -ENOMEM;
+goto err_out;
+}
+
+/* Select device driver */
+rc = of_modalias_node(nc, spi-modalias,
+sizeof(spi-modalias));
+if (rc 0) {
+dev_err(master-dev, cannot find modalias for %s\n,
+nc-full_name);
+goto err_out;
+}
+
+/* Device address */
+rc = of_property_read_u32(nc, reg, value);
+if (rc) {
+dev_err(master-dev, %s has no valid 'reg' property (%d)\n,
+nc-full_name, rc);
+goto err_out;
+}
+spi-chip_select = value;
+
+/* Mode (clock phase/polarity/etc.) */
+if (of_find_property(nc, spi-cpha, NULL))
+spi-mode |= SPI_CPHA;
+if (of_find_property(nc, spi-cpol, NULL))
+spi-mode |= SPI_CPOL;
+if (of_find_property(nc, spi-cs-high, NULL))
+spi-mode |= SPI_CS_HIGH;
+if (of_find_property(nc, spi-3wire, NULL))
+spi-mode |= SPI_3WIRE;
+if (of_find_property(nc, spi-lsb-first, NULL))
+spi-mode |= SPI_LSB_FIRST;
+
+/* Device DUAL/QUAD mode */
+if (!of_property_read_u32(nc, spi-tx-bus-width, value)) {
+switch (value) {
+case 1:
+break;
+case 2:
+spi-mode |= SPI_TX_DUAL;
+break;
+case 4:
+spi-mode |= SPI_TX_QUAD;
+break;
+default:
+dev_warn(master-dev,
+spi-tx-bus-width %d not supported\n,
+value);
+break;
+}
+}
+
+if (!of_property_read_u32(nc, spi-rx-bus-width, value)) {
+switch (value) {
+case 1:
+break;
+case 2:
+spi-mode |= SPI_RX_DUAL;
+break;
+case 4:
+spi-mode |= SPI_RX_QUAD;
+break;
+default:
+dev_warn(master-dev,
+spi-rx-bus-width %d not supported\n,
+value);
+break;
+}
+}
+
+/* Device speed */
+rc = of_property_read_u32(nc, spi-max-frequency, value);
+if (rc) {
+dev_err(master-dev, %s has no valid 'spi-max-frequency'
property (%d)\n,
+nc-full_name, rc);
+goto err_out;
+}
+spi-max_speed_hz = value;
+
+/* IRQ */
+spi-irq = irq_of_parse_and_map(nc, 0);
+
+/* Store a pointer to the node in the device structure */
+of_node_get(nc);
+spi-dev.of_node = nc;
+
+/* Register the new device */
+request_module(%s%s, SPI_MODULE_PREFIX, spi-modalias);
+rc = spi_add_device(spi);
+if (rc) {
+dev_err(master-dev, spi_device register error %s\n,
+nc-full_name);
+goto err_out;
+}
+
+return spi;
+
+err_out:
+spi_dev_put(spi);
+return ERR_PTR(rc);
+}
+
/**
* of_register_spi_devices() - Register child devices onto the SPI bus
* @master: Pointer to spi_master device
@@ -1229,120 +1346,63 @@ err_init_queue:
*/
static void of_register_spi_devices(struct spi_master *master)
Re: [PATCH v2 2/3] ARM: dts: socfpga: fpga bridges bindings docs
Hi! +Optional properties: + - label : name that you want this bridge to show up as under +/sys/class/fpga-bridge. Default is brdevice# if this is +not specified. + Why? Linux-specific. That was a convience for the user. I can take that out and won't miss it. Actually make it - label : optional user-readable name for this bridge ...and it is no longer Linux-specific, and you can keep it if it is otherwise useful... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] add sysfs document for fpga bridges
On Fri 2014-10-24 10:11:26, atull wrote: On Fri, 24 Oct 2014, Pavel Machek wrote: On Thu 2014-10-23 18:51:05, at...@opensource.altera.com wrote: From: Alan Tull at...@opensource.altera.com Add sysfs document for fpga bridges. --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-fpga-bridge @@ -0,0 +1,5 @@ +What:/sys/class/fpga-bridge/bridge/enable +Date:October 2014 +KernelVersion: 3.18 +Contact: Alan Tull at...@opensource.altera.com +Description: Enable bridge. Write 1 to bring bridge out of reset. Specify, what happens when 0 is written there? Yes, I will add: 'Write 0 has no effect.' Definitely add it, then. The way it is written, I'd expect 0 to put bridge into reset. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 01/10] ARM: dts: hix5hd2: add gmac node
Signed-off-by: Zhangfei Gao zhangfei@linaro.org
---
arch/arm/boot/dts/hisi-x5hd2-dkb.dts | 28
arch/arm/boot/dts/hisi-x5hd2.dtsi| 16
2 files changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/hisi-x5hd2-dkb.dts
b/arch/arm/boot/dts/hisi-x5hd2-dkb.dts
index 05b44c2..0da3f3b 100644
--- a/arch/arm/boot/dts/hisi-x5hd2-dkb.dts
+++ b/arch/arm/boot/dts/hisi-x5hd2-dkb.dts
@@ -51,3 +51,31 @@
uart0 {
status = okay;
};
+
+gmac0 {
+ #address-cells = 1;
+ #size-cells = 0;
+ phy-handle = phy2;
+ phy-mode = mii;
+ /* Placeholder, overwritten by bootloader */
+ mac-address = [00 00 00 00 00 00];
+ status = okay;
+
+ phy2: ethernet-phy@2 {
+ reg = 2;
+ };
+};
+
+gmac1 {
+ #address-cells = 1;
+ #size-cells = 0;
+ phy-handle = phy1;
+ phy-mode = rgmii;
+ /* Placeholder, overwritten by bootloader */
+ mac-address = [00 00 00 00 00 00];
+ status = okay;
+
+ phy1: ethernet-phy@1 {
+ reg = 1;
+ };
+};
diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi
b/arch/arm/boot/dts/hisi-x5hd2.dtsi
index f85ba29..012525c 100644
--- a/arch/arm/boot/dts/hisi-x5hd2.dtsi
+++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi
@@ -166,5 +166,21 @@
#clock-cells = 1;
};
};
+
+ gmac0: ethernet@184 {
+ compatible = hisilicon,hix5hd2-gmac;
+ reg = 0x184 0x1000,0x184300c 0x4;
+ interrupts = 0 71 4;
+ clocks = clock HIX5HD2_MAC0_CLK;
+ status = disabled;
+ };
+
+ gmac1: ethernet@1841000 {
+ compatible = hisilicon,hix5hd2-gmac;
+ reg = 0x1841000 0x1000,0x1843010 0x4;
+ interrupts = 0 72 4;
+ clocks = clock HIX5HD2_MAC1_CLK;
+ status = disabled;
+ };
};
};
--
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 v4 07/10] ARM: dts: hix5hd2: add ir node
Signed-off-by: Zhangfei Gao zhangfei@linaro.org
---
arch/arm/boot/dts/hisi-x5hd2.dtsi | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi
b/arch/arm/boot/dts/hisi-x5hd2.dtsi
index d07589b..576d8c2 100644
--- a/arch/arm/boot/dts/hisi-x5hd2.dtsi
+++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi
@@ -391,7 +391,7 @@
};
sysctrl: system-controller@ {
- compatible = hisilicon,sysctrl;
+ compatible = hisilicon,sysctrl, syscon;
reg = 0x 0x1000;
reboot-offset = 0x4;
};
@@ -478,5 +478,13 @@
interrupts = 0 70 4;
clocks = clock HIX5HD2_SATA_CLK;
};
+
+ ir: ir@001000 {
+ compatible = hisilicon,hix5hd2-ir;
+ reg = 0x001000 0x1000;
+ interrupts = 0 47 4;
+ clocks = clock HIX5HD2_FIXED_24M;
+ hisilicon,power-syscon = sysctrl;
+ };
};
};
--
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 v4 05/10] ARM: dts: hix5hd2: add gpio node
Signed-off-by: Jiancheng Xue xuejianch...@huawei.com
Signed-off-by: Zhangfei Gao zhangfei@linaro.org
---
arch/arm/boot/dts/hisi-x5hd2.dtsi | 234 +
1 file changed, 234 insertions(+)
diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi
b/arch/arm/boot/dts/hisi-x5hd2.dtsi
index d5b3a8f..7f1a3e0 100644
--- a/arch/arm/boot/dts/hisi-x5hd2.dtsi
+++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi
@@ -131,6 +131,240 @@
clock-names = apb_pclk;
status = disabled;
};
+
+ gpio0: gpio@b2 {
+ compatible = arm,pl061, arm,primecell;
+ reg = 0xb2 0x1000;
+ interrupts = 0 108 0x4;
+ gpio-controller;
+ #gpio-cells = 2;
+ clocks = clock HIX5HD2_FIXED_100M;
+ clock-names = apb_pclk;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ status = disabled;
+ };
+
+ gpio1: gpio@b21000 {
+ compatible = arm,pl061, arm,primecell;
+ reg = 0xb21000 0x1000;
+ interrupts = 0 109 0x4;
+ gpio-controller;
+ #gpio-cells = 2;
+ clocks = clock HIX5HD2_FIXED_100M;
+ clock-names = apb_pclk;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ status = disabled;
+ };
+
+ gpio2: gpio@b22000 {
+ compatible = arm,pl061, arm,primecell;
+ reg = 0xb22000 0x1000;
+ interrupts = 0 110 0x4;
+ gpio-controller;
+ #gpio-cells = 2;
+ clocks = clock HIX5HD2_FIXED_100M;
+ clock-names = apb_pclk;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ status = disabled;
+ };
+
+ gpio3: gpio@b23000 {
+ compatible = arm,pl061, arm,primecell;
+ reg = 0xb23000 0x1000;
+ interrupts = 0 111 0x4;
+ gpio-controller;
+ #gpio-cells = 2;
+ clocks = clock HIX5HD2_FIXED_100M;
+ clock-names = apb_pclk;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ status = disabled;
+ };
+
+ gpio4: gpio@b24000 {
+ compatible = arm,pl061, arm,primecell;
+ reg = 0xb24000 0x1000;
+ interrupts = 0 112 0x4;
+ gpio-controller;
+ #gpio-cells = 2;
+ clocks = clock HIX5HD2_FIXED_100M;
+ clock-names = apb_pclk;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ status = disabled;
+ };
+
+ gpio5: gpio@004000 {
+ compatible = arm,pl061, arm,primecell;
+ reg = 0x004000 0x1000;
+ interrupts = 0 113 0x4;
+ gpio-controller;
+ #gpio-cells = 2;
+ clocks = clock HIX5HD2_FIXED_100M;
+ clock-names = apb_pclk;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ status = disabled;
+ };
+
+ gpio6: gpio@b26000 {
+ compatible = arm,pl061, arm,primecell;
+ reg = 0xb26000 0x1000;
+ interrupts = 0 114 0x4;
+ gpio-controller;
+ #gpio-cells = 2;
+ clocks = clock HIX5HD2_FIXED_100M;
+ clock-names = apb_pclk;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ status =
[PATCH v4 00/10] hix5hd2 add some nodes
v4: Rebase on 3.18-rc1 Update hisi_defconfig, adding some drivers for hix5hd2 Reuse syscon-reboot for reboot, drivers/power/reset/syscon-reboot.c Test hisi_defconfig on hix5hd2, d01 and k3v2 v3: Change node wdt for a watchdog timer as comment from Dinh v2: Add comments of mac-address, suggested by Mark Zhangfei Gao (10): ARM: dts: hix5hd2: add gmac node ARM: dts: hix5hd2: add mmc node ARM: dts: hix5hd2: add usb node ARM: dts: hix5hd2: add sata node ARM: dts: hix5hd2: add gpio node ARM: dts: hix5hd2: add wdg node ARM: dts: hix5hd2: add ir node ARM: dts: hix5hd2: add i2c node ARM: dts: hix5hd2: add reboot node ARM: hisi_defconfig: add driver support for hix5hd2 arch/arm/boot/dts/hisi-x5hd2-dkb.dts | 33 +++ arch/arm/boot/dts/hisi-x5hd2.dtsi| 390 +- arch/arm/configs/hisi_defconfig | 19 ++ 3 files changed, 440 insertions(+), 2 deletions(-) -- 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 v4 08/10] ARM: dts: hix5hd2: add i2c node
Signed-off-by: Zhangfei Gao zhangfei@linaro.org
---
arch/arm/boot/dts/hisi-x5hd2.dtsi | 60 +
1 file changed, 60 insertions(+)
diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi
b/arch/arm/boot/dts/hisi-x5hd2.dtsi
index 576d8c2..b8deb6c 100644
--- a/arch/arm/boot/dts/hisi-x5hd2.dtsi
+++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi
@@ -486,5 +486,65 @@
clocks = clock HIX5HD2_FIXED_24M;
hisilicon,power-syscon = sysctrl;
};
+
+ i2c0: i2c@b1 {
+ compatible = hisilicon,hix5hd2-i2c;
+ reg = 0xb1 0x1000;
+ interrupts = 0 38 4;
+ clocks = clock HIX5HD2_I2C0_RST;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ };
+
+ i2c1: i2c@b11000 {
+ compatible = hisilicon,hix5hd2-i2c;
+ reg = 0xb11000 0x1000;
+ interrupts = 0 39 4;
+ clocks = clock HIX5HD2_I2C1_RST;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ };
+
+ i2c2: i2c@b12000 {
+ compatible = hisilicon,hix5hd2-i2c;
+ reg = 0xb12000 0x1000;
+ interrupts = 0 40 4;
+ clocks = clock HIX5HD2_I2C2_RST;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ };
+
+ i2c3: i2c@b13000 {
+ compatible = hisilicon,hix5hd2-i2c;
+ reg = 0xb13000 0x1000;
+ interrupts = 0 41 4;
+ clocks = clock HIX5HD2_I2C3_RST;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ };
+
+ i2c4: i2c@b16000 {
+ compatible = hisilicon,hix5hd2-i2c;
+ reg = 0xb16000 0x1000;
+ interrupts = 0 43 4;
+ clocks = clock HIX5HD2_I2C4_RST;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ };
+
+ i2c5: i2c@b17000 {
+ compatible = hisilicon,hix5hd2-i2c;
+ reg = 0xb17000 0x1000;
+ interrupts = 0 44 4;
+ clocks = clock HIX5HD2_I2C5_RST;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ };
};
};
--
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 v4 03/10] ARM: dts: hix5hd2: add usb node
Signed-off-by: Zhangfei Gao zhangfei@linaro.org
Signed-off-by: Jiancheng Xue xuejianch...@huawei.com
---
arch/arm/boot/dts/hisi-x5hd2.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi
b/arch/arm/boot/dts/hisi-x5hd2.dtsi
index fea5d5c..4f9e8a3 100644
--- a/arch/arm/boot/dts/hisi-x5hd2.dtsi
+++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi
@@ -201,5 +201,19 @@
clocks = clock HIX5HD2_MAC1_CLK;
status = disabled;
};
+
+ usb0: ehci@189 {
+ compatible = generic-ehci;
+ reg = 0x189 0x1000;
+ interrupts = 0 66 4;
+ clocks = clock HIX5HD2_USB_CLK;
+ };
+
+ usb1: ohci@188 {
+ compatible = generic-ohci;
+ reg = 0x188 0x1000;
+ interrupts = 0 67 4;
+ clocks = clock HIX5HD2_USB_CLK;
+ };
};
};
--
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 v4 04/10] ARM: dts: hix5hd2: add sata node
Signed-off-by: Jiancheng Xue xuejianch...@huawei.com
Signed-off-by: Zhangfei Gao zhangfei@linaro.org
---
arch/arm/boot/dts/hisi-x5hd2-dkb.dts |5 +
arch/arm/boot/dts/hisi-x5hd2.dtsi| 20
2 files changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/hisi-x5hd2-dkb.dts
b/arch/arm/boot/dts/hisi-x5hd2-dkb.dts
index 0da3f3b..721b092 100644
--- a/arch/arm/boot/dts/hisi-x5hd2-dkb.dts
+++ b/arch/arm/boot/dts/hisi-x5hd2-dkb.dts
@@ -79,3 +79,8 @@
reg = 1;
};
};
+
+ahci {
+ phys = sata_phy;
+ phy-names = sata-phy;
+};
diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi
b/arch/arm/boot/dts/hisi-x5hd2.dtsi
index 4f9e8a3..d5b3a8f 100644
--- a/arch/arm/boot/dts/hisi-x5hd2.dtsi
+++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi
@@ -215,5 +215,25 @@
interrupts = 0 67 4;
clocks = clock HIX5HD2_USB_CLK;
};
+
+ peripheral_ctrl: syscon@a2 {
+ compatible = syscon;
+ reg = 0xa2 0x1000;
+ };
+
+ sata_phy: phy@190 {
+ compatible = hisilicon,hix5hd2-sata-phy;
+ reg = 0x190 0x1;
+ #phy-cells = 0;
+ hisilicon,peripheral-syscon = peripheral_ctrl;
+ hisilicon,power-reg = 0x8 10;
+ };
+
+ ahci: sata@190 {
+ compatible = hisilicon,hisi-ahci;
+ reg = 0x190 0x1;
+ interrupts = 0 70 4;
+ clocks = clock HIX5HD2_SATA_CLK;
+ };
};
};
--
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 v4 02/10] ARM: dts: hix5hd2: add mmc node
Signed-off-by: Zhangfei Gao zhangfei@linaro.org
---
arch/arm/boot/dts/hisi-x5hd2.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi
b/arch/arm/boot/dts/hisi-x5hd2.dtsi
index 012525c..fea5d5c 100644
--- a/arch/arm/boot/dts/hisi-x5hd2.dtsi
+++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi
@@ -167,6 +167,25 @@
};
};
+ /* unremovable emmc as mmcblk0 */
+ mmc: mmc@183 {
+ compatible = snps,dw-mshc;
+ reg = 0x183 0x1000;
+ interrupts = 0 35 4;
+ clocks = clock HIX5HD2_MMC_CIU_RST,
+clock HIX5HD2_MMC_BIU_CLK;
+ clock-names = ciu, biu;
+ };
+
+ sd: mmc@182 {
+ compatible = snps,dw-mshc;
+ reg = 0x182 0x1000;
+ interrupts = 0 34 4;
+ clocks = clock HIX5HD2_SD_CIU_RST,
+clock HIX5HD2_SD_BIU_CLK;
+ clock-names = ciu,biu;
+ };
+
gmac0: ethernet@184 {
compatible = hisilicon,hix5hd2-gmac;
reg = 0x184 0x1000,0x184300c 0x4;
--
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 v4 06/10] ARM: dts: hix5hd2: add wdg node
Signed-off-by: Jiancheng Xue xuejianch...@huawei.com
Signed-off-by: Zhangfei Gao zhangfei@linaro.org
---
arch/arm/boot/dts/hisi-x5hd2.dtsi |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi
b/arch/arm/boot/dts/hisi-x5hd2.dtsi
index 7f1a3e0..d07589b 100644
--- a/arch/arm/boot/dts/hisi-x5hd2.dtsi
+++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi
@@ -365,6 +365,15 @@
#interrupt-cells = 2;
status = disabled;
};
+
+ wdt0: watchdog@a2c000 {
+ compatible = arm,sp805, arm,primecell;
+ arm,primecell-periphid = 0x00141805;
+ reg = 0xa2c000 0x1000;
+ interrupts = 0 29 4;
+ clocks = clock HIX5HD2_WDG0_RST;
+ clock-names = apb_pclk;
+ };
};
local_timer@00a00600 {
--
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 v4 10/10] ARM: hisi_defconfig: add driver support for hix5hd2
Signed-off-by: Zhangfei Gao zhangfei@linaro.org --- arch/arm/configs/hisi_defconfig | 19 +++ 1 file changed, 19 insertions(+) diff --git a/arch/arm/configs/hisi_defconfig b/arch/arm/configs/hisi_defconfig index 1772505..1fe3621f 100644 --- a/arch/arm/configs/hisi_defconfig +++ b/arch/arm/configs/hisi_defconfig @@ -5,6 +5,8 @@ CONFIG_BLK_DEV_INITRD=y CONFIG_RD_LZMA=y CONFIG_ARCH_HISI=y CONFIG_ARCH_HI3xxx=y +CONFIG_PARTITION_ADVANCED=y +CONFIG_CMDLINE_PARTITION=y CONFIG_ARCH_HIX5HD2=y CONFIG_ARCH_HIP04=y CONFIG_SMP=y @@ -14,8 +16,11 @@ CONFIG_AEABI=y CONFIG_HIGHMEM=y CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y +CONFIG_NEON=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y +CONFIG_PM_RUNTIME=y CONFIG_NET=y +CONFIG_PACKET=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_PNP=y @@ -26,6 +31,7 @@ CONFIG_BLK_DEV_SD=y CONFIG_ATA=y CONFIG_SATA_AHCI_PLATFORM=y CONFIG_NETDEVICES=y +CONFIG_HIX5HD2_GMAC=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y CONFIG_SERIAL_8250_CONSOLE=y @@ -39,8 +45,13 @@ CONFIG_I2C_DESIGNWARE_PLATFORM=y CONFIG_SPI=y CONFIG_SPI_PL022=y CONFIG_PINCTRL_SINGLE=y +CONFIG_DEBUG_GPIO=y +CONFIG_GPIO_SYSFS=y +CONFIG_GPIOLIB=y CONFIG_GPIO_GENERIC_PLATFORM=y CONFIG_REGULATOR_GPIO=y +CONFIG_MFD_SYSCON=y +CONFIG_POWER_RESET_SYSCON=y CONFIG_DRM=y CONFIG_FB_SIMPLE=y CONFIG_USB=y @@ -48,15 +59,21 @@ CONFIG_USB_XHCI_HCD=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_MXC=y CONFIG_USB_EHCI_HCD_PLATFORM=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_HCD_PLATFORM=y CONFIG_USB_STORAGE=y CONFIG_NOP_USB_XCEIV=y CONFIG_MMC=y CONFIG_RTC_CLASS=y +CONFIG_MMC_DW=y +CONFIG_MMC_DW_IDMAC=y +CONFIG_MMC_DW_PLTFM=y CONFIG_RTC_DRV_PL031=y CONFIG_DMADEVICES=y CONFIG_DW_DMAC=y CONFIG_PL330_DMA=y CONFIG_PWM=y +CONFIG_PHY_HIX5HD2_SATA=y CONFIG_EXT4_FS=y CONFIG_TMPFS=y CONFIG_NFS_FS=y @@ -65,6 +82,8 @@ CONFIG_NFS_V4=y CONFIG_ROOT_NFS=y CONFIG_PRINTK_TIME=y CONFIG_DEBUG_FS=y +CONFIG_NLS_CODEPAGE_437=y +CONFIG_NLS_ISO8859_1=y CONFIG_DEBUG_KERNEL=y CONFIG_LOCKUP_DETECTOR=y CONFIG_VFP=y -- 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 v4 09/10] ARM: dts: hix5hd2: add reboot node
Reuse syscon-reboot, drivers/power/reset/syscon-reboot.c
Signed-off-by: Zhangfei Gao zhangfei@linaro.org
---
arch/arm/boot/dts/hisi-x5hd2.dtsi |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/hisi-x5hd2.dtsi
b/arch/arm/boot/dts/hisi-x5hd2.dtsi
index b8deb6c..c52722b 100644
--- a/arch/arm/boot/dts/hisi-x5hd2.dtsi
+++ b/arch/arm/boot/dts/hisi-x5hd2.dtsi
@@ -393,7 +393,13 @@
sysctrl: system-controller@ {
compatible = hisilicon,sysctrl, syscon;
reg = 0x 0x1000;
- reboot-offset = 0x4;
+ };
+
+ reboot {
+ compatible = syscon-reboot;
+ regmap = sysctrl;
+ offset = 0x4;
+ mask = 0xdeadbeef;
};
cpuctrl@00a22000 {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Documentation: gpio: guidelines for bindings
On Wednesday 29 October 2014 17:13:14 Alexandre Courbot wrote: Now that ACPI supports named GPIO properties, either through ACPI 5.1 or the per-driver ACPI GPIO mappings, we can be more narrow about the way GPIOs should be specified in Device Tree bindings. This patch updates the GPIO DT bindings documentation to highlight the following rules for new GPIO bindings: - All new bindings must have a meaningful name (e.g. the gpios property must not be used) - The only suffix allowed is -gpios, no matter the number of descriptors in the property - GPIOs can only be grouped under the same property when they serve the same purpose, a case that should remain exceptional (e.g. bit-banged data lines). Signed-off-by: Alexandre Courbot acour...@nvidia.com CC: Linus Walleij linus.wall...@linaro.org CC: Arnd Bergmann a...@arndb.de CC: Rafael J. Wysocki r...@rjwysocki.net CC: Mika Westerberg mika.westerb...@linux.intel.com Acked-by: Arnd Bergmann a...@arndb.de -- 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] of: spi: Export single device registration method and accessors (v2)
Dynamically inserting spi device nodes requires the use of a single
device registration method. Rework and export it.
Methods to lookup a device/master using a device node are added
as well, of_find_spi_master_by_node() of_find_spi_device_by_node().
Changes since v1:
* Brown paper bug with parameter on of_register_spi_device().
Signed-off-by: Pantelis Antoniou pantelis.anton...@konsulko.com
---
drivers/spi/spi.c | 255 +-
1 file changed, 157 insertions(+), 98 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index ebcb33d..4778366 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1220,6 +1220,122 @@ err_init_queue:
/*-*/
#if defined(CONFIG_OF)
+
+static struct spi_device *
+of_register_spi_device(struct spi_master *master, struct device_node *nc)
+{
+ struct spi_device *spi;
+ int rc;
+ u32 value;
+
+ /* Alloc an spi_device */
+ spi = spi_alloc_device(master);
+ if (!spi) {
+ dev_err(master-dev, spi_device alloc error for %s\n,
+ nc-full_name);
+ rc = -ENOMEM;
+ goto err_out;
+ }
+
+ /* Select device driver */
+ rc = of_modalias_node(nc, spi-modalias,
+ sizeof(spi-modalias));
+ if (rc 0) {
+ dev_err(master-dev, cannot find modalias for %s\n,
+ nc-full_name);
+ goto err_out;
+ }
+
+ /* Device address */
+ rc = of_property_read_u32(nc, reg, value);
+ if (rc) {
+ dev_err(master-dev, %s has no valid 'reg' property (%d)\n,
+ nc-full_name, rc);
+ goto err_out;
+ }
+ spi-chip_select = value;
+
+ /* Mode (clock phase/polarity/etc.) */
+ if (of_find_property(nc, spi-cpha, NULL))
+ spi-mode |= SPI_CPHA;
+ if (of_find_property(nc, spi-cpol, NULL))
+ spi-mode |= SPI_CPOL;
+ if (of_find_property(nc, spi-cs-high, NULL))
+ spi-mode |= SPI_CS_HIGH;
+ if (of_find_property(nc, spi-3wire, NULL))
+ spi-mode |= SPI_3WIRE;
+ if (of_find_property(nc, spi-lsb-first, NULL))
+ spi-mode |= SPI_LSB_FIRST;
+
+ /* Device DUAL/QUAD mode */
+ if (!of_property_read_u32(nc, spi-tx-bus-width, value)) {
+ switch (value) {
+ case 1:
+ break;
+ case 2:
+ spi-mode |= SPI_TX_DUAL;
+ break;
+ case 4:
+ spi-mode |= SPI_TX_QUAD;
+ break;
+ default:
+ dev_warn(master-dev,
+ spi-tx-bus-width %d not supported\n,
+ value);
+ break;
+ }
+ }
+
+ if (!of_property_read_u32(nc, spi-rx-bus-width, value)) {
+ switch (value) {
+ case 1:
+ break;
+ case 2:
+ spi-mode |= SPI_RX_DUAL;
+ break;
+ case 4:
+ spi-mode |= SPI_RX_QUAD;
+ break;
+ default:
+ dev_warn(master-dev,
+ spi-rx-bus-width %d not supported\n,
+ value);
+ break;
+ }
+ }
+
+ /* Device speed */
+ rc = of_property_read_u32(nc, spi-max-frequency, value);
+ if (rc) {
+ dev_err(master-dev, %s has no valid 'spi-max-frequency'
property (%d)\n,
+ nc-full_name, rc);
+ goto err_out;
+ }
+ spi-max_speed_hz = value;
+
+ /* IRQ */
+ spi-irq = irq_of_parse_and_map(nc, 0);
+
+ /* Store a pointer to the node in the device structure */
+ of_node_get(nc);
+ spi-dev.of_node = nc;
+
+ /* Register the new device */
+ request_module(%s%s, SPI_MODULE_PREFIX, spi-modalias);
+ rc = spi_add_device(spi);
+ if (rc) {
+ dev_err(master-dev, spi_device register error %s\n,
+ nc-full_name);
+ goto err_out;
+ }
+
+ return spi;
+
+err_out:
+ spi_dev_put(spi);
+ return ERR_PTR(rc);
+}
+
/**
* of_register_spi_devices() - Register child devices onto the SPI bus
* @master:Pointer to spi_master device
@@ -1229,120 +1345,63 @@ err_init_queue:
*/
static void of_register_spi_devices(struct spi_master *master)
{
- struct spi_device *spi;
struct device_node *nc;
- int rc;
- u32 value;
+ struct spi_device *spi;
if (!master-dev.of_node)
return;
for_each_available_child_of_node(master-dev.of_node, nc)
Re: [RFC Patch] gpio: add GPIO hogging mechanism
Hi Benoit, On Oct 21, 2014, at 23:09 , Benoit Parrot bpar...@ti.com wrote: Based on Boris Brezillion work this is a reworked patch of his initial GPIO hogging mechanism. This patch provides a way to initally configure specific GPIO when the gpio controller is probe. The actual DT scanning to collect the GPIO specific data is performed as part of the gpiochip_add(). The purpose of this is to allows specific GPIOs to be configured without any driver specific code. This particularly usueful because board design are getting increassingly complex and given SoC pins can now have upward of 10 mux values a lot of connections are now dependent on external IO muxes to switch various modes and combination. Specific drivers should not necessarily need to be aware of what accounts to a specific board implementation. This board level description should be best kept as part of the dts file. This look like it’s going to the right direction. I have a few general comments at first. 1) It relies on dubious DT binding of having sub-nodes of the gpio device implicitly defining hogs. 2) There is no way for having hogs inserted dynamically as far as I can tell, and no way to remove a hog either. 3) I’m not very fond of having this being part of the gpio controller. This configuration conceptually has little to do with the gpio controller per se, it is more of a board specific thing. Why not come up with a gpio-hog driver that references GPIOs? That way with a single gpio-hog driver instance you could setup all the GPIO-hogging configuration for all GPIOs on the board, even one that lie on different GPIO controllers. Signed-off-by: Benoit Parrot bpar...@ti.com --- Documentation/devicetree/bindings/gpio/gpio.txt | 33 + drivers/gpio/gpiolib-of.c | 99 + drivers/gpio/gpiolib.c | 81 include/linux/of_gpio.h | 11 +++ 4 files changed, 224 insertions(+) Regards — Pantelis -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 07/12] leds: leds-gpio: Add support for GPIO descriptors
On Tue, Oct 28, 2014 at 10:56:09PM +0100, Rafael J. Wysocki wrote:
On Tuesday, October 28, 2014 04:26:25 PM Linus Walleij wrote:
On Fri, Oct 17, 2014 at 2:11 PM, Rafael J. Wysocki r...@rjwysocki.net
wrote:
From: Mika Westerberg mika.westerb...@linux.intel.com
GPIO descriptors are the preferred way over legacy GPIO numbers
nowadays. Convert the driver to use GPIO descriptors internally but
still allow passing legacy GPIO numbers from platform data to support
existing platforms.
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
Acked-by: Alexandre Courbot acour...@nvidia.com
Acked-by: Bryan Wu coolo...@gmail.com
Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
(...)
if (led_dat-blinking) {
- led_dat-platform_gpio_blink_set(led_dat-gpio,
-led_dat-new_level,
-NULL, NULL);
+ int gpio = desc_to_gpio(led_dat-gpiod);
+ int level = led_dat-new_level;
So this desc_to_gpio() is done only to call the legacy callback below?
+ if (gpiod_is_active_low(led_dat-gpiod))
+ level = !level;
And that leads to making it necessary to have this helper variable
to invert the level since that callback does not pass a descriptor
(which would inherently know if it's active low)
+
+ led_dat-platform_gpio_blink_set(gpio, level, NULL, NULL);
Is it *really* impossible to change all the users of this callback?
You said it could be done in a followup patch. Here:
http://marc.info/?l=linux-acpim=141154536921643w=4
And Mika said he would add that to his TODO list:
http://marc.info/?l=linux-acpim=141155173924101w=4
I suppose that is still valid.
Yes, I'll just let dust to settle before sending out a patch that
converts the existing users of platform_gpio_blink_set() callback to
gpio descriptors.
led_dat-blinking = 0;
} else
- gpio_set_value_cansleep(led_dat-gpio,
led_dat-new_level);
+ gpiod_set_value_cansleep(led_dat-gpiod,
led_dat-new_level);
(...)
/* Setting GPIOs with I2C/etc requires a task context, and we
don't
* seem to have a reliable way to know if we're already in one; so
* let's just assume the worst.
@@ -72,11 +73,16 @@ static void gpio_led_set(struct led_clas
schedule_work(led_dat-work);
} else {
if (led_dat-blinking) {
- led_dat-platform_gpio_blink_set(led_dat-gpio,
level,
-NULL, NULL);
+ int gpio = desc_to_gpio(led_dat-gpiod);
+
+ if (gpiod_is_active_low(led_dat-gpiod))
+ level = !level;
+
+ led_dat-platform_gpio_blink_set(gpio, level,
NULL,
+NULL);
Same comment.
@@ -85,9 +91,10 @@ static int gpio_blink_set(struct led_cla
{
struct gpio_led_data *led_dat =
container_of(led_cdev, struct gpio_led_data, cdev);
+ int gpio = desc_to_gpio(led_dat-gpiod);
led_dat-blinking = 1;
- return led_dat-platform_gpio_blink_set(led_dat-gpio,
GPIO_LED_BLINK,
+ return led_dat-platform_gpio_blink_set(gpio, GPIO_LED_BLINK,
delay_on, delay_off);
Same comment.
@@ -97,24 +104,33 @@ static int create_gpio_led(const struct
{
int ret, state;
- led_dat-gpio = -1;
+ if (!template-gpiod) {
+ unsigned long flags = 0;
- /* skip leds that aren't available */
- if (!gpio_is_valid(template-gpio)) {
- dev_info(parent, Skipping unavailable LED gpio %d
(%s)\n,
- template-gpio, template-name);
- return 0;
+ /* skip leds that aren't available */
+ if (!gpio_is_valid(template-gpio)) {
+ dev_info(parent, Skipping unavailable LED gpio
%d (%s)\n,
+ template-gpio, template-name);
+ return 0;
+ }
+
+ if (template-active_low)
+ flags |= GPIOF_ACTIVE_LOW;
+
+ ret = devm_gpio_request_one(parent, template-gpio, flags,
+ template-name);
+ if (ret 0)
+ return ret;
+
+ led_dat-gpiod = gpio_to_desc(template-gpio);
+ if (IS_ERR(led_dat-gpiod))
+ return PTR_ERR(led_dat-gpiod);
Re: [PATCH v2] Documentation: gpio: guidelines for bindings
On Wed, Oct 29, 2014 at 05:13:14PM +0900, Alexandre Courbot wrote: Now that ACPI supports named GPIO properties, either through ACPI 5.1 or the per-driver ACPI GPIO mappings, we can be more narrow about the way GPIOs should be specified in Device Tree bindings. This patch updates the GPIO DT bindings documentation to highlight the following rules for new GPIO bindings: - All new bindings must have a meaningful name (e.g. the gpios property must not be used) - The only suffix allowed is -gpios, no matter the number of descriptors in the property - GPIOs can only be grouped under the same property when they serve the same purpose, a case that should remain exceptional (e.g. bit-banged data lines). Signed-off-by: Alexandre Courbot acour...@nvidia.com CC: Linus Walleij linus.wall...@linaro.org CC: Arnd Bergmann a...@arndb.de CC: Rafael J. Wysocki r...@rjwysocki.net CC: Mika Westerberg mika.westerb...@linux.intel.com Reviewed-by: Mika Westerberg mika.westerb...@linux.intel.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] i2c-qoriq: modified compatibility for correct prescaler
On 10/29/2014 12:08 AM, Scott Wood wrote:
On Fri, 2014-10-17 at 11:27 +0200, Valentin Longchamp wrote:
With fsl-i2c compatibility the i2c frequency is not set
correctly, because it sets no prescaler. According to the AN2919 from
Freescale and the QorIQ (P2041) documentation, the source clock is 1/2
the platform clock. This implies that a prescaler of 2 must be used.
This changes the compatibility of the qoriq-i2c .dtsi files to pick the
mpc8543, which uses the same driver but sets the correct prescaler.
Signed-off-by: Rainer Boschung rainer.bosch...@keymile.com
Signed-off-by: Valentin Longchamp valentin.longch...@keymile.com
---
arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi | 4 ++--
arch/powerpc/boot/dts/fsl/qoriq-i2c-1.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
b/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
index 5f9bf7d..aa6c366 100644
--- a/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/qoriq-i2c-0.dtsi
@@ -36,7 +36,7 @@ i2c@118000 {
#address-cells = 1;
#size-cells = 0;
cell-index = 0;
-compatible = fsl-i2c;
+compatible = fsl,mpc8543-i2c, fsl-i2c;
reg = 0x118000 0x100;
interrupts = 38 2 0 0;
dfsrr;
@@ -46,7 +46,7 @@ i2c@118100 {
#address-cells = 1;
#size-cells = 0;
cell-index = 1;
-compatible = fsl-i2c;
+compatible = fsl,mpc8543-i2c, fsl-i2c;
reg = 0x118100 0x100;
interrupts = 38 2 0 0;
dfsrr;
Are all chips that use this dtsi 100% compatible with mpc8543's i2c, or
just in ways the Linux driver cares about?
I have just looked briefly at the mpc8548 RM (covers mpc8543) and its i2c
controller looks the same as the qoriq's. I cannot however state if they are
100% compatible.
If we wanted to be on the safe side and strict (since we are not sure that the
hardware is 100% compatible), we maybe should add a fsl,qoriq-i2c compatible to
the driver that does the same as mpc8543-i2c.
What about fsl,mpc8544-i2c, which has additional special handling in the
driver, but is only used in socrates.dts (not mpc8544ds.dts)?
From the mpc8544 RM, this controller looks the same as the above 2, except for
the prescaler from the driver which is set to 3. As to why it is only used in
the socrates.dts, I cannot comment about it.
The prescaler is confirmed to be 3 by default by the Table 3 of the AN-219 for
the mpc8544.
What about pq3-i2c-*.dtsi?
This is also interesting: from the AN-219 Table 4, some pq3 have a 2:1
(mcpc8536/43/45/47/48/67/68/72, plus p2020) prescaler where some don't
(mpc8533/44, where it can be 3:1 -default- or 2:1). However pq3-i2c-*.dtsi
defines no prescaler.
Now if I look at what files include these pq3-i2c-*.dtsi, I see some that are in
the the 2:1 list:
arch/powerpc/boot/dts/fsl/mpc8536si-post.dtsi
arch/powerpc/boot/dts/fsl/mpc8548si-post.dtsi
arch/powerpc/boot/dts/fsl/mpc8568si-post.dtsi
arch/powerpc/boot/dts/fsl/mpc8572si-post.dtsi
arch/powerpc/boot/dts/fsl/p2020si-post.dtsi
I don't have any hardware to do some tests with these, but from my measurements
on our qoriq based system (P2041 SoC) I think that the generated I2C clocks for
the above SoC currently are not correct because of the ignored prescaler.
Valentin
--
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] of: spi: Export single device registration method and accessors (v2)
Hello! On 29/10/14 09:40, ext Pantelis Antoniou wrote: Dynamically inserting spi device nodes requires the use of a single device registration method. Rework and export it. Methods to lookup a device/master using a device node are added as well, of_find_spi_master_by_node() of_find_spi_device_by_node(). Changes since v1: * Brown paper bug with parameter on of_register_spi_device(). Signed-off-by: Pantelis Antoniou pantelis.anton...@konsulko.com Acked-by: Alexander Sverdlin alexaner.sverd...@nsn.com --- drivers/spi/spi.c | 255 +- 1 file changed, 157 insertions(+), 98 deletions(-) -- Best regards, Alexander Sverdlin. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND V4 5/9] of: Add NVIDIA Tegra xHCI controller binding
On Tue, Oct 28, 2014 at 03:27:50PM -0700, Andrew Bresticker wrote:
[...]
diff --git
a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
[...]
+Optional properties:
+---
+- vbus-{0,1,2}-supply: VBUS regulator for the corresponding UTMI pad.
+- vddio-hsic-supply: VDDIO regulator for the HSIC pads.
+- nvidia,usb3-port-{0,1}-lane: PCIe/SATA lane to which the corresponding USB3
+ port is mapped. See dt-bindings/pinctrl/pinctrl-tegra-xusb.h for the
list
+ of valid values.
I dislike how we now need to provide a list of all pins in the header
file, where previously we used strings for this. This could become very
ugly if the set of pins changes in future generations of this IP block.
Could we instead derive this from the pinmux nodes? For example you have
this in the example below:
usb3p0 {
nvidia,lanes = pcie-0;
...
};
Perhaps what we need is to either key off the node name or add another
property, such as:
nvidia,usb3-port = 0;
This would match the nvidia,usb2-port property that you've added below.
Lane muxing:
@@ -50,6 +62,17 @@ Optional properties:
pin or group should be assigned to. Valid values for function names are
listed below.
- nvidia,iddq: Enables IDDQ mode of the lane. (0: no, 1: yes)
+- nvidia,usb2-port-num: USB2 port (0, 1, or 2) to which the lane is mapped.
I'd leave away the -num suffix since it is implied that it's a number.
+- nvidia,hsic-strobe-trim: HSIC strobe trimmer value.
+- nvidia,hsic-rx-strobe-trim: HSIC RX strobe trimmer value.
+- nvidia,hsic-rx-data-trim: HSIC RX data trimmer value.
+- nvidia,hsic-tx-rtune-n: HSIC TX RTUNEN value.
+- nvidia,hsic-tx-rtune-p: HSIC TX RTUNEP value.
+- nvidia,hsic-tx-slew-n: HSIC TX SLEWN value.
+- nvidia,hsic-tx-slew-p: HSIC TX SLEWP value.
It would be useful for these to provide a range of valid values. I also
see that there are other registers that contain values for tuning. I
take it that the ones you've included here are the only ones that need
to be overridden on hardware you've tested this on? That should be fine,
we can always add new ones if necessary.
+- nvidia,hsic-auto-term: Enables HSIC AUTO_TERM. (0: no, 1: yes)
+- nvidia,otg-hs-curr-level-offset: Offset to be applied to the pad's fused
+ HS_CURR_LEVEL value.
Note that not all of these properties are valid for all lanes. Lanes can be
divided into three groups:
@@ -58,18 +81,21 @@ divided into three groups:
Valid functions for this group are: snps, xusb, uart, rsvd.
-The nvidia,iddq property does not apply to this group.
+The nvidia,otg-hs-curr-level-offset property only applies.
The wording is confusing here in my opinion. Maybe better: Only the ...
property applies.?
- ulpi-0, hsic-0, hsic-1:
Valid functions for this group are: snps, xusb.
-The nvidia,iddq property does not apply to this group.
+The nvidia,hsic-* properties apply only to the pins hsic-{0,1} when
+the function is xusb.
I assume that hsic-* properties also only apply to the hsic-* pins?
That's not clear from the above sentence.
Thierry
pgpm_bMjWm0CI.pgp
Description: PGP signature
Re: [PATCH v1 1/3] gpio: Add APM X-Gene standby GPIO controller driver
On Fri, Oct 24, 2014 at 3:46 PM, Arnd Bergmann a...@arndb.de wrote:
On Friday 24 October 2014 14:14:43 Linus Walleij wrote:
On Wed, Oct 8, 2014 at 4:52 PM, Y Vo y...@apm.com wrote:
+ apm_gc-irq = devm_kzalloc(pdev-dev, sizeof(u32) *
XGENE_MAX_GPIO_DS,
+ GFP_KERNEL);
+ if (!apm_gc-irq)
+ return -ENOMEM;
+ memset(apm_gc-irq, 0, sizeof(u32) * XGENE_MAX_GPIO_DS);
(...)
+ for (i = 0; i apm_gc-nirq; i++) {
+ apm_gc-irq[default_pins[i]] = platform_get_irq(pdev, i);
So the IRQs for all the GPIO pins are handled somewhere else instead
of being a cascaded IRQ controller.
This means that the IRQ lines from each individual GPIO pin is
connected to a unique IRQ line on a secondary interrupt controller,
instead of the GPIO block being a cascaded interrupt controller
in its own right.
Is this correct?
See the discussion I had on this. Yes, each line is connected to a
GIC SPI interrupt by itself. I've discussed this with Marc Zyngier
and Thomas Gleixner at the conference last week, and we concluded
that we will need a new generic interface to get data out of the
parent interrupt controller in a proper way. The current implementation
just maps the GIC registers and reads them directly, which of course
is not a proper way to do it.
Hmm. OK shall we hold this driver until the infrastructure
issues are resolved?
The following is a recurring pattern among GPIO controllers:
the GPIO controller can go offline (asycnhcronous) and while it
is offline a secondary logic triggers an IRQ that wakes the system
up, however the GPIO logic cannot really see that IRQ since
it was sleeping when it arrived.
Thus a latent IRQ is pending in the wakeup logic. This concept
exists in drivers/pinctrl/nomadik/pinctrl-nomadik.c and I strongly
prefer to call these latent irqs as it's a clear unambigous
terminology.
So is this a case of latent IRQs pending in the GIC?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND V4 5/9] of: Add NVIDIA Tegra xHCI controller binding
On Tue, Oct 28, 2014 at 03:27:52PM -0700, Andrew Bresticker wrote:
[...]
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xhci.txt
[...]
+- pll_u_480m
+- clk_m
+- pll_e
What are these used for? I guess I'll see when I get to the driver
patch.
+Optional properties:
+
+ - phys: Must contain an entry for each entry in phy-names.
+ See ../phy/phy-bindings.txt for details.
+ - phy-names: Should include an entry for each PHY used by the controller.
+ May be a subset of the following:
+- utmi-{0,1,2}
+- hsic-{0,1}
+- usb3-{0,1}
+ - avddio-pex-supply: PCIe/USB3 analog logic power supply. Must supply
1.05V.
+ - dvddio-pex-supply: PCIe/USB3 digital logic power supply. Must supply
1.05V.
+ - avdd-usb-supply: USB controller power supply. Must supply 3.3V.
+ - avdd-pll-utmip-supply: UTMI PLL power supply. Must supply 1.8V.
+ - avdd-pll-erefe-supply: PLLE reference PLL power supply. Must supply
1.05V.
+ - avdd-pex-pll-supply: PCIe/USB3 PLL power supply. Must supply 1.05V.
+ - hvdd-pex-supply: High-voltage PCIe/USB3 power supply. Must supply 3.3V.
+ - hvdd-pex-plle-supply: High-voltage PLLE power supply. Must supply 3.3V.
I think the name for this in the documentation is HVDD_PEX_PLL_E, which
would translate to hvdd-pex-pll-e. At least that's how we named this
supply for PCIe.
Alternatively it seems like there are aliases for the USB 3.0 related
supplies:
avdd-pex-pll - avdd-usb-ss-pll
hvdd-pex - hvdd-usb-ss
hvdd-pex-pll-e - hvdd-usb-ss-pll-e
So perhaps these could be used for the XHCI driver instead? Also, should
these supplies not be mandatory?
Thierry
pgpiiuWVo2sSi.pgp
Description: PGP signature
Re: [PATCH v5 3/4] regulator: max77686: Add suspend disable for some LDOs
On Wed, Oct 29, 2014 at 10:20:13AM +0100, Krzysztof Kozlowski wrote: On wto, 2014-10-28 at 22:31 +, Mark Brown wrote: This looks wrong, you're using the regular enable operation as suspend enable. How does that work without disrupting the current runtime state? Currently it shouldn't disrupt state of regulator because during runtime it may only be only: on (0x3) or off (0x0). Suspend enable in max77686 writes 0x3 to the register which means - always on. If regulator was disabled before suspend then it has to be enabled during suspend_enable() call which is exactly what max77686_enable does. If it was enabled then nothing happens. No, this isn't suspend enable control - this is normal, standard enable control and the device has no suspend enable control. signature.asc Description: Digital signature
[PATCH v5 0/6] ARM: mediatek: Add support for interrupt polarity
This series is 5th version of interrupt polarity support for MediaTek SoCs. This is based on Jiang's hierarchy irqdomain p2v3 [1], which is based on v3.18-rc2, and my mediatek SoC basic support [2]. Besides changing base, this version addressed comments from Thomas and Marc and also fix a bug on mt6589 reported by Matthias. In Jiang's version of irq_create_of_mapping, if irqdomain is hierarchy, it will not perform irq_find_mapping check and set_type. The outermost irqdomain need to take care of that. Because we will have several different outermost irqdomain in different ARM SoCs, this cause code duplication. I moved them back to irq_create_of_mapping. Simplified block diagram for interrupt on my system: +---+ +---+ ---| SYSIRQ|--|ARM GIC| ---| |--| | ---| |--| | ---| |--| | ---| |--| | +---+ +---+ In device tree, interrupt-parent for other devices is sysirq, child of gic. This describe HW better and allow device to specify polarity as it is sent by the device. When using hierarchy irq domain, gic will use irq_domain_add_linear to create irqdomain and all interrupt numbers must come from device tree. My /proc/interrupts looks like this now: # cat /proc/interrupts CPU0 16: 149578 MT_SYSIRQ 113 mtk_timer 20: 1082 MT_SYSIRQ 54 serial Changes in v5: - Fix bug on mt6589 reported by Matthias - Fix bug for irq_find_mapping in irq_create_of_mapping - Merge Marc's change to proper handle non-DT case in gic_init_bases Changes in v4: - Discussed in [3] - Remove arm,hierarchy-irq-domain. When GIC is probed by DT, it will support hierarchy irqdomain. Changes in v3: - Discussed in [4] - First implementation using hierarchy irqdomain [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/297624.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/296093.html [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/296911.html [4] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/293766.html Yingjoe Chen (6): irqdomain: do irq_find_mapping and set_type for hierarchy irqdomain genirq: Add more helper functions to support stacked irq_chip irqchip: gic: Support hierarchy irq domain. ARM: mediatek: Add sysirq interrupt polarity support ARM: mediatek: Add sysirq in mt6589/mt8135/mt8127 dtsi dt-bindings: add bindings for mediatek sysirq .../bindings/arm/mediatek/mediatek,sysirq.txt | 26 arch/arm/boot/dts/mt6589.dtsi | 14 +- arch/arm/boot/dts/mt8127.dtsi | 14 +- arch/arm/boot/dts/mt8135.dtsi | 14 +- drivers/irqchip/Kconfig| 1 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-gic.c | 90 +++ drivers/irqchip/irq-mtk-sysirq.c | 168 + include/linux/irq.h| 6 + kernel/irq/chip.c | 28 kernel/irq/irqdomain.c | 27 ++-- 11 files changed, 348 insertions(+), 41 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt create mode 100644 drivers/irqchip/irq-mtk-sysirq.c -- 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 v5 1/6] irqdomain: do irq_find_mapping and set_type for hierarchy irqdomain
It is possible to call irq_create_of_mapping to create/translate the
same IRQ from DT for multiple times. Perform irq_find_mapping check
and set_type for hierarchy irqdomain in irq_create_of_mapping() to
avoid duplicate these functionality in all outer most irqdomain.
Signed-off-by: Yingjoe Chen yingjoe.c...@mediatek.com
---
kernel/irq/irqdomain.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 7cc9cbb..c292603 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -478,11 +478,6 @@ unsigned int irq_create_of_mapping(struct of_phandle_args
*irq_data)
return 0;
}
- if (irq_domain_is_hierarchy(domain)) {
- virq = irq_domain_alloc_irqs(domain, 1, NUMA_NO_NODE, irq_data);
- return virq = 0 ? 0 : virq;
- }
-
/* If domain has no translation, then we assume interrupt line */
if (domain-ops-xlate == NULL)
hwirq = irq_data-args[0];
@@ -492,10 +487,24 @@ unsigned int irq_create_of_mapping(struct of_phandle_args
*irq_data)
return 0;
}
- /* Create mapping */
- virq = irq_create_mapping(domain, hwirq);
- if (!virq)
- return virq;
+ if (irq_domain_is_hierarchy(domain)) {
+ /*
+* If we've already configured this interrupt,
+* don't do it again, or hell will break loose.
+*/
+ virq = irq_find_mapping(domain, hwirq);
+ if (virq)
+ return virq;
+
+ virq = irq_domain_alloc_irqs(domain, 1, NUMA_NO_NODE, irq_data);
+ if (virq = 0)
+ return 0;
+ } else {
+ /* Create mapping */
+ virq = irq_create_mapping(domain, hwirq);
+ if (!virq)
+ return virq;
+ }
/* Set type if specified and different than the current one */
if (type != IRQ_TYPE_NONE
--
1.8.1.1.dirty
--
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 v5 6/6] dt-bindings: add bindings for mediatek sysirq
Add binding documentation for Mediatek SoC SYSIRQ.
Signed-off-by: Yingjoe Chen yingjoe.c...@mediatek.com
---
.../bindings/arm/mediatek/mediatek,sysirq.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt
new file mode 100644
index 000..8669536
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt
@@ -0,0 +1,26 @@
+Mediatek 65xx/81xx sysirq
+
+Mediatek SOCs sysirq support controllable irq inverter for each GIC SPI
+interrupt.
+
+Required properties:
+- compatible: should be one of:
+ mediatek,mt8135-sysirq
+ mediatek,mt8127-sysirq
+ mediatek,mt6589-sysirq
+ mediatek,mt6582-sysirq
+ mediatek,mt6577-sysirq
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Must use the same cells/format as parent controller.
+- interrupt-parent: phandle of irq domain parent for sysirq.
+- reg: Physical base address of the intpol registers and length of memory
+ mapped region.
+
+Example:
+ sysirq: interrupt-controller@10200100 {
+ compatible = mediatek,mt6589-sysirq, mediatek,mt6577-sysirq;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ interrupt-parent = gic;
+ reg = 0 0x10200100 0 0x1c;
+ };
--
1.8.1.1.dirty
--
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 v5 4/6] ARM: mediatek: Add sysirq interrupt polarity support
Mediatek SoCs have interrupt polarity support in sysirq which
allows to invert polarity for given interrupt. Add this support
using hierarchy irq domain.
Signed-off-by: Yingjoe Chen yingjoe.c...@mediatek.com
---
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-mtk-sysirq.c | 168 +++
2 files changed, 169 insertions(+)
create mode 100644 drivers/irqchip/irq-mtk-sysirq.c
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 173bb5f..4e0f254 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_IRQ_CROSSBAR)+= irq-crossbar.o
obj-$(CONFIG_BRCMSTB_L2_IRQ) += irq-brcmstb-l2.o \
irq-bcm7120-l2.o
obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
+obj-$(CONFIG_ARCH_MEDIATEK)+= irq-mtk-sysirq.o
diff --git a/drivers/irqchip/irq-mtk-sysirq.c b/drivers/irqchip/irq-mtk-sysirq.c
new file mode 100644
index 000..4403bcf
--- /dev/null
+++ b/drivers/irqchip/irq-mtk-sysirq.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Joe.C yingjoe.c...@mediatek.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/irq.h
+#include linux/irqdomain.h
+#include linux/of.h
+#include linux/of_irq.h
+#include linux/of_address.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/spinlock.h
+
+#include irqchip.h
+
+#define MT6577_SYS_INTPOL_NUM (224)
+
+struct mtk_sysirq_chip_data {
+ spinlock_t lock;
+ void __iomem *intpol_base;
+};
+
+static int mtk_sysirq_set_type(struct irq_data *data, unsigned int type)
+{
+ irq_hw_number_t hwirq = data-hwirq;
+ struct mtk_sysirq_chip_data *chip_data = data-chip_data;
+ u32 offset, reg_index, value;
+ unsigned long flags;
+ int ret;
+
+ offset = hwirq 0x1f;
+ reg_index = hwirq 5;
+
+ spin_lock_irqsave(chip_data-lock, flags);
+ value = readl_relaxed(chip_data-intpol_base + reg_index * 4);
+ if (type == IRQ_TYPE_LEVEL_LOW || type == IRQ_TYPE_EDGE_FALLING) {
+ if (type == IRQ_TYPE_LEVEL_LOW)
+ type = IRQ_TYPE_LEVEL_HIGH;
+ else
+ type = IRQ_TYPE_EDGE_RISING;
+ value |= (1 offset);
+ } else
+ value = ~(1 offset);
+ writel(value, chip_data-intpol_base + reg_index * 4);
+
+ data = data-parent_data;
+ ret = data-chip-irq_set_type(data, type);
+ spin_unlock_irqrestore(chip_data-lock, flags);
+ return ret;
+}
+
+static struct irq_chip mtk_sysirq_chip = {
+ .name = MT_SYSIRQ,
+ .irq_mask = irq_chip_mask_parent,
+ .irq_unmask = irq_chip_unmask_parent,
+ .irq_eoi= irq_chip_eoi_parent,
+ .irq_set_type = mtk_sysirq_set_type,
+ .irq_retrigger = irq_chip_retrigger_hierarchy,
+ .irq_set_affinity = irq_chip_set_affinity_parent,
+};
+
+static int mtk_sysirq_domain_xlate(struct irq_domain *d,
+ struct device_node *controller,
+ const u32 *intspec, unsigned int intsize,
+ unsigned long *out_hwirq,
+ unsigned int *out_type)
+{
+ if (intsize 3)
+ return -EINVAL;
+
+ /* sysirq doesn't support PPI */
+ if (intspec[0])
+ return -EINVAL;
+
+ *out_hwirq = intspec[1];
+ *out_type = intspec[2] IRQ_TYPE_SENSE_MASK;
+ return 0;
+}
+
+static int mtk_sysirq_domain_alloc(struct irq_domain *domain, unsigned int
virq,
+ unsigned int nr_irqs, void *arg)
+{
+ int i, ret;
+ irq_hw_number_t hwirq;
+ struct of_phandle_args *irq_data = arg;
+
+ if (irq_data-args_count 3)
+ return -EINVAL;
+
+ hwirq = irq_data-args[1];
+ for (i = 0; i nr_irqs; i++)
+ irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
+ mtk_sysirq_chip,
+ domain-host_data);
+
+ return irq_domain_alloc_irqs_parent(domain, virq, nr_irqs, arg);
+}
+
+static void mtk_sysirq_domain_free(struct irq_domain *domain, unsigned int
virq,
+ unsigned int nr_irqs)
+{
+ int i;
+
+ for (i = 0; i nr_irqs; i++) {
+ irq_set_handler(virq + i, NULL);
+
[PATCH v5 3/6] irqchip: gic: Support hierarchy irq domain.
Add support to use gic as a parent for stacked irq domain.
Signed-off-by: Yingjoe Chen yingjoe.c...@mediatek.com
---
drivers/irqchip/Kconfig | 1 +
drivers/irqchip/irq-gic.c | 90 +--
2 files changed, 65 insertions(+), 26 deletions(-)
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index b21f12f..7f34138 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -5,6 +5,7 @@ config IRQCHIP
config ARM_GIC
bool
select IRQ_DOMAIN
+ select IRQ_DOMAIN_HIERARCHY
select MULTI_IRQ_HANDLER
config GIC_NON_BANKED
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 38493ff..6f39bef 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -786,19 +786,17 @@ void __init gic_init_physaddr(struct device_node *node)
static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
irq_hw_number_t hw)
{
+ irq_domain_set_hwirq_and_chip(d, irq, hw, gic_chip, d-host_data);
if (hw 32) {
irq_set_percpu_devid(irq);
- irq_set_chip_and_handler(irq, gic_chip,
-handle_percpu_devid_irq);
+ irq_set_handler(irq, handle_percpu_devid_irq);
set_irq_flags(irq, IRQF_VALID | IRQF_NOAUTOEN);
} else {
- irq_set_chip_and_handler(irq, gic_chip,
-handle_fasteoi_irq);
+ irq_set_handler(irq, handle_fasteoi_irq);
set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
gic_routable_irq_domain_ops-map(d, irq, hw);
}
- irq_set_chip_data(irq, d-host_data);
return 0;
}
@@ -814,8 +812,6 @@ static int gic_irq_domain_xlate(struct irq_domain *d,
{
unsigned long ret = 0;
- if (d-of_node != controller)
- return -EINVAL;
if (intsize 3)
return -EINVAL;
@@ -858,6 +854,42 @@ static struct notifier_block gic_cpu_notifier = {
};
#endif
+static int gic_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
+ unsigned int nr_irqs, void *arg)
+{
+ int i, ret;
+ irq_hw_number_t hwirq;
+ unsigned int type = IRQ_TYPE_NONE;
+ struct of_phandle_args *irq_data = arg;
+
+ ret = gic_irq_domain_xlate(domain, irq_data-np, irq_data-args,
+ irq_data-args_count, hwirq, type);
+ if (ret)
+ return ret;
+
+ for (i = 0; i nr_irqs; i++)
+ gic_irq_domain_map(domain, virq+i, hwirq+i);
+
+ return 0;
+}
+
+static void gic_irq_domain_free(struct irq_domain *domain, unsigned int virq,
+ unsigned int nr_irqs)
+{
+ int i;
+
+ for (i = 0; i nr_irqs; i++) {
+ irq_set_handler(virq + i, NULL);
+ irq_domain_set_hwirq_and_chip(domain, virq + i, 0, NULL, NULL);
+ }
+}
+
+static const struct irq_domain_ops gic_irq_domain_hierarchy_ops = {
+ .xlate = gic_irq_domain_xlate,
+ .alloc = gic_irq_domain_alloc,
+ .free = gic_irq_domain_free,
+};
+
static const struct irq_domain_ops gic_irq_domain_ops = {
.map = gic_irq_domain_map,
.unmap = gic_irq_domain_unmap,
@@ -948,18 +980,6 @@ void __init gic_init_bases(unsigned int gic_nr, int
irq_start,
gic_cpu_map[i] = 0xff;
/*
-* For primary GICs, skip over SGIs.
-* For secondary GICs, skip over PPIs, too.
-*/
- if (gic_nr == 0 (irq_start 31) 0) {
- hwirq_base = 16;
- if (irq_start != -1)
- irq_start = (irq_start ~31) + 16;
- } else {
- hwirq_base = 32;
- }
-
- /*
* Find out how many interrupts are supported.
* The GIC only supports up to 1020 interrupt sources.
*/
@@ -969,10 +989,32 @@ void __init gic_init_bases(unsigned int gic_nr, int
irq_start,
gic_irqs = 1020;
gic-gic_irqs = gic_irqs;
- gic_irqs -= hwirq_base; /* calculate # of irqs to allocate */
+ if (node) { /* DT case */
+ const struct irq_domain_ops *ops =
+ gic_irq_domain_hierarchy_ops;
+
+ if (!of_property_read_u32(node, arm,routable-irqs,
+ nr_routable_irqs)) {
+ ops = gic_irq_domain_ops;
+ gic_irqs = nr_routable_irqs;
+ }
+
+ gic-domain = irq_domain_add_linear(node, gic_irqs, ops, gic);
+ } else {/* Non-DT case */
+ /*
+* For primary GICs, skip over SGIs.
+* For secondary GICs, skip over PPIs, too.
+*/
+ if (gic_nr == 0 (irq_start 31) 0) {
+ hwirq_base = 16;
+
[PATCH v5 2/6] genirq: Add more helper functions to support stacked irq_chip
Add more helper function for stacked irq_chip to just call parent's
function.
Signed-off-by: Yingjoe Chen yingjoe.c...@mediatek.com
---
include/linux/irq.h | 6 ++
kernel/irq/chip.c | 28
2 files changed, 34 insertions(+)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 0adcbbb..ff0a89c 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -445,6 +445,12 @@ extern void handle_nested_irq(unsigned int irq);
#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
extern void irq_chip_ack_parent(struct irq_data *data);
+extern void irq_chip_mask_parent(struct irq_data *data);
+extern void irq_chip_unmask_parent(struct irq_data *data);
+extern void irq_chip_eoi_parent(struct irq_data *data);
+extern int irq_chip_set_affinity_parent(struct irq_data *data,
+ const struct cpumask *dest,
+ bool force);
extern int irq_chip_retrigger_hierarchy(struct irq_data *data);
#endif
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 12f3e72..fe53575 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -858,6 +858,34 @@ void irq_chip_ack_parent(struct irq_data *data)
data-chip-irq_ack(data);
}
+void irq_chip_mask_parent(struct irq_data *data)
+{
+ data = data-parent_data;
+ data-chip-irq_mask(data);
+}
+
+void irq_chip_unmask_parent(struct irq_data *data)
+{
+ data = data-parent_data;
+ data-chip-irq_unmask(data);
+}
+
+void irq_chip_eoi_parent(struct irq_data *data)
+{
+ data = data-parent_data;
+ data-chip-irq_eoi(data);
+}
+
+int irq_chip_set_affinity_parent(struct irq_data *data,
+const struct cpumask *dest, bool force)
+{
+ data = data-parent_data;
+ if (data-chip-irq_set_affinity)
+ return data-chip-irq_set_affinity(data, dest, force);
+
+ return -ENOSYS;
+}
+
int irq_chip_retrigger_hierarchy(struct irq_data *data)
{
for (data = data-parent_data; data; data = data-parent_data)
--
1.8.1.1.dirty
--
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 v5 5/6] ARM: mediatek: Add sysirq in mt6589/mt8135/mt8127 dtsi
Add sysirq settings for mt6589/mt8135/mt8127
This also correct timer interrupt flag. The old setting works
because boot loader already set polarity for timer interrupt.
Without intpol support, the setting was not changed so gic
can get the irq correctly.
Signed-off-by: Yingjoe Chen yingjoe.c...@mediatek.com
---
arch/arm/boot/dts/mt6589.dtsi | 14 --
arch/arm/boot/dts/mt8127.dtsi | 14 --
arch/arm/boot/dts/mt8135.dtsi | 14 --
3 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/mt6589.dtsi b/arch/arm/boot/dts/mt6589.dtsi
index e3c7600..c91b2a9 100644
--- a/arch/arm/boot/dts/mt6589.dtsi
+++ b/arch/arm/boot/dts/mt6589.dtsi
@@ -19,7 +19,7 @@
/ {
compatible = mediatek,mt6589;
- interrupt-parent = gic;
+ interrupt-parent = sysirq;
cpus {
#address-cells = 1;
@@ -76,15 +76,25 @@
timer: timer@10008000 {
compatible = mediatek,mt6577-timer;
reg = 0x10008000 0x80;
- interrupts = GIC_SPI 113 IRQ_TYPE_EDGE_RISING;
+ interrupts = GIC_SPI 113 IRQ_TYPE_LEVEL_LOW;
clocks = system_clk, rtc_clk;
clock-names = system-clk, rtc-clk;
};
+ sysirq: interrupt-controller@10200100 {
+ compatible = mediatek,mt6589-sysirq,
+mediatek,mt6577-sysirq;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ interrupt-parent = gic;
+ reg = 0x10200100 0x1c;
+ };
+
gic: interrupt-controller@10211000 {
compatible = arm,cortex-a7-gic;
interrupt-controller;
#interrupt-cells = 3;
+ interrupt-parent = gic;
reg = 0x10211000 0x1000,
0x10212000 0x1000,
0x10214000 0x2000,
diff --git a/arch/arm/boot/dts/mt8127.dtsi b/arch/arm/boot/dts/mt8127.dtsi
index 249c218..59efb07 100644
--- a/arch/arm/boot/dts/mt8127.dtsi
+++ b/arch/arm/boot/dts/mt8127.dtsi
@@ -18,7 +18,7 @@
/ {
compatible = mediatek,mt8127;
- interrupt-parent = gic;
+ interrupt-parent = sysirq;
cpus {
#address-cells = 1;
@@ -81,15 +81,25 @@
timer: timer@10008000 {
compatible = mediatek,mt8127-timer,
mediatek,mt6577-timer;
reg = 0 0x10008000 0 0x80;
- interrupts = GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 112 IRQ_TYPE_LEVEL_LOW;
clocks = system_clk, rtc_clk;
clock-names = system-clk, rtc-clk;
};
+ sysirq: interrupt-controller@10200100 {
+ compatible = mediatek,mt8127-sysirq,
+mediatek,mt6577-sysirq;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ interrupt-parent = gic;
+ reg = 0 0x10200100 0 0x1c;
+ };
+
gic: interrupt-controller@10211000 {
compatible = arm,cortex-a7-gic;
interrupt-controller;
#interrupt-cells = 3;
+ interrupt-parent = gic;
reg = 0 0x10211000 0 0x1000,
0 0x10212000 0 0x1000,
0 0x10214000 0 0x2000,
diff --git a/arch/arm/boot/dts/mt8135.dtsi b/arch/arm/boot/dts/mt8135.dtsi
index 683b761..2b6d5c8 100644
--- a/arch/arm/boot/dts/mt8135.dtsi
+++ b/arch/arm/boot/dts/mt8135.dtsi
@@ -18,7 +18,7 @@
/ {
compatible = mediatek,mt8135;
- interrupt-parent = gic;
+ interrupt-parent = sysirq;
cpu-map {
cluster0 {
@@ -104,15 +104,25 @@
timer: timer@10008000 {
compatible = mediatek,mt8135-timer,
mediatek,mt6577-timer;
reg = 0 0x10008000 0 0x80;
- interrupts = GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 113 IRQ_TYPE_LEVEL_LOW;
clocks = system_clk, rtc_clk;
clock-names = system-clk, rtc-clk;
};
+ sysirq: interrupt-controller@10200030 {
+ compatible = mediatek,mt8135-sysirq,
+mediatek,mt6577-sysirq;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ interrupt-parent = gic;
+ reg = 0 0x10200030 0 0x1c;
+ };
+
gic: interrupt-controller@10211000 {
Re: [PATCH 01/11] irqchip: Allow irq_reg_{readl,writel} to use __raw_{readl_writel}
On Tue, 28 Oct 2014, Kevin Cernekee wrote: On big-endian systems readl/writel may perform an unwanted endian swap, breaking generic-chip.c. Let the platform code opt to use the __raw_ variants by selecting RAW_IRQ_ACCESSORS. This is required in order for bcm3384 to use GENERIC_IRQ_CHIP. Several existing irqchip drivers also use the __raw_ accessors directly, so it is a reasonably common requirement. How does that work with multi arch kernels? Thanks, tglx Signed-off-by: Kevin Cernekee cerne...@gmail.com --- drivers/irqchip/Kconfig | 3 +++ include/linux/irq.h | 13 + 2 files changed, 16 insertions(+) diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig index b21f12f..6f0e80b 100644 --- a/drivers/irqchip/Kconfig +++ b/drivers/irqchip/Kconfig @@ -2,6 +2,9 @@ config IRQCHIP def_bool y depends on OF_IRQ +config RAW_IRQ_ACCESSORS + bool + config ARM_GIC bool select IRQ_DOMAIN diff --git a/include/linux/irq.h b/include/linux/irq.h index 03f48d9..ed1ea8a 100644 --- a/include/linux/irq.h +++ b/include/linux/irq.h @@ -639,6 +639,17 @@ void arch_teardown_hwirq(unsigned int irq); void irq_init_desc(unsigned int irq); #endif +#ifdef CONFIG_RAW_IRQ_ACCESSORS + +#ifndef irq_reg_writel +# define irq_reg_writel(val, addr) __raw_writel(val, addr) +#endif +#ifndef irq_reg_readl +# define irq_reg_readl(addr) __raw_readl(addr) +#endif + +#else + #ifndef irq_reg_writel # define irq_reg_writel(val, addr) writel(val, addr) #endif @@ -646,6 +657,8 @@ void irq_init_desc(unsigned int irq); # define irq_reg_readl(addr) readl(addr) #endif +#endif + /** * struct irq_chip_regs - register offsets for struct irq_gci * @enable: Enable register offset to reg_base -- 2.1.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] of: spi: Export single device registration method and accessors (v2)
On Wed, Oct 29, 2014 at 10:40:37AM +0200, Pantelis Antoniou wrote: Dynamically inserting spi device nodes requires the use of a single device registration method. Rework and export it. Methods to lookup a device/master using a device node are added as well, of_find_spi_master_by_node() of_find_spi_device_by_node(). Why do we need to do this - I would expect that adding nodes would trigger parsing in the same way we normally do it. Where is the user and how does it know that it's handling a SPI node? This feels like there is an abstraction problem somewhere, whatever code is supposed to use this is going to need to be taught about each individual bus which is going to be tedious, I would expect that we'd have something like the bus being able to provide a callback which will get invoked whenever a new node appears on the parent node for the bus. Changes since v1: * Brown paper bug with parameter on of_register_spi_device(). Don't include noise like this in the changelog, put it after --- like SubmittingPatches says. Please also try to keep your CC list sane, CCing random people just means that you're increasing the volume of mail they have to process. I'm surprised kernel.org accepts so many CCs. I have to say I don't recall ever seeing v1... signature.asc Description: Digital signature
Re: [PATCH v2 2/3] ARM: dts: socfpga: fpga bridges bindings docs
On Wed, Oct 29, 2014 at 08:57:01AM +0100, Steffen Trumtrar wrote: So, that shouldn't be a problem though, as I already cooked up a driver for the L3 with all the ranges specified. The only thing I need to figure out before I will post it, is how to nicely handle the WO remap register. I think regmap might be able to handle this itself, but am not sure yet. It's supposed to be able to, not sure if anyone really tests that or not though so it's possible bugs crept in. Most write only registers can physically be read so actually come out as volatile rather than write only even if functionally there is no reason to read. signature.asc Description: Digital signature
Re: [PATCH v5 3/4] regulator: max77686: Add suspend disable for some LDOs
On śro, 2014-10-29 at 10:01 +, Mark Brown wrote: On Wed, Oct 29, 2014 at 10:20:13AM +0100, Krzysztof Kozlowski wrote: On wto, 2014-10-28 at 22:31 +, Mark Brown wrote: This looks wrong, you're using the regular enable operation as suspend enable. How does that work without disrupting the current runtime state? Currently it shouldn't disrupt state of regulator because during runtime it may only be only: on (0x3) or off (0x0). Suspend enable in max77686 writes 0x3 to the register which means - always on. If regulator was disabled before suspend then it has to be enabled during suspend_enable() call which is exactly what max77686_enable does. If it was enabled then nothing happens. No, this isn't suspend enable control - this is normal, standard enable control and the device has no suspend enable control. You mean that for such regulator the driver shouldn't implement suspend_enable()? Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/3] gpio: Add APM X-Gene standby GPIO controller driver
On Wednesday 29 October 2014 10:52:47 Linus Walleij wrote: On Fri, Oct 24, 2014 at 3:46 PM, Arnd Bergmann a...@arndb.de wrote: On Friday 24 October 2014 14:14:43 Linus Walleij wrote: See the discussion I had on this. Yes, each line is connected to a GIC SPI interrupt by itself. I've discussed this with Marc Zyngier and Thomas Gleixner at the conference last week, and we concluded that we will need a new generic interface to get data out of the parent interrupt controller in a proper way. The current implementation just maps the GIC registers and reads them directly, which of course is not a proper way to do it. Hmm. OK shall we hold this driver until the infrastructure issues are resolved? Y could send a first version that does not support the IRQ lines if he wants to speed up the process. The following is a recurring pattern among GPIO controllers: the GPIO controller can go offline (asycnhcronous) and while it is offline a secondary logic triggers an IRQ that wakes the system up, however the GPIO logic cannot really see that IRQ since it was sleeping when it arrived. Thus a latent IRQ is pending in the wakeup logic. This concept exists in drivers/pinctrl/nomadik/pinctrl-nomadik.c and I strongly prefer to call these latent irqs as it's a clear unambigous terminology. So is this a case of latent IRQs pending in the GIC? I think this case is different, from what I understand, the GPIO controller cannot implement gpio_chip-get() for any line that is connected to the GIC, and it has to ask the GIC instead. This seems independent of the online/offline state of the controller. 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 v2 2/3] ARM: dts: socfpga: fpga bridges bindings docs
On Wed, Oct 29, 2014 at 10:16:32AM +, Mark Brown wrote: On Wed, Oct 29, 2014 at 08:57:01AM +0100, Steffen Trumtrar wrote: So, that shouldn't be a problem though, as I already cooked up a driver for the L3 with all the ranges specified. The only thing I need to figure out before I will post it, is how to nicely handle the WO remap register. I think regmap might be able to handle this itself, but am not sure yet. It's supposed to be able to, not sure if anyone really tests that or not though so it's possible bugs crept in. Most write only registers can physically be read so actually come out as volatile rather than write only even if functionally there is no reason to read. Ah, I think you might be actually right there. IIRC it IS possible to read from that register, but you only get 0s. So, I shot myself in the knee with specifying that register as write-only in my driver. Thanks, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 3/4] regulator: max77686: Add suspend disable for some LDOs
On Wed, Oct 29, 2014 at 11:18:54AM +0100, Krzysztof Kozlowski wrote: On śro, 2014-10-29 at 10:01 +, Mark Brown wrote: No, this isn't suspend enable control - this is normal, standard enable control and the device has no suspend enable control. You mean that for such regulator the driver shouldn't implement suspend_enable()? Yes, if there is no separate control of suspend mode in hardware then of course the driver shouldn't implement operations for things it doesn't have. signature.asc Description: Digital signature
Re: [RFC Patch] gpio: add GPIO hogging mechanism
Hi, On Tue, Oct 21, 2014 at 03:09:58PM -0500, Benoit Parrot wrote: Based on Boris Brezillion work this is a reworked patch of his initial GPIO hogging mechanism. This patch provides a way to initally configure specific GPIO when the gpio controller is probe. The actual DT scanning to collect the GPIO specific data is performed as part of the gpiochip_add(). The purpose of this is to allows specific GPIOs to be configured without any driver specific code. This particularly usueful because board design are getting increassingly complex and given SoC pins can now have upward of 10 mux values a lot of connections are now dependent on external IO muxes to switch various modes and combination. Specific drivers should not necessarily need to be aware of what accounts to a specific board implementation. This board level description should be best kept as part of the dts file. Signed-off-by: Benoit Parrot bpar...@ti.com I've been thinking about this for quite some time, it's good to see some progress on that :) However, I have a slightly different use case for it: the Allwinner SoCs have a vdd pin coming in for every gpio bank. Nothing out of the ordinary so far, except that some of the boards are using a GPIO-controlled regulator to feed another bank vdd. That obviously causes a chicken-egg issue, since for the gpio-regulator driver to probe, it needs to gpio driver, and for the gpio driver to probe, it needs the regulator driver. I was thinking of solving this by enforcing gpio hogs, in order to have the gpio driver loading, grabing its gpios setting them to the right value to enable the current to flow in, and then let the regulator driver probe later on. I don't think it's possible with your current code, would it be something worth considering, or would someone have a better solution? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 6/8] regulator: max77686: Add external GPIO control
[adding Linus and Alexandre to the cc list]
Hello Krzysztof,
On 10/29/2014 11:42 AM, Krzysztof Kozlowski wrote:
On wto, 2014-10-28 at 13:11 +0100, Krzysztof Kozlowski wrote:
On wto, 2014-10-28 at 09:52 +0100, Krzysztof Kozlowski wrote:
On pon, 2014-10-27 at 21:03 +0100, Javier Martinez Canillas wrote:
Hello Krzysztof,
On 10/27/2014 04:03 PM, Krzysztof Kozlowski wrote:
@@ -85,6 +91,9 @@ struct max77686_data {
struct max77686_regulator_data *regulators;
int num_regulators;
+ /* Array of size num_regulators with GPIOs for external
control. */
+ int *ext_control_gpio;
+
The integer-based GPIO API is deprecated in favor of the
descriptor-based GPIO
interface (Documentation/gpio/consumer.txt). Could you please use the
later?
Sure, I can. Please have in mind that regulator core still accepts old
GPIO so I will have to use desc_to_gpio(). That should work... and
should be future-ready.
It seems I was too hasty... I think usage of the new gpiod API implies
completely different bindings.
The gpiod_get() gets GPIO from a device level, not from given sub-node
pointer. This means that you cannot have DTS like this:
ldo21_reg: ldo21 {
regulator-compatible = LDO21;
regulator-name = VTF_2.8V;
regulator-min-microvolt = 280;
regulator-max-microvolt = 280;
ec-gpio = gpy2 0 0;
};
ldo22_reg: ldo22 {
regulator-compatible = LDO22;
regulator-name = VMEM_VDD_2.8V;
regulator-min-microvolt = 280;
regulator-max-microvolt = 280;
ec-gpio = gpk0 2 0;
};
I could put GPIOs in device node:
max77686_pmic@09 {
compatible = maxim,max77686;
interrupt-parent = gpx0;
interrupts = 7 0;
reg = 0x09;
#clock-cells = 1;
ldo21-gpio = gpy2 0 0;
ldo22-gpio = gpk0 2 0;
ldo21_reg: ldo21 {
regulator-compatible = LDO21;
regulator-name = VTF_2.8V;
regulator-min-microvolt = 280;
regulator-max-microvolt = 280;
};
ldo22_reg: ldo22 {
regulator-compatible = LDO22;
regulator-name = VMEM_VDD_2.8V;
regulator-min-microvolt = 280;
regulator-max-microvolt = 280;
};
This would work but I don't like it. The properties of a regulator are
above the node configuring that regulator.
Any ideas?
Continuing talking to myself... I found another problem - GPIO cannot be
requested more than once (-EBUSY). In case of this driver (and board:
Trats2) one GPIO is connected to regulators. The legacy GPIO API and
regulator core handle this.
With new GPIO API I would have to implement some additional steps in
such case...
So there are 2 issues:
1. Cannot put GPIO property in regulator node.
2. Cannot request some GPIO more than once.
I'm going back to legacy API for now.
I've added the GPIO maintainers as cc so hopefully they can comment on this.
Best regards,
Krzysztof
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: [PATCH v5 3/4] regulator: max77686: Add suspend disable for some LDOs
On śro, 2014-10-29 at 11:51 +0100, Javier Martinez Canillas wrote: Hello Krzysztof, On 10/29/2014 11:44 AM, Krzysztof Kozlowski wrote: On śro, 2014-10-29 at 10:31 +, Mark Brown wrote: On Wed, Oct 29, 2014 at 11:18:54AM +0100, Krzysztof Kozlowski wrote: On śro, 2014-10-29 at 10:01 +, Mark Brown wrote: No, this isn't suspend enable control - this is normal, standard enable control and the device has no suspend enable control. You mean that for such regulator the driver shouldn't implement suspend_enable()? Yes, if there is no separate control of suspend mode in hardware then of course the driver shouldn't implement operations for things it doesn't have. Oh, thanks! I'll send fixed patch. This means that probably the max77802 (mirrored driver) should be fixed... Indeed, I had the same confusion that you had. Just to avoid duplicating work, do you want me to send a fix or are you going to include one on your series? I'll send a patch for max77802 also. Best regards, Krzysztof -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 2/4] of: Add binding document for MIPS GIC
On 10/29/2014 12:12 AM, Andrew Bresticker wrote: +- mti,available-cpu-vectors : Specifies the list of CPU interrupt vectors + to which the GIC may route interrupts. May contain up to 6 entries, one + for each of the CPU's hardware interrupt vectors. Valid values are 2 - 7. + This property is ignored if the CPU is started in EIC mode. + Wouldn't it be better to have this in the reversed sense ie: mti,nonavailable-cpu-vectors? I think the assumption that by default they're all available unless something else is connected to them which is unlikely in most cases. It can be made optional property then. I don't have a strong opinion about it though. Qais -- 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: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
Hi Hans, Rob, On 28/10/14 13:30, Hans de Goede wrote: Hi, On 10/28/2014 12:11 PM, Rob Herring wrote: Yes, I object to the binding still as it has not changed from what was previously posted. It would be helpful if you could explain why you object. Last time you said: You are mixing in a hardware description that is simply inaccurate. I then explained that this is not hardware description, but runtime state information, as it tells the kernel which clocks were chosen to drive the display (out of typically a list of possible options, depending on which output is used, etc.). Just like which memory address the bootloader has chosen to scan out the video image from. Then you got quiet, so sorry, but this time your objection really is too late. You cannot simply go quiet halfway through a discussion and then pop up again when a new version is posted to say I object yet another time, you've had your chance to make your arguments last time, and chose to stay quiet after I explained in detail that this is not hardware description but state information, so now it is simply too late. These bindings have been discussed at Plumbers with various interested people present, and the conclusion was that this really is the best way to handle this, so this patch is: Signed-off-by: Hans de Goede hdego...@redhat.com Reviewed-by: Mike Turquette mturque...@linaro.org Acked-by: Geert Uytterhoeven ge...@linux-m68k.org Reviewed-by: Maxime Ripard maxime.rip...@free-electrons.com And David Herrman who is working on simpledrm, which will be merged soon, which will also use the simplefb bindings also agrees. So we have the simplefb maintainer, simpledrm maintainer, and the clk subsystem maintainer + 2 other maintainers all agreeing on a way forward, the time for bikeshedding now really really really is over. Tomi, can you please let us know how you plan to proceed with this ? I won't merge DT bindings via fbdev tree, if a DT maintainer says no. I took Rob's silence to the earlier series as a silent ack for your explanation. Obviously that was not the case. Rob, please advice asap what should be done to the bindings to get your ack. As Hans explained above, this discussion has been going on for a long time, and afaik this series is the best way forward of all the options discussed. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH V3 2/4] of: Add binding document for MIPS GIC
On 10/29/2014 12:12 AM, Andrew Bresticker wrote: +- reg : Base address and length of the GIC registers. Also except for sead3, the base address should be properly reported by the hardware. The size is fixed (for a specific version of GIC at least - which is also reported by the hardware). So it would be nice to make this optional. Qais -- 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/3] regulator: max77686: Add suspend disable for some LDOs
Some LDOs of Maxim 77686 PMIC support disabling during system suspend
(LDO{2,6,7,8,10,11,12,14,15,16}). This was already implemented as part
of set_suspend_mode function. In that case the mode was one of:
- disable,
- normal mode,
- low power mode.
However there are no bindings for setting the mode during suspend.
Add suspend disable for LDO regulators supporting this. Re-use existing
max77686_buck_set_suspend_disable() function. This helps reducing
energy consumption during system sleep.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/regulator/max77686.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/max77686.c b/drivers/regulator/max77686.c
index 2ebc4257425b..f960cfc7fdc6 100644
--- a/drivers/regulator/max77686.c
+++ b/drivers/regulator/max77686.c
@@ -99,8 +99,8 @@ static unsigned int max77686_get_opmode_shift(int id)
}
}
-/* Some BUCKS supports Normal[ON/OFF] mode during suspend */
-static int max77686_buck_set_suspend_disable(struct regulator_dev *rdev)
+/* Some BUCKs and LDOs supports Normal[ON/OFF] mode during suspend */
+static int max77686_set_suspend_disable(struct regulator_dev *rdev)
{
unsigned int val, shift;
struct max77686_data *max77686 = rdev_get_drvdata(rdev);
@@ -195,6 +195,9 @@ static int max77686_enable(struct regulator_dev *rdev)
shift = max77686_get_opmode_shift(id);
+ if (max77686-opmode[id] == MAX77686_OFF_PWRREQ)
+ max77686-opmode[id] = MAX77686_NORMAL;
+
return regmap_update_bits(rdev-regmap, rdev-desc-enable_reg,
rdev-desc-enable_mask,
max77686-opmode[id] shift);
@@ -247,6 +250,7 @@ static struct regulator_ops max77686_ldo_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel = regulator_set_voltage_time_sel,
.set_suspend_mode = max77686_ldo_set_suspend_mode,
+ .set_suspend_disable= max77686_set_suspend_disable,
};
static struct regulator_ops max77686_buck1_ops = {
@@ -258,7 +262,7 @@ static struct regulator_ops max77686_buck1_ops = {
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel = regulator_set_voltage_time_sel,
- .set_suspend_disable= max77686_buck_set_suspend_disable,
+ .set_suspend_disable= max77686_set_suspend_disable,
};
static struct regulator_ops max77686_buck_dvs_ops = {
@@ -271,7 +275,7 @@ static struct regulator_ops max77686_buck_dvs_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel = regulator_set_voltage_time_sel,
.set_ramp_delay = max77686_set_ramp_delay,
- .set_suspend_disable= max77686_buck_set_suspend_disable,
+ .set_suspend_disable= max77686_set_suspend_disable,
};
#define regulator_desc_ldo(num){
\
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 3/3] ARM: dts: exynos4412-trats: Add suspend configuration for max77686 regulators
Add suspend to RAM configuration for max77686 regulators. Some LDOs and
bucks are disabled. This reduces energy consumption during S2R,
approximately from 17 mA to 9 mA.
Additionally remove old and not supported bindings:
- regulator-mem-off
- regulator-mem-idle
- regulator-mem-on
The max77686 driver does not parse them and they are not documented
anywere.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Reviewed-by: Chanwoo Choi cw00.c...@samsung.com
---
arch/arm/boot/dts/exynos4412-trats2.dts | 72 +++--
1 file changed, 42 insertions(+), 30 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index dd9ac66770f7..8067eb447829 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -225,7 +225,6 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-always-on;
- regulator-mem-on;
};
ldo2_reg: ldo2 {
@@ -234,7 +233,9 @@
regulator-min-microvolt = 120;
regulator-max-microvolt = 120;
regulator-always-on;
- regulator-mem-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
ldo3_reg: ldo3 {
@@ -243,7 +244,6 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
regulator-always-on;
- regulator-mem-on;
};
ldo4_reg: ldo4 {
@@ -252,7 +252,6 @@
regulator-min-microvolt = 280;
regulator-max-microvolt = 280;
regulator-always-on;
- regulator-mem-on;
};
ldo5_reg: ldo5 {
@@ -261,7 +260,6 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
regulator-always-on;
- regulator-mem-on;
};
ldo6_reg: ldo6 {
@@ -270,7 +268,9 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-always-on;
- regulator-mem-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
ldo7_reg: ldo7 {
@@ -279,7 +279,9 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-always-on;
- regulator-mem-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
ldo8_reg: ldo8 {
@@ -287,7 +289,9 @@
regulator-name = VMIPI_1.0V;
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
- regulator-mem-off;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
ldo9_reg: ldo9 {
@@ -295,7 +299,6 @@
regulator-name = CAM_ISP_MIPI_1.2V;
regulator-min-microvolt = 120;
regulator-max-microvolt = 120;
- regulator-mem-idle;
};
[PATCH v6 2/3] regulator: max77802: Remove suspend_enable
The Maxim 77802 PMIC regulators do not have special enable configuration
for suspend. The driver instead enabled them manually which is not a
best way to deal with suspend.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
drivers/regulator/max77802.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/regulator/max77802.c b/drivers/regulator/max77802.c
index 5839c4509e1f..b9958d927297 100644
--- a/drivers/regulator/max77802.c
+++ b/drivers/regulator/max77802.c
@@ -295,7 +295,6 @@ static struct regulator_ops max77802_ldo_ops_logic1 = {
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel = regulator_set_voltage_time_sel,
- .set_suspend_enable = max77802_enable,
.set_suspend_disable= max77802_set_suspend_disable,
.set_suspend_mode = max77802_set_suspend_mode,
};
@@ -328,7 +327,6 @@ static struct regulator_ops max77802_buck_16_dvs_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel = regulator_set_voltage_time_sel,
.set_ramp_delay = max77802_set_ramp_delay_4bit,
- .set_suspend_enable = max77802_enable,
.set_suspend_disable= max77802_set_suspend_disable,
};
@@ -343,7 +341,6 @@ static struct regulator_ops max77802_buck_234_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel = regulator_set_voltage_time_sel,
.set_ramp_delay = max77802_set_ramp_delay_2bit,
- .set_suspend_enable = max77802_enable,
.set_suspend_disable= max77802_set_suspend_disable,
.set_suspend_mode = max77802_set_suspend_mode,
};
@@ -359,7 +356,6 @@ static struct regulator_ops max77802_buck_dvs_ops = {
.set_voltage_sel= regulator_set_voltage_sel_regmap,
.set_voltage_time_sel = regulator_set_voltage_time_sel,
.set_ramp_delay = max77802_set_ramp_delay_2bit,
- .set_suspend_enable = max77802_enable,
.set_suspend_disable= max77802_set_suspend_disable,
};
--
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 v2 2/2] ARM: shmobile: lager: enable USB3.0
Hi Magnus-san, (2014/10/29 15:53), Magnus Damm wrote: On Fri, Oct 24, 2014 at 7:41 PM, Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com wrote: Since the PHY of USB3.0 and EHCI/OHCI ch2 are the same, the USB3.0 driver cannot use the phy driver when the EHCI/OHCI ch2 already used it: phy phy-e6590100.usb-phy.3: phy init failed -- -16 xhci-hcd: probe of ee00.usb failed with error -16 If so, we have to unbind the EHCI/OHCI ch2, and then we have to bind the USB3.0 driver as the following: echo :02:02.0 /sys/bus/pci/drivers/ehci-pci/unbind echo :02:01.0 /sys/bus/pci/drivers/ohci-pci/unbind echo ee00.usb /sys/bus/platform/drivers/xhci-hcd/bind Note that there will be pinctrl-related error messages if both internal PCI and USB3.0 are enabled but they should be just ignored: sh-pfc e606.pfc: pin GP_5_22 already requested by ee0d.pci; cannot claim for ee00.usb sh-pfc e606.pfc: pin-182 (ee00.usb) status -22 ata1: SATA link down (SStatus 0 SControl 300) sh-pfc e606.pfc: could not request pin 182 (GP_5_22) from group usb2 on device sh-pfc Signed-off-by: Yoshihiro Shimoda yoshihiro.shimoda...@renesas.com --- arch/arm/boot/dts/r8a7790-lager.dts |6 ++ 1 file changed, 6 insertions(+) Hi Shimoda-san, Thanks for your patch. I'm fine with this patch as a first step, but I'm wondering what the reason is to prioritize USB 2.0 over USB 3.0? I investigated this reason today, and I found the reason is request_firmware(). I checked the following environments: Case 1: xHCI and EHCI and OHCI are enabled =y Case 2: xHCI and EHCI and OHCI are loadable modules =m Case 3: xHCI and EHCI and OHCI are enabled =y, and CONFIG_EXTRA_FIRMWARE is enabled The results are: - In Case 1, EHCI and OHCI are probed first because xHCI didn't find the firmware. - In Case 2 and Case 3, xHCI is probed first. Is the current order just based on device init order? In my mind the expected behavior would be to always use USB 3.0 if it happens to be available in the hardware, specified in the DTS, enabled by the kernel configuration and firmware is loadable. Or does some case exist where it is better to use USB 2.0? I suspect no. I agree with you. So I wonder if you have any plans how to make USB 3.0 enabled by default on Lager? It depends on a kernel config. I'm not sure of the shmobile_defconfig strategy. But, in my opinion, one of a solution is kernel modules (this means the Case 2.) Best regards, Yoshihiro Shimoda 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
[PATCH 1/2] ARM: socfpga: Add driver for the L3 interconnect
The L3 interconnect provides Global Programmer View (GPV) registers for every
AXI master and slave on the SoC.
Although this is just a bunch of bits, syscon is not the right approach for
this IP core.
The L3 interconnect is configured with a lot of reserved holes in its memory
space. Just mapping this with regmap, what syscon would do, would lead to the
system completely hanging, if one of those areas would be touched.
One example for when this might happen is the regmap registers dump in the
debugfs.
This driver specifies also the valid readable and writable ranges of the L3
interconnect. Other drivers that want to access their GPV registers can do
so with this driver via socfpga_l3nic_regmap_by_phandle.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
.../bindings/soc/socfpga/altr,l3-nic.txt | 15 ++
drivers/soc/Kconfig| 1 +
drivers/soc/Makefile | 1 +
drivers/soc/socfpga/Kconfig| 11 +
drivers/soc/socfpga/Makefile | 1 +
drivers/soc/socfpga/l3nic.c| 221 +
include/soc/socfpga/gpv.h | 63 ++
include/soc/socfpga/l3regs.h | 194 ++
8 files changed, 507 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/socfpga/altr,l3-nic.txt
create mode 100644 drivers/soc/socfpga/Kconfig
create mode 100644 drivers/soc/socfpga/Makefile
create mode 100644 drivers/soc/socfpga/l3nic.c
create mode 100644 include/soc/socfpga/gpv.h
create mode 100644 include/soc/socfpga/l3regs.h
diff --git a/Documentation/devicetree/bindings/soc/socfpga/altr,l3-nic.txt
b/Documentation/devicetree/bindings/soc/socfpga/altr,l3-nic.txt
new file mode 100644
index ..d9491f14eed3
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socfpga/altr,l3-nic.txt
@@ -0,0 +1,15 @@
+Altera SOCFPGA L3 Network Interconnect
+--
+
+The L3 NIC provides access to Global Programmer View (GPV) registers for all
+AXI slaves and masters on the SoC.
+
+Required properties:
+- compatible : altr,l3-nic
+- reg : Should contain 1 register range (address and length)
+
+Example:
+gpv@ff80 {
+ compatible = altr,l3-nic;
+ reg = 0xff80 0x10;
+ };
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 76d6bd4da138..11db07da894f 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -1,6 +1,7 @@
menu SOC (System On Chip) specific Drivers
source drivers/soc/qcom/Kconfig
+source drivers/soc/socfpga/Kconfig
source drivers/soc/ti/Kconfig
source drivers/soc/versatile/Kconfig
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 063113d0bd38..0f89173e328a 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_ARCH_QCOM)+= qcom/
+obj-$(CONFIG_ARCH_SOCFPGA) += socfpga/
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_SOC_TI) += ti/
obj-$(CONFIG_PLAT_VERSATILE) += versatile/
diff --git a/drivers/soc/socfpga/Kconfig b/drivers/soc/socfpga/Kconfig
new file mode 100644
index ..0478c959ab2c
--- /dev/null
+++ b/drivers/soc/socfpga/Kconfig
@@ -0,0 +1,11 @@
+#
+# SoCFPGA Soc drivers
+#
+
+config SOCFPGA_L3NIC
+ tristate SoCFPGA L3 NIC-301 driver
+ depends on ARCH_SOCFPGA
+ select REGMAP_MMIO
+ default y
+ help
+ Enable configuration support for the SoCFPGA L3 AMBA Network
Interconnect.
diff --git a/drivers/soc/socfpga/Makefile b/drivers/soc/socfpga/Makefile
new file mode 100644
index ..e6616d079226
--- /dev/null
+++ b/drivers/soc/socfpga/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SOCFPGA_L3NIC) += l3nic.o
diff --git a/drivers/soc/socfpga/l3nic.c b/drivers/soc/socfpga/l3nic.c
new file mode 100644
index ..87cae77e5764
--- /dev/null
+++ b/drivers/soc/socfpga/l3nic.c
@@ -0,0 +1,221 @@
+/*
+ * Copyright 2014 Steffen Trumtrar s.trumt...@pengutronix.de
+ *
+ * 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 linux/clk.h
+#include linux/err.h
+#include linux/io.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/types.h
+#include soc/socfpga/gpv.h
+#include soc/socfpga/l3regs.h
+
+static const struct regmap_range l3nic_write_regs_range[] = {
+ regmap_reg_range(L3NIC_REMAP, L3NIC_REMAP),
+ regmap_reg_range(L3NIC_L4MAIN, L3NIC_LWHPS2FPGAREGS),
+ regmap_reg_range(L3NIC_USB1, L3NIC_NANDDATA),
+ regmap_reg_range(L3NIC_USB0, L3NIC_SDRDATA),
+ regmap_reg_range(L3NIC_L4_MAIN_FN_MOD_BM_ISS,
Re: [PATCH] DT: video: atmel_lcdc: Add example of fixed framebuffer memory
Will someone pick this up? It is laying around for 6 months now.
Thanks and best regards,
Alexander
On Tuesday 15 April 2014 17:19:16, Nicolas Ferre wrote:
On 15/04/2014 16:57, Alexander Stein :
Any feedback in this?
Actually I didn't notice it previously: thanks for the heads up.
Regards,
Alexander
On Tuesday 01 April 2014 08:28:50, Alexander Stein wrote:
This drivers allows a fixed framebuffer memory to be set by an additional
IORESOURCE_MEM resource. Thus add an example to the DT documentation.
Signed-off-by: Alexander Stein alexander.st...@systec-electronic.com
Indeed, it can be useful:
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
---
Actually I stumbled myself over this wondering how can I use this specific
feature. In the end I found it myself my coincidence. So it's best to add
this as an example for other people maybe not that experienced on
device-tree.
Documentation/devicetree/bindings/video/atmel,lcdc.txt | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/video/atmel,lcdc.txt
b/Documentation/devicetree/bindings/video/atmel,lcdc.txt
index 1ec175e..92492b7 100644
--- a/Documentation/devicetree/bindings/video/atmel,lcdc.txt
+++ b/Documentation/devicetree/bindings/video/atmel,lcdc.txt
@@ -10,7 +10,9 @@ Required properties:
atmel,at91sam9g45es-lcdc ,
atmel,at91sam9rl-lcdc ,
atmel,at32ap-lcdc
-- reg : Should contain 1 register ranges(address and length)
+- reg : Should contain 1 register ranges(address and length).
+ Can contain an additional register range(address and length)
+ for fixed framebuffer memory.Usefull for dedicated memories.
- interrupts : framebuffer controller interrupt
- display: a phandle pointing to the display node
@@ -35,6 +37,14 @@ Example:
};
+Example for fixed framebuffer memory:
+
+ fb0: fb@0x0050 {
+ compatible = atmel,at91sam9263-lcdc;
+ reg = 0x0070 0x1000 0x7000 0x20;
+ [...]
+ };
+
Atmel LCDC Display
-
Required properties (as per of_videomode_helper):
--
Dipl.-Inf. Alexander Stein
SYS TEC electronic GmbH
Am Windrad 2
08468 Heinsdorfergrund
Tel.: 03765 38600-1156
Fax: 03765 38600-4100
Email: alexander.st...@systec-electronic.com
Website: www.systec-electronic.com
Managing Director: Dipl.-Phys. Siegmar Schmidt
Commercial registry: Amtsgericht Chemnitz, HRB 28082
--
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 0/7] This is the 1st version of suspend for RK3288.
RK3288 can shut down the cpu, gpu and other device controllers in suspend, and it will pull the GLOBAL_PWROFF pin to high in the final stage of the process of suspend, pull the pin to low again when resume. Changes in v6: - modify comments - get rid of the save/restore of SRAM - doing the copy of resume code once at init time - remove ROCKCHIP_ARM_OFF_LOGIC_DEEP from rk3288_fill_in_bootram - add of_platform_populate in rockchip_dt_init - change pmu_intmem@ff72 to sram@ff72 - change pmu_intmem@ff72 to sram@ff72 Changes in v5: - reset-author - use __maybe_unused annotation - add pinctrl_force_default() in the error case - modify comments - use rk3288_bootram_sz for memcpy size - fixed error of sram save and restore - change the size of sram in example - change size to 4k Changes in v4: - use SIMPLE_DEV_PM_OPS for suspend/resume struct - remove grf regmap Changes in v3: - move the pinmux of gpio6_c6 save and restore to pinctrl-rockchip Changes in v2: - __raw_readl/__raw_writel replaced by readl_relaxed/writel_relaxed - add the regulator calls in prepare and finish. - add the pinmux of gpio6_c6 save and restore - put rockchip,rk3288-pmu-sram to first Chris Zhong (7): pinctrl: rockchip: add suspend/resume functions pinctrl: rockchip: save and restore gpio6_c6 pinmux in suspend/resume clk: rockchip: RK3288: add suspend and resume ARM: rockchip: add suspend and resume for RK3288 ARM: rockchip: Add pmu-sram binding ARM: dts: add RK3288 suspend support ARM: dts: add suspend voltage setting for RK808 .../devicetree/bindings/arm/rockchip/pmu-sram.txt | 16 ++ arch/arm/boot/dts/rk3288-evb-rk808.dts | 16 +- arch/arm/boot/dts/rk3288.dtsi | 11 + arch/arm/mach-rockchip/Makefile|1 + arch/arm/mach-rockchip/pm.c| 278 arch/arm/mach-rockchip/pm.h| 103 arch/arm/mach-rockchip/rockchip.c |8 + arch/arm/mach-rockchip/sleep.S | 90 +++ drivers/clk/rockchip/clk-rk3288.c | 60 + drivers/pinctrl/pinctrl-rockchip.c | 46 10 files changed, 628 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt create mode 100644 arch/arm/mach-rockchip/pm.c create mode 100644 arch/arm/mach-rockchip/pm.h create mode 100644 arch/arm/mach-rockchip/sleep.S -- 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 7/7] ARM: dts: add suspend voltage setting for RK808
global_pwroff would be pull to high when RK3288 entering suspend,
this pin is a sleep signal for RK808, so RK808 could goto sleep
mode, and some regulators would be disable.
Signed-off-by: Chris Zhong z...@rock-chips.com
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/arm/boot/dts/rk3288-evb-rk808.dts | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288-evb-rk808.dts
b/arch/arm/boot/dts/rk3288-evb-rk808.dts
index ff522f8..319fcb6 100644
--- a/arch/arm/boot/dts/rk3288-evb-rk808.dts
+++ b/arch/arm/boot/dts/rk3288-evb-rk808.dts
@@ -27,7 +27,7 @@
interrupt-parent = gpio0;
interrupts = 4 IRQ_TYPE_LEVEL_LOW;
pinctrl-names = default;
- pinctrl-0 = pmic_int;
+ pinctrl-0 = pmic_int global_pwroff;
rockchip,system-power-controller;
wakeup-source;
#clock-cells = 1;
@@ -46,6 +46,7 @@
regulator-min-microvolt = 75;
regulator-max-microvolt = 130;
regulator-name = vdd_arm;
+ regulator-suspend-mem-disabled;
};
vdd_gpu: DCDC_REG2 {
@@ -54,12 +55,14 @@
regulator-min-microvolt = 85;
regulator-max-microvolt = 125;
regulator-name = vdd_gpu;
+ regulator-suspend-mem-disabled;
};
vcc_ddr: DCDC_REG3 {
regulator-always-on;
regulator-boot-on;
regulator-name = vcc_ddr;
+ regulator-suspend-mem-enabled;
};
vcc_io: DCDC_REG4 {
@@ -68,6 +71,7 @@
regulator-min-microvolt = 330;
regulator-max-microvolt = 330;
regulator-name = vcc_io;
+ regulator-suspend-mem-microvolt = 330;
};
vccio_pmu: LDO_REG1 {
@@ -76,6 +80,7 @@
regulator-min-microvolt = 330;
regulator-max-microvolt = 330;
regulator-name = vccio_pmu;
+ regulator-suspend-mem-microvolt = 330;
};
vcc_tp: LDO_REG2 {
@@ -84,6 +89,7 @@
regulator-min-microvolt = 330;
regulator-max-microvolt = 330;
regulator-name = vcc_tp;
+ regulator-suspend-mem-disabled;
};
vdd_10: LDO_REG3 {
@@ -92,6 +98,7 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-name = vdd_10;
+ regulator-suspend-mem-microvolt = 100;
};
vcc18_lcd: LDO_REG4 {
@@ -100,6 +107,7 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
regulator-name = vcc18_lcd;
+ regulator-suspend-mem-disabled;
};
vccio_sd: LDO_REG5 {
@@ -108,6 +116,7 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 330;
regulator-name = vccio_sd;
+ regulator-suspend-mem-disabled;
};
vdd10_lcd: LDO_REG6 {
@@ -116,6 +125,7 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-name = vdd10_lcd;
+ regulator-suspend-mem-disabled;
};
vcc_18: LDO_REG7 {
@@ -124,6 +134,7 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
regulator-name = vcc_18;
+ regulator-suspend-mem-microvolt = 180;
};
vcca_codec: LDO_REG8 {
@@ -132,18 +143,21 @@
regulator-min-microvolt = 330;
regulator-max-microvolt =
[PATCH v6 6/7] ARM: dts: add RK3288 suspend support
add pmu sram node for suspend, add global_pwroff pinctrl.
The pmu sram is used to store the resume code.
global_pwroff is held low level at work, it would be pull to high
when entering suspend. reference this in the board DTS file since
some boards need it.
Signed-off-by: Tony Xie x...@rock-chips.com
Signed-off-by: Chris Zhong z...@rock-chips.com
Reviewed-by: Doug Anderson diand...@chromium.org
Tested-by: Doug Anderson diand...@chromium.org
---
Changes in v6:
- change pmu_intmem@ff72 to sram@ff72
Changes in v5:
- change size to 4k
Changes in v4: None
Changes in v3: None
Changes in v2:
- put rockchip,rk3288-pmu-sram to first
arch/arm/boot/dts/rk3288.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 874e66d..248c349 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -439,6 +439,11 @@
status = disabled;
};
+ sram@ff72 {
+ compatible = rockchip,rk3288-pmu-sram, mmio-sram;
+ reg = 0xff72 0x1000;
+ };
+
pmu: power-management@ff73 {
compatible = rockchip,rk3288-pmu, syscon;
reg = 0xff73 0x100;
@@ -634,6 +639,12 @@
bias-disable;
};
+ sleep {
+ global_pwroff: global-pwroff {
+ rockchip,pins = 0 0 RK_FUNC_1 pcfg_pull_none;
+ };
+ };
+
i2c0 {
i2c0_xfer: i2c0-xfer {
rockchip,pins = 0 15 RK_FUNC_1
pcfg_pull_none,
--
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 5/7] ARM: rockchip: Add pmu-sram binding
The pmu-sram is used to store resume code, suspend/resume need get the
address of it. Therefore add a binding and documentation for it.
Signed-off-by: Tony Xie x...@rock-chips.com
Signed-off-by: Chris Zhong z...@rock-chips.com
Reviewed-by: Doug Anderson diand...@chromium.org
---
Changes in v6:
- change pmu_intmem@ff72 to sram@ff72
Changes in v5:
- change the size of sram in example
Changes in v4: None
Changes in v3: None
Changes in v2: None
.../devicetree/bindings/arm/rockchip/pmu-sram.txt | 16
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
b/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
new file mode 100644
index 000..6b42fda
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
@@ -0,0 +1,16 @@
+Rockchip SRAM for pmu:
+--
+
+The sram of pmu is used to store the function of resume from maskrom(the 1st
+level loader). This is a common use of the pmu-sram because it keeps power
+even in low power states in the system.
+
+Required node properties:
+- compatible : should be rockchip,rk3288-pmu-sram
+- reg : physical base address and the size of the registers window
+
+Example:
+ sram@ff72 {
+ compatible = rockchip,rk3288-pmu-sram, mmio-sram;
+ reg = 0xff72 0x1000;
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: spi: Export single device registration method and accessors (v2)
On Wed, Oct 29, 2014 at 01:48:06PM +0200, Pantelis Antoniou wrote: On Oct 29, 2014, at 12:14 , Mark Brown broo...@kernel.org wrote: This feels like there is an abstraction problem somewhere, whatever code is supposed to use this is going to need to be taught about each individual bus which is going to be tedious, I would expect that we'd have something like the bus being able to provide a callback which will get invoked whenever a new node appears on the parent node for the bus. There’s a whole patchset that does exactly this. Look at OF: spi: Add OF notifier handler” and you’ll where this is used. I deleted that unread I'm afraid; one of the reasons that you should use subject lines matching the styles for the subsystems is that it's one of the things people use to filter out things that actually need attention, if things are busy things that at first glance don't look terribly relevant (like changes to the OF core in this case) are likely to get looked at less urgently or just skipped. A quick glance suggests that this is adding code inside the SPI core so it's still not explaining why anything is being exported, can you clarify please? SubmittingPatches says. Please also try to keep your CC list sane, CCing random people just means that you're increasing the volume of mail they have to process. I'm surprised kernel.org accepts so many CCs. I have to say I don't recall ever seeing v1... All of them are in the CC list for a reason. This is a single, standalone SPI patch - you didn't send it as part of a series (which is the only reason I read it). signature.asc Description: Digital signature
Re: [PATCH RESEND V4 4/9] pinctrl: tegra-xusb: Add USB PHY support
On Tue, Oct 28, 2014 at 03:27:51PM -0700, Andrew Bresticker wrote:
[...]
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index c6a66de..0f4cdef 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -163,6 +163,7 @@ config PINCTRL_TEGRA_XUSB
select GENERIC_PHY
select PINCONF
select PINMUX
+ select MAILBOX
I think this should be a depends on because we use the mailbox API as
a client rather than a provider.
diff --git a/drivers/pinctrl/pinctrl-tegra-xusb.c
b/drivers/pinctrl/pinctrl-tegra-xusb.c
[...]
struct tegra_xusb_padctl_function {
const char *name;
const char * const *groups;
@@ -72,6 +222,16 @@ struct tegra_xusb_padctl_soc {
const struct tegra_xusb_padctl_lane *lanes;
unsigned int num_lanes;
+
+ u32 rx_wander;
+ u32 rx_eq;
+ u32 cdr_cntl;
+ u32 dfe_cntl;
+ u32 hs_slew;
+ u32 ls_rslew[TEGRA_XUSB_UTMI_PHYS];
+ u32 hs_discon_level;
+ u32 spare_in;
+ int hsic_port_offset;
unsigned int? Are these values all SoC-specific or can they vary per
board?
+struct tegra_xusb_fuse_calibration {
+ u32 hs_curr_level[TEGRA_XUSB_UTMI_PHYS];
+ u32 hs_iref_cap;
+ u32 hs_term_range_adj;
+ u32 hs_squelch_level;
+};
+
+struct tegra_xusb_usb3_port {
+ int lane;
unsigned
+ bool context_saved;
+ u32 tap1_val;
+ u32 amp_val;
+ u32 ctle_z_val;
+ u32 ctle_g_val;
+};
+
[...]
+static inline bool is_otg_lane(unsigned int lane)
+{
+ return lane = TEGRA_XUSB_PADCTL_PIN_OTG_0
+ lane = TEGRA_XUSB_PADCTL_PIN_OTG_2;
+}
+
+static inline bool is_hsic_lane(unsigned int lane)
+{
+ return lane = TEGRA_XUSB_PADCTL_PIN_HSIC_0
+ lane = TEGRA_XUSB_PADCTL_PIN_HSIC_1;
+}
+
+static inline bool is_pcie_or_sata_lane(unsigned int lane)
+{
+ return lane = TEGRA_XUSB_PADCTL_PIN_PCIE_0
+ lane = TEGRA_XUSB_PADCTL_PIN_SATA_0;
+}
+
+static int lane_to_usb3_port(struct tegra_xusb_padctl *padctl,
+ unsigned int lane)
+{
+ int i;
unsigned
+
+ for (i = 0; i TEGRA_XUSB_USB3_PHYS; i++) {
+ if (padctl-usb3_ports[i].lane == lane)
+ return i;
+ }
+
+ return -1;
+}
Why not return a proper error code here that callers can simply
propagate?
Also, for consistency, I'd prefer the is_*_lane() functions to be
renamed to lane_is_*().
@@ -321,6 +561,7 @@ static int tegra_xusb_padctl_pinconf_group_get(struct
pinctrl_dev *pinctrl,
struct tegra_xusb_padctl *padctl = pinctrl_dev_get_drvdata(pinctrl);
const struct tegra_xusb_padctl_lane *lane;
enum tegra_xusb_padctl_param param;
+ int port;
u32 value;
The variable here were sorted in inverse christmas tree order, so port
should be below value.
+static int usb3_phy_to_port(struct phy *phy)
+{
+ struct tegra_xusb_padctl *padctl = phy_get_drvdata(phy);
+ int i;
unsigned
+
+ for (i = 0; i TEGRA_XUSB_USB3_PHYS; i++) {
+ if (phy == padctl-phys[TEGRA_XUSB_PADCTL_USB3_P0 + i])
+ break;
You could simply return i here and then BUG_ON unconditionally.
+ }
+ BUG_ON(i == TEGRA_XUSB_USB3_PHYS);
+
+ return i;
+}
Actually, thinking about it some more, perhaps making this a WARN_ON()
and returning an error so that we can continue and propagate the error
would be more useful. BUG_ON() will completely hang the kernel with no
way out but rebooting. WARN_ON() will give a hint about something being
wrong and returning an error will allow the kernel to continue to run,
which might be the only way to diagnose and fix the problem, even if it
means that USB 3.0 support will be disabled.
+static void usb3_phy_save_context(struct tegra_xusb_padctl *padctl, int port)
unsigned for port...
+{
+ int lane = padctl-usb3_ports[port].lane;
... and lane.
+ u32 value, offset;
+
+ padctl-usb3_ports[port].context_saved = true;
What's the purpose of saving the context here? This seems to be
triggered by a request from XUSB, but it's then restored when the PHY is
powered on. How does that even happen? Won't the PHY stay powered all
the time? Or shouldn't the context be saved when powering off the PHY?
+static int utmi_phy_to_port(struct phy *phy)
+{
+ struct tegra_xusb_padctl *padctl = phy_get_drvdata(phy);
+ int i;
+
+ for (i = 0; i TEGRA_XUSB_UTMI_PHYS; i++) {
+ if (phy == padctl-phys[TEGRA_XUSB_PADCTL_UTMI_P0 + i])
+ break;
+ }
+ BUG_ON(i == TEGRA_XUSB_UTMI_PHYS);
+
+ return i;
+}
Same comment as before.
+static int utmi_phy_power_on(struct phy *phy)
+{
+ struct tegra_xusb_padctl *padctl = phy_get_drvdata(phy);
+ int port = utmi_phy_to_port(phy);
+ int ret;
The driver uses err as the name for variables that store error codes.
I'd like to remain consistent with that.
+static int
Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature
On Tue, Oct 28, 2014 at 03:16:10PM +, Russell King - ARM Linux wrote:
On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote:
That's not what I was trying to refer to. But the patch set explicitly
allows for multiple, prioritised power-off handlers, which can power
off a board in different ways and with various degrees of success.
Specifically, it allows for fallback handlers in case one or more
power-off handlers fail.
So if we allow for that, what is to prevent the final power-off handler
from failing? And should this not be logged by arch code in the same way
as failure to restart is?
And how is that different from having a set of power-off handlers, and
reporting when each individual one fails? Don't you want to know if
your primary high priority reboot handler fails, just as much as you
want to know if your final last-resort power-off handler fails?
Good point. Failed power-off should probably be logged by the power-off
call chain implementation (which seems to makes notifier chains a bad
fit).
And what about any power-off latencies? Should this always be dealt with
in the power-off handler?
Again, if it's predictable and high, as in the OMAP RTC case, it should
go in the handler. But what if it's just normal bus latencies
(peripheral busses, i2c, or whatever people may come up with)?
Should there always be a short delay before calling the next handler?
Or different from having no power-off handlers.
That is actually quite different, as in that case we call machine_halt
instead (via kernel_halt).
Here's the x86 code:
void machine_power_off(void)
{
machine_ops.power_off();
}
struct machine_ops machine_ops = {
.power_off = native_machine_power_off,
...
static void native_machine_power_off(void)
{
if (pm_power_off) {
if (!reboot_force)
machine_shutdown();
pm_power_off();
}
/* A fallback in case there is no PM info available */
tboot_shutdown(TB_SHUTDOWN_HALT);
}
void tboot_shutdown(u32 shutdown_type)
{
void (*shutdown)(void);
if (!tboot_enabled())
return;
See - x86 can very well just fall straight back out of machine_power_off()
if there's no pm_power_off() hook and tboot is not enabled.
I never doubted that, but is the right thing to do? Not all arches do it
that way.
And what about the killing of init? Shall we simply consider that a
systemd bug?
case LINUX_REBOOT_CMD_POWER_OFF:
kernel_power_off();
do_exit(0);
break;
If power-off fails (for whatever reason), do_exit(0) will trigger a
panic when called from PID 1.
Johan
--
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] rtc: omap: add support for pmic_power_en
On Tue, Oct 28, 2014 at 02:18:05PM -0700, Andrew Morton wrote: On Tue, 28 Oct 2014 09:36:33 +0100 Johan Hovold jo...@kernel.org wrote: But it doesn't explain *why* we want the alarm to trigger before returning. Should we really require every power-off handler to document arch behaviour (even if its inconsistent and currently undocumented); in this case that some arches return to user-space where we may oops if called from process 0 (e.g. systemd, but not if using sysvinit)? The kernel really doesn't have a problem related to excessive amounts of useful code comments :( The bottom line is: did I provide a reader with the ability to understand why the code is this way? If no then improvements beckon. This does look like one code site where an elaborate explanation is warranted. There's no way in which a reader can get to your above paragraph from the current rtc-omap.c. I agree with you that I should add a comment on why that mdelay is there to make it perfectly clear and obvious that it's purpose is to let the alarm trigger, which in turn causes the pmic to power off the system. It is a power-off handler, and any power-off handler should not return until it has at least attempted to power off the system. In this case, that mandates a two-second delay. So far, so good. I don't agree with you that every power-off handler should document what happens if it fails to power-off the system. That is, to describe what arches will happily return to user space, and under what conditions (e.g. what init system is used) that this will cause a panic. If anything that belongs in arch code or kernel/reboot.c, and is also something that is likely to change over time (consider the power-off-handler call chains). Johan -- 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] rtc: omap: add support for pmic_power_en
On Tue, Oct 28, 2014 at 09:36:33AM +0100, Johan Hovold wrote: On Mon, Oct 27, 2014 at 03:40:31PM -0700, Andrew Morton wrote: On Mon, 27 Oct 2014 09:09:28 +0100 Johan Hovold jo...@kernel.org wrote: But in general, how do you want to handle updates to a single patch in a series you already have in your tree? Do you prefer a proper incremental-fix patch (with commit message), just an updated single patch, or a resend of the whole series? How should I best send the updated patch? Can you just replace the current three incremental patches: rtc-omap-add-support-for-pmic_power_en.patch rtc-omap-add-support-for-pmic_power_en-v3.patch rtc-omap-add-support-for-pmic_power_en-v3-fix.patch that you have in your tree, with a single new v4 which adds a more elaborate comment? Thanks, Johan -- 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 00/20] rtc: omap: fixes and power-off feature
Johan:. do you really plan to use this poweroff-source property ? As
you proposed a renaming few days ago...
I don't really want to waste time to propose patches to fix things
incrementally and rename it if the old one is used...
Romain
2014-10-29 13:34 GMT+01:00 Johan Hovold jo...@kernel.org:
On Tue, Oct 28, 2014 at 03:16:10PM +, Russell King - ARM Linux wrote:
On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote:
That's not what I was trying to refer to. But the patch set explicitly
allows for multiple, prioritised power-off handlers, which can power
off a board in different ways and with various degrees of success.
Specifically, it allows for fallback handlers in case one or more
power-off handlers fail.
So if we allow for that, what is to prevent the final power-off handler
from failing? And should this not be logged by arch code in the same way
as failure to restart is?
And how is that different from having a set of power-off handlers, and
reporting when each individual one fails? Don't you want to know if
your primary high priority reboot handler fails, just as much as you
want to know if your final last-resort power-off handler fails?
Good point. Failed power-off should probably be logged by the power-off
call chain implementation (which seems to makes notifier chains a bad
fit).
And what about any power-off latencies? Should this always be dealt with
in the power-off handler?
Again, if it's predictable and high, as in the OMAP RTC case, it should
go in the handler. But what if it's just normal bus latencies
(peripheral busses, i2c, or whatever people may come up with)?
Should there always be a short delay before calling the next handler?
Or different from having no power-off handlers.
That is actually quite different, as in that case we call machine_halt
instead (via kernel_halt).
Here's the x86 code:
void machine_power_off(void)
{
machine_ops.power_off();
}
struct machine_ops machine_ops = {
.power_off = native_machine_power_off,
...
static void native_machine_power_off(void)
{
if (pm_power_off) {
if (!reboot_force)
machine_shutdown();
pm_power_off();
}
/* A fallback in case there is no PM info available */
tboot_shutdown(TB_SHUTDOWN_HALT);
}
void tboot_shutdown(u32 shutdown_type)
{
void (*shutdown)(void);
if (!tboot_enabled())
return;
See - x86 can very well just fall straight back out of machine_power_off()
if there's no pm_power_off() hook and tboot is not enabled.
I never doubted that, but is the right thing to do? Not all arches do it
that way.
And what about the killing of init? Shall we simply consider that a
systemd bug?
case LINUX_REBOOT_CMD_POWER_OFF:
kernel_power_off();
do_exit(0);
break;
If power-off fails (for whatever reason), do_exit(0) will trigger a
panic when called from PID 1.
Johan
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/2] mtd: nand: add sunxi NAND flash controller support
Hi Brian,
On Tue, 28 Oct 2014 11:13:11 -0700
Brian Norris computersforpe...@gmail.com wrote:
Hi Boris,
On Tue, Oct 21, 2014 at 03:08:41PM +0200, Boris Brezillon wrote:
+static int sunxi_nand_hw_ecc_ctrl_init(struct mtd_info *mtd,
+ struct nand_ecc_ctrl *ecc,
+ struct device_node *np)
+{
+ struct nand_ecclayout *layout;
+ int i, j;
+ int ret;
+
+ ret = sunxi_nand_hw_common_ecc_ctrl_init(mtd, ecc, np);
+ if (ret)
+ return ret;
+
+ ecc-read_page = sunxi_nfc_hw_ecc_read_page;
+ ecc-write_page = sunxi_nfc_hw_ecc_write_page;
+ layout = ecc-layout;
+
+ for (i = 0; i ecc-steps; i++) {
Hmm, did you retest this since changing this to ecc-steps? I think this
won't work, since ecc-steps is only initialized in nand_scan_tail(),
which comes after this. I only recommended the change for the
{read,write}_page() type of functions, not the initialization functions.
[snip the rest]
So I'd suggest the following additional patch, and otherwise, the series
is fine with me. If you give your ack, I can just squash this in and
apply it to my tree:
It works, you can squash those changes into my first patch.
Thanks,
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: [PATCH v2 00/20] rtc: omap: fixes and power-off feature
[ Please do not top-post. ] On Wed, Oct 29, 2014 at 01:55:49PM +0100, Romain Perier wrote: Johan:. do you really plan to use this poweroff-source property ? As you proposed a renaming few days ago... I don't really want to waste time to propose patches to fix things incrementally and rename it if the old one is used... Why would I want to use your retracted renaming proposal for this property (i.e. poweroff-source)? These patches use ti,system-power-controller and the vendor prefix will be dropped when your patches have been merged. Johan -- 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 00/20] rtc: omap: fixes and power-off feature
On Wed, Oct 29, 2014 at 01:34:18PM +0100, Johan Hovold wrote:
On Tue, Oct 28, 2014 at 03:16:10PM +, Russell King - ARM Linux wrote:
And how is that different from having a set of power-off handlers, and
reporting when each individual one fails? Don't you want to know if
your primary high priority reboot handler fails, just as much as you
want to know if your final last-resort power-off handler fails?
Good point. Failed power-off should probably be logged by the power-off
call chain implementation (which seems to makes notifier chains a bad
fit).
And what about any power-off latencies? Should this always be dealt with
in the power-off handler?
Again, if it's predictable and high, as in the OMAP RTC case, it should
go in the handler. But what if it's just normal bus latencies
(peripheral busses, i2c, or whatever people may come up with)?
Should there always be a short delay before calling the next handler?
If the handler has determined that it has failed, then why delay before
trying the next handler? At the point it has decided it has failed,
surely that's after it has waited sufficient time to determine that
failure?
Or different from having no power-off handlers.
That is actually quite different, as in that case we call machine_halt
instead (via kernel_halt).
Today, ARM does exactly what x86 does. If there's no power off handler
registered, machine_power_off() shuts down other CPUs and returns.
Here's the x86 code:
void machine_power_off(void)
{
machine_ops.power_off();
}
struct machine_ops machine_ops = {
.power_off = native_machine_power_off,
...
static void native_machine_power_off(void)
{
if (pm_power_off) {
if (!reboot_force)
machine_shutdown();
pm_power_off();
}
/* A fallback in case there is no PM info available */
tboot_shutdown(TB_SHUTDOWN_HALT);
}
void tboot_shutdown(u32 shutdown_type)
{
void (*shutdown)(void);
if (!tboot_enabled())
return;
See - x86 can very well just fall straight back out of machine_power_off()
if there's no pm_power_off() hook and tboot is not enabled.
I never doubted that, but is the right thing to do? Not all arches do it
that way.
Well, the biggest question there is: if the power off or restart syscall
fails, what is the _generic_ non-architecture action which is supposed to
happen?
Whatever the answer is to that question, that action should be performed
by the _generic_ non-architecture code, rather than having the same
implementation spread across all 30 architectures which the kernel
supports today.
And what about the killing of init? Shall we simply consider that a
systemd bug?
case LINUX_REBOOT_CMD_POWER_OFF:
kernel_power_off();
do_exit(0);
break;
If power-off fails (for whatever reason), do_exit(0) will trigger a
panic when called from PID 1.
Oh, systemd calls this from PID1? I guess that's another reason to hate
systemd with vitriol. :) SysVinit and upstart implementations call it
from the halt command, which is itself normally run from a script,
which totally avoids that problem.
I'm quite sure the insane systemd lobby will scream that this is a kernel
bug and will want to change it somehow, just like they want to change the
kernel in soo many other silly ways.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
--
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 00/20] rtc: omap: fixes and power-off feature
This just to be sure, nothing more. I did read that you mentionned poweroff-source earlier. However If I am wrong, my bad, everything is fine. 2014-10-29 14:00 GMT+01:00 Johan Hovold jo...@kernel.org: [ Please do not top-post. ] On Wed, Oct 29, 2014 at 01:55:49PM +0100, Romain Perier wrote: Johan:. do you really plan to use this poweroff-source property ? As you proposed a renaming few days ago... I don't really want to waste time to propose patches to fix things incrementally and rename it if the old one is used... Why would I want to use your retracted renaming proposal for this property (i.e. poweroff-source)? These patches use ti,system-power-controller and the vendor prefix will be dropped when your patches have been merged. Johan -- 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/2] ARM: dts: exynos4412-odroid-common: add reboot handler
This patch adds node which enables board-specific reboot/poweroff code.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 4ebb5572d8d0..3544bb255e58 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -32,6 +32,12 @@
};
};
+ odroid_reboot {
+ compatible = hardkernel,odroid-reboot;
+ samsung,pmureg-phandle = pmu_system_controller;
+ reset-gpios = gpk1 2 0;
+ };
+
i2s0: i2s@0383 {
pinctrl-0 = i2s0_bus;
pinctrl-names = default;
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: rockchip: use internal pull-up resistors on I2C busses
Hi Addy, Max, Wolfram,
after Doug's explanation of disfavour [0] and Julien's subsequent response I'm
not sure which direction to go. So if possible I'd like to collect some more
opinions of people knowing a lot more about i2c internals than myself :-) .
Thanks
Heiko
[0] http://lists.infradead.org/pipermail/linux-rockchip/2014-October/000934.html
Am Dienstag, 28. Oktober 2014, 11:36:36 schrieb Julien CHAUVEAU:
According to the I2C bus specification, it is required to use pull-up
resistors on the clock and data lines. Probing the I2C busses with
i2cdetect results in bad results when no devices are connected and no
external resistors are used.
This patch configures the I2C busses to use the internal pull-up resistors
on the RK3066, RK3188 and RK3288 Rockchip processors. It should also be
noted that these default pull settings match the original configuration on
these SoCs.
Below is the results of using i2cdetect on a I2C bus with no devices
connected before (1) and after (2) applying this patch.
(1) root@localhost:~# i2cdetect -y 3
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
10: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f
20: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
30: -- -- -- -- -- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x81, state: 2
-- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x80, state: 2
-- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x80, state: 2
-- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x80, state: 3
-- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x80, state: 3
-- rk3x-i2c 2005a000.i2c: timeout, ipd: 0x80, state: 3
...
(2) root@localhost:~# i2cdetect -y 3
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
Signed-off-by: Julien CHAUVEAU julien.chauv...@neo-technologies.fr
---
Changes since v1:
- fix the rk3066a pull settings (only available is pull_none/pull_default)
- remove the warnings in the results of i2cdetect
arch/arm/boot/dts/rk3066a.dtsi | 20 ++--
arch/arm/boot/dts/rk3188.dtsi | 20 ++--
arch/arm/boot/dts/rk3288.dtsi | 24
3 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/arch/arm/boot/dts/rk3066a.dtsi b/arch/arm/boot/dts/rk3066a.dtsi
index ad9c2db..dbc1a0b 100644
--- a/arch/arm/boot/dts/rk3066a.dtsi
+++ b/arch/arm/boot/dts/rk3066a.dtsi
@@ -202,36 +202,36 @@
i2c0 {
i2c0_xfer: i2c0-xfer {
- rockchip,pins = RK_GPIO2 28 RK_FUNC_1
pcfg_pull_none,
- RK_GPIO2 29 RK_FUNC_1
pcfg_pull_none;
+ rockchip,pins = RK_GPIO2 28 RK_FUNC_1
pcfg_pull_default,
+ RK_GPIO2 29 RK_FUNC_1
pcfg_pull_default;
};
};
i2c1 {
i2c1_xfer: i2c1-xfer {
- rockchip,pins = RK_GPIO2 30 RK_FUNC_1
pcfg_pull_none,
- RK_GPIO2 31 RK_FUNC_1
pcfg_pull_none;
+ rockchip,pins = RK_GPIO2 30 RK_FUNC_1
pcfg_pull_default,
+ RK_GPIO2 31 RK_FUNC_1
pcfg_pull_default;
};
};
i2c2 {
i2c2_xfer: i2c2-xfer {
- rockchip,pins = RK_GPIO3 0 RK_FUNC_1
pcfg_pull_none,
- RK_GPIO3 1 RK_FUNC_1
pcfg_pull_none;
+ rockchip,pins = RK_GPIO3 0 RK_FUNC_1
pcfg_pull_default,
+ RK_GPIO3 1 RK_FUNC_1
pcfg_pull_default;
};
};
i2c3 {
i2c3_xfer: i2c3-xfer {
- rockchip,pins = RK_GPIO3 2 RK_FUNC_2
pcfg_pull_none,
- RK_GPIO3 3 RK_FUNC_2
pcfg_pull_none;
+ rockchip,pins = RK_GPIO3 2 RK_FUNC_2
pcfg_pull_default,
+ RK_GPIO3 3 RK_FUNC_2
pcfg_pull_default;
};
};
i2c4 {
i2c4_xfer: i2c4-xfer {
- rockchip,pins = RK_GPIO3 4 RK_FUNC_1
pcfg_pull_none,
- RK_GPIO3 5 RK_FUNC_1
pcfg_pull_none;
+ rockchip,pins = RK_GPIO3 4 RK_FUNC_1
pcfg_pull_default,
+
[PATCH 1/2] power: reset: add driver for Hardkernel's Odroid boards
This patch adds a driver implementing correct reboot and poweroff
procedures for Exynos4412-based Hardkernel's Odroid X/X2/U2/U3/U3+
boards.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
.../bindings/power/reset/odroid-reset.txt | 18
drivers/power/reset/Kconfig| 6 ++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/odroid-reboot.c| 119 +
4 files changed, 144 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/reset/odroid-reset.txt
create mode 100644 drivers/power/reset/odroid-reboot.c
diff --git a/Documentation/devicetree/bindings/power/reset/odroid-reset.txt
b/Documentation/devicetree/bindings/power/reset/odroid-reset.txt
new file mode 100644
index ..86471a463518
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/odroid-reset.txt
@@ -0,0 +1,18 @@
+* Device tree bindings for Hardkernel's Exynos4412 based Odroid boards
+
+This node is intended to allow proper system reboot and power off of
+Odroid X/X2/U2/U3/U3+ boards with eMMC storage. Without this node, board
+hangs during standard reset procedure.
+
+Required properties:
+- compatible: hardkernel,odroid-reboot
+- samsung,pmureg-phandle: phandle to Exynos PMU node
+- reset-gpios: phandle and gpio-specifier to the GPIO pin
+ connected to the eMMC_nDET
+
+Example:
+odroid_reboot {
+ compatible = hardkernel,odroid-reboot;
+ samsung,pmureg-phandle = pmu_system_controller;
+ reset-gpio = gpk1 2 0;
+};
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index f65ff49bb275..f02b13d5344f 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -84,6 +84,12 @@ config POWER_RESET_LTC2952
This driver supports an external powerdown trigger and board power
down via the LTC2952. Bindings are made in the device tree.
+config POWER_RESET_ODROID
+ bool Hardkernel's Exynos4412 based Odroid reboot driver
+ depends on POWER_RESET ARCH_EXYNOS
+ help
+ Power off and restart support for Odroid boards.
+
config POWER_RESET_QNAP
bool QNAP power-off driver
depends on OF_GPIO PLAT_ORION
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index 76ce1c59469b..178ee86eb813 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
+obj-$(CONFIG_POWER_RESET_ODROID) += odroid-reboot.o
obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
obj-$(CONFIG_POWER_RESET_SUN6I) += sun6i-reboot.o
diff --git a/drivers/power/reset/odroid-reboot.c
b/drivers/power/reset/odroid-reboot.c
new file mode 100644
index ..823e93539220
--- /dev/null
+++ b/drivers/power/reset/odroid-reboot.c
@@ -0,0 +1,119 @@
+/*
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * 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 linux/delay.h
+#include linux/gpio.h
+#include linux/io.h
+#include linux/mfd/syscon.h
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/of_gpio.h
+#include linux/reboot.h
+#include linux/regmap.h
+
+#include asm/system_misc.h
+
+#define PS_HOLD_CONTROL0x330C
+
+struct odroid_reboot_data {
+ struct device *dev;
+ int power_gpio;
+ struct regmap *reg_pmu;
+ void (*reboot_func)(enum reboot_mode mode, const char *cmd);
+};
+
+static struct odroid_reboot_data *reboot_data;
+
+static void odroid_reboot(enum reboot_mode mode, const char *cmd)
+{
+ local_irq_disable();
+
+ gpio_set_value(reboot_data-power_gpio, 0);
+ mdelay(150);
+ gpio_set_value(reboot_data-power_gpio, 1);
+
+ reboot_data-reboot_func(mode, cmd);
+
+ pr_emerg(%s: waiting for reboot\n, __func__);
+ while (1)
+ ;
+}
+
+static void odroid_power_off(void)
+{
+ regmap_update_bits(reboot_data-reg_pmu, PS_HOLD_CONTROL, 0x,
0x5200);
+ while (1) {
+ pr_emerg(%s: should not reach here!\n, __func__);
+ msleep(1000);
+ }
+}
+
+static struct odroid_reboot_data *odroid_reboot_parse_dt(struct device *dev)
+{
+ struct device_node *np = dev-of_node;
+ struct odroid_reboot_data *data;
+
+ data = devm_kzalloc(dev, sizeof(struct odroid_reboot_data), GFP_KERNEL);
+ if (!data)
+ return NULL;
+
+
Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature
On 10/29/2014 05:34 AM, Johan Hovold wrote:
On Tue, Oct 28, 2014 at 03:16:10PM +, Russell King - ARM Linux wrote:
On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote:
That's not what I was trying to refer to. But the patch set explicitly
allows for multiple, prioritised power-off handlers, which can power
off a board in different ways and with various degrees of success.
Specifically, it allows for fallback handlers in case one or more
power-off handlers fail.
So if we allow for that, what is to prevent the final power-off handler
from failing? And should this not be logged by arch code in the same way
as failure to restart is?
And how is that different from having a set of power-off handlers, and
reporting when each individual one fails? Don't you want to know if
your primary high priority reboot handler fails, just as much as you
want to know if your final last-resort power-off handler fails?
Good point. Failed power-off should probably be logged by the power-off
call chain implementation (which seems to makes notifier chains a bad
fit).
Good that I just replaced notifier chain with an open coded implementation.
Sure, that is possible, but I would prefer to do that as a follow-up commit,
and it should be discussed in the context of the power-off handler patch set.
And what about any power-off latencies? Should this always be dealt with
in the power-off handler?
Again, if it's predictable and high, as in the OMAP RTC case, it should
go in the handler. But what if it's just normal bus latencies
(peripheral busses, i2c, or whatever people may come up with)?
Should there always be a short delay before calling the next handler?
That delay would depend on the individual power-off handler, so I think
the current implementation works just fine (where power-off handlers
implement the delay).
We could move the delay into the infrastructure, but it would have
to be configurable. I would prefer to consider that as a follow-up patch
to not overload the power-off handler patch set with too many changes
at the same time.
Or different from having no power-off handlers.
That is actually quite different, as in that case we call machine_halt
instead (via kernel_halt).
Here's the x86 code:
void machine_power_off(void)
{
machine_ops.power_off();
}
struct machine_ops machine_ops = {
.power_off = native_machine_power_off,
...
static void native_machine_power_off(void)
{
if (pm_power_off) {
if (!reboot_force)
machine_shutdown();
pm_power_off();
}
/* A fallback in case there is no PM info available */
tboot_shutdown(TB_SHUTDOWN_HALT);
}
void tboot_shutdown(u32 shutdown_type)
{
void (*shutdown)(void);
if (!tboot_enabled())
return;
See - x86 can very well just fall straight back out of machine_power_off()
if there's no pm_power_off() hook and tboot is not enabled.
I never doubted that, but is the right thing to do? Not all arches do it
that way.
And what about the killing of init? Shall we simply consider that a
systemd bug?
case LINUX_REBOOT_CMD_POWER_OFF:
kernel_power_off();
do_exit(0);
break;
If power-off fails (for whatever reason), do_exit(0) will trigger a
panic when called from PID 1.
Common handling of that condition - eg to call machine_halt() - might be
an option. Separate patch, though.
Guenter
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/20] rtc: omap: fixes and power-off feature
On Wed, Oct 29, 2014 at 01:10:20PM +, Russell King - ARM Linux wrote:
On Wed, Oct 29, 2014 at 01:34:18PM +0100, Johan Hovold wrote:
On Tue, Oct 28, 2014 at 03:16:10PM +, Russell King - ARM Linux wrote:
And how is that different from having a set of power-off handlers, and
reporting when each individual one fails? Don't you want to know if
your primary high priority reboot handler fails, just as much as you
want to know if your final last-resort power-off handler fails?
Good point. Failed power-off should probably be logged by the power-off
call chain implementation (which seems to makes notifier chains a bad
fit).
And what about any power-off latencies? Should this always be dealt with
in the power-off handler?
Again, if it's predictable and high, as in the OMAP RTC case, it should
go in the handler. But what if it's just normal bus latencies
(peripheral busses, i2c, or whatever people may come up with)?
Should there always be a short delay before calling the next handler?
If the handler has determined that it has failed, then why delay before
trying the next handler? At the point it has decided it has failed,
surely that's after it has waited sufficient time to determine that
failure?
The current handlers we have are not expecting any other handler to be
run after they return. My question was whether all these handlers should
get a short mdelay added to them (e.g. to compensate for bus latencies)
or if this could be done in the power-off handler (e.g. before printing
the error message).
Or different from having no power-off handlers.
That is actually quite different, as in that case we call machine_halt
instead (via kernel_halt).
Today, ARM does exactly what x86 does. If there's no power off handler
registered, machine_power_off() shuts down other CPUs and returns.
No, if there are no power-off handlers registered, kernel/reboot.c will
never call machine_power_off:
/* Instead of trying to make the power_off code look like
* halt when pm_power_off is not set do it the easy way.
*/
if ((cmd == LINUX_REBOOT_CMD_POWER_OFF) !pm_power_off)
cmd = LINUX_REBOOT_CMD_HALT;
So in that case on arm, a system-halted message is printed, and we never
return to user-space.
Here's the x86 code:
void machine_power_off(void)
{
machine_ops.power_off();
}
struct machine_ops machine_ops = {
.power_off = native_machine_power_off,
...
static void native_machine_power_off(void)
{
if (pm_power_off) {
if (!reboot_force)
machine_shutdown();
pm_power_off();
}
/* A fallback in case there is no PM info available */
tboot_shutdown(TB_SHUTDOWN_HALT);
}
void tboot_shutdown(u32 shutdown_type)
{
void (*shutdown)(void);
if (!tboot_enabled())
return;
See - x86 can very well just fall straight back out of machine_power_off()
if there's no pm_power_off() hook and tboot is not enabled.
I never doubted that, but is the right thing to do? Not all arches do it
that way.
Well, the biggest question there is: if the power off or restart syscall
fails, what is the _generic_ non-architecture action which is supposed to
happen?
Whatever the answer is to that question, that action should be performed
by the _generic_ non-architecture code, rather than having the same
implementation spread across all 30 architectures which the kernel
supports today.
I fully agree.
And what about the killing of init? Shall we simply consider that a
systemd bug?
case LINUX_REBOOT_CMD_POWER_OFF:
kernel_power_off();
do_exit(0);
break;
If power-off fails (for whatever reason), do_exit(0) will trigger a
panic when called from PID 1.
Oh, systemd calls this from PID1? I guess that's another reason to hate
systemd with vitriol. :) SysVinit and upstart implementations call it
from the halt command, which is itself normally run from a script,
which totally avoids that problem.
Yeah, that's why I never noticed the missing mdelay.
I'm quite sure the insane systemd lobby will scream that this is a kernel
bug and will want to change it somehow, just like they want to change the
kernel in soo many other silly ways.
Will be interesting to follow. :)
Johan
--
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 00/20] rtc: omap: fixes and power-off feature
On Wed, Oct 29, 2014 at 06:20:40AM -0700, Guenter Roeck wrote: On 10/29/2014 05:34 AM, Johan Hovold wrote: On Tue, Oct 28, 2014 at 03:16:10PM +, Russell King - ARM Linux wrote: On Tue, Oct 28, 2014 at 02:12:57PM +0100, Johan Hovold wrote: That's not what I was trying to refer to. But the patch set explicitly allows for multiple, prioritised power-off handlers, which can power off a board in different ways and with various degrees of success. Specifically, it allows for fallback handlers in case one or more power-off handlers fail. So if we allow for that, what is to prevent the final power-off handler from failing? And should this not be logged by arch code in the same way as failure to restart is? And how is that different from having a set of power-off handlers, and reporting when each individual one fails? Don't you want to know if your primary high priority reboot handler fails, just as much as you want to know if your final last-resort power-off handler fails? Good point. Failed power-off should probably be logged by the power-off call chain implementation (which seems to makes notifier chains a bad fit). Good that I just replaced notifier chain with an open coded implementation. Good to hear. Sure, that is possible, but I would prefer to do that as a follow-up commit, and it should be discussed in the context of the power-off handler patch set. Fine with me. And what about any power-off latencies? Should this always be dealt with in the power-off handler? Again, if it's predictable and high, as in the OMAP RTC case, it should go in the handler. But what if it's just normal bus latencies (peripheral busses, i2c, or whatever people may come up with)? Should there always be a short delay before calling the next handler? That delay would depend on the individual power-off handler, so I think the current implementation works just fine (where power-off handlers implement the delay). Some don't, and could possibly unknowingly have been relying on the fact that they could return to user space and be powered off at some later time. With systemd that would have caused a panic. Also consider generic power-off handlers such as gpio-poweroff. It currently hard-codes a three-second delay but the actual delay would really be board specific. We could move the delay into the infrastructure, but it would have to be configurable. I would prefer to consider that as a follow-up patch to not overload the power-off handler patch set with too many changes at the same time. Sure. Johan -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] phy: sun4i: add support for USB phy0
Hi all, sorry for missing Signed-offs, they will be added, of course. + /* Regulation 45 ohms */ + if (phy-index == 0) + sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1); What is this code supposed to do? Some define for this bit and/or a better comment would be nice. From Allwinner's sources: Enable/Disable USB res45 Calibration which I think refers to the internal 45 ohm termination resistors for the USB data lines. But I'm not an expert on USB hardware. Same with me. I will however change the comment to make it more informative. Thanks for your review, Roman -- 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 v5 3/3] ARM: imx_v6_v7_defconfig: enable tlv320aic3x audio codec by default
Used on Phytec PBAB01 board. Signed-off-by: Dmitry Lavnikevich d.lavnikev...@sam-solutions.com --- arch/arm/configs/imx_v6_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig index 8fca6e276b69..cac07d67b933 100644 --- a/arch/arm/configs/imx_v6_v7_defconfig +++ b/arch/arm/configs/imx_v6_v7_defconfig @@ -210,6 +210,7 @@ CONFIG_SND_SOC_IMX_WM8962=y CONFIG_SND_SOC_IMX_SGTL5000=y CONFIG_SND_SOC_IMX_SPDIF=y CONFIG_SND_SOC_IMX_MC13783=y +CONFIG_SND_SOC_TLV320AIC3X=y CONFIG_SND_SIMPLE_CARD=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y -- 2.1.2 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/3] ARM: dts: pbab01: move i2c pins and frequency configuration into pfla02
Since pins and frequency are specific to module (pfla02), not base board
(pbab02), it is better to be initialized in corresponding dts file.
This patch fixes i2c2, i2c3 pin configuration which caused messages:
imx6q-pinctrl 20e.iomuxc: no groups defined in
/soc/aips-bus@0200/iomuxc@020e/i2c2grp
imx6q-pinctrl 20e.iomuxc: no groups defined in
/soc/aips-bus@0200/iomuxc@020e/i2c3grp
imx6q-pinctrl 20e.iomuxc: unable to find group for node i2c2grp
imx6q-pinctrl 20e.iomuxc: unable to find group for node i2c3grp
Signed-off-by: Dmitry Lavnikevich d.lavnikev...@sam-solutions.com
---
arch/arm/boot/dts/imx6qdl-phytec-pbab01.dtsi | 22 --
arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi | 26 ++
2 files changed, 26 insertions(+), 22 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-pbab01.dtsi
b/arch/arm/boot/dts/imx6qdl-phytec-pbab01.dtsi
index 584721264121..f1bdcae5b97d 100644
--- a/arch/arm/boot/dts/imx6qdl-phytec-pbab01.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-phytec-pbab01.dtsi
@@ -28,9 +28,6 @@
};
i2c2 {
- pinctrl-names = default;
- pinctrl-0 = pinctrl_i2c2;
- clock-frequency = 10;
status = okay;
tlv320@18 {
@@ -55,9 +52,6 @@
};
i2c3 {
- pinctrl-names = default;
- pinctrl-0 = pinctrl_i2c3;
- clock-frequency = 10;
status = okay;
};
@@ -84,19 +78,3 @@
usdhc3 {
status = okay;
};
-
-iomuxc {
- pinctrl_i2c2: i2c2grp {
- fsl,pins =
- MX6QDL_PAD_EIM_EB2__I2C2_SCL0x4001b8b1
- MX6QDL_PAD_EIM_D16__I2C2_SDA0x4001b8b1
- ;
- };
-
- pinctrl_i2c3: i2c3grp {
- fsl,pins =
- MX6QDL_PAD_EIM_D17__I2C3_SCL0x4001b8b1
- MX6QDL_PAD_EIM_D18__I2C3_SDA0x4001b8b1
- ;
- };
-};
diff --git a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
index 0e50bb0a6b94..aa2275671d2c 100644
--- a/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
@@ -162,6 +162,18 @@
};
};
+i2c2 {
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_i2c2;
+ clock-frequency = 10;
+};
+
+i2c3 {
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_i2c3;
+ clock-frequency = 10;
+};
+
iomuxc {
pinctrl-names = default;
pinctrl-0 = pinctrl_hog;
@@ -235,6 +247,20 @@
;
};
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins =
+ MX6QDL_PAD_EIM_EB2__I2C2_SCL
0x4001b8b1
+ MX6QDL_PAD_EIM_D16__I2C2_SDA
0x4001b8b1
+ ;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins =
+ MX6QDL_PAD_EIM_D17__I2C3_SCL
0x4001b8b1
+ MX6QDL_PAD_EIM_D18__I2C3_SDA
0x4001b8b1
+ ;
+ };
+
pinctrl_uart3: uart3grp {
fsl,pins =
MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1
--
2.1.2
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
