Re: [PATCH 0/2] fix ehrpwm tbclk data on am33xx and am43xx

[Tero Kristo]

On 02/24/2015 07:15 PM, Tony Lindgren wrote:

* Vignesh R  [150209 22:43]:

In am33xx and am43xx, ehrpwm tbclk is derived from functional clock of
PWMSS. The schematics and TRMs show that there is only one input clock to
the PWMSS. But currently, tbclk is wrongly shown to be deriving from
dpll_per_m2_ck instead of functional clock l4ls_gclk in the DT.

Fixing ehrpwm tbclk data to reflect the right clk source.
Tested on beaglebone and am437x-gp-evm.

Vignesh R (2):
   ARM: dts: am33xx-clocks: Fix ehrpwm tbclk data on am33xx
   ARM: dts: am43xx-clocks: Fix ehrpwm tbclk data on am43xx

  arch/arm/boot/dts/am33xx-clocks.dtsi |  6 +++---
  arch/arm/boot/dts/am43xx-clocks.dtsi | 12 ++--
  2 files changed, 9 insertions(+), 9 deletions(-)


Tero, care to check this one too and ack if OK?


These look fine also, just verified from TRM. These two were actually 
buried in my mailbox, sorry about that.


Acked-by: Tero Kristo 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] ARM: DRA7x/OMAP5: Clock: DPLL Clock fixes

[Tero Kristo]

On 02/24/2015 06:27 PM, Tony Lindgren wrote:

* Ravikumar Kattekola  [150219 08:13]:

On 1/31/2015 10:36 PM, Ravikumar Kattekola wrote:

Fix bypass clock source for a few DPLLs.

On DRA7x/OMAP5, for a few DPLLs, both CLKINP and CLKINPULOW are connected
to a mux and the output from mux is routed to the bypass clkout.
Add a mux-clock as bypass clock with CLKINP and CLKINPULOW as parents.

Tested against:
tree: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
branch: master
On:
CPU  : OMAP5432 ES2.0
Board: OMAP5432 uEVM
and
CPU  : DRA752 ES1.0
Board: DRA7xx


Ravikumar Kattekola (2):
   ARM: DRA7x: dts: Fix the bypass clock source for dpll_iva and others
   ARM: OMAP5: dts: Fix the bypass clock source for dpll_iva and others

  arch/arm/boot/dts/dra7xx-clocks.dtsi   |   90 
  arch/arm/boot/dts/omap54xx-clocks.dtsi |   41 +--
  2 files changed, 118 insertions(+), 13 deletions(-)


Hi Benoit,
 Can these fixes be looked into for 3.20-rc?


Seem like valid fixes to me. Tero, care to take a look at these and ack
if OK?


Yes, both are good to go.

Acked-by: Tero Kristo 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save

[Lee Jones]

On Wed, 07 Jan 2015, Vignesh R wrote:

> In one shot mode, sequencer automatically disables all enabled steps at
> the end of each cycle. (both ADC steps and TSC steps) Hence these steps
> need not be saved in reg_se_cache for clearing these steps at a later
> stage.
> Also, when ADC wakes up Sequencer should not be busy executing any of the
> config steps except for the charge step. Previously charge step was 1 ADC
> clock cycle and hence it was ignored.
> TSC steps are always disabled at the end of each conversion cycle, hence
> there is no need to explicitly disable TSC steps by writing 0 to REG_SE.
> 
> Signed-off-by: Vignesh R 
> ---
> 
> v5:
>  - Remove unnecessary clearing of REG_SE
> 
>  drivers/mfd/ti_am335x_tscadc.c   | 13 +
>  include/linux/mfd/ti_am335x_tscadc.h |  1 +
>  2 files changed, 6 insertions(+), 8 deletions(-)

Applied, thanks.

> diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
> index 467c80e1c4ae..e4e4b22eebc9 100644
> --- a/drivers/mfd/ti_am335x_tscadc.c
> +++ b/drivers/mfd/ti_am335x_tscadc.c
> @@ -68,12 +68,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev 
> *tsadc)
>   DEFINE_WAIT(wait);
>   u32 reg;
>  
> - /*
> -  * disable TSC steps so it does not run while the ADC is using it. If
> -  * write 0 while it is running (it just started or was already running)
> -  * then it completes all steps that were enabled and stops then.
> -  */
> - tscadc_writel(tsadc, REG_SE, 0);
>   reg = tscadc_readl(tsadc, REG_ADCFSM);
>   if (reg & SEQ_STATUS) {
>   tsadc->adc_waiting = true;
> @@ -86,8 +80,12 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev 
> *tsadc)
>   spin_lock_irq(&tsadc->reg_lock);
>   finish_wait(&tsadc->reg_se_wait, &wait);
>  
> + /*
> +  * Sequencer should either be idle or
> +  * busy applying the charge step.
> +  */
>   reg = tscadc_readl(tsadc, REG_ADCFSM);
> - WARN_ON(reg & SEQ_STATUS);
> + WARN_ON((reg & SEQ_STATUS) && !(reg & CHARGE_STEP));
>   tsadc->adc_waiting = false;
>   }
>   tsadc->adc_in_use = true;
> @@ -96,7 +94,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev 
> *tsadc)
>  void am335x_tsc_se_set_once(struct ti_tscadc_dev *tsadc, u32 val)
>  {
>   spin_lock_irq(&tsadc->reg_lock);
> - tsadc->reg_se_cache |= val;
>   am335x_tscadc_need_adc(tsadc);
>  
>   tscadc_writel(tsadc, REG_SE, val);
> diff --git a/include/linux/mfd/ti_am335x_tscadc.h 
> b/include/linux/mfd/ti_am335x_tscadc.h
> index 3f4e994ace2b..1fd50dcfe47c 100644
> --- a/include/linux/mfd/ti_am335x_tscadc.h
> +++ b/include/linux/mfd/ti_am335x_tscadc.h
> @@ -128,6 +128,7 @@
>  
>  /* Sequencer Status */
>  #define SEQ_STATUS BIT(5)
> +#define CHARGE_STEP  0x11
>  
>  #define ADC_CLK  300
>  #define TOTAL_STEPS  16

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Patch V6 04/10] ASoC: qcom: add LPASS header files

[Kenneth Westfield]

From: Kenneth Westfield 

Add the LPASS header files for ipq806x SOC.  This
includes the register definitions for the ipq806x
LPAIF, and the structure definition for the driver
data.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 sound/soc/qcom/lpass-lpaif-ipq806x.h | 172 +++
 sound/soc/qcom/lpass.h   |  51 +++
 2 files changed, 223 insertions(+)
 create mode 100644 sound/soc/qcom/lpass-lpaif-ipq806x.h
 create mode 100644 sound/soc/qcom/lpass.h

diff --git a/sound/soc/qcom/lpass-lpaif-ipq806x.h 
b/sound/soc/qcom/lpass-lpaif-ipq806x.h
new file mode 100644
index 
..dc423b425e60ebb11cd0ce78da2574ed27c2
--- /dev/null
+++ b/sound/soc/qcom/lpass-lpaif-ipq806x.h
@@ -0,0 +1,172 @@
+/*
+ * Copyright (c) 2010-2011,2013-2015 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * lpass-lpaif-ipq806x.h -- Definitions for the QTi LPAIF in the ipq806x LPASS
+ */
+
+#ifndef __LPASS_LPAIF_H__
+#define __LPASS_LPAIF_H__
+
+#define LPAIF_BANK_OFFSET  0x1000
+
+/* LPAIF I2S */
+
+#define LPAIF_I2SCTL_REG_BASE  0x0010
+#define LPAIF_I2SCTL_REG_STRIDE0x4
+#define LPAIF_I2SCTL_REG_ADDR(addr, port) \
+   (LPAIF_I2SCTL_REG_BASE + (addr) + (LPAIF_I2SCTL_REG_STRIDE * (port)))
+
+enum lpaif_i2s_ports {
+   LPAIF_I2S_PORT_MIN  = 0,
+
+   LPAIF_I2S_PORT_CODEC_SPK= 0,
+   LPAIF_I2S_PORT_CODEC_MIC= 1,
+   LPAIF_I2S_PORT_SEC_SPK  = 2,
+   LPAIF_I2S_PORT_SEC_MIC  = 3,
+   LPAIF_I2S_PORT_MI2S = 4,
+
+   LPAIF_I2S_PORT_MAX  = 4,
+   LPAIF_I2S_PORT_NUM  = 5,
+};
+
+#define LPAIF_I2SCTL_REG(port) LPAIF_I2SCTL_REG_ADDR(0x0, (port))
+
+#define LPAIF_I2SCTL_LOOPBACK_MASK 0x8000
+#define LPAIF_I2SCTL_LOOPBACK_SHIFT15
+#define LPAIF_I2SCTL_LOOPBACK_DISABLE  (0 << LPAIF_I2SCTL_LOOPBACK_SHIFT)
+#define LPAIF_I2SCTL_LOOPBACK_ENABLE   (1 << LPAIF_I2SCTL_LOOPBACK_SHIFT)
+
+#define LPAIF_I2SCTL_SPKEN_MASK0x4000
+#define LPAIF_I2SCTL_SPKEN_SHIFT   14
+#define LPAIF_I2SCTL_SPKEN_DISABLE (0 << LPAIF_I2SCTL_SPKEN_SHIFT)
+#define LPAIF_I2SCTL_SPKEN_ENABLE  (1 << LPAIF_I2SCTL_SPKEN_SHIFT)
+
+#define LPAIF_I2SCTL_SPKMODE_MASK  0x3C00
+#define LPAIF_I2SCTL_SPKMODE_SHIFT 10
+#define LPAIF_I2SCTL_SPKMODE_NONE  (0 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_SD0   (1 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_SD1   (2 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_SD2   (3 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_SD3   (4 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_QUAD01(5 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_QUAD23(6 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_6CH   (7 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+#define LPAIF_I2SCTL_SPKMODE_8CH   (8 << LPAIF_I2SCTL_SPKMODE_SHIFT)
+
+#define LPAIF_I2SCTL_SPKMONO_MASK  0x0200
+#define LPAIF_I2SCTL_SPKMONO_SHIFT 9
+#define LPAIF_I2SCTL_SPKMONO_STEREO(0 << LPAIF_I2SCTL_SPKMONO_SHIFT)
+#define LPAIF_I2SCTL_SPKMONO_MONO  (1 << LPAIF_I2SCTL_SPKMONO_SHIFT)
+
+#define LPAIF_I2SCTL_WSSRC_MASK0x0004
+#define LPAIF_I2SCTL_WSSRC_SHIFT   2
+#define LPAIF_I2SCTL_WSSRC_INTERNAL(0 << LPAIF_I2SCTL_WSSRC_SHIFT)
+#define LPAIF_I2SCTL_WSSRC_EXTERNAL(1 << LPAIF_I2SCTL_WSSRC_SHIFT)
+
+#define LPAIF_I2SCTL_BITWIDTH_MASK 0x0003
+#define LPAIF_I2SCTL_BITWIDTH_SHIFT0
+#define LPAIF_I2SCTL_BITWIDTH_16   (0 << LPAIF_I2SCTL_BITWIDTH_SHIFT)
+#define LPAIF_I2SCTL_BITWIDTH_24   (1 << LPAIF_I2SCTL_BITWIDTH_SHIFT)
+#define LPAIF_I2SCTL_BITWIDTH_32   (2 << LPAIF_I2SCTL_BITWIDTH_SHIFT)
+
+/* LPAIF IRQ */
+
+#define LPAIF_IRQ_REG_BASE 0x3000
+#define LPAIF_IRQ_REG_STRIDE   0x1000
+#define LPAIF_IRQ_REG_ADDR(addr, port) \
+   (LPAIF_IRQ_REG_BASE + (addr) + (LPAIF_IRQ_REG_STRIDE * (port)))
+
+enum lpaif_irq_ports {
+   LPAIF_IRQ_PORT_MIN  = 0,
+
+   LPAIF_IRQ_PORT_HOST = 0,
+   LPAIF_IRQ_PORT_ADSP = 1,
+
+   LPAIF_IRQ_PORT_MAX  = 2,
+   LPAIF_IRQ_PORT_NUM  = 3,
+};
+
+#define LPAIF_IRQEN_REG(port)  LPAIF_IRQ_REG_ADDR(0x0, (port))
+#define LPAIF_IRQSTAT_REG(port)LPAIF_IRQ_REG_ADDR(0x4, (port))
+#define LPAIF_IRQCLEAR_REG(port)   LPAIF_IRQ_REG_ADD

[Patch V6 00/10] ASoC: QCOM: Add support for ipq806x SOC

[Kenneth Westfield]

From: Kenneth Westfield 

This patch series adds support for I2S audio playback on the Storm board, which
contains a Qualcomm Technologies ipq806x SOC and a Maxim max98357a DAC/amp.

The ipq806x SOC has audio-related hardware blocks in its low-power audio
subsystem (or LPASS).  One of the relevant blocks in the LPASS is its low-power
audio interface (or LPAIF).  This contains an MI2S port, which is what these
drivers are configured to use.  The LPAIF also contains a DMA engine that is
dedicated to moving audio samples into the transmit FIFO of the MI2S port.

One bus from the MI2S port of the SOC is connected to the DAC/amp for stereo
playback.  This bus is configured so that the SOC is bus master and consists of
DATA, LRCLK, and BCLK.  The DAC/amp does not need MCLK to operate.  In addition,
a single GPIO pin from the SOC is connected to the same DAC/amp, which gives
enable/disable control over the DAC/amp.

The specific drivers added are:
  * a CPU DAI driver for controlling the MI2S port
  * a platform driver for controlling the LPAIF DMA engine
  * a machine driver that instantiates a dai-link for playback

The LPASS also contains clocks that need to be controlled.  Those drivers have
been submitted as a separate patch series:  
  [PATCH v3 0/8] qcom audio clock control drivers
  http://lkml.org/lkml/2015/1/19/656

Even though the ipq806x LPASS does not contain an audio DSP, other SOCs do have
one.  For those SOCs, the audio DSP typically controls the hardware blocks in
the LPASS.  Hence, different CPU DAI driver(s) would need to be used in order to
facilitate audio with the DSP.  As such, the LPASS DT contains an adsp subnode,
which is disabled for this SOC.  The same subnode should be enabled and
populated for other SOCs that do contain an audio DSP.  Not using the audio DSP
would require different CPU DAI driver(s), in addition to possible bootloader
and/or firmware changes.

Corresponding additions to the device tree for the ipq806x SOC and its
documentation has also been added.  Also, as this is a new directory, the
MAINTAINERS file has been updated as well.

= Changes since V5
  [Patch V5 00/12] ASoC: QCOM: Add support for ipq806x SOC
  http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/087832.html

  * Correctly use Storm as the build target label and DT binding label.
  * Added audio DSP sub-node to the LPASS device tree, disabled for this SOC.
  * Added logic to CPU DAI driver to fail the probe() if a DSP is present.
  * Use the standard naming convention for the DAI link properties.
  * General code cleanup.

= Changes since V4
  [Patch V4 00/10] ASoC: QCOM: Add support for ipq806x SOC
  http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/087499.html

  * Replaced simple-card with a machine driver to resolve the system clock
configuration, rather than having the CPU DAI driver do it.
  * Added header files to avoid indirect header dependencies and implicit
forward declarations.
  * Tweaked the ISR to match the conventions of the surrounding code.
  * Removed the usage of the low-power memory as it is not needed.
  * Removed the use of the DRV_NAME constant.
  * Added explicit dependency on gpiolib for the codec driver.
  * Moved the MODULE_DEVICE_TABLE macro inside the CONFIG_OF conditional.
  * Modified the documentation to reflect the changes.
  * General code cleanup.

= Changes since V3
  [Patch V3 00/10] ASoC: QCOM: Add support for ipq806x SOC
  http://mailman.alsa-project.org/pipermail/alsa-devel/2014-December/085694.html

  * Placed the content of the inline functions into the callbacks.
  * Replaced use of readl/writel register access functions with regmap access
functions.  Notable exception is the ISR, which uses ioread32/iowrite32.
  * Rearranged the sequencing of the hardware block enables to fit within the
ASoC framework callbacks, while remaining functional.
REQ 1: The hardware requires the enable sequence to be:
   LPAIF-DMA[enable],then LPAIF-MI2S[enable], then DAC-GPIO[enable]
REQ 2: The hardware requires the disable sequence to be:
   DAC-GPIO[disable], then LPAIF-MI2S[disable]
  * Corrected the implementation of the pointer callback.
  * Utilize the LPM to buffer audio samples, rather than memory external to
LPASS.
  * Corrected the interrupt clearing in the ISR.
  * Implemented a default system clock (defined by the simple-card DT node), and
optional LPASS DT node modifiers that can alter the system clock in order to
expand the range of available bit clock frequencies.
  * Addressed all of the remaining issues raised by Mark Brown.
  * General code cleanup.

= Changes since V2
  [Patch v2 00/11] ASoC: QCOM: Add support for ipq806x SOC
  http://mailman.alsa-project.org/pipermail/alsa-devel/2014-December/085186.html

  * Removed the PCM platform driver from the DTS platform and tied it to the CPU
DAI driver.
  * Changed I2S pinctrl to use generic naming convention and moved control to

[Patch V6 01/10] MAINTAINERS: Add QCOM audio ASoC maintainer

[Kenneth Westfield]

From: Kenneth Westfield 

Add maintainers for the Qualcomm Technologies
sound drivers.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 
ddc5a8cf9a8ac0078f8ca1bc99d9c48f8197214a..9514b794b74d7fb93072bbdbaefaaa79df38c5fd
 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5254,6 +5254,13 @@ F:   drivers/char/ipmi/
 F: include/linux/ipmi*
 F: include/uapi/linux/ipmi*
 
+QCOM AUDIO (ASoC) DRIVERS
+M: Patrick Lai 
+M: Banajit Goswami 
+L: alsa-de...@alsa-project.org (moderated for non-subscribers)
+S: Supported
+F: sound/soc/qcom/
+
 IPS SCSI RAID DRIVER
 M: Adaptec OEM Raid Solutions 
 L: linux-s...@vger.kernel.org
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Patch V6 02/10] ASoC: qcom: Document LPASS CPU bindings

[Kenneth Westfield]

From: Kenneth Westfield 

Add documentation to the sound directory of the
device-tree bindings for the QTi LPASS CPU DAI
device.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 .../devicetree/bindings/sound/qcom,lpass-cpu.txt   | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt

diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt 
b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt
new file mode 100644
index 
..e7c6e9321863f022ebf0d51b75d7bb83c10b9062
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.txt
@@ -0,0 +1,49 @@
+* Qualcomm Technologies LPASS CPU DAI
+
+This node models the Qualcomm Technologies Low-Power Audio SubSystem (LPASS).
+
+Required properties:
+
+- compatible   : "qcom,lpass-cpu"
+- clocks   : Must contain an entry for each entry in clock-names.
+- clock-names  : A list which must include the following entries:
+   * "ahbix-clk"
+   * "mi2s-osr-clk"
+   * "mi2s-bit-clk"
+- interrupts   : Must contain an entry for each entry in
+ interrupt-names.
+- interrupt-names  : A list which must include the following entries:
+   * "lpass-irq-lpaif"
+- pinctrl-N: One property must exist for each entry in
+ pinctrl-names.  See ../pinctrl/pinctrl-bindings.txt
+ for details of the property values.
+- pinctrl-names: Must contain a "default" entry.
+- reg  : Must contain an address for each entry in reg-names.
+- reg-names: A list which must include the following entries:
+   * "lpass-lpaif"
+
+Required subnodes:
+
+- qcom,adsp: Audio DSP sub-node
+
+Optional Audio DSP subnode properties:
+
+- status   : "disabled" indicates the adsp is not available.
+
+Example:
+
+lpass@2810 {
+   compatible = "qcom,lpass-cpu";
+   clocks = <&lcc AHBIX_CLK>, <&lcc MI2S_OSR_CLK>, <&lcc MI2S_BIT_CLK>;
+   clock-names = "ahbix-clk", "mi2s-osr-clk", "mi2s-bit-clk";
+   interrupts = <0 85 1>;
+   interrupt-names = "lpass-irq-lpaif";
+   pinctrl-names = "default", "idle";
+   pinctrl-0 = <&mi2s_default>;
+   pinctrl-1 = <&mi2s_idle>;
+   reg = <0x2810 0x1>;
+   reg-names = "lpass-lpaif";
+   qcom,adsp {
+   status = "disabled";
+   };
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Patch V6 05/10] ASoC: qcom: Add LPASS CPU DAI driver

[Kenneth Westfield]

From: Kenneth Westfield 

Add the CPU DAI driver for the Qualcomm
Technologies low-power audio subsystem (LPASS).

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 sound/soc/qcom/lpass-cpu.c | 508 +
 1 file changed, 508 insertions(+)
 create mode 100644 sound/soc/qcom/lpass-cpu.c

diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
new file mode 100644
index 
..44ba7e34915e2cac91c51fecbcb8516805e99f56
--- /dev/null
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -0,0 +1,508 @@
+/*
+ * Copyright (c) 2010-2011,2013-2015 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * lpass-cpu.c -- ALSA SoC CPU DAI driver for QTi LPASS
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "lpass-lpaif-ipq806x.h"
+#include "lpass.h"
+
+static int lpass_cpu_daiops_set_sysclk(struct snd_soc_dai *dai, int clk_id,
+   unsigned int freq, int dir)
+{
+   struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai);
+   int ret;
+
+   ret = clk_set_rate(drvdata->mi2s_osr_clk, freq);
+   if (ret)
+   dev_err(dai->dev, "%s() error setting mi2s osrclk to %u: %d\n",
+   __func__, freq, ret);
+
+   return ret;
+}
+
+static int lpass_cpu_daiops_startup(struct snd_pcm_substream *substream,
+   struct snd_soc_dai *dai)
+{
+   struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai);
+   int ret;
+
+   ret = clk_prepare_enable(drvdata->mi2s_osr_clk);
+   if (ret) {
+   dev_err(dai->dev, "%s() error in enabling mi2s osr clk: %d\n",
+   __func__, ret);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(drvdata->mi2s_bit_clk);
+   if (ret) {
+   dev_err(dai->dev, "%s() error in enabling mi2s bit clk: %d\n",
+   __func__, ret);
+   clk_disable_unprepare(drvdata->mi2s_osr_clk);
+   return ret;
+   }
+
+   return 0;
+}
+
+static void lpass_cpu_daiops_shutdown(struct snd_pcm_substream *substream,
+   struct snd_soc_dai *dai)
+{
+   struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai);
+
+   clk_disable_unprepare(drvdata->mi2s_bit_clk);
+   clk_disable_unprepare(drvdata->mi2s_osr_clk);
+}
+
+static int lpass_cpu_daiops_hw_params(struct snd_pcm_substream *substream,
+   struct snd_pcm_hw_params *params, struct snd_soc_dai *dai)
+{
+   struct lpass_data *drvdata = snd_soc_dai_get_drvdata(dai);
+   snd_pcm_format_t format = params_format(params);
+   unsigned int channels = params_channels(params);
+   unsigned int rate = params_rate(params);
+   unsigned int regval;
+   int bitwidth, ret;
+
+   bitwidth = snd_pcm_format_width(format);
+   if (bitwidth < 0) {
+   dev_err(dai->dev, "%s() invalid bit width given: %d\n",
+   __func__, bitwidth);
+   return bitwidth;
+   }
+
+   regval = LPAIF_I2SCTL_LOOPBACK_DISABLE |
+   LPAIF_I2SCTL_WSSRC_INTERNAL;
+
+   switch (bitwidth) {
+   case 16:
+   regval |= LPAIF_I2SCTL_BITWIDTH_16;
+   break;
+   case 24:
+   regval |= LPAIF_I2SCTL_BITWIDTH_24;
+   break;
+   case 32:
+   regval |= LPAIF_I2SCTL_BITWIDTH_32;
+   break;
+   default:
+   dev_err(dai->dev, "%s() invalid bitwidth given: %d\n",
+   __func__, bitwidth);
+   return -EINVAL;
+   }
+
+   switch (channels) {
+   case 1:
+   regval |= LPAIF_I2SCTL_SPKMODE_SD0;
+   regval |= LPAIF_I2SCTL_SPKMONO_MONO;
+   break;
+   case 2:
+   regval |= LPAIF_I2SCTL_SPKMODE_SD0;
+   regval |= LPAIF_I2SCTL_SPKMONO_STEREO;
+   break;
+   case 4:
+   regval |= LPAIF_I2SCTL_SPKMODE_QUAD01;
+   regval |= LPAIF_I2SCTL_SPKMONO_STEREO;
+   break;
+   case 6:
+   regval |= LPAIF_I2SCTL_SPKMODE_6CH;
+   regval |= LPAIF_I2SCTL_SPKMONO_STEREO;
+   break;
+   case 8:
+   regval |= LPAIF_I2SCTL_SPKMODE_8CH;
+   regval |= LPAIF_I2SCTL_SPKMONO_STEREO;
+   break;
+  

[Patch V6 03/10] ASoC: qcom: Document Storm bindings

[Kenneth Westfield]

From: Kenneth Westfield 

Add documentation to the sound directory of the
device-tree bindings for the soundcard of the
Storm board.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 Documentation/devicetree/bindings/sound/storm.txt | 23 +++
 1 file changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/storm.txt

diff --git a/Documentation/devicetree/bindings/sound/storm.txt 
b/Documentation/devicetree/bindings/sound/storm.txt
new file mode 100644
index 
..2a308e9c4cd3f9550c0b7078200a14a787f02858
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/storm.txt
@@ -0,0 +1,23 @@
+* Sound complex for Storm boards
+
+Models a soundcard for Storm boards with the Qualcomm Technologies IPQ806x SOC
+connected to a MAX98357A DAC via I2S.
+
+Required properties:
+
+- compatible   : "google,storm"
+- cpu  : Phandle of the CPU DAI
+- codec: Phandle of the codec DAI
+
+Optional properties:
+
+- qcom,model   : The user-visible name of this sound card.
+
+Example:
+
+sound {
+   compatible = "google,storm";
+   qcom,model = "ipq806x-storm";
+   cpu = <&lpass_cpu>;
+   codec = <&max98357a>;
+};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Patch V6 06/10] ASoC: qcom: Add LPASS platform driver

[Kenneth Westfield]

From: Kenneth Westfield 

Add platform driver for the Qualcomm Technologies
low-power audio subsystem (LPASS) ports.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 sound/soc/qcom/lpass-platform.c | 526 
 1 file changed, 526 insertions(+)
 create mode 100644 sound/soc/qcom/lpass-platform.c

diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
new file mode 100644
index 
..2fa6280dfb234b213904ad73dfad91c7f575538c
--- /dev/null
+++ b/sound/soc/qcom/lpass-platform.c
@@ -0,0 +1,526 @@
+/*
+ * Copyright (c) 2010-2011,2013-2015 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * lpass-platform.c -- ALSA SoC platform driver for QTi LPASS
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "lpass-lpaif-ipq806x.h"
+#include "lpass.h"
+
+#define LPASS_PLATFORM_BUFFER_SIZE (16 * 1024)
+#define LPASS_PLATFORM_PERIODS 2
+
+static struct snd_pcm_hardware lpass_platform_pcm_hardware = {
+   .info   =   SNDRV_PCM_INFO_MMAP |
+   SNDRV_PCM_INFO_MMAP_VALID |
+   SNDRV_PCM_INFO_INTERLEAVED |
+   SNDRV_PCM_INFO_PAUSE |
+   SNDRV_PCM_INFO_RESUME,
+   .formats=   SNDRV_PCM_FMTBIT_S16 |
+   SNDRV_PCM_FMTBIT_S24 |
+   SNDRV_PCM_FMTBIT_S32,
+   .rates  =   SNDRV_PCM_RATE_8000_192000,
+   .rate_min   =   8000,
+   .rate_max   =   192000,
+   .channels_min   =   1,
+   .channels_max   =   8,
+   .buffer_bytes_max   =   LPASS_PLATFORM_BUFFER_SIZE,
+   .period_bytes_max   =   LPASS_PLATFORM_BUFFER_SIZE /
+   LPASS_PLATFORM_PERIODS,
+   .period_bytes_min   =   LPASS_PLATFORM_BUFFER_SIZE /
+   LPASS_PLATFORM_PERIODS,
+   .periods_min=   LPASS_PLATFORM_PERIODS,
+   .periods_max=   LPASS_PLATFORM_PERIODS,
+   .fifo_size  =   0,
+};
+
+static int lpass_platform_pcmops_open(struct snd_pcm_substream *substream)
+{
+   struct snd_pcm_runtime *runtime = substream->runtime;
+   struct snd_soc_pcm_runtime *soc_runtime = substream->private_data;
+   int ret;
+
+   snd_soc_set_runtime_hwparams(substream, &lpass_platform_pcm_hardware);
+
+   runtime->dma_bytes = lpass_platform_pcm_hardware.buffer_bytes_max;
+
+   ret = snd_pcm_hw_constraint_integer(runtime,
+   SNDRV_PCM_HW_PARAM_PERIODS);
+   if (ret < 0) {
+   dev_err(soc_runtime->dev, "%s() setting constraints failed: 
%d\n",
+   __func__, ret);
+   return -EINVAL;
+   }
+
+   snd_pcm_set_runtime_buffer(substream, &substream->dma_buffer);
+
+   return 0;
+}
+
+static int lpass_platform_pcmops_hw_params(struct snd_pcm_substream *substream,
+   struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *soc_runtime = substream->private_data;
+   struct lpass_data *drvdata =
+   snd_soc_platform_get_drvdata(soc_runtime->platform);
+   snd_pcm_format_t format = params_format(params);
+   unsigned int channels = params_channels(params);
+   unsigned int regval;
+   int bitwidth;
+   int ret;
+
+   bitwidth = snd_pcm_format_width(format);
+   if (bitwidth < 0) {
+   dev_err(soc_runtime->dev, "%s() invalid bit width given: %d\n",
+   __func__, bitwidth);
+   return bitwidth;
+   }
+
+   regval = LPAIF_RDMACTL_BURSTEN_INCR4 |
+   LPAIF_RDMACTL_AUDINTF_MI2S |
+   LPAIF_RDMACTL_FIFOWM_8;
+
+   switch (bitwidth) {
+   case 16:
+   switch (channels) {
+   case 1:
+   case 2:
+   regval |= LPAIF_RDMACTL_WPSCNT_ONE;
+   break;
+   case 4:
+   regval |= LPAIF_RDMACTL_WPSCNT_TWO;
+   break;
+   case 6:
+   regval |= LPAIF_RDMACTL

[Patch V6 08/10] ASoC: qcom: Add ability to build QCOM drivers

[Kenneth Westfield]

From: Kenneth Westfield 

Define the LPASS platform driver, the LPASS
CPU DAI driver and the Storm machine driver
configurations, and how to build them.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 sound/soc/qcom/Kconfig  | 23 +++
 sound/soc/qcom/Makefile | 11 +++
 2 files changed, 34 insertions(+)
 create mode 100644 sound/soc/qcom/Kconfig
 create mode 100644 sound/soc/qcom/Makefile

diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
new file mode 100644
index 
..90e686be613a5ef7689582a9d085835d2fe12678
--- /dev/null
+++ b/sound/soc/qcom/Kconfig
@@ -0,0 +1,23 @@
+config SND_SOC_QCOM
+   tristate "ASoC support for QCOM platforms"
+   help
+  Say Y or M if you want to add support to use audio devices
+  in Qualcomm Technologies SOC-based platforms.
+
+config SND_SOC_LPASS_CPU
+   tristate
+   depends on SND_SOC_QCOM
+
+config SND_SOC_LPASS_PLATFORM
+   tristate
+   depends on SND_SOC_QCOM
+
+config SND_SOC_STORM
+   tristate "ASoC I2S support for Storm boards"
+   depends on (ARCH_QCOM && SND_SOC_QCOM) || COMPILE_TEST
+   select SND_SOC_LPASS_CPU
+   select SND_SOC_LPASS_PLATFORM
+   select SND_SOC_MAX98357A
+   help
+  Say Y or M if you want add support for SoC audio on the
+  Qualcomm Technologies IPQ806X-based Storm board.
diff --git a/sound/soc/qcom/Makefile b/sound/soc/qcom/Makefile
new file mode 100644
index 
..c5ce96c761c47b3a1b98e27d863fe0b5b9bc019e
--- /dev/null
+++ b/sound/soc/qcom/Makefile
@@ -0,0 +1,11 @@
+# Platform
+snd-soc-lpass-cpu-objs := lpass-cpu.o
+snd-soc-lpass-platform-objs := lpass-platform.o
+
+obj-$(CONFIG_SND_SOC_LPASS_CPU) += snd-soc-lpass-cpu.o
+obj-$(CONFIG_SND_SOC_LPASS_PLATFORM) += snd-soc-lpass-platform.o
+
+# Machine
+snd-soc-storm-objs := storm.o
+
+obj-$(CONFIG_SND_SOC_STORM) += snd-soc-storm.o
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Patch V6 09/10] ASoC: Allow for building QCOM drivers

[Kenneth Westfield]

From: Kenneth Westfield 

Allow for the Qualcomm Technologies ASoC drivers
to build.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 sound/soc/Kconfig  | 1 +
 sound/soc/Makefile | 1 +
 2 files changed, 2 insertions(+)

diff --git a/sound/soc/Kconfig b/sound/soc/Kconfig
index 
dcc79aa0236b548bfe5408fe56689241fc597e97..3ba52da18bc69a9bb41c84627cfc7d08f47e3bf0
 100644
--- a/sound/soc/Kconfig
+++ b/sound/soc/Kconfig
@@ -47,6 +47,7 @@ source "sound/soc/kirkwood/Kconfig"
 source "sound/soc/intel/Kconfig"
 source "sound/soc/mxs/Kconfig"
 source "sound/soc/pxa/Kconfig"
+source "sound/soc/qcom/Kconfig"
 source "sound/soc/rockchip/Kconfig"
 source "sound/soc/samsung/Kconfig"
 source "sound/soc/sh/Kconfig"
diff --git a/sound/soc/Makefile b/sound/soc/Makefile
index 
5b3c8f67c8db7a29ff7199a6103d445428978125..974ba708b4826a03077a58251434a311542d5e3c
 100644
--- a/sound/soc/Makefile
+++ b/sound/soc/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_SND_SOC) += nuc900/
 obj-$(CONFIG_SND_SOC)  += omap/
 obj-$(CONFIG_SND_SOC)  += kirkwood/
 obj-$(CONFIG_SND_SOC)  += pxa/
+obj-$(CONFIG_SND_SOC)  += qcom/
 obj-$(CONFIG_SND_SOC)  += rockchip/
 obj-$(CONFIG_SND_SOC)  += samsung/
 obj-$(CONFIG_SND_SOC)  += sh/
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Patch V6 10/10] ARM: dts: Model IPQ LPASS audio hardware

[Kenneth Westfield]

From: Kenneth Westfield 

Model the Qualcomm Technologies LPASS hardware for
the ipq806x SOC.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 arch/arm/boot/dts/qcom-ipq8064.dtsi | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index 
cb225dafe97cd83c9ae4cc19482ed55d4a71b8b3..dd5cbb33cc2d89be57494e05b7477352358affa5
 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -2,6 +2,7 @@
 
 #include "skeleton.dtsi"
 #include 
+#include 
 #include 
 
 / {
@@ -96,6 +97,24 @@
cpu-offset = <0x8>;
};
 
+   lpass@2810 {
+   compatible = "qcom,lpass-cpu";
+   status = "disabled";
+   clocks = <&lcc AHBIX_CLK>,
+   <&lcc MI2S_OSR_CLK>,
+   <&lcc MI2S_BIT_CLK>;
+   clock-names = "ahbix-clk",
+   "mi2s-osr-clk",
+   "mi2s-bit-clk";
+   interrupts = <0 85 1>;
+   interrupt-names = "lpass-irq-lpaif";
+   reg = <0x2810 0x1>;
+   reg-names = "lpass-lpaif";
+   qcom,adsp {
+   status = "disabled";
+   };
+   };
+
acc0: clock-controller@2088000 {
compatible = "qcom,kpss-acc-v1";
reg = <0x02088000 0x1000>, <0x02008000 0x1000>;
@@ -273,6 +292,13 @@
qcom,controller-type = "pmic-arbiter";
};
 
+   lcc: clock-controller@2800 {
+   compatible = "qcom,lcc-ipq8064";
+   reg = <0x2800 0x1000>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
gcc: clock-controller@90 {
compatible = "qcom,gcc-ipq8064";
reg = <0x0090 0x4000>;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Patch V6 07/10] ASoC: qcom: Add Storm machine driver

[Kenneth Westfield]

From: Kenneth Westfield 

Add machine driver for the Storm board with the
IPQ806X SOC connected to the MAX98357A DAC.

Signed-off-by: Kenneth Westfield 
Acked-by: Banajit Goswami 
---
 sound/soc/qcom/storm.c | 162 +
 1 file changed, 162 insertions(+)
 create mode 100644 sound/soc/qcom/storm.c

diff --git a/sound/soc/qcom/storm.c b/sound/soc/qcom/storm.c
new file mode 100644
index 
..5b981af4aa38a6a3bba926b3dd877239eefe8cb0
--- /dev/null
+++ b/sound/soc/qcom/storm.c
@@ -0,0 +1,162 @@
+/*
+ * Copyright (c) 2010-2011,2013-2015 The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * storm.c -- ALSA SoC machine driver for QTi ipq806x-based Storm board
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define STORM_SYSCLK_MULT  4
+
+static int storm_ops_hw_params(struct snd_pcm_substream *substream,
+   struct snd_pcm_hw_params *params)
+{
+   struct snd_soc_pcm_runtime *soc_runtime = substream->private_data;
+   struct snd_soc_card *card = soc_runtime->card;
+   snd_pcm_format_t format = params_format(params);
+   unsigned int rate = params_rate(params);
+   unsigned int sysclk_freq;
+   int bitwidth, ret;
+
+   bitwidth = snd_pcm_format_width(format);
+   if (bitwidth < 0) {
+   dev_err(card->dev, "%s() invalid bit width given: %d\n",
+   __func__, bitwidth);
+   return bitwidth;
+   }
+
+   /*
+* as the CPU DAI is the I2S bus master and no system clock is needed by
+* the MAX98357a DAC, simply set the system clock to be a constant
+* multiple of the bit clock for the clock divider
+*/
+   sysclk_freq = rate * bitwidth * 2 * STORM_SYSCLK_MULT;
+
+   ret = snd_soc_dai_set_sysclk(soc_runtime->cpu_dai, 0, sysclk_freq, 0);
+   if (ret) {
+   dev_err(card->dev, "%s() error setting sysclk to %u: %d\n",
+   __func__, sysclk_freq, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static struct snd_soc_ops storm_soc_ops = {
+   .hw_params  = storm_ops_hw_params,
+};
+
+static struct snd_soc_dai_link storm_dai_link = {
+   .name   = "Primary",
+   .stream_name= "Primary",
+   .codec_dai_name = "HiFi",
+   .ops= &storm_soc_ops,
+};
+
+static struct snd_soc_card storm_soc_card = {
+   .name   = "ipq806x-storm",
+   .dev= NULL,
+};
+
+static int storm_parse_of(struct snd_soc_card *card)
+{
+   struct snd_soc_dai_link *dai_link = card->dai_link;
+   struct device_node *np = card->dev->of_node;
+
+   dai_link->cpu_of_node = of_parse_phandle(np, "cpu", 0);
+   if (!dai_link->cpu_of_node) {
+   dev_err(card->dev, "%s() error getting cpu phandle\n",
+   __func__);
+   return -EINVAL;
+   }
+   dai_link->platform_of_node = dai_link->cpu_of_node;
+
+   dai_link->codec_of_node = of_parse_phandle(np, "codec", 0);
+   if (!dai_link->codec_of_node) {
+   dev_err(card->dev, "%s() error getting codec phandle\n",
+   __func__);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int storm_platform_probe(struct platform_device *pdev)
+{
+   struct snd_soc_card *card = &storm_soc_card;
+   int ret;
+
+   if (card->dev) {
+   dev_err(&pdev->dev, "%s() error, existing soundcard\n",
+   __func__);
+   return -ENODEV;
+   }
+   card->dev = &pdev->dev;
+   platform_set_drvdata(pdev, card);
+
+   ret = snd_soc_of_parse_card_name(card, "qcom,model");
+   if (ret) {
+   dev_err(&pdev->dev, "%s() error parsing card name: %d\n",
+   __func__, ret);
+   return ret;
+   }
+
+   card->dai_link  = &storm_dai_link;
+   card->num_links = 1;
+
+   ret = storm_parse_of(card);
+   if (ret) {
+   dev_err(&pdev->dev, "%s() error resolving dai links: %d\n",
+   __func__, ret);
+   return ret;
+   }
+
+   ret = devm_snd_soc_register_card(&pdev->dev, card);
+   if (ret == -EPROBE_DEFER) {
+   card->dev = NULL;
+   return ret;
+   } else if (ret) {
+   dev_err(&pdev->dev, "%s() error registering

[Patch] ASoC: max98357a: Use standard DAI names

[Kenneth Westfield]

From: Kenneth Westfield 

Use the standard naming convention for the codec DAI.

Signed-off-by: Kenneth Westfield 
---

based on next/topic/max98357a branch

 sound/soc/codecs/max98357a.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/max98357a.c b/sound/soc/codecs/max98357a.c
index 
4ee23fbc4e1237268ae104319a9cfe4fc369934e..bf3e933ee895752352e90f610195f39fc6cc058f
 100644
--- a/sound/soc/codecs/max98357a.c
+++ b/sound/soc/codecs/max98357a.c
@@ -85,9 +85,9 @@ static struct snd_soc_dai_ops max98357a_dai_ops = {
 };
 
 static struct snd_soc_dai_driver max98357a_dai_driver = {
-   .name = "max98357a",
+   .name = "HiFi",
.playback = {
-   .stream_name= "max98357a-playback",
+   .stream_name= "HiFi Playback",
.formats= SNDRV_PCM_FMTBIT_S16 |
SNDRV_PCM_FMTBIT_S24 |
SNDRV_PCM_FMTBIT_S32,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V5 2/2] ARM: dts: Add HS400 support for exynos5420 and exynos5800

[Jaehoon Chung]

Hi, Alim.

Acked-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

On 01/29/2015 11:41 AM, Alim Akhtar wrote:
> From: Seungwon Jeon 
> 
> HS400 timing values are added for SMDK5420, exynos5420-peach-pit
> and exynos5800-peach-pi boards.
> This also adds RCLK GPIO line, this gpio should be in pull-down
> state.
> This also enables HS400 on peach-pi and this updates the clock frequency
> to 800MHz to be set as input clock to controller.
> 
> Signed-off-by: Seungwon Jeon 
> Signed-off-by: Alim Akhtar 
> [Alim: addressed review comments]
> ---
>  arch/arm/boot/dts/exynos5420-peach-pit.dts |4 +++-
>  arch/arm/boot/dts/exynos5420-pinctrl.dtsi  |7 +++
>  arch/arm/boot/dts/exynos5420-smdk5420.dts  |4 +++-
>  arch/arm/boot/dts/exynos5800-peach-pi.dts  |7 +--
>  4 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
> b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> index 9a050e1..f7a44a4 100644
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -569,8 +569,10 @@
>   samsung,dw-mshc-ciu-div = <3>;
>   samsung,dw-mshc-sdr-timing = <0 4>;
>   samsung,dw-mshc-ddr-timing = <0 2>;
> + samsung,dw-mshc-hs400-timing = <0 2>;
> + samsung,read-strobe-delay = <90>;
>   pinctrl-names = "default";
> - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8 &sd0_rclk>;
>   bus-width = <8>;
>  };
>  
> diff --git a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi 
> b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> index ba686e4..8b15316 100644
> --- a/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> +++ b/arch/arm/boot/dts/exynos5420-pinctrl.dtsi
> @@ -201,6 +201,13 @@
>   samsung,pin-drv = <3>;
>   };
>  
> + sd0_rclk: sd0-rclk {
> + samsung,pins = "gpc0-7";
> + samsung,pin-function = <2>;
> + samsung,pin-pud = <1>;
> + samsung,pin-drv = <3>;
> + };
> +
>   sd1_cmd: sd1-cmd {
>   samsung,pins = "gpc1-1";
>   samsung,pin-function = <2>;
> diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
> b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> index 8be3d7b..2078a1f 100644
> --- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
> +++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
> @@ -80,8 +80,10 @@
>   samsung,dw-mshc-ciu-div = <3>;
>   samsung,dw-mshc-sdr-timing = <0 4>;
>   samsung,dw-mshc-ddr-timing = <0 2>;
> + samsung,dw-mshc-hs400-timing = <0 2>;
> + samsung,read-strobe-delay = <90>;
>   pinctrl-names = "default";
> - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8 &sd0_rclk>;
>   bus-width = <8>;
>   cap-mmc-highspeed;
>   };
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
> b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index e8fdda8..96f0d61 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -550,15 +550,18 @@
>   num-slots = <1>;
>   broken-cd;
>   mmc-hs200-1_8v;
> + mmc-hs400-1_8v;
>   cap-mmc-highspeed;
>   non-removable;
>   card-detect-delay = <200>;
> - clock-frequency = <4>;
> + clock-frequency = <8>;
>   samsung,dw-mshc-ciu-div = <3>;
>   samsung,dw-mshc-sdr-timing = <0 4>;
>   samsung,dw-mshc-ddr-timing = <0 2>;
> + samsung,dw-mshc-hs400-timing = <0 2>;
> + samsung,read-strobe-delay = <90>;
>   pinctrl-names = "default";
> - pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8>;
> + pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_bus4 &sd0_bus8 &sd0_rclk>;
>   bus-width = <8>;
>  };
>  
> 

--
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 1/2] mmc: dw_mmc: exynos: Support eMMC's HS400 mode

[Jaehoon Chung]

Hi, Alim.

Tested-by: Jaehoon Chung 
Acked-by: Jaehoon Chung 

I will include this patch into my tree, and i will request pull to Ulf.

Thanks!

Best Regards,
Jaehoon Chung

On 01/29/2015 11:41 AM, Alim Akhtar wrote:
> From: Seungwon Jeon 
> 
> Implements HS400 mode support for exynos host driver.
> This also include some updates as new mode is added.
> 
> Signed-off-by: Seungwon Jeon 
> Signed-off-by: Alim Akhtar 
> [Alim: addressed review comments]
> ---
>  .../devicetree/bindings/mmc/exynos-dw-mshc.txt |7 +
>  drivers/mmc/host/dw_mmc-exynos.c   |  185 
> 
>  drivers/mmc/host/dw_mmc-exynos.h   |   19 +-
>  drivers/mmc/host/dw_mmc.c  |   16 +-
>  drivers/mmc/host/dw_mmc.h  |2 +
>  5 files changed, 195 insertions(+), 34 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt 
> b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> index ee4fc05..aad9844 100644
> --- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
> @@ -36,6 +36,8 @@ Required Properties:
>in transmit mode and CIU clock phase shift value in receive mode for double
>data rate mode operation. Refer notes below for the order of the cells and 
> the
>valid values.
> +* samsung,dw-mshc-hs400-timing: Specifies the value of CIU TX and RX clock 
> phase
> +  shift value for hs400 mode operation.
>  
>Notes for the sdr-timing and ddr-timing values:
>  
> @@ -50,6 +52,9 @@ Required Properties:
>- if CIU clock divider value is 0 (that is divide by 1), both tx and rx
>  phase shift clocks should be 0.
>  
> +* samsung,read-strobe-delay: RCLK (Data strobe) delay to control HS400 mode
> +  (Latency value for delay line in Read path)
> +
>  Required properties for a slot (Deprecated - Recommend to use one slot per 
> host):
>  
>  * gpios: specifies a list of gpios used for command, clock and data bus. The
> @@ -82,5 +87,7 @@ Example:
>   samsung,dw-mshc-ciu-div = <3>;
>   samsung,dw-mshc-sdr-timing = <2 3>;
>   samsung,dw-mshc-ddr-timing = <1 2>;
> + samsung,dw-mshc-hs400-timing = <0 2>;
> + samsung,read-strobe-delay = <90>;
>   bus-width = <8>;
>   };
> diff --git a/drivers/mmc/host/dw_mmc-exynos.c 
> b/drivers/mmc/host/dw_mmc-exynos.c
> index fe32948..0a56d76 100644
> --- a/drivers/mmc/host/dw_mmc-exynos.c
> +++ b/drivers/mmc/host/dw_mmc-exynos.c
> @@ -40,7 +40,12 @@ struct dw_mci_exynos_priv_data {
>   u8  ciu_div;
>   u32 sdr_timing;
>   u32 ddr_timing;
> + u32 hs400_timing;
> + u32 tuned_sample;
>   u32 cur_speed;
> + u32 dqs_delay;
> + u32 saved_dqs_en;
> + u32 saved_strobe_ctrl;
>  };
>  
>  static struct dw_mci_exynos_compatible {
> @@ -71,6 +76,21 @@ static struct dw_mci_exynos_compatible {
>   },
>  };
>  
> +static inline u8 dw_mci_exynos_get_ciu_div(struct dw_mci *host)
> +{
> + struct dw_mci_exynos_priv_data *priv = host->priv;
> +
> + if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS4412)
> + return EXYNOS4412_FIXED_CIU_CLK_DIV;
> + else if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS4210)
> + return EXYNOS4210_FIXED_CIU_CLK_DIV;
> + else if (priv->ctrl_type == DW_MCI_TYPE_EXYNOS7 ||
> + priv->ctrl_type == DW_MCI_TYPE_EXYNOS7_SMU)
> + return SDMMC_CLKSEL_GET_DIV(mci_readl(host, CLKSEL64)) + 1;
> + else
> + return SDMMC_CLKSEL_GET_DIV(mci_readl(host, CLKSEL)) + 1;
> +}
> +
>  static int dw_mci_exynos_priv_init(struct dw_mci *host)
>  {
>   struct dw_mci_exynos_priv_data *priv = host->priv;
> @@ -85,6 +105,16 @@ static int dw_mci_exynos_priv_init(struct dw_mci *host)
>  SDMMC_MPSCTRL_NON_SECURE_WRITE_BIT);
>   }
>  
> + if (priv->ctrl_type >= DW_MCI_TYPE_EXYNOS5420) {
> + priv->saved_strobe_ctrl = mci_readl(host, HS400_DLINE_CTRL);
> + priv->saved_dqs_en = mci_readl(host, HS400_DQS_EN);
> + priv->saved_dqs_en |= AXI_NON_BLOCKING_WR;
> + mci_writel(host, HS400_DQS_EN, priv->saved_dqs_en);
> + if (!priv->dqs_delay)
> + priv->dqs_delay =
> + DQS_CTRL_GET_RD_DELAY(priv->saved_strobe_ctrl);
> + }
> +
>   return 0;
>  }
>  
> @@ -97,6 +127,26 @@ static int dw_mci_exynos_setup_clock(struct dw_mci *host)
>   return 0;
>  }
>  
> +static void dw_mci_exynos_set_clksel_timing(struct dw_mci *host, u32 timing)
> +{
> + struct dw_mci_exynos_priv_data *priv = host->priv;
> + u32 clksel;
> +
> + if (priv->c

Re: [PATCH v6 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save

[Vignesh R]

Hi,

On Thursday 05 February 2015 11:51 AM, Vignesh R wrote:
> 
> 
> On Wednesday 21 January 2015 03:44 PM, Vignesh R wrote:
>> On Tuesday 20 January 2015 09:34 PM, Lee Jones wrote:
>>> On Tue, 20 Jan 2015, R, Vignesh wrote:
 On 1/20/2015 5:23 PM, Lee Jones wrote:
> On Wed, 07 Jan 2015, Vignesh R wrote:
>
>> In one shot mode, sequencer automatically disables all enabled steps at
>> the end of each cycle. (both ADC steps and TSC steps) Hence these steps
>> need not be saved in reg_se_cache for clearing these steps at a later
>> stage.
>> Also, when ADC wakes up Sequencer should not be busy executing any of the
>> config steps except for the charge step. Previously charge step was 1 ADC
>> clock cycle and hence it was ignored.
>> TSC steps are always disabled at the end of each conversion cycle, hence
>> there is no need to explicitly disable TSC steps by writing 0 to REG_SE.
>>
>> Signed-off-by: Vignesh R 
>> ---
>>
>> v5:
>>  - Remove unnecessary clearing of REG_SE
>>
>>  drivers/mfd/ti_am335x_tscadc.c   | 13 +
>>  include/linux/mfd/ti_am335x_tscadc.h |  1 +
>>  2 files changed, 6 insertions(+), 8 deletions(-)
>
> Looks fine.
>
> For my own reference:
>   Acked-by: Lee Jones 
>
> Can this patch be applied on its own?
>

 I prefer to wait until input patches are picked up.
>>>
>>> I have no problem with that, but is there a technical reason why?
>>>
>>
>> Nothing, in particular. This patch alone has no impact on the
>> performance of TSC/ADC unit. Patch 2/6 is necessary to observe the
>> changes caused by this series. Hence, please wait until those patches
>> are picked up.
> 
> Input maintainer has applied other patches. You can pick this one.

Gentle ping... Can you pull this patch into 4.0-rc? Other patches of
this series are already in mainline.

Regards
Vignesh

--
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 3/7] clk: pistachio: Add PLL driver

[Andrew Bresticker]

Add a driver for the integer (GF40LP_LAINT) and fractional (GF40LP_FRAC)
PLLs present on Pistachio.

Signed-off-by: Andrew Bresticker 
---
 drivers/clk/pistachio/Makefile  |   1 +
 drivers/clk/pistachio/clk-pll.c | 401 
 drivers/clk/pistachio/clk.h |  50 +
 3 files changed, 452 insertions(+)
 create mode 100644 drivers/clk/pistachio/clk-pll.c

diff --git a/drivers/clk/pistachio/Makefile b/drivers/clk/pistachio/Makefile
index fc216ad..a93490d 100644
--- a/drivers/clk/pistachio/Makefile
+++ b/drivers/clk/pistachio/Makefile
@@ -1 +1,2 @@
 obj-y  += clk.o
+obj-y  += clk-pll.o
diff --git a/drivers/clk/pistachio/clk-pll.c b/drivers/clk/pistachio/clk-pll.c
new file mode 100644
index 000..de53756
--- /dev/null
+++ b/drivers/clk/pistachio/clk-pll.c
@@ -0,0 +1,401 @@
+/*
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+#define PLL_STATUS 0x0
+#define PLL_STATUS_LOCKBIT(0)
+
+#define PLL_CTRL1  0x4
+#define PLL_CTRL1_REFDIV_SHIFT 0
+#define PLL_CTRL1_REFDIV_MASK  0x3f
+#define PLL_CTRL1_FBDIV_SHIFT  6
+#define PLL_CTRL1_FBDIV_MASK   0xfff
+#define PLL_INT_CTRL1_POSTDIV1_SHIFT   18
+#define PLL_INT_CTRL1_POSTDIV1_MASK0x7
+#define PLL_INT_CTRL1_POSTDIV2_SHIFT   21
+#define PLL_INT_CTRL1_POSTDIV2_MASK0x7
+#define PLL_INT_CTRL1_PD   BIT(24)
+#define PLL_INT_CTRL1_DSMPDBIT(25)
+#define PLL_INT_CTRL1_FOUTPOSTDIVPDBIT(26)
+#define PLL_INT_CTRL1_FOUTVCOPDBIT(27)
+
+#define PLL_CTRL2  0x8
+#define PLL_FRAC_CTRL2_FRAC_SHIFT  0
+#define PLL_FRAC_CTRL2_FRAC_MASK   0xff
+#define PLL_FRAC_CTRL2_POSTDIV1_SHIFT  24
+#define PLL_FRAC_CTRL2_POSTDIV1_MASK   0x7
+#define PLL_FRAC_CTRL2_POSTDIV2_SHIFT  27
+#define PLL_FRAC_CTRL2_POSTDIV2_MASK   0x7
+#define PLL_INT_CTRL2_BYPASS   BIT(28)
+
+#define PLL_CTRL3  0xc
+#define PLL_FRAC_CTRL3_PD  BIT(0)
+#define PLL_FRAC_CTRL3_DACPD   BIT(1)
+#define PLL_FRAC_CTRL3_DSMPD   BIT(2)
+#define PLL_FRAC_CTRL3_FOUTPOSTDIVPD   BIT(3)
+#define PLL_FRAC_CTRL3_FOUT4PHASEPDBIT(4)
+#define PLL_FRAC_CTRL3_FOUTVCOPD   BIT(5)
+
+#define PLL_CTRL4  0x10
+#define PLL_FRAC_CTRL4_BYPASS  BIT(28)
+
+struct pistachio_clk_pll {
+   struct clk_hw hw;
+   void __iomem *base;
+   struct pistachio_pll_rate_table *rates;
+   unsigned int nr_rates;
+};
+
+static inline u32 pll_readl(struct pistachio_clk_pll *pll, u32 reg)
+{
+   return readl(pll->base + reg);
+}
+
+static inline void pll_writel(struct pistachio_clk_pll *pll, u32 val, u32 reg)
+{
+   writel(val, pll->base + reg);
+}
+
+static inline u32 do_div_round_closest(u64 dividend, u32 divisor)
+{
+   dividend += divisor / 2;
+   do_div(dividend, divisor);
+
+   return dividend;
+}
+
+static inline struct pistachio_clk_pll *to_pistachio_pll(struct clk_hw *hw)
+{
+   return container_of(hw, struct pistachio_clk_pll, hw);
+}
+
+static struct pistachio_pll_rate_table *
+pll_get_params(struct pistachio_clk_pll *pll, unsigned long fref,
+  unsigned long fout)
+{
+   unsigned int i;
+
+   for (i = 0; i < pll->nr_rates; i++) {
+   if (pll->rates[i].fref == fref && pll->rates[i].fout == fout)
+   return &pll->rates[i];
+   }
+
+   return NULL;
+}
+
+static long pll_round_rate(struct clk_hw *hw, unsigned long rate,
+  unsigned long *parent_rate)
+{
+   struct pistachio_clk_pll *pll = to_pistachio_pll(hw);
+   unsigned int i;
+
+   for (i = 0; i < pll->nr_rates; i++) {
+   if (i > 0 && pll->rates[i].fref == *parent_rate &&
+   pll->rates[i].fout <= rate)
+   return pll->rates[i - 1].fout;
+   }
+
+   return pll->rates[0].fout;
+}
+
+static int pll_gf40lp_frac_enable(struct clk_hw *hw)
+{
+   struct pistachio_clk_pll *pll = to_pistachio_pll(hw);
+   u32 val;
+
+   val = pll_readl(pll, PLL_CTRL3);
+   val &= ~(PLL_FRAC_CTRL3_PD | PLL_FRAC_CTRL3_DACPD |
+PLL_FRAC_CTRL3_DSMPD | PLL_FRAC_CTRL3_FOUTPOSTDIVPD |
+PLL_FRAC_CTRL3_FOUT4PHASEPD | PLL_FRAC_CTRL3_FOUTVCOPD);
+   pll_writel(pll, val, PLL_CTRL3);
+
+   val = pll_readl(pll, PLL_CTRL4);
+   val &= ~PLL_FRAC_CTRL4_BYPASS;
+   pll_writel(pll, val, PLL_CTRL4);
+
+   return 0;
+}
+
+static void pll_gf40lp_frac_disable(struct clk_hw *hw)
+{
+   struct pistachio_clk_pll *pll = to_pistachio_pll(hw);
+   u32 val;
+
+   val = pll_readl(pll, PLL_CTRL3);
+   val |= PLL_FRAC_CTRL3_PD;

[PATCH 1/7] clk: Add binding document for Pistachio clock controllers

[Andrew Bresticker]

Add a device-tree binding document describing the four clock
controllers present on the IMG Pistachio SoC.

Signed-off-by: Damien Horsley 
Signed-off-by: Andrew Bresticker 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
---
 .../devicetree/bindings/clock/pistachio-clock.txt  | 123 ++
 include/dt-bindings/clock/pistachio-clk.h  | 183 +
 2 files changed, 306 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/pistachio-clock.txt
 create mode 100644 include/dt-bindings/clock/pistachio-clk.h

diff --git a/Documentation/devicetree/bindings/clock/pistachio-clock.txt 
b/Documentation/devicetree/bindings/clock/pistachio-clock.txt
new file mode 100644
index 000..868db49
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/pistachio-clock.txt
@@ -0,0 +1,123 @@
+Imagination Technologies Pistachio SoC clock controllers
+
+
+Pistachio has four clock controllers (core clock, peripheral clock, peripheral
+general control, and top general control) which are instantiated individually
+from the device-tree.
+
+External clocks:
+
+
+There are three external inputs to the clock controllers which should be
+defined with the following clock-output-names:
+- "xtal": External 52Mhz oscillator (required)
+- "audio_clk_in": Alternate audio reference clock (optional)
+- "enet_clk_in": Alternate ethernet PHY clock (optional)
+
+Core clock controller:
+--
+
+The core clock controller generates clocks for the CPU, RPU (WiFi + BT
+co-processor), audio, and several peripherals.
+
+Required properties:
+- compatible: Must be "img,pistachio-clk".
+- reg: Must contain the base address and length of the core clock controller.
+- #clock-cells: Must be 1.  The single cell is the clock identifier.
+  See dt-bindings/clock/pistachio-clk.h for the list of valid identifiers.
+- clocks: Must contain an entry for each clock in clock-names.
+- clock-names: Must include "xtal" (see "External clocks") and
+  "audio_clk_in_gate", "enet_clk_in_gate" which are generated by the
+  top-level general control.
+
+Example:
+   clk_core: clock-controller@18144000 {
+   compatible = "img,pistachio-clk";
+   reg = <0x18144000 0x800>;
+   clocks = <&xtal>, <&cr_top EXT_CLK_AUDIO_IN>,
+<&cr_top EXT_CLK_ENET_IN>;
+   clock-names = "xtal", "audio_clk_in_gate", "enet_clk_in_gate";
+
+   #clock-cells = <1>;
+   };
+
+Peripheral clock controller:
+
+
+The peripheral clock controller generates clocks for the DDR, ROM, and other
+peripherals.  The peripheral system clock ("periph_sys") generated by the core
+clock controller is the input clock to the peripheral clock controller.
+
+Required properties:
+- compatible: Must be "img,pistachio-periph-clk".
+- reg: Must contain the base address and length of the peripheral clock
+  controller.
+- #clock-cells: Must be 1.  The single cell is the clock identifier.
+  See dt-bindings/clock/pistachio-clk.h for the list of valid identifiers.
+- clocks: Must contain an entry for each clock in clock-names.
+- clock-names: Must include "periph_sys", the peripheral system clock generated
+  by the core clock controller.
+
+Example:
+   clk_periph: clock-controller@18144800 {
+   compatible = "img,pistachio-clk-periph";
+   reg = <0x18144800 0x800>;
+   clocks = <&clk_core CLK_PERIPH_SYS>;
+   clock-names = "periph_sys";
+
+   #clock-cells = <1>;
+   };
+
+Peripheral general control:
+---
+
+The peripheral general control block generates system interface clocks and
+resets for various peripherals.  It also contains miscellaneous peripheral
+control registers.  The system clock ("sys") generated by the peripheral clock
+controller is the input clock to the system clock controller.
+
+Required properties:
+- compatible: Must include "img,pistachio-periph-cr" and "syscon".
+- reg: Must contain the base address and length of the peripheral general
+  control registers.
+- #clock-cells: Must be 1.  The single cell is the clock identifier.
+  See dt-bindings/clock/pistachio-clk.h for the list of valid identifiers.
+- clocks: Must contain an entry for each clock in clock-names.
+- clock-names: Must include "sys", the system clock generated by the peripheral
+  clock controller.
+
+Example:
+   cr_periph: syscon@18144800 {
+   compatible = "img,pistachio-cr-periph", "syscon";
+   reg = <0x18148000 0x1000>;
+   clocks = <&clock_periph PERIPH_CLK_PERIPH_SYS>;
+   clock-names = "sys";
+
+   #clock-cells = <1>;
+   };
+
+Top-level general control:
+--
+
+The top-level general control block contains miscellaneous control registers 
and
+gates for the e

[PATCH 2/7] clk: Add basic infrastructure for Pistachio clocks

[Andrew Bresticker]

Add helpers for registering clocks and clock providers on Pistachio.

Signed-off-by: Andrew Bresticker 
---
 drivers/clk/Makefile   |   1 +
 drivers/clk/pistachio/Makefile |   1 +
 drivers/clk/pistachio/clk.c| 140 +
 drivers/clk/pistachio/clk.h| 124 
 4 files changed, 266 insertions(+)
 create mode 100644 drivers/clk/pistachio/Makefile
 create mode 100644 drivers/clk/pistachio/clk.c
 create mode 100644 drivers/clk/pistachio/clk.h

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d478ceb..e43ff53 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_ARCH_MMP)+= mmp/
 endif
 obj-$(CONFIG_PLAT_ORION)   += mvebu/
 obj-$(CONFIG_ARCH_MXS) += mxs/
+obj-$(CONFIG_MACH_PISTACHIO)   += pistachio/
 obj-$(CONFIG_COMMON_CLK_PXA)   += pxa/
 obj-$(CONFIG_COMMON_CLK_QCOM)  += qcom/
 obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
diff --git a/drivers/clk/pistachio/Makefile b/drivers/clk/pistachio/Makefile
new file mode 100644
index 000..fc216ad
--- /dev/null
+++ b/drivers/clk/pistachio/Makefile
@@ -0,0 +1 @@
+obj-y  += clk.o
diff --git a/drivers/clk/pistachio/clk.c b/drivers/clk/pistachio/clk.c
new file mode 100644
index 000..85faa83
--- /dev/null
+++ b/drivers/clk/pistachio/clk.c
@@ -0,0 +1,140 @@
+/*
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+struct pistachio_clk_provider *
+pistachio_clk_alloc_provider(struct device_node *node, unsigned int num_clks)
+{
+   struct pistachio_clk_provider *p;
+
+   p = kzalloc(sizeof(*p), GFP_KERNEL);
+   if (!p)
+   return p;
+
+   p->clk_data.clks = kcalloc(num_clks, sizeof(struct clk *), GFP_KERNEL);
+   if (!p->clk_data.clks)
+   goto free_provider;
+   p->clk_data.clk_num = num_clks;
+   p->node = node;
+   p->base = of_iomap(node, 0);
+   if (!p->base) {
+   pr_err("Failed to map clock provider registers\n");
+   goto free_clks;
+   }
+
+   return p;
+
+free_clks:
+   kfree(p->clk_data.clks);
+free_provider:
+   kfree(p);
+   return NULL;
+}
+
+void pistachio_clk_register_provider(struct pistachio_clk_provider *p)
+{
+   unsigned int i;
+
+   for (i = 0; i < p->clk_data.clk_num; i++) {
+   if (IS_ERR(p->clk_data.clks[i]))
+   pr_warn("Failed to register clock %d: %ld\n", i,
+   PTR_ERR(p->clk_data.clks[i]));
+   }
+
+   of_clk_add_provider(p->node, of_clk_src_onecell_get, &p->clk_data);
+}
+
+void pistachio_clk_register_gate(struct pistachio_clk_provider *p,
+struct pistachio_gate *gate,
+unsigned int num)
+{
+   struct clk *clk;
+   unsigned int i;
+
+   for (i = 0; i < num; i++) {
+   clk = clk_register_gate(NULL, gate[i].name, gate[i].parent,
+   CLK_SET_RATE_PARENT,
+   p->base + gate[i].reg, gate[i].shift,
+   0, NULL);
+   p->clk_data.clks[gate[i].id] = clk;
+   }
+}
+
+void pistachio_clk_register_mux(struct pistachio_clk_provider *p,
+   struct pistachio_mux *mux,
+   unsigned int num)
+{
+   struct clk *clk;
+   unsigned int i;
+
+   for (i = 0; i < num; i++) {
+   clk = clk_register_mux(NULL, mux[i].name, mux[i].parents,
+  mux[i].num_parents,
+  CLK_SET_RATE_NO_REPARENT,
+  p->base + mux[i].reg, mux[i].shift,
+  get_count_order(mux[i].num_parents),
+  0, NULL);
+   p->clk_data.clks[mux[i].id] = clk;
+   }
+}
+
+void pistachio_clk_register_div(struct pistachio_clk_provider *p,
+   struct pistachio_div *div,
+   unsigned int num)
+{
+   struct clk *clk;
+   unsigned int i;
+
+   for (i = 0; i < num; i++) {
+   clk = clk_register_divider(NULL, div[i].name, div[i].parent,
+  0, p->base + div[i].reg, 0,
+  div[i].width, div[i].div_flags,
+  NULL);
+   p->clk_data.clks[div[i].id] = clk;
+   }
+}
+
+void pistachio_clk_register_fixed_factor(struct pistachio_clk_provider *p,
+

[PATCH 6/7] clk: pistachio: Register system interface gate clocks

[Andrew Bresticker]

Register the system interface gate clocks provided by the peripheral
general control block.  These clocks gate register access for various
peripherals.

Signed-off-by: Damien Horsley 
Signed-off-by: Andrew Bresticker 
---
 drivers/clk/pistachio/clk-pistachio.c | 42 +++
 1 file changed, 42 insertions(+)

diff --git a/drivers/clk/pistachio/clk-pistachio.c 
b/drivers/clk/pistachio/clk-pistachio.c
index 0eabb54..3351808 100644
--- a/drivers/clk/pistachio/clk-pistachio.c
+++ b/drivers/clk/pistachio/clk-pistachio.c
@@ -264,3 +264,45 @@ static void __init pistachio_clk_periph_init(struct 
device_node *np)
 }
 CLK_OF_DECLARE(pistachio_clk_periph, "img,pistachio-clk-periph",
   pistachio_clk_periph_init);
+
+static struct pistachio_gate pistachio_sys_gates[] __initdata = {
+   GATE(SYS_CLK_I2C0, "i2c0_sys", "sys", 0x8, 0),
+   GATE(SYS_CLK_I2C1, "i2c1_sys", "sys", 0x8, 1),
+   GATE(SYS_CLK_I2C2, "i2c2_sys", "sys", 0x8, 2),
+   GATE(SYS_CLK_I2C3, "i2c3_sys", "sys", 0x8, 3),
+   GATE(SYS_CLK_I2S_IN, "i2s_in_sys", "sys", 0x8, 4),
+   GATE(SYS_CLK_PAUD_OUT, "paud_out_sys", "sys", 0x8, 5),
+   GATE(SYS_CLK_SPDIF_OUT, "spdif_out_sys", "sys", 0x8, 6),
+   GATE(SYS_CLK_SPI0_MASTER, "spi0_master_sys", "sys", 0x8, 7),
+   GATE(SYS_CLK_SPI0_SLAVE, "spi0_slave_sys", "sys", 0x8, 8),
+   GATE(SYS_CLK_PWM, "pwm_sys", "sys", 0x8, 9),
+   GATE(SYS_CLK_UART0, "uart0_sys", "sys", 0x8, 10),
+   GATE(SYS_CLK_UART1, "uart1_sys", "sys", 0x8, 11),
+   GATE(SYS_CLK_SPI1, "spi1_sys", "sys", 0x8, 12),
+   GATE(SYS_CLK_MDC, "mdc_sys", "sys", 0x8, 13),
+   GATE(SYS_CLK_SD_HOST, "sd_host_sys", "sys", 0x8, 14),
+   GATE(SYS_CLK_ENET, "enet_sys", "sys", 0x8, 15),
+   GATE(SYS_CLK_IR, "ir_sys", "sys", 0x8, 16),
+   GATE(SYS_CLK_WD, "wd_sys", "sys", 0x8, 17),
+   GATE(SYS_CLK_TIMER, "timer_sys", "sys", 0x8, 18),
+   GATE(SYS_CLK_I2S_OUT, "i2s_out_sys", "sys", 0x8, 24),
+   GATE(SYS_CLK_SPDIF_IN, "spdif_in_sys", "sys", 0x8, 25),
+   GATE(SYS_CLK_EVENT_TIMER, "event_timer_sys", "sys", 0x8, 26),
+   GATE(SYS_CLK_HASH, "hash_sys", "sys", 0x8, 27),
+};
+
+static void __init pistachio_cr_periph_init(struct device_node *np)
+{
+   struct pistachio_clk_provider *p;
+
+   p = pistachio_clk_alloc_provider(np, SYS_CLK_NR_CLKS);
+   if (!p)
+   return;
+
+   pistachio_clk_register_gate(p, pistachio_sys_gates,
+   ARRAY_SIZE(pistachio_sys_gates));
+
+   pistachio_clk_register_provider(p);
+}
+CLK_OF_DECLARE(pistachio_cr_periph, "img,pistachio-cr-periph",
+  pistachio_cr_periph_init);
-- 
2.2.0.rc0.207.ga3a616c

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/7] clk: pistachio: Register peripheral clocks

[Andrew Bresticker]

Register the clocks generated by the peripheral clock controller.
This includes the clocks for several peripherals, including I2C,
PWM, watchdog, and timer.

Signed-off-by: Damien Horsley 
Signed-off-by: Andrew Bresticker 
---
 drivers/clk/pistachio/clk-pistachio.c | 67 +++
 1 file changed, 67 insertions(+)

diff --git a/drivers/clk/pistachio/clk-pistachio.c 
b/drivers/clk/pistachio/clk-pistachio.c
index 12a45e2..0eabb54 100644
--- a/drivers/clk/pistachio/clk-pistachio.c
+++ b/drivers/clk/pistachio/clk-pistachio.c
@@ -197,3 +197,70 @@ static void __init pistachio_clk_init(struct device_node 
*np)
   ARRAY_SIZE(pistachio_critical_clks));
 }
 CLK_OF_DECLARE(pistachio_clk, "img,pistachio-clk", pistachio_clk_init);
+
+static struct pistachio_gate pistachio_periph_gates[] __initdata = {
+   GATE(PERIPH_CLK_SYS, "sys", "periph_sys", 0x100, 0),
+   GATE(PERIPH_CLK_SYS_BUS, "bus_sys", "periph_sys", 0x100, 1),
+   GATE(PERIPH_CLK_DDR, "ddr", "periph_sys", 0x100, 2),
+   GATE(PERIPH_CLK_ROM, "rom", "rom_div", 0x100, 3),
+   GATE(PERIPH_CLK_COUNTER_FAST, "counter_fast", "counter_fast_div",
+0x100, 4),
+   GATE(PERIPH_CLK_COUNTER_SLOW, "counter_slow", "counter_slow_div",
+0x100, 5),
+   GATE(PERIPH_CLK_IR, "ir", "ir_div", 0x100, 6),
+   GATE(PERIPH_CLK_WD, "wd", "wd_div", 0x100, 7),
+   GATE(PERIPH_CLK_PDM, "pdm", "pdm_div", 0x100, 8),
+   GATE(PERIPH_CLK_PWM, "pwm", "pwm_div", 0x100, 9),
+   GATE(PERIPH_CLK_I2C0, "i2c0", "i2c0_div", 0x100, 10),
+   GATE(PERIPH_CLK_I2C1, "i2c1", "i2c1_div", 0x100, 11),
+   GATE(PERIPH_CLK_I2C2, "i2c2", "i2c2_div", 0x100, 12),
+   GATE(PERIPH_CLK_I2C3, "i2c3", "i2c3_div", 0x100, 13),
+};
+
+static struct pistachio_div pistachio_periph_divs[] __initdata = {
+   DIV(PERIPH_CLK_ROM_DIV, "rom_div", "periph_sys", 0x10c, 7),
+   DIV(PERIPH_CLK_COUNTER_FAST_DIV, "counter_fast_div", "periph_sys",
+   0x110, 7),
+   DIV(PERIPH_CLK_COUNTER_SLOW_PRE_DIV, "counter_slow_pre_div",
+   "periph_sys", 0x114, 7),
+   DIV(PERIPH_CLK_COUNTER_SLOW_DIV, "counter_slow_div",
+   "counter_slow_pre_div", 0x118, 7),
+   DIV_F(PERIPH_CLK_IR_PRE_DIV, "ir_pre_div", "periph_sys", 0x11c, 7,
+ CLK_DIVIDER_ROUND_CLOSEST),
+   DIV_F(PERIPH_CLK_IR_DIV, "ir_div", "ir_pre_div", 0x120, 7,
+ CLK_DIVIDER_ROUND_CLOSEST),
+   DIV_F(PERIPH_CLK_WD_PRE_DIV, "wd_pre_div", "periph_sys", 0x124, 7,
+ CLK_DIVIDER_ROUND_CLOSEST),
+   DIV_F(PERIPH_CLK_WD_DIV, "wd_div", "wd_pre_div", 0x128, 7,
+ CLK_DIVIDER_ROUND_CLOSEST),
+   DIV(PERIPH_CLK_PDM_PRE_DIV, "pdm_pre_div", "periph_sys", 0x12c, 7),
+   DIV(PERIPH_CLK_PDM_DIV, "pdm_div", "pdm_pre_div", 0x130, 7),
+   DIV(PERIPH_CLK_PWM_PRE_DIV, "pwm_pre_div", "periph_sys", 0x134, 7),
+   DIV(PERIPH_CLK_PWM_DIV, "pwm_div", "pwm_pre_div", 0x138, 7),
+   DIV(PERIPH_CLK_I2C0_PRE_DIV, "i2c0_pre_div", "periph_sys", 0x13c, 7),
+   DIV(PERIPH_CLK_I2C0_DIV, "i2c0_div", "i2c0_pre_div", 0x140, 7),
+   DIV(PERIPH_CLK_I2C1_PRE_DIV, "i2c1_pre_div", "periph_sys", 0x144, 7),
+   DIV(PERIPH_CLK_I2C1_DIV, "i2c1_div", "i2c1_pre_div", 0x148, 7),
+   DIV(PERIPH_CLK_I2C2_PRE_DIV, "i2c2_pre_div", "periph_sys", 0x14c, 7),
+   DIV(PERIPH_CLK_I2C2_DIV, "i2c2_div", "i2c2_pre_div", 0x150, 7),
+   DIV(PERIPH_CLK_I2C3_PRE_DIV, "i2c3_pre_div", "periph_sys", 0x154, 7),
+   DIV(PERIPH_CLK_I2C3_DIV, "i2c3_div", "i2c3_pre_div", 0x158, 7),
+};
+
+static void __init pistachio_clk_periph_init(struct device_node *np)
+{
+   struct pistachio_clk_provider *p;
+
+   p = pistachio_clk_alloc_provider(np, PERIPH_CLK_NR_CLKS);
+   if (!p)
+   return;
+
+   pistachio_clk_register_div(p, pistachio_periph_divs,
+  ARRAY_SIZE(pistachio_periph_divs));
+   pistachio_clk_register_gate(p, pistachio_periph_gates,
+   ARRAY_SIZE(pistachio_periph_gates));
+
+   pistachio_clk_register_provider(p);
+}
+CLK_OF_DECLARE(pistachio_clk_periph, "img,pistachio-clk-periph",
+  pistachio_clk_periph_init);
-- 
2.2.0.rc0.207.ga3a616c

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/7] clk: pistachio: Register core clocks

[Andrew Bresticker]

Register the clocks generated by the core clock controller.
This includes the 7 PLLs and clocks for the CPU, RPU co-processor,
audio, WiFi, bluetooth, and several other peripherals.

The MIPS and PERIPH_SYS clocks must remain enabled at all times.

Signed-off-by: Damien Horsley 
Signed-off-by: Andrew Bresticker 
---
 drivers/clk/pistachio/Makefile|   1 +
 drivers/clk/pistachio/clk-pistachio.c | 199 ++
 2 files changed, 200 insertions(+)
 create mode 100644 drivers/clk/pistachio/clk-pistachio.c

diff --git a/drivers/clk/pistachio/Makefile b/drivers/clk/pistachio/Makefile
index a93490d..f1e151f 100644
--- a/drivers/clk/pistachio/Makefile
+++ b/drivers/clk/pistachio/Makefile
@@ -1,2 +1,3 @@
 obj-y  += clk.o
 obj-y  += clk-pll.o
+obj-y  += clk-pistachio.o
diff --git a/drivers/clk/pistachio/clk-pistachio.c 
b/drivers/clk/pistachio/clk-pistachio.c
new file mode 100644
index 000..12a45e2
--- /dev/null
+++ b/drivers/clk/pistachio/clk-pistachio.c
@@ -0,0 +1,199 @@
+/*
+ * Pistachio SoC clock controllers
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "clk.h"
+
+static struct pistachio_gate pistachio_gates[] __initdata = {
+   GATE(CLK_MIPS, "mips", "mips_div", 0x104, 0),
+   GATE(CLK_AUDIO_IN, "audio_in", "audio_clk_in_gate", 0x104, 1),
+   GATE(CLK_AUDIO, "audio", "audio_div", 0x104, 2),
+   GATE(CLK_I2S, "i2s", "i2s_div", 0x104, 3),
+   GATE(CLK_SPDIF, "spdif", "spdif_div", 0x104, 4),
+   GATE(CLK_AUDIO_DAC, "audio_dac", "audio_dac_div", 0x104, 5),
+   GATE(CLK_RPU_V, "rpu_v", "rpu_v_div", 0x104, 6),
+   GATE(CLK_RPU_L, "rpu_l", "rpu_l_div", 0x104, 7),
+   GATE(CLK_RPU_SLEEP, "rpu_sleep", "rpu_sleep_div", 0x104, 8),
+   GATE(CLK_WIFI_PLL_GATE, "wifi_pll_gate", "wifi_pll_mux", 0x104, 9),
+   GATE(CLK_RPU_CORE, "rpu_core", "rpu_core_div", 0x104, 10),
+   GATE(CLK_WIFI_ADC, "wifi_adc", "wifi_div8_mux", 0x104, 11),
+   GATE(CLK_WIFI_DAC, "wifi_dac", "wifi_div4_mux", 0x104, 12),
+   GATE(CLK_USB_PHY, "usb_phy", "usb_phy_div", 0x104, 13),
+   GATE(CLK_ENET_IN, "enet_in", "enet_clk_in_gate", 0x104, 14),
+   GATE(CLK_ENET, "enet", "enet_div", 0x104, 15),
+   GATE(CLK_UART0, "uart0", "uart0_div", 0x104, 16),
+   GATE(CLK_UART1, "uart1", "uart1_div", 0x104, 17),
+   GATE(CLK_PERIPH_SYS, "periph_sys", "sys_internal_div", 0x104, 18),
+   GATE(CLK_SPI0, "spi0", "spi0_div", 0x104, 19),
+   GATE(CLK_SPI1, "spi1", "spi1_div", 0x104, 20),
+   GATE(CLK_EVENT_TIMER, "event_timer", "event_timer_div", 0x104, 21),
+   GATE(CLK_AUX_ADC_INTERNAL, "aux_adc_internal", "sys_internal_div",
+0x104, 22),
+   GATE(CLK_AUX_ADC, "aux_adc", "aux_adc_div", 0x104, 23),
+   GATE(CLK_SD_HOST, "sd_host", "sd_host_div", 0x104, 24),
+   GATE(CLK_BT, "bt", "bt_div", 0x104, 25),
+   GATE(CLK_BT_DIV4, "bt_div4", "bt_div4_div", 0x104, 26),
+   GATE(CLK_BT_DIV8, "bt_div8", "bt_div8_div", 0x104, 27),
+   GATE(CLK_BT_1MHZ, "bt_1mhz", "bt_1mhz_div", 0x104, 28),
+};
+
+static struct pistachio_fixed_factor pistachio_ffs[] __initdata = {
+   FIXED_FACTOR(CLK_WIFI_DIV4, "wifi_div4", "wifi_pll", 4),
+   FIXED_FACTOR(CLK_WIFI_DIV8, "wifi_div8", "wifi_pll", 8),
+};
+
+static struct pistachio_div pistachio_divs[] __initdata = {
+   DIV(CLK_MIPS_INTERNAL_DIV, "mips_internal_div", "mips_pll_mux",
+   0x204, 2),
+   DIV(CLK_MIPS_DIV, "mips_div", "mips_internal_div", 0x208, 8),
+   DIV_F(CLK_AUDIO_DIV, "audio_div", "audio_mux",
+   0x20c, 8, CLK_DIVIDER_ROUND_CLOSEST),
+   DIV_F(CLK_I2S_DIV, "i2s_div", "audio_pll_mux",
+   0x210, 8, CLK_DIVIDER_ROUND_CLOSEST),
+   DIV_F(CLK_SPDIF_DIV, "spdif_div", "audio_pll_mux",
+   0x214, 8, CLK_DIVIDER_ROUND_CLOSEST),
+   DIV_F(CLK_AUDIO_DAC_DIV, "audio_dac_div", "audio_pll_mux",
+   0x218, 8, CLK_DIVIDER_ROUND_CLOSEST),
+   DIV(CLK_RPU_V_DIV, "rpu_v_div", "rpu_v_pll_mux", 0x21c, 2),
+   DIV(CLK_RPU_L_DIV, "rpu_l_div", "rpu_l_mux", 0x220, 2),
+   DIV(CLK_RPU_SLEEP_DIV, "rpu_sleep_div", "xtal", 0x224, 10),
+   DIV(CLK_RPU_CORE_DIV, "rpu_core_div", "rpu_core_mux", 0x228, 3),
+   DIV(CLK_USB_PHY_DIV, "usb_phy_div", "sys_internal_div", 0x22c, 6),
+   DIV(CLK_ENET_DIV, "enet_div", "enet_mux", 0x230, 6),
+   DIV_F(CLK_UART0_INTERNAL_DIV, "uart0_internal_div", "sys_pll_mux",
+ 0x234, 3, CLK_DIVIDER_ROUND_CLOSEST),
+   DIV_F(CLK_UART0_DIV, "uart0_div", "uart0_internal_div", 0x238, 10,
+ CLK_DIVIDER_ROUND_CLOSEST),
+   DIV_F(CLK_UART1_INTERNAL_DIV, "uart1_internal_div", "sys_pll_mux",
+ 0x23c, 3, CLK_DIVIDER_ROUND_CLOSEST),
+   DI

[PATCH 7/7] clk: pistachio: Register external clock gates

[Andrew Bresticker]

Register the clock gates for the external audio and ethernet
reference clocks provided by the top-level general control block.

Signed-off-by: Damien Horsley 
Signed-off-by: Andrew Bresticker 
---
 drivers/clk/pistachio/clk-pistachio.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/clk/pistachio/clk-pistachio.c 
b/drivers/clk/pistachio/clk-pistachio.c
index 3351808..8c0fe88 100644
--- a/drivers/clk/pistachio/clk-pistachio.c
+++ b/drivers/clk/pistachio/clk-pistachio.c
@@ -306,3 +306,24 @@ static void __init pistachio_cr_periph_init(struct 
device_node *np)
 }
 CLK_OF_DECLARE(pistachio_cr_periph, "img,pistachio-cr-periph",
   pistachio_cr_periph_init);
+
+static struct pistachio_gate pistachio_ext_gates[] __initdata = {
+   GATE(EXT_CLK_ENET_IN, "enet_clk_in_gate", "enet_clk_in", 0x58, 5),
+   GATE(EXT_CLK_AUDIO_IN, "audio_clk_in_gate", "audio_clk_in", 0x58, 8)
+};
+
+static void __init pistachio_cr_top_init(struct device_node *np)
+{
+   struct pistachio_clk_provider *p;
+
+   p = pistachio_clk_alloc_provider(np, EXT_CLK_NR_CLKS);
+   if (!p)
+   return;
+
+   pistachio_clk_register_gate(p, pistachio_ext_gates,
+   ARRAY_SIZE(pistachio_ext_gates));
+
+   pistachio_clk_register_provider(p);
+}
+CLK_OF_DECLARE(pistachio_cr_top, "img,pistachio-cr-top",
+  pistachio_cr_top_init);
-- 
2.2.0.rc0.207.ga3a616c

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/7] clk: Common clock support for IMG Pistachio

[Andrew Bresticker]

This series adds common clock support for the IMG Pistachio SoC.
Pistachio has two clock controllers (core and peripheral) and two
general control blocks (peripheral and top) which also contain
several clock gates.  Like the recently submitted pinctrl driver [1],
this driver is written so that it's hopefully easy to add support
for future IMG SoCs.

Tested on an IMG Pistachio BuB.  Based on 4.0-rc1 + my series adding
Pistachio platform support [2], which introduces the MACH_PISTACHIO
Kconfig symbol.  A branch with this series and the dependent patches
is available at [3].  I'd like this to go through the MIPS tree with
Mike's or Stephen's ACK if possible.

Cc: Ezequiel Garcia 
Cc: James Hartley 
Cc: James Hogan 

[1] https://lkml.org/lkml/2015/2/23/705
[2] https://lkml.org/lkml/2015/2/23/694
[3] https://github.com/abrestic/linux/tree/pistachio-clk-v1

Andrew Bresticker (7):
  clk: Add binding document for Pistachio clock controllers
  clk: Add basic infrastructure for Pistachio clocks
  clk: pistachio: Add PLL driver
  clk: pistachio: Register core clocks
  clk: pistachio: Register peripheral clocks
  clk: pistachio: Register system interface gate clocks
  clk: pistachio: Register external clock gates

 .../devicetree/bindings/clock/pistachio-clock.txt  | 123 +++
 drivers/clk/Makefile   |   1 +
 drivers/clk/pistachio/Makefile |   3 +
 drivers/clk/pistachio/clk-pistachio.c  | 329 +
 drivers/clk/pistachio/clk-pll.c| 401 +
 drivers/clk/pistachio/clk.c| 140 +++
 drivers/clk/pistachio/clk.h| 174 +
 include/dt-bindings/clock/pistachio-clk.h  | 183 ++
 8 files changed, 1354 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/pistachio-clock.txt
 create mode 100644 drivers/clk/pistachio/Makefile
 create mode 100644 drivers/clk/pistachio/clk-pistachio.c
 create mode 100644 drivers/clk/pistachio/clk-pll.c
 create mode 100644 drivers/clk/pistachio/clk.c
 create mode 100644 drivers/clk/pistachio/clk.h
 create mode 100644 include/dt-bindings/clock/pistachio-clk.h

-- 
2.2.0.rc0.207.ga3a616c

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/4] media: ov2640: add primary dt support

[Josh Wu]

Hi, Prabhakar Lad

On 2/17/2015 12:48 AM, Lad, Prabhakar wrote:

Hi Josh,

Thanks for the patch.

On Tue, Feb 10, 2015 at 9:31 AM, Josh Wu  wrote:
[Snip]

-   priv->clk = v4l2_clk_get(&client->dev, "mclk");
+   priv->clk = v4l2_clk_get(&client->dev, "xvclk");

with this change don’t you need to update the board file using this driver/
the bridge driver ?

I think no.

First, my patch should be on top of the following two patches, which 
changed the *v4l2_clk_get()* behavior:

[v3,1/2] V4L: remove clock name from v4l2_clk API
https://patchwork.linuxtv.org/patch/28108/
[v4,2/2] V4L: add CCF support to the v4l2_clk API
https://patchwork.linuxtv.org/patch/28111/

After applied above two patches, v4l2_clk_get() function is changed. The 
name "mclk" is refer to a CCF clock of the ov2640 device.
If not found such a "mclk" CCF clock, v4l2_clk_get() will try to get the 
internal register clock in soc_camera.c.
As the CCF dt clock is not support by ov2640 until I add DT support, 
that means current ov2640 driver will always not found the "mclk" CCF 
clock, and they will use internal clock.
So after I changed the name "mclk" to "xvclk", the default behavior will 
not change (still using internal clock registered by soc-camera.c).


Best Regards,
Josh Wu



Regards,
--Prabhakar Lad


--
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 v3 2/2] leds: add Qualcomm PM8941 WLED driver

[Bjorn Andersson]

From: Courtney Cavin 

This adds support for the WLED ('White' LED) block on Qualcomm's
PM8941 PMICs.

Signed-off-by: Courtney Cavin 
Signed-off-by: Bjorn Andersson 
---

The details surrounding the OVP spike issue that Stephen brought up during v2
review is still unkown, the patches provided on codeaurora msm-3.10 can with
ease be implemented as an incremental patch on top of this.
As the severity doesn't seem to high (the fixes are not done on all active msm
branches), I'm sending out v3 instead of waiting for a conclusion.

Changes since v2:
- Fix of parser return value on error
- Dropped THIS_MODULE

Changes since v1:
- Replace enum blob with defines
- Merged wled_context and wled structs
- Some style updates

 drivers/leds/Kconfig|   8 +
 drivers/leds/Makefile   |   1 +
 drivers/leds/leds-pm8941-wled.c | 446 
 3 files changed, 455 insertions(+)
 create mode 100644 drivers/leds/leds-pm8941-wled.c

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index a6c3d2f..901b21a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -516,6 +516,14 @@ config LEDS_VERSATILE
  This option enabled support for the LEDs on the ARM Versatile
  and RealView boards. Say Y to enabled these.
 
+config LEDS_PM8941_WLED
+   tristate "LED support for the Qualcomm PM8941 WLED block"
+   depends on LEDS_CLASS
+   select REGMAP
+   help
+ This option enables support for the 'White' LED block
+ on Qualcomm PM8941 PMICs.
+
 comment "LED Triggers"
 source "drivers/leds/trigger/Kconfig"
 
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 1c65a19..4325e49 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
 obj-$(CONFIG_LEDS_SYSCON)  += leds-syscon.o
 obj-$(CONFIG_LEDS_VERSATILE)   += leds-versatile.o
 obj-$(CONFIG_LEDS_MENF21BMC)   += leds-menf21bmc.o
+obj-$(CONFIG_LEDS_PM8941_WLED) += leds-pm8941-wled.o
 
 # LED SPI Drivers
 obj-$(CONFIG_LEDS_DAC124S085)  += leds-dac124s085.o
diff --git a/drivers/leds/leds-pm8941-wled.c b/drivers/leds/leds-pm8941-wled.c
new file mode 100644
index 000..9bf7358
--- /dev/null
+++ b/drivers/leds/leds-pm8941-wled.c
@@ -0,0 +1,446 @@
+/* Copyright (c) 2015, Sony Mobile Communications, AB.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PM8941_WLED_REG_VAL_BASE   0x40
+#define  PM8941_WLED_REG_VAL_MAX   0xFFF
+
+#define PM8941_WLED_REG_MOD_EN 0x46
+#define  PM8941_WLED_REG_MOD_EN_BITBIT(7)
+#define  PM8941_WLED_REG_MOD_EN_MASK   BIT(7)
+
+#define PM8941_WLED_REG_SYNC   0x47
+#define  PM8941_WLED_REG_SYNC_MASK 0x07
+#define  PM8941_WLED_REG_SYNC_LED1 BIT(0)
+#define  PM8941_WLED_REG_SYNC_LED2 BIT(1)
+#define  PM8941_WLED_REG_SYNC_LED3 BIT(2)
+#define  PM8941_WLED_REG_SYNC_ALL  0x07
+#define  PM8941_WLED_REG_SYNC_CLEAR0x00
+
+#define PM8941_WLED_REG_FREQ   0x4c
+#define  PM8941_WLED_REG_FREQ_MASK 0x0f
+
+#define PM8941_WLED_REG_OVP0x4d
+#define  PM8941_WLED_REG_OVP_MASK  0x03
+
+#define PM8941_WLED_REG_BOOST  0x4e
+#define  PM8941_WLED_REG_BOOST_MASK0x07
+
+#define PM8941_WLED_REG_SINK   0x4f
+#define  PM8941_WLED_REG_SINK_MASK 0xe0
+#define  PM8941_WLED_REG_SINK_SHFT 0x05
+
+/* Per-'string' registers below */
+#define PM8941_WLED_REG_STR_OFFSET 0x10
+
+#define PM8941_WLED_REG_STR_MOD_EN_BASE0x60
+#define  PM8941_WLED_REG_STR_MOD_MASK  BIT(7)
+#define  PM8941_WLED_REG_STR_MOD_ENBIT(7)
+
+#define PM8941_WLED_REG_STR_SCALE_BASE 0x62
+#define  PM8941_WLED_REG_STR_SCALE_MASK0x1f
+
+#define PM8941_WLED_REG_STR_MOD_SRC_BASE   0x63
+#define  PM8941_WLED_REG_STR_MOD_SRC_MASK  0x01
+#define  PM8941_WLED_REG_STR_MOD_SRC_INT   0x00
+#define  PM8941_WLED_REG_STR_MOD_SRC_EXT   0x01
+
+#define PM8941_WLED_REG_STR_CABC_BASE  0x66
+#define  PM8941_WLED_REG_STR_CABC_MASK BIT(7)
+#define  PM8941_WLED_REG_STR_CABC_EN   BIT(7)
+
+struct pm8941_wled_config {
+   u32 i_boost_limit;
+   u32 ovp;
+   u32 switch_freq;
+   u32 num_strings;
+   u32 i_limit;
+   bool cs_o

[PATCH v3 1/2] leds: add DT binding for Qualcomm PM8941 WLED block

[Bjorn Andersson]

From: Courtney Cavin 

This adds device tree binding documentation for the WLED ('White' LED)
block on Qualcomm's PM8941 PMICs.

Signed-off-by: Courtney Cavin 
Signed-off-by: Bjorn Andersson 
---

Changes since v2:
- None

Changes since v1:
- None

 .../devicetree/bindings/leds/leds-pm8941-wled.txt  | 43 ++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt

diff --git a/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt 
b/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
new file mode 100644
index 000..a85a964
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
@@ -0,0 +1,43 @@
+Binding for Qualcomm PM8941 WLED driver
+
+Required properties:
+- compatible: should be "qcom,pm8941-wled"
+- reg: slave address
+
+Optional properties:
+- label: The label for this led
+  See Documentation/devicetree/bindings/leds/common.txt
+- linux,default-trigger: Default trigger assigned to the LED
+  See Documentation/devicetree/bindings/leds/common.txt
+- qcom,cs-out: bool; enable current sink output
+- qcom,cabc: bool; enable content adaptive backlight control
+- qcom,ext-gen: bool; use externally generated modulator signal to dim
+- qcom,current-limit: mA; per-string current limit; value from 0 to 25
+   default: 20mA
+- qcom,current-boost-limit: mA; boost current limit; one of:
+   105, 385, 525, 805, 980, 1260, 1400, 1680
+   default: 805mA
+- qcom,switching-freq: kHz; switching frequency; one of:
+   600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371,
+   1600, 1920, 2400, 3200, 4800, 9600,
+   default: 1600kHz
+- qcom,ovp: V; Over-voltage protection limit; one of:
+   27, 29, 32, 35
+   default: 29V
+- qcom,num-strings: #; number of led strings attached; value from 1 to 3
+   default: 2
+
+Example:
+
+pm8941-wled@d800 {
+   compatible = "qcom,pm8941-wled";
+   reg = <0xd800>;
+   label = "backlight";
+
+   qcom,cs-out;
+   qcom,current-limit = <20>;
+   qcom,current-boost-limit = <805>;
+   qcom,switching-freq = <1600>;
+   qcom,ovp = <29>;
+   qcom,num-strings = <2>;
+};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] OPP: Redefine bindings to overcome shortcomings

[viresh kumar]

On Tuesday 24 February 2015 10:42 PM, Kevin Hilman wrote:
> Viresh Kumar  writes:

> s/they share clock lines/they share clock and/or voltage lines/

Hmm, will update that.

> OK, fair enough.  Looks like it's been thought through.  
> 
> However, in the end, I don't think it's going to avoid the "help of some
> algorithms."  The flag will tell you it's shared, but not how, and that
> will likely still need to be determined.

What did you mean by 'how' here? You wanted to say which devices share the
OPP? Yeah, a small piece of code is required and that's present in my patchset.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 6/7] PCI: update dma configuration from DT

[Bjorn Helgaas]

On Thu, Feb 05, 2015 at 04:52:58PM -0500, Murali Karicheri wrote:
> If there is a DT node available for the root bridge's parent device,
> use the dma configuration from that device node. For example, keystone
> PCI devices would require dma_pfn_offset to be set correctly in the
> device structure of the pci device in order to have the correct dma mask.
> The DT node will have dma-ranges defined for this. Also support using
> the DT property dma-coherent to allow coherent DMA operation by the
> PCI device.

Hi Murali,

I'm guessing this is the patch that actually fixes things for Keystone.

And it looks like it should also fix things for other hardware that has
similar characteristics.  So I'd like to include some higher-level text
about that here.  For example:

  This fixes DMA on systems where DMA addresses are a constant offset
  from CPU physical addresses.

(I don't know exactly how these patches all fit together, so that's
probably not accurate, but that's the *sort* of thing I'd like to include.)

If that actually *is* what's going on, I have to wonder why this isn't
implemented as a very simple IOMMU instead of adding dma_pfn_offset,
which is present on all arches but only used on ARM.  In some sense that
offset is parallel but incompatible with an IOMMU: they both translate DMA
addresses into system RAM addresses.

I know you're not adding this, and I assume somebody explored that option
and rejected it for good reasons.  I just missed that discussion.

> This patch use the new helper function of_pci_dma_configure() to update
> the device dma configuration.
> 
> Cc: Joerg Roedel 
> Cc: Grant Likely 
> Cc: Rob Herring 
> Cc: Will Deacon 
> Cc: Russell King 
> Cc: Arnd Bergmann 
> Cc: Suravee Suthikulpanit 
> 
> Acked-by: Bjorn Helgaas 
> Signed-off-by: Murali Karicheri 
> ---
>  drivers/pci/probe.c |2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 23212f8..d7dcd6c 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -6,6 +6,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1520,6 +1521,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus 
> *bus)
>   dev->dev.dma_mask = &dev->dma_mask;
>   dev->dev.dma_parms = &dev->dma_parms;
>   dev->dev.coherent_dma_mask = 0xull;
> + of_pci_dma_configure(dev);
>  
>   pci_set_dma_max_seg_size(dev, 65536);
>   pci_set_dma_seg_boundary(dev, 0x);
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 1/2] powerpc/mpc85xx: Add FSL QorIQ DPAA BMan support to device tree(s)

