Re: [PATCH v2 2/4] dmaengine: Add STM32 DMA driver

[Daniel Thompson]

On 14/10/15 14:41, M'boumba Cedric Madianga wrote:

2015-10-14 15:29 GMT+02:00 Daniel Thompson :

On 14/10/15 14:17, M'boumba Cedric Madianga wrote:


Hi Daniel,


+
+static int stm32_dma_remove(struct platform_device *pdev)
+{
+   struct stm32_dma_device *dmadev = platform_get_drvdata(pdev);
+
+   of_dma_controller_free(pdev->dev.of_node);
+
+   dma_async_device_unregister(>ddev);
+
+   clk_disable_unprepare(dmadev->clk);




What is the purpose of disabling/unpreparing the clock here?
stm32_dma_alloc_chan_resources() and stm32_dma_free_chan_resources()
should
pair up and the clock should already be stopped.



stm32_dma_remove() could be called during an on-going transfer during
module unload.
So in that case, it seems that disabling/unpreparing the clock is needed.



Really?

I think we need to be sure any on-going transfers are stopped.

There are multiple reasons for this, not least the risk of executing a
callback that has been freed, but the one related to my point is that a
single clk_disable_unprepare() will remain broken because if you don't know
that the transfers have stopped then you don't know how many on-going
transfers there are.


In the next version, I am going to stop the DMA, free all interrupts
and kill tasklet in stm32_dma_remove.
In that way, all on-going transfers will be lost as we don't have to
wait the end of remaining transfer in order to execute this function
as quickly as possible.


Hmnnn...

The dmaengine framework will WARN_ONCE() if an dmaengine is removed 
whilst it is active and also works hard to ensure dmaengine modules are 
not removed whilst there are active drivers using the framework.


How do we get into this function whilst there is still an active DMA 
channels?




But even with this improvement, I think I have to disable the clock here.


As above, I think the dmaengine framework work to protect you from this 
sort problem. However even if I am wrong about that then unconditionally 
calling clk_disable_unprepare() can not be used to reliably manage the 
clocks. You don't know what the counts are!



Daniel.
--
To unsubscribe from this list: send the line "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/3] extcon: arizona: Add extcon specific device tree binding document

[Charles Keepax]

Signed-off-by: Charles Keepax 
---
 .../devicetree/bindings/extcon/extcon-arizona.txt  |   15 +++
 MAINTAINERS|1 +
 2 files changed, 16 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-arizona.txt

diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt 
b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
new file mode 100644
index 000..e1705fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
@@ -0,0 +1,15 @@
+Cirrus Logic Arizona class audio SoCs
+
+These devices are audio SoCs with extensive digital capabilities and a range
+of analogue I/O.
+
+This document lists Extcon specific bindings, see the primary binding document:
+  ../mfd/arizona.txt
+
+Optional properties:
+
+  - wlf,hpdet-channel : Headphone detection channel.
+ARIZONA_ACCDET_MODE_HPL or 1 - Headphone detect mode is set to HPDETL
+ARIZONA_ACCDET_MODE_HPR or 2 - Headphone detect mode is set to HPDETR
+If this node is not mentioned or if the value is unknown, then
+headphone detection mode is set to HPDETL.
diff --git a/MAINTAINERS b/MAINTAINERS
index 9f6685f..08c804a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11393,6 +11393,7 @@ T:  git 
https://github.com/CirrusLogic/linux-drivers.git
 W: https://github.com/CirrusLogic/linux-drivers/wiki
 S: Supported
 F: Documentation/hwmon/wm83??
+F: Documentation/devicetree/bindings/extcon/extcon-arizona.txt
 F: arch/arm/mach-s3c64xx/mach-crag6410*
 F: drivers/clk/clk-wm83*.c
 F: drivers/extcon/extcon-arizona.c
-- 
1.7.2.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 2/3] regulator: arizona: Add regulator specific device tree binding document

[Charles Keepax]

Signed-off-by: Charles Keepax 
---
 .../bindings/regulator/arizona-regulator.txt   |   34 
 MAINTAINERS|1 +
 2 files changed, 35 insertions(+), 0 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/arizona-regulator.txt

diff --git a/Documentation/devicetree/bindings/regulator/arizona-regulator.txt 
b/Documentation/devicetree/bindings/regulator/arizona-regulator.txt
new file mode 100644
index 000..25bb7f3
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/arizona-regulator.txt
@@ -0,0 +1,34 @@
+Cirrus Logic Arizona class audio SoCs
+
+These devices are audio SoCs with extensive digital capabilities and a range
+of analogue I/O.
+
+This document lists regulator specific bindings, see the primary binding
+document:
+  ../mfd/arizona.txt
+
+Required properties:
+
+  - AVDD-supply, DBVDD1-supply, CPVDD-supply : Power supplies for the device,
+as covered in regulator.txt
+
+  - DBVDD2-supply, DBVDD3-supply : Additional databus power supplies (wm5102,
+wm5110, wm8280, wm8998, wm1814)
+
+  - SPKVDDL-supply, SPKVDDR-supply : Speaker driver power supplies (wm5102,
+wm5110, wm8280, wm8998, wm1814)
+
+  - SPKVDD-supply : Speaker driver power supply (wm8997)
+
+Optional properties:
+  - wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
+
+  - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if
+they are being externally supplied. As covered in
+Documentation/devicetree/bindings/regulator/regulator.txt
+
+Optional subnodes:
+  - ldo1 : Initial data for the LDO1 regulator, as covered in
+Documentation/devicetree/bindings/regulator/regulator.txt
+  - micvdd : Initial data for the MICVDD regulator, as covered in
+Documentation/devicetree/bindings/regulator/regulator.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index 08c804a..f353491 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11394,6 +11394,7 @@ W:  
https://github.com/CirrusLogic/linux-drivers/wiki
 S: Supported
 F: Documentation/hwmon/wm83??
 F: Documentation/devicetree/bindings/extcon/extcon-arizona.txt
+F: Documentation/devicetree/bindings/regulator/arizona-regulator.txt
 F: arch/arm/mach-s3c64xx/mach-crag6410*
 F: drivers/clk/clk-wm83*.c
 F: drivers/extcon/extcon-arizona.c
-- 
1.7.2.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 3/3] mfd: arizona: Remove bindings covered in new subsystem specific docs

[Charles Keepax]

Binding documentation has been added in new subsystem specific binding
documents. This patch removes the now duplicate documentation from the
MFD documentation. Also whilst we are at it add a missing maintainers
entry for the MFD binding document.

Signed-off-by: Charles Keepax 
---
 Documentation/devicetree/bindings/mfd/arizona.txt |   30 ++--
 MAINTAINERS   |1 +
 2 files changed, 4 insertions(+), 27 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
b/Documentation/devicetree/bindings/mfd/arizona.txt
index a8fee60..077c4fe 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -30,21 +30,9 @@ Required properties:
   - #gpio-cells : Must be 2. The first cell is the pin number and the
 second cell is used to specify optional parameters (currently unused).
 
-  - AVDD-supply, DBVDD1-supply, CPVDD-supply : Power supplies for the device,
-as covered in Documentation/devicetree/bindings/regulator/regulator.txt
-
-  - DBVDD2-supply, DBVDD3-supply : Additional databus power supplies (wm5102,
-wm5110, wm8280, wm8998, wm1814)
-
-  - SPKVDDL-supply, SPKVDDR-supply : Speaker driver power supplies (wm5102,
-wm5110, wm8280, wm8998, wm1814)
-
-  - SPKVDD-supply : Speaker driver power supply (wm8997)
-
 Optional properties:
 
   - wlf,reset : GPIO specifier for the GPIO controlling /RESET
-  - wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
 
   - wlf,gpio-defaults : A list of GPIO configuration register values. Defines
 for the appropriate values can found in . If
@@ -67,21 +55,9 @@ Optional properties:
 present, the number of values should be less than or equal to the
 number of inputs, unspecified inputs will use the chip default.
 
-  - wlf,hpdet-channel : Headphone detection channel.
-ARIZONA_ACCDET_MODE_HPL or 1 - Headphone detect mode is set to HPDETL
-ARIZONA_ACCDET_MODE_HPR or 2 - Headphone detect mode is set to HPDETR
-If this node is not mentioned or if the value is unknown, then
-headphone detection mode is set to HPDETL.
-
-  - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if
-they are being externally supplied. As covered in
-Documentation/devicetree/bindings/regulator/regulator.txt
-
-Optional subnodes:
-  - ldo1 : Initial data for the LDO1 regulator, as covered in
-Documentation/devicetree/bindings/regulator/regulator.txt
-  - micvdd : Initial data for the MICVDD regulator, as covered in
-Documentation/devicetree/bindings/regulator/regulator.txt
+Also see child specific device properties:
+  Regulator - ../regulator/arizona-regulator.txt
+  Extcon- ../extcon/extcon-arizona.txt
 
 Example:
 
diff --git a/MAINTAINERS b/MAINTAINERS
index f353491..544c747 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11395,6 +11395,7 @@ S:  Supported
 F: Documentation/hwmon/wm83??
 F: Documentation/devicetree/bindings/extcon/extcon-arizona.txt
 F: Documentation/devicetree/bindings/regulator/arizona-regulator.txt
+F: Documentation/devicetree/bindings/mfd/arizona.txt
 F: arch/arm/mach-s3c64xx/mach-crag6410*
 F: drivers/clk/clk-wm83*.c
 F: drivers/extcon/extcon-arizona.c
-- 
1.7.2.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 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Franklin S Cooper Jr.]

On 10/14/2015 09:11 AM, Roger Quadros wrote:
> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>
>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>>> Franklin,
>>>
>>> On 14/10/15 14:36, Roger Quadros wrote:
 On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> Switch from dma_request_channel to allow passing dma channel
> information from DT rather than hardcoding a value.
>
> Signed-off-by: Franklin S Cooper Jr 
 Acked-by: Roger Quadros 

> ---
>  drivers/mtd/nand/omap2.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index d0f2620..957c32f 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device 
> *pdev)
>   dma_cap_zero(mask);
>   dma_cap_set(DMA_SLAVE, mask);
>   sig = OMAP24XX_DMA_GPMC;
> - info->dma = dma_request_channel(mask, omap_dma_filter_fn, );
> + info->dma = dma_request_slave_channel_compat(mask,
> + omap_dma_filter_fn, , pdev->dev.parent, "rxtx");
> +
>>> Just discovered that you are using the parent device node.
>>>
>>> How about moving the dma bindings to the nand node instead and using
>>> pdev->dev here?
>> Roger,
>>
>> From what I can tell the interrupt number and the dma channel will always be
>> the same no matter what. Doesn't matter if you have multiple nands or a
>> combination of nands and nors. Since that is the case I think it just makes
>> sense to leave it in the gpmc parent node and define it once.
> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
> or only for NAND?
The dma seems tied to the prefetch. From what I can tell the prefetch is only
used by nand.
>
> Let's also get Tony's inputs on this.
Sure.
>
>   if (!info->dma) {
>   dev_err(>dev, "DMA engine request failed\n");
>   err = -ENXIO;
>
> --
> cheers,
> -roger

--
To unsubscribe from this list: send the line "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 09/25] scsi: hisi_sas: add phy SAS ADDR initialization

[Arnd Bergmann]

On Wednesday 14 October 2015 16:05:21 John Garry wrote:
> 
> OK, we can look at adding the ability to read the SAS HBA address from a 
> FW image or EFI variables.
> 

The easiest way is usually to have a DT property that gets updated
by the firmware.

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

Re: [RFC 1/5] clk: iproc: define Broadcom NSP iProc clock binding

[Jon Mason]

On Tue, Oct 13, 2015 at 03:17:36PM -0700, Ray Jui wrote:
> Shouldn't the device tree binding document go with the other patch
> series since both the binding document and drivers are merged by Michael
> or Stephen?
> 
> On 10/13/2015 2:22 PM, Jon Mason wrote:
> > Document the device tree bindings for Broadcom Northstar Plus
> > architecture based clock controller
> > 
> > Signed-off-by: Jon Mason 
> > ---
> >  .../bindings/clock/brcm,iproc-clocks.txt   | 30 
> > ++
> >  1 file changed, 30 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt 
> > b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
> > index da8d9bb..b3c3e9d 100644
> > --- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
> > +++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
> > @@ -130,3 +130,33 @@ These clock IDs are defined in:
> >  ch3_unused mipipll  4   BCM_CYGNUS_MIPIPLL_CH3_UNUSED
> >  ch4_unused mipipll  5   BCM_CYGNUS_MIPIPLL_CH4_UNUSED
> >  ch5_unused mipipll  6   BCM_CYGNUS_MIPIPLL_CH5_UNUSED
> > +
> > +Northstar and Northstar Plus
> > +--
> > +PLL and leaf clock compatible strings for Northstar and Northstar Plus are:
> > + "brcm,nsp-armpll"
> > + "brcm,nsp-genpll"
> > + "brcm,nsp-lcpll0"
> 
> So the current clock driver also supports NS? That will be nice and that
> indicates all the clock related registers/offsets are exactly the same
> between NS and NSP?

Yes.  The register offsets are different, but everything else is
identical.

> 
> > +
> > +The following table defines the set of PLL/clock index and ID for 
> > Northstar and
> > +Northstar Plus.  These clock IDs are defined in:
> > +"include/dt-bindings/clock/bcm-nsp.h"
> > +
> > +Clock  Source  Index   ID
> > +----   -   -
> > +crystalN/A N/A N/A
> > +
> > +armpll crystal N/A N/A
> > +
> > +genpll crystal 0   BCM_NSP_GENPLL
> > +phygenpll  1   BCM_NSP_GENPLL_PHY_CLK
> > +ethernetclkgenpll  2   BCM_NSP_GENPLL_ENET_SW_CLK
> > +usbclk genpll  3   BCM_NSP_GENPLL_USB_PHY_REF_CLK
> > +iprocfast  genpll  4   BCM_NSP_GENPLL_IPROCFAST_CLK
> > +sata1  genpll  5   BCM_NSP_GENPLL_SATA1_CLK
> > +sata2  genpll  6   BCM_NSP_GENPLL_SATA2_CLK
> > +
> > +lcpll0 crystal 0   BCM_NSP_LCPLL0
> > +pcie_phy   lcpll0  1   BCM_NSP_LCPLL0_PCIE_PHY_REF_CLK
> > +sdio   lcpll0  2   BCM_NSP_LCPLL0_SDIO_CLK
> > +ddr_phylcpll0  3   BCM_NSP_LCPLL0_DDR_PHY_CLK
> > 
--
To unsubscribe from this list: send the line "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/3] ARM: dts: stm32f429: Adopt STM32 RNG driver

[Daniel Thompson]

New bindings and driver have been created for STM32 series parts. This
patch integrates this changes.

Signed-off-by: Daniel Thompson 
Acked-by: Maxime Coquelin 
---
 arch/arm/boot/dts/stm32f429.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index cb0613090243..90081fc22c6c 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -175,6 +175,13 @@
reg = <0x40023800 0x400>;
clocks = <_hse>;
};
+
+   rng: rng@50060800 {
+   compatible = "st,stm32-rng";
+   reg = <0x50060800 0x400>;
+   interrupts = <80>;
+   clocks = < 0 38>;
+   };
};
 };
 
-- 
2.4.3

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

[PATCH v4 0/3]

[Murali Karicheri]

This patch series enable accumulator queue support for K2 SoCs. Accumulator
queues are a type of qmss queue that is monitored by the PDSP firmware and
accumulated. Host is interrupted by PDSP firmware when packets become
available in a ring buffer shared between the host and PDSP.

There was an issue raised when merging the original patch set at
 (1) https://lkml.org/lkml/2015/9/4/681
[PATCH v1 1/2] soc: ti: display firmware file name as part of boot log
 (2) https://lkml.org/lkml/2015/9/4/680
[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels

This series fixes the issues raised against v3. Maintainer, could you please
apply this series to v4.4 next please at your earliest opportunity.

Change Log
==
v4
- collected Acked-by from Arnd Bergmann against 1/3
v3
- Added Arnd's Acked-by against 2/4
- 1/4 modified not to touch the DT documentation per Rob's comment.
- Removed DTS update from the series per Santosh. Will send the same
  as a separate patch
v2
- Remove the firmware filename from DT and add it to the driver.
  Use a name ks2_qmss_pdsp_acc48.bin. The idea is this can be a
  soft link pointing to the real firmware file in file system.

- Move the description of the driver design from DT document to one
  under Documentation/arm/keystone/knav-qmss.txt. Update the this
  document with location of acc firmware available under
  linux-firmware.git.

- Additionally added accumulator queue support optional so that lack
  of firmware in the file system will not cause other queue types not
  available due to driver probe failure.

Murali Karicheri (3):
  Documentation: dt: soc: Add description for knav qmss driver
  soc: ti: add firmware file name as part of the driver
  soc: ti: qmss: make acc queue support optional in the driver

 Documentation/arm/keystone/knav-qmss.txt   | 56 ++
 .../bindings/soc/ti/keystone-navigator-qmss.txt|  1 -
 drivers/soc/ti/knav_qmss.h |  3 +-
 drivers/soc/ti/knav_qmss_acc.c | 10 +++-
 drivers/soc/ti/knav_qmss_queue.c   | 67 ++
 5 files changed, 109 insertions(+), 28 deletions(-)
 create mode 100644 Documentation/arm/keystone/knav-qmss.txt

-- 
1.9.1

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

RE: [PATCH 1/3] phy: keystone: serdes driver for gbe 10gbe and pcie

[Kwok, WingMan]

Hello,

> -Original Message-
> From: KISHON VIJAY ABRAHAM
> Sent: Tuesday, October 13, 2015 6:58 PM
> To: Kwok, WingMan; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org;
> Quadros, Roger; Karicheri, Muralidharan; bhelg...@google.com;
> ssant...@kernel.org; li...@arm.linux.org.uk; devicetree@vger.kernel.org;
> linux-ker...@vger.kernel.org; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH 1/3] phy: keystone: serdes driver for gbe 10gbe and
> pcie
> 
> Hi,
> 
> On Tuesday 13 October 2015 11:34 PM, WingMan Kwok wrote:
> > On TI's Keystone platforms, several peripherals such as the
> > gbe ethernet switch, 10gbe ethernet switch and PCIe controller
> > require the use of a SerDes for converting SoC parallel data into
> > serialized data that can be output over a high-speed electrical
> > interface, and also converting high-speed serial input data
> > into parallel data that can be processed by the SoC.  The
> > SerDeses used by those peripherals, though they may be different,
> > are largely similar in functionality and setup.
> >
> > This patch provides a SerDes phy driver implementation that can be
> > used by the above mentioned peripheral drivers to configure their
> > respective SerDeses.
> >
> > Signed-off-by: WingMan Kwok 
> > ---
> >  Documentation/devicetree/bindings/phy/ti-phy.txt |  256 +++
> >  drivers/phy/Kconfig  |8 +
> >  drivers/phy/Makefile |1 +
> >  drivers/phy/phy-keystone-serdes.c| 2465
> ++
> >  4 files changed, 2730 insertions(+)
> >  create mode 100644 drivers/phy/phy-keystone-serdes.c
> >
> 
> 
> 
> > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> > index 47da573..8fc21a4 100644
> > --- a/drivers/phy/Kconfig
> > +++ b/drivers/phy/Kconfig
> > @@ -118,6 +118,14 @@ config PHY_RCAR_GEN2
> > help
> >   Support for USB PHY found on Renesas R-Car generation 2 SoCs.
> >
> > +config PHY_TI_KEYSTONE_SERDES
> > +   tristate "TI Keystone SerDes PHY support"
> > +   depends on OF && ARCH_KEYSTONE
> > +   select GENERIC_PHY
> > +   help
> > + This option enables support for TI Keystone SerDes PHY found
> > + in peripherals GBE, 10GBE and PCIe.
> > +
> >  config OMAP_CONTROL_PHY
> > tristate "OMAP CONTROL PHY Driver"
> > depends on ARCH_OMAP2PLUS || COMPILE_TEST
> > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> > index a5b18c1..8cb365b 100644
> > --- a/drivers/phy/Makefile
> > +++ b/drivers/phy/Makefile
> > @@ -46,3 +46,4 @@ obj-$(CONFIG_PHY_QCOM_UFS)+= phy-qcom-ufs-qmp-
> 14nm.o
> >  obj-$(CONFIG_PHY_TUSB1210) += phy-tusb1210.o
> >  obj-$(CONFIG_PHY_BRCMSTB_SATA) += phy-brcmstb-sata.o
> >  obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
> > +obj-$(CONFIG_PHY_TI_KEYSTONE_SERDES)   += phy-keystone-serdes.o
> > diff --git a/drivers/phy/phy-keystone-serdes.c b/drivers/phy/phy-
> keystone-serdes.c
> > new file mode 100644
> > index 000..c73d4de
> > --- /dev/null
> > +++ b/drivers/phy/phy-keystone-serdes.c
> > @@ -0,0 +1,2465 @@
> > +/*
> > + * Texas Instruments Keystone SerDes driver
> > + * Authors: WingMan Kwok 
> > + *
> > + * This is the SerDes Phy driver for Keystone devices. This is
> > + * required to support PCIe RC functionality based on designware
> > + * PCIe hardware, gbe and 10gbe found on these devices.
> > + *
> > + * Copyright (C) 2015 Texas Instruments Incorporated -
> http://www.ti.com/
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation 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.
> > + *
> > + * Copyright (C) 2015 Texas Instruments Incorporated -
> http://www.ti.com/
> > + *
> > + * 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 Texas Instruments Incorporated nor the names of
> > + * its contributors may be used to endorse or promote products derived
> > + * from this software without specific prior written permission.
> > + *

Re: [PATCH v2 2/4] dmaengine: Add STM32 DMA driver

[M'boumba Cedric Madianga]

2015-10-14 17:28 GMT+02:00 Daniel Thompson :
> On 14/10/15 16:26, M'boumba Cedric Madianga wrote:
>>
>> 2015-10-14 16:24 GMT+02:00 Daniel Thompson :
>>>
>>>
>>> Hmnnn...
>>>
>>> The dmaengine framework will WARN_ONCE() if an dmaengine is removed
>>> whilst
>>> it is active and also works hard to ensure dmaengine modules are not
>>> removed
>>> whilst there are active drivers using the framework.
>>>
>>> How do we get into this function whilst there is still an active DMA
>>> channels?
>>
>>
>> For example, when a user try "rmmod stm32-dma" in uart console.
>> It will enter in stm32_dma_remove while there is potentially still active
>> DMA.
>
>
> Check dmaengine.c for yourself but I think in this case the dmaengine
> framework will hold references to the module and prevent the remove from
> taking place.

Yes I did it.
As far I understand, the dmaengine framework will print a warning
message but doesn't stop removing operation if there are some active
clients.

Cedric.
--
To unsubscribe from this list: send the line "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/3] hwrng: stm32 - add support for STM32 HW RNG

[Daniel Thompson]

This patchset introduces a driver for the STM32 hardware random number
generator.

Herbert: I have assumed the v2 version is *so* badly broken (sorry
 again for that) that you would probably choose to remove v2
 completely and replace it with v3. In a moment I will also
 post a patch to fix the build without ripping out v2. Choose
 whichever suits you best.

v3:

 * Fixed build with CONFIG_PM (Fengguang Wu). Runtime tested as normal
   and also build tested on stm32 (which has CONFIG_PM set) and on
   x86/COMPILE_TEST with and without CONFIG_PM.

v2:

 * Moved binding docs from .../hwrng/ to .../rng/ and renamed to match
   convention in new directory (Rob Herring).
 * Adopted runtime PM and auto-suspend instead of managing the clocks
   from the read function (Linus Walleij). Increased bandwidth by ~30%.
 * Simplified error detection in main read loop (Linus Walleij, Maxime
   Coquelin).
 * Only WARN_ONCE() when hardware failure mechanisms trigger (Maxime
   Coquelin).
 * Simplify end of probe function after cocci warning (Fengguang Wu).
 * Switch to devm_hwrng_register.


Daniel Thompson (3):
  dt-bindings: Document the STM32 HW RNG bindings
  hwrng: stm32 - add support for STM32 HW RNG
  ARM: dts: stm32f429: Adopt STM32 RNG driver

 .../devicetree/bindings/rng/st,stm32-rng.txt   |  21 +++
 arch/arm/boot/dts/stm32f429.dtsi   |   7 +
 drivers/char/hw_random/Kconfig |  12 ++
 drivers/char/hw_random/Makefile|   1 +
 drivers/char/hw_random/stm32-rng.c | 202 +
 5 files changed, 243 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/st,stm32-rng.txt
 create mode 100644 drivers/char/hw_random/stm32-rng.c

--
2.4.3

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

[PATCH v3 1/3] dt-bindings: Document the STM32 HW RNG bindings

[Daniel Thompson]

This adds documentation of device tree bindings for the STM32 hardware
random number generator.

Signed-off-by: Daniel Thompson 
Acked-by: Maxime Coquelin 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/rng/st,stm32-rng.txt| 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/st,stm32-rng.txt

diff --git a/Documentation/devicetree/bindings/rng/st,stm32-rng.txt 
b/Documentation/devicetree/bindings/rng/st,stm32-rng.txt
new file mode 100644
index ..47f04176f93b
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/st,stm32-rng.txt
@@ -0,0 +1,21 @@
+STMicroelectronics STM32 HW RNG
+===
+
+The STM32 hardware random number generator is a simple fixed purpose IP and
+is fully separated from other crypto functions.
+
+Required properties:
+
+- compatible : Should be "st,stm32-rng"
+- reg : Should be register base and length as documented in the datasheet
+- interrupts : The designated IRQ line for the RNG
+- clocks : The clock needed to enable the RNG
+
+Example:
+
+   rng: rng@50060800 {
+   compatible = "st,stm32-rng";
+   reg = <0x50060800 0x400>;
+   interrupts = <80>;
+   clocks = < 0 38>;
+   };
-- 
2.4.3

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

Re: [PATCH 10/13] dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx

[Vinod Koul]

On Wed, Oct 14, 2015 at 04:12:21PM +0300, Peter Ujfalusi wrote:
> The DMA event crossbar on AM33xx/AM43xx is different from the one found in
> DRA7x family.
> Instead of a single event crossbar it has 64 identical mux attached to each
> eDMA event line. When the 0 event mux is selected, the default mapped event
> is going to be routed to the corresponding eDMA event line. If different
> mux is selected, then the selected event is going to be routed to the given
> eDMA event.

Why is crossbar patch in edma series?

> +static void ti_am335x_xbar_free(struct device *dev, void *route_data)
> +{
> + struct ti_am335x_xbar_data *xbar = dev_get_drvdata(dev);
> + struct ti_am335x_xbar_map *map = route_data;
> +
> + dev_err(dev, "Unmapping XBAR event %u on channel %u\n",
> + map->mux_val, map->dma_line);

Err ?

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

Re: [PATCH 0/3] hwrng: stm32 - add support for STM32 HW RNG

[Maxime Coquelin]

Herbert,

2015-10-14 16:28 GMT+02:00 Herbert Xu :
> On Mon, Oct 12, 2015 at 09:21:27AM +0100, Daniel Thompson wrote:
>> This patchset introduces a driver for the STM32 hardware random number
>> generator.
>>
>> v2:
>>
>>  * Moved binding docs from .../hwrng/ to .../rng/ and renamed to match
>>convention in new directory (Rob Herring).
>>  * Adopted runtime PM and auto-suspend instead of managing the clocks
>>from the read function (Linus Walleij). Increased bandwidth by ~30%.
>>  * Simplified error detection in main read loop (Linus Walleij, Maxime
>>Coquelin).
>>  * Only WARN_ONCE() when hardware failure mechanisms trigger (Maxime
>>Coquelin).
>>  * Simplify end of probe function after cocci warning (Fengguang Wu).
>>  * Switch to devm_hwrng_register.
>
> All applied.  Thanks!

I see you again have applied the DT patch like for STi three weeks ago.
The DT patch should go through the arm_soc tree to avoid Linus having
to handle conflicts resolution.

Can you please remove these two patches from your tree?
ba25d8b ARM: STi: STiH407: Enable the 2 HW Random Number Generators
for STiH4{07, 10}
b47c9fa ARM: dts: stm32f429: Adopt STM32 RNG driver

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

Re: [PATCH 1/2] ARM: dts: fix gpio-keys wakeup-source property

[Sudeep Holla]

Hi Linus,

On 13/10/15 14:32, Sudeep Holla wrote:

The keyboard driver for GPIO buttons(gpio-keys) checks for one of the
two boolean properties to enable gpio buttons as wakeup source:
1. "wakeup-source" or
2. the legacy "gpio-key,wakeup"

However juno, ste-snowball and emev2-kzm9d dts file have a undetected
"wakeup" property to indictate the wakeup source.

This patch fixes it by making use of "wakeup-source" property.

Cc: Simon Horman 
Cc: Magnus Damm 
Cc: Linus Walleij 


Please review this and provide ack if you are fine with the change for
ste-snowball. I can then ask arm-soc guys to pick this up as fix for v4.3

--
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 v2 2/4] dmaengine: Add STM32 DMA driver

[Daniel Thompson]

On 14/10/15 16:26, M'boumba Cedric Madianga wrote:

2015-10-14 16:24 GMT+02:00 Daniel Thompson :


Hmnnn...

The dmaengine framework will WARN_ONCE() if an dmaengine is removed whilst
it is active and also works hard to ensure dmaengine modules are not removed
whilst there are active drivers using the framework.

How do we get into this function whilst there is still an active DMA
channels?


For example, when a user try "rmmod stm32-dma" in uart console.
It will enter in stm32_dma_remove while there is potentially still active DMA.


Check dmaengine.c for yourself but I think in this case the dmaengine 
framework will hold references to the module and prevent the remove from 
taking place.



Daniel.
--
To unsubscribe from this list: send the line "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 20/27] ARM: dts: dra7: Fix NAND device nodes.

[Roger Quadros]

On 14/10/15 16:34, Franklin S Cooper Jr. wrote:
> 
> 
> On 09/18/2015 09:53 AM, Roger Quadros wrote:
>> Add compatible id, GPMC register resource and interrupt
>> resource to NAND controller nodes.
>>
>> The GPMC driver now implements gpiochip and irqchip so
>> enable gpio-controller and interrupt-controller properties.
>>
>> With this the interrupt parent of NAND node changes so fix it
>> accordingly.
>>
>> Signed-off-by: Roger Quadros 
>> ---
>>  arch/arm/boot/dts/dra7-evm.dts  | 5 -
>>  arch/arm/boot/dts/dra7.dtsi | 4 
>>  arch/arm/boot/dts/dra72-evm.dts | 5 -
>>  3 files changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
>> index a6c82e5..8a31161 100644
>> --- a/arch/arm/boot/dts/dra7-evm.dts
>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>> @@ -585,9 +585,12 @@
>>  status = "okay";
>>  pinctrl-names = "default";
>>  pinctrl-0 = <_flash_x16>;
>> -ranges = <0 0 0 0x0100>;/* minimum GPMC partition = 16MB */
>> +ranges = <0 0 0x0800 0x0100>;   /* minimum GPMC partition = 
>> 16MB */
>>  nand@0,0 {
>> +compatible = "ti,omap2-nand";
>>  reg = <0 0 4>;  /* device IO registers */
>> +interrupt-parent = <_mpu>;
>> +interrupts = ;
>>  ti,nand-ecc-opt = "bch8";
>>  ti,elm-id = <>;
>>  nand-bus-width = <16>;
>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>> index 5d65db9..f0a3616 100644
>> --- a/arch/arm/boot/dts/dra7.dtsi
>> +++ b/arch/arm/boot/dts/dra7.dtsi
>> @@ -1389,6 +1389,10 @@
>>  gpmc,num-waitpins = <2>;
>>  #address-cells = <2>;
>>  #size-cells = <1>;
>> +gpio-controller;
>> +#gpio-cells = <2>;
>> +interrupt-controller;
>> +#interrupt-cells = <2>;
>>  status = "disabled";
>>  };
> Based on the discussion on my patchset I noticed that the nand node defines 
> the
> interrupt but it is also defined in the parent node. Similar to the dma 
> channel we
> should conclude where the best place for it to be defined.  But to me it 
> seems at
> least it should only be defined once.