[Scott Wood]

On Mon, 2015-02-02 at 00:53 -0600, Emil Medve wrote:
> From: Kumar Gala 
> 
> Change-Id: If643fa5ba0a903aef8f5056a2c90ebecc995b760

Remove these.

-Scott


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework

[Stephen Boyd]

On 02/24, Maxime Ripard wrote:
> On Mon, Feb 23, 2015 at 03:11:40PM -0800, Stephen Boyd wrote:
> > >>> I would do something more simple that is just a list of keys and
> > >>> their location like this:
> > >>>
> > >>> device-serial-number = ;
> > >>> key1 = ;
> > >>> key2 = ;
> > >> I'm sorry, but what's the difference?
> > > It can describe the layout completely whether the fields are tied to a
> > > h/w device or not.
> > >
> > > What I would like to see here is the entire layout described covering
> > > both types of fields.
> > >
> > 
> > I was thinking the DT might be like this on the provider side:
> > 
> >qfprom@100 {
> >   reg = <0x100 0x1000>;
> >   ranges = <0 0x100 0x1000>;
> >   compatible = "qcom,qfprom-msm8960"
> > 
> >   pvs-data: pvs-data@40 {
> > compatible = "qcom,pvs-a";
> > reg = <0x40 0x20>,
> > #eeprom-cells = <0>;
> >   };
> > 
> >tsens-data: tmdata@10 {
> > compatible = "qcom,tsens-data-msm8960";
> > reg = <0x10 4>, <0x16 4>;
> > #eeprom-cells = <0>;
> > 
> >   };
> > 
> >   serial-number: serial@50 {
> > compatible = "qcom,serial-msm8960";
> > reg = <0x50 4>, <0x60 4>;
> > #eeprom-cells = <0>;
> > 
> >   };
> >};
> 
> I'm not sure the compatible is really needed.
> 
> A label of some sort, just like the MTD partitions do would do just
> fine, and wouldn't have the implicit expectation that a driver will be
> probed from that node.