The interrupt is defined at both places because it is used at both places.
It is used as a shared interrupt. Wait_pin interrupts are managed by the
gpmc driver and NAND specific interrupts are managed by the NAND driver.

If GPMC dma channel is going to be used only by the NAND driver then
we should define the channel in the NAND node.

> 
> This is true for your other patches making similar changes to the dt.

Yes, GPMC IRQ is defined in both GPMC and NAND nodes.

--
cheers,
-roger
--
To unsubscribe from this list: send the line "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 4/5] clk: iproc: define Broadcom NS2 iProc clock binding

[Jon Mason]

On Tue, Oct 13, 2015 at 03:24:52PM -0700, Ray Jui wrote:
> Same as this patch. I thought device tree binding document should go
> with the clock driver changes.
> 
> Strictly speaking, device tree binding document should always go before
> the driver changes. In the binding document the DT interface is defined,
> then changes are implemented in the driver.

I split them off this way due to the clk maintainer not wanting to
pull in any device tree changes.  Since the documentation is for the
device tree enties, it makes logical sense to me that they be in the
same device tree series.  If Stephen will pull these in with the clk
changes, I am more than happy to have it done by him :)

Thanks,
Jon

> 
> Ray
> 
> On 10/13/2015 2:22 PM, Jon Mason wrote:
> > Document the device tree bindings for Broadcom Northstar 2 architecture
> > based clock controller
> > 
> > Signed-off-by: Jon Mason 
> > ---
> >  .../bindings/clock/brcm,iproc-clocks.txt   | 48 
> > ++
> >  1 file changed, 48 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt 
> > b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
> > index b3c3e9d..ede65a5 100644
> > --- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
> > +++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt
> > @@ -160,3 +160,51 @@ Northstar Plus.  These clock IDs are defined in:
> >  pcie_phy   lcpll0  1   BCM_NSP_LCPLL0_PCIE_PHY_REF_CLK
> >  sdio   lcpll0  2   BCM_NSP_LCPLL0_SDIO_CLK
> >  ddr_phylcpll0  3   BCM_NSP_LCPLL0_DDR_PHY_CLK
> > +
> > +Northstar 2
> > +---
> > +PLL and leaf clock compatible strings for Northstar 2 are:
> > +"brcm,ns2-genpll-scr"
> > +"brcm,ns2-genpll-sw"
> > +"brcm,ns2-lcpll-ddr"
> > +"brcm,ns2-lcpll-ports"
> > +
> > +The following table defines the set of PLL/clock index and ID for 
> > Northstar 2.
> > +These clock IDs are defined in:
> > +"include/dt-bindings/clock/bcm-ns2.h"
> > +
> > +Clock  Source  Index   ID
> > +----   -   -
> > +crystalN/A N/A N/A
> > +
> > +genpll_scr crystal 0   BCM_NS2_GENPLL_SCR
> > +scrgenpll_scr  1   BCM_NS2_GENPLL_SCR_SCR_CLK
> > +fs genpll_scr  2   BCM_NS2_GENPLL_SCR_FS_CLK
> > +audio_ref  genpll_scr  3   BCM_NS2_GENPLL_SCR_AUDIO_CLK
> > +ch3_unused genpll_scr  4   BCM_NS2_GENPLL_SCR_CH3_UNUSED
> > +ch4_unused genpll_scr  5   BCM_NS2_GENPLL_SCR_CH4_UNUSED
> > +ch5_unused genpll_scr  6   BCM_NS2_GENPLL_SCR_CH5_UNUSED
> > +
> > +genpll_sw  crystal 0   BCM_NS2_GENPLL_SW
> > +rpegenpll_sw   1   BCM_NS2_GENPLL_SW_RPE_CLK
> > +250genpll_sw   2   BCM_NS2_GENPLL_SW_250_CLK
> > +nicgenpll_sw   3   BCM_NS2_GENPLL_SW_NIC_CLK
> > +chimp  genpll_sw   4   BCM_NS2_GENPLL_SW_CHIMP_CLK
> > +port   genpll_sw   5   BCM_NS2_GENPLL_SW_PORT_CLK
> > +sdio   genpll_sw   6   BCM_NS2_GENPLL_SW_SDIO_CLK
> > +
> > +lcpll_ddr  crystal 0   BCM_NS2_LCPLL_DDR
> > +pcie_sata_usb lcpll_ddr1   
> > BCM_NS2_LCPLL_DDR_PCIE_SATA_USB_CLK
> > +ddrlcpll_ddr   2   BCM_NS2_LCPLL_DDR_DDR_CLK
> > +ch2_unused lcpll_ddr   3   BCM_NS2_LCPLL_DDR_CH2_UNUSED
> > +ch3_unused lcpll_ddr   4   BCM_NS2_LCPLL_DDR_CH3_UNUSED
> > +ch4_unused lcpll_ddr   5   BCM_NS2_LCPLL_DDR_CH4_UNUSED
> > +ch5_unused lcpll_ddr   6   BCM_NS2_LCPLL_DDR_CH5_UNUSED
> > +
> > +lcpll_portscrystal 0   BCM_NS2_LCPLL_PORTS
> > +wanlcpll_ports 1   BCM_NS2_LCPLL_PORTS_WAN_CLK
> > +rgmii  lcpll_ports 2   BCM_NS2_LCPLL_PORTS_RGMII_CLK
> > +ch2_unused lcpll_ports 3   BCM_NS2_LCPLL_PORTS_CH2_UNUSED
> > +ch3_unused lcpll_ports 4   BCM_NS2_LCPLL_PORTS_CH3_UNUSED
> > +ch4_unused lcpll_ports 5   BCM_NS2_LCPLL_PORTS_CH4_UNUSED
> > +ch5_unused lcpll_ports 6   BCM_NS2_LCPLL_PORTS_CH5_UNUSED
> > 
--
To unsubscribe from this list: send the line "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/3] hwrng: stm32 - add support for STM32 HW RNG

[Daniel Thompson]

Add support for STMicroelectronics STM32 random number generator.

The config value defaults to N, reflecting the fact that STM32 is a
very low resource microcontroller platform and unlikely to be targeted
by any "grown up" defconfigs.

Signed-off-by: Daniel Thompson 
Reviewed-by: Linus Walleij 
---
 drivers/char/hw_random/Kconfig |  12 +++
 drivers/char/hw_random/Makefile|   1 +
 drivers/char/hw_random/stm32-rng.c | 202 +
 3 files changed, 215 insertions(+)
 create mode 100644 drivers/char/hw_random/stm32-rng.c

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index f48cf11c655e..7930cc9b719c 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -359,6 +359,18 @@ config HW_RANDOM_XGENE
 
  If unsure, say Y.
 
+config HW_RANDOM_STM32
+   tristate "STMicroelectronics STM32 random number generator"
+   depends on HW_RANDOM && (ARCH_STM32 || COMPILE_TEST)
+   help
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on STM32 microcontrollers.
+
+ To compile this driver as a module, choose M here: the
+ module will be called stm32-rng.
+
+ If unsure, say N.
+
 endif # HW_RANDOM
 
 config UML_RANDOM
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 055bb01510ad..8b49c0f7abb1 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_HW_RANDOM_BCM2835) += bcm2835-rng.o
 obj-$(CONFIG_HW_RANDOM_IPROC_RNG200) += iproc-rng200.o
 obj-$(CONFIG_HW_RANDOM_MSM) += msm-rng.o
 obj-$(CONFIG_HW_RANDOM_XGENE) += xgene-rng.o
+obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
diff --git a/drivers/char/hw_random/stm32-rng.c 
b/drivers/char/hw_random/stm32-rng.c
new file mode 100644
index ..92a810648bd0
--- /dev/null
+++ b/drivers/char/hw_random/stm32-rng.c
@@ -0,0 +1,202 @@
+/*
+ * Copyright (c) 2015, Daniel Thompson
+ *
+ * This file 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.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RNG_CR 0x00
+#define RNG_CR_RNGEN BIT(2)
+
+#define RNG_SR 0x04
+#define RNG_SR_SEIS BIT(6)
+#define RNG_SR_CEIS BIT(5)
+#define RNG_SR_DRDY BIT(0)
+
+#define RNG_DR 0x08
+
+/*
+ * It takes 40 cycles @ 48MHz to generate each random number (e.g. <1us).
+ * At the time of writing STM32 parts max out at ~200MHz meaning a timeout
+ * of 500 leaves us a very comfortable margin for error. The loop to which
+ * the timeout applies takes at least 4 instructions per iteration so the
+ * timeout is enough to take us up to multi-GHz parts!
+ */
+#define RNG_TIMEOUT 500
+
+struct stm32_rng_private {
+   struct hwrng rng;
+   void __iomem *base;
+   struct clk *clk;
+};
+
+static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
+{
+   struct stm32_rng_private *priv =
+   container_of(rng, struct stm32_rng_private, rng);
+   u32 sr;
+   int retval = 0;
+
+   pm_runtime_get_sync((struct device *) priv->rng.priv);
+
+   while (max > sizeof(u32)) {
+   sr = readl_relaxed(priv->base + RNG_SR);
+   if (!sr && wait) {
+   unsigned int timeout = RNG_TIMEOUT;
+
+   do {
+   cpu_relax();
+   sr = readl_relaxed(priv->base + RNG_SR);
+   } while (!sr && --timeout);
+   }
+
+   /* If error detected or data not ready... */
+   if (sr != RNG_SR_DRDY)
+   break;
+
+   *(u32 *)data = readl_relaxed(priv->base + RNG_DR);
+
+   retval += sizeof(u32);
+   data += sizeof(u32);
+   max -= sizeof(u32);
+   }
+
+   if (WARN_ONCE(sr & (RNG_SR_SEIS | RNG_SR_CEIS),
+ "bad RNG status - %x\n", sr))
+   writel_relaxed(0, priv->base + RNG_SR);
+
+   pm_runtime_mark_last_busy((struct device *) priv->rng.priv);
+   pm_runtime_put_sync_autosuspend((struct device *) priv->rng.priv);
+
+   return retval || !wait ? retval : -EIO;
+}
+
+static int stm32_rng_init(struct hwrng *rng)
+{
+   struct stm32_rng_private *priv =
+   container_of(rng, struct stm32_rng_private, rng);
+   int err;
+
+   err = 

Re: [PATCH v4 02/11] phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC

[Alim Akhtar]

Hi,

On Wed, Oct 14, 2015 at 9:31 PM, Kishon Vijay Abraham I  wrote:
> Hi,
>
> On Wednesday 14 October 2015 06:25 PM, Alim Akhtar wrote:
>> From: Seungwon Jeon 
>>
>> This patch introduces Exynos UFS PHY driver. This driver
>> supports to deal with phy calibration and power control
>> according to UFS host driver's behavior.
>>
>> Signed-off-by: Seungwon Jeon 
>> Signed-off-by: Alim Akhtar 
>> Cc: Kishon Vijay Abraham I 
>> ---
>>  drivers/phy/Kconfig|7 +
>>  drivers/phy/Makefile   |1 +
>>  drivers/phy/phy-exynos-ufs.c   |  257 
>> 
>>  drivers/phy/phy-exynos-ufs.h   |   88 
>>  drivers/phy/phy-exynos7-ufs.h  |   89 +
>>  include/linux/phy/phy-exynos-ufs.h |  101 ++
>>  6 files changed, 543 insertions(+)
>>  create mode 100644 drivers/phy/phy-exynos-ufs.c
>>  create mode 100644 drivers/phy/phy-exynos-ufs.h
>>  create mode 100644 drivers/phy/phy-exynos7-ufs.h
>>  create mode 100644 include/linux/phy/phy-exynos-ufs.h
>>
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 47da573d0bab..499eec4a967c 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -371,4 +371,11 @@ config PHY_BRCMSTB_SATA
>> Enable this to support the SATA3 PHY on 28nm Broadcom STB SoCs.
>> Likely useful only with CONFIG_SATA_BRCMSTB enabled.
>>
>> +config PHY_EXYNOS_UFS
>> + tristate "EXYNOS SoC series UFS PHY driver"
>> + depends on OF && ARCH_EXYNOS || COMPILE_TEST
>> + select GENERIC_PHY
>> + help
>> +   Support for UFS PHY on Samsung EXYNOS chipsets.
>> +
>>  endmenu
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index a5b18c18fc12..2a312ca20795 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -46,3 +46,4 @@ obj-$(CONFIG_PHY_QCOM_UFS)  += phy-qcom-ufs-qmp-14nm.o
>>  obj-$(CONFIG_PHY_TUSB1210)   += phy-tusb1210.o
>>  obj-$(CONFIG_PHY_BRCMSTB_SATA)   += phy-brcmstb-sata.o
>>  obj-$(CONFIG_PHY_PISTACHIO_USB)  += phy-pistachio-usb.o
>> +obj-$(CONFIG_PHY_EXYNOS_UFS) += phy-exynos-ufs.o
>> diff --git a/drivers/phy/phy-exynos-ufs.c b/drivers/phy/phy-exynos-ufs.c
>> new file mode 100644
>> index ..77330b85e3f8
>> --- /dev/null
>> +++ b/drivers/phy/phy-exynos-ufs.c
>> @@ -0,0 +1,257 @@
>> +/*
>> + * UFS PHY driver for Samsung EXYNOS SoC
>> + *
>> + * Copyright (C) 2015 Samsung Electronics Co., Ltd.
>> + * Author: Seungwon Jeon 
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "phy-exynos-ufs.h"
>> +
>> +#define for_each_phy_lane(phy, i) \
>> + for (i = 0; i < (phy)->lane_cnt; i++)
>> +#define for_each_phy_cfg(cfg) \
>> + for (; (cfg)->id; (cfg)++)
>> +
>> +#define PHY_DEF_LANE_CNT 1
>> +
>> +static void exynos_ufs_phy_config(struct exynos_ufs_phy *phy,
>> + const struct exynos_ufs_phy_cfg *cfg, u8 lane)
>> +{
>> + enum {LANE_0, LANE_1}; /* lane index */
>> +
>> + switch (lane) {
>> + case LANE_0:
>> + writel(cfg->val, (phy)->reg_pma + cfg->off_0);
>> + break;
>> + case LANE_1:
>> + if (cfg->id == PHY_TRSV_BLK)
>> + writel(cfg->val, (phy)->reg_pma + cfg->off_1);
>> + break;
>> + }
>> +}
>> +
>> +static bool match_cfg_to_pwr_mode(u8 desc, u8 required_pwr)
>> +{
>> + if (IS_PWR_MODE_ANY(desc))
>> + return true;
>> +
>> + if (IS_PWR_MODE_HS(required_pwr) && IS_PWR_MODE_HS_ANY(desc))
>> + return true;
>> +
>> + if (COMP_PWR_MODE(required_pwr, desc))
>> + return true;
>> +
>> + if (COMP_PWR_MODE_MD(required_pwr, desc) &&
>> + COMP_PWR_MODE_GEAR(required_pwr, desc) &&
>> + COMP_PWR_MODE_SER(required_pwr, desc))
>> + return true;
>> +
>> + return false;
>> +}
>> +
>> +static int exynos_ufs_phy_calibrate(struct phy *phy,
>> + enum phy_cfg_tag tag, u8 pwr)
>> +{
>> + struct exynos_ufs_phy *ufs_phy = get_exynos_ufs_phy(phy);
>> + struct exynos_ufs_phy_cfg **cfgs = ufs_phy->cfg;
>> + const struct exynos_ufs_phy_cfg *cfg;
>> + int i;
>> +
>> + if (unlikely(tag < CFG_PRE_INIT || tag >= CFG_TAG_MAX)) {
>> + dev_err(ufs_phy->dev, "invalid phy config index %d\n", tag);
>> + return -EINVAL;
>> + }
>> +
>> + cfg = cfgs[tag];
>> + if (!cfg)
>> + goto out;
>> +
>> + 

[PATCH v4 1/3] Documentation: dt: soc: Add description for knav qmss driver

[Murali Karicheri]

Add a documentation for knav qmss driver.

Signed-off-by: Murali Karicheri 
---
 v4: added Arnd's Acked-by

 Documentation/arm/keystone/knav-qmss.txt | 24 
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/arm/keystone/knav-qmss.txt

diff --git a/Documentation/arm/keystone/knav-qmss.txt 
b/Documentation/arm/keystone/knav-qmss.txt
new file mode 100644
index 000..79946d1
--- /dev/null
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -0,0 +1,24 @@
+* Texas Instruments Keystone Navigator Queue Management SubSystem driver
+
+Driver source code path
+  drivers/soc/ti/knav_qmss.c
+  drivers/soc/ti/knav_qmss_acc.c
+
+The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
+the main hardware sub system which forms the backbone of the Keystone
+multi-core Navigator. QMSS consist of queue managers, packed-data structure
+processors(PDSP), linking RAM, descriptor pools and infrastructure
+Packet DMA.
+The Queue Manager is a hardware module that is responsible for accelerating
+management of the packet queues. Packets are queued/de-queued by writing or
+reading descriptor address to a particular memory mapped location. The PDSPs
+perform QMSS related functions like accumulation, QoS, or event management.
+Linking RAM registers are used to link the descriptors which are stored in
+descriptor RAM. Descriptor RAM is configurable as internal or external memory.
+The QMSS driver manages the PDSP setups, linking RAM regions,
+queue pool management (allocation, push, pop and notify) and descriptor
+pool management.
+
+knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
+allocate descriptor pools, map the descriptors, push/pop to queues etc. For
+details of the available APIs, please refers to 
include/linux/soc/ti/knav_qmss.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 v2 2/4] dmaengine: Add STM32 DMA driver

[Vinod Koul]

On Wed, Oct 14, 2015 at 03:07:16PM +0200, M'boumba Cedric Madianga wrote:
> >> +static inline uint32_t stm32_dma_read(struct stm32_dma_device *dmadev, 
> >> u32 reg)
> >
> > this and few other could be made more readable
> 
> Ok, I could replace uint32_t by u32. Is it what you expect ?
> For others, I don't see how I could make it more readable.
> Could you please give me more details to help me ? Thanks in advance

Yes that is one and also aplitting this up so that it fits within 80chars
while not sacrficing readablity...

> >> + } else if ((status & STM32_DMA_FEI) && (sfcr & STM32_DMA_SFCR_FEIE)) 
> >> {
> >> + dev_err(chan2dev(chan), "DMA error: received FEI event\n");
> >> + stm32_dma_irq_clear(chan, STM32_DMA_FEI);
> >> + chan->status = DMA_ERROR;
> >> + spin_unlock(>vchan.lock);
> >> + return IRQ_HANDLED;
> >
> > this is repeat of above apart from err print!!
> 
> Not only for print as we also need that to define which bit to clear
> in the IRQ status.
> In that way we will be sure to handle each interrupt event.

You can print error type based on status, or print the whole status but
handle it same for all three cases

> >> + enum dma_status status;
> >> + unsigned long flags;
> >> + unsigned int residue;
> >> +
> >> + status = dma_cookie_status(c, cookie, state);
> >> + if (status == DMA_COMPLETE)
> >> + return status;
> >> +
> >> + if (!state)
> >> + return chan->status;
> > why channel status and not status from dma_cookie_status()?
> 
> If status is different than DMA_COMPLETE it seems better to use channel 
> status.
> Indeed, in that way, we have the possibility to notify that there is a
> potential error in the bus via DMA_ERROR.
> But if I return status from dma_cookie_status(), I will always notify
> DMA_IN_PROGRESS.

No, you are supposed to return the descriptor status and not channel status!

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

Re: [PATCH 10/13] dmaengine: ti-dma-crossbar: Add support for crossbar on AM33xx/AM43xx

[Peter Ujfalusi]

On 10/14/2015 05:48 PM, Vinod Koul wrote:
> On Wed, Oct 14, 2015 at 04:12:21PM +0300, Peter Ujfalusi wrote:
>> The DMA event crossbar on AM33xx/AM43xx is different from the one found in
>> DRA7x family.
>> Instead of a single event crossbar it has 64 identical mux attached to each
>> eDMA event line. When the 0 event mux is selected, the default mapped event
>> is going to be routed to the corresponding eDMA event line. If different
>> mux is selected, then the selected event is going to be routed to the given
>> eDMA event.
> 
> Why is crossbar patch in edma series?

The old eDMA binding had xbar support which is not supported by the new
binding since it does not belong to the eDMA driver at all.
We have couple of boards where the crossbar is in use so I included the
crossbar support in this series.

>> +static void ti_am335x_xbar_free(struct device *dev, void *route_data)
>> +{
>> +struct ti_am335x_xbar_data *xbar = dev_get_drvdata(dev);
>> +struct ti_am335x_xbar_map *map = route_data;
>> +
>> +dev_err(dev, "Unmapping XBAR event %u on channel %u\n",
>> +map->mux_val, map->dma_line);
> 
> Err ?

Aargh, leftover from debugging.

-- 
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 2/2] dt-bindings: Add new boards to bcm4708 DT bindings

[Jon Mason]

On Tue, Oct 13, 2015 at 03:37:49PM -0700, Florian Fainelli wrote:
> On 13/10/15 14:40, Jon Mason wrote:
> > On Sat, Oct 10, 2015 at 04:42:04PM +0200, Hauke Mehrtens wrote:
> >> On 10/03/2015 12:22 AM, Jon Mason wrote:
> >>> Add the 4708, 4709, and 953012k SVKs to the the documentation for the
> >>> Broadcom Northstar device tree bindings.
> >>>
> >>> Signed-off-by: Jon Mason 
> >>> ---
> >>>  Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt | 7 +++
> >>>  1 file changed, 7 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt 
> >>> b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
> >>> index 6b0f49f..bdf4c06 100644
> >>> --- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
> >>> +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm4708.txt
> >>
> >> What should be documented in this file? This is more a question to the
> >> guys more familiar with arm in Linux. Currently the Linux kernel only
> >> supports brcm,bcm4708 and all goes back to that one.
> > 
> > I was under the impression that all boards should be added to these
> > files.  We have been doing so for Cygnus and NSP.
> 
> Tracking exactly which boards are supported by the brcm,bcm4708
> compatible string might be tedious, I tend to agree with just listing
> the supported SoCs, and leaving the specific board compatibles to the
> individual DTS files instead.

Ok, I'll simply add entries for NS and 4709 to this.

Thanks,
Jon 

> 
> > 
> > Thanks,
> > Jon
> > 
> >>
> >>> @@ -5,4 +5,11 @@ Boards with the BCM4708 SoC shall have the following 
> >>> properties:
> >>>  
> >>>  Required root node property:
> >>>  
> >>> +bcm94709
> >>>  compatible = "brcm,bcm4708";
> >>> +
> >>> +bcm94709
> >>> +compatible = "brcm,bcm4709", "brcm,bcm4708";
> >>> +
> >>> +bcm953012k
> >>> +compatible = "brcm,bcm5301k", "brcm,bcm4708";
> >>>
> >>
> 
> 
> -- 
> Florian
--
To unsubscribe from this list: send the line "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/3]

[santosh shilimkar]

10/14/2015 7:17 AM, Murali Karicheri wrote:

This patch series enable accumulator queue support for K2 SoCs. Accumulator
queues are a type of qmss queue that is monitored by the PDSP firmware and
accumulated. Host is interrupted by PDSP firmware when packets become
available in a ring buffer shared between the host and PDSP.

There was an issue raised when merging the original patch set at
  (1) https://lkml.org/lkml/2015/9/4/681
[PATCH v1 1/2] soc: ti: display firmware file name as part of boot log
  (2) https://lkml.org/lkml/2015/9/4/680
[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels

This series fixes the issues raised against v3. Maintainer, could you please
apply this series to v4.4 next please at your earliest opportunity.


I have picked up the series. Thanks for quick turnaround.

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

Re: [PATCH 1/2] ARM: dts: bcm5301x: Add BCM SVK DT files

[Jon Mason]

On Tue, Oct 13, 2015 at 03:43:20PM -0700, Ray Jui wrote:
> 
> 
> On 10/13/2015 2:38 PM, Jon Mason wrote:
> > On Sat, Oct 10, 2015 at 04:39:00PM +0200, Hauke Mehrtens wrote:
> >> On 10/03/2015 12:22 AM, Jon Mason wrote:
> >>> Add device tree files for Broadcom Northstar based SVKs.  Since the
> >>> bcm5301x.dtsi already exists, all that is necessary is the dts files to
> >>> enable the UARTs (and specify the RAM size for the 4708/9).  With these
> >>> files, the SVKs are able to boot to shell.
> >>>
> >>> Signed-off-by: Jon Mason 
> >>> ---
> >>>  arch/arm/boot/dts/Makefile   |  5 +++-
> >>>  arch/arm/boot/dts/bcm94708.dts   | 52 +++
> >>>  arch/arm/boot/dts/bcm94709.dts   | 52 +++
> >>>  arch/arm/boot/dts/bcm953012k.dts | 59 
> >>> 
> >>>  4 files changed, 167 insertions(+), 1 deletion(-)
> >>>  create mode 100644 arch/arm/boot/dts/bcm94708.dts
> >>>  create mode 100644 arch/arm/boot/dts/bcm94709.dts
> >>>  create mode 100644 arch/arm/boot/dts/bcm953012k.dts
> >>>
> 
> >>> + {
> >>> + clock-frequency = <62499840>;
> >>
> >> Just out of curiosity on what does this clock frequency depend? I saw
> >> your patch adding a real clock driver which should make this obsolete.
> >  
> > Better to add this now, as the device tree part might be out of sync
> > for a time.
> 
> Sure, this can potentially be a reason to not using the real clock node
> and just use a hardcoded clock frequency for now, until the other clock
> change is merged, then you can submit another patch to use it.
> 
> Also, is it not better to make the UARTs a static clock
> > and not dependent on the clk driver?
> > 
> 
> I disagree. You should always use the real clock driver for querying the
> clock frequency, in the case when the clock driver is available.
> 
> Today one can change the core clock for UART in the bootloader for
> various reasons (and we saw that happening a lot in the past), which in
> this case will make your kernel not seeing any console output.
> 
> By always querying the clock rate based on real registers instead of a
> hardcoded value, you don't have that issue and your kernel is less
> dependent on any changes in the bootloader.

Fair enough.  This is moot until the clk driver changes get pulled in.
This file can be changed at that time :)

Thanks,
Jon


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

Re: [PATCH v4 02/11] phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC

[Kishon Vijay Abraham I]

Hi,

On Wednesday 14 October 2015 06:25 PM, Alim Akhtar wrote:
> From: Seungwon Jeon 
> 
> This patch introduces Exynos UFS PHY driver. This driver
> supports to deal with phy calibration and power control
> according to UFS host driver's behavior.
> 
> Signed-off-by: Seungwon Jeon 
> Signed-off-by: Alim Akhtar 
> Cc: Kishon Vijay Abraham I 
> ---
>  drivers/phy/Kconfig|7 +
>  drivers/phy/Makefile   |1 +
>  drivers/phy/phy-exynos-ufs.c   |  257 
> 
>  drivers/phy/phy-exynos-ufs.h   |   88 
>  drivers/phy/phy-exynos7-ufs.h  |   89 +
>  include/linux/phy/phy-exynos-ufs.h |  101 ++
>  6 files changed, 543 insertions(+)
>  create mode 100644 drivers/phy/phy-exynos-ufs.c
>  create mode 100644 drivers/phy/phy-exynos-ufs.h
>  create mode 100644 drivers/phy/phy-exynos7-ufs.h
>  create mode 100644 include/linux/phy/phy-exynos-ufs.h
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 47da573d0bab..499eec4a967c 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -371,4 +371,11 @@ config PHY_BRCMSTB_SATA
> Enable this to support the SATA3 PHY on 28nm Broadcom STB SoCs.
> Likely useful only with CONFIG_SATA_BRCMSTB enabled.
>  
> +config PHY_EXYNOS_UFS
> + tristate "EXYNOS SoC series UFS PHY driver"
> + depends on OF && ARCH_EXYNOS || COMPILE_TEST
> + select GENERIC_PHY
> + help
> +   Support for UFS PHY on Samsung EXYNOS chipsets.
> +
>  endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a5b18c18fc12..2a312ca20795 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -46,3 +46,4 @@ obj-$(CONFIG_PHY_QCOM_UFS)  += phy-qcom-ufs-qmp-14nm.o
>  obj-$(CONFIG_PHY_TUSB1210)   += phy-tusb1210.o
>  obj-$(CONFIG_PHY_BRCMSTB_SATA)   += phy-brcmstb-sata.o
>  obj-$(CONFIG_PHY_PISTACHIO_USB)  += phy-pistachio-usb.o
> +obj-$(CONFIG_PHY_EXYNOS_UFS) += phy-exynos-ufs.o
> diff --git a/drivers/phy/phy-exynos-ufs.c b/drivers/phy/phy-exynos-ufs.c
> new file mode 100644
> index ..77330b85e3f8
> --- /dev/null
> +++ b/drivers/phy/phy-exynos-ufs.c
> @@ -0,0 +1,257 @@
> +/*
> + * UFS PHY driver for Samsung EXYNOS SoC
> + *
> + * Copyright (C) 2015 Samsung Electronics Co., Ltd.
> + * Author: Seungwon Jeon 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "phy-exynos-ufs.h"
> +
> +#define for_each_phy_lane(phy, i) \
> + for (i = 0; i < (phy)->lane_cnt; i++)
> +#define for_each_phy_cfg(cfg) \
> + for (; (cfg)->id; (cfg)++)
> +
> +#define PHY_DEF_LANE_CNT 1
> +
> +static void exynos_ufs_phy_config(struct exynos_ufs_phy *phy,
> + const struct exynos_ufs_phy_cfg *cfg, u8 lane)
> +{
> + enum {LANE_0, LANE_1}; /* lane index */
> +
> + switch (lane) {
> + case LANE_0:
> + writel(cfg->val, (phy)->reg_pma + cfg->off_0);
> + break;
> + case LANE_1:
> + if (cfg->id == PHY_TRSV_BLK)
> + writel(cfg->val, (phy)->reg_pma + cfg->off_1);
> + break;
> + }
> +}
> +
> +static bool match_cfg_to_pwr_mode(u8 desc, u8 required_pwr)
> +{
> + if (IS_PWR_MODE_ANY(desc))
> + return true;
> +
> + if (IS_PWR_MODE_HS(required_pwr) && IS_PWR_MODE_HS_ANY(desc))
> + return true;
> +
> + if (COMP_PWR_MODE(required_pwr, desc))
> + return true;
> +
> + if (COMP_PWR_MODE_MD(required_pwr, desc) &&
> + COMP_PWR_MODE_GEAR(required_pwr, desc) &&
> + COMP_PWR_MODE_SER(required_pwr, desc))
> + return true;
> +
> + return false;
> +}
> +
> +static int exynos_ufs_phy_calibrate(struct phy *phy,
> + enum phy_cfg_tag tag, u8 pwr)
> +{
> + struct exynos_ufs_phy *ufs_phy = get_exynos_ufs_phy(phy);
> + struct exynos_ufs_phy_cfg **cfgs = ufs_phy->cfg;
> + const struct exynos_ufs_phy_cfg *cfg;
> + int i;
> +
> + if (unlikely(tag < CFG_PRE_INIT || tag >= CFG_TAG_MAX)) {
> + dev_err(ufs_phy->dev, "invalid phy config index %d\n", tag);
> + return -EINVAL;
> + }
> +
> + cfg = cfgs[tag];
> + if (!cfg)
> + goto out;
> +
> + for_each_phy_cfg(cfg) {
> + for_each_phy_lane(ufs_phy, i) {
> + if (match_cfg_to_pwr_mode(cfg->desc, pwr))
> + exynos_ufs_phy_config(ufs_phy, cfg, i);
> + }
> + 

Re: [GIT PULL]Hisilicon ARMv7 based SoCs DT updates for V4.4

[Arnd Bergmann]

On Monday 12 October 2015 15:51:23 Wei Xu wrote:
> Hi Arnd, Hi Olof, Hi Kevin,
> 
> Please help to pull the following changes.
> Thanks!

Pulled into next/dt, thanks!

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

Re: [PATCH] ARM64: dts: vexpress: Use a symlink to vexpress-v2m-rs1.dtsi from arch=arm

[Arnd Bergmann]

On Monday 12 October 2015 16:37:50 Mark Rutland wrote:
> On Mon, Oct 05, 2015 at 12:53:52PM +0100, Ian Campbell wrote:
> > Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on
> > LogicTile Express 20MG" added a new dts file to arch/arm64 which
> > included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
> > .dtsi supplied by arch/arm.
> > 
> > Unfortunately this causes some issues for the split device tree
> > repository[0], since things get moved around there. In that context
> > the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
> > while the include is at src/arm/vexpress-v2m-rs1.dtsi.
> > 
> > The sharing of the .dtsi is legitimate since the baseboard is the same
> > for various vexpress systems whatever processor they use.
> > 
> > Previously I attempted to resolve this by creating a shared location
> > for such things but we have been unable to come to a consensus on
> > where that should be.
> > 
> > Instead this patch simply replaces the use of ../../ in the dts
> > /include/ with a symlink in arch/arm64/boot/dts/arm pointing to the
> > file arch/arm/boot/dts.
> > 
> > Since the split device tree repo will shortly be required to flatten
> > symlinks for other reasons this will cause the dtsi file to appear in
> > both src/arm and src/arm64 in the split repo, which is an improvement
> > on not building for arm64 now.
> > 
> > [0] 
> > https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
> > 
> > Signed-off-by: Ian Campbell 


> Acked-by: Mark Rutland 
> 

Applied to next/dt, thanks!

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

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Tony Lindgren]

* Franklin S Cooper Jr.  [151014 07:37]:
> 
> 
> On 10/14/2015 09:11 AM, Roger Quadros wrote:
> > On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
> >>
> >> On 10/14/2015 06:52 AM, Roger Quadros wrote:
> >>> Franklin,
> >>>
> >>> On 14/10/15 14:36, Roger Quadros wrote:
>  On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> > Switch from dma_request_channel to allow passing dma channel
> > information from DT rather than hardcoding a value.
> >
> > Signed-off-by: Franklin S Cooper Jr 
>  Acked-by: Roger Quadros 
> 
> > ---
> >  drivers/mtd/nand/omap2.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> > index d0f2620..957c32f 100644
> > --- a/drivers/mtd/nand/omap2.c
> > +++ b/drivers/mtd/nand/omap2.c
> > @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device 
> > *pdev)
> > dma_cap_zero(mask);
> > dma_cap_set(DMA_SLAVE, mask);
> > sig = OMAP24XX_DMA_GPMC;
> > -   info->dma = dma_request_channel(mask, 
> > omap_dma_filter_fn, );
> > +   info->dma = dma_request_slave_channel_compat(mask,
> > +   omap_dma_filter_fn, , pdev->dev.parent, 
> > "rxtx");
> > +
> >>> Just discovered that you are using the parent device node.
> >>>
> >>> How about moving the dma bindings to the nand node instead and using
> >>> pdev->dev here?
> >> Roger,
> >>
> >> From what I can tell the interrupt number and the dma channel will always 
> >> be
> >> the same no matter what. Doesn't matter if you have multiple nands or a
> >> combination of nands and nors. Since that is the case I think it just makes
> >> sense to leave it in the gpmc parent node and define it once.
> > Is prefetch/writepost dma used for NOR or any other GPMC peripheral
> > or only for NAND?
> The dma seems tied to the prefetch. From what I can tell the prefetch is only
> used by nand.
> >
> > Let's also get Tony's inputs on this.
> Sure.

Hmm so what would keep other devices from using the prefetch?

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 0/3] hwrng: stm32 - add support for STM32 HW RNG