I wasn't aware that compatible meant driver probe. I thought
compatible just meant some software entity can understand what
I've described within this node. For example, compatible for
reserved-memory nodes doesn't mean we're going to probe a device.

> 
> > and then on the consumer side:
> > 
> > device {
> > eeproms = <&serial-number>;
> > eeprom-names = "soc-rev-id";
> > };
> > 
> > 
> > This would solve a problem where the consumer device is some standard
> > off-the-shelf IP block that needs to get some SoC specific calibration
> > data from the eeprom. I may want to interpret the bits differently
> > depending on which eeprom is connected to my SoC. Sometimes that data
> > format may be the same across many variations of the SoC (e.g. the
> > qcom,pvs-a node) or it may be completely different for a given SoC (e.g.
> > qcom,serial-msm8960 node). I imagine for other SoCs out there it could
> > be different depending on which eeprom the board manufacturer decides to
> > wire onto their board and how they choose to program the data.
> 
> Oh, so you'd like to infer the data format it's stored in from the
> compatible?
> 
> AFAICT, this format will be highly depending on the board itself,
> rather than on the SoC, do you think it will scale enough?
> 
> > So this is where I think the eeprom-cells and offset + length starts to
> > fall apart. It forces us to make up a bunch of different compatible
> > strings for our consumer device just so that we can parse the eeprom
> > that we decided to use for some SoC/board specific data. Instead I'd
> > like to see some framework that expresses exactly which eeprom is on my
> > board and how to interpret the bits in a way that doesn't require me to
> > keep refining the compatible string for my generic IP block.
> 
> H, apparently you don't :)
> 
> > I worry that if we put all those details in DT we'll end up having to
> > describe individual bits like serial-number-bit-2, serial-number-bit-3,
> > etc. because sometimes these pieces of data are scattered all around the
> > eeprom and aren't contiguous or aligned on a byte boundary. It may be
> > easier to just have a way to express that this is an eeprom with this
> > specific layout and my device has data stored in there. Then the driver
> > can be told what layout it is (via compatible or some other string based
> > means if we're not using DT?) and match that up with some driver data if
> > it needs to know how to understand the bits it can read with the
> > eeprom_read() API.
> 
> I'm half convinced that the layout information will actually work for
> more complex cases, like the linked list Rob described.
> 
> If such a structure is ever to be found, it would feel wrong to have
> that in the EEPROM driver, but it would feel just as wrong to put that
> in the client driver, that would have to handle the parsing of raw
> data coming flashed by one single crazy board vendor.
> 
> Maybe we can have each cell carry a property that defines the format
> it's stored in, and match that to some parsers plugins, starting with
> the generic and trivial cases but still allowing for custom parsers to
> be defined?
> 
> Something like
> 
> eeprom@42 {
>   compatible = "atmel,at24something";
>   reg = <0x42>;
> 
>   serial@0 {
>   label = "board serial";
>   reg = <0x0 0x10>;
>   format = "packed";
>   };
> 
>   opps@10 {
>

Re: [PATCH] mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes

[Bjorn Andersson]

On Wed 18 Feb 18:29 PST 2015, Stephen Boyd wrote:

> On 02/18/15 13:08, Bjorn Andersson wrote:
> > On Wed, Feb 18, 2015 at 12:28 PM, Stephen Boyd  wrote:

After taking a deeper look at this I've come to the following
conclusion:

We can save 2100 bytes of data by spreading out the magic numbers from
the rpm resource tables into the regulator, clock and bus drivers. At
the cost of having this rpm-specific information spread out.

Separate of that we could rewrite the entire regulator implementation to
define all regulators in platform specific tables in the regulators.
This would save about 12-15k of ram.

This can however be done in two ways:
1) We modify the mfd driver to instatiate 3 mfd_cells; one of them
being "qcom,rpm-regulators". We modify the regulator driver to have
tables of the regulators for each platform and matching regulator
parameters by of_node name and registering these.

2) We stick with this binding, we then go ahead and do the same
modification to the mfd as above - passing the rpm of_node to the
regulator driver, that walks the children and match that to the current
compatible list. (in other words, we replace of_platform_populate with
our own mechamism).


The benefit of 2 is that we can use the code that was posted 10 months
ago and merged 3 months ago until someone prioritize those 12kb.


To take either of these paths the issue at the bottom has to be
resolved first.


More answers follows inline:

> 
> We're already maintaining these tables in qcom-rpm.c. I'm advocating for
> removing those tables from the rpm driver and putting the data into the
> regulator driver. Then we don't have to index into a sparse table to
> figure out what values the RPM wants to use. Instead we have the data at
> hand for a particular regulator based on the of_regulator_match.
> 

I do like the "separation of concerns" between the rpm driver and the
children, but you're right in that we're wasting almost 3kb in doing so:

(gdb) p sizeof(apq8064_rpm_resource_table) + sizeof(msm8660_rpm_resource_table) 
+ sizeof(msm8960_rpm_resource_table)
$2 = 6384

vs

(gdb) p sizeof(struct qcom_rpm_resource) * (77 + 74 + 73)
$3 = 3584

The alternative would be to spread those magic constants out in the
three client drivers.

Looking at this from a software design perspective I stand by the
argument that the register layout of the rpm is not a regulator driver
implementation detail and is better kept separate.

As we decided to define the regulators in code but the actual
composition in dt it was not possible to put the individual numbers in
DT. Having reg = <165 68 48> does not make any sense, unless we perhaps
maintain said table in the dt binding documentation.

> I don't understand the maintenance argument either. The data has to go
> somewhere so the maintenance is always there.
> 

Well, you used exactly that argument when you questioned the way I did
pinctrl-msm, with a table per platform.

> From what I can tell, that data is split in two places. The regulator
> type knows how big the data we want to send is (1 or 2) and that is
> checked in the RPM driver to make sure that the two agree (this part
> looks like over-defensive coding).

Yeah, after debugging production code for years I like to be slightly on
the defensive side. But the size could of course be dropped from the
resource-tables; reducing the savings of your suggestion by another 800
bytes...

> Then the DT has a made up number that
> maps to 3 different numbers in the RPM driver.

Reading the following snippet in my dts file makes imidiate sense:

reg = 

the following doesn't make any sense:

reg = <116 31 30>;

Maybe it's write-once in a dts so it doesn't matter that much - as long
as the node is descriptive. But I like the properties to be human
understandable.

> The same could be done
> for b-family, where we have two numbers that just so happen to be user
> friendly enough to make sense on their own. Instead of being 165, 68,
> and 48, they're a #define SMPS and 1. We could make a #define SMPS1 and
> map it to a tuple with #define SMPS and 1. It looks like that was how
> you had b-family prototyped at one point.
> 

In family B things are completely different. The reason why I proposed
the similar setup was simply because I wanted to keep the api similar
(or even the same). But the mechanism is completely different;

The regulator driver builds up a key-value-pair list and encapsulte this
in a packet with a header that includes 'type' and 'id' of the resource
to be modified. This is then put in the packet-channel (smd) that goes
to the rpm.

The types are magic numbers but the id correlates to the resource id of
that type - so it doesn't give anything to maintain any tables for
family B.

Family A and B are so different that it doesn't make sense to share any
code, it was however my indention to have the dt bindings follow the
same structure!

> >
> > So for family B, where this is not necessary for the rpm driver, I
> > have revised this to

[PATCH 2/2] ARM: dts: qcom: add stdout-path to AP148

[Mathieu Olivari]

AP148 default console output is uart4, so this change adds a serial0
alias to it, as well add the corresponding stdout-path.

This will avoid having to set these as chosen.

Signed-off-by: Mathieu Olivari 
---
 arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts 
b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
index 55b2910..208bb79 100644
--- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
+++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
@@ -14,6 +14,14 @@
};
};
 