[Herbert Xu]

On Mon, Oct 12, 2015 at 09:21:27AM +0100, Daniel Thompson wrote:
> This patchset introduces a driver for the STM32 hardware random number
> generator.
> 
> v2:
> 
>  * Moved binding docs from .../hwrng/ to .../rng/ and renamed to match
>convention in new directory (Rob Herring).
>  * Adopted runtime PM and auto-suspend instead of managing the clocks
>from the read function (Linus Walleij). Increased bandwidth by ~30%.
>  * Simplified error detection in main read loop (Linus Walleij, Maxime
>Coquelin).
>  * Only WARN_ONCE() when hardware failure mechanisms trigger (Maxime
>Coquelin).
>  * Simplify end of probe function after cocci warning (Fengguang Wu).
>  * Switch to devm_hwrng_register.

All applied.  Thanks!
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "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] iio: mma8452: support either of the available interrupt pins

[Lars-Peter Clausen]

On 10/14/2015 03:15 PM, Martin Kepplinger wrote:
[...]
> + if (irq1 > 0)
> + client->irq = irq1;

You must not overwrite client->irq, that field is manged by the I2C core and
is supposed to be read only for device drivers.

> + dev_info(>dev, "using interrupt line INT1\n");

This should probably be a dev_dbg()

> + } else {
> + client->irq = irq2;
> + dev_info(>dev, "using interrupt line INT2\n");

Same here

> + }
--
To unsubscribe from this list: send the line "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/4] dmaengine: Add STM32 DMA driver

[M'boumba Cedric Madianga]

2015-10-14 16:24 GMT+02:00 Daniel Thompson :
>
> Hmnnn...
>
> The dmaengine framework will WARN_ONCE() if an dmaengine is removed whilst
> it is active and also works hard to ensure dmaengine modules are not removed
> whilst there are active drivers using the framework.
>
> How do we get into this function whilst there is still an active DMA
> channels?

For example, when a user try "rmmod stm32-dma" in uart console.
It will enter in stm32_dma_remove while there is potentially still active DMA.

>
>
>> But even with this improvement, I think I have to disable the clock here.
>
>
> As above, I think the dmaengine framework work to protect you from this sort
> problem. However even if I am wrong about that then unconditionally calling
> clk_disable_unprepare() can not be used to reliably manage the clocks. You
> don't know what the counts are!

Ok got it. Thanks for the clarification.

Cedric
--
To unsubscribe from this list: send the line "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] hwrng: stm32 - Fix build with CONFIG_PM

[Daniel Thompson]

Commit c6a97c42e399 ("hwrng: stm32 - add support for STM32 HW RNG")
was inadequately tested (actually it was tested quite hard so
incompetent would be a better description that inadequate) and does
not compile on platforms with CONFIG_PM set.

Fix this.

Signed-off-by: Daniel Thompson 
---

Notes:
Herbert: This is the diff between v2 and v3 of my STM32 HW RNG
 patch. This is partly reassurance of what has changed
 and also "just in case" you prefer to simply fix the
 problem.

 drivers/char/hw_random/stm32-rng.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/char/hw_random/stm32-rng.c 
b/drivers/char/hw_random/stm32-rng.c
index 7fa3656a5fc5..92a810648bd0 100644
--- a/drivers/char/hw_random/stm32-rng.c
+++ b/drivers/char/hw_random/stm32-rng.c
@@ -160,7 +160,7 @@ static int stm32_rng_probe(struct platform_device *ofdev)
 #ifdef CONFIG_PM
 static int stm32_rng_runtime_suspend(struct device *dev)
 {
-   struct stm32_rng_private *priv = dev_get_drvdata(pdev);
+   struct stm32_rng_private *priv = dev_get_drvdata(dev);

stm32_rng_cleanup(>rng);

@@ -169,7 +169,7 @@ static int stm32_rng_runtime_suspend(struct device *dev)

 static int stm32_rng_runtime_resume(struct device *dev)
 {
-   struct stm32_rng_private *priv = dev_get_drvdata(pdev);
+   struct stm32_rng_private *priv = dev_get_drvdata(dev);

return stm32_rng_init(>rng);
 }
--
2.4.3

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

[PATCH v4 3/3] soc: ti: qmss: make acc queue support optional in the driver

[Murali Karicheri]

acc channels are available only if accumulator PDSP is loaded and
running in the SoC. As this requires firmware and user may not have
firmware in the file system, make the accumulator queue support
available in qmss driver optional. To use accumulator queus user needs
to add firmware to the file system and boot up kernel.

Signed-off-by: Murali Karicheri 
---
 v4: no change from v3
 Documentation/arm/keystone/knav-qmss.txt |  6 ++
 drivers/soc/ti/knav_qmss.h   |  2 ++
 drivers/soc/ti/knav_qmss_acc.c   | 10 --
 drivers/soc/ti/knav_qmss_queue.c | 20 +++-
 4 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/Documentation/arm/keystone/knav-qmss.txt 
b/Documentation/arm/keystone/knav-qmss.txt
index da34a5b..fcdb9fd 100644
--- a/Documentation/arm/keystone/knav-qmss.txt
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -48,3 +48,9 @@ in the file system and boot up the kernel. User would see
  "firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
 
 in the boot up log if loading of firmware to PDSP is successful.
+
+Use of accumulated queues requires the firmware image to be present in the
+file system. The driver doesn't acc queues to the supported queue range if
+PDSP is not running in the SoC. The API call fails if there is a queue open
+request to an acc queue and PDSP is not running. So make sure to copy firmware
+to file system before using these queue types.
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index c31b8d8..6ff936c 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -137,6 +137,8 @@ struct knav_pdsp_info {
u32 __iomem *iram;
u32 id;
struct list_headlist;
+   boolloaded;
+   boolstarted;
 };
 
 struct knav_qmgr_info {
diff --git a/drivers/soc/ti/knav_qmss_acc.c b/drivers/soc/ti/knav_qmss_acc.c
index b98fe56..d2d48f2 100644
--- a/drivers/soc/ti/knav_qmss_acc.c
+++ b/drivers/soc/ti/knav_qmss_acc.c
@@ -486,8 +486,8 @@ struct knav_range_ops knav_acc_range_ops = {
  * Return 0 on success or error
  */
 int knav_init_acc_range(struct knav_device *kdev,
-   struct device_node *node,
-   struct knav_range_info *range)
+   struct device_node *node,
+   struct knav_range_info *range)
 {
struct knav_acc_channel *acc;
struct knav_pdsp_info *pdsp;
@@ -530,6 +530,12 @@ int knav_init_acc_range(struct knav_device *kdev,
return -EINVAL;
}
 
+   if (!pdsp->started) {
+   dev_err(kdev->dev, "pdsp id %d not started for range %s\n",
+   info->pdsp_id, range->name);
+   return -ENODEV;
+   }
+
info->pdsp = pdsp;
channels = range->num_queues;
if (of_get_property(node, "multi-queue", NULL)) {
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 06d9de8..f3a0b6a 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -1504,6 +1504,8 @@ static int knav_queue_stop_pdsp(struct knav_device *kdev,
dev_err(kdev->dev, "timed out on pdsp %s stop\n", pdsp->name);
return ret;
}
+   pdsp->loaded = false;
+   pdsp->started = false;
return 0;
 }
 
@@ -1592,16 +1594,24 @@ static int knav_queue_start_pdsps(struct knav_device 
*kdev)
int ret;
 
knav_queue_stop_pdsps(kdev);
-   /* now load them all */
+   /* now load them all. We return success even if pdsp
+* is not loaded as acc channels are optional on having
+* firmware availability in the system. We set the loaded
+* and stated flag and when initialize the acc range, check
+* it and init the range only if pdsp is started.
+*/
for_each_pdsp(kdev, pdsp) {
ret = knav_queue_load_pdsp(kdev, pdsp);
-   if (ret < 0)
-   return ret;
+   if (!ret)
+   pdsp->loaded = true;
}
 
for_each_pdsp(kdev, pdsp) {
-   ret = knav_queue_start_pdsp(kdev, pdsp);
-   WARN_ON(ret);
+   if (pdsp->loaded) {
+   ret = knav_queue_start_pdsp(kdev, pdsp);
+   if (!ret)
+   pdsp->started = true;
+   }
}
return 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

[PATCH 0/3] Split Arizona DT bindings between subsystems

[Charles Keepax]

As discussed the Arizona device tree bindings documentation
will be split up into a seperate document holding properties
specific to each subsystem.

This series factors out the regulator and extcon
bindings. It will probably make sense to split out a GPIO
binding document as well but at the moment the only property
here is the gpio-defaults which are still handled in the MFD
driver and probably require significantly more thought to
split out.

Thanks,
Charles

Charles Keepax (3):
  extcon: arizona: Add extcon specific device tree binding document
  regulator: arizona: Add regulator specific device tree binding
document
  mfd: arizona: Remove bindings covered in new subsystem specific docs

 .../devicetree/bindings/extcon/extcon-arizona.txt  |   15 +
 Documentation/devicetree/bindings/mfd/arizona.txt  |   30 ++---
 .../bindings/regulator/arizona-regulator.txt   |   34 
 MAINTAINERS|3 ++
 4 files changed, 55 insertions(+), 27 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-arizona.txt
 create mode 100644 
Documentation/devicetree/bindings/regulator/arizona-regulator.txt

-- 
1.7.2.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 09/25] scsi: hisi_sas: add phy SAS ADDR initialization

[John Garry]

On 14/10/2015 09:40, Hannes Reinecke wrote:

On 10/13/2015 07:14 PM, John Garry wrote:

On 13/10/2015 07:12, Hannes Reinecke wrote:

On 10/12/2015 05:20 PM, John Garry wrote:

This SAS ID is chosen as Huawei IEEE id: 001882

Signed-off-by: John Garry 
---
   drivers/scsi/hisi_sas/hisi_sas_init.c | 15 +++
   1 file changed, 15 insertions(+)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_init.c
b/drivers/scsi/hisi_sas/hisi_sas_init.c
index 44fc524..c295c39 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_init.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_init.c
@@ -283,6 +283,19 @@ err_out:
   return NULL;
   }

+static void hisi_sas_init_add(struct hisi_hba *hisi_hba)
+{
+u8 i;
+
+/* Huawei IEEE id (001882) */
+for (i = 0; i < hisi_hba->n_phy; i++)
+hisi_hba->phy[i].dev_sas_addr =
+cpu_to_be64(0x5001882016072015ULL);
+

Ouch. Each phy has the same SAS address?
For all boards? Ever?

Not sure if that's a good idea, nor even valid.
It'll confuse the hell out of any SAS array.

Please provide a means of having individual SAS addresses for each
HBA.

Cheers,

Hannes


Hello,

Are you saying we should be getting the SAS address from fw with
sas_request_addr() or the like?

Marvell solution seems to hardcode it.


Doesn't make it any better, nor even valid.

Problem is that using a hardcoded SAS address makes it impossible
do any resource allocation on a SAS target array.
The SAS target array is allocating / mapping the LUNs based on the
SAS address, so if HBAs from different machines coming in with the
same SAS address the SAS array will assume that all ports belong to
the same machine, thus allowing access to all of them.

And don't try to _ever_ connect these HBAs to a SAS switch; that
will be even more confused.

So please, if you have a chance _DO_ get the SAS address from fw.
If the firmware doesn't provide it you really should get in touch
with the firmware team to get you one.

To clarify the situation the SAS spec states:

   Device names are worldwide unique names for devices within a
   transport protocol (see SAM-3).

and:
   The VENDOR - SPECIFIC IDENTIFIER contains a 36-bit numeric value
   that is uniquely assigned by the organization associated with the
   company identifier in the IEEE COMPANY ID field.

So as you are using the Huawei Vendor ID Huawei as a company needs
to ensure uniqueness of the vendor-specific identifier (ie the last
36 bits of the SAS address). Which the above patch most patently
fails to address.

Cheers,

Hannes


Hi,

OK, we can look at adding the ability to read the SAS HBA address from a 
FW image or EFI variables.


Thanks,
John

--
To unsubscribe from this list: send the line "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] gpio/xilinx: enable for MIPS

[Sören Brinkmann]

On Wed, 2015-10-14 at 01:51PM +0100, Zubair Lutfullah Kakakhel wrote:
> MIPSfpga uses the axi gpio controller. Enable the driver for MIPS.
> 
> Signed-off-by: Zubair Lutfullah Kakakhel 
> ---
>  drivers/gpio/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 8949b3f..58e9afd 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -508,7 +508,7 @@ config GPIO_XGENE_SB
>  
>  config GPIO_XILINX
>   tristate "Xilinx GPIO support"
> - depends on OF_GPIO && (PPC || MICROBLAZE || ARCH_ZYNQ || X86)
> + depends on OF_GPIO && (PPC || MICROBLAZE || ARCH_ZYNQ || X86 || MIPS)

Hmm, in general, this driver is hopefully generic enough that it doesn't
have any real architecture dependencies. And I suspect, we want to
enable this driver for ARM64 for ZynqMP soon too. Should we probably
drop these arch dependencies completely? It seems to become quite a long list.

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

[PATCH v4 2/3] soc: ti: add firmware file name as part of the driver

[Murali Karicheri]

Currently firmware file name is included in the DTS. This is not scalable
as user has to change the DTS if they need upgrade to a new firmware.
Instead, add the firmware file name in the driver itself. As long as there
is no API change, new firmware upgrade is easy and require no driver
change. User is expected to copy the firmware image to the file system
and add a sym link to the new firmware for doing an upgrade. Driver add
a array of firmware file names to search for the available firmware blobs.
This scheme also prepare the driver for future changes to API if ever
happens. In such case it is assumed that driver needs to change to
accommodate the new firmware and new firmware file name will get added to
the array.

Also update the DT document to remove the firmware attribute and add
description about firmware in the driver documentation.

Signed-off-by: Murali Karicheri 
Acked-by: Arnd Bergmann 
---
 v4: no change from v3
 Documentation/arm/keystone/knav-qmss.txt   | 26 
 .../bindings/soc/ti/keystone-navigator-qmss.txt|  1 -
 drivers/soc/ti/knav_qmss.h |  1 -
 drivers/soc/ti/knav_qmss_queue.c   | 47 +-
 4 files changed, 54 insertions(+), 21 deletions(-)

diff --git a/Documentation/arm/keystone/knav-qmss.txt 
b/Documentation/arm/keystone/knav-qmss.txt
index 79946d1..da34a5b 100644
--- a/Documentation/arm/keystone/knav-qmss.txt
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -22,3 +22,29 @@ pool management.
 knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
 allocate descriptor pools, map the descriptors, push/pop to queues etc. For
 details of the available APIs, please refers to 
include/linux/soc/ti/knav_qmss.h
+
+DT documentation is available at
+Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+
+Accumulator QMSS queues using PDSP firmware
+
+The QMSS PDSP firmware support accumulator channel that can monitor a single
+queue or multiple contiguous queues. drivers/soc/ti/knav_qmss_acc.c is the
+driver that interface with the accumulator PDSP. This configures
+accumulator channels defined in DTS (example in DT documentation) to monitor
+1 or 32 queues per channel. More description on the firmware is available in
+CPPI/QMSS Low Level Driver document (docs/CPPI_QMSS_LLD_SDS.pdf) at
+   git://git.ti.com/keystone-rtos/qmss-lld.git
+
+k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports upto 48 accumulator
+channels. This firmware is available under ti-keystone folder of
+firmware.git at
+   git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
+
+To use copy the firmware image to lib/firmware folder of the initramfs or
+ubifs file system and provide a sym link to 
k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin
+in the file system and boot up the kernel. User would see
+
+ "firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
+
+in the boot up log if loading of firmware to PDSP is successful.
diff --git 
a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt 
b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
index d8e8cdb..d1ce21a 100644
--- a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
@@ -221,7 +221,6 @@ qmss: qmss@2a4 {
#size-cells = <1>;
ranges;
pdsp0@0x2a1 {
-   firmware = "keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw";
reg = <0x2a1 0x1000>,
  <0x2a0f000 0x100>,
  <0x2a0c000 0x3c8>,
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index 51da234..c31b8d8 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -135,7 +135,6 @@ struct knav_pdsp_info {
};
void __iomem*intd;
u32 __iomem *iram;
-   const char  *firmware;
u32 id;
struct list_headlist;
 };
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 6d8646d..06d9de8 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -68,6 +68,12 @@ static DEFINE_MUTEX(knav_dev_lock);
 idx < (kdev)->num_queues_in_use;   \
 idx++, inst = knav_queue_idx_to_inst(kdev, idx))
 
+/* All firmware file names end up here. List the firmware file names below.
+ * Newest followed by older ones. Search is done from start of the array
+ * until a firmware file is found.
+ */
+const char *knav_acc_firmwares[] = {"ks2_qmss_pdsp_acc48.bin"};
+
 /**
  * knav_queue_notify: qmss queue notfier 

Re: [PATCH v3 20/27] ARM: dts: dra7: Fix NAND device nodes.

[Franklin S Cooper Jr.]

On 10/14/2015 09:17 AM, Roger Quadros wrote:
> On 14/10/15 16:34, Franklin S Cooper Jr. wrote:
>>
>> On 09/18/2015 09:53 AM, Roger Quadros wrote:
>>> Add compatible id, GPMC register resource and interrupt
>>> resource to NAND controller nodes.
>>>
>>> The GPMC driver now implements gpiochip and irqchip so
>>> enable gpio-controller and interrupt-controller properties.
>>>
>>> With this the interrupt parent of NAND node changes so fix it
>>> accordingly.
>>>
>>> Signed-off-by: Roger Quadros 
>>> ---
>>>  arch/arm/boot/dts/dra7-evm.dts  | 5 -
>>>  arch/arm/boot/dts/dra7.dtsi | 4 
>>>  arch/arm/boot/dts/dra72-evm.dts | 5 -
>>>  3 files changed, 12 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
>>> index a6c82e5..8a31161 100644
>>> --- a/arch/arm/boot/dts/dra7-evm.dts
>>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>>> @@ -585,9 +585,12 @@
>>> status = "okay";
>>> pinctrl-names = "default";
>>> pinctrl-0 = <_flash_x16>;
>>> -   ranges = <0 0 0 0x0100>;/* minimum GPMC partition = 16MB */
>>> +   ranges = <0 0 0x0800 0x0100>;   /* minimum GPMC partition = 
>>> 16MB */
>>> nand@0,0 {
>>> +   compatible = "ti,omap2-nand";
>>> reg = <0 0 4>;  /* device IO registers */
>>> +   interrupt-parent = <_mpu>;
>>> +   interrupts = ;
>>> ti,nand-ecc-opt = "bch8";
>>> ti,elm-id = <>;
>>> nand-bus-width = <16>;
>>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>>> index 5d65db9..f0a3616 100644
>>> --- a/arch/arm/boot/dts/dra7.dtsi
>>> +++ b/arch/arm/boot/dts/dra7.dtsi
>>> @@ -1389,6 +1389,10 @@
>>> gpmc,num-waitpins = <2>;
>>> #address-cells = <2>;
>>> #size-cells = <1>;
>>> +   gpio-controller;
>>> +   #gpio-cells = <2>;
>>> +   interrupt-controller;
>>> +   #interrupt-cells = <2>;
>>> status = "disabled";
>>> };
>> Based on the discussion on my patchset I noticed that the nand node defines 
>> the
>> interrupt but it is also defined in the parent node. Similar to the dma 
>> channel we
>> should conclude where the best place for it to be defined.  But to me it 
>> seems at
>> least it should only be defined once.
> The interrupt is defined at both places because it is used at both places.
> It is used as a shared interrupt. Wait_pin interrupts are managed by the
> gpmc driver and NAND specific interrupts are managed by the NAND driver.
>
> If GPMC dma channel is going to be used only by the NAND driver then
> we should define the channel in the NAND node.
>
>> This is true for your other patches making similar changes to the dt.
> Yes, GPMC IRQ is defined in both GPMC and NAND nodes.
Ok. I would still think you would just reuse the entry from the
parent since you know it will always be the same. But we can
go with what Tony thinks is best.
>
> --
> cheers,
> -roger

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

Re: [PATCH 02/13] dmaengine: edma: Optimize memcpy operation

[Vinod Koul]

On Wed, Oct 14, 2015 at 04:12:13PM +0300, Peter Ujfalusi wrote:
> @@ -1320,41 +1317,92 @@ static struct dma_async_tx_descriptor 
> *edma_prep_dma_memcpy(
>   struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
>   size_t len, unsigned long tx_flags)
>  {
> - int ret;
> + int ret, nslots;
>   struct edma_desc *edesc;
>   struct device *dev = chan->device->dev;
>   struct edma_chan *echan = to_edma_chan(chan);
> - unsigned int width;
> + unsigned int width, pset_len;
>  
>   if (unlikely(!echan || !len))
>   return NULL;
>  
> - edesc = kzalloc(sizeof(*edesc) + sizeof(edesc->pset[0]), GFP_ATOMIC);
> + if (len < SZ_64K) {
> + /*
> +  * Transfer size less than 64K can be handled with one paRAM
> +  * slot. ACNT = length
> +  */
> + width = len;
> + pset_len = len;
> + nslots = 1;
> + } else {
> + /*
> +  * Transfer size bigger than 64K will be handled with maximum of
> +  * two paRAM slots.
> +  * slot1: ACNT = 32767, length1: (length / 32767)
> +  * slot2: the remaining amount of data.
> +  */
> + width = SZ_32K - 1;
> + pset_len = rounddown(len, width);
> + /* One slot is enough for lengths multiple of (SZ_32K -1) */

Hmm so does this mean if I have 140K transfer, it will do two 64K for 1st
slot and 12K in second slot ?

Is there a limit on 'blocks' of 64K we can do here?

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

Re: [PATCH] dmaengine: xgene-dma: Remove memcpy offload support due to performance drop

[Vinod Koul]

On Wed, Oct 14, 2015 at 07:25:07PM +0530, Rameshwar Prasad Sahu wrote:
> The DMA engine supports memory copy, RAID5 XOR, RAID6 PQ, and other
> computations. But the bandwidth of the entire DMA engine is shared
> among all channels. This patch re-configures operations availability
> such that one can achieve maximum performance for XOR and PQ
> computation by removing the memory offload operations.

Applied, thanks

-- 
~Vinod

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

Re: [PATCH-RFC 6/7] drivers: of: ifdef out cmdline section

[Daniel Walker]

There's one last little wrinkle .. In the current setup the defconfig 
CONFIG_CMDLINE="" is used as a default in case the device tree has 
nothing in it. In my changes, there is no identical functionality. The 
only similar thing I have is the the CONFIG_CMDLINE_APPEND="" . The main 
difference is that in the current implementation CONFIG_CMDLINE="" 
doesn't get added at all if there is a device tree bootargs, but with my 
implementation this line would be added unconditionally. It would 
represent a subtle change where people would have to add into the DT 
bootargs something to override what might be in the default command line.


For example,

if a config has CONFIG_CMDLINE_APPEND="debug" then they would have to 
add a "loglevel=7" into the DT bootargs to get back to normal. I 
wouldn't think people would want "debug" as the default, but oddly 
enough some of the configs do have this. Some of them also have default 
ip address setting, nfsroot= settings, and loglevel= settings.


What are your thoughts on this ? I think using the append type default 
makes more sense because it's actually setting up global defaults. The 
current complete replacement scheme seems to set the stage for people to 
make an entirely custom default for a single development machine, which 
IMO doesn't make sense. However, I'm not sure what the intent is with 
the current setup.


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

Re: [PATCH 02/13] dmaengine: edma: Optimize memcpy operation

[Peter Ujfalusi]

On 10/14/2015 05:41 PM, Vinod Koul wrote:
> On Wed, Oct 14, 2015 at 04:12:13PM +0300, Peter Ujfalusi wrote:
>> @@ -1320,41 +1317,92 @@ static struct dma_async_tx_descriptor 
>> *edma_prep_dma_memcpy(
>>  struct dma_chan *chan, dma_addr_t dest, dma_addr_t src,
>>  size_t len, unsigned long tx_flags)
>>  {
>> -int ret;
>> +int ret, nslots;
>>  struct edma_desc *edesc;
>>  struct device *dev = chan->device->dev;
>>  struct edma_chan *echan = to_edma_chan(chan);
>> -unsigned int width;
>> +unsigned int width, pset_len;
>>  
>>  if (unlikely(!echan || !len))
>>  return NULL;
>>  
>> -edesc = kzalloc(sizeof(*edesc) + sizeof(edesc->pset[0]), GFP_ATOMIC);
>> +if (len < SZ_64K) {
>> +/*
>> + * Transfer size less than 64K can be handled with one paRAM
>> + * slot. ACNT = length
>> + */
>> +width = len;
>> +pset_len = len;
>> +nslots = 1;
>> +} else {
>> +/*
>> + * Transfer size bigger than 64K will be handled with maximum of
>> + * two paRAM slots.
>> + * slot1: ACNT = 32767, length1: (length / 32767)
>> + * slot2: the remaining amount of data.
>> + */
>> +width = SZ_32K - 1;
>> +pset_len = rounddown(len, width);
>> +/* One slot is enough for lengths multiple of (SZ_32K -1) */
> 
> Hmm so does this mean if I have 140K transfer, it will do two 64K for 1st
> slot and 12K in second slot ?

Not exactly. If the size is less than 64K it can be done with one 'burst' but
if it is bigger we need to have two sets of transfer:
1. 32K blocks
2. the remaining data

so in case of 140K:
4 x 32K followed by 12K

> 
> Is there a limit on 'blocks' of 64K we can do here?

32767 32K blocks is the limit.

The 64K burst is only possible if the whole transfer is less less than 64K.
With the ACNT counter we can transfer 64K - 1 bytes, but if this is not enough
we need to use the BCNT counter and for that to work the the distance between
the start of 'slot n' and the start of 'slot n+1' need to be less than 32K,
this is the reason why we have 32K 'blocks' to transfer first followed by the
remaining.

-- 
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 2/5] gpio/xilinx: enable for MIPS

[Lars-Peter Clausen]

On 10/14/2015 05:18 PM, Sören Brinkmann wrote:
> On Wed, 2015-10-14 at 01:51PM +0100, Zubair Lutfullah Kakakhel wrote:
>> MIPSfpga uses the axi gpio controller. Enable the driver for MIPS.
>>
>> Signed-off-by: Zubair Lutfullah Kakakhel 
>> ---
>>  drivers/gpio/Kconfig | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>> index 8949b3f..58e9afd 100644
>> --- a/drivers/gpio/Kconfig
>> +++ b/drivers/gpio/Kconfig
>> @@ -508,7 +508,7 @@ config GPIO_XGENE_SB
>>  
>>  config GPIO_XILINX
>>  tristate "Xilinx GPIO support"
>> -depends on OF_GPIO && (PPC || MICROBLAZE || ARCH_ZYNQ || X86)
>> +depends on OF_GPIO && (PPC || MICROBLAZE || ARCH_ZYNQ || X86 || MIPS)
> 
> Hmm, in general, this driver is hopefully generic enough that it doesn't
> have any real architecture dependencies. And I suspect, we want to
> enable this driver for ARM64 for ZynqMP soon too. Should we probably
> drop these arch dependencies completely? It seems to become quite a long list.

I've been thinking about this a while ago. This is certainly not the only
driver affected by this problem. But the thing is people always complain if
new symbols become visable in Kconfig that don't apply to their platform.

Maybe we should introduce a HAS_REPROGRAMABLE_LOGIC (or similar) feature
Kconfig symbol and let platforms which have a FPGA select it and let drivers
for FPGA peripherals depend on it.

- Lars

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

[PATCH 2/6] mfd: axp20x: Split the driver into core and i2c bits

[Chen-Yu Tsai]

The axp20x driver assumes the device is i2c based. This is not the
case with later models, which use a proprietary 2 wire serial bus
called "Reduced Serial Bus".

This patch follows the example of mfd/wm831x and splits it into
an interface independet core, and an i2c specific glue layer.

The old MFD_AXP20X Kconfig symbol is kept until sub-device drivers
and defconfigs have migrated to the new MFD_AXP20X_CORE symbol.

Included but unused header files are removed as well.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/mfd/Kconfig |  18 -
 drivers/mfd/Makefile|   3 +-
 drivers/mfd/{axp20x.c => axp20x-core.c} | 105 +++---
 drivers/mfd/axp20x-i2c.c| 127 
 include/linux/mfd/axp20x.h  |  33 -
 5 files changed, 186 insertions(+), 100 deletions(-)
 rename drivers/mfd/{axp20x.c => axp20x-core.c} (87%)
 create mode 100644 drivers/mfd/axp20x-i2c.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 99d63675f073..9ba3feb3f2fc 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -79,15 +79,25 @@ config MFD_BCM590XX
help
  Support for the BCM590xx PMUs from Broadcom
 
+# Keep the old symbol until subdevice driver dependencies and defconfigs
+# have been updated.
 config MFD_AXP20X
-   bool "X-Powers AXP20X"
+   bool "X-Powers AXP series PMICs"
+   select MFD_AXP20X_I2C
+
+config MFD_AXP20X_CORE
+   bool
select MFD_CORE
-   select REGMAP_I2C
select REGMAP_IRQ
+
+config MFD_AXP20X_I2C
+   bool "X-Powers AXP series I2C PMICs"
+   select MFD_AXP20X_CORE
+   select REGMAP_I2C
depends on I2C=y
help
- If you say Y here you get support for the X-Powers AXP202, AXP209 and
- AXP288 power management IC (PMIC).
+ If you say Y here you get support for the X-Powers AXP series I2C
+ based power management ICs (PMICs).
  This driver include only the core APIs. You have to select individual
  components like regulators or the PEK (Power Enable Key) under the
  corresponding menus.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a59e3fcc8626..ce3ad5fd4e2f 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -106,7 +106,8 @@ obj-$(CONFIG_PMIC_DA9052)   += da9052-irq.o
 obj-$(CONFIG_PMIC_DA9052)  += da9052-core.o
 obj-$(CONFIG_MFD_DA9052_SPI)   += da9052-spi.o
 obj-$(CONFIG_MFD_DA9052_I2C)   += da9052-i2c.o
-obj-$(CONFIG_MFD_AXP20X)   += axp20x.o
+obj-$(CONFIG_MFD_AXP20X_CORE)  += axp20x-core.o
+obj-$(CONFIG_MFD_AXP20X_I2C)   += axp20x-i2c.o
 
 obj-$(CONFIG_MFD_LP3943)   += lp3943.o
 obj-$(CONFIG_MFD_LP8788)   += lp8788.o lp8788-irq.o
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x-core.c
similarity index 87%
rename from drivers/mfd/axp20x.c
rename to drivers/mfd/axp20x-core.c
index 3f576b76c322..dd33548d93c4 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x-core.c
@@ -5,6 +5,8 @@
  * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
  * as well as configurable GPIOs.
  *
+ * This file contains the interface independent core functions.
+ *
  * Author: Carlo Caione 
  *
  * This program is free software; you can redistribute it and/or modify
@@ -13,18 +15,14 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 
 #define AXP20X_OFF 0x80
@@ -361,32 +359,6 @@ static const struct regmap_irq axp288_regmap_irqs[] = {
INIT_REGMAP_IRQ(AXP288, BC_USB_CHNG,5, 1),
 };
 
-static const struct of_device_id axp20x_of_match[] = {
-   { .compatible = "x-powers,axp152", .data = (void *) AXP152_ID },
-   { .compatible = "x-powers,axp202", .data = (void *) AXP202_ID },
-   { .compatible = "x-powers,axp209", .data = (void *) AXP209_ID },
-   { .compatible = "x-powers,axp221", .data = (void *) AXP221_ID },
-   { },
-};
-MODULE_DEVICE_TABLE(of, axp20x_of_match);
-
-/*
- * This is useless for OF-enabled devices, but it is needed by I2C subsystem
- */
-static const struct i2c_device_id axp20x_i2c_id[] = {
-   { },
-};
-MODULE_DEVICE_TABLE(i2c, axp20x_i2c_id);
-
-static const struct acpi_device_id axp20x_acpi_match[] = {
-   {
-   .id = "INT33F4",
-   .driver_data = AXP288_ID,
-   },
-   { },
-};
-MODULE_DEVICE_TABLE(acpi, axp20x_acpi_match);
-
 static const struct regmap_irq_chip axp152_regmap_irq_chip = {
.name   = "axp152_irq_chip",
.status_base= AXP152_IRQ1_STATE,
@@ -586,27 +558,8 @@ static void axp20x_power_off(void)
 AXP20X_OFF);
 }
 
-static int axp20x_match_device(struct axp20x_dev *axp20x, struct device *dev)
+int axp20x_match_device(struct axp20x_dev *axp20x, struct device *dev)
 {
-   const struct 

[PATCH 6/6] ARM: dts: sun8i: sinlinx-sina33: Add AXP223 PMIC device and regulator nodes

[Chen-Yu Tsai]

This board has a X-Powers AXP223 PMIC connected via RSB. It's regulators
provide power to various parts of the SoC and the board.

Also update the regulator supply phandles.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 79 +-
 1 file changed, 76 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts 
b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index 13ce68f06dd6..91a0fde47fdd 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -68,7 +68,7 @@
 };
 
  {
-   vref-supply = <_vcc3v0>;
+   vref-supply = <_dcdc1>;
status = "okay";
 
button@200 {
@@ -96,7 +96,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin_sina33>;
-   vmmc-supply = <_vcc3v0>;
+   vmmc-supply = <_dcdc1>;
bus-width = <4>;
cd-gpios = < 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
cd-inverted;
@@ -106,7 +106,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_8bit_pins>;
-   vmmc-supply = <_vcc3v0>;
+   vmmc-supply = <_dcdc1>;
bus-width = <8>;
non-removable;
status = "okay";
@@ -132,6 +132,79 @@
 
 _rsb {
status = "okay";
+
+   axp22x: pmic@3e3 {
+   compatible = "x-powers,axp223";
+   reg = <0x3e3>;
+   interrupt-parent = <_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   eldoin-supply = <_dcdc1>;
+   };
+};
+
+#include "axp22x.dtsi"
+
+_aldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-io";
+};
+
+_aldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <235>;
+   regulator-max-microvolt = <265>;
+   regulator-name = "vdd-dll";
+};
+
+_aldo3 {
+   regulator-always-on;
+   regulator-min-microvolt = <270>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-pll-avcc";
+};
+
+_dc5ldo {
+   regulator-always-on;
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpus";
+};
+
+_dcdc1 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-3v0";
+};
+
+_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-sys";
+};
+
+_dcdc3 {
+   regulator-always-on;
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpu";
+};
+
+_dcdc5 {
+   regulator-always-on;
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   regulator-name = "vcc-dram";
+};
+
+_rtc_ldo {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-rtc";
 };
 
  {
-- 
2.6.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/6] mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings

[Chen-Yu Tsai]

The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.

Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index a474359dd206..fd39fa54571b 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -5,11 +5,12 @@ axp152 (X-Powers)
 axp202 (X-Powers)
 axp209 (X-Powers)
 axp221 (X-Powers)
+axp223 (X-Powers)
 
 Required properties:
 - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
- "x-powers,axp221"
-- reg: The I2C slave address for the AXP chip
+ "x-powers,axp221", "x-powers,axp223"
+- reg: The I2C slave address or RSB hardware address for the AXP chip
 - interrupt-parent: The parent interrupt controller
 - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
 - interrupt-controller: The PMIC has its own internal IRQs
@@ -51,7 +52,7 @@ LDO3  : LDO   : ldo3in-supply
 LDO4   : LDO   : ldo24in-supply: shared supply
 LDO5   : LDO   : ldo5in-supply
 
-AXP221 regulators, type, and corresponding input supply names:
+AXP221/AXP223 regulators, type, and corresponding input supply names:
 
 RegulatorTypeSupply Name Notes
 ---- -
-- 
2.6.1

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

Re: [PATCH v3 3/5] net: phy: Add Broadcom phy library for common interfaces

[Robert E Cochran]

On 10/06/2015 03:25 PM, Arun Parameswaran wrote:

This patch adds the Broadcom phy library to consolidate common
interfaces shared by Broadcom phy's.


The BCM54612E is included in the Broadcom Community part portfolio 
(https://community.broadcom.com).  However, I don't see this part 
explicitly supported by your phy library ( e.g., not included in 
broadcom_drivers[] in broadcom.c ).


Can you please comment on whether this part is supported or the extent 
of changes required to establish and support a robust GigE connection 
between RGMII and CU?


We're considering this part for a new embedded design, and we need an 
open source driver for it.


Thanks

Bob





Moved the common interfaces to the 'bcm-phy-lib.c' and updated
the Broadcom PHY drivers to use the new APIs.

Signed-off-by: Arun Parameswaran 
---
  drivers/net/phy/Kconfig   |   6 ++
  drivers/net/phy/Makefile  |   1 +
  drivers/net/phy/bcm-phy-lib.c | 209 ++
  drivers/net/phy/bcm-phy-lib.h |  37 
  drivers/net/phy/bcm63xx.c |  38 +---
  drivers/net/phy/bcm7xxx.c | 127 ++---
  drivers/net/phy/broadcom.c| 149 +-
  include/linux/brcmphy.h   |  22 +
  8 files changed, 333 insertions(+), 256 deletions(-)
  create mode 100644 drivers/net/phy/bcm-phy-lib.c
  create mode 100644 drivers/net/phy/bcm-phy-lib.h

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index b57f6c2..606fdc9 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -69,8 +69,12 @@ config SMSC_PHY
---help---
  Currently supports the LAN83C185, LAN8187 and LAN8700 PHYs
  
+config BCM_NET_PHYLIB

+   tristate
+
  config BROADCOM_PHY
tristate "Drivers for Broadcom PHYs"
+   select BCM_NET_PHYLIB
---help---
  Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S, BCM5464,
  BCM5481 and BCM5482 PHYs.
@@ -78,11 +82,13 @@ config BROADCOM_PHY
  config BCM63XX_PHY
tristate "Drivers for Broadcom 63xx SOCs internal PHY"
depends on BCM63XX
+   select BCM_NET_PHYLIB
---help---
  Currently supports the 6348 and 6358 PHYs.
  
  config BCM7XXX_PHY

tristate "Drivers for Broadcom 7xxx SOCs internal PHYs"
+   select BCM_NET_PHYLIB
---help---
  Currently supports the BCM7366, BCM7439, BCM7445, and
  40nm and 65nm generation of BCM7xxx Set Top Box SoCs.
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index f4e6eb9..6932475 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_QSEMI_PHY)   += qsemi.o
  obj-$(CONFIG_SMSC_PHY)+= smsc.o
  obj-$(CONFIG_TERANETICS_PHY)  += teranetics.o
  obj-$(CONFIG_VITESSE_PHY) += vitesse.o
+obj-$(CONFIG_BCM_NET_PHYLIB)   += bcm-phy-lib.o
  obj-$(CONFIG_BROADCOM_PHY)+= broadcom.o
  obj-$(CONFIG_BCM63XX_PHY) += bcm63xx.o
  obj-$(CONFIG_BCM7XXX_PHY) += bcm7xxx.o
diff --git a/drivers/net/phy/bcm-phy-lib.c b/drivers/net/phy/bcm-phy-lib.c
new file mode 100644
index 000..13e161e
--- /dev/null
+++ b/drivers/net/phy/bcm-phy-lib.c
@@ -0,0 +1,209 @@
+/*
+ * Copyright (C) 2015 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 "bcm-phy-lib.h"
+#include 
+#include 
+#include 
+#include 
+
+#define MII_BCM_CHANNEL_WIDTH 0x2000
+#define BCM_CL45VEN_EEE_ADV   0x3c
+
+int bcm_phy_write_exp(struct phy_device *phydev, u16 reg, u16 val)
+{
+   int rc;
+
+   rc = phy_write(phydev, MII_BCM54XX_EXP_SEL, reg);
+   if (rc < 0)
+   return rc;
+
+   return phy_write(phydev, MII_BCM54XX_EXP_DATA, val);
+}
+EXPORT_SYMBOL_GPL(bcm_phy_write_exp);
+
+int bcm_phy_read_exp(struct phy_device *phydev, u16 reg)
+{
+   int val;
+
+   val = phy_write(phydev, MII_BCM54XX_EXP_SEL, reg);
+   if (val < 0)
+   return val;
+
+   val = phy_read(phydev, MII_BCM54XX_EXP_DATA);
+
+   /* Restore default value.  It's O.K. if this write fails. */
+   phy_write(phydev, MII_BCM54XX_EXP_SEL, 0);
+
+   return val;
+}
+EXPORT_SYMBOL_GPL(bcm_phy_read_exp);
+
+int bcm_phy_write_misc(struct phy_device *phydev,
+  u16 reg, u16 chl, u16 val)
+{
+   int rc;
+   int tmp;
+
+   rc = phy_write(phydev, MII_BCM54XX_AUX_CTL,
+  MII_BCM54XX_AUXCTL_SHDWSEL_MISC);
+   if (rc < 0)
+   return rc;
+
+   tmp = phy_read(phydev, MII_BCM54XX_AUX_CTL);
+ 

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Tony Lindgren]

* Franklin S Cooper Jr.  [151014 09:27]:
> 
> 
> On 10/14/2015 11:18 AM, Tony Lindgren wrote:
> > * Franklin S Cooper Jr.  [151014 07:37]:
> >>
> >> On 10/14/2015 09:11 AM, Roger Quadros wrote:
> >>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>  On 10/14/2015 06:52 AM, Roger Quadros wrote:
> > Franklin,
> >
> > On 14/10/15 14:36, Roger Quadros wrote:
> >> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> >>> Switch from dma_request_channel to allow passing dma channel
> >>> information from DT rather than hardcoding a value.
> >>>
> >>> Signed-off-by: Franklin S Cooper Jr 
> >> Acked-by: Roger Quadros 
> >>
> >>> ---
> >>>  drivers/mtd/nand/omap2.c | 4 +++-
> >>>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> >>> index d0f2620..957c32f 100644
> >>> --- a/drivers/mtd/nand/omap2.c
> >>> +++ b/drivers/mtd/nand/omap2.c
> >>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct 
> >>> platform_device *pdev)
> >>>   dma_cap_zero(mask);
> >>>   dma_cap_set(DMA_SLAVE, mask);
> >>>   sig = OMAP24XX_DMA_GPMC;
> >>> - info->dma = dma_request_channel(mask, 
> >>> omap_dma_filter_fn, );
> >>> + info->dma = dma_request_slave_channel_compat(mask,
> >>> + omap_dma_filter_fn, , pdev->dev.parent, 
> >>> "rxtx");
> >>> +
> > Just discovered that you are using the parent device node.
> >
> > How about moving the dma bindings to the nand node instead and using
> > pdev->dev here?
>  Roger,
> 
>  From what I can tell the interrupt number and the dma channel will 
>  always be
>  the same no matter what. Doesn't matter if you have multiple nands or a
>  combination of nands and nors. Since that is the case I think it just 
>  makes
>  sense to leave it in the gpmc parent node and define it once.
> >>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
> >>> or only for NAND?
> >> The dma seems tied to the prefetch. From what I can tell the prefetch is 
> >> only
> >> used by nand.
> >>> Let's also get Tony's inputs on this.
> >> Sure.
> > Hmm so what would keep other devices from using the prefetch
> Looking at the TRM any references to the prefetch are always with respect to
> NAND.
> 
> I also see the below mentioned in the TRM.
> Pre-fetch and write posting engine associated with system DMA to get full 
> performance from NAND
> device with minimum impact on NOR/SRAM concurrent access.

OK up to you guys to figure out if it may be usable in a generic way then :)

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

[PATCH 3/6] mfd: axp20x: Add support for RSB based AXP223 PMIC

[Chen-Yu Tsai]

The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/mfd/Kconfig| 12 ++
 drivers/mfd/Makefile   |  1 +
 drivers/mfd/axp20x-core.c  |  2 +
 drivers/mfd/axp20x-rsb.c   | 93 ++
 include/linux/mfd/axp20x.h |  1 +
 5 files changed, 109 insertions(+)
 create mode 100644 drivers/mfd/axp20x-rsb.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 9ba3feb3f2fc..6e5edb61d42e 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -84,6 +84,7 @@ config MFD_BCM590XX
 config MFD_AXP20X
bool "X-Powers AXP series PMICs"
select MFD_AXP20X_I2C
+   select MFD_AXP20X_RSB
 
 config MFD_AXP20X_CORE
bool
@@ -102,6 +103,17 @@ config MFD_AXP20X_I2C
  components like regulators or the PEK (Power Enable Key) under the
  corresponding menus.
 
+config MFD_AXP20X_RSB
+   bool "X-Powers AXP series RSB PMICs"
+   select MFD_AXP20X_CORE
+   depends on SUNXI_RSB=y
+   help
+ If you say Y here you get support for the X-Powers AXP series RSB
+ based power management ICs (PMICs).
+ This driver include only the core APIs. You have to select individual
+ components like regulators or the PEK (Power Enable Key) under the
+ corresponding menus.
+
 config MFD_CROS_EC
tristate "ChromeOS Embedded Controller"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index ce3ad5fd4e2f..1eb278619dd6 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -108,6 +108,7 @@ obj-$(CONFIG_MFD_DA9052_SPI)+= da9052-spi.o
 obj-$(CONFIG_MFD_DA9052_I2C)   += da9052-i2c.o
 obj-$(CONFIG_MFD_AXP20X_CORE)  += axp20x-core.o
 obj-$(CONFIG_MFD_AXP20X_I2C)   += axp20x-i2c.o
+obj-$(CONFIG_MFD_AXP20X_RSB)   += axp20x-rsb.o
 
 obj-$(CONFIG_MFD_LP3943)   += lp3943.o
 obj-$(CONFIG_MFD_LP8788)   += lp8788.o lp8788-irq.o
diff --git a/drivers/mfd/axp20x-core.c b/drivers/mfd/axp20x-core.c
index dd33548d93c4..baecccb6d400 100644
--- a/drivers/mfd/axp20x-core.c
+++ b/drivers/mfd/axp20x-core.c
@@ -32,6 +32,7 @@ static const char * const axp20x_model_names[] = {
"AXP202",
"AXP209",
"AXP221",
+   "AXP223",
"AXP288",
 };
 