+   alias {
+   serial0 = &uart4;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
soc {
pinmux@80 {
i2c4_pins: i2c4_pinmux {
-- 
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 1/2] ARM: dts: qcom: label all gsbi devices

[Mathieu Olivari]

All IPQ806x based boards will include this file and will need a way to
identify each GSBI device. So this change is labelling them all to make
reference from board specific file easier.

Signed-off-by: Mathieu Olivari 
---
 arch/arm/boot/dts/qcom-ipq8064.dtsi | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index d01f618..ffa5b5e 100644
--- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
@@ -140,7 +140,7 @@
ranges;
status = "disabled";
 
-   serial@1249 {
+   uart2: serial@1249 {
compatible = "qcom,msm-uartdm-v1.3", 
"qcom,msm-uartdm";
reg = <0x1249 0x1000>,
  <0x1248 0x1000>;
@@ -150,7 +150,7 @@
status = "disabled";
};
 
-   i2c@124a {
+   i2c2: i2c@124a {
compatible = "qcom,i2c-qup-v1.1.1";
reg = <0x124a 0x1000>;
interrupts = <0 196 0>;
@@ -175,7 +175,7 @@
ranges;
status = "disabled";
 
-   serial@1634 {
+   uart4: serial@1634 {
compatible = "qcom,msm-uartdm-v1.3", 
"qcom,msm-uartdm";
reg = <0x1634 0x1000>,
  <0x1630 0x1000>;
@@ -185,7 +185,7 @@
status = "disabled";
};
 
-   i2c@1638 {
+   i2c4: i2c@1638 {
compatible = "qcom,i2c-qup-v1.1.1";
reg = <0x1638 0x1000>;
interrupts = <0 153 0>;
@@ -209,7 +209,7 @@
ranges;
status = "disabled";
 
-   serial@1a24 {
+   uart5: serial@1a24 {
compatible = "qcom,msm-uartdm-v1.3", 
"qcom,msm-uartdm";
reg = <0x1a24 0x1000>,
  <0x1a20 0x1000>;
@@ -219,7 +219,7 @@
status = "disabled";
};
 
-   i2c@1a28 {
+   i2c5: i2c@1a28 {
compatible = "qcom,i2c-qup-v1.1.1";
reg = <0x1a28 0x1000>;
interrupts = <0 155 0>;
@@ -232,7 +232,7 @@
#size-cells = <0>;
};
 
-   spi@1a28 {
+   spi5: spi@1a28 {
compatible = "qcom,spi-qup-v1.1.1";
reg = <0x1a28 0x1000>;
interrupts = <0 155 0>;
-- 
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 1/2] Input: touchscreen-iproc: Add Broadcom iProc touchscreen driver

[Dmitry Torokhov]

Hi Jonathan,

On Fri, Dec 19, 2014 at 02:17:49PM -0800, Jonathan Richardson wrote:
> Add initial version of the Broadcom touchscreen driver.
> 
> Reviewed-by: Ray Jui 
> Reviewed-by: Scott Branden 
> Tested-by: Scott Branden 
> Signed-off-by: Jonathan Richardson 
> ---
>  drivers/input/touchscreen/Kconfig |   11 +
>  drivers/input/touchscreen/Makefile|1 +
>  drivers/input/touchscreen/bcm_iproc_tsc.c |  535 
> +
>  3 files changed, 547 insertions(+)
>  create mode 100644 drivers/input/touchscreen/bcm_iproc_tsc.c
> 
> diff --git a/drivers/input/touchscreen/Kconfig 
> b/drivers/input/touchscreen/Kconfig
> index e1d8003..77ff531 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -310,6 +310,17 @@ config TOUCHSCREEN_ILI210X
> To compile this driver as a module, choose M here: the
> module will be called ili210x.
>  
> +config TOUCHSCREEN_IPROC
> + tristate "IPROC touch panel driver support"
> + help
> +   Say Y here if you want to add support for the IPROC touch
> +   controller to your system.
> +
> +   If unsure, say N.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called iproc-ts.
> +
>  config TOUCHSCREEN_S3C2410
>   tristate "Samsung S3C2410/generic touchscreen input driver"
>   depends on ARCH_S3C24XX || SAMSUNG_DEV_TS
> diff --git a/drivers/input/touchscreen/Makefile 
> b/drivers/input/touchscreen/Makefile
> index 090e61c..f7e6de9 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -37,6 +37,7 @@ obj-$(CONFIG_TOUCHSCREEN_FUJITSU)   += fujitsu_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_ILI210X)+= ili210x.o
>  obj-$(CONFIG_TOUCHSCREEN_INEXIO) += inexio.o
>  obj-$(CONFIG_TOUCHSCREEN_INTEL_MID)  += intel-mid-touch.o
> +obj-$(CONFIG_TOUCHSCREEN_IPROC)  += bcm_iproc_tsc.o
>  obj-$(CONFIG_TOUCHSCREEN_LPC32XX)+= lpc32xx_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_MAX11801)   += max11801_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_MC13783)+= mc13783_ts.o
> diff --git a/drivers/input/touchscreen/bcm_iproc_tsc.c 
> b/drivers/input/touchscreen/bcm_iproc_tsc.c
> new file mode 100644
> index 000..bf6eb7f
> --- /dev/null
> +++ b/drivers/input/touchscreen/bcm_iproc_tsc.c
> @@ -0,0 +1,535 @@
> +/*
> +* Copyright (C) 2014 Broadcom Corporation
> +*
> +* This program is free software; you can redistribute it and/or
> +* modify it under the terms of the GNU General Public License as
> +* published by the Free Software Foundation version 2.
> +*
> +* This program is distributed "as is" WITHOUT ANY WARRANTY of any
> +* kind, whether express or implied; without even the implied warranty
> +* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +* GNU General Public License for more details.
> +*/
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define IPROC_TS_NAME "iproc-ts"
> +
> +#define PEN_DOWN_STATUS 1
> +#define PEN_UP_STATUS   0
> +
> +#define X_MIN   0
> +#define Y_MIN   0
> +#define X_MAX   0xFFF
> +#define Y_MAX   0xFFF
> +
> +/* Value given by controller for invalid coordinate. */
> +#define INVALID_COORD   0x
> +
> +/* Register offsets */
> +#define REGCTL1 0x00
> +#define REGCTL2 0x04
> +#define INTERRUPT_THRES 0x08
> +#define INTERRUPT_MASK  0x0c
> +
> +#define INTERRUPT_STATUS0x10
> +#define CONTROLLER_STATUS   0x14
> +#define FIFO_DATA   0x18
> +#define FIFO_DATA_X_Y_MASK  0x
> +#define ANALOG_CONTROL  0x1c
> +
> +#define AUX_DATA0x20
> +#define DEBOUNCE_CNTR_STAT  0x24
> +#define SCAN_CNTR_STAT  0x28
> +#define REM_CNTR_STAT   0x2c
> +
> +#define SETTLING_TIMER_STAT 0x30
> +#define SPARE_REG   0x34
> +#define SOFT_BYPASS_CONTROL 0x38
> +#define SOFT_BYPASS_DATA0x3c
> +
> +
> +/* Bit values for INTERRUPT_MASK and INTERRUPT_STATUS regs */
> +#define TS_PEN_INTR_MASKBIT(0)
> +#define TS_FIFO_INTR_MASK   BIT(2)
> +
> +/* Bit values for CONTROLLER_STATUS reg1 */
> +#define TS_PEN_DOWN BIT(0)
> +
> +/* Shift values for control reg1 */
> +#define SCANNING_PERIOD_SHIFT   24
> +#define DEBOUNCE_TIMEOUT_SHIFT  16
> +#define SETTLING_TIMEOUT_SHIFT  8
> +#define TOUCH_TIMEOUT_SHIFT 0
> +
> +/* Shift values for coordinates from fifo */
> +#define X_COORD_SHIFT  0
> +#define Y_COORD_SHIFT  16
> +
> +/* Bit values for REGCTL2 */
> +#define TS_CONTROLLER_EN_BITBIT(16)
> +#define TS_CONTROLLER_AVGDATA_SHIFT 8
> +#define TS_CONTROLLER_AVGDATA_MASK (0x7 << TS_CONTROLLER_AVGDATA_SHIFT)
> +#define TS_CONTROLLER_PWR_LDO   BIT(5)
> +#define TS_CONTROLLER_PWR_ADC   BIT(4)
> +#define TS_CONTROLLER_PWR_BGP   BIT(3)
> +#define TS_CONTROLLER_PWR_TSBIT(2)
> +#define TS_WIRE_MODE_BIT   

Re: [PATCH v2 1/2] Input: touchscreen-iproc: Add Broadcom iProc touchscreen driver

[Dmitry Torokhov]

Jonathan,


On Wed, Feb 11, 2015 at 10:45:34AM -0800, Jonathan Richardson wrote:
> Pinging maintainers... Am I ok to go ahead with the current rotation
> implementation? I haven't heard anything further. Any feedback on naming
> conventions from DT people?
>

I believe we should go with touchscreen-inverted-x,
touchscreen-inverted-y and touchscreen-swapped-x-y properties since
rotation can't really describe all permutations of potential
connections.

I'll be taking Hans de Goede's patch adding this new property to the
bindings (adjusting the name slightly).

Thanks.

> Thanks!
> 
> On 15-01-15 11:51 AM, Jonathan Richardson wrote:
> > Hi Dmitry,
> > 
> > On 15-01-14 10:07 PM, Dmitry Torokhov wrote:
> >> On Wed, Jan 14, 2015 at 09:44:39PM -0800, Scott Branden wrote:
> >>> On 15-01-14 05:02 PM, Dmitry Torokhov wrote:
>  Hi Jonathan,
> 
>  On Fri, Dec 19, 2014 at 02:17:49PM -0800, Jonathan Richardson wrote:
> > +   if (of_property_read_u32(np, "scanning_period", &val) >= 0) {
> > +   if (val < 1 || val > 256) {
> > +   dev_err(dev, "scanning_period must be 
> > [1-256]\n");
> > +   return -EINVAL;
> > +   }
> > +   priv->cfg_params.scanning_period = val;
> > +   }
> > +
> > +   if (of_property_read_u32(np, "debounce_timeout", &val) >= 0) {
> > +   if (val < 0 || val > 255) {
> > +   dev_err(dev, "debounce_timeout must be 
> > [0-255]\n");
> > +   return -EINVAL;
> > +   }
> > +   priv->cfg_params.debounce_timeout = val;
> > +   }
> > +
> > +   if (of_property_read_u32(np, "settling_timeout", &val) >= 0) {
> > +   if (val < 0 || val > 11) {
> > +   dev_err(dev, "settling_timeout must be 
> > [0-11]\n");
> > +   return -EINVAL;
> > +   }
> > +   priv->cfg_params.settling_timeout = val;
> > +   }
> > +
> > +   if (of_property_read_u32(np, "touch_timeout", &val) >= 0) {
> > +   if (val < 0 || val > 255) {
> > +   dev_err(dev, "touch_timeout must be [0-255]\n");
> > +   return -EINVAL;
> > +   }
> > +   priv->cfg_params.touch_timeout = val;
> > +   }
> > +
> > +   if (of_property_read_u32(np, "average_data", &val) >= 0) {
> > +   if (val < 0 || val > 8) {
> > +   dev_err(dev, "average_data must be [0-8]\n");
> > +   return -EINVAL;
> > +   }
> > +   priv->cfg_params.average_data = val;
> > +   }
> > +
> > +   if (of_property_read_u32(np, "fifo_threshold", &val) >= 0) {
> > +   if (val < 0 || val > 31) {
> > +   dev_err(dev, "fifo_threshold must be [0-31]\n");
> > +   return -EINVAL;
> > +   }
> > +   priv->cfg_params.fifo_threshold = val;
> > +   }
> 
>  I think these are dveice specific and thus should have "brcm," prefix.
> >>> I'm confused as to why we need the brcm prefix?  Other device tree
> >>> bindings we have for other drivers do not need such prefix.
> >>
> >> Properties that are not standard on the system (reg, interrupts,
> >> clkocks, etc) or subsystem level customarily carry the vendor prefix so
> >> that they do not clash with newly added global or subsystem properties.
> >>
> >>>  Is this
> >>> convention documented somewhere?
> >>
> >> Not sure. I glanced through Documentation/devicetree and do not see it
> >> spelled out. Device tree overlords, what say you?
> > 
> > Let me know. I haven't seen this before either. I will change the
> > entries to use dashes though instead of underscores but will wait until
> > these other issues are decided on before sending out another patch.
> > 
> >>
> 
> > +
> > +   priv->ts_rotation = TS_ROTATION_0;
> > +   if (of_property_read_u32(np, "ts-rotation", &val) >= 0) {
> > +   priv->ts_rotation = val;
> > +   dev_dbg(dev, "ts rotation [%d] degrees\n",
> > +   90 * priv->ts_rotation);
> > +   }
> 
>  This I am not quite sure about - if we want rotation or swap+invert. You
>  are CCed on another email (tsc2007) that talks about need of generic
>  touchscreen transforms in input core/of bindings.
> >>> Does such generic binding exist today?  If not, I would like to go
> >>> with this implementation and update to the new binding if/when it
> >>> exists?
> >>
> >> Not yet but there several people interested. I think we have enough time
> >> till 3.20 to hash it out properly.
> > 
> > I think the rotation is simpler personally. Everyone would understand
> > 

Re: [PATCH] mfd: arizona: Move useful defines into a dt-binding include

[Charles Keepax]

On Mon, Feb 23, 2015 at 10:00:50AM -0600, Rob Herring wrote:
> On Wed, Feb 18, 2015 at 5:03 AM, Charles Keepax
>  wrote:
> > Move parts of linux/mfd/arizona/pdata.h and gpio.h into a new file in
> > the dt-binding directory for use by device tree bindings. This also
> > makes gpio.h redundant so remove it in the process.
> >
> > Signed-off-by: Charles Keepax 
> > ---
> >  include/dt-bindings/mfd/arizona.h |  109 
> > +
> >  include/linux/mfd/arizona/gpio.h  |   96 
> >  include/linux/mfd/arizona/pdata.h |   46 +---
> >  sound/soc/codecs/arizona.c|1 -
> >  4 files changed, 110 insertions(+), 142 deletions(-)
> >  create mode 100644 include/dt-bindings/mfd/arizona.h
> >  delete mode 100644 include/linux/mfd/arizona/gpio.h
> >
> > diff --git a/include/dt-bindings/mfd/arizona.h 
> > b/include/dt-bindings/mfd/arizona.h
> > new file mode 100644
> > index 000..f2a4821
> > --- /dev/null
> > +++ b/include/dt-bindings/mfd/arizona.h
> > @@ -0,0 +1,109 @@
> > +/*
> > + * Device Tree defines for Arizona devices
> > + *
> > + * Copyright 2014 Wolfson Microelectronics. PLC.
> > + *
> > + * Author: Charles Keepax 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#ifndef _DT_BINDINGS_MFD_ARIZONA_H
> > +#define _DT_BINDINGS_MFD_ARIZONA_H
> > +
> > +#define ARIZONA_GP_FN_TXLRCLK0x00
> > +#define ARIZONA_GP_FN_GPIO   0x01
> 
> These are all register offsets? If so, I don't think they belong in dts files.

These are the various functions that the chips GPIO pins can be
set to. They are values rather than register offsets.

> 
> > +#define ARIZONA_GP_FN_IRQ1   0x02
> > +#define ARIZONA_GP_FN_IRQ2   0x03
> > +#define ARIZONA_GP_FN_ASYNC_OPCLK0x3D
> > +#define ARIZONA_GP_FN_BOOT_DONE  0x44
> > +#define ARIZONA_GP_FN_DSP1_RAM_READY 0x45
> > +#define ARIZONA_GP_FN_SYSCLK_ENA_STATUS  0x4B
> > +#define ARIZONA_GP_FN_ASYNCCLK_ENA_STATUS0x4C
> > +
> > +#define ARIZONA_GPN_DIR  0x8000  /* GPN_DIR */
> > +#define ARIZONA_GPN_DIR_MASK 0x8000  /* GPN_DIR */
> > +#define ARIZONA_GPN_DIR_SHIFT15  /* GPN_DIR */
> > +#define ARIZONA_GPN_DIR_WIDTH 1  /* GPN_DIR */
> 
> Similarly, how do you intend to use these in dts files?
> 
> Rob

Admittedly, the shift and width defines are unlikely to see use
in the DT file, I will do a respin to filter those out.

The defines themselves are settings for the GPIO pins again.
Direction, pull up, pull down. These all go into the
wlf,gpio-defaults field in the DT binding.

So instead of:

wlf,gpio-defaults = <
0x /* AIF1TXLRCLK */
0x
0x
0x
0x
>;

We can write something a little more readable like:

wlf,gpio-defaults = <
ARIZONA_GP_FN_TXLRCLK
0x
0x
0x
0x
>;

Although looking at that example I feel like I should add a
define for the default value (triggered by an out of range value
such as 0x).

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] MIPS: Allow platforms to specify the decompressor load address

[Ralf Baechle]

On Tue, Feb 24, 2015 at 01:39:03PM -0800, Andrew Bresticker wrote:

> It is the same sort of issue, though I think the only way to solve it
> on MIPS would be to copy the image to the address it was linked at,
> which could be problematic if there's overlap.  There's also the cache
> maintenance we'd have to do, which varies from CPU to CPU (and more so
> the ARM I believe).

On MIPS it's significantly less complex to implement than the in-kernel
cache maintenance code because only one flush operation needs to be
implemented that will be invoked only once so performance is less of
an issue.  Also oddball hardware such as the S-caches controlled by
an external controller can be ignored for purpose of kernel decomporession.
That pretty much leaves to treat the standard R4000 style of caches
and a few oddballs like R2000 class processors.

  Ralf
--
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] spi: qup: Add DMA capabilities

[Andy Gross]

On Tue, Feb 24, 2015 at 06:08:54PM +0200, Stanimir Varbanov wrote:



> 
> yes, there is a potential race between atomic_inc and dma callback. I
> reordered these calls to save few checks, and now it returns to me.
> 
> I imagine few options here:
> 
>  - reorder the dmaengine calls and atomic operations, i.e.
> call atomic_inc for rx and tx channels before corresponding
> dmaengine_submit and dmaengine_issue_pending.
> 
>  - have two different dma callbacks and two completions and waiting for
> the two.

This is probably the better solution.  The only thing you'll have to take into
consideration is that you may not have a RX DMA transactions.

> 
>  - manage to receive only one dma callback, i.e. the last transfer in
> case of presence of the rx_buf and tx_buf at the same time.

You use separate channels for the RX and TX, so as long as you have separate
callbacks, it shouldnt be a problem.


-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] arm-cci: Split the code for PMU vs driver support

[Nicolas Pitre]

On Tue, 24 Feb 2015, Suzuki K. Poulose wrote:

> From: "Suzuki K. Poulose" 
> 
> This patch separates the PMU driver code from the low level
> CCI driver code, and enables the CCI400-PMU for ARM64.
> 
> Introduces config options for both.
> 
>  - ARM_CCI400_MCPM- controls the low level MCPM driver code for CCI
>  - ARM_CCI400_PMU - controls the PMU driver code
>  - ARM_CCI400_COMMON  - CCI400 specific details shared by MCPM
> and PMU
> Changes:
>  - ARM_CCI- common code for probing the CCI devices
> 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: Kukjin Kim 
> Cc: Abhilash Kesavan 
> Cc: Liviu Dudau 
> Cc: Lorenzo Pieralisi 
> Cc: Sudeep Holla 
> Signed-off-by: Suzuki K. Poulose 

Comments inline.

> ---
>  arch/arm/mach-exynos/Kconfig   |2 +-
>  arch/arm/mach-vexpress/Kconfig |4 ++--
>  drivers/bus/Kconfig|   28 +++-
>  drivers/bus/arm-cci.c  |   25 +
>  include/linux/arm-cci.h|7 ++-
>  5 files changed, 53 insertions(+), 13 deletions(-)
> 
> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
> index 603820e..9bc8b4d 100644
> --- a/arch/arm/mach-exynos/Kconfig
> +++ b/arch/arm/mach-exynos/Kconfig
> @@ -123,7 +123,7 @@ config SOC_EXYNOS5800
>  config EXYNOS5420_MCPM
>   bool "Exynos5420 Multi-Cluster PM support"
>   depends on MCPM && SOC_EXYNOS5420
> - select ARM_CCI
> + select ARM_CCI400_MCPM
>   select ARM_CPU_SUSPEND
>   help
> This is needed to provide CPU and cluster power management
> diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
> index d6b16d9..097912f 100644
> --- a/arch/arm/mach-vexpress/Kconfig
> +++ b/arch/arm/mach-vexpress/Kconfig
> @@ -53,7 +53,7 @@ config ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA
>  config ARCH_VEXPRESS_DCSCB
>   bool "Dual Cluster System Control Block (DCSCB) support"
>   depends on MCPM
> - select ARM_CCI
> + select ARM_CCI400_MCPM
>   help
> Support for the Dual Cluster System Configuration Block (DCSCB).
> This is needed to provide CPU and cluster power management
> @@ -71,7 +71,7 @@ config ARCH_VEXPRESS_SPC
>  config ARCH_VEXPRESS_TC2_PM
>   bool "Versatile Express TC2 power management"
>   depends on MCPM
> - select ARM_CCI
> + select ARM_CCI400_MCPM
>   select ARCH_VEXPRESS_SPC
>   help
> Support for CPU and cluster power management on Versatile Express
> diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
> index b99729e..91dd013 100644
> --- a/drivers/bus/Kconfig
> +++ b/drivers/bus/Kconfig
> @@ -43,12 +43,30 @@ config OMAP_INTERCONNECT
>   help
> Driver to enable OMAP interconnect error handling driver.
>  
> -config ARM_CCI
> - bool "ARM CCI driver support"
> - depends on ARM && OF && CPU_V7
> +config ARM_CCI400_MCPM
> + bool
> + depends on ARM && OF && CPU_V7 && MCPM

MCPM is not an actual dependency and therefore should probably not be 
added here.  You removed the prompt string therefore this will only be 
selectable explicitly as needed.

Also, shouldn't it select ARM_CCI400_COMMON ?

> + help
> +   Low level power management driver for CCI400 cache coherent
> +   interconnect for ARM platforms.
> +
> +config ARM_CCI400_PMU
> + bool "ARM CCI400 PMU support"
> + depends on ARM || ARM64
> + depends on HW_PERF_EVENTS
> + select ARM_CCI400_COMMON
>   help
> -   Driver supporting the CCI cache coherent interconnect for ARM
> -   platforms.
> +   Support for PMU events monitoring on the ARM CCI cache coherent
> +   interconnect.
> +
> +   If unsure, say N
> +
> +config ARM_CCI400_COMMON
> + bool
> + select ARM_CCI
> +
> +config ARM_CCI
> + bool

Surely you could do with only one of ARM_CCI or ARM_CCI400_COMMON?  
Personally I'd go with the later as it is more precise.

>  config ARM_CCN
>   bool "ARM CCN driver support"
> diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
> index fe9fa46..7e330fe 100644
> --- a/drivers/bus/arm-cci.c
> +++ b/drivers/bus/arm-cci.c
> @@ -32,6 +32,7 @@
>  static void __iomem *cci_ctrl_base;
>  static unsigned long cci_ctrl_phys;
>  
> +#ifdef CONFIG_ARM_CCI400_MCPM
>  struct cci_nb_ports {
>   unsigned int nb_ace;
>   unsigned int nb_ace_lite;
> @@ -42,12 +43,19 @@ static const struct cci_nb_ports cci400_ports = {
>   .nb_ace_lite = 3
>  };
>  
> +#define CCI400_MCPM_PORTS_DATA   (&cci400_ports)

I'm a bit uneasy with the conflation of MCPM in here.  Sure (most) MCPM 
backends are the only users of this code, but that doesn't mean MCPM has 
to have exclusive access.  Having "MCPM" entranched into the code and 
config symbols like that is misrepresenting this code somewhat.

> +#else
> +#define CCI400_MCPM_PORTS_DATA   (NULL)
> +#endif
> +
>  static const struct of_device_id arm_cci_matches[] = {
> - {.compatible = "arm,cci-400", .data = &cc

Re: [PATCH 2/4] arm-cci: Get rid of secure transactions for PMU driver

[Nicolas Pitre]

On Tue, 24 Feb 2015, Suzuki K. Poulose wrote:

> From: "Suzuki K. Poulose" 
> 
> Avoid secure transactions while probing the CCI PMU. The
> existing code makes use of the Peripheral ID2 (PID2) register
> to determine the revision of the CCI400, which requires a
> secure transaction. This puts a limitation on the usage of the
> driver on systems running non-secure Linux(e.g, ARM64).
> 
> Updated the device-tree binding for cci pmu node to add the explicit
> revision number for the compatible field.
> 
> The supported strings are :
>   arm,cci-400-pmu,r0
>   arm,cci-400-pmu,r1
>   arm,cci-400-pmu - DEPRECATED. See NOTE below
> 
> NOTE: If the revision is not mentioned, we need to probe the cci revision,
> which could be fatal on a platform running non-secure. We need a reliable way
> to know if we can poke the CCI registers at runtime on ARM32. We depend on
> 'mcpm_is_available()' when it is available. mcpm_is_available() returns true
> only when there is a registered driver for mcpm. Otherwise, we assume that we
> don't have secure access, and skips probing the revision number(ARM64 case).
> 
> The MCPM should figure out if it is safe to access the CCI. Unfortunately
> there isn't a reliable way to indicate the same via dtb. This patch doesn't
> address/change the current situation. It only deals with the CCI-PMU, leaving
> the assumptions about the secure access as it has been, prior to this patch.

This is an extensive commit log about secure access issues which is nice 
and appreciated.  However the patch does quite some more code reorg not 
mentioned here.  Could you please move this code reorg to a separate 
patch and then have a patch on top introducing these probing changes?  
This should make the implication of what is said above clearer.

> Cc: devicetree@vger.kernel.org
> Cc: Punit Agrawal 
> Signed-off-by: Suzuki K. Poulose 
> ---
>  Documentation/devicetree/bindings/arm/cci.txt |7 +-
>  arch/arm/include/asm/arm-cci.h|   42 
>  arch/arm64/include/asm/arm-cci.h  |   27 +
>  drivers/bus/arm-cci.c |  138 
> -
>  include/linux/arm-cci.h   |2 +
>  5 files changed, 166 insertions(+), 50 deletions(-)
>  create mode 100644 arch/arm/include/asm/arm-cci.h
>  create mode 100644 arch/arm64/include/asm/arm-cci.h
> 
> diff --git a/Documentation/devicetree/bindings/arm/cci.txt 
> b/Documentation/devicetree/bindings/arm/cci.txt
> index f28d82b..0e4b6a7 100644
> --- a/Documentation/devicetree/bindings/arm/cci.txt
> +++ b/Documentation/devicetree/bindings/arm/cci.txt
> @@ -94,8 +94,11 @@ specific to ARM.
>   - compatible
>   Usage: required
>   Value type: 
> - Definition: must be "arm,cci-400-pmu"
> -
> + Definition: Supported strings are :
> +  "arm,cci-400-pmu,r0"
> +  "arm,cci-400-pmu,r1"
> +  "arm,cci-400-pmu"  - DEPRECATED, permitted 
> only where OS has
> +   secure acces to CCI 
> registers
>   - reg:
>   Usage: required
>   Value type: Integer cells. A register entry, expressed
> diff --git a/arch/arm/include/asm/arm-cci.h b/arch/arm/include/asm/arm-cci.h
> new file mode 100644
> index 000..b828d7a
> --- /dev/null
> +++ b/arch/arm/include/asm/arm-cci.h
> @@ -0,0 +1,42 @@
> +/*
> + * arch/arm/include/asm/arm-cci.h
> + *
> + * Copyright (C) 2015 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#ifndef __ASM_ARM_CCI_H
> +#define __ASM_ARM_CCI_H
> +
> +#ifdef CONFIG_MCPM
> +#include 
> +
> +/*
> + * We don't have a reliable way of detecting, whether
> + * we have access to secure-only registers, unless
> + * mcpm is registered.
> + */
> +static inline int platform_has_secure_cci_access(void)
> +{
> + return mcpm_is_available();
> +}
> +
> +#else
> +static inline int platform_has_secure_cci_access(void)
> +{
> + return 0;
> +}
> +#endif
> +
> +#endif
> diff --git a/arch/arm64/include/asm/arm-cci.h 
> b/arch/arm64/include/asm/arm-cci.h
> new file mode 100644
> index 000..37bbe37
> --- /dev/null
> +++ b/arch/arm64/include/asm/arm-cci.h
> @@ -0,0 +1,27 @@
> +/*
> + * arch/arm64/include/asm/arm-cci.h
> + *
> + * Copyrig

Re: [PATCH 2/5] MIPS: Allow platforms to specify the decompressor load address

[Andrew Bresticker]

On Tue, Feb 24, 2015 at 12:15 AM, Arnd Bergmann  wrote:
> On Monday 23 February 2015 17:31:44 Andrew Bresticker wrote:
>> Platforms which use raw zboot images may need to link the image at
>> a fixed address if there is no other way to communicate the load
>> address to the bootloader.  Allow the per-platform Kbuild files
>> to specify an optional zboot image load address (zload-y) and fall
>> back to calc_vmlinuz_load_addr if unset.
>>
>> Signed-off-by: Andrew Bresticker 
>> Cc: Lars-Peter Clausen 
>
> No objections to the patch, but have you considered doing the
> same thing as ARM's AUTO_ZRELADDR, where we calculate the
> address at runtime from the entry point?
>
> I assume this is the same kind of address you are talking
> about here; if not, nevermind.

It is the same sort of issue, though I think the only way to solve it
on MIPS would be to copy the image to the address it was linked at,
which could be problematic if there's overlap.  There's also the cache
maintenance we'd have to do, which varies from CPU to CPU (and more so
the ARM I believe).
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] pinctrl: tegra: add a driver for Tegra210

[Stephen Warren]

From: Stephen Warren 

Tegra210's pinmux supports a different set of pins/options than earlier
SoCs, so requires its own driver (well, table of pin-specific data).

Cc: devicetree@vger.kernel.org
Signed-off-by: Stephen Warren 
---
 .../bindings/pinctrl/nvidia,tegra210-pinmux.txt|  166 ++
 drivers/pinctrl/Kconfig|4 +
 drivers/pinctrl/Makefile   |1 +
 drivers/pinctrl/pinctrl-tegra210.c | 1588 
 4 files changed, 1759 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.txt
 create mode 100644 drivers/pinctrl/pinctrl-tegra210.c

diff --git 
a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.txt 
b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.txt
new file mode 100644
index ..a62d82d5fbe9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra210-pinmux.txt
@@ -0,0 +1,166 @@
+NVIDIA Tegra210 pinmux controller
+
+Required properties:
+- compatible: "nvidia,tegra210-pinmux"
+- reg: Should contain a list of base address and size pairs for:
+  - first entry: The APB_MISC_GP_*_PADCTRL registers (pad control)
+  - second entry: The PINMUX_AUX_* registers (pinmux)
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+Tegra's pin configuration nodes act as a container for an arbitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, tristate, drive strength, etc.
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Each subnode only affects those parameters that are explicitly listed. In
+other words, a subnode that lists a mux function but no pin configuration
+parameters implies no information about any pin configuration parameters.
+Similarly, a pin subnode that describes a pullup parameter implies no
+information about e.g. the mux function or tristate parameter. For this
+reason, even seemingly boolean values are actually tristates in this binding:
+unspecified, off, or on. Unspecified is represented as an absent property,
+and off/on are represented as integer values 0 and 1.
+
+See the TRM to determine which properties and values apply to each pin/group.
+Macro values for property values are defined in
+include/dt-binding/pinctrl/pinctrl-tegra.h.
+
+Required subnode-properties:
+- nvidia,pins : An array of strings. Each string contains the name of a pin or
+group. Valid values for these names are listed below.
+
+Optional subnode-properties:
+- nvidia,function: A string containing the name of the function to mux to the
+pin or group.
+- nvidia,pull: Integer, representing the pull-down/up to apply to the pin.
+0: none, 1: down, 2: up.
+- nvidia,tristate: Integer.
+0: drive, 1: tristate.
+- nvidia,enable-input: Integer. Enable the pin's input path.
+enable :TEGRA_PIN_ENABLE0 and
+disable or output only: TEGRA_PIN_DISABLE.
+- nvidia,open-drain: Integer.
+enable: TEGRA_PIN_ENABLE.
+disable: TEGRA_PIN_DISABLE.
+- nvidia,lock: Integer. Lock the pin configuration against further changes
+until reset.
+enable: TEGRA_PIN_ENABLE.
+disable: TEGRA_PIN_DISABLE.
+- nvidia,io-hv: Integer. Select high-voltage receivers.
+normal: TEGRA_PIN_DISABLE
+high: TEGRA_PIN_ENABLE
+- nvidia,high-speed-mode: Integer. Enable high speed mode the pins.
+normal: TEGRA_PIN_DISABLE
+high: TEGRA_PIN_ENABLE
+- nvidia,schmitt: Integer. Enables Schmitt Trigger on the input.
+normal: TEGRA_PIN_DISABLE
+high: TEGRA_PIN_ENABLE
+- nvidia,drive-type: Integer. Valid range 0...3.
+- nvidia,pull-down-strength: Integer. Controls drive strength. 0 is weakest.
+The range of valid values depends on the pingroup. See "CAL_DRVDN" in the
+Tegra TRM.
+- nvidia,pull-up-strength: Integer. Controls drive strength. 0 is weakest.
+The range of valid values depends on the pingroup. See "CAL_DRVUP" in the
+Tegra TRM.
+- nvidia,slew-rate-rising: Integer. Controls rising signal slew rate. 0 is
+fastest. The range of valid values depends on the pingroup. See
+"DRVDN_SLWR" in the Tegra TRM.
+- nvidia,slew-rate-falling: Integer. Controls falling signal slew rate. 0 is
+fastest. The range of valid values depends on the pingroup. See
+"DRVUP_SLWF" in the Tegra TRM.
+
+Valid values for pin and group names (nvidia,pin) are:
+
+  Mux groups:
+
+These correspond to Tegra PINMUX_AUX_* (pinmux) registers. Any property
+that exists in those registers may be set for the following pin names.
+
+In Tegra210, many pins also have a dedica

Re: [PATCH V2] (gpio-fan): Add thermal control hooks

[Nishanth Menon]

On Tue, Feb 24, 2015 at 1:55 PM, Guenter Roeck  wrote:
> On Tue, Feb 24, 2015 at 03:29:35PM -0400, Eduardo Valentin wrote:
>> Guenter,
>>
>> On Thu, Jan 08, 2015 at 08:48:40PM -0800, Guenter Roeck wrote:
>> > On 01/08/2015 10:05 AM, Nishanth Menon wrote:
>> > > Allow gpio-fan to be used as thermal cooling device for platforms that
>> > > use GPIO maps to control fans.
>> > >
>> > > As part of this change, we make the shutdown and remove logic the same
>> > > as well.
>> > >
>> > > Signed-off-by: Nishanth Menon 
>> > > ---
>> >
>> > Applied to -next.
>>
>> What is the target kernel version for this change? It didn't make
>> 4.0-rc1
>>
> If I recall correctly, I had to pull it because the thermal framework
> does not provide hooks if disabled. Weird, I am sure I sent an e-mail
> about this, but I don't find it right now.
>
> It can't make it in before the hooks are in place, or we'll need
> another version with ifdefs around the thermal registration code.

I had posted the required hooks.
https://patchwork.kernel.org/patch/5828261/ -> I think Eduardo picked
this one up.. So once it hits mainline, we should ideally be clear.

-- 
---
Regards,
Nishanth Menon
--
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] (gpio-fan): Add thermal control hooks

[Eduardo Valentin]

On Tue, Feb 24, 2015 at 11:55:23AM -0800, Guenter Roeck wrote:
> On Tue, Feb 24, 2015 at 03:29:35PM -0400, Eduardo Valentin wrote:
> > Guenter,
> > 
> > On Thu, Jan 08, 2015 at 08:48:40PM -0800, Guenter Roeck wrote:
> > > On 01/08/2015 10:05 AM, Nishanth Menon wrote:
> > > > Allow gpio-fan to be used as thermal cooling device for platforms that
> > > > use GPIO maps to control fans.
> > > >
> > > > As part of this change, we make the shutdown and remove logic the same
> > > > as well.
> > > >
> > > > Signed-off-by: Nishanth Menon 
> > > > ---
> > > 
> > > Applied to -next.
> > 
> > What is the target kernel version for this change? It didn't make
> > 4.0-rc1
> > 
> If I recall correctly, I had to pull it because the thermal framework
> does not provide hooks if disabled. Weird, I am sure I sent an e-mail
> about this, but I don't find it right now.
> 
> It can't make it in before the hooks are in place, or we'll need
> another version with ifdefs around the thermal registration code.

Got it!

I applied the fix that Nishanth sent to thermal.h [1]. I am planing to
send it during 4.0 rc cycles.

Thanks for the clarification.

[1] -
https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=fixes&id=12ca7188468ee29c4e717f73db4bf43c90954fc7

> 
> Guenter

Eduardo Valentin


signature.asc
Description: Digital signature

Re: [PATCH] thermal: armada: read stable temp on Armada XP

[Tyler Hall]

Eduardo,

On Tue, Feb 24, 2015 at 1:36 PM, Eduardo Valentin  wrote:
> The fix seams reasonable. Although, it remains the question what is
> applicability to other Armada chips? Besides, shouldn't we simply use it
> by default? Also, do you plan to send updates in the DTS files?

As far as I can tell, Armada 370 is already using the equivalent of
this register I'd like to use in Armada XP. I'm not sure about the
other mvebu platforms. I couldn't just change the device tree for XP
to instantiate the 370 sensor, however, as they have different
initialization routines. Possibly Eziquiel can comment on the
significance of the differences between armadaxp_init_sensor() and
armada370_init_sensor().

I would like to change the default going forward, but I don't think it
can be changed on platforms using an older DTB.

I had planned to submit the dts change separately. It's not clear to
me how that's supposed to be handled if they might go through
different trees.

Thanks,
Tyler
--
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] (gpio-fan): Add thermal control hooks

[Guenter Roeck]

On Tue, Feb 24, 2015 at 03:29:35PM -0400, Eduardo Valentin wrote:
> Guenter,
> 
> On Thu, Jan 08, 2015 at 08:48:40PM -0800, Guenter Roeck wrote:
> > On 01/08/2015 10:05 AM, Nishanth Menon wrote:
> > > Allow gpio-fan to be used as thermal cooling device for platforms that
> > > use GPIO maps to control fans.
> > >
> > > As part of this change, we make the shutdown and remove logic the same
> > > as well.
> > >
> > > Signed-off-by: Nishanth Menon 
> > > ---
> > 
> > Applied to -next.
> 
> What is the target kernel version for this change? It didn't make
> 4.0-rc1
> 
If I recall correctly, I had to pull it because the thermal framework
does not provide hooks if disabled. Weird, I am sure I sent an e-mail
about this, but I don't find it right now.

It can't make it in before the hooks are in place, or we'll need
another version with ifdefs around the thermal registration code.

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 v4 5/8] ARM: dts: Add properties to use pwm-fan device as a cooling device in Odroid U3

[Eduardo Valentin]

On Wed, Feb 18, 2015 at 11:07:33AM +0100, Lukasz Majewski wrote:
> With those bindings it is possible to use pwm-fan device available in
> Odroid U3 as a cooling device.
> 
> Signed-off-by: Lukasz Majewski 
> ---
> Changes for v2:
> - Rename cooling-pwm-values property to cooling-levels
> Changes for v3:
> - Change patch's topic to "ARM dts"
> - Reduce maximal cooling-level to 230 from 255
> Changes for v4:
> - None
> ---
>  arch/arm/boot/dts/exynos4412-odroidu3.dts | 33 
> ++-
>  1 file changed, 32 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts 
> b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> index 60bd1e4..3e5df3e 100644
> --- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
> +++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
> @@ -32,11 +32,42 @@
>   };
>   };
>  
> - pwm-fan {
> + fan0: pwm-fan {
>   compatible = "pwm-fan";
>   pwms = <&pwm 0 1 0>;
> + cooling-min-state = <0>;
> + cooling-max-state = <3>;
> + #cooling-cells = <2>;
> + cooling-levels = <0 102 170 230>;
>   status = "okay";
>   };
> +
> + thermal-zones {
> + cpu_thermal: cpu-thermal {


This thermal zone misses the mandatory properties as per 
 Documentation/devicetree/bindings/thermal/thermal.txt

> + cooling-maps {
> + map0 {
> +  trip = <&cpu_alert1>;
> +  cooling-device = <&cpu0 7 7>;
> + };
> + map1 {
> +  trip = <&cpu_alert2>;
> +  cooling-device = <&cpu0 13 13>;
> + };
> + map2 {
> +  trip = <&cpu_alert0>;
> +  cooling-device = <&fan0 0 1>;
> + };
> + map3 {
> +  trip = <&cpu_alert1>;
> +  cooling-device = <&fan0 1 2>;
> + };
> + map4 {
> +  trip = <&cpu_alert2>;
> +  cooling-device = <&fan0 2 3>;
> + };
> + };
> + };
> + };
>  };
>  
>  &pwm {
> -- 
> 2.0.0.rc2
> 


signature.asc
Description: Digital signature

Re: [PATCH V2] (gpio-fan): Add thermal control hooks

[Eduardo Valentin]

Guenter,

On Thu, Jan 08, 2015 at 08:48:40PM -0800, Guenter Roeck wrote:
> On 01/08/2015 10:05 AM, Nishanth Menon wrote:
> > Allow gpio-fan to be used as thermal cooling device for platforms that
> > use GPIO maps to control fans.
> >
> > As part of this change, we make the shutdown and remove logic the same
> > as well.
> >
> > Signed-off-by: Nishanth Menon 
> > ---
> 
> Applied to -next.

What is the target kernel version for this change? It didn't make
4.0-rc1

BR,

Eduardo Valentin

> 
> Thanks,
> Guenter
> 


signature.asc
Description: Digital signature

Re: [PATCH v4 3/8] Documentation: dts: Documentation entry to explain how to use PWM FAN as a cooling device

[Eduardo Valentin]

On Wed, Feb 18, 2015 at 11:07:31AM +0100, Lukasz Majewski wrote:
> Explanation of several properties, which allow PWM fan working as a cooling
> device, have been embraced in this commit.
> 
> Signed-off-by: Lukasz Majewski 
> ---
> Changes for v2:
> - Rename cooling-pwm-values to cooling-levels
> - Remove default-pulse-width property and stick to default hwmon policy
> Changes for v3:
> - Changing commit title from "hwmon: dts: Doc:" to "Documentation: dts"
> - Remove unnecessary properties
> - Set maximal cooling level to 230 instead of 255
> Changes for v4:
> - None
> ---
>  Documentation/devicetree/bindings/hwmon/pwm-fan.txt | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt 
> b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
> index 610757c..d53fe0c 100644
> --- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
> +++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt
> @@ -3,10 +3,30 @@ Bindings for a fan connected to the PWM lines
>  Required properties:
>  - compatible : "pwm-fan"
>  - pwms   : the PWM that is used to control the PWM fan
> +- cooling-levels  : PWM duty cycle values in a range from 0 to 255
> + which correspond to thermal cooling states
> +
> +Thorough description of the following bindings:
> + cooling-min-state = <0>;
> + cooling-max-state = <3>;
> + #cooling-cells = <2>;
> + thermal-zone {
> + cpu_thermal: cpu-thermal {
> + cooling-maps {
> + map0 {
> +  trip = <&cpu_alert1>;
> +  cooling-device = <&fan0 0 1>;
> + };
> + };
> + };

I am fine if you leave the reference to thermal.txt biding description,
but I would prefer if you move the above lines to a proper example section.

> +
> +for PWM FAN used as cooling device can be found at:
> +./Documentation/devicetree/bindings/thermal/thermal.txt
>  
>  Example:
>   pwm-fan {
>   compatible = "pwm-fan";
>   status = "okay";
>   pwms = <&pwm 0 1 0>;
> + cooling-levels = <0 102 170 230>;
>   };
> -- 
> 2.0.0.rc2
> 


signature.asc
Description: Digital signature

Re: [PATCH v4 1/8] thermal: Provide stub for thermal_of_cooling_device_register() function

[Eduardo Valentin]

On Wed, Feb 18, 2015 at 11:07:29AM +0100, Lukasz Majewski wrote:
> Odroid U3 fan can work without being registered as OF cooling device
> (with CONFIG_THERMAL_OF disabled).
> In this situation it can be controlled via PWM entry at
> /sys/class/hwmon/hwmon0/pwm1.
> 
> Therefore, the thermal_of_cooling_device_register() function needs a stub
> to allow clean compilation.


I've just applied a patch on this same matter from Nishanth Menon [1].
Can you please check if his patch is enough for you?

[1] -
https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=fixes&id=12ca7188468ee29c4e717f73db4bf43c90954fc7


> 
> Signed-off-by: Lukasz Majewski 
> ---
> Changes for v2:
> - None
> Changes for v3:
> - Provide stub declaration when CONFIG_THERMAL is not set
> Changes for v4:
> - None
> ---
>  include/linux/thermal.h | 17 ++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index fc52e30..eacf2de 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -293,6 +293,20 @@ struct thermal_trip {
>  };
>  
>  /* Function declarations */
> +#ifdef CONFIG_THERMAL
> +struct thermal_cooling_device *
> +thermal_of_cooling_device_register(struct device_node *np,
> +char *type, void *devdata,
> +const struct thermal_cooling_device_ops *);
> +#else
> +static inline struct thermal_cooling_device *
> +thermal_of_cooling_device_register(struct device_node *np,
> +char *type, void *devdata,
> +const struct thermal_cooling_device_ops *ops)
> +{
> + return NULL;
> +}
> +#endif
>  #ifdef CONFIG_THERMAL_OF
>  struct thermal_zone_device *
>  thermal_zone_of_sensor_register(struct device *dev, int id, void *data,
> @@ -328,9 +342,6 @@ void thermal_zone_device_update(struct 
> thermal_zone_device *);
>  
>  struct thermal_cooling_device *thermal_cooling_device_register(char *, void 
> *,
>   const struct thermal_cooling_device_ops *);
> -struct thermal_cooling_device *
> -thermal_of_cooling_device_register(struct device_node *np, char *, void *,
> -const struct thermal_cooling_device_ops *);
>  void thermal_cooling_device_unregister(struct thermal_cooling_device *);
>  struct thermal_zone_device *thermal_zone_get_zone_by_name(const char *name);
>  int thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned long 
> *temp);
> -- 
> 2.0.0.rc2
> 


signature.asc
Description: Digital signature

Re: [PATCH v4 2/8] thermal: Provide stub for thermal_cdev_update() function

[Eduardo Valentin]

On Wed, Feb 18, 2015 at 11:07:30AM +0100, Lukasz Majewski wrote:
> Odroid U3 fan can work without being registered as OF cooling device
> (with CONFIG_THERMAL{_OF|} disabled).
> In this situation it can be controlled via PWM entry at
> /sys/class/hwmon/hwmon0/pwm1.
> 
> Therefore, the thermal_cdev_update() function needs a stub
> to allow clean compilation.

I've just applied a patch on this same matter from Nishanth Menon [1].
Can you please check if his patch is enough for you?

[1] -
https://git.kernel.org/cgit/linux/kernel/git/evalenti/linux-soc-thermal.git/commit/?h=fixes&id=12ca7188468ee29c4e717f73db4bf43c90954fc7

> 
> Signed-off-by: Lukasz Majewski 
> ---
> Changes for v2:
> - New patch
> Changes for v3:
> - thermal_cdev_update() now depends on CONFIG_THERMAL flag
> Changes for v4:
> - None
> ---
>  include/linux/thermal.h | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index eacf2de..25382e6 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -298,6 +298,7 @@ struct thermal_cooling_device *
>  thermal_of_cooling_device_register(struct device_node *np,
>  char *type, void *devdata,
>  const struct thermal_cooling_device_ops *);
> +void thermal_cdev_update(struct thermal_cooling_device *);
>  #else
>  static inline struct thermal_cooling_device *
>  thermal_of_cooling_device_register(struct device_node *np,
> @@ -306,6 +307,9 @@ thermal_of_cooling_device_register(struct device_node *np,
>  {
>   return NULL;
>  }
> +static inline void thermal_cdev_update(struct thermal_cooling_device *cdev)
> +{
> +}
>  #endif
>  #ifdef CONFIG_THERMAL_OF
>  struct thermal_zone_device *
> @@ -349,7 +353,6 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, 
> unsigned long *temp);
>  int get_tz_trend(struct thermal_zone_device *, int);
>  struct thermal_instance *get_thermal_instance(struct thermal_zone_device *,
>   struct thermal_cooling_device *, int);
> -void thermal_cdev_update(struct thermal_cooling_device *);
>  void thermal_notify_framework(struct thermal_zone_device *, int);
>  
>  #ifdef CONFIG_NET
> -- 
> 2.0.0.rc2
> 


signature.asc
Description: Digital signature

[PATCH 1/1] ARM: dts: Enable Broadcom Cygnus BCM958305K

[Jonathan Richardson]

DT file to enable the Wireless Audio reference design based on the
BCM58305.

Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Tested-by: Scott Branden 
Signed-off-by: Jonathan Richardson 
---
 arch/arm/boot/dts/Makefile   |3 ++-
 arch/arm/boot/dts/bcm958305k.dts |   53 ++
 2 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/bcm958305k.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 91bd5bd..24b6084 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -64,7 +64,8 @@ dtb-$(CONFIG_ARCH_BCM_5301X) += \
 dtb-$(CONFIG_ARCH_BCM_63XX) += bcm963138dvt.dtb
 dtb-$(CONFIG_ARCH_BCM_CYGNUS) += bcm911360_entphn.dtb \
bcm911360k.dtb \
-   bcm958300k.dtb
+   bcm958300k.dtb \
+   bcm958305k.dtb
 dtb-$(CONFIG_ARCH_BCM_MOBILE) += bcm28155-ap.dtb \
bcm21664-garnet.dtb
 dtb-$(CONFIG_ARCH_BERLIN) += \
diff --git a/arch/arm/boot/dts/bcm958305k.dts b/arch/arm/boot/dts/bcm958305k.dts
new file mode 100644
index 000..56b429a
--- /dev/null
+++ b/arch/arm/boot/dts/bcm958305k.dts
@@ -0,0 +1,53 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2015 Broadcom Corporation.  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:
+ *
+ ** Redistributions of source code must retain the above copyright
+ *  notice, this list of conditions and the following disclaimer.
+ ** Redistributions in binary form must reproduce the above copyright
+ *  notice, this list of conditions and the following disclaimer in
+ *  the documentation and/or other materials provided with the
+ *  distribution.
+ ** Neither the name of Broadcom Corporation nor the names of its
+ *  contributors may be used to endorse or promote products derived
+ *  from this software without specific prior written permission.
+ *
+ *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+#include "bcm-cygnus.dtsi"
+
+/ {
+   model = "Cygnus Wireless Audio (BCM958305K)";
+   compatible = "brcm,bcm58305", "brcm,cygnus";
+
+   aliases {
+   serial0 = &uart3;
+   };
+
+   chosen {
+   stdout-path = &uart3;
+   bootargs = "console=ttyS0,115200";
+   };
+
+   uart3: serial@18023000 {
+   status = "okay";
+   };
+};
-- 
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 0/1] Enable Broadcom Cygnus BCM958305K

[Jonathan Richardson]

This patchset adds a DTS file to enable the BCM58305 Wireless Audio reference
design based on Cygnus. It will be kept up to date as Cygnus drivers are
accepted into the mainline.

Jonathan Richardson (1):
  ARM: dts: Enable Broadcom Cygnus BCM958305K

 arch/arm/boot/dts/Makefile   |3 ++-
 arch/arm/boot/dts/bcm958305k.dts |   53 ++
 2 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/boot/dts/bcm958305k.dts

-- 
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] ARM: dts: am335x-bone*: usb0 is hardwired for peripheral

[Tony Lindgren]

* Felipe Balbi  [150224 08:23]:
> On Tue, Feb 24, 2015 at 10:10:43AM -0600, Robert Nelson wrote:
> > Fixes: http://bugs.elinux.org/issues/127
> > 
> > the bb.org community was seeing random reboots before this change.
> > 
> > Signed-off-by: Robert Nelson 
> 
> that's a dead giveaway considering the connector in the board :-)
> 
> Thanks
> 
> Reviewed-by: Felipe Balbi 
> Acked-by: Felipe Balbi 

Applying into omap-for-v4.0/fixes thanks.

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/4] phy: ti-pipe3: fixes for 3.19-rc

[Tony Lindgren]

* Roger Quadros  [150218 00:13]:
> On 18/02/15 10:00, Roger Quadros wrote:
> > On 13/01/15 17:54, Tony Lindgren wrote:
> >> * Roger Quadros  [150113 04:26]:
> >>> Hi,
> >>>
> >>> During system suspend L3INIT_960M_GFCLK and L3INIT_480M_GFCLK clocks 
> >>> remain
> >>> active on the DRA7 platform. This is because the pipe3 driver doesn't shut
> >>> them off as part of .suspend(). Patch 1 addresses this issue.
> >>>
> >>> SATA on both OMAP5 and DRA7 breaks when SATA drive is plugged in after a
> >>> system suspend/resume or if AHCI_PLATFORM driver is used as module.
> >>> Patches 2,3,4 fix it.
> >>>
> >>> Hope to get these patches in through the 3.19-rc cycle.
> >>>
> >>> Tony,
> >>>
> >>> Do you wish to take the DTS patches or let them go in through PHY tree?
> >>
> >> Those look ok to me to merge along with the fixes, will ack those two.
> >>
> > 
> > Looks like this missed 3.19-rc. My bad for not following up.
> > 
> > Kishon, can you please queue these for 3.20-rc? Thanks.
> 
> Well the PHY patches (1 and 2) are already queued for v3.20-rc1 via Greg's 
> usb-next tree.
> Tony can you please queue the DT side patches for v3.20? Thanks.

Applying these into omap-for-v4.0/fixes. Lookse like we're a few
kernel releases behind with these :)

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH][v4.0-rc] ARM: dts: dra7x-evm: beagle-x15: Fix USB Host

[Tony Lindgren]

* Roger Quadros  [150224 04:40]:
> In commit 87517d26d888 ("ARM: dts: dra7-evm: Add extcon nodes for USB")
> we enabled Extcon USB gpio to tackle the USB ID pin and get
> peripheral mode to work.
> 
> But the extcon-gpio-usb driver [1] didn't make it into v4.0
> and this makes the USB driver defer probe indefinitely breaking
> USB Host functionality.
> 
> As a temporary fix we remove the extcon handle from the
> USB controller and add it back when the extcon driver
> merges in v4.1.

Uhh OK, If there are dependencies, can you please start splitting
your patches so the dts changes that cause issues are sent only
after the related driver changes are in Linux next?

Anyways, applying into omap-for-v4.0/fixes.

Tony
 
> [1] - https://lkml.org/lkml/2015/2/2/187
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/5] ARM: DTS: OMAP/DRA7: dma property name correction

[Tony Lindgren]

* Peter Ujfalusi  [150220 05:45]:
> Hi,
> 
> While working on the DMA crossbar support for DRA7 typo of devices I have
> noticed that the dma-channels and dma-requests properties of sdma wrongly
> has # at the beginning.
> According to the documentation, it should not have:
> Documentation/devicetree/bindings/dma/dma.txt
> 
> Since these properties are not in use at the moment, but it is going to be 
> needed
> for the crossbar driver it is better to fix it right now so we do not need to
> patch .dtsi and .c files at the same time later.
> 
> Tony: I would really appreciate if this could go in within the current merge
> window.

Yeah applying into omap-for-v4.0/fixes, let's get it out of the
way to avoid more cut-n-paste errors.

Regards,

Tony
 
> Peter Ujfalusi (5):
>   ARM: DTS: omap2: Correct the dma controller's property names
>   ARM: DTS: omap3: Correct the dma controller's property names
>   ARM: DTS: omap4: Correct the dma controller's property names
>   ARM: DTS: omap5: Correct the dma controller's property names
>   ARM: DTS: dra7: Correct the dma controller's property names
> 
>  arch/arm/boot/dts/dra7.dtsi  | 4 ++--
>  arch/arm/boot/dts/omap2.dtsi | 4 ++--
>  arch/arm/boot/dts/omap3.dtsi | 4 ++--
>  arch/arm/boot/dts/omap4.dtsi | 4 ++--
>  arch/arm/boot/dts/omap5.dtsi | 4 ++--
>  5 files changed, 10 insertions(+), 10 deletions(-)
> 
> -- 
> 2.3.0
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: OMAP3-N900: Fix offset for smc91x ethernet

[Tony Lindgren]

* Tony Lindgren  [150220 07:47]:
> * Pali Rohár  [150220 01:56]:
> > On Friday 20 February 2015 10:24:35 Arnd Bergmann wrote:
> > > On Thursday 19 February 2015 17:49:50 Pali Rohár wrote:
> > > > Offset for smc91x must be zero otherwise smc91x linux kernel
> > > > driver does not detect smc91x ethernet hardware in qemu
> > > > N900 machine.
> > > > 
> > > > Signed-off-by: Pali Rohár 
> > > 
> > > Is that the same offset on real hardware, or could this be a
> > > mistake in the qemu model?
> > > 
> > >   Arnd
> > 
> > In original Nokia 2.6.28 kernel is offset also set to 0, see:
> > 
> > https://gitorious.org/linux-n900/linux-n900/source/629fc5ab00cafb31272c478efa2c2b35fabd4c70:arch/arm/mach-omap2/board-rx51-peripherals.c#L42
> > 
> > https://gitorious.org/linux-n900/linux-n900/source/629fc5ab00cafb31272c478efa2c2b35fabd4c70:arch/arm/mach-omap2/board-rx51-peripherals.c#L274
> > 
> > Tony already tested offset 0 on real HW and wrote that it is
> > working too, just show some warning. But qemu with offset 0x300
> > does not work.
> 
> Yes it works with offset 0, except the smc91x warns about not
> using the default offset 0x300 based on the EEPROM. As only
> three address lines seem to be connected, we can use offset
> 0 just fine, and update the EEPROM configuration as needed.

Applying into omap-for-v4.0/fixes with updated comments.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM64: Add new Xilinx ZynqMP SoC

[Mark Rutland]

Hi Michal,

I have a few minor comments below, but generally this is looking like
one of the best dts submissions I've seen!

[...]

> +/ {
> +   model = "ZynqMP EP108";
> +
> +   aliases {
> +   serial0 = &uart0;
> +   };
> +
> +   chosen {
> +   stdout-path = "serial0:115200n8";
> +   };

Thanks for using stdout-path with the full parameters.

Does your UART have earlycon support?

[...]

> +/ {
> +   compatible = "xlnx,zynqmp";
> +   #address-cells = <2>;
> +   #size-cells = <1>;

I guess this is fine, though to me it feels more natural to use
#size-cells = <2> in case we need to describe larger ranges for some bus
later.

> +   cpus {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   cpu@0 {
> +   compatible = "arm,cortex-a53", "arm,armv8";
> +   device_type = "cpu";
> +   enable-method = "psci";
> +   reg = <0x0>;
> +   };
> +
> +   cpu@1 {
> +   compatible = "arm,cortex-a53", "arm,armv8";
> +   device_type = "cpu";
> +   enable-method = "psci";
> +   reg = <0x1>;
> +   };
> +
> +   cpu@2 {
> +   compatible = "arm,cortex-a53", "arm,armv8";
> +   device_type = "cpu";
> +   enable-method = "psci";
> +   reg = <0x2>;
> +   };
> +
> +   cpu@3 {
> +   compatible = "arm,cortex-a53", "arm,armv8";
> +   device_type = "cpu";
> +   enable-method = "psci";
> +   reg = <0x3>;
> +   };
> +   };

These look fine.

> +
> +   psci {
> +   compatible = "arm,psci-0.2";
> +   method = "smc";
> +   };

Neat!

What are you using as your implementation? Are all the mandatory
PSCIv0.2 features implemented (e.g. MIGRATE_INFO_TYPE)?

I take it this boots at EL2 on all CPUs?

Does CPU0 hotplug work?

Do you need to keep a CPU online or do you require MIGRATE? e.g. does
MIGRATE_INFO_TYPE return something other than 2 ("MP or not present")?

[...]

> +   amba_apu {
> +   compatible = "simple-bus";
> +   #address-cells = <2>;
> +   #size-cells = <1>;
> +   ranges;
> +
> +   timer {
> +   compatible = "arm,armv8-timer";
> +   interrupt-parent = <&gic>;
> +   interrupts = <1 13 0xff01>,
> +<1 14 0xff01>,
> +<1 11 0xff01>,
> +<1 10 0xff01>;
> +   };

The architected timer should just be under the root node, given it's a
component of the CPU -- it doesn't live on any bus.

I take it CNTFRQ is configured appropriately on all CPUs?

[...]

> +   i2c_clk: i2c_clk {
> +   compatible = "fixed-clock";
> +   #clock-cells = <0x0>;
> +   clock-frequency = <1>;
> +   };

That clock-frequency looks a little odd. Is that right?

I haven't taken an in-depth look at the other nodes. They look sane at a
high-level, and assuming they are all already documented and supported
they look fine to me.

Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: DTS: omap3-n900.dts: fix i2c bus numbering

[Tony Lindgren]

* Ivaylo Dimitrov  [150209 08:07]:
> 
> 
> On  9.02.2015 17:02, Nishanth Menon wrote:
> >On 17:48-20150208, Ivaylo Dimitrov wrote:
> >>With legacy boot i2c buses on Nokia N900 are numbered i2c1, i2c2 and i2c3.
> >>Commit 20b80942ef4e ("ARM: dts: OMAP3+: Add i2c aliases") fixed the
> >>numbering with DT boot, but introduced a regression on N900 - aliases
> >>become i2c0, i2c1 and i2c2. Fix that by providing the correct aliases in
> >>the board dts.
> >>
> >>Signed-off-by: Ivaylo Dimitrov 
> >>---
> >I suppose this is due to some legacy userspace breakage?
> >if yes, we do not intend to break userspace :), So:
> 
> Yes, legacy userspace breakage :)

Applying into omap-for-v4.0/fixes thanks,

Tony
--
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] thermal: armada: read stable temp on Armada XP

[Eduardo Valentin]

Tyler,

On Tue, Feb 10, 2015 at 05:50:15PM -0500, Tyler Hall wrote:
> The current register being used to read the temperature returns a noisy value
> that is prone to variance and occasional outliers. The value in the thermal
> manager control and status register appears to have the same scale but much
> less variability.
> 
> Add a "marvell,armadaxp-filtered-thermal" config which is set up to read from
> the Thermal Manager Control and Status Register at 0x184c4 rather than the
> Thermal Sensor Status Register at 0x182b0. The only difference is the
> temperature value shift. The original "marvell,armadaxp-thermal" is retained
> for device tree compatibility.
> 
> This also fixes Armada XP clearing the disable bit in the wrong register. Bit > 0
> of the sensor register was being cleared but that bit is read-only. The 
> disable
> bit doesn't seem to have an effect on the temperature sensor value, however, 
> so
> this doesn't make a material difference.
> 
> This problem was detected when running with the watchdog(8) daemon polling the
> thermal value. In one instance I observed a single read of over 200 degrees C
> which caused a spurious watchdog-initiated reboot. I have since observed
> individual outliers of ~20 degrees C. With this change and the corresponding
> device tree update, the temperature is much more stable.
> 
> Signed-off-by: Tyler Hall 
> ---
> 
> If there's a better way to handle this than a separate binding, I'm open to
> suggestions.


The fix seams reasonable. Although, it remains the question what is
applicability to other Armada chips? Besides, shouldn't we simply use it
by default? Also, do you plan to send updates in the DTS files?


I would appreciate if you get a Review-by, from Ezequiel for instance,
before we apply this.


Ezequiel, any objections before I move forward with this one?

BR,

Eduardo Valentin
> 
> My conclusions about these registers are based on experimental data. The
> documentation is very sparse, but the Thermal Manager Control and Status
> Register looks like the preferred register given the way it is laid out in the
> public spec.
> 
> I have the small corresponding patch to the dts which I can submit separately.
> 
> Thanks
> Tyler
> 
>  .../devicetree/bindings/thermal/armada-thermal.txt  |  8 
>  drivers/thermal/armada_thermal.c| 13 
> +
>  2 files changed, 21 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> index 4698e0e..0d6a3f1 100644
> --- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> @@ -7,6 +7,14 @@ Required properties:
>   marvell,armada375-thermal
>   marvell,armada380-thermal
>   marvell,armadaxp-thermal
> + marvell,armadaxp-filtered-thermal
> +
> + Note: "marvell,armadaxp-filtered-thermal" is adjusted to read
> + the hardware-filtered value in the thermal manager
> + control/status register rather than the raw sensor value in the
> + thermal sensor status register. "marvell,armadaxp-thermal"
> + remains for backward compatibility. The sensor reg address must
> + also point to the appropriate register.
>  
>  - reg:   Device's register space.
>   Two entries are expected, see the examples below.
> diff --git a/drivers/thermal/armada_thermal.c 
> b/drivers/thermal/armada_thermal.c
> index c2556cf..d3c2ad3 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -196,6 +196,15 @@ static const struct armada_thermal_data armadaxp_data = {
>   .coef_div = 13825,
>  };
>  
> +static const struct armada_thermal_data armadaxp_filt_data = {
> + .init_sensor = armadaxp_init_sensor,
> + .temp_shift = 1,
> + .temp_mask = 0x1ff,
> + .coef_b = 315300UL,
> + .coef_m = 1000UL,
> + .coef_div = 13825,
> +};
> +
>  static const struct armada_thermal_data armada370_data = {
>   .is_valid = armada_is_valid,
>   .init_sensor = armada370_init_sensor,
> @@ -236,6 +245,10 @@ static const struct of_device_id 
> armada_thermal_id_table[] = {
>   .data   = &armadaxp_data,
>   },
>   {
> + .compatible = "marvell,armadaxp-filtered-thermal",
> + .data   = &armadaxp_filt_data,
> + },
> + {
>   .compatible = "marvell,armada370-thermal",
>   .data   = &armada370_data,
>   },
> -- 
> 2.3.0
> 


signature.asc
Description: Digital signature

[PATCH_V2 1/3] dt-bindings: dma: Add binding for jz4780-dma

[Zubair Lutfullah Kakakhel]

From: Alex Smith 

Add device tree bindings for the DMA controller on JZ4780 SoCs, used by
the dma-jz4780 driver.

Signed-off-by: Alex Smith 
Signed-off-by: Zubair Lutfullah Kakakhel 

---
V1 -> V2 None
---
 .../devicetree/bindings/dma/jz4780-dma.txt | 61 ++
 1 file changed, 61 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/jz4780-dma.txt

diff --git a/Documentation/devicetree/bindings/dma/jz4780-dma.txt 
b/Documentation/devicetree/bindings/dma/jz4780-dma.txt
new file mode 100644
index 000..ce90011
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/jz4780-dma.txt
@@ -0,0 +1,61 @@
+* Ingenic JZ4780 DMA Controller
+
+Required properties:
+
+- compatible: Should be "ingenic,jz4780-dma"
+- reg: Should contain the DMA controller registers location and length.
+- interrupts: Should contain the interrupt specifier of the DMA controller.
+- interrupt-parent: Should be the phandle of the interrupt controller that
+- clocks: Should contain a clock specifier for the JZ4780 PDMA clock.
+- #dma-cells: Must be <3>. Number of integer cells in the dmas property of
+  DMA clients (see below).
+
+Optional properties:
+
+- ingenic,reserved-channels: Bitmask of channels to reserve for devices that
+  need a specific channel. These channels will only be assigned when explicitly
+  requested by a client. The primary use for this is channels 0 and 1, which
+  can be configured to have special behaviour for NAND/BCH when using
+  programmable firmware.
+
+Example:
+
+dma: dma@1342 {
+   compatible = "ingenic,jz4780-dma";
+   reg = <0x1342 0x1>;
+
+   interrupt-parent = <&intc>;
+   interrupts = <10>;
+
+   clocks = <&cgu JZ4780_CLK_PDMA>;
+
+   #dma-cells = <3>;
+
+   ingenic,reserved-channels = <0x3>;
+};
+
+DMA clients must use the format described in dma.txt, giving a phandle to the
+DMA controller plus the following 3 integer cells:
+
+1. Transmit request type: The DMA request type for transfers to the device on
+   the allocated channel, as defined in the SoC documentation. If set to 0,
+   transfers to the device will not be allowed on the channel.
+
+2. Receive request type: The DMA request type for transfers from the device on
+   the allocated channel, as defined in the SoC documentation. If set to 0,
+   transfers from the device will not be allowed on the channel.
+
+3. Channel: If set to 0x, any available channel will be allocated for
+   the client. Otherwise, the exact channel specified will be used. The channel
+   should be reserved on the DMA controller using the ingenic,reserved-channels
+   property.
+
+Example:
+
+uart0: serial@1003 {
+   ...
+   dmas = <&dma 0x14 0 0x
+   &dma 0 0x15 0x>;
+   dma-names = "tx", "rx";
+   ...
+};
-- 
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 2/3] dma: jz4780: add driver for the Ingenic JZ4780 DMA controller

[Zubair Lutfullah Kakakhel]

From: Alex Smith 

This patch adds a driver for the DMA controller found in the Ingenic
JZ4780.

It currently does not implement any support for the programmable firmware
feature of the controller - this is not necessary for most uses. It also
does not take priority into account when allocating channels, it just
allocates the first available channel. This can be implemented later.

Signed-off-by: Alex Smith 
Signed-off-by: Zubair Lutfullah Kakakhel 
[Updated for dmaengine api changes, Add residue support, couple of minor fixes]

---
V1 -> V2
Updated for dmaengine api change See https://lkml.org/lkml/2014/10/22/585
Fixed email address
Removed context from arguments from prep_dma_cyclic and prep_slave_sg 31c1e5a135
Remove chancnt See b2c100e02f6
Removed .owner See cd166280
Added dma controller capabilites See 75dc177 and http://lwn.net/Articles/616390/
Call dma_free_irq in remove
Rename irq handler from jz4780_dma_irq to jz4780_dma_irq_handler
Fix case switch in jz4780_dma_transfer_size to make clearer.
Removed redundant check in jz4780_dma_slave_config.
Add residue support for dma-jz4780
Removed reduntant print after devm_kzalloc.
---
 drivers/dma/Kconfig  |  10 +
 drivers/dma/Makefile |   1 +
 drivers/dma/dma-jz4780.c | 877 +++
 include/dt-bindings/dma/jz4780-dma.h |  49 ++
 4 files changed, 937 insertions(+)
 create mode 100644 drivers/dma/dma-jz4780.c
 create mode 100644 include/dt-bindings/dma/jz4780-dma.h

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index a874b6e..ce09734 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -358,6 +358,16 @@ config DMA_JZ4740
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
 
+config DMA_JZ4780
+   tristate "JZ4780 DMA support"
+   depends on MACH_JZ4780
+   select DMA_ENGINE
+   select DMA_VIRTUAL_CHANNELS
+   help
+ This selects support for the DMA controller in Ingenic JZ4780 SoCs.
+ If you have a board based on such a SoC and wish to use DMA for
+ devices which can use the DMA controller, say Y or M here.
+
 config K3_DMA
tristate "Hisilicon K3 DMA support"
depends on ARCH_HI3xxx
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index f915f61..af239e7 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_DMA_OMAP) += omap-dma.o
 obj-$(CONFIG_DMA_BCM2835) += bcm2835-dma.o
 obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o
 obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
+obj-$(CONFIG_DMA_JZ4780) += dma-jz4780.o
 obj-$(CONFIG_TI_CPPI41) += cppi41.o
 obj-$(CONFIG_K3_DMA) += k3dma.o
 obj-$(CONFIG_MOXART_DMA) += moxart-dma.o
diff --git a/drivers/dma/dma-jz4780.c b/drivers/dma/dma-jz4780.c
new file mode 100644
index 000..db9ff05
--- /dev/null
+++ b/drivers/dma/dma-jz4780.c
@@ -0,0 +1,877 @@
+/*
+ * Ingenic JZ4780 DMA controller
+ *
+ * Copyright (c) 2015 Imagination Technologies
+ * Author: Alex Smith 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation;  either version 2 of the  License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dmaengine.h"
+#include "virt-dma.h"
+
+#define JZ_DMA_NR_CHANNELS 32
+
+/* Global registers. */
+#define JZ_DMA_REG_DMAC0x1000
+#define JZ_DMA_REG_DIRQP   0x1004
+#define JZ_DMA_REG_DDR 0x1008
+#define JZ_DMA_REG_DDRS0x100c
+#define JZ_DMA_REG_DMACP   0x101c
+#define JZ_DMA_REG_DSIRQP  0x1020
+#define JZ_DMA_REG_DSIRQM  0x1024
+#define JZ_DMA_REG_DCIRQP  0x1028
+#define JZ_DMA_REG_DCIRQM  0x102c
+
+/* Per-channel registers. */
+#define JZ_DMA_REG_DSA(n)  (0x00 + (n) * 0x20)
+#define JZ_DMA_REG_DTA(n)  (0x04 + (n) * 0x20)
+#define JZ_DMA_REG_DTC(n)  (0x08 + (n) * 0x20)
+#define JZ_DMA_REG_DRT(n)  (0x0c + (n) * 0x20)
+#define JZ_DMA_REG_DCS(n)  (0x10 + (n) * 0x20)
+#define JZ_DMA_REG_DCM(n)  (0x14 + (n) * 0x20)
+#define JZ_DMA_REG_DDA(n)  (0x18 + (n) * 0x20)
+#define JZ_DMA_REG_DSD(n)  (0x1c + (n) * 0x20)
+
+#define JZ_DMA_DMAC_DMAE   BIT(0)
+#define JZ_DMA_DMAC_AR BIT(2)
+#define JZ_DMA_DMAC_HLTBIT(3)
+#define JZ_DMA_DMAC_FMSC   BIT(31)
+
+#define JZ_DMA_DRT_AUTO0x8
+
+#define JZ_DMA_DCS_CTE BIT(0)
+#define JZ_DMA_DCS_HLT BIT(2)
+#define JZ_DMA_DCS_TT  BIT(3)
+#define JZ_DMA_DCS_AR  BIT(4)
+#define JZ_DMA_DCS_DES8BIT(30)
+
+#define JZ_DMA_DCM_LINKBIT(0)
+#define JZ_DMA_DCM_TIE BIT(1)
+#define JZ_DMA_DCM_STDEBIT(2)
+#define JZ_DMA_DCM_TSZ_SHIFT   8
+#define JZ_DMA_DCM_TSZ_MASK(0x7 << JZ_DMA_DCM_TSZ_SHIFT)
+#define JZ_DMA_DCM_DP_SHIFT12
+#define JZ_DMA_DCM_SP_SHIFT

[PATCH_V2 3/3] MAINTAINERS: Add Ingenic JZ4780 DMA driver maintainer entry

[Zubair Lutfullah Kakakhel]

Signed-off-by: Zubair Lutfullah Kakakhel 
---
 MAINTAINERS | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..be98874 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4962,6 +4962,11 @@ W:   http://industrypack.sourceforge.net
 S: Maintained
 F: drivers/ipack/
 
+INGENIC JZ4780 DMA Driver
+M: Zubair Lutfullah Kakakhel 
+S: Maintained
+F: drivers/dma/dma-jz4780.c
+
 INTEGRITY MEASUREMENT ARCHITECTURE (IMA)
 M: Mimi Zohar 
 M: Dmitry Kasatkin 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH_V2 0/3] dma: dt: Add DMA driver for jz4780

[Zubair Lutfullah Kakakhel]

Hi,

Here we have three patches that add a DMA driver for the Ingenic JZ4780 SoC.

JZ4780 support is still in-flight.

See http://patchwork.linux-mips.org/bundle/paulburton/ci20-v3.20/

These are based on 4.0-rc1.

Apart from the channel numbers, jz4740 and jz4780 are quite different.
jz4780 has many more features in hardware.

Hence, we are unable to use the jz4740-dma driver.

V1->V2 changes
Updates for dmaengine api changes.
Add residue support.
Details in the patch commit message

ZubairLK


Alex Smith (2):
  dt-bindings: dma: Add binding for jz4780-dma
  dma: jz4780: add driver for the Ingenic JZ4780 DMA controller

Zubair Lutfullah Kakakhel (1):
  MAINTAINERS: Add Ingenic JZ4780 DMA driver maintainer entry

 .../devicetree/bindings/dma/jz4780-dma.txt |  61 ++
 MAINTAINERS|   5 +
 drivers/dma/Kconfig|  10 +
 drivers/dma/Makefile   |   1 +
 drivers/dma/dma-jz4780.c   | 877 +
 include/dt-bindings/dma/jz4780-dma.h   |  49 ++
 6 files changed, 1003 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/jz4780-dma.txt
 create mode 100644 drivers/dma/dma-jz4780.c
 create mode 100644 include/dt-bindings/dma/jz4780-dma.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

Re: [PATCH 2/2] dma: jz4780: add driver for the Ingenic JZ4780 DMA controller

[Zubair Lutfullah Kakakhel]

On 23/02/15 11:15, Vinod Koul wrote:
> On Thu, Jan 29, 2015 at 12:19:39PM +, Zubair Lutfullah Kakakhel wrote:
>> From: Alex Smith 
>>
>> This patch adds a driver for the DMA controller found in the Ingenic
>> JZ4780.

Thank-you for the detailed review.

I'm sending another series.

Regards,
ZubairLK
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM64: Add new Xilinx ZynqMP SoC

[Michal Simek]

On 02/24/2015 05:29 PM, Rob Herring wrote:
> On Tue, Feb 24, 2015 at 8:58 AM, Michal Simek  wrote:
>> On 02/24/2015 03:42 PM, Rob Herring wrote:
>>> On Tue, Feb 24, 2015 at 1:56 AM, Michal Simek  
>>> wrote:
 Initial version of device tree for Xilinx ZynqMP SoC.

 Signed-off-by: Michal Simek 
 Acked-by: Sören Brinkmann 
 ---
>>>
>>> [...]
>>>
 +   gic: interrupt-controller@f901 {
 +   compatible = "arm,cortex-a15-gic", 
 "arm,cortex-a9-gic";
>>>
>>> gic-400, right?
>>
>> yep
>>
>>>
 +   #interrupt-cells = <3>;
 +   reg = <0x0 0xf901 0x1>,
 + <0x0 0xf902 0x2>,
 + <0x0 0xf904 0x2>,
 + <0x0 0xf906 0x2>;
>>>
>>> These addresses are wrong if you are doing address swizzling to do 64K
>>> offsets. We don't really have an answer yet as to what is the right
>>> way. See the XGene GIC discussion[1].
>>
>> Is this better for GICC?
>> <0x0 0xf902f000 0x2000>
> 
> Yes, and the VCPU interface needs this as well. As far as sizes, we're
> still discussing that.

ok. Will test and fix. What about the rest of DT description?

Thanks,
Michal

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/4] clk: st: New always-on clock domain

[Lee Jones]

On Tue, 24 Feb 2015, Lee Jones wrote:

> v2 => v3:
>   - Ensure DT actually reflects h/w
> - i.e. Nodes should not contain a mishmash of different IP
>   blocks, but should identify related h/w.  In the current
>   example we use interconnects
>   - Change naming from clkdomain to clk-always-on
>   - Place "do not abuse" warning in documentation
> 
> v1 => v2:
>   - Turned the ST specific driver into a generic one
>   
> Hardware can have a bunch of clocks which must not be turned off.
> If drivers a) fail to obtain a reference to any of these or b) give
> up a previously obtained reference during suspend, the common clk
> framework will attempt to turn them off and the hardware will
> subsequently die.  The only way to recover from this failure is to
> restart.
>   
> To avoid either of these two scenarios from catastrophically
> disabling the running system we have implemented a clock domain
> where clocks are consumed and references are taken, thus preventing
> them from being shut down by the framework.
> 
> *** BLURB HERE ***

*grumble*, that's annoying, as I removed this.

I guess Git caches the patches before sending them.

> Lee Jones (4):
>   ARM: sti: stih407-family: Supply defines for CLOCKGEN A0
>   ARM: sti: stih407-family: Add platform interconnects to always-on clk
> domain
>   clk: Provide an always-on clock domain framework
>   clk: dt: Introduce always-on clock domain documentation
> 
>  .../devicetree/bindings/clock/clk-always-on.txt| 35 
>  arch/arm/boot/dts/stih407-family.dtsi  | 15 ++
>  drivers/clk/Makefile   |  1 +
>  drivers/clk/clk-always-on.c| 62 
> ++
>  include/dt-bindings/clock/stih407-clks.h   |  4 ++
>  5 files changed, 117 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/clk-always-on.txt
>  create mode 100644 drivers/clk/clk-always-on.c
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] fix ehrpwm tbclk data on am33xx and am43xx

[Tony Lindgren]

* Vignesh R  [150209 22:43]:
> In am33xx and am43xx, ehrpwm tbclk is derived from functional clock of
> PWMSS. The schematics and TRMs show that there is only one input clock to
> the PWMSS. But currently, tbclk is wrongly shown to be deriving from
> dpll_per_m2_ck instead of functional clock l4ls_gclk in the DT.
> 
> Fixing ehrpwm tbclk data to reflect the right clk source.
> Tested on beaglebone and am437x-gp-evm.
> 
> Vignesh R (2):
>   ARM: dts: am33xx-clocks: Fix ehrpwm tbclk data on am33xx
>   ARM: dts: am43xx-clocks: Fix ehrpwm tbclk data on am43xx
> 
>  arch/arm/boot/dts/am33xx-clocks.dtsi |  6 +++---
>  arch/arm/boot/dts/am43xx-clocks.dtsi | 12 ++--
>  2 files changed, 9 insertions(+), 9 deletions(-)

Tero, care to check this one too and ack if OK?

Thanks,

Tony
--
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 v3 0/4] clk: st: New always-on clock domain