@@ -575,6 +576,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x, struct 
device *dev)
axp20x->regmap_irq_chip = _regmap_irq_chip;
break;
case AXP221_ID:
+   case AXP223_ID:
axp20x->nr_cells = ARRAY_SIZE(axp22x_cells);
axp20x->cells = axp22x_cells;
axp20x->regmap_cfg = _regmap_config;
diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
new file mode 100644
index ..5d053d177717
--- /dev/null
+++ b/drivers/mfd/axp20x-rsb.c
@@ -0,0 +1,93 @@
+/*
+ * axp20x-rsb.c - RSB driver for the X-Powers' Power Management ICs
+ *
+ * AXP20x typically comprises an adaptive USB-Compatible PWM charger, BUCK 
DC-DC
+ * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
+ * as well as configurable GPIOs.
+ *
+ * This driver supports the RSB variants.
+ *
+ * Author: Chen-Yu Tsai 
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static const struct of_device_id axp20x_sunxi_rsb_of_match[] = {
+   { .compatible = "x-powers,axp223", .data = (void *) AXP223_ID },
+   { },
+};
+MODULE_DEVICE_TABLE(of, axp20x_sunxi_rsb_of_match);
+
+static int axp20x_sunxi_rsb_match_device(struct axp20x_dev *axp20x,
+struct device *dev)
+{
+   const struct of_device_id *of_id;
+
+   of_id = of_match_device(axp20x_sunxi_rsb_of_match, dev);
+   if (!of_id) {
+   dev_err(dev, "Unable to match OF ID\n");
+   return -ENODEV;
+   }
+   axp20x->variant = (long) of_id->data;
+
+   return axp20x_match_device(axp20x, dev);
+}
+
+static int axp20x_sunxi_rsb_probe(struct sunxi_rsb_device *rdev)
+{
+   struct axp20x_dev *axp20x;
+   int ret;
+
+   axp20x = devm_kzalloc(>dev, sizeof(*axp20x), GFP_KERNEL);
+   if (!axp20x)
+   return -ENOMEM;
+
+   ret = axp20x_sunxi_rsb_match_device(axp20x, >dev);
+   if (ret)
+   return ret;
+
+   axp20x->dev = >dev;
+   axp20x->irq = rdev->irq;
+   sunxi_rsb_device_set_drvdata(rdev, axp20x);
+
+   axp20x->regmap = devm_regmap_init_sunxi_rsb(rdev, axp20x->regmap_cfg);
+   if (IS_ERR(axp20x->regmap)) {
+   ret = PTR_ERR(axp20x->regmap);
+   

Re: [PATCH v1 1/2] clk: samsung: exynos5250: Add DISP1 clocks

[Stephen Boyd]

On 10/14, Tomeu Vizoso wrote:
> When the DISP1 power domain is powered off, there's two clocks that need
> to be temporarily reparented to OSC, and back to their original parents
> when the domain is powered on again.
> 
> We expose these two clocks in the DT bindings so that the DT node of the
> power domain can reference them.
> 
> Signed-off-by: Tomeu Vizoso 
> ---

Acked-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 02/11] phy: exynos-ufs: add UFS PHY driver for EXYNOS SoC

[Kishon Vijay Abraham I]

On Wednesday 14 October 2015 09:43 PM, Alim Akhtar wrote:
> Hi,
> 
> On Wed, Oct 14, 2015 at 9:31 PM, Kishon Vijay Abraham I  wrote:
>> Hi,
>>
>> On Wednesday 14 October 2015 06:25 PM, Alim Akhtar wrote:
>>> From: Seungwon Jeon 
>>>
>>> This patch introduces Exynos UFS PHY driver. This driver
>>> supports to deal with phy calibration and power control
>>> according to UFS host driver's behavior.
>>>
>>> Signed-off-by: Seungwon Jeon 
>>> Signed-off-by: Alim Akhtar 
>>> Cc: Kishon Vijay Abraham I 
>>> ---
>>>  drivers/phy/Kconfig|7 +
>>>  drivers/phy/Makefile   |1 +
>>>  drivers/phy/phy-exynos-ufs.c   |  257 
>>> 
>>>  drivers/phy/phy-exynos-ufs.h   |   88 
>>>  drivers/phy/phy-exynos7-ufs.h  |   89 +
>>>  include/linux/phy/phy-exynos-ufs.h |  101 ++
>>>  6 files changed, 543 insertions(+)
>>>  create mode 100644 drivers/phy/phy-exynos-ufs.c
>>>  create mode 100644 drivers/phy/phy-exynos-ufs.h
>>>  create mode 100644 drivers/phy/phy-exynos7-ufs.h
>>>  create mode 100644 include/linux/phy/phy-exynos-ufs.h
>>>
>>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>>> index 47da573d0bab..499eec4a967c 100644
>>> --- a/drivers/phy/Kconfig
>>> +++ b/drivers/phy/Kconfig
>>> @@ -371,4 +371,11 @@ config PHY_BRCMSTB_SATA
>>> Enable this to support the SATA3 PHY on 28nm Broadcom STB SoCs.
>>> Likely useful only with CONFIG_SATA_BRCMSTB enabled.
>>>
>>> +config PHY_EXYNOS_UFS
>>> + tristate "EXYNOS SoC series UFS PHY driver"
>>> + depends on OF && ARCH_EXYNOS || COMPILE_TEST
>>> + select GENERIC_PHY
>>> + help
>>> +   Support for UFS PHY on Samsung EXYNOS chipsets.
>>> +
>>>  endmenu
>>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>>> index a5b18c18fc12..2a312ca20795 100644
>>> --- a/drivers/phy/Makefile
>>> +++ b/drivers/phy/Makefile
>>> @@ -46,3 +46,4 @@ obj-$(CONFIG_PHY_QCOM_UFS)  += phy-qcom-ufs-qmp-14nm.o
>>>  obj-$(CONFIG_PHY_TUSB1210)   += phy-tusb1210.o
>>>  obj-$(CONFIG_PHY_BRCMSTB_SATA)   += phy-brcmstb-sata.o
>>>  obj-$(CONFIG_PHY_PISTACHIO_USB)  += phy-pistachio-usb.o
>>> +obj-$(CONFIG_PHY_EXYNOS_UFS) += phy-exynos-ufs.o
>>> diff --git a/drivers/phy/phy-exynos-ufs.c b/drivers/phy/phy-exynos-ufs.c
>>> new file mode 100644
>>> index ..77330b85e3f8
>>> --- /dev/null
>>> +++ b/drivers/phy/phy-exynos-ufs.c
>>> @@ -0,0 +1,257 @@
>>> +/*
>>> + * UFS PHY driver for Samsung EXYNOS SoC
>>> + *
>>> + * Copyright (C) 2015 Samsung Electronics Co., Ltd.
>>> + * Author: Seungwon Jeon 
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + */
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include "phy-exynos-ufs.h"
>>> +
>>> +#define for_each_phy_lane(phy, i) \
>>> + for (i = 0; i < (phy)->lane_cnt; i++)
>>> +#define for_each_phy_cfg(cfg) \
>>> + for (; (cfg)->id; (cfg)++)
>>> +
>>> +#define PHY_DEF_LANE_CNT 1
>>> +
>>> +static void exynos_ufs_phy_config(struct exynos_ufs_phy *phy,
>>> + const struct exynos_ufs_phy_cfg *cfg, u8 lane)
>>> +{
>>> + enum {LANE_0, LANE_1}; /* lane index */
>>> +
>>> + switch (lane) {
>>> + case LANE_0:
>>> + writel(cfg->val, (phy)->reg_pma + cfg->off_0);
>>> + break;
>>> + case LANE_1:
>>> + if (cfg->id == PHY_TRSV_BLK)
>>> + writel(cfg->val, (phy)->reg_pma + cfg->off_1);
>>> + break;
>>> + }
>>> +}
>>> +
>>> +static bool match_cfg_to_pwr_mode(u8 desc, u8 required_pwr)
>>> +{
>>> + if (IS_PWR_MODE_ANY(desc))
>>> + return true;
>>> +
>>> + if (IS_PWR_MODE_HS(required_pwr) && IS_PWR_MODE_HS_ANY(desc))
>>> + return true;
>>> +
>>> + if (COMP_PWR_MODE(required_pwr, desc))
>>> + return true;
>>> +
>>> + if (COMP_PWR_MODE_MD(required_pwr, desc) &&
>>> + COMP_PWR_MODE_GEAR(required_pwr, desc) &&
>>> + COMP_PWR_MODE_SER(required_pwr, desc))
>>> + return true;
>>> +
>>> + return false;
>>> +}
>>> +
>>> +static int exynos_ufs_phy_calibrate(struct phy *phy,
>>> + enum phy_cfg_tag tag, u8 pwr)
>>> +{
>>> + struct exynos_ufs_phy *ufs_phy = get_exynos_ufs_phy(phy);
>>> + struct exynos_ufs_phy_cfg **cfgs = ufs_phy->cfg;
>>> + const struct exynos_ufs_phy_cfg *cfg;
>>> + int i;
>>> +
>>> + if (unlikely(tag < CFG_PRE_INIT || tag >= CFG_TAG_MAX)) {
>>> + 

Re: [GIT PULL]Hisilicon ARMv7 based SoCs DT updates for V4.4

[Wei Xu]

On 10/14/2015 4:53 PM, Arnd Bergmann wrote:
> On Monday 12 October 2015 15:51:23 Wei Xu wrote:
>> Hi Arnd, Hi Olof, Hi Kevin,
>>
>> Please help to pull the following changes.
>> Thanks!
> 

Hi Arnd,

> Pulled into next/dt, thanks!

Thanks!

Best Regards,
Wei

> 
>   Arnd
> 
> .
> 

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

Re: [PATCH 2/5] arm: dts: lpc32xx: fix improper usage of ranges property

[Joachim Eastwood]

Hi Arnd,

On 14 October 2015 at 15:52, Arnd Bergmann  wrote:
> On Wednesday 14 October 2015 02:13:49 Vladimir Zapolskiy wrote:
>> Ok, practically it should work for my purposes, but the change must be
>> done along with added EMC device node description.
>>
>> I'm not so confident that it is correct to add description of static
>> memory banks to ahb node though, please give me a short confirmation,
>
> The DT should reflect whichever memory ranges are accessible
> on the bus. I've looked up the memory map in the data sheet, and
> I think a reasonable representation would be
>
> /ahb {
> ranges = <0x2000 0x2000 0x1000>, /* AHB port 5 */
>  <0x3000 0x3000 0x1000>, /* AHB port 6 */
>  <0x4000 0x4000 0x1000>, /* AHB port 7 */
>  <0x8000 0x8000 0x4000>, /* EMC DYCS0/1 */
>  <0xE000 0xE000 0x0400>; /* EMC CS0-3 */
>
> apb {
> ranges = <0x2008 0x2008 0x0002>;
> };
>
> };
>
> alternatively, each AHB port could be a separate node, with a
> more direct translation like
>
> /ahb5 {
> ranges = <0 0x2000 0x1000>;
>
> apb {
> ranges = <0 0x8 0x2>;
> };
> };
> /ahb6 {
> ranges = <0 0x3000 0x1000>,   /* AHB registers */
>  <0x8000 0x8000 0x4000>, /* EMC DYCS0/1 */
>  <0xE000 0xE000 0x0400>; /* EMC CS0-3 */
>
> memory-controller@108 {
> reg = <0x108 0x1>;
> };
> };

Sorry for hijacking the thread, but I have related question to this.

What is the advantage of using a hierarchical bus structure in dt?
I thought the recommendation, at least for new device trees, was to
keep it flat under a "soc"-node.

If doesn't offer any advantages why not remove instead of adding the
ranges property which seems to grow a bit complex now?
Of course removing it would create a lot of churn because of the
re-indentation but at least the end result would be simpler.


regards,
Joachim Eastwood
--
To unsubscribe from this list: send the line "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 4/5] clk: iproc: define Broadcom NS2 iProc clock binding

[Ray Jui]

On 10/14/2015 8:44 AM, Jon Mason wrote:
> On Tue, Oct 13, 2015 at 03:24:52PM -0700, Ray Jui wrote:
>> Same as this patch. I thought device tree binding document should go
>> with the clock driver changes.
>>
>> Strictly speaking, device tree binding document should always go before
>> the driver changes. In the binding document the DT interface is defined,
>> then changes are implemented in the driver.
> 
> I split them off this way due to the clk maintainer not wanting to
> pull in any device tree changes.  Since the documentation is for the
> device tree enties, it makes logical sense to me that they be in the
> same device tree series.  If Stephen will pull these in with the clk
> changes, I am more than happy to have it done by him :)
> 
> Thanks,
> Jon

Yeah the clock maintainers do not pull in device tree changes like
*.dtsi and *.dts. But they do take changes including the binding
documents and clock driver changes. You can confirm with Stephen.

Thanks,

Ray
--
To unsubscribe from this list: send the line "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] gpio/xilinx: enable for MIPS

[Sören Brinkmann]

On Wed, 2015-10-14 at 05:57PM +0200, Lars-Peter Clausen wrote:
> On 10/14/2015 05:18 PM, Sören Brinkmann wrote:
> > On Wed, 2015-10-14 at 01:51PM +0100, Zubair Lutfullah Kakakhel wrote:
> >> MIPSfpga uses the axi gpio controller. Enable the driver for MIPS.
> >>
> >> Signed-off-by: Zubair Lutfullah Kakakhel 
> >> ---
> >>  drivers/gpio/Kconfig | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> >> index 8949b3f..58e9afd 100644
> >> --- a/drivers/gpio/Kconfig
> >> +++ b/drivers/gpio/Kconfig
> >> @@ -508,7 +508,7 @@ config GPIO_XGENE_SB
> >>  
> >>  config GPIO_XILINX
> >>tristate "Xilinx GPIO support"
> >> -  depends on OF_GPIO && (PPC || MICROBLAZE || ARCH_ZYNQ || X86)
> >> +  depends on OF_GPIO && (PPC || MICROBLAZE || ARCH_ZYNQ || X86 || MIPS)
> > 
> > Hmm, in general, this driver is hopefully generic enough that it doesn't
> > have any real architecture dependencies. And I suspect, we want to
> > enable this driver for ARM64 for ZynqMP soon too. Should we probably
> > drop these arch dependencies completely? It seems to become quite a long 
> > list.
> 
> I've been thinking about this a while ago. This is certainly not the only
> driver affected by this problem. But the thing is people always complain if
> new symbols become visable in Kconfig that don't apply to their platform.
> 
> Maybe we should introduce a HAS_REPROGRAMABLE_LOGIC (or similar) feature
> Kconfig symbol and let platforms which have a FPGA select it and let drivers
> for FPGA peripherals depend on it.

Sounds like a good idea to me. But, does that work for all use-cases.
E.g. if you plug some PCIe card with an FPGA into an x86(_64) machine.
That would allow you to use those drivers, but I'm not sure how that
could pull in the new config symbol.

Sören
--
To unsubscribe from this list: send the line "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/5] arm: dts: lpc32xx: add device node for the second pwm controller

[Joachim Eastwood]

Hi Vladimir,

On 13 October 2015 at 01:54, Vladimir Zapolskiy  wrote:
> LPC32xx SoCs have two independent PWM controllers, they have different
> clock parents, clock gates and even slightly different controls,
> each of these two PWM controllers has one output channel. Due to
> almost similar controls arranged in a row it is incorrectly assumed
> that there is one PWM controller with two channels, fix this problem
> in lpc32xx.dtsi, which at the moment prevents separate configuration
> of different clock parents and gates for both PWM controllers.
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  arch/arm/boot/dts/lpc32xx.dtsi | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
> index 929458d..f4d2a0e 100644
> --- a/arch/arm/boot/dts/lpc32xx.dtsi
> +++ b/arch/arm/boot/dts/lpc32xx.dtsi
> @@ -286,9 +286,15 @@
> status = "disabled";
> };
>
> -   pwm: pwm@4005C000 {
> +   pwm1: pwm@4005C000 {
> compatible = "nxp,lpc3220-pwm";
> -   reg = <0x4005C000 0x8>;
> +   reg = <0x4005C000 0x4>;
> +   status = "disabled";
> +   };
> +
> +   pwm2: pwm@4005C004 {
> +   compatible = "nxp,lpc3220-pwm";
> +   reg = <0x4005C004 0x4>;
> status = "disabled";
> };
> };

I am not really against your change, but...

What's wrong with a binding like the one below?
pwm: pwm@0x4005c000 {
compatible = "nxp,lpc3220-pwm";
reg = <0x4005C000 0x8>;
clocks =< CLK_PWM1,  CLK_PWM2>;
clock-names = "pwm1", "pwm2";
#pwm-cells = <3>;
};

With two clocks and where the first pwm-cell would select either PWM1 or PWM2.

Seems like the driver only handle one clock, but should be fairly easy to fix.

Note: with your DT change you would also need to change the driver
since it currently sets npwm to 2.


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

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Franklin S Cooper Jr.]

On 10/14/2015 11:18 AM, Tony Lindgren wrote:
> * Franklin S Cooper Jr.  [151014 07:37]:
>>
>> On 10/14/2015 09:11 AM, Roger Quadros wrote:
>>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
 On 10/14/2015 06:52 AM, Roger Quadros wrote:
> Franklin,
>
> On 14/10/15 14:36, Roger Quadros wrote:
>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>> Switch from dma_request_channel to allow passing dma channel
>>> information from DT rather than hardcoding a value.
>>>
>>> Signed-off-by: Franklin S Cooper Jr 
>> Acked-by: Roger Quadros 
>>
>>> ---
>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>> index d0f2620..957c32f 100644
>>> --- a/drivers/mtd/nand/omap2.c
>>> +++ b/drivers/mtd/nand/omap2.c
>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device 
>>> *pdev)
>>> dma_cap_zero(mask);
>>> dma_cap_set(DMA_SLAVE, mask);
>>> sig = OMAP24XX_DMA_GPMC;
>>> -   info->dma = dma_request_channel(mask, 
>>> omap_dma_filter_fn, );
>>> +   info->dma = dma_request_slave_channel_compat(mask,
>>> +   omap_dma_filter_fn, , pdev->dev.parent, 
>>> "rxtx");
>>> +
> Just discovered that you are using the parent device node.
>
> How about moving the dma bindings to the nand node instead and using
> pdev->dev here?
 Roger,

 From what I can tell the interrupt number and the dma channel will always 
 be
 the same no matter what. Doesn't matter if you have multiple nands or a
 combination of nands and nors. Since that is the case I think it just makes
 sense to leave it in the gpmc parent node and define it once.
>>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
>>> or only for NAND?
>> The dma seems tied to the prefetch. From what I can tell the prefetch is only
>> used by nand.
>>> Let's also get Tony's inputs on this.
>> Sure.
> Hmm so what would keep other devices from using the prefetch
Looking at the TRM any references to the prefetch are always with respect to
NAND.

I also see the below mentioned in the TRM.
Pre-fetch and write posting engine associated with system DMA to get full 
performance from NAND
device with minimum impact on NOR/SRAM concurrent access.
>
> 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

[PATCH 0/6] mfd: axp20x: Add support for RSB based AXP223

[Chen-Yu Tsai]

Hi everyone,

This series adds support for the Reduced Serial Bus based AXP223 PMIC.
The AXP223 is functionally identical to the AXP221, which we already
support. Only some default values for the regulators are different.
The defaults fit their recommended application, paired with different
SoCs.

Patch 1 adds AXP223 to the list of supported chips in the DT binding.

Patch 2 splits the axp20x mfd driver into 2 parts, a core library, and
an I2C driver.

Patch 3 adds an RSB based driver for the AXP223.

Patch 4 adds support for the AXP223 regulators

Patch 5 adds the NMI interrupt controller to the sun8i dtsi. This is
chained to the GIC, and exposes an external NMI pin for the PMIC.

Patch 6 enables the AXP223 PMIC and its regulators for the Sinlinx
SinA33.

Another patch enabling the PMIC for the A23/A33 Q8 format tablets
is available, but I'll send it after I get the simplefb regulator
support merged. Otherwise the LCD would get powered down. The whole
branch is available at https://github.com/wens/linux/tree/axp223.

This series is a bit messy to merge. RSB support has just been merged
and is queued up for 4.4. It is available at

  https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git
  
  tags/sunxi-drivers-for-4.4

Patch 4 depends on patch 3 for the new ID, and RSB support, obviously.
And patch 3 depends on patch 2. I suppose with Lee's ack, Mark can
merge the tag above, or wait for 4.4-rc1, then the first 4 patches.


Regards
ChenYu


Chen-Yu Tsai (6):
  mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings
  mfd: axp20x: Split the driver into core and i2c bits
  mfd: axp20x: Add support for RSB based AXP223 PMIC
  regulator: axp20x: Support new AXP223 PMIC
  ARM: dts: sun8i: Add NMI interrupt controller node
  ARM: dts: sun8i: sinlinx-sina33: Add AXP223 PMIC device and regulator
nodes

 Documentation/devicetree/bindings/mfd/axp20x.txt |   7 +-
 arch/arm/boot/dts/sun8i-a23-a33.dtsi |   8 ++
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts   |  79 +-
 drivers/mfd/Kconfig  |  30 +-
 drivers/mfd/Makefile |   4 +-
 drivers/mfd/{axp20x.c => axp20x-core.c}  | 107 +++
 drivers/mfd/axp20x-i2c.c | 127 +++
 drivers/mfd/axp20x-rsb.c |  93 +
 drivers/regulator/axp20x-regulator.c |   3 +
 include/linux/mfd/axp20x.h   |  34 +-
 10 files changed, 386 insertions(+), 106 deletions(-)
 rename drivers/mfd/{axp20x.c => axp20x-core.c} (87%)
 create mode 100644 drivers/mfd/axp20x-i2c.c
 create mode 100644 drivers/mfd/axp20x-rsb.c

-- 
2.6.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 5/6] ARM: dts: sun8i: Add NMI interrupt controller node

[Chen-Yu Tsai]

The NMI interrupt controller is in charge of the NMI pin exposed by
the SoC to the PMIC. The PMIC signals interrupts through this.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a23-a33.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi 
b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 828aaf52c342..a1e3acd325f4 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -579,6 +579,14 @@
 ;
};
 
+   nmi_intc: interrupt-controller@01f00c0c {
+   compatible = "allwinner,sun6i-a31-sc-nmi";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   reg = <0x01f00c0c 0x38>;
+   interrupts = ;
+   };
+
prcm@01f01400 {
compatible = "allwinner,sun8i-a23-prcm";
reg = <0x01f01400 0x200>;
-- 
2.6.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 4/6] regulator: axp20x: Support new AXP223 PMIC

[Chen-Yu Tsai]

The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/regulator/axp20x-regulator.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index 35de22fdb7a0..55cce8125716 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -244,6 +244,7 @@ static int axp20x_set_dcdc_freq(struct platform_device 
*pdev, u32 dcdcfreq)
step = 75;
break;
case AXP221_ID:
+   case AXP223_ID:
min = 1800;
max = 4050;
def = 3000;
@@ -322,6 +323,7 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev 
*rdev, int id, u32 work
break;
 
case AXP221_ID:
+   case AXP223_ID:
if (id < AXP22X_DCDC1 || id > AXP22X_DCDC5)
return -EINVAL;
 
@@ -360,6 +362,7 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
nregulators = AXP20X_REG_ID_MAX;
break;
case AXP221_ID:
+   case AXP223_ID:
regulators = axp22x_regulators;
nregulators = AXP22X_REG_ID_MAX;
break;
-- 
2.6.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 2/3] ARM: dts: add SMP support for Broadcom NSP

[Kapil Hali]

Add device tree changes required for providing SMP support
for Broadcom Northstar Plus SoC.

Signed-off-by: Kapil Hali 
---
 arch/arm/boot/dts/bcm-nsp.dtsi | 33 +
 1 file changed, 21 insertions(+), 12 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 58aca27..d1875d9 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -40,24 +40,33 @@