[Lee Jones]

v2 => v3:
  - Ensure DT actually reflects h/w
- i.e. Nodes should not contain a mishmash of different IP
  blocks, but should identify related h/w.  In the current
  example we use interconnects
  - Change naming from clkdomain to clk-always-on
  - Place "do not abuse" warning in documentation

v1 => v2:
  - Turned the ST specific driver into a generic one
  
Hardware can have a bunch of clocks which must not be turned off.
If drivers a) fail to obtain a reference to any of these or b) give
up a previously obtained reference during suspend, the common clk
framework will attempt to turn them off and the hardware will
subsequently die.  The only way to recover from this failure is to
restart.
  
To avoid either of these two scenarios from catastrophically
disabling the running system we have implemented a clock domain
where clocks are consumed and references are taken, thus preventing
them from being shut down by the framework.

*** BLURB HERE ***

Lee Jones (4):
  ARM: sti: stih407-family: Supply defines for CLOCKGEN A0
  ARM: sti: stih407-family: Add platform interconnects to always-on clk
domain
  clk: Provide an always-on clock domain framework
  clk: dt: Introduce always-on clock domain documentation

 .../devicetree/bindings/clock/clk-always-on.txt| 35 
 arch/arm/boot/dts/stih407-family.dtsi  | 15 ++
 drivers/clk/Makefile   |  1 +
 drivers/clk/clk-always-on.c| 62 ++
 include/dt-bindings/clock/stih407-clks.h   |  4 ++
 5 files changed, 117 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/clk-always-on.txt
 create mode 100644 drivers/clk/clk-always-on.c

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/4] ARM: sti: stih407-family: Supply defines for CLOCKGEN A0