model = "Broadcom Northstar Plus SoC";
interrupt-parent = <>;
 
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   enable-method = "brcm,bcm-nsp-smp";
+   secondary-boot-reg = <0x042c>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   next-level-cache = <>;
+   reg = <0x0>;
+   };
+
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   next-level-cache = <>;
+   reg = <0x1>;
+   };
+   };
+
mpcore {
compatible = "simple-bus";
ranges = <0x 0x1902 0x3000>;
#address-cells = <1>;
#size-cells = <1>;
 
-   cpus {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   cpu@0 {
-   device_type = "cpu";
-   compatible = "arm,cortex-a9";
-   next-level-cache = <>;
-   reg = <0x0>;
-   };
-   };
-
L2: l2-cache {
compatible = "arm,pl310-cache";
reg = <0x2000 0x1000>;
-- 
2.1.0

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

Re: [PATCH-RFC 6/7] drivers: of: ifdef out cmdline section

[Rob Herring]

On Wed, Oct 14, 2015 at 9:48 AM, Daniel Walker  wrote:
>
>
> There's one last little wrinkle .. In the current setup the defconfig
> CONFIG_CMDLINE="" is used as a default in case the device tree has nothing
> in it. In my changes, there is no identical functionality. The only similar
> thing I have is the the CONFIG_CMDLINE_APPEND="" . The main difference is
> that in the current implementation CONFIG_CMDLINE="" doesn't get added at
> all if there is a device tree bootargs, but with my implementation this line
> would be added unconditionally. It would represent a subtle change where
> people would have to add into the DT bootargs something to override what
> might be in the default command line.

So CMDLINE_EXTEND would be equivalent to your version, but it looks
like CMDLINE_EXTEND is not used in the DT case. Perhaps you can add
the option? You already have OVERRIDE which is equivalent to FORCE.


> For example,
>
> if a config has CONFIG_CMDLINE_APPEND="debug" then they would have to add a
> "loglevel=7" into the DT bootargs to get back to normal. I wouldn't think
> people would want "debug" as the default, but oddly enough some of the
> configs do have this. Some of them also have default ip address setting,
> nfsroot= settings, and loglevel= settings.

Or they would have to remove the kernel default from their config.
That might be acceptable. You could have a case where you have 1
kernel binary and 2 different bootloaders where you expect the
bootloader's cmdline used in one case and the kernel's in the other.
Seems unlikely, but it would be an ABI break.

I would not judge people's choices of defaults making sense...

> What are your thoughts on this ? I think using the append type default makes
> more sense because it's actually setting up global defaults. The current
> complete replacement scheme seems to set the stage for people to make an
> entirely custom default for a single development machine, which IMO doesn't
> make sense. However, I'm not sure what the intent is with the current setup.

People will want a path to support up to the current 3 options (use
bootloader's cmdline, append bootloader cmdline to default, and force
kernel default) and you have to assume changing bootloader is not an
option.

Rob

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

Re: [PATCH 2/5] gpio/xilinx: enable for MIPS

[Sören Brinkmann]

On Wed, 2015-10-14 at 07:24PM +0200, Lars-Peter Clausen wrote:
> On 10/14/2015 06:54 PM, Sören Brinkmann wrote:
> > On Wed, 2015-10-14 at 05:57PM +0200, Lars-Peter Clausen wrote:
> >> On 10/14/2015 05:18 PM, Sören Brinkmann wrote:
> >>> On Wed, 2015-10-14 at 01:51PM +0100, Zubair Lutfullah Kakakhel wrote:
>  MIPSfpga uses the axi gpio controller. Enable the driver for MIPS.
> 
>  Signed-off-by: Zubair Lutfullah Kakakhel 
>  ---
>   drivers/gpio/Kconfig | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
>  diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>  index 8949b3f..58e9afd 100644
>  --- a/drivers/gpio/Kconfig
>  +++ b/drivers/gpio/Kconfig
>  @@ -508,7 +508,7 @@ config GPIO_XGENE_SB
>   
>   config GPIO_XILINX
>   tristate "Xilinx GPIO support"
>  -depends on OF_GPIO && (PPC || MICROBLAZE || ARCH_ZYNQ || X86)
>  +depends on OF_GPIO && (PPC || MICROBLAZE || ARCH_ZYNQ || X86 || 
>  MIPS)
> >>>
> >>> Hmm, in general, this driver is hopefully generic enough that it doesn't
> >>> have any real architecture dependencies. And I suspect, we want to
> >>> enable this driver for ARM64 for ZynqMP soon too. Should we probably
> >>> drop these arch dependencies completely? It seems to become quite a long 
> >>> list.
> >>
> >> I've been thinking about this a while ago. This is certainly not the only
> >> driver affected by this problem. But the thing is people always complain if
> >> new symbols become visable in Kconfig that don't apply to their platform.
> >>
> >> Maybe we should introduce a HAS_REPROGRAMABLE_LOGIC (or similar) feature
> >> Kconfig symbol and let platforms which have a FPGA select it and let 
> >> drivers
> >> for FPGA peripherals depend on it.
> > 
> > Sounds like a good idea to me. But, does that work for all use-cases.
> > E.g. if you plug some PCIe card with an FPGA into an x86(_64) machine.
> > That would allow you to use those drivers, but I'm not sure how that
> > could pull in the new config symbol.
> 
> Hm, right. We could also make it a user-selectable config symbol. In that
> case you only need to disable one symbol when you don't have FPGA support
> rather than one for each driver. Although I'm not quite sure where to put
> such a symbol.

Eventually, the FPGA manager subsystem could probably provide some high
level config symbols. Though, it is probably also not given that every
FPGA-enabled platform needs the FPGA manager.

Sören
--
To unsubscribe from this list: send the line "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 3/5] net: phy: Add Broadcom phy library for common interfaces

[Florian Fainelli]

On 14/10/15 10:33, Robert E Cochran wrote:
> 
> 
> On 10/06/2015 03:25 PM, Arun Parameswaran wrote:
>> This patch adds the Broadcom phy library to consolidate common
>> interfaces shared by Broadcom phy's.
> 
> The BCM54612E is included in the Broadcom Community part portfolio
> (https://community.broadcom.com).  However, I don't see this part
> explicitly supported by your phy library ( e.g., not included in
> broadcom_drivers[] in broadcom.c ).

These are external PHY products which have a different support channel
and engineering teams.

> 
> Can you please comment on whether this part is supported or the extent
> of changes required to establish and support a robust GigE connection
> between RGMII and CU?

This probably deserves a separate thread rather than hijacking an
existing one?

> 
> We're considering this part for a new embedded design, and we need an
> open source driver for it.
> 
> Thanks
> 
> Bob
> 
> 
> 
>>
>> Moved the common interfaces to the 'bcm-phy-lib.c' and updated
>> the Broadcom PHY drivers to use the new APIs.
>>
>> Signed-off-by: Arun Parameswaran 
>> ---
>>   drivers/net/phy/Kconfig   |   6 ++
>>   drivers/net/phy/Makefile  |   1 +
>>   drivers/net/phy/bcm-phy-lib.c | 209
>> ++
>>   drivers/net/phy/bcm-phy-lib.h |  37 
>>   drivers/net/phy/bcm63xx.c |  38 +---
>>   drivers/net/phy/bcm7xxx.c | 127 ++---
>>   drivers/net/phy/broadcom.c| 149 +-
>>   include/linux/brcmphy.h   |  22 +
>>   8 files changed, 333 insertions(+), 256 deletions(-)
>>   create mode 100644 drivers/net/phy/bcm-phy-lib.c
>>   create mode 100644 drivers/net/phy/bcm-phy-lib.h
>>
>> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
>> index b57f6c2..606fdc9 100644
>> --- a/drivers/net/phy/Kconfig
>> +++ b/drivers/net/phy/Kconfig
>> @@ -69,8 +69,12 @@ config SMSC_PHY
>>   ---help---
>> Currently supports the LAN83C185, LAN8187 and LAN8700 PHYs
>>   +config BCM_NET_PHYLIB
>> +tristate
>> +
>>   config BROADCOM_PHY
>>   tristate "Drivers for Broadcom PHYs"
>> +select BCM_NET_PHYLIB
>>   ---help---
>> Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S,
>> BCM5464,
>> BCM5481 and BCM5482 PHYs.
>> @@ -78,11 +82,13 @@ config BROADCOM_PHY
>>   config BCM63XX_PHY
>>   tristate "Drivers for Broadcom 63xx SOCs internal PHY"
>>   depends on BCM63XX
>> +select BCM_NET_PHYLIB
>>   ---help---
>> Currently supports the 6348 and 6358 PHYs.
>> config BCM7XXX_PHY
>>   tristate "Drivers for Broadcom 7xxx SOCs internal PHYs"
>> +select BCM_NET_PHYLIB
>>   ---help---
>> Currently supports the BCM7366, BCM7439, BCM7445, and
>> 40nm and 65nm generation of BCM7xxx Set Top Box SoCs.
>> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
>> index f4e6eb9..6932475 100644
>> --- a/drivers/net/phy/Makefile
>> +++ b/drivers/net/phy/Makefile
>> @@ -12,6 +12,7 @@ obj-$(CONFIG_QSEMI_PHY)+= qsemi.o
>>   obj-$(CONFIG_SMSC_PHY)+= smsc.o
>>   obj-$(CONFIG_TERANETICS_PHY)+= teranetics.o
>>   obj-$(CONFIG_VITESSE_PHY)+= vitesse.o
>> +obj-$(CONFIG_BCM_NET_PHYLIB)+= bcm-phy-lib.o
>>   obj-$(CONFIG_BROADCOM_PHY)+= broadcom.o
>>   obj-$(CONFIG_BCM63XX_PHY)+= bcm63xx.o
>>   obj-$(CONFIG_BCM7XXX_PHY)+= bcm7xxx.o
>> diff --git a/drivers/net/phy/bcm-phy-lib.c
>> b/drivers/net/phy/bcm-phy-lib.c
>> new file mode 100644
>> index 000..13e161e
>> --- /dev/null
>> +++ b/drivers/net/phy/bcm-phy-lib.c
>> @@ -0,0 +1,209 @@
>> +/*
>> + * Copyright (C) 2015 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 "bcm-phy-lib.h"
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define MII_BCM_CHANNEL_WIDTH 0x2000
>> +#define BCM_CL45VEN_EEE_ADV   0x3c
>> +
>> +int bcm_phy_write_exp(struct phy_device *phydev, u16 reg, u16 val)
>> +{
>> +int rc;
>> +
>> +rc = phy_write(phydev, MII_BCM54XX_EXP_SEL, reg);
>> +if (rc < 0)
>> +return rc;
>> +
>> +return phy_write(phydev, MII_BCM54XX_EXP_DATA, val);
>> +}
>> +EXPORT_SYMBOL_GPL(bcm_phy_write_exp);
>> +
>> +int bcm_phy_read_exp(struct phy_device *phydev, u16 reg)
>> +{
>> +int val;
>> +
>> +val = phy_write(phydev, MII_BCM54XX_EXP_SEL, reg);
>> +if (val < 0)
>> +return val;
>> +
>> +val = phy_read(phydev, MII_BCM54XX_EXP_DATA);
>> +
>> +/* Restore default value.  It's 

[PATCH 0/3] SMP support for Broadcom NSP

[Kapil Hali]

Hi,

This series adds SMP support for Broadcom's Northstar Plus SoC.

There are similar SMP enablement methods for many ARMv7 bsed SoCs.
BCM NSP SoC, has a typical such mechanism - after power-on, the
secondary core is held in a standby state, primary core provides a
startup address for the secondary core and wakes it up. Booting of
the secondary core is serialized using pen_release global variable.

The startup address is programmed at a special register location
which is defined in the device tree using a "secondary-boot-reg"
property in a node whose "enable-method" property matches.

The first patch adds cpu-enable-method in the device tree bindings
documentation. It also updates ARM CPU device tree documentation
with Broadcom Northstar Plus CPU details.

The second patch adds SMP support to the BCM NSP device tree file.

Finally, third patch, enables SMP on BCM NSP. It also consolidates
common SMP handling between BCM NSP and BCM Kona.

This patch series is constructed based on Linux v4.3-rc2.

The source code is available at GITHUB:
https://github.com/Broadcom/cygnus-linux/tree/nsp-smp-v1

Kapil Hali (3):
  dt-bindings: add SMP enable-method for Broadcom NSP
  ARM: dts: add SMP support for Broadcom NSP
  ARM: BCM: Add SMP support for Broadcom NSP

 .../bindings/arm/bcm/brcm,nsp-cpu-method.txt   |  36 ++
 Documentation/devicetree/bindings/arm/cpus.txt |   1 +
 arch/arm/boot/dts/bcm-nsp.dtsi |  33 +++--
 arch/arm/mach-bcm/Kconfig  |   2 +
 arch/arm/mach-bcm/Makefile |   8 +-
 arch/arm/mach-bcm/bcm_nsp.h|  19 +++
 arch/arm/mach-bcm/headsmp.S|  37 ++
 arch/arm/mach-bcm/{kona_smp.c => platsmp.c}| 142 +++--
 8 files changed, 255 insertions(+), 23 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/bcm/brcm,nsp-cpu-method.txt
 create mode 100644 arch/arm/mach-bcm/bcm_nsp.h
 create mode 100644 arch/arm/mach-bcm/headsmp.S
 rename arch/arm/mach-bcm/{kona_smp.c => platsmp.c} (63%)

-- 
2.1.0

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

Re: [PATCH 2/5] gpio/xilinx: enable for MIPS

[Moritz Fischer]

On Wed, Oct 14, 2015 at 10:33 AM, Sören Brinkmann
 wrote:
> On Wed, 2015-10-14 at 07:24PM +0200, Lars-Peter Clausen wrote:
>> On 10/14/2015 06:54 PM, Sören Brinkmann wrote:
>> > On Wed, 2015-10-14 at 05:57PM +0200, Lars-Peter Clausen wrote:
>> >> On 10/14/2015 05:18 PM, Sören Brinkmann wrote:
>> >>> On Wed, 2015-10-14 at 01:51PM +0100, Zubair Lutfullah Kakakhel wrote:
>>  MIPSfpga uses the axi gpio controller. Enable the driver for MIPS.
>> 
>>  Signed-off-by: Zubair Lutfullah Kakakhel 
>>  ---
>>   drivers/gpio/Kconfig | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>>  diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>>  index 8949b3f..58e9afd 100644
>>  --- a/drivers/gpio/Kconfig
>>  +++ b/drivers/gpio/Kconfig
>>  @@ -508,7 +508,7 @@ config GPIO_XGENE_SB
>> 
>>   config GPIO_XILINX
>>   tristate "Xilinx GPIO support"
>>  -depends on OF_GPIO && (PPC || MICROBLAZE || ARCH_ZYNQ || X86)
>>  +depends on OF_GPIO && (PPC || MICROBLAZE || ARCH_ZYNQ || X86 
>>  || MIPS)
>> >>>
>> >>> Hmm, in general, this driver is hopefully generic enough that it doesn't
>> >>> have any real architecture dependencies. And I suspect, we want to
>> >>> enable this driver for ARM64 for ZynqMP soon too. Should we probably
>> >>> drop these arch dependencies completely? It seems to become quite a long 
>> >>> list.
>> >>
>> >> I've been thinking about this a while ago. This is certainly not the only
>> >> driver affected by this problem. But the thing is people always complain 
>> >> if
>> >> new symbols become visable in Kconfig that don't apply to their platform.
>> >>
>> >> Maybe we should introduce a HAS_REPROGRAMABLE_LOGIC (or similar) feature
>> >> Kconfig symbol and let platforms which have a FPGA select it and let 
>> >> drivers
>> >> for FPGA peripherals depend on it.
>> >
>> > Sounds like a good idea to me. But, does that work for all use-cases.
>> > E.g. if you plug some PCIe card with an FPGA into an x86(_64) machine.
>> > That would allow you to use those drivers, but I'm not sure how that
>> > could pull in the new config symbol.
>>
>> Hm, right. We could also make it a user-selectable config symbol. In that
>> case you only need to disable one symbol when you don't have FPGA support
>> rather than one for each driver. Although I'm not quite sure where to put
>> such a symbol.
>
> Eventually, the FPGA manager subsystem could probably provide some high
> level config symbols. Though, it is probably also not given that every
> FPGA-enabled platform needs the FPGA manager.

I agree. I suspect most platforms will not actually runtime reload the
FPGA using
FPGA manager they probably use onboard flash or something similar.

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

Moritz
--
To unsubscribe from this list: send the line "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] dt-bindings: Correct the example for Exynos power domain clocks

[Krzysztof Kozlowski]

Since commit 29e5eea06bc1 ("ARM: EXYNOS: Get current parent clock for
power domain on/off") the "pclkN" names of "clock-names" property is not
parsed any more. The bindings and driver were updated but the example
was not. Fix the example now.

Signed-off-by: Krzysztof Kozlowski 
---
 Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index e151057d92f0..4e947372a693 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -43,9 +43,8 @@ Example:
mfc_pd: power-domain@10044060 {
compatible = "samsung,exynos4210-pd";
reg = <0x10044060 0x20>;
-   clocks = < CLK_FIN_PLL>, < CLK_MOUT_SW_ACLK333>,
-   < CLK_MOUT_USER_ACLK333>;
-   clock-names = "oscclk", "pclk0", "clk0";
+   clocks = < CLK_FIN_PLL>, < CLK_MOUT_USER_ACLK333>;
+   clock-names = "oscclk", "clk0";
#power-domain-cells = <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 2/3] dts: Updated devicetree bindings for Zynq 7000 platform

[Michal Simek]

On 10/14/2015 04:50 AM, Moritz Fischer wrote:
> Hi Michal,
> 
> On Mon, Oct 12, 2015 at 2:32 AM, Michal Simek  wrote:
>> On 10/09/2015 12:45 AM, Moritz Fischer wrote:
>>> Added addtional bindings required for FPGA Manager operation
>>> of the Xilinx Zynq Devc configuration interface.
>>>
>>> Signed-off-by: Moritz Fischer 
>>> ---
>>>  arch/arm/boot/dts/zynq-7000.dtsi | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/zynq-7000.dtsi 
>>> b/arch/arm/boot/dts/zynq-7000.dtsi
>>> index dc0457e..1a5220e 100644
>>> --- a/arch/arm/boot/dts/zynq-7000.dtsi
>>> +++ b/arch/arm/boot/dts/zynq-7000.dtsi
>>> @@ -294,6 +294,11 @@
>>>   devcfg: devcfg@f8007000 {
>>>   compatible = "xlnx,zynq-devcfg-1.0";
>>>   reg = <0xf8007000 0x100>;
>>> + interrupt-parent = <>;
>>> + interrupts = <0 8 4>;
>>> + clocks = < 12>;
>>> + clock-names = "ref_clk";
>>> + syscon = <>;
>>>   };
>>>
>>>   global_timer: timer@f8f00200 {
>>>
>>
>> This patch should go via arm-soc tree. That's why please remove it from
>> this patchset.
> 
> Just to clarify, you want this as a separate patch?

yes when binding is ACKed.

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 3/3] input: rotary-encoder: Support 'steps-per-period' DT property

[Dmitry Torokhov]

On Fri, Oct 09, 2015 at 10:46:56AM -0300, Ezequiel Garcia wrote:
> As per the recent devicetree binding changes, this commit adds the
> support for the new 'steps-per-period' property.
> 
> Legacy properties to specify the rotary behavior, are now deprecated
> and instead the new 'steps-per-period' is supported. The default behavior
> is retained.
> 
> This allows to support rotary-encoder devices with detents wich are capable
> of producing a stable event on each step.
> 
> Signed-off-by: Guido Martínez 
> Signed-off-by: Ezequiel Garcia 
> ---
>  drivers/input/misc/rotary_encoder.c | 87 
> +++--
>  include/linux/rotary_encoder.h  |  2 +-
>  2 files changed, 84 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/input/misc/rotary_encoder.c 
> b/drivers/input/misc/rotary_encoder.c
> index 15a4cc670a3f..e021615dd3c0 100644
> --- a/drivers/input/misc/rotary_encoder.c
> +++ b/drivers/input/misc/rotary_encoder.c
> @@ -142,6 +142,55 @@ static irqreturn_t rotary_encoder_half_period_irq(int 
> irq, void *dev_id)
>   return IRQ_HANDLED;
>  }
>  
> +static irqreturn_t rotary_encoder_quarter_period_irq(int irq, void *dev_id)
> +{
> + struct rotary_encoder *encoder = dev_id;
> + unsigned char sum;
> + int state;
> +
> + state = rotary_encoder_get_state(encoder->pdata);
> +
> + /*
> +  * We encode the previous and the current state using a byte.
> +  * The previous state in the MSB nibble, the current state in the LSB
> +  * nibble. Then use a table to decide the direction of the turn.
> +  */
> + sum = (encoder->last_stable << 4) + state;
> + switch (sum) {
> + case 0x31:
> + case 0x10:
> + case 0x02:
> + case 0x23:
> + encoder->dir = 0; /* clockwise */
> + break;
> +
> + case 0x13:
> + case 0x01:
> + case 0x20:
> + case 0x32:
> + encoder->dir = 1; /* counter-clockwise */
> + break;
> +
> + default:
> + /*
> +  * Ignore all other values. This covers the case when the
> +  * state didn't change (a spurious interrupt) and the
> +  * cases where the state changed by two steps, making it
> +  * impossible to tell the direction.
> +  *
> +  * In either case, don't report any event and save the
> +  * state for later.
> +  */
> + goto out;
> + }
> +
> + rotary_encoder_report_event(encoder);
> +
> +out:
> + encoder->last_stable = state;
> + return IRQ_HANDLED;
> +}
> +
>  #ifdef CONFIG_OF
>  static const struct of_device_id rotary_encoder_of_match[] = {
>   { .compatible = "rotary-encoder", },
> @@ -176,7 +225,26 @@ static struct rotary_encoder_platform_data 
> *rotary_encoder_parse_dt(struct devic
>  
>   pdata->relative_axis = of_property_read_bool(np, 
> "rotary-encoder,relative-axis");
>   pdata->rollover = of_property_read_bool(np, "rotary-encoder,rollover");
> - pdata->half_period = of_property_read_bool(np, 
> "rotary-encoder,half-period");
> +
> + if (!of_get_property(np, "rotary-encoder,steps-per-period", NULL)) {
> + /*
> +  * Fallback to a one step per period behavior if the
> +  * 'steps-per-period' is not set.
> +  */
> + pdata->steps_per_period = 1;
> + } else {
> + of_property_read_u32(np, "rotary-encoder,steps-per-period",
> +  >steps_per_period);
> + }
> +
> + /*
> +  * The 'half-period' property has been deprecated, you must use
> +  * 'steps-per-period' and set an appropriate value.
> +  */
> + if (of_get_property(np, "rotary-encoder,half-period", NULL)) {
> + pr_warn(FW_WARN "\"rotary-encoder,half-period\" is 
> deprecated\n");
> + pdata->steps_per_period = 2;
> + }

Hmm, I do not think we need to warn about old DTSes if we consider them
ABI. How about if we parse like this:

error = of_property_read_u32(np, "rotary-encoder,steps-per-period",
 >steps_per_period);
if (error) {
/*
 * The 'half-period' property has been deprecated, you must use
 * 'steps-per-period' and set an appropriate value, but we still
 * need to parse it to maintain compatibility.
 */
if (of_property_read_bool(np, "rotary-encoder,half-period")) {
pdata->steps_per_period = 2;
} else {
/* Fallback to a one step per period behavior */
pdata->steps_per_period = 1;
}
}


(no need to resubmit if you are OK with this).

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to 

Re: [PATCH v9 2/9] Input: goodix - reset device at init

[Dmitry Torokhov]

On Tue, Oct 13, 2015 at 01:07:24PM +0300, mika.westerb...@linux.intel.com wrote:
> On Tue, Oct 13, 2015 at 08:54:12AM +, Tirdea, Irina wrote:
> > > > I did not use devm_gpiod_get_optional() in order to ignore more errors
> > > > than -ENOENT. This is needed because the ACPI gpio core will fall back
> > > > to indexed gpios if named gpios are not found. In the common case of
> > > > having 2 indexed gpio pins declared in the ACPI table, the first
> > > > devm_gpiod_get() will successfully get indexed gpio pin 0 and the
> > > > second devm_gpiod_get() will try to get the same gpio pin 0 and return
> > > > -EBUSY. Considering this, I thought it is better to just ignore all 
> > > > errors in
> > > > order not to break any platforms currently using this driver.
> > > 
> > > This seems like issue with ACPI gpio lookup implementation. If I am
> > > requesting named gpio and it is not present then I definitely do not
> > > need to be returned some random gpio. Doing so breaks all other drivers
> > > that use several names to retrieve GPIOs. We basically can't trust GPIO
> > > API on ACPI systems.
> > > 
> > 
> > I'm not sure there is a way to avoid fall back to indexed gpios when 
> > requesting
> > named gpios.
> > Adding Mika to this thread as he might help answer this.
> 
> Before ACPI 5.1 _DSD device properties were introduced all we had was an
> array of GPIOs returned by _CRS ACPI method. Ordering of those GPIOs
> could change from one vendor to another :-(
> 
> We can (and do) use acpi_dev_add_driver_gpios() to pass correct mappings
> where _DSD is not present based on the device ACPI ID for instance. Not
> all drivers do that, though.
> 
> I would like to get rid of the fallback completely at some point. We
> have had already problems with the API because then some ACPI only
> drivers did this:
> 
>   reset_gpio = gpiod_get_index(dev, NULL, 0);
>   power_gpio = gpiod_get_index(dev, NULL, 1);
> 
> which might not do what is expected on DT systems. That's why
> acpi_dev_add_driver_gpios() was added in the first place IIRC.

I understand why one might use acpi_dev_add_driver_gpios() to augment
data in ACPI, however here we have completely different issue: driver
that expects named gpios gets returned gpio that has nothing to do with
what it requested, because gpiolib acpi code always falls back to
unnamed gpio if it does not find named gpio. That can be acceptable if
driver uses the same con_id for all requests to gpiolib, but is not
working when driver supplies different con_ids.

Thanks.

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

Re: [PATCH v7 3/9] Input: goodix - write configuration data to device

[Dmitry Torokhov]

On Thu, Oct 08, 2015 at 01:19:29PM +0300, Irina Tirdea wrote:
> Goodix devices can be configured by writing custom data to the device at
> init. The configuration data is read with request_firmware from
> "goodix__cfg.bin", where  is the product id read from the device
> (e.g.: goodix_911_cfg.bin for Goodix GT911, goodix_9271_cfg.bin for
> GT9271).
> 
> The configuration information has a specific format described in the Goodix
> datasheet. It includes X/Y resolution, maximum supported touch points,
> interrupt flags, various sensitivity factors and settings for advanced
> features (like gesture recognition).
> 
> Before writing the firmware, it is necessary to reset the device. If
> the device ACPI/DT information does not declare gpio pins (needed for
> reset), writing the firmware will not be available for these devices.
> 
> This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> driver gt9xx.c for Android (publicly available in Android kernel
> trees for various devices).
> 
> Signed-off-by: Octavian Purdila 
> Signed-off-by: Irina Tirdea 
> ---
>  drivers/input/touchscreen/goodix.c | 229 
> +++--
>  1 file changed, 196 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/goodix.c 
> b/drivers/input/touchscreen/goodix.c
> index 916198d..37035fb 100644
> --- a/drivers/input/touchscreen/goodix.c
> +++ b/drivers/input/touchscreen/goodix.c
> @@ -16,6 +16,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -40,6 +41,9 @@ struct goodix_ts_data {
>   int cfg_len;
>   struct gpio_desc *gpiod_int;
>   struct gpio_desc *gpiod_rst;
> + u16 id;
> + u16 version;
> + char *cfg_name;
>  };
>  
>  #define GOODIX_GPIO_INT_NAME "irq"
> @@ -159,6 +163,39 @@ static int goodix_i2c_read(struct i2c_client *client,
>   return ret < 0 ? ret : (ret != ARRAY_SIZE(msgs) ? -EIO : 0);
>  }
>  
> +/**
> + * goodix_i2c_write - write data to a register of the i2c slave device.
> + *
> + * @client: i2c device.
> + * @reg: the register to write to.
> + * @buf: raw data buffer to write.
> + * @len: length of the buffer to write
> + */
> +static int goodix_i2c_write(struct i2c_client *client, u16 reg, const u8 
> *buf,
> + unsigned len)
> +{
> + u8 *addr_buf;
> + struct i2c_msg msg;
> + int ret;
> +
> + addr_buf = kmalloc(len + 2, GFP_KERNEL);
> + if (!addr_buf)
> + return -ENOMEM;
> +
> + addr_buf[0] = reg >> 8;
> + addr_buf[1] = reg & 0xFF;
> + memcpy(_buf[2], buf, len);
> +
> + msg.flags = 0;
> + msg.addr = client->addr;
> + msg.buf = addr_buf;
> + msg.len = len + 2;
> +
> + ret = i2c_transfer(client->adapter, , 1);
> + kfree(addr_buf);
> + return ret < 0 ? ret : (ret != 1 ? -EIO : 0);
> +}
> +
>  static int goodix_get_cfg_len(u16 id)
>  {
>   switch (id) {
> @@ -278,6 +315,73 @@ static irqreturn_t goodix_ts_irq_handler(int irq, void 
> *dev_id)
>   return IRQ_HANDLED;
>  }
>  
> +/**
> + * goodix_check_cfg - Checks if config fw is valid
> + *
> + * @ts: goodix_ts_data pointer
> + * @cfg: firmware config data
> + */
> +static int goodix_check_cfg(struct goodix_ts_data *ts,
> + const struct firmware *cfg)
> +{
> + int i, raw_cfg_len;
> + u8 check_sum = 0;
> +
> + if (cfg->size > GOODIX_CONFIG_MAX_LENGTH) {
> + dev_err(>client->dev,
> + "The length of the config fw is not correct");
> + return -EINVAL;
> + }
> +
> + raw_cfg_len = cfg->size - 2;
> + for (i = 0; i < raw_cfg_len; i++)
> + check_sum += cfg->data[i];
> + check_sum = (~check_sum) + 1;
> + if (check_sum != cfg->data[raw_cfg_len]) {
> + dev_err(>client->dev,
> + "The checksum of the config fw is not correct");
> + return -EINVAL;
> + }
> +
> + if (cfg->data[raw_cfg_len + 1] != 1) {
> + dev_err(>client->dev,
> + "Config fw must have Config_Fresh register set");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * goodix_send_cfg - Write fw config to device
> + *
> + * @ts: goodix_ts_data pointer
> + * @cfg: config firmware to write to device
> + */
> +static int goodix_send_cfg(struct goodix_ts_data *ts,
> +const struct firmware *cfg)
> +{
> + int error;
> +
> + error = goodix_check_cfg(ts, cfg);
> + if (error)
> + return error;
> +
> + error = goodix_i2c_write(ts->client, GOODIX_REG_CONFIG_DATA, cfg->data,
> +  cfg->size);
> + if (error) {
> + dev_err(>client->dev, "Failed to write config data: %d",
> + error);
> + return error;
> + }
> + dev_dbg(>client->dev, "Config sent successfully.");
> +
> + /* Let the firmware 

Re: [PATCH v9 3/6] pci:host: Add Altera PCIe host controller driver

[Ley Foon Tan]

On Wed, Oct 14, 2015 at 4:20 PM, Arnd Bergmann  wrote:
> On Wednesday 14 October 2015 10:41:29 Ley Foon Tan wrote:
>> +static int altera_pcie_remove(struct platform_device *pdev)
>> +{
>> + struct altera_pcie *pcie = platform_get_drvdata(pdev);
>> +
>> + altera_pcie_free_irq_domain(pcie);
>> + platform_set_drvdata(pdev, NULL);
>> + return 0;
>> +}
>
> I just noticed this. Does it actually work to unload the module
> and tear down all the pci_dev structures in a safe way?
Good catch. It only can be compiled as builtin-moduley now, so we can
remove this _remove callback function.
Thanks.

Regards
Ley Foon
--
To unsubscribe from this list: send the line "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 09/25] scsi: hisi_sas: add phy SAS ADDR initialization

[Hannes Reinecke]

On 10/13/2015 07:14 PM, John Garry wrote:
> On 13/10/2015 07:12, Hannes Reinecke wrote:
>> On 10/12/2015 05:20 PM, John Garry wrote:
>>> This SAS ID is chosen as Huawei IEEE id: 001882
>>>
>>> Signed-off-by: John Garry 
>>> ---
>>>   drivers/scsi/hisi_sas/hisi_sas_init.c | 15 +++
>>>   1 file changed, 15 insertions(+)
>>>
>>> diff --git a/drivers/scsi/hisi_sas/hisi_sas_init.c
>>> b/drivers/scsi/hisi_sas/hisi_sas_init.c
>>> index 44fc524..c295c39 100644
>>> --- a/drivers/scsi/hisi_sas/hisi_sas_init.c
>>> +++ b/drivers/scsi/hisi_sas/hisi_sas_init.c
>>> @@ -283,6 +283,19 @@ err_out:
>>>   return NULL;
>>>   }
>>>
>>> +static void hisi_sas_init_add(struct hisi_hba *hisi_hba)
>>> +{
>>> +u8 i;
>>> +
>>> +/* Huawei IEEE id (001882) */
>>> +for (i = 0; i < hisi_hba->n_phy; i++)
>>> +hisi_hba->phy[i].dev_sas_addr =
>>> +cpu_to_be64(0x5001882016072015ULL);
>>> +
>> Ouch. Each phy has the same SAS address?
>> For all boards? Ever?
>>
>> Not sure if that's a good idea, nor even valid.
>> It'll confuse the hell out of any SAS array.
>>
>> Please provide a means of having individual SAS addresses for each
>> HBA.
>>
>> Cheers,
>>
>> Hannes
>>
> Hello,
> 
> Are you saying we should be getting the SAS address from fw with
> sas_request_addr() or the like?
> 
> Marvell solution seems to hardcode it.
> 
Doesn't make it any better, nor even valid.

Problem is that using a hardcoded SAS address makes it impossible
do any resource allocation on a SAS target array.
The SAS target array is allocating / mapping the LUNs based on the
SAS address, so if HBAs from different machines coming in with the
same SAS address the SAS array will assume that all ports belong to
the same machine, thus allowing access to all of them.

And don't try to _ever_ connect these HBAs to a SAS switch; that
will be even more confused.

So please, if you have a chance _DO_ get the SAS address from fw.
If the firmware doesn't provide it you really should get in touch
with the firmware team to get you one.

To clarify the situation the SAS spec states:

  Device names are worldwide unique names for devices within a
  transport protocol (see SAM-3).

and:
  The VENDOR - SPECIFIC IDENTIFIER contains a 36-bit numeric value
  that is uniquely assigned by the organization associated with the
  company identifier in the IEEE COMPANY ID field.

So as you are using the Huawei Vendor ID Huawei as a company needs
to ensure uniqueness of the vendor-specific identifier (ie the last
36 bits of the SAS address). Which the above patch most patently
fails to address.

Cheers,

Hannes
-- 
Dr. Hannes ReineckezSeries & Storage
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v9 3/6] pci:host: Add Altera PCIe host controller driver

[Arnd Bergmann]

On Wednesday 14 October 2015 16:32:25 Ley Foon Tan wrote:
> On Wed, Oct 14, 2015 at 4:20 PM, Arnd Bergmann  wrote:
> > On Wednesday 14 October 2015 10:41:29 Ley Foon Tan wrote:
> >> +static int altera_pcie_remove(struct platform_device *pdev)
> >> +{
> >> + struct altera_pcie *pcie = platform_get_drvdata(pdev);
> >> +
> >> + altera_pcie_free_irq_domain(pcie);
> >> + platform_set_drvdata(pdev, NULL);
> >> + return 0;
> >> +}
> >
> > I just noticed this. Does it actually work to unload the module
> > and tear down all the pci_dev structures in a safe way?
> Good catch. It only can be compiled as builtin-moduley now, so we can
> remove this _remove callback function.

I think we should change both: make it possible to load the
driver dynamically, and remove the altera_pcie_remove function.

You can prevent the module from being unloaded if you also remove
the module_platform_driver() directive and add a module_init()
without a matching module_exit().

Please also add a '.suppress_bind_attrs = true,' flag in the driver
struct to prevent manual unbinding.

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

Re: [PATCH v4 2/2] usb: chipidea: imx: refine clock operations to adapt for all platforms

[Peter Chen]

On Wed, Oct 14, 2015 at 10:07:59AM +0200, Marc Kleine-Budde wrote:
> On 10/14/2015 03:57 AM, Peter Chen wrote:
> > Some i.mx platforms need three clocks to let controller work, but
> > others only need one, refine clock operation to adapt for all
> > platforms, it fixes a regression found at i.mx27.
> > 
> > Signed-off-by: Peter Chen 
> > Tested-by: Fabio Estevam 
> > Cc:  #v4.1+
> > ---
> >  drivers/usb/chipidea/ci_hdrc_imx.c | 132 
> > -
> >  1 file changed, 114 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
> > b/drivers/usb/chipidea/ci_hdrc_imx.c
> > index 6ccbf60..82b1dfe 100644
> > --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> > +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> > @@ -84,6 +84,12 @@ struct ci_hdrc_imx_data {
> > struct imx_usbmisc_data *usbmisc_data;
> > bool supports_runtime_pm;
> > bool in_lpm;
> > +   /* SoC before i.mx6 (except imx23/imx28) needs three clks */
> > +   bool need_three_clks;
> > +   struct clk *clk_ipg;
> > +   struct clk *clk_ahb;
> > +   struct clk *clk_per;
> > +   /* - */
> >  };
> >  
> >  /* Common functions shared by usbmisc drivers */
> > @@ -135,6 +141,103 @@ static struct imx_usbmisc_data 
> > *usbmisc_get_init_data(struct device *dev)
> >  }
> >  
> >  /* End of common functions shared by usbmisc drivers*/
> > +static int imx_get_clks(struct device *dev)
> > +{
> > +   struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
> > +   int ret = 0;
> > +
> > +   data->clk_ipg = devm_clk_get(dev, "ipg");
> > +   if (IS_ERR(data->clk_ipg)) {
> > +   /* If the platform only needs one clocks */
> > +   data->clk = devm_clk_get(dev, NULL);
> > +   if (IS_ERR(data->clk)) {
> > +   ret = PTR_ERR(data->clk);
> > +   dev_err(dev,
> > +   "Failed to get clock, err=%d\n", ret);
> > +   dev_err(dev,
> > +   "Failed to get ipg clock, err=%d\n", ret);
> 
> Nitpick, one error message should be enough.

Yes, I will show both error value for clk_ipg and NULL.

> 
> > +   return ret;
> > +   }
> > +   return ret;
> > +   }
> > +
> > +   data->clk_ahb = devm_clk_get(dev, "ahb");
> > +   if (IS_ERR(data->clk_ahb)) {
> > +   ret = PTR_ERR(data->clk_ahb);
> > +   dev_err(dev,
> > +   "Failed to get ahb clock, err=%d\n", ret);
> > +   return ret;
> > +   }
> > +
> > +   data->clk_per = devm_clk_get(dev, "per");
> > +   if (IS_ERR(data->clk_per)) {
> > +   ret = PTR_ERR(data->clk_per);
> > +   dev_err(dev,
> > +   "Failed to get per clock, err=%d\n", ret);
> > +   return ret;
> > +   }
> > +
> > +   data->need_three_clks = true;
> > +   return ret;
> > +}
> > +
> > +static int imx_prepare_enable_clks(struct device *dev)
> > +{
> > +   struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
> > +   int ret = 0;
> > +
> > +   if (data->need_three_clks) {
> > +   ret = clk_prepare_enable(data->clk_ipg);
> > +   if (ret) {
> > +   dev_err(dev,
> > +   "Failed to prepare/enable ipg clk, err=%d\n",
> > +   ret);
> > +   return ret;
> > +   }
> > +
> > +   ret = clk_prepare_enable(data->clk_ahb);
> > +   if (ret) {
> > +   dev_err(dev,
> > +   "Failed to prepare/enable ahb clk, err=%d\n",
> > +   ret);
> > +   clk_disable_unprepare(data->clk_ipg);
> > +   return ret;
> > +   }
> > +
> > +   ret = clk_prepare_enable(data->clk_per);
> > +   if (ret) {
> > +   dev_err(dev,
> > +   "Failed to prepare/enable per clk, err=%d\n",
> > +   ret);
> > +   clk_disable_unprepare(data->clk_ahb);
> > +   clk_disable_unprepare(data->clk_ipg);
> > +   return ret;
> > +   }
> > +   } else {
> > +   ret = clk_prepare_enable(data->clk);
> > +   if (ret) {
> > +   dev_err(dev,
> > +   "Failed to prepare/enable clk, err=%d\n",
> > +   ret);
> > +   return ret;
> > +   }
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> > +static void imx_disable_unprepare_clks(struct device *dev)
> > +{
> > +   struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
> > +
> > +   if (data->need_three_clks) {
> > +   clk_disable_unprepare(data->clk_per);
> > +   clk_disable_unprepare(data->clk_ipg);
> > +   clk_disable_unprepare(data->clk_ahb);
> 
> nit: you enable in this order: ipg, ahb, per. Disabling should be inverse.

Will change, 

Re: [PATCH v9 3/6] pci:host: Add Altera PCIe host controller driver

[Arnd Bergmann]

On Wednesday 14 October 2015 17:28:45 Ley Foon Tan wrote:
> On Wed, Oct 14, 2015 at 5:09 PM, Arnd Bergmann  wrote:
> > On Wednesday 14 October 2015 16:32:25 Ley Foon Tan wrote:
> >> On Wed, Oct 14, 2015 at 4:20 PM, Arnd Bergmann  wrote:
> >> > On Wednesday 14 October 2015 10:41:29 Ley Foon Tan wrote:
> >> >> +static int altera_pcie_remove(struct platform_device *pdev)
> >> >> +{
> >> >> + struct altera_pcie *pcie = platform_get_drvdata(pdev);
> >> >> +
> >> >> + altera_pcie_free_irq_domain(pcie);
> >> >> + platform_set_drvdata(pdev, NULL);
> >> >> + return 0;
> >> >> +}
> >> >
> >> > I just noticed this. Does it actually work to unload the module
> >> > and tear down all the pci_dev structures in a safe way?
> >> Good catch. It only can be compiled as builtin-moduley now, so we can
> >> remove this _remove callback function.
> >
> > I think we should change both: make it possible to load the
> > driver dynamically, and remove the altera_pcie_remove function.
> This driver depends on the pci fixups to work correctly. But, fixups
> callback functions in this driver are not being call if the driver is
> loadable module.

Ah, I see. We should find a better way to deal with this, as we
are getting an increasing number of host driver specific fixups.

Bjorn, do you have any idea here?

Could we perhaps have a helper function that lets us register
fixups dynamically?

> The linker script keeps all pci fixup callbacks in pci fixup regions
> during kernel compile time. So, it needs to be builtin module. Do you
> know any way we can update those fixup regions?

The only method I'm aware of at the moment is move the fixups to
drivers/pci/quirks.c and enclose them in an #ifdef if you want them
to not appear in kernels that don't support your SoC.

> > You can prevent the module from being unloaded if you also remove
> > the module_platform_driver() directive and add a module_init()
> > without a matching module_exit().
> >
> > Please also add a '.suppress_bind_attrs = true,' flag in the driver
> > struct to prevent manual unbinding.
> I think we don't need these if it only can work as builtin module.

No, this is orthogonal, you need it either way, as built-in drivers
can still be unbound by writing to sysfs. Try writing the device name
to /sys/bus/platform/drivers/altera-pcie/unbind and watch it blow up ;-)

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

Re: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

[Arnd Bergmann]

On Wednesday 14 October 2015 09:31:48 Gabriele Paoloni wrote:
> > 
> > > To me it sounds more appropriate to adopt subsys_initcall() for all
> > the
> > > PCI Host Bridge controllers rather than having them as loadable
> > modules...
> > >
> > > What is your view?
> > 
> > subsys_initcall() sounds odd because it's a driver rather than a
> > subsystem,
> > but I realize that most of the other levels don't fit any better.
> 
> Yes well I was seeing for example the vgaarb 
> http://lxr.free-electrons.com/source/drivers/gpu/vga/vgaarb.c#L1357
> 
> That in the init is calling pci_get_subsys()
> 
> So I was wondering that the PCI devices may not be registered unless
> we also init the PCI host bridge through subsys_initcall()...

I think this should work as is: the code first looks for devices
that are already there and then registers a notifier for devices
that show up later. This is meant to work for both devices that
are hotplugged at a later point as well as PCI buses that are
already there but not yet probed.

> But then maybe is the vgaarb to be buggy...

Possible. It may well be that the code is only tested on x86,
which always probes its PCI very early.

> > As I said, it's not really a choice we have to make in the source code,
> > we can use subsys_initcall together with module_exit(), or we can
> > create a helper macro that is similar to module_platform_driver()
> > specifically for PCI that uses a particular initcall level.
> 
> Ok got it. But I guess this needs to be thought and applied to all
> the PCI host bridge controllers...
> 
> So maybe for this driver I can use module_platform_driver_probe()
> and then we can see...

Sounds good. Let's focus on getting the driver merged first and
then follow up with a patch to get this right for all PCI hosts.

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

Re: [PATCH 3/4] mmc: mediatek: Add tune support

[Ulf Hansson]

On 13 October 2015 at 11:37, Chaotian Jing  wrote:
> Add CMD19/CMD21 support for EMMC/SD/SDIO tuning
> Add HS400 mode support
>
> Signed-off-by: Chaotian Jing 
> ---
>  drivers/mmc/host/mtk-sd.c | 359 
> ++
>  1 file changed, 332 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> index b2e89d3..f12a50a 100644
> --- a/drivers/mmc/host/mtk-sd.c
> +++ b/drivers/mmc/host/mtk-sd.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include 
> @@ -64,6 +65,7 @@
>  #define SDC_RESP20x48
>  #define SDC_RESP30x4c
>  #define SDC_BLK_NUM  0x50
> +#define EMMC_IOCON   0x7c
>  #define SDC_ACMD_RESP0x80
>  #define MSDC_DMA_SA  0x90
>  #define MSDC_DMA_CTRL0x98
> @@ -71,6 +73,8 @@
>  #define MSDC_PATCH_BIT   0xb0
>  #define MSDC_PATCH_BIT1  0xb4
>  #define MSDC_PAD_TUNE0xec
> +#define PAD_DS_TUNE  0x188
> +#define EMMC50_CFG0  0x208
>
>  
> /*--*/
>  /* Register Mask
> */
> @@ -87,6 +91,7 @@
>  #define MSDC_CFG_CKSTB  (0x1 << 7) /* R  */
>  #define MSDC_CFG_CKDIV  (0xff << 8)/* RW */
>  #define MSDC_CFG_CKMOD  (0x3 << 16)/* RW */
> +#define MSDC_CFG_HS400_CK_MODE  (0x1 << 18)/* RW */
>
>  /* MSDC_IOCON mask */
>  #define MSDC_IOCON_SDR104CKS(0x1 << 0) /* RW */
> @@ -204,6 +209,17 @@
>  #define MSDC_PATCH_BIT_SPCPUSH(0x1 << 29)  /* RW */
>  #define MSDC_PATCH_BIT_DECRCTMO   (0x1 << 30)  /* RW */
>
> +#define MSDC_PAD_TUNE_DATRRDLY   (0x1f <<  8)  /* RW */
> +#define MSDC_PAD_TUNE_CMDRDLY(0x1f << 16)  /* RW */
> +
> +#define PAD_DS_TUNE_DLY1 (0x1f << 2)   /* RW */
> +#define PAD_DS_TUNE_DLY2 (0x1f << 7)   /* RW */
> +#define PAD_DS_TUNE_DLY3 (0x1f << 12)  /* RW */
> +
> +#define EMMC50_CFG_PADCMD_LATCHCK (0x1 << 0)   /* RW */
> +#define EMMC50_CFG_CRCSTS_EDGE(0x1 << 3)   /* RW */
> +#define EMMC50_CFG_CFCSTS_SEL (0x1 << 4)   /* RW */
> +
>  #define REQ_CMD_EIO  (0x1 << 0)
>  #define REQ_CMD_TMO  (0x1 << 1)
>  #define REQ_DAT_ERR  (0x1 << 2)
> @@ -219,6 +235,7 @@
>  #define CMD_TIMEOUT (HZ/10 * 5)/* 100ms x5 */
>  #define DAT_TIMEOUT (HZ* 5)/* 1000ms x5 */
>
> +#define DELAY_MAX  32 /* PAD dalay cells */

/s/dalay/delay

Can we have some more explaination around this define. Perhaps a more
self-explaining name would be enough.-

>  
> /*--*/
>  /* Descriptor Structure 
> */
>  
> /*--*/
> @@ -265,6 +282,14 @@ struct msdc_save_para {
> u32 pad_tune;
> u32 patch_bit0;
> u32 patch_bit1;
> +   u32 pad_ds_tune;
> +   u32 emmc50_cfg0;
> +};
> +
> +struct msdc_delay_phase {
> +   u8 maxlen;
> +   u8 start;
> +   u8 final_phase;
>  };
>
>  struct msdc_host {
> @@ -293,12 +318,15 @@ struct msdc_host {
> int irq;/* host interrupt */
>
> struct clk *src_clk;/* msdc source clock */
> +   struct clk *src_clk_parent; /* src_clk's parent */
> +   struct clk *hs400_src;  /* 400Mhz source clock */

Hmm, so you need to control the upper level clocks. Can you elaborate
on why this is needed?

> struct clk *h_clk;  /* msdc h_clk */
> u32 mclk;   /* mmc subsystem clock frequency */
> u32 src_clk_freq;   /* source clock frequency */
> u32 sclk;   /* SD/MS bus clock frequency */
> -   bool ddr;
> +   unsigned char timing;
> bool vqmmc_enabled;
> +   u32 hs400_ds_delay;
> struct msdc_save_para save_para; /* used when gate HCLK */
>  };
>
> @@ -353,7 +381,10 @@ static void msdc_reset_hw(struct msdc_host *host)
>  static void msdc_cmd_next(struct msdc_host *host,
> struct mmc_request *mrq, struct mmc_command *cmd);
>
> -static u32 data_ints_mask = MSDC_INTEN_XFER_COMPL | MSDC_INTEN_DATTMO |
> +static const u32 cmd_ints_mask = MSDC_INTEN_CMDRDY | MSDC_INTEN_RSPCRCERR |
> +   MSDC_INTEN_CMDTMO | MSDC_INTEN_ACMDRDY |
> +   MSDC_INTEN_ACMDCRCERR | MSDC_INTEN_ACMDTMO;

This belongs to separate code improvement patch.

> +static const u32 data_ints_mask = MSDC_INTEN_XFER_COMPL | MSDC_INTEN_DATTMO |
> MSDC_INTEN_DATCRCERR | MSDC_INTEN_DMA_BDCSERR |
> MSDC_INTEN_DMA_GPDCSERR | MSDC_INTEN_DMA_PROTECT;
>
> @@ -485,7 +516,7 @@ static void msdc_ungate_clock(struct msdc_host *host)
> cpu_relax();
>  }
>
> -static void msdc_set_mclk(struct msdc_host *host, int ddr, u32 hz)
> +static 

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Tue, 13 Oct 2015, Mark Brown wrote:
> On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:
> > On Mon, 12 Oct 2015, Mark Brown wrote:
> > > On Mon, Oct 12, 2015 at 09:45:54AM +0100, Charles Keepax wrote:
> 
> > > > I am guessing Mark is slightly hesitant to ack as he probably
> > > > doesn't want to add reviewing all our jack detection bindings to
> > > > his already fairly sizable work load and doing so here likely
> > > > means it will be expected in the future. From talking to people at
> 
> > Providing Acks should not (and has not to my knowledge) be a binding
> > contract to continue providing Acks.  However, should more bindings be
> > submitted which appear as though they are related to a particular
> > maintainer, then sure, you'll be asked for your expert eye again.
> 
> It's a bit concerning when it seems like my review is becoming a blocker
> for something and I don't understand why.

Not necessarily _your_ review.  Just someone, other than the
submitter, who I trust and knows about this stuff.  You just happen 
to tick those boxes this time.  Cross pollination and knowledge sharing
is one of the characteristics of MLs which I'm particularly proud of.

> > > Pretty much (plus generally being busy at ELC-E last week) - if there's
> > > specific questions that's one thing but if it's just general requests to
> > > look at bindings then it seems like the relevant subsystem maintainers
> 
> > This is exactly my point.  I am not the 'relevant subsystem
> > maintainer' for these properties and subsequently know nothing of
> > microphone detection, headsets, bias', etc.  These look like Audio
> > related properties to me (the uninitiated), which is why you were
> > asked.
> 
> They're extcon things (and there are accompanying driver changes to the
> extcon driver parsing them).

Yes, I'm aware of that now.  Hence the "(uninitiated)" part.

> > > should have the confidence to review straightfoward device properties
> > > like this.
> 
> > I don't think these bindings are particularly straightforward.  The
> > contain many terms which I'm unfamiliar with, and again, to me (the
> > uninitiated) this looks like way too many bindings just to see if an
> > audio jack is plugged in or not.
> 
> When your power budget is in the low double digit microamps and you're
> trying to respond promptly and reliably to rapidly changing and variable
> physical inputs it gets complicated.

This is exactly why I asked you.

Thanks for adding structure to my PoV. ;) 

-- 
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 v2 2/4] dmaengine: Add STM32 DMA driver

[M'boumba Cedric Madianga]

Hi Daniel,

2015-10-13 16:34 GMT+02:00 Daniel Thompson :
> On 13/10/15 15:05, M'boumba Cedric Madianga wrote:
>>
>> This patch adds support for the STM32 DMA controller.
>>
>> Signed-off-by: M'boumba Cedric Madianga 
>> ---
>>   drivers/dma/Kconfig |   12 +
>>   drivers/dma/Makefile|1 +
>>   drivers/dma/stm32-dma.c | 1175
>> +++
>>   3 files changed, 1188 insertions(+)
>>   create mode 100644 drivers/dma/stm32-dma.c
>
>
>> diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
>> new file mode 100644
>> index 000..031bab7
>> --- /dev/null
>> +++ b/drivers/dma/stm32-dma.c
>
>
>> +enum stm32_dma_width {
>> +   STM32_DMA_BYTE,
>> +   STM32_DMA_HALF_WORD,
>> +   STM32_DMA_WORD,
>> +};
>> +
>> +enum stm32_dma_burst_size {
>> +   STM32_DMA_BURST_SINGLE,
>> +   STM32_DMA_BURST_INCR4,
>> +   STM32_DMA_BURST_INCR8,
>> +   STM32_DMA_BURST_INCR16,
>> +};
>> +
>> +enum stm32_dma_channel_id {
>> +   STM32_DMA_CHANNEL0,
>> +   STM32_DMA_CHANNEL1,
>> +   STM32_DMA_CHANNEL2,
>> +   STM32_DMA_CHANNEL3,
>> +   STM32_DMA_CHANNEL4,
>> +   STM32_DMA_CHANNEL5,
>> +   STM32_DMA_CHANNEL6,
>> +   STM32_DMA_CHANNEL7,
>> +};
>
>
> Why have (unused) enumerations to map numeric symbols to their own natural
> values? Using normal integers would be better.

Good point. I will remove these in the next version.
Thanks.

>
>
>> +enum stm32_dma_request_id {
>> +   STM32_DMA_REQUEST0,
>> +   STM32_DMA_REQUEST1,
>> +   STM32_DMA_REQUEST2,
>> +   STM32_DMA_REQUEST3,
>> +   STM32_DMA_REQUEST4,
>> +   STM32_DMA_REQUEST5,
>> +   STM32_DMA_REQUEST6,
>> +   STM32_DMA_REQUEST7,
>> +};
>
>
> Ditto.

As above, I will remove it in the next version. Thanks.

>
>
>> +static void stm32_dma_dump_reg(struct stm32_dma_chan *chan)
>> +{
>> +   struct stm32_dma_device *dmadev = stm32_dma_chan_get_dev(chan);
>> +
>> +   dev_dbg(chan2dev(chan), "SCR:   0x%08x\n",
>> +   stm32_dma_read(dmadev, STM32_DMA_SCR(chan->id)));
>> +   dev_dbg(chan2dev(chan), "NDTR:  0x%08x\n",
>> +   stm32_dma_read(dmadev, STM32_DMA_SNDTR(chan->id)));
>> +   dev_dbg(chan2dev(chan), "SPAR:  0x%08x\n",
>> +   stm32_dma_read(dmadev, STM32_DMA_SPAR(chan->id)));
>> +   dev_dbg(chan2dev(chan), "SM0AR: 0x%08x\n",
>> +   stm32_dma_read(dmadev, STM32_DMA_SM0AR(chan->id)));
>> +   dev_dbg(chan2dev(chan), "SM1AR: 0x%08x\n",
>> +   stm32_dma_read(dmadev, STM32_DMA_SM1AR(chan->id)));
>> +   dev_dbg(chan2dev(chan), "SFCR:  0x%08x\n",
>> +   stm32_dma_read(dmadev, STM32_DMA_SFCR(chan->id)));
>> +}
>
>
> Even at dev_dbg() this looks like log spam. This debug info gets issued
> every time we set up a transfer!

Yes, this info will be logged after each transfer.
But it will complete other debug info print when DMADEVICES_DEBUG is set.

>
>
>> +static int stm32_dma_alloc_chan_resources(struct dma_chan *c)
>> +{
>> +   struct stm32_dma_chan *chan = to_stm32_dma_chan(c);
>> +   struct stm32_dma_device *dmadev = stm32_dma_chan_get_dev(chan);
>> +   int ret;
>> +
>> +   chan->config_init = false;
>> +   ret = clk_prepare_enable(dmadev->clk);
>> +   if (ret < 0) {
>> +   dev_err(chan2dev(chan), "clk_prepare_enable failed: %d\n",
>> ret);
>> +   return ret;
>> +   }
>> +
>> +   ret = stm32_dma_disable_chan(chan);
>> +
>> +   return ret;
>> +}
>
>
> The error path here looks like it will leak clock references.

Sorry I didn't catch it. What does it mean ?

>
>
>
>> +static int stm32_dma_probe(struct platform_device *pdev)
>> +{
>> +   struct stm32_dma_chan *chan;
>> +   struct stm32_dma_device *dmadev;
>> +   struct dma_device *dd;
>> +   const struct of_device_id *match;
>> +   unsigned int i;
>> +   struct resource *res;
>> +   int ret;
>> +
>> +   match = of_match_device(stm32_dma_of_match, >dev);
>> +   if (!match) {
>> +   dev_err(>dev, "Error: No device match found\n");
>> +   return -ENODEV;
>> +   }
>> +
>> +   dmadev = devm_kzalloc(>dev, sizeof(*dmadev), GFP_KERNEL);
>> +   if (!dmadev)
>> +   return -ENOMEM;
>> +
>> +   dd = >ddev;
>> +
>> +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +   dmadev->base = devm_ioremap_resource(>dev, res);
>> +   if (IS_ERR(dmadev->base))
>> +   return PTR_ERR(dmadev->base);
>> +
>> +   dmadev->clk = devm_clk_get(>dev, NULL);
>> +   if (IS_ERR(dmadev->clk)) {
>> +   dev_err(>dev, "Error: Missing controller clock\n");
>> +   return PTR_ERR(dmadev->clk);
>> +   }
>> +
>> +   dmadev->mem2mem = of_property_read_bool(pdev->dev.of_node,
>> +   "st,mem2mem");
>> +
>> +   dmadev->rst = 

RE: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

[Gabriele Paoloni]

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Tuesday, October 13, 2015 12:19 PM
> To: Gabriele Paoloni
> Cc: Wangzhou (B); Bjorn Helgaas; Bjorn Helgaas; jingooh...@gmail.com;
> pratyush.an...@gmail.com; li...@arm.linux.org.uk;
> thomas.petazz...@free-electrons.com; lorenzo.pieral...@arm.com;
> james.mo...@arm.com; liviu.du...@arm.com; ja...@lakedaemon.net;
> r...@kernel.org; gabriel.fernan...@linaro.org;
> minghuan.l...@freescale.com; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicetree@vger.kernel.org; linux-
> ker...@vger.kernel.org; zhangjukuo; qiuzhenfa; liudongdong (C);
> qiujiang; xuwei (O); Liguozhu (Kenneth); Wangkefeng (Kevin); Rob
> Herring
> Subject: Re: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for
> HiSilicon SoC Hip05
> 
> On Tuesday 13 October 2015 06:58:42 Gabriele Paoloni wrote:
> >
> > > >> +
> > > >> +static int __init hisi_pcie_init(void)
> > > >> +{
> > > >> +  return platform_driver_probe(_pcie_driver,
> hisi_pcie_probe);
> > > >> +}
> > > >> +subsys_initcall(hisi_pcie_init);
> > > >
> > > > Can you use module_platform_driver() or
> module_platform_driver_probe()
> > > > here instead of the subsys_initcall()?  No, I don't really know
> what
> > > > the difference between module_platform_driver() and
> > > > module_platform_driver_probe() is, sorry :)
> 
> module_platform_driver_probe() will only call the probe function once
> (and fail in case of -EPROBE_DEFER), while module_platform_driver()
> installs the platform driver in a way that the device can be bound
> and unbound at any point.
> 
> > > In fact, I used module_platform_driver_probe in previous version,
> but
> > > A PCIe VGA card of HiSilicon will use Hip05 PCIe host, so we
> modified
> > > module_platform_driver_probe to subsys_initcall which will be
> called
> > > before module_platform_driver_probe.
> > >
> > > We will upstream the driver of above PCIe VGA card soon.
> 
> I don't see a reason why a VGA driver would need the PCI host to be
> probed this early, unless it is the only usable console in the system.
> 
> > Hi Bjorn, firstly many thanks for looking at this.
> >
> > About this last bit the reason why we use subsys_initcall() is that
> > our host bridge is embedded in the SoC and as such is not hot-
> pluggable
> > for instance see:
> > http://lxr.free-electrons.com/source/Documentation/driver-
> model/platform.txt#L59
> 
> We should still be able to build the driver as a loadable module,
> even if you don't do that on your own kernels.

Hi Arnd, I don't see the point of having loadable KOs for platform
devices that are integrated into SoCs (like PCIe Host Controllers...)

> 
> This doesn't mean that it has to be module_platform_driver,
> subsys_initcall
> will also work in a loadable module, it just won't be as early. However,
> we should try to come up with a consistent approach for all PCI host
> drivers,
> I don't see any reason for hisi to be different from the others here.

To me it sounds more appropriate to adopt subsys_initcall() for all the
PCI Host Bridge controllers rather than having them as loadable modules...

What is your view?

Thanks

Gab

> 
> > Our approach is also used by Exynos:
> > http://lxr.free-electrons.com/source/drivers/pci/host/pci-
> exynos.c#L644
> 
> Maybe we should change that too.
> 
>   Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/4] dmaengine: Add STM32 DMA driver

[Daniel Thompson]

On 14/10/15 08:54, M'boumba Cedric Madianga wrote:

+static int stm32_dma_alloc_chan_resources(struct dma_chan *c)
+{
+   struct stm32_dma_chan *chan = to_stm32_dma_chan(c);
+   struct stm32_dma_device *dmadev = stm32_dma_chan_get_dev(chan);
+   int ret;
+
+   chan->config_init = false;
+   ret = clk_prepare_enable(dmadev->clk);
+   if (ret < 0) {
+   dev_err(chan2dev(chan), "clk_prepare_enable failed: %d\n",
ret);
+   return ret;
+   }
+
+   ret = stm32_dma_disable_chan(chan);
+
+   return ret;
+}



The error path here looks like it will leak clock references.


Sorry I didn't catch it. What does it mean ?


If stm32_dma_disable_chan() returns an error then we will not restore 
the original the clock counts causing them to "leak".



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

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Mark Brown]

On Wed, Oct 14, 2015 at 08:28:12AM +0100, Lee Jones wrote:
> On Tue, 13 Oct 2015, Mark Brown wrote:
> > On Tue, Oct 13, 2015 at 09:02:18AM +0100, Lee Jones wrote:

> > > Providing Acks should not (and has not to my knowledge) be a binding
> > > contract to continue providing Acks.  However, should more bindings be
> > > submitted which appear as though they are related to a particular
> > > maintainer, then sure, you'll be asked for your expert eye again.

> > It's a bit concerning when it seems like my review is becoming a blocker
> > for something and I don't understand why.

> Not necessarily _your_ review.  Just someone, other than the
> submitter, who I trust and knows about this stuff.  You just happen 
> to tick those boxes this time.  Cross pollination and knowledge sharing
> is one of the characteristics of MLs which I'm particularly proud of.

That was what it read like.

> > When your power budget is in the low double digit microamps and you're
> > trying to respond promptly and reliably to rapidly changing and variable
> > physical inputs it gets complicated.

> This is exactly why I asked you.

> Thanks for adding structure to my PoV. ;) 

So, a more specific question would have helped - just a general "any
thoughts" type question isn't very clear.


signature.asc
Description: PGP signature

RE: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

[Gabriele Paoloni]

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Wednesday, October 14, 2015 10:42 AM
> To: Gabriele Paoloni
> Cc: Wangzhou (B); Bjorn Helgaas; Bjorn Helgaas; jingooh...@gmail.com;
> pratyush.an...@gmail.com; li...@arm.linux.org.uk;
> thomas.petazz...@free-electrons.com; lorenzo.pieral...@arm.com;
> james.mo...@arm.com; liviu.du...@arm.com; ja...@lakedaemon.net;
> r...@kernel.org; gabriel.fernan...@linaro.org;
> minghuan.l...@freescale.com; linux-...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; devicetree@vger.kernel.org; linux-
> ker...@vger.kernel.org; zhangjukuo; qiuzhenfa; liudongdong (C);
> qiujiang; xuwei (O); Liguozhu (Kenneth); Wangkefeng (Kevin); Rob
> Herring
> Subject: Re: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for
> HiSilicon SoC Hip05
> 
> On Wednesday 14 October 2015 09:31:48 Gabriele Paoloni wrote:
> > >
> > > > To me it sounds more appropriate to adopt subsys_initcall() for
> all
> > > the
> > > > PCI Host Bridge controllers rather than having them as loadable
> > > modules...
> > > >
> > > > What is your view?
> > >
> > > subsys_initcall() sounds odd because it's a driver rather than a
> > > subsystem,
> > > but I realize that most of the other levels don't fit any better.
> >
> > Yes well I was seeing for example the vgaarb
> > http://lxr.free-electrons.com/source/drivers/gpu/vga/vgaarb.c#L1357
> >
> > That in the init is calling pci_get_subsys()
> >
> > So I was wondering that the PCI devices may not be registered unless
> > we also init the PCI host bridge through subsys_initcall()...
> 
> I think this should work as is: the code first looks for devices
> that are already there and then registers a notifier for devices
> that show up later. This is meant to work for both devices that
> are hotplugged at a later point as well as PCI buses that are
> already there but not yet probed.
> 
> > But then maybe is the vgaarb to be buggy...
> 
> Possible. It may well be that the code is only tested on x86,
> which always probes its PCI very early.
> 
> > > As I said, it's not really a choice we have to make in the source
> code,
> > > we can use subsys_initcall together with module_exit(), or we can
> > > create a helper macro that is similar to module_platform_driver()
> > > specifically for PCI that uses a particular initcall level.
> >
> > Ok got it. But I guess this needs to be thought and applied to all
> > the PCI host bridge controllers...
> >
> > So maybe for this driver I can use module_platform_driver_probe()
> > and then we can see...
> 
> Sounds good. Let's focus on getting the driver merged first and
> then follow up with a patch to get this right for all PCI hosts.

Ok good let's do like this then

will change in v11

Again Many Thanks

Gab

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

Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver

[Javier Martinez Canillas]

Hello Yakir,

On 10/13/2015 03:50 PM, Yakir Yang wrote:
> On 10/13/2015 05:21 PM, Javier Martinez Canillas wrote:
> 

[snip]

>>> And it's better to enable pstore function on mainline kernel, so we can 
>>> analysis the last log when
>>> the mainline kernel crashed. After enable PSTORE_RAM in .config, we still 
>>> need add ramoops node
>> Interesting, I knew about pstore but I never used it with the Exynos 
>> Chromebooks.
>>
>>> into file, like:
>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>> @@ -750,6 +750,15 @@
>>>  iommu = <_gsc3>;
>>>  };
>>>
>>> +   ramoops: ramoops {
>>> +   compatible = "ramoops";
>>> +   name = "ramoops";
>>> +   reg = <0x41f0 0x10>;
>>> +   record-size = <0x2>;
>>> +   dump-oops;
>>> +   status = "okay";
>>> +   };
>>> +
>> Are you using mainline? There isn't a "ramoops" compatible string documented
>> in the upstream DT bindings, platform_match() would match by driver name as
>> a fallback but I don't see code in fs/pstore/ram.c that parses the properties
>> in your device node. I wonder how this works for you or did I missunderstand?
> 
> Aha, I lost some things that I back port the pstore/ram.c from chrome
> v3.14 tree which driver would parsed the "ramoops" compatible.
>

Ah, that explains it then.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/4] dt-bindings: Document the STM32 DMA bindings

[M'boumba Cedric Madianga]

Hi Mark,

2015-10-13 18:21 GMT+02:00 Mark Rutland :
>> >> +4. A 32bit mask specifying the DMA channel configuration
>> >> + -bit 1: Direct Mode Error Interrupt
>> >> + 0x0: disabled
>> >> + 0x1: enabled
>> >> + -bit 2: Transfer Error Interrupt
>> >> + 0x0: disabled
>> >> + 0x1: enabled
>> >> + -bit 3: Half Transfer Mode Error Interrupt
>> >> + 0x0: disabled
>> >> + 0x1: enabled
>> >> + -bit 4: Transfer Complete Interrupt
>> >> + 0x0: disabled
>> >> + 0x1: enabled
>> >
> The DT is separate from what the client driver might want, so if
> different clients want different things, that should be requested in a a
> generic and dnyamic fashion through the dmaengine API, with the physical
> details left to the DMA controller driver.
>
> I really don't see why the DTS author should be in charge of how the DMA
> controller driver chooses to use interrupts in this fashion.
>

Ok got it. As enabling all interrupts by default does not influence
DMA behavior I will remove these inputs from DT.
Thanks for this explanation.

>
>> >> + -bit 9: Peripheral Increment Address
>> >> + 0x0: no address increment between transfers
>> >> + 0x1: increment address between transfers
>> >> + -bit 10: Memory Increment Address
>> >> + 0x0: no address increment between transfers
>> >> + 0x1: increment address between transfers
>> >
> I'd have expected other DMA controllers to also need to handle this, but
> from a quick skim of bindings I couldn't spot anything similar, so I
> assume that this gets handled somehow dynamically.
>
> Do you know what other DMA controllers do for cases like this in Linux?

After quick search I don't find any other DMA controller that handles
this problematic.
For sure, there is no way to handle it thanks to dmaengine API.

Then, I know that previously many DMA clients could pass specific
information during channel request thanks to *fn_param as below:
struct dma_chan *__dma_request_channel(const dma_cap_mask_t *mask,
dma_filter_fn fn, void *fn_param)
But now, this API seems obsolete has new platform has to request
channel thanks to DT inputs via dma_request_slave_channel(struct
device *dev, const char *name) API.
In that way, all specific information has to be retrieved from DT.

>
>> But others clients could do it by incrementing an memory area after
>> each transfer and in this case PINC=1.
>> I don't have any example in mind for the second use case but as the
>> DMA supports it I would like to keep it.
>
> Similarly this seems odd. What do other DMA controllers do?

Same remark as above

>
>
>> >> +5. A 32bit mask specifying the DMA FIFO configuration
>> >> + -bit 0-1: Fifo threshold
>> >> + 0x0: 1/4 full FIFO
>> >> + 0x1: 1/2 full FIFO
>> >> + 0x2: 3/4 full FIFO
>> >> + 0x3:full FIFO
>> >
> Likewise there seems to be precedent for this. I don't know whether it
> really makes sense for this to be in the DT.

Same remark as above. We abolutely need to retrieve it from DT.
Moreover, this point really influence DMA controller behavior in term
of performance.

>
>> >> + -bit 7: FIFO Error Interrupt
>> >> + 0x0: disabled
>> >> + 0x1: enabled
>> >
>> > As with the other interrupt configuration, this does not look like it
>> > belongs in the DT.
>> Again the driver could set default configuration and don't let the DMA
>> client set it.
>> The goal here is to offer for each DMA client a way to choose his
>> level of information when an error occured on DMA bus.
>
> As with the other interrupts, I still don't believe this should be in
> the DT.

As other interrupt configuration, I will remove it from DT.

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

Re: [PATCH 1/2] ARM: dts: fix gpio-keys wakeup-source property

[Sudeep Holla]

On 14/10/15 01:13, Simon Horman wrote:

[cc linux-sh]

On Tue, Oct 13, 2015 at 02:32:43PM +0100, Sudeep Holla wrote:

The keyboard driver for GPIO buttons(gpio-keys) checks for one of the
two boolean properties to enable gpio buttons as wakeup source:
1. "wakeup-source" or
2. the legacy "gpio-key,wakeup"

However juno, ste-snowball and emev2-kzm9d dts file have a undetected
"wakeup" property to indictate the wakeup source.

This patch fixes it by making use of "wakeup-source" property.

Cc: Simon Horman 
Cc: Magnus Damm 
Cc: Linus Walleij 
Signed-off-by: Sudeep Holla 
---
  arch/arm/boot/dts/emev2-kzm9d.dts |  8 
  arch/arm/boot/dts/ste-snowball.dts| 10 +-
  arch/arm64/boot/dts/arm/juno-motherboard.dtsi | 12 ++--
  3 files changed, 15 insertions(+), 15 deletions(-)


emev2-kzm9d portion:

Acked-by: Simon Horman 

My preferred course of action would be to take that portion through the
renesas tree if it was broken out into a separate patch. But I won't
object if someone wants to take the whole patch/series.


I can split this patch, but it is more like a bug fix IMO, I can't use
these GPIO as wakeup on Juno. So I hope arm-soc guys take it directly.
If not, I can split and sent it separately.

--
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 v10 4/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

[Arnd Bergmann]

On Wednesday 14 October 2015 16:59:03 Zhou Wang wrote:
> 
> Hi Arnd,
> 
> In Hip05 PCIe host, it uses GITS_TRANSLATER's address to get TLP package
> which contains MSI address and MSI data, and then combine BDF and MSI data
> to a 32 bit data which will be writen to GITS_TRANSLATER register of ITS.
> 
> I think maybe this is a defect of our PCIe controller.

I'd consider it a bug in the firmware if this is not set up correctly
before boot.

> > I don't think what you do here is safe because the 'reg' property
> > of the MSI controller might point to the address that is used for
> > the message directly.
> 
> I see your point, however we must get address of GITS_TRANSLATER and
> set it to PCIe host. How about adding necessary comments here?

This seems to just be static setup that should be done before Linux
is even loaded. Any reason you can't do it that way?

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

Re: [PATCH] dt-bindings: Correct the example for Exynos power domain clocks

[Javier Martinez Canillas]

[dropping my old email address from the cc list]

Hello Krzysztof,

On 10/14/2015 08:02 AM, Krzysztof Kozlowski wrote:
> Since commit 29e5eea06bc1 ("ARM: EXYNOS: Get current parent clock for
> power domain on/off") the "pclkN" names of "clock-names" property is not
> parsed any more. The bindings and driver were updated but the example
> was not. Fix the example now.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt 
> b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> index e151057d92f0..4e947372a693 100644
> --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> @@ -43,9 +43,8 @@ Example:
>   mfc_pd: power-domain@10044060 {
>   compatible = "samsung,exynos4210-pd";
>   reg = <0x10044060 0x20>;
> - clocks = < CLK_FIN_PLL>, < CLK_MOUT_SW_ACLK333>,
> - < CLK_MOUT_USER_ACLK333>;
> - clock-names = "oscclk", "pclk0", "clk0";
> + clocks = < CLK_FIN_PLL>, < CLK_MOUT_USER_ACLK333>;
> + clock-names = "oscclk", "clk0";
>   #power-domain-cells = <0>;
>   };
>  
> 

Reviewed-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "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 27/27] ARM: dts: omap3: Fix gpmc and NAND nodes

[Roger Quadros]

Tony,

On 13/10/15 18:18, Tony Lindgren wrote:
> * Roger Quadros  [151012 23:33]:
>> On 13/10/15 03:43, Tony Lindgren wrote:
>>> * Roger Quadros  [150918 08:00]:
 Add compatible id, GPMC register resource and interrupt
 resource to NAND controller nodes.

 The GPMC driver now implements gpiochip and irqchip so
 enable gpio-controller and interrupt-controller properties.

 With this the interrupt parent of NAND node changes so fix it
 accordingly.
>>> ...
 --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
 +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
 @@ -35,11 +35,14 @@
  };
  
   {
 -  ranges = <0 0 0x 0x100>;/* CS0: 16MB for NAND */
 +  ranges = <0 0 0x0800 0x100>;/* CS0: 16MB for NAND */
  
nand@0,0 {
 -  linux,mtd-name = "micron,mt29f4g16abbda3w";
 +  compatible = "ti,omap2-nand";
reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
 +  interrupt-parent = <>;
 +  interrupts = <20>;
 +  linux,mtd-name = "micron,mt29f4g16abbda3w";
nand-bus-width = <16>;
ti,nand-ecc-opt = "bch8";
gpmc,sync-clk-ps = <0>;
>>>
>>> At least torpedo breaks for NFSroot as NAND now overlaps with
>>> Ethernet.. What's the policy you have for moving the addresses
>>> around?
>>
>> For OMAP3 I intended to use 0x3000 for NAND but incorrectly
>> used 0x0800 for the torpedo.
> 
> Might be worth adding some documentation of suggested standardized
> mappings.. For most of theme we could just add them as 16MB chunks,
> then reserve some larger area for NOR?

As GPMC peripherals are not plug and play the GPMC map is specific to
the board and need not necessarily apply to all boards.
So I don't think we need to have any standardized mappings.

> 
>> Does setting it to 0x3000 work? If not what is the original
>> NAND address for this board?
> 
> The u-boot addresses are probably what were used in the .dts* files.
> Setting NAND to 0x3000 is not enough though, looks like there's
> a bug where the logicpd-torpedo-37xx-devkit.dts ranges is missing
> the NAND range in logicpd-torpedo-som.dtsi. Something like the
> patch below seems to make things work again, might be worth
> checking what ranges make sense to standardize on though. Please
> feel free to fold it into your patches.

Thanks. I'll post a revised patch.

> 
>>> There may be other similar cases to check too.
>>
>> Just checked that all other OMAP3 boards I've set to 0x3000
>> if they were 0x0.
> 
> Do you want to reserve a large chunk for NOR at cs0 or what's
> the reason for picking 0x3000 for NAND?

All of the OMAP3 boards were using 0x3000. Probably copy paste effect? :)
What's the point of reserving anything for NOR. If the board doesn't already
have NOR it never will. Future board having NOR can have its own GPMC map.
> 
> I guess NOR can be also on other chipselects.. Not sure we can
> standardize on any specific partition scheme?

Exactly.

cheers,
-roger

> 
> Regards,
> 
> Tony
> 
> 8< 
> --- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
> +++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
> @@ -73,7 +73,8 @@
>  };
>  
>   {
> - ranges = <1 0 0x0800 0x100>;/* CS1: 16MB for LAN9221 */
> + ranges = <0 0 0x3000 0x100  /* CS0: 16MB for NAND */
> +   1 0 0x2c00 0x100>;/* CS1: 16MB for LAN9221 */
>  
>   ethernet@gpmc {
>   pinctrl-names = "default";
> --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> @@ -35,7 +35,7 @@
>  };
>  
>   {
> - ranges = <0 0 0x0800 0x100>;/* CS0: 16MB for NAND */
> + ranges = <0 0 0x3000 0x100>;/* CS0: 16MB for NAND */
>  
>   nand@0,0 {
>   compatible = "ti,omap2-nand";
> 
--
To unsubscribe from this list: send the line "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 2/2] usb: chipidea: imx: refine clock operations to adapt for all platforms

[Marc Kleine-Budde]

On 10/14/2015 03:57 AM, Peter Chen wrote:
> Some i.mx platforms need three clocks to let controller work, but
> others only need one, refine clock operation to adapt for all
> platforms, it fixes a regression found at i.mx27.
> 
> Signed-off-by: Peter Chen 
> Tested-by: Fabio Estevam 
> Cc:  #v4.1+
> ---
>  drivers/usb/chipidea/ci_hdrc_imx.c | 132 
> -
>  1 file changed, 114 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
> b/drivers/usb/chipidea/ci_hdrc_imx.c
> index 6ccbf60..82b1dfe 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -84,6 +84,12 @@ struct ci_hdrc_imx_data {
>   struct imx_usbmisc_data *usbmisc_data;
>   bool supports_runtime_pm;
>   bool in_lpm;
> + /* SoC before i.mx6 (except imx23/imx28) needs three clks */
> + bool need_three_clks;
> + struct clk *clk_ipg;
> + struct clk *clk_ahb;
> + struct clk *clk_per;
> + /* - */
>  };
>  
>  /* Common functions shared by usbmisc drivers */
> @@ -135,6 +141,103 @@ static struct imx_usbmisc_data 
> *usbmisc_get_init_data(struct device *dev)
>  }
>  
>  /* End of common functions shared by usbmisc drivers*/
> +static int imx_get_clks(struct device *dev)
> +{
> + struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
> + int ret = 0;
> +
> + data->clk_ipg = devm_clk_get(dev, "ipg");
> + if (IS_ERR(data->clk_ipg)) {
> + /* If the platform only needs one clocks */
> + data->clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(data->clk)) {
> + ret = PTR_ERR(data->clk);
> + dev_err(dev,
> + "Failed to get clock, err=%d\n", ret);
> + dev_err(dev,
> + "Failed to get ipg clock, err=%d\n", ret);

Nitpick, one error message should be enough.

> + return ret;
> + }
> + return ret;
> + }
> +
> + data->clk_ahb = devm_clk_get(dev, "ahb");
> + if (IS_ERR(data->clk_ahb)) {
> + ret = PTR_ERR(data->clk_ahb);
> + dev_err(dev,
> + "Failed to get ahb clock, err=%d\n", ret);
> + return ret;
> + }
> +
> + data->clk_per = devm_clk_get(dev, "per");
> + if (IS_ERR(data->clk_per)) {
> + ret = PTR_ERR(data->clk_per);
> + dev_err(dev,
> + "Failed to get per clock, err=%d\n", ret);
> + return ret;
> + }
> +
> + data->need_three_clks = true;
> + return ret;
> +}
> +
> +static int imx_prepare_enable_clks(struct device *dev)
> +{
> + struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
> + int ret = 0;
> +
> + if (data->need_three_clks) {
> + ret = clk_prepare_enable(data->clk_ipg);
> + if (ret) {
> + dev_err(dev,
> + "Failed to prepare/enable ipg clk, err=%d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(data->clk_ahb);
> + if (ret) {
> + dev_err(dev,
> + "Failed to prepare/enable ahb clk, err=%d\n",
> + ret);
> + clk_disable_unprepare(data->clk_ipg);
> + return ret;
> + }
> +
> + ret = clk_prepare_enable(data->clk_per);
> + if (ret) {
> + dev_err(dev,
> + "Failed to prepare/enable per clk, err=%d\n",
> + ret);
> + clk_disable_unprepare(data->clk_ahb);
> + clk_disable_unprepare(data->clk_ipg);
> + return ret;
> + }
> + } else {
> + ret = clk_prepare_enable(data->clk);
> + if (ret) {
> + dev_err(dev,
> + "Failed to prepare/enable clk, err=%d\n",
> + ret);
> + return ret;
> + }
> + }
> +
> + return ret;
> +}
> +
> +static void imx_disable_unprepare_clks(struct device *dev)
> +{
> + struct ci_hdrc_imx_data *data = dev_get_drvdata(dev);
> +
> + if (data->need_three_clks) {
> + clk_disable_unprepare(data->clk_per);
> + clk_disable_unprepare(data->clk_ipg);
> + clk_disable_unprepare(data->clk_ahb);

nit: you enable in this order: ipg, ahb, per. Disabling should be inverse.

> + } else {
> + clk_disable_unprepare(data->clk);
> + }
> +}

Marc

-- 
Pengutronix e.K.  | Marc Kleine-Budde   |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung 

Re: [PATCH v9 3/6] pci:host: Add Altera PCIe host controller driver

[Arnd Bergmann]

On Wednesday 14 October 2015 10:41:29 Ley Foon Tan wrote:
> +static int altera_pcie_remove(struct platform_device *pdev)
> +{
> + struct altera_pcie *pcie = platform_get_drvdata(pdev);
> +
> + altera_pcie_free_irq_domain(pcie);
> + platform_set_drvdata(pdev, NULL);
> + return 0;
> +}

I just noticed this. Does it actually work to unload the module
and tear down all the pci_dev structures in a safe way?

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

Re: [PATCH] ARM: dts: am437x-gp-evm: Add wakeup interrupt source for pixcir_i2c_ts

[Roger Quadros]

+Dave

On 14/10/15 08:52, Vignesh R wrote:
> On am437x-gp-evm, pixcir_i2c_ts can wakeup the system from lower power
> state via pinctrl and IO daisy chain using generic wakeirq framework.
> With commit 3fffd1283927 ("i2c: allow specifying separate wakeup
> interrupt in device tree") i2c core allows optional wakeirq to be
> specified via device tree. Add wakeup irq entry to enable pixcir_i2c_ts
> to wake the system from low power state.
> 
> Signed-off-by: Vignesh R 
> ---
>  arch/arm/boot/dts/am437x-gp-evm.dts | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
> b/arch/arm/boot/dts/am437x-gp-evm.dts
> index 22038f21f228..69e93af7df0d 100644
> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
> @@ -581,8 +581,13 @@
>  
>   attb-gpio = < 22 GPIO_ACTIVE_HIGH>;
>  
> + interrupts-extended = < 22 GPIO_ACTIVE_HIGH>,
> +   <_pinmux 0x264>;

How does this work?

interrupts-extended property must have
1) interrupt parent
2) interrupt number
3) interrupt flags

Your change doesn't seem to comply with those requirements.

> + interrupt-names = "tsc", "wakeup";
> +
>   touchscreen-size-x = <1024>;
>   touchscreen-size-y = <600>;
> + wakeup-source;
>   };
>  
>   ov2659@30 {
> 

cheers,
-roger
--
To unsubscribe from this list: send the line "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 v10 4/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

[Zhou Wang]

On 2015/10/13 23:00, Arnd Bergmann wrote:
> On Tuesday 13 October 2015 14:49:07 Gabriele Paoloni wrote:
>>> On Monday 12 October 2015 16:35:45 Bjorn Helgaas wrote:

> +{
> + u64 addr;
> + struct device_node *msi_node;
> + struct resource res;
> + struct device_node *np = pp->dev->of_node;
> + struct hisi_pcie *pcie = to_hisi_pcie(pp);
> +
> + msi_node = of_parse_phandle(np, "msi-parent", 0);
> + if (!msi_node) {
> + dev_err(pp->dev, "failed to find msi-parent\n");
> + return -EINVAL;
> + }
> + of_address_to_resource(msi_node, 0, );

 Does this use the "msi-parent" node in the same way as other drivers
 do?  I'm sure there must be other places where we extract struct
 resource information from an "msi-parent" node, but I don't see them.

 I'm trying to verify that this isn't some kind of incompatible
 extension of the "msi-parent" property.  I cc'd Arnd and Rob (DT
 experts).
>>>
>>> This is not ok, what this does is that it relies on a particular
>>> implementation of the MSI controller and directly accesses its
>>> registers.
>>
>> Hi Arnd, thanks for reviewing.
>>
>> What we do is to retrieve the msi-parent physical address and we store it
>> in our internal PCIe register locations...
> 
> Ah, thanks for the clarification, I missed that part.
> 
>> So we do not operate directly on the msi controller registers...
>>
>> So I wonder if the current implementation is Ok to retrieve the
>> msi-parent address
> 
> Not sure. Why do you do this? Normally the PCI host does not know
> or care about the address of the MSI controller, because the messages
> are just passed up to the parent bus as DMA transfers.
>

Hi Arnd,

In Hip05 PCIe host, it uses GITS_TRANSLATER's address to get TLP package
which contains MSI address and MSI data, and then combine BDF and MSI data
to a 32 bit data which will be writen to GITS_TRANSLATER register of ITS.

I think maybe this is a defect of our PCIe controller.

> I don't think what you do here is safe because the 'reg' property
> of the MSI controller might point to the address that is used for
> the message directly.

I see your point, however we must get address of GITS_TRANSLATER and set it to 
PCIe
host. How about adding necessary comments here?

Best Regards,
Zhou

>
>   Arnd
> 
> .
> 


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

Re: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

[Arnd Bergmann]

On Wednesday 14 October 2015 08:34:43 Gabriele Paoloni wrote:
> > -Original Message-
> > From: Arnd Bergmann [mailto:a...@arndb.de]
> > Sent: Tuesday, October 13, 2015 12:19 PM
> > To: Gabriele Paoloni
> > Cc: Wangzhou (B); Bjorn Helgaas; Bjorn Helgaas; jingooh...@gmail.com;
> > pratyush.an...@gmail.com; li...@arm.linux.org.uk;
> > thomas.petazz...@free-electrons.com; lorenzo.pieral...@arm.com;
> > james.mo...@arm.com; liviu.du...@arm.com; ja...@lakedaemon.net;
> > r...@kernel.org; gabriel.fernan...@linaro.org;
> > minghuan.l...@freescale.com; linux-...@vger.kernel.org; linux-arm-
> > ker...@lists.infradead.org; devicetree@vger.kernel.org; linux-
> > ker...@vger.kernel.org; zhangjukuo; qiuzhenfa; liudongdong (C);
> > qiujiang; xuwei (O); Liguozhu (Kenneth); Wangkefeng (Kevin); Rob
> > Herring
> > Subject: Re: [PATCH v10 4/6] PCI: hisi: Add PCIe host support for
> > HiSilicon SoC Hip05
> > 
> > On Tuesday 13 October 2015 06:58:42 Gabriele Paoloni wrote:
> > >
> > > > >> +
> > > > >> +static int __init hisi_pcie_init(void)
> > > > >> +{
> > > > >> +  return platform_driver_probe(_pcie_driver,
> > hisi_pcie_probe);
> > > > >> +}
> > > > >> +subsys_initcall(hisi_pcie_init);
> > > > >
> > > > > Can you use module_platform_driver() or
> > module_platform_driver_probe()
> > > > > here instead of the subsys_initcall()?  No, I don't really know
> > what
> > > > > the difference between module_platform_driver() and
> > > > > module_platform_driver_probe() is, sorry 
> > 
> > module_platform_driver_probe() will only call the probe function once
> > (and fail in case of -EPROBE_DEFER), while module_platform_driver()
> > installs the platform driver in a way that the device can be bound
> > and unbound at any point.
> > 
> > > > In fact, I used module_platform_driver_probe in previous version,
> > but
> > > > A PCIe VGA card of HiSilicon will use Hip05 PCIe host, so we
> > modified
> > > > module_platform_driver_probe to subsys_initcall which will be
> > called
> > > > before module_platform_driver_probe.
> > > >
> > > > We will upstream the driver of above PCIe VGA card soon.
> > 
> > I don't see a reason why a VGA driver would need the PCI host to be
> > probed this early, unless it is the only usable console in the system.
> > 
> > > Hi Bjorn, firstly many thanks for looking at this.
> > >
> > > About this last bit the reason why we use subsys_initcall() is that
> > > our host bridge is embedded in the SoC and as such is not hot-
> > pluggable
> > > for instance see:
> > > http://lxr.free-electrons.com/source/Documentation/driver-
> > model/platform.txt#L59
> > 
> > We should still be able to build the driver as a loadable module,
> > even if you don't do that on your own kernels.
> 
> Hi Arnd, I don't see the point of having loadable KOs for platform
> devices that are integrated into SoCs (like PCIe Host Controllers...)

Mainly we want as many drivers as possible to be loadable modules,
and there is no reason why PCI needs to be different from other
subsystems here.

> > This doesn't mean that it has to be module_platform_driver,
> > subsys_initcall
> > will also work in a loadable module, it just won't be as early. However,
> > we should try to come up with a consistent approach for all PCI host
> > drivers,
> > I don't see any reason for hisi to be different from the others here.
> 
> To me it sounds more appropriate to adopt subsys_initcall() for all the
> PCI Host Bridge controllers rather than having them as loadable modules...
> 
> What is your view?

subsys_initcall() sounds odd because it's a driver rather than a subsystem,
but I realize that most of the other levels don't fit any better.

As I said, it's not really a choice we have to make in the source code,
we can use subsys_initcall together with module_exit(), or we can
create a helper macro that is similar to module_platform_driver()
specifically for PCI that uses a particular initcall level.

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

RE: [PATCH v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

[Harvey Hunt]

On 8 October 2015 at 22:23, Ezequiel Garcia < ezequ...@vanguardiasur.com.ar> 
wrote:
>On 6 October 2015 at 13:27, Harvey Hunt  wrote:
>> From: Alex Smith 
>>
>> Add device tree nodes for the NEMC and BCH to the JZ4780 device tree,
>> and make use of them in the Ci20 device tree to add a node for the
>> board's NAND.
>>
>> Note that since the pinctrl driver is not yet upstream, this includes
>> neither pin configuration nor busy/write-protect GPIO pins for the
>> NAND. Use of the NAND relies on the boot loader to have left the pins
>> configured in a usable state, which should be the case when booted
>> from the NAND.
>>
>> Signed-off-by: Alex Smith 
>> Cc: Zubair Lutfullah Kakakhel 
>> Cc: David Woodhouse 
>> Cc: Brian Norris 
>> Cc: Paul Burton 
>> Cc: linux-...@lists.infradead.org
>> Cc: devicetree@vger.kernel.org
>> Cc: linux-ker...@vger.kernel.org
>> Cc: linux-m...@linux-mips.org
>> Cc: Alex Smith 
>> Signed-off-by: Harvey Hunt 
>> ---
>> v6 -> v7:
>>  - Add nand-ecc-mode to DT.
>>  - Add nand-on-flash-bbt to DT.
>>
>> v4 -> v5:
>>  - New patch adding DT nodes for the NAND so that the driver can be
>>tested.
>>
>>  arch/mips/boot/dts/ingenic/ci20.dts| 54 
>> ++
>>  arch/mips/boot/dts/ingenic/jz4780.dtsi | 26 
>>  2 files changed, 80 insertions(+)
>>
>> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
>> b/arch/mips/boot/dts/ingenic/ci20.dts
>> index 9fcb9e7..453f1d3 100644
>> --- a/arch/mips/boot/dts/ingenic/ci20.dts
>> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
>> @@ -42,3 +42,57 @@
>>   {
>> status = "okay";
>>  };
>> +
>> + {
>> +   status = "okay";
>> +
>> +   nand: nand@1 {
>> +   compatible = "ingenic,jz4780-nand";
>> +   reg = <1 0 0x100>;
>> +
>
>Why is this in the ci20.dts instead of the SoC dtsi?
>
>Seems at least compatible and reg is not board-specific.
>
>Thanks,
>-- 
>Ezequiel García, VanguardiaSur
>www.vanguardiasur.com.ar

Hi Ezequiel,

The number of NAND nodes under the NEMC node is board specific - some devices
could have 2 NAND banks and others could have none. Including the compatible
property in jz4780.dtsi would imply that all JZ4780 boards have at least one 
NAND bank.

The size in the reg property would be the same for all NAND devices (as it 
refers to the
NAND registers), however the bank number would be different, so that can also 
be seen
as board specific.

Thanks,

Harvey

Re: [PATCH] ARM: dts: am437x-gp-evm: Add wakeup interrupt source for pixcir_i2c_ts

[Vignesh R]

On 10/14/2015 02:16 PM, Roger Quadros wrote:

> 
> On 14/10/15 08:52, Vignesh R wrote:
>> On am437x-gp-evm, pixcir_i2c_ts can wakeup the system from lower power
>> state via pinctrl and IO daisy chain using generic wakeirq framework.
>> With commit 3fffd1283927 ("i2c: allow specifying separate wakeup
>> interrupt in device tree") i2c core allows optional wakeirq to be
>> specified via device tree. Add wakeup irq entry to enable pixcir_i2c_ts
>> to wake the system from low power state.
>>
>> Signed-off-by: Vignesh R 
>> ---
>>  arch/arm/boot/dts/am437x-gp-evm.dts | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
>> b/arch/arm/boot/dts/am437x-gp-evm.dts
>> index 22038f21f228..69e93af7df0d 100644
>> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
>> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
>> @@ -581,8 +581,13 @@
>>  
>>  attb-gpio = < 22 GPIO_ACTIVE_HIGH>;
>>  
>> +interrupts-extended = < 22 GPIO_ACTIVE_HIGH>,
>> +  <_pinmux 0x264>;
> 
> How does this work?
> 
> interrupts-extended property must have
> 1) interrupt parent
> 2) interrupt number
> 3) interrupt flags
> 
> Your change doesn't seem to comply with those requirements.

AFAIU, interrupts-extended has two parts: interrupt parent phandle and
interrupt specifier.
The number of cells in interrupt specifier is determined by
interrupt-cells property of interrupt parent node.
In above case, gpio3 has interrupt-cells = 2 hence interrupt specifier
has interrupt number and interrupt flag field.
But in case am43xx_pinmux node, interrupt-cells is 1 hence has no
interrupt flag field.

-- 
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