[Lee Jones]

There are 2 LMI clocks generated by CLOCKGEN A0.  We wish to control
them individually and need to use these indexes to do so.

Signed-off-by: Lee Jones 
---
 include/dt-bindings/clock/stih407-clks.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/dt-bindings/clock/stih407-clks.h 
b/include/dt-bindings/clock/stih407-clks.h
index 7af2b71..082edd9 100644
--- a/include/dt-bindings/clock/stih407-clks.h
+++ b/include/dt-bindings/clock/stih407-clks.h
@@ -5,6 +5,10 @@
 #ifndef _DT_BINDINGS_CLK_STIH407
 #define _DT_BINDINGS_CLK_STIH407
 
+/* CLOCKGEN A0 */
+#define CLK_IC_LMI00
+#define CLK_IC_LMI11
+
 /* CLOCKGEN C0 */
 #define CLK_ICN_GPU0
 #define CLK_FDMA   1
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 3/4] clk: Provide an always-on clock domain framework

[Lee Jones]

Lots of platforms contain clocks which if turned off would prove fatal.
The only way to recover is to restart the board(s).  This driver takes
references to clocks which are required to be always-on in order to
prevent the common clk framework from trying to turn them off during
the clk_disabled_unused() procedure.

Signed-off-by: Lee Jones 
---
 drivers/clk/Makefile|  1 +
 drivers/clk/clk-always-on.c | 62 +
 2 files changed, 63 insertions(+)
 create mode 100644 drivers/clk/clk-always-on.c

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index d478ceb..0d42541 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_HAVE_CLK)  += clk-devres.o
 obj-$(CONFIG_CLKDEV_LOOKUP)+= clkdev.o
 obj-$(CONFIG_COMMON_CLK)   += clk.o
 obj-$(CONFIG_COMMON_CLK)   += clk-divider.o
+obj-$(CONFIG_COMMON_CLK)   += clk-always-on.o
 obj-$(CONFIG_COMMON_CLK)   += clk-fixed-factor.o
 obj-$(CONFIG_COMMON_CLK)   += clk-fixed-rate.o
 obj-$(CONFIG_COMMON_CLK)   += clk-gate.o
diff --git a/drivers/clk/clk-always-on.c b/drivers/clk/clk-always-on.c
new file mode 100644
index 000..f3d90ac
--- /dev/null
+++ b/drivers/clk/clk-always-on.c
@@ -0,0 +1,62 @@
+/*
+ * Always-on Clock Domain
+ *
+ * Copyright (C) 2015 STMicroelectronics – All Rights Reserved
+ *
+ * Author: Lee Jones 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static void ao_clock_domain_hog_clock(struct platform_device *pdev, int index)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct clk *clk;
+   int ret;
+
+   clk = of_clk_get(np, index);
+   if (IS_ERR(clk)) {
+   dev_warn(&pdev->dev, "Failed get clock %s[%d]: %li\n",
+np->full_name, index, PTR_ERR(clk));
+   return;
+   }
+
+   ret = clk_prepare_enable(clk);
+   if (ret)
+   dev_warn(&pdev->dev, "Failed to enable clock: %s\n", 
__clk_get_name(clk));
+}
+
+static int ao_clock_domain_probe(struct platform_device *pdev)
+{
+   struct device_node *np = pdev->dev.of_node;
+   int nclks, i;
+
+   nclks = of_count_phandle_with_args(np, "clocks", "#clock-cells");
+
+   for (i = 0; i < nclks; i++)
+   ao_clock_domain_hog_clock(pdev, i);
+
+   return 0;
+}
+
+static const struct of_device_id ao_clock_domain_match[] = {
+   { .compatible = "clk-always-on" },
+   { },
+};
+
+static struct platform_driver ao_clock_domain_driver = {
+   .probe = ao_clock_domain_probe,
+   .driver = {
+   .name = "clk-always-on",
+   .of_match_table = ao_clock_domain_match,
+   },
+};
+module_platform_driver(ao_clock_domain_driver);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/4] ARM: sti: stih407-family: Add platform interconnects to always-on clk domain

[Lee Jones]

Certain clocks should not be turned of by clk_disable_unused.  Until
now we have been using the kernel command-line of the same name to
prevent common clk from turning off all clocks without a reference,
as this would ensure hardware lockup.  This patch lists each
platform interconnect which needs to stay on to prevent the
aforementioned issue from arising.

Signed-off-by: Lee Jones 
---
 arch/arm/boot/dts/stih407-family.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index c06a546..35c74c6 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -34,6 +34,21 @@
reg = <0x08761000 0x1000>, <0x08760100 0x100>;
};
 
+   /*
+* ICNs are not visible/controllable in Linux, but references to their
+* clocks must be obtained and retained or the platform will become
+* irrecoverably unresponsive.
+*/
+   icn {
+   compatible = "clk-always-on";
+   clocks = <&clk_s_c0_flexgen CLK_ICN_SBC>,
+<&clk_s_c0_flexgen CLK_ICN_CPU>,
+<&clk_s_c0_flexgen CLK_ICN_LMI>,
+<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
+<&clk_s_a0_flexgen CLK_IC_LMI0>,
+<&clk_s_c0_flexgen CLK_EXT2F_A9>;
+   };
+
scu@0876 {
compatible = "arm,cortex-a9-scu";
reg = <0x0876 0x1000>;
-- 
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 v3 4/4] clk: dt: Introduce always-on clock domain documentation

[Lee Jones]

Signed-off-by: Lee Jones 
---
 .../devicetree/bindings/clock/clk-always-on.txt| 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/clk-always-on.txt

diff --git a/Documentation/devicetree/bindings/clock/clk-always-on.txt 
b/Documentation/devicetree/bindings/clock/clk-always-on.txt
new file mode 100644
index 000..d61eaca
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-always-on.txt
@@ -0,0 +1,35 @@
+Always-on Clock Domain
+
+Some hardware contains bunches of clocks which must never be turned
+off.  If drivers a) fail to obtain a reference to any of these or b)
+give up a previously obtained reference during suspend, the common clk
+framework will attempt to disable them and the hardware can fail
+irrecoverably.  Usually the only way to recover from these failures is
+to restart.
+
+To avoid either of these two scenarios from catastrophically disabling
+an otherwise perfectly healthy running system, an always-on clock
+domain has been provided.  In this implementation clocks are consumed
+and references are taken, thus preventing them from being shut down by
+the framework.
+
+This binding is not to be abused.  It is only to be used to protect
+platforms from being crippled by gated clocks, not as a convenience
+function to avoid using clk_disable_unused.
+
+We use the generic clock bindings found in:
+  Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : Must be "clk-always-on"
+
+Example:
+
+icn {
+   compatible = "clk-always-on";
+   clocks = <&clk_s_c0_flexgen CLK_ICN_SBC>,
+<&clk_s_c0_flexgen CLK_ICN_LMI>,
+<&clk_s_c0_flexgen CLK_ICN_CPU>,
+<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
+<&clk_s_a0_flexgen CLK_IC_LMI0>,
+};
-- 
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: perf: Add support for Scorpion PMUs

[Ashwin Chaugule]

On 20 February 2015 at 15:16, Stephen Boyd  wrote:
> On 02/20, Will Deacon wrote:
>> On Fri, Feb 13, 2015 at 06:24:09PM +, Stephen Boyd wrote:
>>
>> > +static void scorpion_evt_setup(int idx, u32 config_base)
>> > +{
>> > +   u32 val;
>> > +   u32 mask;
>> > +   u32 vval, fval;
>> > +   unsigned int region;
>> > +   unsigned int group;
>> > +   unsigned int code;
>> > +   unsigned int group_shift;
>> > +   bool venum_event;
>> > +
>> > +   krait_decode_event(config_base, ®ion, &group, &code, 
>> > &venum_event,
>> > +  NULL);
>> > +
>> > +   group_shift = group * 8;
>> > +   mask = 0xff << group_shift;
>> > +
>> > +   /* Configure evtsel for the region and group */
>> > +   if (venum_event)
>> > +   val = SCORPION_VLPM_GROUP0;
>> > +   else
>> > +   val = scorpion_get_pmresrn_event(region);
>> > +   val += group;
>> > +   /* Mix in mode-exclusion bits */
>> > +   val |= config_base & (ARMV7_EXCLUDE_USER | ARMV7_EXCLUDE_PL1);
>> > +   armv7_pmnc_write_evtsel(idx, val);
>> > +
>> > +   asm volatile("mcr p15, 0, %0, c9, c15, 0" : : "r" (0));
>>
>> What's this guy doing?
>
> This is the same as Krait. It's clearing some implementation
> defined register. From what I can tell it's a per-event register
> (i.e. PMSELR decides which event this register write actually
> affects) and we do this here to reset this register to some
> defined value, zero. Otherwise the reset value of this register
> is UNPREDICTABLE and that would be bad. I think we might be able
> to move it to the pmu reset path, but I don't know. Ashwin?

Will have to check once I get to office tomorrow.
--
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] spi: qup: Add DMA capabilities

[Ivan T. Ivanov]

Hi Stan, 

Sorry I didn't saw this first look.

On Tue, 2015-02-24 at 15:00 +0200, Stanimir Varbanov wrote:



> 
> +static bool spi_qup_can_dma(struct spi_master *master, struct spi_device 
> *spi,
> +   struct spi_transfer 
> *xfer)
> +{
> +   struct spi_qup *qup = spi_master_get_devdata(master);
> +   size_t dma_align = dma_get_cache_alignment();
> +   int n_words, w_size;
> +
> +   qup->dma_available = 0;
> +
> +   if (xfer->rx_buf && xfer->len % qup->in_blk_sz)
> +   return false;
> +
> +   if (xfer->tx_buf && xfer->len % qup->out_blk_sz)
> +   return false;
> +

Actually we can end up here with tx_buf or rx_buf to be NULL.
Which voids my previous comments about these pointers.

It will be simpler if you just check transfer length.

And better return false if both are NULL.

> +   if (IS_ERR_OR_NULL(master->dma_rx) || IS_ERR_OR_NULL(master->dma_tx))
> +   return false;
> +
> +   if (!IS_ALIGNED((size_t)xfer->tx_buf, dma_align) ||
> +   !IS_ALIGNED((size_t)xfer->rx_buf, 
> dma_align))
> +   return false;

Testing NULL for alignment is fine, right?

> +   w_size = spi_qup_get_word_sz(xfer);
> +   n_words = xfer->len / w_size;
> +
> +   /* will use fifo mode */
> +   if (n_words <= (qup->in_fifo_sz / sizeof(u32)))
> +   return false;
> +
> +   qup->dma_available = 1;
> +
> +   return true;
> +}
> +

Regards,
Ivan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] OPP: Redefine bindings to overcome shortcomings

[Kevin Hilman]

Viresh Kumar  writes:

> On 24 February 2015 at 04:06, Kevin Hilman  wrote:
>> Viresh Kumar  writes:
>
>>> +Optional properties:
>>> +- shared-opp: Indicates that device nodes using this OPP descriptor's 
>>> phandle
>>> +  switch their DVFS state together, i.e. they share clock lines.
>>
>> ... or shared voltage rail?
>
> The point is that they switch their frequencies together. Which means,
> sharing voltage rail + PLLs .. How do we write it properly ?

s/they share clock lines/they share clock and/or voltage lines/

>>> +  Missing property means devices have independent clock lines, but they 
>>> share OPPs.
>>
>> huh?  missing 'shared-opp' property means they share OPPs?  -ECONFUSED.
>
> Right. s/OPPs/OPP tables ..
>
> Makes sense now ?

Yes.

>> Maybe I missed some of the discussion of why this property is needed,
>> but I'm left wondering why it's needed explicitly.  With the OPPs as
>
> So that same OPP tables can be shared across CPUs which don't share
> voltage rails..  For example, Krait. We only need to define single set
> of tables and all CPUs will point to it. But this property would be
> missing in that case as CPUs don't change their DVFS state together.


>> part of the CPU nodes, shouldnt' the "shared" nature of the OPP be
>> easily derived from the clock and or regulator (opp-supply) property of
>> the CPU nodes?  IOW, if two CPU nodes share a clock and/or a regulator,
>> the framework should know it's "shared".
>
> So you missed all earlier discussions :), there were lots of concerns
> around that.  And the best solution we found out is to do it this
> way..
>
> - There can be multiple clocks/regulators present in CPU's DT node and
> that makes it complex.
>
> - There are cases where immediate clock parents of CPUs are different
> but somewhere higher in the hierarchy they have a common ancestor,
> which is responsible for rate change. And so it would be difficult to
> find out if they share clock/regulator or not..
>
> - People wanted it to be some static data instead of trying to find
> with help of some algorithms..

OK, fair enough.  Looks like it's been thought through.  

However, in the end, I don't think it's going to avoid the "help of some
algorithms."  The flag will tell you it's shared, but not how, and that
will likely still need to be determined.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/6] dmaengine: omap-dma: Remove mapping between virtual channels and requests

[Peter Ujfalusi]

On 02/24/2015 04:28 PM, Russell King - ARM Linux wrote:
> On Tue, Feb 24, 2015 at 04:21:22PM +0200, Peter Ujfalusi wrote:
>> Do not direct map the virtual channels to sDMA request number. When the
>> sDMA is behind of a crossbar this direct mapping can cause situations when
>> certain channel can not be requested since the crossbar request number
>> will no longer match with the sDMA request line.
>> The direct mapping for virtual channels with HW request lines will make it
>> harder to implement MEM_TO_MEM mode for the driver.
> 
> I assume when you talk about MEM_TO_MEM, you're referring to a DMA_MEMCPY
> driver.
> 
> mem2mem should not be handled by the slave driver.  This should be a
> separate DMA engine driver structure which does not have DMA_SLAVE set.
> 
> See how amba-pl08x handles this.

Thanks for the pointer. I'm just planning to add the DMA_MEMCPY support for
omap-dma. With that in place we can convert the remaining legacy API users to
use dmaengine (as I recall all of them are using DMA for memcopy)

-- 
Péter
--
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 net-next v4 0/3] Linn Ethernet Packet Sniffer driver

[Stathis Voukelatos]

This patch adds support for the Ethernet Packet Sniffer H/W module
developed by Linn Products Ltd and found in the IMG Pistachio SoC.
The module allows Ethernet packets to be parsed, matched against
a user-defined pattern and timestamped. It sits between a 100M
Ethernet MAC and PHY and is completely passive with respect to
Ethernet frames.

Selected packet bytes from matched packets and timestamp values are
returned through a H/W FIFO. Timestamps are provided to the module
through an externally generated Gray-encoded counter.

The command string for packet matching is stored in module RAM
and consists of a sequence of 16-bit entries. Each entry includes
an 8-bit command code and and 8-bit data value. Valid command
codes are:
0 - Don't care
1 - Match: packet data must match command string byte
2 - Copy: packet data will be copied to FIFO
3 - Match/Stamp: if packet data matches string byte, a timestamp
 is copied into the FIFO
4 - Copy/Done: packet data will be copied into the FIFO.
   This command terminates the command string.

The driver consists of two modules:
- Core: it provides a common framework for managing backend packet
sniffer implementations. Each backend channel is registered
by the core as a netdev, which can be accessed from user
space through AF_PACKET sockets. 

- Ethernet Packet Sniffer backend: provides the driver for the
Linn Ethernet Packet Sniffer H/W modules.

The split between a core and backend modules allows for other
implementations to be added in the future apart of the Ethernet
packet sniffer presented in this patch set.

Changelog:

v4:
* More detailed documentation on driver usage (in snf_core.c) and 
  H/W operation (in platform.c)
* Some source file renaming in the core module.
* Rebased against linux-net-next

v3:
* Code moved into vendor specific directory
* Device tree binding updated and streamlined. Cyclecounter params
  are now calculated dynamically.

v2:
* Complete redesign of core framework to use netdev instead of 
the generic netlink framework
* Updated device tree binding
* A number of minor code improvements suggested by code review

Stathis Voukelatos (3):
  Linn Ethernet packet sniffer: device tree binding and vendor prefix
  Linn packet sniffer core framework
  Linn Ethernet packet sniffer driver

 .../bindings/net/linn-ether-packet-sniffer.txt |  39 ++
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 MAINTAINERS|   6 +
 drivers/net/ethernet/Kconfig   |   1 +
 drivers/net/ethernet/Makefile  |   1 +
 drivers/net/ethernet/linn/Kconfig  |  36 ++
 drivers/net/ethernet/linn/Makefile |  20 +
 .../linn/pkt-sniffer/backends/ether/Makefile   |  20 +
 .../linn/pkt-sniffer/backends/ether/channel.c  | 444 +
 .../linn/pkt-sniffer/backends/ether/channel.h  |  80 
 .../ethernet/linn/pkt-sniffer/backends/ether/hw.h  |  46 +++
 .../linn/pkt-sniffer/backends/ether/platform.c | 318 +++
 .../net/ethernet/linn/pkt-sniffer/core/Makefile|  19 +
 .../net/ethernet/linn/pkt-sniffer/core/snf_core.c  | 344 
 .../net/ethernet/linn/pkt-sniffer/core/snf_core.h  |  60 +++
 15 files changed, 1435 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt
 create mode 100644 drivers/net/ethernet/linn/Kconfig
 create mode 100644 drivers/net/ethernet/linn/Makefile
 create mode 100644 
drivers/net/ethernet/linn/pkt-sniffer/backends/ether/Makefile
 create mode 100644 
drivers/net/ethernet/linn/pkt-sniffer/backends/ether/channel.c
 create mode 100644 
drivers/net/ethernet/linn/pkt-sniffer/backends/ether/channel.h
 create mode 100644 drivers/net/ethernet/linn/pkt-sniffer/backends/ether/hw.h
 create mode 100644 
drivers/net/ethernet/linn/pkt-sniffer/backends/ether/platform.c
 create mode 100644 drivers/net/ethernet/linn/pkt-sniffer/core/Makefile
 create mode 100644 drivers/net/ethernet/linn/pkt-sniffer/core/snf_core.c
 create mode 100644 drivers/net/ethernet/linn/pkt-sniffer/core/snf_core.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 net-next v4 2/3] Linn packet sniffer core framework

[Stathis Voukelatos]

The framework registers each backend sniffer channel as a netdev,
which can be accessed from user space through a raw packet socket.
Packets received from user space are treated as a command string
configuration. Each match event from the backend driver will
generate a packet with the matching bytes plus an optional
timestamp, if configured by the command string.

Signed-off-by: Stathis Voukelatos 
---
 MAINTAINERS|   6 +
 drivers/net/ethernet/Kconfig   |   1 +
 drivers/net/ethernet/Makefile  |   1 +
 drivers/net/ethernet/linn/Kconfig  |  25 ++
 drivers/net/ethernet/linn/Makefile |  19 ++
 .../net/ethernet/linn/pkt-sniffer/core/Makefile|  19 ++
 .../net/ethernet/linn/pkt-sniffer/core/snf_core.c  | 344 +
 .../net/ethernet/linn/pkt-sniffer/core/snf_core.h  |  60 
 8 files changed, 475 insertions(+)
 create mode 100644 drivers/net/ethernet/linn/Kconfig
 create mode 100644 drivers/net/ethernet/linn/Makefile
 create mode 100644 drivers/net/ethernet/linn/pkt-sniffer/core/Makefile
 create mode 100644 drivers/net/ethernet/linn/pkt-sniffer/core/snf_core.c
 create mode 100644 drivers/net/ethernet/linn/pkt-sniffer/core/snf_core.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 0597c5b..6186c0c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5828,6 +5828,12 @@ M:   Sasha Levin 
 S: Maintained
 F: tools/lib/lockdep/
 
+LINN PACKET SNIFFER DRIVER
+M: Stathis Voukelatos 
+S: Maintained
+F: drivers/net/ethernet/linn/
+F: Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt
+
 LINUX FOR IBM pSERIES (RS/6000)
 M: Paul Mackerras 
 W: http://www.ibm.com/linux/ltc/projects/ppc
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index eadcb05..ee4b3ed 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -103,6 +103,7 @@ config LANTIQ_ETOP
---help---
  Support for the MII0 inside the Lantiq SoC
 
+source "drivers/net/ethernet/linn/Kconfig"
 source "drivers/net/ethernet/marvell/Kconfig"
 source "drivers/net/ethernet/mellanox/Kconfig"
 source "drivers/net/ethernet/micrel/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index 1367afc..f8071d3 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_NET_VENDOR_HP) += hp/
 obj-$(CONFIG_NET_VENDOR_IBM) += ibm/
 obj-$(CONFIG_NET_VENDOR_INTEL) += intel/
 obj-$(CONFIG_NET_VENDOR_I825XX) += i825xx/
+obj-$(CONFIG_NET_VENDOR_LINN) += linn/
 obj-$(CONFIG_NET_VENDOR_XSCALE) += xscale/
 obj-$(CONFIG_IP1000) += icplus/
 obj-$(CONFIG_JME) += jme.o
diff --git a/drivers/net/ethernet/linn/Kconfig 
b/drivers/net/ethernet/linn/Kconfig
new file mode 100644
index 000..6654f4e
--- /dev/null
+++ b/drivers/net/ethernet/linn/Kconfig
@@ -0,0 +1,25 @@
+#
+# Linn device configuration
+#
+
+config NET_VENDOR_LINN
+   bool "Linn devices"
+   ---help---
+ Say Y to add support for Linn Products devices.
+
+ Note that the answer to this question doesn't directly affect the
+ kernel: saying N will just cause the configurator to skip all
+ the questions about Linn devices. If you say Y, you will be asked for
+ your specific device in the following questions.
+
+if NET_VENDOR_LINN
+
+menuconfig PKT_SNIFFER
+tristate "Packet sniffer support"
+---help---
+Say Y to add support for the packet sniffer driver framework.
+
+The core driver can also be built as a module. If so, the module
+will be called snf_core.
+
+endif # NET_VENDOR_LINN
diff --git a/drivers/net/ethernet/linn/Makefile 
b/drivers/net/ethernet/linn/Makefile
new file mode 100644
index 000..f3338f3
--- /dev/null
+++ b/drivers/net/ethernet/linn/Makefile
@@ -0,0 +1,19 @@
+###
+# Makefile for the Linn Products device drivers
+#
+# Copyright (C) 2015 Linn Products Ltd
+#
+# 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.
+#
+# Written by:
+# Stathis Voukelatos 
+###
+
+obj-$(CONFIG_PKT_SNIFFER) += pkt-sniffer/core/
diff --git a/drivers/net/ethernet/linn/pkt-sniffer/core/Makefile 
b/drivers/net/ethernet/linn/pkt-sniffer/core/Makefile
new file mode 100644
index 000..4dc8f11
--- /dev/null
+++ b/drivers/net/ethernet/linn/pkt-sniffer/core/Makefile
@@ -0,0 +1,19 @@
+###
+

[PATCH net-next v4 1/3] Linn Ethernet packet sniffer: device tree binding and vendor prefix

[Stathis Voukelatos]

Signed-off-by: Stathis Voukelatos 
---
 .../bindings/net/linn-ether-packet-sniffer.txt | 39 ++
 .../devicetree/bindings/vendor-prefixes.txt|  1 +
 2 files changed, 40 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt

diff --git 
a/Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt 
b/Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt
new file mode 100644
index 000..66bfc48
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/linn-ether-packet-sniffer.txt
@@ -0,0 +1,39 @@
+* Linn Products Ethernet Packet Sniffer
+The module allows Ethernet packets to be parsed, matched against
+a user-defined pattern and timestamped. It sits between a 100M
+Ethernet MAC and PHY and is completely passive with respect to
+Ethernet frames.
+Matched packet bytes and timestamp values are returned through a
+FIFO. Timestamps are provided to the module through an externally
+generated Gray-encoded counter.
+
+Required properties:
+- compatible : must be "linn,eth-packet-sniffer"
+- reg : a list of physical address and size pairs corresponding to
+   each entry in 'reg-names'
+- reg-names : must contain:
+   "regs"   : control registers
+   "tx-ram" : TX command string memory
+   "rx-ram" : RX command string memory
+- interrupts : sniffer interrupt specifier
+- clocks : list of clocks corresponding to each entry in 'clock-names'
+- clock-names : must contain:
+   "sys": system clock for the peripheral
+   "tstamp" : timestamp counter clock
+- fifo-block-words : number of words in one data FIFO entry
+- tstamp-bits : width in bits of the timestamp counter
+
+Example:
+
+sniffer@1814a000 {
+   compatible = "linn,eth-sniffer";
+   reg = <0x1814a000 0x100>, <0x1814a400 0x400>,
+ <0x1814a800 0x400>;
+   reg-names = "regs", "tx-ram", "rx-ram";
+   interrupts = ;
+   clocks = <&cr_periph SYS_CLK_ENET>,
+<&clk_core CLK_AUDIO>;
+   clock-names = "sys", "tstamp";
+   fifo-block-words = <4>;
+   tstamp-bits = <30>;
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 389ca13..f685707 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -102,6 +102,7 @@ lacie   LaCie
 lantiq Lantiq Semiconductor
 lenovo Lenovo Group Ltd.
 lg LG Corporation
+linn   Linn Products Ltd.
 linux  Linux-specific binding
 lsiLSI Corp. (LSI Logic)
 lltc   Linear Technology Corporation
-- 
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 net-next v4 3/3] Linn Ethernet packet sniffer driver

[Stathis Voukelatos]

Driver for the Ethernet Mii packet sniffer H/W module found in
the IMG Pistachio SoC.

Signed-off-by: Stathis Voukelatos 
---
 drivers/net/ethernet/linn/Kconfig  |  11 +
 drivers/net/ethernet/linn/Makefile |   1 +
 .../linn/pkt-sniffer/backends/ether/Makefile   |  20 +
 .../linn/pkt-sniffer/backends/ether/channel.c  | 444 +
 .../linn/pkt-sniffer/backends/ether/channel.h  |  80 
 .../ethernet/linn/pkt-sniffer/backends/ether/hw.h  |  46 +++
 .../linn/pkt-sniffer/backends/ether/platform.c | 318 +++
 7 files changed, 920 insertions(+)
 create mode 100644 
drivers/net/ethernet/linn/pkt-sniffer/backends/ether/Makefile
 create mode 100644 
drivers/net/ethernet/linn/pkt-sniffer/backends/ether/channel.c
 create mode 100644 
drivers/net/ethernet/linn/pkt-sniffer/backends/ether/channel.h
 create mode 100644 drivers/net/ethernet/linn/pkt-sniffer/backends/ether/hw.h
 create mode 100644 
drivers/net/ethernet/linn/pkt-sniffer/backends/ether/platform.c

diff --git a/drivers/net/ethernet/linn/Kconfig 
b/drivers/net/ethernet/linn/Kconfig
index 6654f4e..bbfd6a4 100644
--- a/drivers/net/ethernet/linn/Kconfig
+++ b/drivers/net/ethernet/linn/Kconfig
@@ -22,4 +22,15 @@ menuconfig PKT_SNIFFER
 The core driver can also be built as a module. If so, the module
 will be called snf_core.
 
+config PKT_SNIFFER_ETHER
+tristate "Ethernet packet sniffer"
+depends on PKT_SNIFFER
+help
+Say Y here if you want to use the Ethernet packet sniffer
+module by Linn Products Ltd. It can be found in the upcoming
+Pistachio SoC by Imagination Technologies.
+
+The driver can also be built as a module. If so, the module
+will be called snf_ether.
+
 endif # NET_VENDOR_LINN
diff --git a/drivers/net/ethernet/linn/Makefile 
b/drivers/net/ethernet/linn/Makefile
index f3338f3..f51eb66 100644
--- a/drivers/net/ethernet/linn/Makefile
+++ b/drivers/net/ethernet/linn/Makefile
@@ -17,3 +17,4 @@
 ###
 
 obj-$(CONFIG_PKT_SNIFFER) += pkt-sniffer/core/
+obj-$(CONFIG_PKT_SNIFFER_ETHER) += pkt-sniffer/backends/ether/
diff --git a/drivers/net/ethernet/linn/pkt-sniffer/backends/ether/Makefile 
b/drivers/net/ethernet/linn/pkt-sniffer/backends/ether/Makefile
new file mode 100644
index 000..1f97e51
--- /dev/null
+++ b/drivers/net/ethernet/linn/pkt-sniffer/backends/ether/Makefile
@@ -0,0 +1,20 @@
+###
+# Makefile for the Linn ethernet packet sniffer driver
+#
+# Copyright (C) 2015 Linn Products Ltd
+#
+# 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.
+#
+# Written by:
+# Stathis Voukelatos 
+###
+
+obj-$(CONFIG_PKT_SNIFFER_ETHER) += snf_ether.o
+snf_ether-objs := platform.o channel.o
diff --git a/drivers/net/ethernet/linn/pkt-sniffer/backends/ether/channel.c 
b/drivers/net/ethernet/linn/pkt-sniffer/backends/ether/channel.c
new file mode 100644
index 000..87ec790
--- /dev/null
+++ b/drivers/net/ethernet/linn/pkt-sniffer/backends/ether/channel.c
@@ -0,0 +1,444 @@
+/*
+ * Ethernet Mii packet sniffer driver
+ *  - channel functions
+ *
+ * Copyright (C) 2015 Linn Products Ltd
+ *
+ * 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.
+ *
+ * Written by:
+ * Stathis Voukelatos 
+ */
+#include 
+#include 
+#include 
+#include "../../core/snf_core.h"
+#include "hw.h"
+#include "channel.h"
+
+#define to_ether_snf_chan(dev) container_of(dev, struct ether_snf_chan, chan)
+
+#define CMD_DONTCARE   0
+#define CMD_MATCH  1
+#define CMD_COPY   2
+#define CMD_MATCHSTAMP 3
+#define CMD_COPYDONE   4
+
+/* Checks if the supplied command string is compatible with the
+ * capabilities of the H/W.
+ */
+static bool validate_pattern(
+   struct ether_snf_chan *ch,
+   const u8 *buf,
+   int count)
+{
+   int i, complete, max_copy_bytes;
+   int ts = 0;
+   int copy_before = 0;
+   int copy_after = 0;
+
+   if (count > ch->max_cmds)
+   return false;
+
+   /* I

Re: [PATCH 0/2] ARM: DRA7x/OMAP5: Clock: DPLL Clock fixes

[Tony Lindgren]

* Ravikumar Kattekola  [150219 08:13]:
> On 1/31/2015 10:36 PM, Ravikumar Kattekola wrote:
> >Fix bypass clock source for a few DPLLs.
> >
> >On DRA7x/OMAP5, for a few DPLLs, both CLKINP and CLKINPULOW are connected
> >to a mux and the output from mux is routed to the bypass clkout.
> >Add a mux-clock as bypass clock with CLKINP and CLKINPULOW as parents.
> >
> >Tested against:
> > tree: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
> > branch: master
> >On:
> >CPU  : OMAP5432 ES2.0
> >Board: OMAP5432 uEVM
> >and
> >CPU  : DRA752 ES1.0
> >Board: DRA7xx
> >
> >
> >Ravikumar Kattekola (2):
> >   ARM: DRA7x: dts: Fix the bypass clock source for dpll_iva and others
> >   ARM: OMAP5: dts: Fix the bypass clock source for dpll_iva and others
> >
> >  arch/arm/boot/dts/dra7xx-clocks.dtsi   |   90 
> > 
> >  arch/arm/boot/dts/omap54xx-clocks.dtsi |   41 +--
> >  2 files changed, 118 insertions(+), 13 deletions(-)
> >
> Hi Benoit,
> Can these fixes be looked into for 3.20-rc?

Seem like valid fixes to me. Tero, care to take a look at these and ack
if OK?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM64: Add new Xilinx ZynqMP SoC

[Rob Herring]

On Tue, Feb 24, 2015 at 8:58 AM, Michal Simek  wrote:
> On 02/24/2015 03:42 PM, Rob Herring wrote:
>> On Tue, Feb 24, 2015 at 1:56 AM, Michal Simek  
>> wrote:
>>> Initial version of device tree for Xilinx ZynqMP SoC.
>>>
>>> Signed-off-by: Michal Simek 
>>> Acked-by: Sören Brinkmann 
>>> ---
>>
>> [...]
>>
>>> +   gic: interrupt-controller@f901 {
>>> +   compatible = "arm,cortex-a15-gic", 
>>> "arm,cortex-a9-gic";
>>
>> gic-400, right?
>
> yep
>
>>
>>> +   #interrupt-cells = <3>;
>>> +   reg = <0x0 0xf901 0x1>,
>>> + <0x0 0xf902 0x2>,
>>> + <0x0 0xf904 0x2>,
>>> + <0x0 0xf906 0x2>;
>>
>> These addresses are wrong if you are doing address swizzling to do 64K
>> offsets. We don't really have an answer yet as to what is the right
>> way. See the XGene GIC discussion[1].
>
> Is this better for GICC?
> <0x0 0xf902f000 0x2000>

Yes, and the VCPU interface needs this as well. As far as sizes, we're
still discussing that.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: am335x-bone*: usb0 is hardwired for peripheral

[Felipe Balbi]

On Tue, Feb 24, 2015 at 10:10:43AM -0600, Robert Nelson wrote:
> Fixes: http://bugs.elinux.org/issues/127
> 
> the bb.org community was seeing random reboots before this change.
> 
> Signed-off-by: Robert Nelson 

that's a dead giveaway considering the connector in the board :-)

Thanks

Reviewed-by: Felipe Balbi 
Acked-by: Felipe Balbi 

> ---
>  arch/arm/boot/dts/am335x-bone-common.dtsi | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
> b/arch/arm/boot/dts/am335x-bone-common.dtsi
> index 6cc25ed..2c6248d 100644
> --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
> +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
> @@ -195,6 +195,7 @@
>  
>  &usb0 {
>   status = "okay";
> + dr_mode = "peripheral";
>  };
>  
>  &usb1 {
> -- 
> 2.1.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] ARM: dts: am335x-bone*: usb0 is hardwired for peripheral

[Robert Nelson]

On Tue, Feb 24, 2015 at 10:10 AM, Robert Nelson  wrote:
> Fixes: http://bugs.elinux.org/issues/127
>
> the bb.org community was seeing random reboots before this change.

Sorry.. ^ "beagleboard.org" i shouldn't use shorthand in mainline commits..

Regards,

-- 
Robert Nelson
http://www.rcn-ee.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

[PATCH] ARM: dts: am335x-bone*: usb0 is hardwired for peripheral

[Robert Nelson]

Fixes: http://bugs.elinux.org/issues/127

the bb.org community was seeing random reboots before this change.

Signed-off-by: Robert Nelson 
---
 arch/arm/boot/dts/am335x-bone-common.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 6cc25ed..2c6248d 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -195,6 +195,7 @@
 
 &usb0 {
status = "okay";
+   dr_mode = "peripheral";
 };
 
 &usb1 {
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] spi: qup: Add DMA capabilities

[Stanimir Varbanov]

On 02/24/2015 03:56 PM, Mark Brown wrote:
> On Tue, Feb 24, 2015 at 03:00:03PM +0200, Stanimir Varbanov wrote:
> 
>> +static void spi_qup_dma_done(void *data)
>> +{
>> +struct spi_qup *qup = data;
>> +
>> +if (atomic_dec_and_test(&qup->dma_outstanding))
>> +complete(&qup->done);
>> +}
> 
> I'm finding it hard to be thrilled about the use of atomics for
> synchronization (they're just generally hard to work with) and...
> 
>> +cookie = dmaengine_submit(desc);
>> +ret = dma_submit_error(cookie);
>> +if (ret)
>> +return ret;
> 
>> +atomic_inc(&qup->dma_outstanding);
> 
> ..don't we have two potential races here: one if somehow the DMA manages
> to complete prior to the atomic_inc() (unlikely but that's what race
> conditions are all about really) and one if we are issuing multiple DMAs
> and the early ones complete before the later ones are issued?
> 

yes, there is a potential race between atomic_inc and dma callback. I
reordered these calls to save few checks, and now it returns to me.

I imagine few options here:

 - reorder the dmaengine calls and atomic operations, i.e.
call atomic_inc for rx and tx channels before corresponding
dmaengine_submit and dmaengine_issue_pending.

 - have two different dma callbacks and two completions and waiting for
the two.

 - manage to receive only one dma callback, i.e. the last transfer in
case of presence of the rx_buf and tx_buf at the same time.

 - let me see for better solution.

Thanks for the comments.

regards,
Stan



--
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] spi: qup: Add DMA capabilities

[Ivan T. Ivanov]

Hi Stan,

On Tue, 2015-02-24 at 15:00 +0200, Stanimir Varbanov wrote:
> 



>  #define SPI_MAX_RATE   5000
> @@ -143,6 +147,11 @@ struct spi_qup {
> int tx_bytes;
> int rx_bytes;
> int qup_v1;
> +
> +   int dma_available;

This is more like 'use dma for this transfer", right?

> +   struct dma_slave_configrx_conf;
> +   struct dma_slave_configtx_conf;
> +   atomic_t  dma_outstanding;

Do we really need this one. See below.

>  };
> 



> +
> +static int spi_qup_prep_sg(struct spi_master *master, struct spi_transfer 
> *xfer,
> +   enum dma_transfer_direction 
> dir)
> +{
> +   struct spi_qup *qup = spi_master_get_devdata(master);
> +   unsigned long flags = DMA_PREP_INTERRUPT | DMA_PREP_FENCE;
> +   struct dma_async_tx_descriptor *desc;
> +   struct scatterlist *sgl;
> +   dma_cookie_t cookie;
> +   unsigned int nents;
> +   struct dma_chan *chan;
> +   int ret;
> +
> +   if (dir == DMA_MEM_TO_DEV) {
> +   chan = master->dma_tx;
> +   nents = xfer->tx_sg.nents;
> +   sgl = xfer->tx_sg.sgl;
> +   } else {
> +   chan = master->dma_rx;
> +   nents = xfer->rx_sg.nents;
> +   sgl = xfer->rx_sg.sgl;
> +   }
> +
> +   desc = dmaengine_prep_slave_sg(chan, sgl, nents, dir, flags);
> +   if (!desc)
> +   return -EINVAL;
> +
> +   desc->callback = spi_qup_dma_done;
> +   desc->callback_param = qup;

What if we attach callback only on RX descriptor and use
dmaengine_tx_status() for TX channel in wait for completion?

> +
> +   cookie = dmaengine_submit(desc);
> +   ret = dma_submit_error(cookie);
> +   if (ret)
> +   return ret;
> +
> +   atomic_inc(&qup->dma_outstanding);
> +
> +   return 0;
> +}
> +
> +static int spi_qup_do_dma(struct spi_master *master, struct spi_transfer 
> *xfer)
> +{
> +   struct spi_qup *qup = spi_master_get_devdata(master);
> +   int ret;
> +
> +   atomic_set(&qup->dma_outstanding, 0);
> +
> +   reinit_completion(&qup->done);

Redundant, already done in transfer_one().

> +
> +   if (xfer->rx_buf) {

Always true.

> +   ret = spi_qup_prep_sg(master, xfer, DMA_DEV_TO_MEM);
> +   if (ret)
> +   return ret;
> +
> +   dma_async_issue_pending(master->dma_rx);
> +   }
> +
> +   if (xfer->tx_buf) {

Same.

> 
+   ret = spi_qup_prep_sg(master, xfer, DMA_MEM_TO_DEV);
> +   if (ret)
> +   goto err_rx;
> +
> +   dma_async_issue_pending(master->dma_tx);
> +   }
> +
> +   ret = spi_qup_set_state(qup, QUP_STATE_RUN);
> +   if (ret) {
> +   dev_warn(qup->dev, "cannot set RUN state\n");
> +   goto err_tx;
> +   }
> +
> +   if (!wait_for_completion_timeout(&qup->done, msecs_to_jiffies(1000))) 
> {

transfer_one() calculates timeout dynamically based on transfer length.

Transition in state RUN and wait for completion are already coded in 
transfer_one().
With little rearrangement they could be removed from here.

> +   ret = -ETIMEDOUT;
> +   goto err_tx;
> +   }
> +
> +   return 0;
> +
> +err_tx:
> +   if (xfer->tx_buf)

Always true.

> +   dmaengine_terminate_all(master->dma_tx);
> +err_rx:
> +   if (xfer->rx_buf)
> 

Same.

> +   dmaengine_terminate_all(master->dma_rx);
> +
> +   return ret;
> +}

I don't see reason for this function, based on comments so far :-).



> 
> @@ -621,10 +881,16 @@ static int spi_qup_probe(struct platform_device *pdev)
> writel_relaxed(0, base + SPI_CONFIG);
> writel_relaxed(SPI_IO_C_NO_TRI_STATE, base + SPI_IO_CONTROL);
> 
> +   ret = spi_qup_init_dma(master, res->start);
> +   if (ret == -EPROBE_DEFER)
> +   goto error;

Better move resource allocation before touching hardware.

Otherwise is looking good and I know that is working :-)

Regards,
Ivan



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm64: Add L2 cache topology to ARM Ltd boards/models

[Sudeep Holla]

Hi Arnd,

On 21/01/15 14:43, Arnd Bergmann wrote:

On Wednesday 21 January 2015 12:02:30 Sudeep Holla wrote:


Hi Arnd/Olof,

Though this patch and commit 5d425c18653731af6 ("arm64: kernel: add
support for cpu cache information") which is in -next(via arm64) are
dependent to provide desired functionality, then can go indepedently
if you think there could be conflicts if this change is taken via arm64.
If not, Catalin can pick up with your acks after the review.


I think it would be better to take this through arm-soc. It's not
extremely likely to cause conflicts, but as you say there are no
strict dependencies on which goes in first, so there is no harm
in merging them separately.



I think this patch got missed for -rc1. The arm64 architectural
support patch for cacheinfo got merged via arm64 tree. It would be good
if this is also merged so that cache information can be exposed
to the user-space on ARM Ltd boards.

Regards,
Sudeep

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM64: Add new Xilinx ZynqMP SoC

[Michal Simek]

On 02/24/2015 03:42 PM, Rob Herring wrote:
> On Tue, Feb 24, 2015 at 1:56 AM, Michal Simek  wrote:
>> Initial version of device tree for Xilinx ZynqMP SoC.
>>
>> Signed-off-by: Michal Simek 
>> Acked-by: Sören Brinkmann 
>> ---
> 
> [...]
> 
>> +   gic: interrupt-controller@f901 {
>> +   compatible = "arm,cortex-a15-gic", 
>> "arm,cortex-a9-gic";
> 
> gic-400, right?

yep

> 
>> +   #interrupt-cells = <3>;
>> +   reg = <0x0 0xf901 0x1>,
>> + <0x0 0xf902 0x2>,
>> + <0x0 0xf904 0x2>,
>> + <0x0 0xf906 0x2>;
> 
> These addresses are wrong if you are doing address swizzling to do 64K
> offsets. We don't really have an answer yet as to what is the right
> way. See the XGene GIC discussion[1].

Is this better for GICC?
<0x0 0xf902f000 0x2000>

Thanks,
Michal
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM64: Add new Xilinx ZynqMP SoC

[Rob Herring]

On Tue, Feb 24, 2015 at 1:56 AM, Michal Simek  wrote:
> Initial version of device tree for Xilinx ZynqMP SoC.
>
> Signed-off-by: Michal Simek 
> Acked-by: Sören Brinkmann 
> ---

[...]

> +   gic: interrupt-controller@f901 {
> +   compatible = "arm,cortex-a15-gic", 
> "arm,cortex-a9-gic";

gic-400, right?

> +   #interrupt-cells = <3>;
> +   reg = <0x0 0xf901 0x1>,
> + <0x0 0xf902 0x2>,
> + <0x0 0xf904 0x2>,
> + <0x0 0xf906 0x2>;

These addresses are wrong if you are doing address swizzling to do 64K
offsets. We don't really have an answer yet as to what is the right
way. See the XGene GIC discussion[1].

Rob

[1] https://www.mail-archive.com/devicetree@vger.kernel.org/msg62547.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 0/2] Add R8A7794 GPIO DT support

[Sergei Shtylyov]

Hello.

On 02/24/2015 02:19 AM, Simon Horman wrote:


Here's the set of 2 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20150220-v3.19' tag. Here we add the GPIO device tree support
for the R8A7794 SoC. It depends on the R8A7794 PFC/MMCIF device tree patches
posted recently in order to apply.



[1/2] ARM: shmobile: r8a7794: add GPIO clocks
[2/2] ARM: shmobile: r8a7794: add GPIO DT support



Thanks,  I have queued these up with Geert's Acks.



Sorry, I was too hasty again. I have dropped these pending the
dependencies being queued up.


   Ah, I just didn't mention that the PFC patch is necessary for the latter 
patch to compile (but I don't expect it to change, so IMHO you can apply the 
PFC patch now). The former patch still can be merged, I think.


WBR, Sergei

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm64: dts: Fix GIC reg sizes for APM X-Gene

[Rob Herring]

On Tue, Feb 24, 2015 at 12:34 AM, Pranavkumar Sawargaonkar
 wrote:
> Hi Rob,
>
> On Mon, Feb 23, 2015 at 10:09 PM, Rob Herring  wrote:
>> On Mon, Feb 23, 2015 at 6:07 AM, Christoffer Dall
>>  wrote:
>>> On Sat, Feb 21, 2015 at 03:56:17PM -0600, Rob Herring wrote:
 On Thu, Feb 19, 2015 at 1:03 PM, Christoffer Dall
  wrote:
 > On Thu, Feb 19, 2015 at 12:23:15PM -0600, Rob Herring wrote:
 >> On Tue, Jan 27, 2015 at 1:03 AM, Pranavkumar Sawargaonkar
 >>  wrote:
 >> > In APM X-Gene, GIC register space is 64K aligned while the sizes 
 >> > mentioned
 >> > in the dt are 4K aligned. This breaks KVM when kernel is built with 
 >> > 64K page
 >> > size due to size alignment checking in vgic driver for VCPU Control 
 >> > and
 >> > VCPU register.
 >> >
 >> > This patch corrects the sizes to be inline with the hardware spec.
 >>
 >> This does not make sense. The GIC regions are still only 4 or 8KB and
 >> the h/w description should reflect that. For implementations using
 >> gic-400 and the addressing decode trick, the rest of the register
 >> range is also not safe to access given it is multiple mapped. Also,
 >> this wastes virtual space, but I guess we don't care on 64-bit.
 >>
 >> KVM should be fixed to only check base address alignment. Size
 >> alignment does not matter (if it does, then you need to fix all
 >> register blocks).
 >>
 > It matters if you want to ensure that the 64K page you are assigning to
 > a guest for the GIC virtual CPU interface contains only GIC virtual CPU
 > mappings, and not other random stuff that the guest is not allowed to
 > touch.

 Good point.

 > How else should this be enforced?

 Rely on correct h/w design? You'll have to repeat this every time you
 want to do pass-thru of a device.

 What do you do if 64K mapping is not supported? Fallback to emulation
 of the CPU interface?
>>>
>>> Agree with Peter on these two points.
>>>

 Are there other DTSs that need to be fixed?

>>> Not sure really, AMD Seattle works with 64K pages IIRC.
>>
>> Well, looks we have been inconsistent here:
>>
>> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi-   reg = <0x0
>> 0xe111 0 0x1000>,
>> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0
>> 0xe112f000 0 0x2000>,
>> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0
>> 0xe114 0 0x1>,
>> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi- <0x0
>> 0xe116 0 0x1>;
>>
>> arch/arm64/boot/dts/arm/juno.dts-   reg = <0x0 0x2c01 0 
>> 0x1000>,
>> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c02f000 0 
>> 0x2000>,
>> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c04f000 0 
>> 0x2000>,
>> arch/arm64/boot/dts/arm/juno.dts- <0x0 0x2c06f000 0 
>> 0x2000>;
>>
>> If we are going to use 64K sizes, can we have some consistency here
>> please. Which ranges really need 64KB sizes? It should only be the
>> VCPU interface. right? Why does XGene need 128K? If XGene is doing
>> address swizzling, then the CPU and VCPU base addresses are wrong.
>> Seattle is also wrong for the VCPU, but no one has noticed because we
>> don't use the DIR register IIRC.
>>
>> XGene should also add an "arm,gic-400" compatible string or something
>> XGene specific if in fact it is not GIC-400.
>
> X-Gene has gic-400 as an interrupt controller.
> Only thing is GIC pages are mapped at 64K boundary (with 64K page size)
> Hence CPU, VCPU interfaces has a size of 128K (2GIC pages)
> Regarding GICC_DIR, yes there is a problem which needs to be solved
> since the first page size is 64K.
> In XEN we already have a small fix to access GICC_DIR with 64K page
> offset instead of standard 4K.

Right, and in order for this to work, you should use the last 4K alias
for the cpu interface(s). This is why other platforms use xxxf000 as
their cpu interface base.

It is of course possible that xgene does not properly do the address
swizzling and therefore you have to use 64K aligned addresses. But in
that case you need a unique compatible string.

> I remember a small discussion in this regard in past
> (http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266468.html)
> which was deferred at that time.
> Once this patch is accepted we can post RFC patch to address GICC_DIR
> and discuss further.

No, let's get this right now and not keep changing the dts.

Rob

>
>>
>> I think perhaps we need a specific compatible property to indicate a
>> GIC-400 with address swizzling. While we could get away with using the
>> aliased addresses, that seems to be hard to get right and we may
>> regret not doing it in the long term. It would indicate at least it is
>> 64K page safe for example.
>>
>> Rob
>
> Thanks,
> Pranav
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a messa

Re: [PATCH 2/4] i2c: sunxi: Add Reduced Serial Bus (RSB) DT bindings documentation

[Chen-Yu Tsai]

On Tue, Feb 24, 2015 at 10:17 PM, Arnd Bergmann  wrote:
> On Tuesday 24 February 2015 22:01:26 Chen-Yu Tsai wrote:
>> On Tue, Feb 24, 2015 at 6:37 PM, Arnd Bergmann  wrote:
>> > On Tuesday 24 February 2015 18:29:02 Chen-Yu Tsai wrote:
>> >>
>> >> +   rsb@01f03400 {
>> >> +   compatible = "allwinner,sun8i-a23-rsb";
>> >> +   reg = <0x01f03400 0x400>;
>> >> +   interrupts = <0 39 4>;
>> >> +   clocks = <&apb0_gates 3>;
>> >> +   clock-frequency = <300>;
>> >> +   resets = <&apb0_rst 3>;
>> >> +
>> >> +   axp223: pmic@2d {
>> >> +   compatible = "x-powers,axp223", "x-powers,axp221";
>> >> +   reg = <0x2d>;
>> >> +   allwinner,rsb-hw-addr = <0x3e3>;
>> >> +
>> >> +   /* ... */
>> >> +   };
>> >> +   };
>>
>> > I don't really understand the need for having two addresses (runtime
>> > and hardware). Could the runtime address be configured at runtime?
>>
>> You can, though the driver doesn't support this. I don't think the
>> I2C subsystem allows arbitrary device insertion during normal
>> operation, but maybe i2c-dev? I've tried using different addresses
>> for devices so they do get changed during the probe phase, just
>> to be sure that the code works, and it's not just sitting at
>> the address the bootloader used.
>>
>> In any case, the distinction is more like burnt-in or hardwired
>> addresses vs software configurable addresses.
>
> The simplest binding would the probably be to only put the
> hardware address into the 'reg' property and always assign the
> logical addresses dynamically.
>
> Would that add a lot of complexity or does it have any other
> downsides?

The hardware address is 12 bits wide. Any address higher than
0x3ff will be rejected by the I2C core. The AC100 is at 0xe89.

Assigning addresses dynamically means the driver has to keep
a lookup table to map the hardware address to the logical
address to issue the command to.

There's also the issue of dynamically assigned address colliding
with unlisted devices, though I think this would only happen in
the development / bring up phase of the device.

I think the first issue pretty much rules out putting the
hardware address into 'reg'.

Putting the logical address in the 'reg' property allows the
user to poke unlisted devices using i2c-tools, though this
is not so useful to the average user.


Regards,
ChenYu
--
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 4/6] dmaengine: omap-dma: Take DMA request number from DT if it is available

[Peter Ujfalusi]

On 02/24/2015 04:25 PM, Russell King - ARM Linux wrote:
> On Tue, Feb 24, 2015 at 04:21:21PM +0200, Peter Ujfalusi wrote:
>> Use the dma-requests property from DT to get the number of DMA requests.
>> In case of legacy boot or failure to find the property, use the default
>> 127 as number of requests.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  drivers/dma/omap-dma.c | 11 ++-
>>  1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
>> index 56c33e93dd24..7def31c919f4 100644
>> --- a/drivers/dma/omap-dma.c
>> +++ b/drivers/dma/omap-dma.c
>> @@ -34,6 +34,7 @@ struct omap_dmadev {
>>  const struct omap_dma_reg *reg_map;
>>  struct omap_system_dma_plat_info *plat;
>>  bool legacy;
>> +unsigned dma_requests;
>>  spinlock_t irq_lock;
>>  uint32_t irq_enable_mask;
>>  struct omap_chan *lch_map[OMAP_SDMA_CHANNELS];
>> @@ -1118,7 +1119,15 @@ static int omap_dma_probe(struct platform_device 
>> *pdev)
>>  
>>  tasklet_init(&od->task, omap_dma_sched, (unsigned long)od);
>>  
>> -for (i = 0; i < OMAP_SDMA_REQUESTS; i++) {
>> +if (!pdev->dev.of_node || of_property_read_u32(pdev->dev.of_node,
>> +   "dma-requests",
>> +   &od->dma_requests)) {
>> +dev_info(&pdev->dev,
>> + "DMA request lines not specified, using 127\n");
>> +od->dma_requests = 127;
> 
> What happened to OMAP_SDMA_REQUESTS?
> 
> If you're not going to use OMAP_SDMA_REQUESTS, then don't add it.  If
> you are going to use it, please also change the dev_info() line to use
> that macro too.

Aargh, yes you are right. Will fix this up in v2.

-- 
Péter
--
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 5/6] dmaengine: omap-dma: Remove mapping between virtual channels and requests

[Russell King - ARM Linux]

On Tue, Feb 24, 2015 at 04:21:22PM +0200, Peter Ujfalusi wrote:
> Do not direct map the virtual channels to sDMA request number. When the
> sDMA is behind of a crossbar this direct mapping can cause situations when
> certain channel can not be requested since the crossbar request number
> will no longer match with the sDMA request line.
> The direct mapping for virtual channels with HW request lines will make it
> harder to implement MEM_TO_MEM mode for the driver.

I assume when you talk about MEM_TO_MEM, you're referring to a DMA_MEMCPY
driver.

mem2mem should not be handled by the slave driver.  This should be a
separate DMA engine driver structure which does not have DMA_SLAVE set.

See how amba-pl08x handles this.

-- 
FTTC broadband for 0.8mile line: currently at 10.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