Re: [linux-sunxi] [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

[Siarhei Siamashka]

On Mon, 5 Oct 2015 08:58:53 +0300
Siarhei Siamashka  wrote:

> On Mon, 5 Oct 2015 08:39:40 +0300
> Siarhei Siamashka  wrote:
> 
> > On Mon, 5 Oct 2015 09:55:28 +0800
> > Chen-Yu Tsai  wrote:
> > 
> > > On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
> > >  wrote:
> > > > The pcDuino1 board does not use any power switches at all for its
> > > > two USB host ports and the VBUS pins are always connected to 5V.
> > > >
> > > > The pcDuino2 board uses the RT9701GB power switch for its single
> > > > USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> > > > resistor. So that the USB power is still enabled by default even
> > > > if nobody bothers to configure the PD2 pin or runs the pcDuino1
> > > > firmware.
> > > 
> > > Seems like it would be better if you had a regulator controlled
> > > by PD2. At least can shut down VBUS power when it wants to?
> > 
> > That's a good question.
> > 
> > Describing the regulator controlled by PD2 in the dts file is surely
> > the right solution for pcDuino2 boards. But in the case of using this
> > dts for pcDuino1, the kernel would think that it can shut down VBUS
> > power, while in fact this is not true.
> > 
> > The RT9701GB switch also provides the current limiting feature in
> > addition to the ability to enable/disable the VBUS power. Probably
> > this was a real reason why it was added to the board.
> > 
> > Everything boils down to the question whether we want to have a
> > common dts file for pcDuino1 and pcDuino2 or decide to split them.
> > Based on the schematics comparison, there do not seem to be any
> > substantial differences between these boards if we ignore the PD2
> > pin altogether. LinkSprite says that "Ubuntu images are same for
> > both pcDuino1 and pcDuino2" at their website:
> > http://www.linksprite.com/?page_id=809
> > 
> > And I actually like their decision to have the PD2 pin pulled-up.
> 
> I'm not sure if everyone would like this, but the following trick
> works. If we configure the PD2 pin as input with pull-down on the SoC
> side and read it, then it still reads as 1 on pcDuino2. Which means
> that the pull-up is apparently stronger (by how much and whether this
> is really reliable is another question). It should read as 0 on
> pcDuino1 and we might use this to detect the board type at runtime.
> 
> Still it is probably an overkill for just this really minor thing :-)

I few more details about this. I have actually measured the voltage
with/without pull-down on the SoC side (which competes with the 10K
pull-up resistor on the PCB) and the results are the following. The
voltage drops from 3.306V to 3.187V on one board and from 3.325V to
3.204V on another. Based on these numbers, we can in estimate
pull-down resistors used for GPIO inside of the A10 SoC as something
like ~270K Ohm.

As such, it looks like we can do reliable runtime detection of
pcDuino1 and pcDuino2 variants by probing this PD2 pin. The most
appropriate place to do the runtime detection is probably the board
type selection stub (sunxi-bootsetup), run as the initial part of
a Linux distribution installer. We are perfectly fine having
separate dts files for the pcDuino1/pcDuino2 boards and the
kernel does not need to become more complicated.

Probing for pull-up and pull-down resistors on the PCB can be
generalized beyond just PD2 and used to further narrow down the
selection of compatible boards (sunxi-bootsetup currently only
considers the SoC type, DRAM size and DRAM bus width for this).

Additional very interesting observation is that the reference
Allwinner schematics and Cubieboard/Cubietruck boards use 510K
pull-down resistor for the USB power switches. With 270K pull-up
by the SoC and 510K pull-down by a resistor on the PCB, the
resulting voltage is going to be around ~2.2V, which should be
enough to be interpreted as digital 1. And indeed, a quick test
shows that if we just configure either PH3 or PH6 pin as input
with pull-up, then the corresponding USB port gets powered up
on the Cubieboard :-)

There are two important consequences:
* As far as generic device independent code is concerned, we can
  reasonably safely enable USB power on the Cubieboard, Cubietruck
  and other device, which did not deviate from the reference
  Allwinner schematics and used 510K pull-down resistors. Configuring
  pins for input can't possibly do much harm (if any at all).
* By doing run-time checks, we can see the difference between the
  boards using 10K pull-down resistors (OLIMEX boards) and the boards
  using 510K pull-down resistors (CubieTech boards).

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

[Patch v2] firmware: qcom: scm: Convert to platform driver

[Andy Gross]

This patch creates a platform driver for the SCM so that we can adequately
manage resources.  This removes clients having to carry the necessary
clocks to use the SCM resources.

Signed-off-by: Andy Gross 
---
 .../devicetree/bindings/firmware/qcom,scm.txt  |   25 
 drivers/firmware/qcom_scm.c|  135 ++--
 2 files changed, 152 insertions(+), 8 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/firmware/qcom,scm.txt

diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt 
b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
new file mode 100644
index 000..debcd32
--- /dev/null
+++ b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
@@ -0,0 +1,25 @@
+QCOM Secure Channel Manager (SCM)
+
+Qualcomm processors include an interface to communicate to the secure firmware.
+This interface allows for clients to request different types of actions.  These
+can include CPU power up/down, HDCP requests, loading of firmware, and other
+assorted actions.
+
+Required properties:
+- compatible: must contain "qcom,scm"
+- clocks: Should contain the core, iface, and bus clocks.
+- clock-names: Must contain "core" for the core clock, "iface" for the 
interface
+  clock and "bus" for the bus clock.
+
+Example:
+
+   firmware {
+   compatible = "simple-bus";
+
+   scm {
+   compatible = "qcom,scm";
+   clocks = < GCC_CE1_CLK> , < GCC_CE1_AXI_CLK>, 
< GCC_CE1_AHB_CLK>;
+   clock-names = "core", "bus", "iface";
+   };
+   };
+
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 45c008d..7c4ec48 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -10,19 +10,57 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
- * 02110-1301, USA.
  */
-
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "qcom_scm.h"
 
+struct qcom_scm {
+   struct clk *core_clk;
+   struct clk *iface_clk;
+   struct clk *bus_clk;
+};
+
+static struct qcom_scm *__scm;
+
+static int qcom_scm_clk_enable(void)
+{
+   int ret;
+
+   ret = clk_prepare_enable(__scm->core_clk);
+   if (ret)
+   goto bail;
+   ret = clk_prepare_enable(__scm->iface_clk);
+   if (ret)
+   goto disable_core;
+   ret = clk_prepare_enable(__scm->bus_clk);
+   if (ret)
+   goto disable_iface;
+
+   return 0;
+
+disable_iface:
+   clk_disable_unprepare(__scm->iface_clk);
+disable_core:
+   clk_disable_unprepare(__scm->core_clk);
+bail:
+   return ret;
+}
+
+static void qcom_scm_clk_disable(void)
+{
+   clk_disable_unprepare(__scm->core_clk);
+   clk_disable_unprepare(__scm->iface_clk);
+   clk_disable_unprepare(__scm->bus_clk);
+}
+
 /**
  * qcom_scm_set_cold_boot_addr() - Set the cold boot address for cpus
  * @entry: Entry point function for the cpus
@@ -72,11 +110,17 @@ EXPORT_SYMBOL(qcom_scm_cpu_power_down);
  */
 bool qcom_scm_hdcp_available(void)
 {
-   int ret;
+   int ret = qcom_scm_clk_enable();
+
+   if (ret)
+   goto clk_err;
 
ret = __qcom_scm_is_call_available(QCOM_SCM_SVC_HDCP,
-   QCOM_SCM_CMD_HDCP);
+   QCOM_SCM_CMD_HDCP);
 
+   qcom_scm_clk_disable();
+
+clk_err:
return (ret > 0) ? true : false;
 }
 EXPORT_SYMBOL(qcom_scm_hdcp_available);
@@ -91,6 +135,81 @@ EXPORT_SYMBOL(qcom_scm_hdcp_available);
  */
 int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt, u32 *resp)
 {
-   return __qcom_scm_hdcp_req(req, req_cnt, resp);
+   int ret = qcom_scm_clk_enable();
+
+   if (ret)
+   return ret;
+
+   ret = __qcom_scm_hdcp_req(req, req_cnt, resp);
+   qcom_scm_clk_disable();
+   return ret;
 }
 EXPORT_SYMBOL(qcom_scm_hdcp_req);
+
+/**
+ * qcom_scm_is_available() - Checks if SCM is available
+ */
+bool qcom_scm_is_available(void)
+{
+   return !!__scm;
+}
+EXPORT_SYMBOL(qcom_scm_is_available);
+
+static int qcom_scm_probe(struct platform_device *pdev)
+{
+   struct qcom_scm *scm;
+   long rate;
+   int ret;
+
+   scm = devm_kzalloc(>dev, sizeof(*scm), GFP_KERNEL);
+   if (!scm)
+   return -ENOMEM;
+
+   scm->core_clk = devm_clk_get(>dev, "core");
+   if (IS_ERR(scm->core_clk)) {
+   if (PTR_ERR(scm->core_clk) != -EPROBE_DEFER)
+   dev_err(>dev, "failed to acquire core clk\n");
+   return PTR_ERR(scm->core_clk);
+   }
+
+   scm->iface_clk = devm_clk_get(>dev, "iface");

Re: [PATCH v3 0/3] ARM: uniphier: add outer cache support and rework SMP operations

[Arnd Bergmann]

On Friday 18 September 2015 13:37:31 Masahiro Yamada wrote:
> Hi Olof,
> 
> Now Linux 4.3-rc1 is out, so I am back to this.
> 
> 1/3: add outer cache support
> 2/3: rework SMP operations
> 3/3: add device tree nodes
> 
> Because 2/3 highly depends on 1/3, I hope whole of this series
> is applied through ARM-SOC tree.

Sorry for the long delay here. Is this the latest version of these
patches?

Did Russell King review the first patch?
Is he ok with merging this through arm-soc?

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 v9 3/5] phy: add usb3.0 phy driver for mt65xx SoCs

[Kishon Vijay Abraham I]

Hi Chunfeng,

On Tuesday 29 September 2015 08:31 AM, Chunfeng Yun wrote:
> support usb3.0 phy of mt65xx SoCs

I have merged this driver. Can you also send a patch adding yourself as
the maintainer of this driver?

Thanks
Kishon
> 
> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/phy/Kconfig   |   9 +
>  drivers/phy/Makefile  |   1 +
>  drivers/phy/phy-mt65xx-usb3.c | 506 
> ++
>  3 files changed, 516 insertions(+)
>  create mode 100644 drivers/phy/phy-mt65xx-usb3.c
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 47da573..ec436c1 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -206,6 +206,15 @@ config PHY_HIX5HD2_SATA
>   help
> Support for SATA PHY on Hisilicon hix5hd2 Soc.
>  
> +config PHY_MT65XX_USB3
> + tristate "Mediatek USB3.0 PHY Driver"
> + depends on ARCH_MEDIATEK && OF
> + select GENERIC_PHY
> + help
> +   Say 'Y' here to add support for Mediatek USB3.0 PHY driver
> +   for mt65xx SoCs. it supports two usb2.0 ports and
> +   one usb3.0 port.
> +
>  config PHY_SUN4I_USB
>   tristate "Allwinner sunxi SoC USB PHY driver"
>   depends on ARCH_SUNXI && HAS_IOMEM && OF
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a5b18c1..a7cc629 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_TI_PIPE3)  += 
> phy-ti-pipe3.o
>  obj-$(CONFIG_TWL4030_USB)+= phy-twl4030-usb.o
>  obj-$(CONFIG_PHY_EXYNOS5250_SATA)+= phy-exynos5250-sata.o
>  obj-$(CONFIG_PHY_HIX5HD2_SATA)   += phy-hix5hd2-sata.o
> +obj-$(CONFIG_PHY_MT65XX_USB3)+= phy-mt65xx-usb3.o
>  obj-$(CONFIG_PHY_SUN4I_USB)  += phy-sun4i-usb.o
>  obj-$(CONFIG_PHY_SUN9I_USB)  += phy-sun9i-usb.o
>  obj-$(CONFIG_PHY_SAMSUNG_USB2)   += phy-exynos-usb2.o
> diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
> new file mode 100644
> index 000..f30b28b
> --- /dev/null
> +++ b/drivers/phy/phy-mt65xx-usb3.c
> @@ -0,0 +1,506 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + * Author: Chunfeng Yun 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * for sifslv2 register, but exclude port's;
> + * relative to USB3_SIF2_BASE base address
> + */
> +#define SSUSB_SIFSLV_SPLLC   0x
> +
> +/* offsets of sub-segment in each port registers */
> +#define SSUSB_SIFSLV_U2PHY_COM_BASE  0x
> +#define SSUSB_SIFSLV_U3PHYD_BASE 0x0100
> +#define SSUSB_USB30_PHYA_SIV_B_BASE  0x0300
> +#define SSUSB_SIFSLV_U3PHYA_DA_BASE  0x0400
> +
> +#define U3P_USBPHYACR0   (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x)
> +#define PA0_RG_U2PLL_FORCE_ONBIT(15)
> +
> +#define U3P_USBPHYACR2   (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0008)
> +#define PA2_RG_SIF_U2PLL_FORCE_ENBIT(18)
> +
> +#define U3P_USBPHYACR5   (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014)
> +#define PA5_RG_U2_HSTX_SRCTRLGENMASK(14, 12)
> +#define PA5_RG_U2_HSTX_SRCTRL_VAL(x) ((0x7 & (x)) << 12)
> +#define PA5_RG_U2_HS_100U_U3_EN  BIT(11)
> +
> +#define U3P_USBPHYACR6   (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018)
> +#define PA6_RG_U2_ISO_EN BIT(31)
> +#define PA6_RG_U2_BC11_SW_EN BIT(23)
> +#define PA6_RG_U2_OTG_VBUSCMP_EN BIT(20)
> +
> +#define U3P_U2PHYACR4(SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020)
> +#define P2C_RG_USB20_GPIO_CTLBIT(9)
> +#define P2C_USB20_GPIO_MODE  BIT(8)
> +#define P2C_U2_GPIO_CTR_MSK  (P2C_RG_USB20_GPIO_CTL | P2C_USB20_GPIO_MODE)
> +
> +#define U3D_U2PHYDCR0(SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0060)
> +#define P2C_RG_SIF_U2PLL_FORCE_ONBIT(24)
> +
> +#define U3P_U2PHYDTM0(SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0068)
> +#define P2C_FORCE_UART_ENBIT(26)
> +#define P2C_FORCE_DATAIN BIT(23)
> +#define P2C_FORCE_DM_PULLDOWNBIT(21)
> +#define P2C_FORCE_DP_PULLDOWNBIT(20)
> +#define P2C_FORCE_XCVRSELBIT(19)
> +#define P2C_FORCE_SUSPENDM   BIT(18)
> +#define P2C_FORCE_TERMSELBIT(17)
> +#define P2C_RG_DATAINGENMASK(13, 10)
> +#define P2C_RG_DATAIN_VAL(x) ((0xf & (x)) << 10)
> +#define P2C_RG_DMPULLDOWN   

Re: [PATCH v5 2/3] PCI: st: Add Device Tree bindings for sti pcie

[Rob Herring]

On Tue, Oct 6, 2015 at 2:56 AM, Gabriel Fernandez
 wrote:
> sti pcie is built around a Synopsis Designware PCIe IP.
>
> Signed-off-by: Fabrice Gasnier 
> Signed-off-by: Gabriel Fernandez 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/pci/st-pcie.txt | 56 
> +++
>  1 file changed, 56 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/st-pcie.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/st-pcie.txt 
> b/Documentation/devicetree/bindings/pci/st-pcie.txt
> new file mode 100644
> index 000..32e76d0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/st-pcie.txt
> @@ -0,0 +1,56 @@
> +STMicroelectronics STi PCIe controller
> +
> +This PCIe host controller is based on the Synopsis Designware PCIe IP
> +and thus inherits all the common properties defined in designware-pcie.txt.
> +
> +Required properties:
> + - compatible: Should be "st,pcie", "snps,dw-pcie"
> +
> + - reg: base address and length of the pcie controller, mem-window address
> +   and length available to the controller.
> +
> + - interrupts: one GIC interrupt line connected to PCI MSI interrupt line
> +
> + - st,syscfg : should be a phandle of the syscfg node. Also contains syscfg
> +   offset for IP configuration.
> +
> + - resets: phandle to the powerdown and reset controller for the PCIe IP.
> +   See ../reset/reset.txt for details.
> + - reset-names: should be "powerdown" and "softreset".
> +
> + - phys: the phandle for the PHY device (used by generic PHY framework).
> + - phys-names: must be "pcie".
> +
> +Optional properties:
> + - reset-gpio: a GPIO spec to define which pin is connected to the bus reset.
> +
> +Example:
> +
> +pcie0: pcie@9b0 {
> +   compatible = "st,pcie", "snps,dw-pcie";
> +   device_type = "pci";
> +   reg = <0x09b0 0x4000>,  /* dbi cntrl registers */
> + <0x2fff 0x0001>,  /* configuration space */
> + <0x4000 0x8000>;  /* lmi mem window */
> +   reg-names = "dbi", "config", "mem-window";
> +   st,syscfg = <_core 0xd8 0xe0>;
> +   #address-cells = <3>;
> +   #size-cells = <2>;
> +   ranges = <0x8200 0 0x2000 0x2000 0 0x0FFF>; /* 
> non-prefetchable memory */
> +   num-lanes = <1>;
> +   interrupts = ;
> +   interrupt-names = "msi";
> +   #interrupt-cells = <1>;
> +   interrupt-map-mask = <0 0 0 7>;
> +   interrupt-map = <0 0 0 1  GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>, /* 
> INT A */
> +   <0 0 0 2  GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>, /* 
> INT B */
> +   <0 0 0 3  GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>, /* 
> INT C */
> +   <0 0 0 4  GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>; /* 
> INT D */
> +
> +   resets = < STIH407_PCIE0_POWERDOWN>,
> +< STIH407_PCIE0_SOFTRESET>;
> +   reset-names = "powerdown",
> + "softreset";
> +   phys = <_port0 PHY_TYPE_PCIE>;
> +   phy-names = "pcie";
> +};
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Bharat Kumar Gogada]

Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.

Signed-off-by: Bharat Kumar Gogada 
Signed-off-by: Ravi Kiran Gummaluri 
---
Added interrupt-map, interrupt-map-mask properties
---
 .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   56 ++
 drivers/pci/host/Kconfig   |9 +
 drivers/pci/host/Makefile  |1 +
 drivers/pci/host/pcie-xilinx-nwl.c | 1029 
 4 files changed, 1095 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
 create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c

diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt 
b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
new file mode 100644
index 000..81006ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
@@ -0,0 +1,56 @@
+* Xilinx NWL PCIe Root Port Bridge DT description
+
+Required properties:
+- compatible: Should contain "xlnx,nwl-pcie-2.11"
+- #address-cells: Address representation for root ports, set to <3>
+- #size-cells: Size representation for root ports, set to <2>
+- #interrupt-cells: specifies the number of cells needed to encode an
+   interrupt source. The value must be 1.
+- reg: Should contain Bridge, PCIe Controller registers location,
+   configuration sapce, and length
+- reg-names: Must include the following entries:
+   "breg": bridge registers
+   "pcireg": PCIe controller registers
+   "cfg": configuration space region
+- device_type: must be "pci"
+- interrupts: Should contain NWL PCIe interrupt
+- interrupt-names: Must include the following entries:
+   "misc": interrupt asserted when miscellaneous is recieved
+   "intx": interrupt that is asserted when an legacy interrupt is received
+   "msi_1, msi_0": interrupt asserted when msi is recieved
+- interrupt-map-mask and interrupt-map: standard PCI properties to define the
+   mapping of the PCI interface to interrupt numbers.
+- ranges: ranges for the PCI memory regions (I/O space region is not
+   supported by hardware)
+   Please refer to the standard PCI bus binding document for a more
+   detailed explanation
+
+Optional properties:
+- xlnx,msi-fifo: To enable MSI FIFO mode
+   - This feature can be used to queue multiple MSI interrupts
+
+Example:
+
+nwl_pcie: pcie@fd0e {
+   compatible = "xlnx,nwl-pcie-2.11";
+   #address-cells = <3>;
+   #size-cells = <2>;
+   #interrupt-cells = <1>;
+   device_type = "pci";
+   interrupt-parent = <>;
+   interrupts = < 0 118 4
+  0 116 4
+  0 115 4  // MSI_1 [63...32]
+  0 114 4 >;   // MSI_0 [31...0]
+   interrupt-names = "misc", "intx", "msi_1", "msi_0";
+   interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+   interrupt-map = <0x0 0x0 0x0 0x1  0x0 116 0x4
+   0x0 0x0 0x0 0x2  0x0 116 0x4
+   0x0 0x0 0x0 0x3  0x0 116 0x4
+   0x0 0x0 0x0 0x4  0x0 116 0x4>;
+   reg = <0x0 0xfd0e 0x1000
+  0x0 0xfd48 0x1000
+  0x0 0xE000 0x100>;
+   reg-names = "breg", "pcireg", "cfg";
+   ranges = <0x0200 0x 0xE100 0x 0xE100 0 
0x0F00>;
+};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index c132bdd..7f5f35e 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -15,6 +15,15 @@ config PCI_MVEBU
depends on ARCH_MVEBU || ARCH_DOVE
depends on OF

+config PCIE_XILINX_NWL
+   bool "NWL PCIe Core && PCI_MSI"
+   depends on ARCH_ZYNQMP
+   help
+Say 'Y' here if you want kernel to support for Xilinx
+NWL PCIe controller.The controller can act as Root Port
+or End Point.The current option selection will only
+support root port enabling.
+
 config PCIE_DW
bool

diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..6a56df7 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
 obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
 obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
 obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
+obj-$(CONFIG_PCIE_XILINX_NWL) += pcie-xilinx-nwl.o
 obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
 obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
 obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
diff --git a/drivers/pci/host/pcie-xilinx-nwl.c 
b/drivers/pci/host/pcie-xilinx-nwl.c
new file mode 100644
index 000..ff25ec1
--- /dev/null
+++ b/drivers/pci/host/pcie-xilinx-nwl.c
@@ -0,0 +1,1029 @@
+/*
+ * PCIe host controller driver for NWL PCIe Bridge
+ * Based on pci-xilinx.c, pci-tegra.c
+ *
+ * (C) Copyright 2014 - 2015, Xilinx, Inc.
+ *
+ * This program 

Re: [GIT PULL]Hisilicon arm64 dt changes for 4.3

[Arnd Bergmann]

On Monday 21 September 2015 17:36:35 Wei Xu wrote:
> ARM64: DT: Hisilicon hip05 soc and D02 board updates for 4.3
> 
> - Updated the hisilicon devicetree bindings document to support hip05-D02 
> board
> - Added dts files for hip05 SoC and D02 board
> 

Sorry for the long delay on our side, I've now merged these
into the next/dt branch. Thanks for waiting,

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] pwm: pwm-rcar: Revise the device tree binding document about compatible

[Rob Herring]

On Tue, Oct 6, 2015 at 6:28 AM, Yoshihiro Shimoda
 wrote:
> The compatible should be "renesas,pwm-rcar", and one the the SoC
> specific string. So, this patch revises the documentation.
>
> Reported-by: Rob Herring 
> Signed-off-by: Yoshihiro Shimoda 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt 
> b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt
> index ea0a27b..0822a08 100644
> --- a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt
> +++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt
> @@ -1,8 +1,7 @@
>  * Renesas R-Car PWM Timer Controller
>
>  Required Properties:
> -- compatible: should be one of the following.
> - - "renesas,pwm-rcar": for generic R-Car compatible PWM Timer
> +- compatible: should be "renesas,pwm-rcar" and one of the following.
>   - "renesas,pwm-r8a7778": for R-Car M1A
>   - "renesas,pwm-r8a7779": for R-Car H1
>   - "renesas,pwm-r8a7790": for R-Car H2
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/3] ARM: uniphier: add outer cache support and rework SMP operations

[Arnd Bergmann]

On Tuesday 06 October 2015 16:20:23 Arnd Bergmann wrote:
> On Friday 18 September 2015 13:37:31 Masahiro Yamada wrote:
> > Hi Olof,
> > 
> > Now Linux 4.3-rc1 is out, so I am back to this.
> > 
> > 1/3: add outer cache support
> > 2/3: rework SMP operations
> > 3/3: add device tree nodes
> > 
> > Because 2/3 highly depends on 1/3, I hope whole of this series
> > is applied through ARM-SOC tree.
> 
> Sorry for the long delay here. Is this the latest version of these
> patches?
> 
> Did Russell King review the first patch?
> Is he ok with merging this through arm-soc?
> 

I found an answer to the first question, as I see you posted
v5 of the patchset in the meantime.

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 PATCH v6 2/3] dtc: dts source location annotation

[David Gibson]

On Tue, Oct 06, 2015 at 12:45:34AM -0700, Frank Rowand wrote:
> On 10/5/2015 9:56 PM, David Gibson wrote:
> > On Fri, Oct 02, 2015 at 09:52:48PM -0700, Frank Rowand wrote:
> >> From: Frank Rowand 
> >>
> >> Proof of concept patch.
> >>
> >> Annotates input source file and line number of nodes and properties
> >> as comments in output .dts file when --annotate flag is supplied.
> 
> < snip >
> 
> 
> >> Index: b/srcpos.c
> >> ===
> >> --- a/srcpos.c
> >> +++ b/srcpos.c
> >> @@ -246,6 +246,41 @@ srcpos_copy(struct srcpos *pos)
> >>return pos_new;
> >>  }
> >>  
> >> +struct srcpos *
> >> +srcpos_copy_all(struct srcpos *pos)
> >> +{
> >> +  struct srcpos *pos_new;
> >> +  struct srcfile_state *srcfile_state;
> >> +
> >> +  if (!pos)
> >> +  return NULL;
> >> +
> >> +  pos_new = srcpos_copy(pos);
> >> +
> >> +  if (pos_new) {
> >> +  /* allocate without free */
> >> +  srcfile_state = xmalloc(sizeof(struct srcfile_state));
> >> +  memcpy(srcfile_state, pos->file, sizeof(struct srcfile_state));
> >> +
> >> +  pos_new->file = srcfile_state;
> >> +  }
> >> +
> >> +  return pos_new;
> >> +}
> > 
> > You still don't need this function.  srcfile_states have unlimited
> > lifetime.
> 
> My observation about this is buried in a late reply to v5, so
> copying here:
> 
>If I don't allocate a new copy of pos->file, then the file names are
>incorrect.  I'm not sure why.  I can dig into this deeper to try to
>understand what is going on if you want me to.
> 
> It sounds like I do need to debug this.

That's weird.  Yeah, we need to debug this.

Btw, I was thinking about the filenames - in particular the way the
current draft will give you very unwield full paths.  I was thinking
about a different approach which should shorten those without
requiring different invocation or hand hacking:
   * For the "base" dts file (the one passed on the command line),
 always use just the basename (i.e. final piece of the file path)
   * For all other files, print the relative path from the directory
 of the base file

/include/ directives already open files relative to the directory of
the file including the /include/ so we have some of the mechanisms for
this already.

I think this will require a moderate amount of extra work, so I
wouldn't suggest it for the first cut, but does it sound like a good
approach in principle to you?

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [RFC PATCH v6 2/3] dtc: dts source location annotation

[David Gibson]

On Tue, Oct 06, 2015 at 12:38:19AM -0700, Frank Rowand wrote:
> On 10/5/2015 9:56 PM, David Gibson wrote:
> > On Fri, Oct 02, 2015 at 09:52:48PM -0700, Frank Rowand wrote:
> >> From: Frank Rowand 
> >>
> >> Proof of concept patch.
> >>
> >> Annotates input source file and line number of nodes and properties
> >> as comments in output .dts file when --annotate flag is supplied.
> 
> < snip >
> 
> > The two branches here aren't quite consistent - the first doesn't
> > include the '/', the second does.  You could either change the second
> > to just &@3, or use &@$ for the first.
> 
> < snip >
> 
> > This one doesn't include the name/label again
> 
> < snip>
> 
> > 
> > .. and this one does.
> > 
> > Looking at all of these it's probably going to be simplest not to
> > include the label/name (i.e. just use the srcpos from the nodedef).
> 
> This also shows how much I need to create a better "make check" test
> suite to exercise all of the relevant paths (as is on my todo list).
> 
> I've been trying to capture the line that the name is on, since it
> might be different than the line that the "{" is on, but maybe I'm
> just trying too hard and should accept the simpler solution.  The
> result will be obvious to the person using the output.

Hm, yes I see your point, it probably is slightly better to include
the name.  I'm fine with that, as long as it's done consistently.

> I'll fix this all up after I get back from the conference.
> 
> Thanks for checking the patch over at that level of detail!
> 
> -frank

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

RE: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND controller

[Anup Patel]

> -Original Message-
> From: Florian Fainelli [mailto:f.faine...@gmail.com]
> Sent: 07 October 2015 04:51
> To: Scott Branden; Brian Norris; Anup Patel
> Cc: linux-arm-ker...@lists.infradead.org; Rob Herring; Pawel Moll; Mark
> Rutland; Ian Campbell; Kumar Gala; Catalin Marinas; Will Deacon; David
> Woodhouse; Ray Jui; Florian Fainelli; Pramod Kumar; Vikram Prakash; Sandeep
> Tripathy; devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; linux-
> m...@lists.infradead.org; bcm-kernel-feedback-list; Rafal Milecki
> Subject: Re: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND
> controller
> 
> On 06/10/15 15:25, Scott Branden wrote:
> > Hi Brian,
> >
> > On 15-10-06 06:41 AM, Brian Norris wrote:
> >
> 
>  Is there a reason not to do this reset unconditionally? I recall
>  this came up in discussion previously, when the OpenWRT folks were
>  trying to integrate with BCMA, where this reset was one of the few
>  differences between the
>  platform-
>  device-based driver (i.e., this one) and the BCMA based driver.
>  Might it help
>  simplify things a bit if we just did the same thing everywhere?
> >>>
> >>> This driver is currently shared by Cygnus and NS2.
> >>>
> >>> We had similar suggestion when this patch was reviewed internally in
> >>> Broadcom.
> >>>
> >>> The rationale for adding optional DT flag is as follows:
> >>> 1. The NAND controller reset is currently required for NS2 only so
> >>> that it is in sane state before any NAND commands are issued. We are
> >>> not sure if Cygnus and all future iProc SoCs will require NAND
> >>> controller reset.
> >>
> >> I'm not sure this is a very strong reason. It seems fairly reasonable
> >> in general to reset a HW block before using it.
> >
> > Efficient Boot time is a very strong reason for needing this actually.
> > We use the NAND controller in the bootROM, boot1/BL1, u-boot/UEFI, and
> > then Kernel stage.  By properly initializing the controller once we do
> > not need to reset it 4 different times.
> 
> This could be used as a reverse argument, issuing a reset will increase the 
> boot
> time.
> 
> >
> >>
> >>> 2. The NAND controller reset in probe would certainly increase Linux
> >>> boot time so for certain iProc SoCs we might choose avoid NAND
> >>> controller reset to reduce boot time if possible.
> >>
> >> I recall this reason being mentioned before. I believe this only
> >> happens because the brcmnand driver doesn't yet handle configuring
> >> the timing registers, so iProc is implicitly relying on the
> >> bootloader to configure the NAND timings. Perhaps it's time that we
> >> fix that. I'd rather not add extra DT properties unless we actually
> >> need to [1]. And having proper timing configuration in the Linux
> >> driver will help improve speeds for all users (whose timings may not be
> configured in the bootloader).
> >
> > This is the very reason we need the optional reset property.  We need
> > to have timings configured by the linux driver or not.  Yes, in some
> > cases we will be relying on earlier boot stages to configure some of
> > the hardware.
> 
> Then instead of adding a "reset flag" to Device Tree, another approach could 
> be
> to put the desired or currently configured exhaustive list of NAND timings in
> Device Tree, and based on that you could have this:
> 
> - the NAND controller driver finds that these timings match the current
> configuration, you are good to go
> 
> - the NAND controller drivers finds a difference in how current timings are
> configured vs. desired timings, and issues a controller reset, prior to 
> applying
> new timing configuration

To add to this ...

The mechanism to reset is BRCM NAND controller is SOC specific so the
SoC independent BRCM NAND driver (i.e. brcmnand.c) does not know how
to reset the NAND controller.

For iProc SoC family, the NAND controller reset is through IDM register
space which is only iomap'ed by iproc_nand.c.

We might end-up having one more SoC specific callback which will be
Provided by iproc_nand.c to brcmnand.c.

> 
> - no timings are configured, reset the controller and use existing 
> auto-detection
> capabilities like ONFI modes
> 
> Typically you would put the desired timings instead of the currently 
> configured
> timings though..

Overall, it would good to support timing parameters through DT or ONFI but
for now have we can rely on reset and auto-devid configuration.

> 
> >
> >>
> >> I actually had some preliminary work to do some timing configuration
> >> according to the new timing information from nand_base.c/nand_timing.c.
> >> Unfortunately, I didn't complete this, and I'm no longer working at
> >> Broadcom, so I don't exactly have access to the HW docs for all the
> >> NAND controller revisions, nor do I have access to as much HW for 
> >> testing...
> >>
> >> Brian
> >>
> >> [1] If we really do need a device tree differentiation, perhaps it
> >> would be better to just differentiate the 

Re: [PATCH] ARM: shmobile: porter: add SDHI0/2 DT support

[Simon Horman]

On Wed, Oct 07, 2015 at 02:05:41AM +0300, Sergei Shtylyov wrote:
> Define the Porter board dependent part of the SDHI0/2 device nodes along with
> the  necessary  voltage regulators (note that the Vcc regulators are dummy --
> they are required but don't actually exist on the board). Also, GPIOs have to
> be used for the CD and WP signals due to the SDHI driver constraints...
> 
> This patch is analogous to the commit 1299df03d719 (ARM: shmobile: henninger:
> add SDHI0/2 DT support) as there  are no differences between those boards in
> this respect.
> 
> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
> 
> ---
> This patch is against the 'renesas-devel-20151006-v4.3-rc4' tag of Simon
> Horman's 'renesas.git' repo.

Thanks I have queued this up after addressing some issues
in the changelog that checkpatch complained about:

* text > 75 characters wide
* Missing '"' around name of patch referred to

Its looking like there is already quite a log shared between
r8a7791-porter.dts and r8a7791-henninger.dts. Do you have any
thoughts on consolidating or sharing common elements between
them somehow?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 15/18] powerpc/book3e-64/kexec: Enable SMP release

[Scott Wood]

The SMP release mechanism for FSL book3e is different from when booting
with normal hardware.  In theory we could simulate the normal spin
table mechanism, but not at the addresses U-Boot put in the device tree
-- so there'd need to be even more communication between the kernel and
kexec to set that up.  Instead, kexec-tools will set a boolean property
linux,booted-from-kexec in the /chosen node.

Signed-off-by: Scott Wood 
Cc: devicetree@vger.kernel.org
---
v2: Use a device tree property instead of a flag in the kernel image

This depends on the kexec-tools patch v2 "ppc64: Add a flag to tell the
kernel it's booting from kexec":
http://patchwork.ozlabs.org/patch/527050/
---
 Documentation/devicetree/bindings/chosen.txt |  8 
 arch/powerpc/kernel/setup_64.c   | 17 -
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/chosen.txt 
b/Documentation/devicetree/bindings/chosen.txt
index ed838f4..6ae9d82 100644
--- a/Documentation/devicetree/bindings/chosen.txt
+++ b/Documentation/devicetree/bindings/chosen.txt
@@ -44,3 +44,11 @@ Implementation note: Linux will look for the property 
"linux,stdout-path" or
 on PowerPC "stdout" if "stdout-path" is not found.  However, the
 "linux,stdout-path" and "stdout" properties are deprecated. New platforms
 should only use the "stdout-path" property.
+
+linux,booted-from-kexec
+---
+
+This property is set (currently only on PowerPC, and only needed on
+book3e) by some versions of kexec-tools to tell the new kernel that it
+is being booted by kexec, as the booting environment may differ (e.g.
+a different secondary CPU release mechanism)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 505ec2c..5c03a6a 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -340,11 +340,26 @@ void early_setup_secondary(void)
 #endif /* CONFIG_SMP */
 
 #if defined(CONFIG_SMP) || defined(CONFIG_KEXEC)
+static bool use_spinloop(void)
+{
+   if (!IS_ENABLED(CONFIG_PPC_BOOK3E))
+   return true;
+
+   /*
+* When book3e boots from kexec, the ePAPR spin table does
+* not get used.
+*/
+   return of_property_read_bool(of_chosen, "linux,booted-from-kexec");
+}
+
 void smp_release_cpus(void)
 {
unsigned long *ptr;
int i;
 
+   if (!use_spinloop())
+   return;
+
DBG(" -> smp_release_cpus()\n");
 
/* All secondary cpus are spinning on a common spinloop, release them
@@ -524,7 +539,7 @@ void __init setup_system(void)
 * Freescale Book3e parts spin in a loop provided by firmware,
 * so smp_release_cpus() does nothing for them
 */
-#if defined(CONFIG_SMP) && !defined(CONFIG_PPC_FSL_BOOK3E)
+#if defined(CONFIG_SMP)
/* Release secondary cpus out of their spinloops at 0x60 now that
 * we can map physical -> logical CPU ids
 */
-- 
2.1.4

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

Re: [PATCH 0/3] ARM: dts: sun4i: USB DRC and voltage-scaling for pcDuino1/2

[Siarhei Siamashka]

On Mon, 5 Oct 2015 14:38:48 +0200
Maxime Ripard  wrote:

> Hi,
> 
> On Sun, Oct 04, 2015 at 09:58:45PM +0300, Siarhei Siamashka wrote:
> > Hello,
> > 
> > This brings LinkSprite pcDuino1/2 boards up to date with the latest
> > kernel features. And the first patch in this set is a bugfix for the
> > PH3/PH6 pins misuse.
> > 
> > There is currently a single dts file for pcDuino1 and pcDuino2 boards.
> > They obviously had been designed to be compatible with each other, but
> > have some minor differences, as can be seen when comparing schematics:
> > https://s3.amazonaws.com/pcduino/Hardware/PC+Duino_V01-20130128.pdf
> > https://s3.amazonaws.com/pcduino/Hardware/v2/pcDuino_v2_sch.pdf
> 
> Usually, the way we handle this is simply by including just the other
> DT that will only hold those differences.
> 
> What are those differences exactly ?

For the exact differences, one might look into the pdf schematics
files (that's why I have provided links). But a short summary is
the following:

* pcDuino1 has two USB host receptacles, but pcDuino2 has one USB host
  receptacle and a USB WIFI chip.
* There is this difference with the USB_EN pin (PD2), which controls
  a USB power switch in pcDuino2. There is no USB power switch in
  pcDuino1 and the PD2 pin is apparently only connected to a test
  point on the PCB.
* The SZQ resistor is different, which might mean different DDR3
  tracks routing.
* The Ethernet transceiver is different (RTL8201CP in pcDuino1 and
  IP101A_LF in pcDuino2).
* An extra LED is connected to the WIFI chip, but can't be accessed
  in any other way.

Other than the PD2 pin, nothing else seems to be really relevant
to the dts file. And even the PD2 pin is pulled-up in pcDuino2,
making the USB host port powered by default just like in pcDuino1.

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

Re: [linux-sunxi] [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

[Siarhei Siamashka]

On Mon, 5 Oct 2015 14:49:49 +0200
Maxime Ripard  wrote:

> On Mon, Oct 05, 2015 at 08:39:40AM +0300, Siarhei Siamashka wrote:
> > On Mon, 5 Oct 2015 09:55:28 +0800
> > Chen-Yu Tsai  wrote:
> > 
> > > On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
> > >  wrote:
> > > > The pcDuino1 board does not use any power switches at all for its
> > > > two USB host ports and the VBUS pins are always connected to 5V.
> > > >
> > > > The pcDuino2 board uses the RT9701GB power switch for its single
> > > > USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> > > > resistor. So that the USB power is still enabled by default even
> > > > if nobody bothers to configure the PD2 pin or runs the pcDuino1
> > > > firmware.
> > > 
> > > Seems like it would be better if you had a regulator controlled
> > > by PD2. At least can shut down VBUS power when it wants to?
> > 
> > That's a good question.
> > 
> > Describing the regulator controlled by PD2 in the dts file is surely
> > the right solution for pcDuino2 boards. But in the case of using this
> > dts for pcDuino1, the kernel would think that it can shut down VBUS
> > power, while in fact this is not true.
> 
> I do agree that this is the right solution for the pcduino1, but it's
> definitely not the right one for the pcduino 2 then.
> 
> Declaring this as a regulator isn't just meant for the USB to be
> working, it's also meant so that it keeps working. If the pin is not
> claimed by anyone, the userspace and / or some other driver, will
> actually be able to grab that pin and do whatever it wants with it,
> effectively fiddling with the VBUS supply behind the USB driver's
> back.

OK. That's a very good point.

> It also allows to disable the regulator if VBUS isn't going to be
> used, for example because the driver has not be compiled in, or that
> it's actually a module that might (or might not) be loaded later.
> 
> Finally, it also allows to keep track of who consumes what amount of
> power in the system, which is a nice plus.
>
> > The RT9701GB switch also provides the current limiting feature in
> > addition to the ability to enable/disable the VBUS power. Probably
> > this was a real reason why it was added to the board.
> > 
> > Everything boils down to the question whether we want to have a
> > common dts file for pcDuino1 and pcDuino2 or decide to split them.
> 
> You don't have to split them, if this is really the only difference,
> just create a new dts for the pcduino2 that includes the first one,
> and add the supply there.

Well, we get two dts files instead of one as the end result. If "split"
is not a good description, then I should have probably used a different
word for it.

I don't mind having separate dts files for pcDuino1 and pcDuino2.
What are we going to do with testing on pcDuino1? I only have
pcDuino2 hardware myself.

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

Re: [PATCH v5 1/3] ARM: STi: Kconfig update for PCIe support

[Russell King - ARM Linux]

On Tue, Oct 06, 2015 at 09:56:06AM +0200, Gabriel Fernandez wrote:
> Update Kconfig:
> - MIGHT_HAVE_PCI
> - PCI_DOMAINS
> 
> Signed-off-by: Fabrice Gasnier 
> ---
>  arch/arm/mach-sti/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
> index 125865d..5f99e93 100644
> --- a/arch/arm/mach-sti/Kconfig
> +++ b/arch/arm/mach-sti/Kconfig
> @@ -9,6 +9,8 @@ menuconfig ARCH_STI
>   select ARCH_HAS_RESET_CONTROLLER
>   select HAVE_ARM_SCU if SMP
>   select ARCH_REQUIRE_GPIOLIB
> + select PCI_DOMAINS if PCI
> + select MIGHT_HAVE_PCI
>   select ARM_ERRATA_754322
>   select ARM_ERRATA_764369 if SMP
>   select ARM_ERRATA_775420

Please, alphabetical ordering for select statements.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V9] dt: add NVIDIA Tegra XUSB controller binding

[Stephen Warren]

From: Stephen Warren 

Add device-tree binding documentation for the XUSB (xHCI) controller
present on Tegra124 and later SoCs.

Signed-off-by: Andrew Bresticker 
[swarren, combined separate MFD, mailbox, XHCI bindings into one node]
Signed-off-by: Stephen Warren 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Mathias Nyman 
Cc: Greg Kroah-Hartman 
---
Changes from v8:
 - Combined the separate MFD, mailbox, and XHCI bindings into one; there
   is a single HW module, and so there should be a single DT node to
   represent it. Any Linux-internal driver structure should not influence
   the binding structure. This included squashing the various reg and
   interrupt resources that were previously in the separate modules into
   one list.
 - Used lists to document the compatible, reg, and interrupts properties.
 - Renamed the primary binding from xhci to xusb to reflect the name of
   the overall module.
Changes from v7:
 - Added back non-shared reg/interrupts properties.
Changes from v6:
 - Removed XUSB_DEV related clocks/resets.  They will be consumed by
   a separate driver and binding.
 - Removed reg/interrupts properties.
No changes from v5.
Changes from v4:
 - Updated regulator names, as suggested by Thierry.
No changes from v3.
Changes from v2:
 - Added mbox-names property.
Changes from v1:
 - Updated to use common mailbox bindings.
 - Added remaining XUSB-related clocks and resets.
 - Updated list of power supplies to be more accurate wrt to the hardware.
---
 .../bindings/usb/nvidia,tegra124-xusb.txt  | 96 ++
 1 file changed, 96 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt

diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt 
b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt
new file mode 100644
index ..f8de8d49602e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra124-xusb.txt
@@ -0,0 +1,96 @@
+NVIDIA Tegra XUSB (XHCI) controller
+===
+
+The Tegra XUSB controller supports both USB2 and USB3 interfaces exposed
+by the Tegra XUSB pad controller.
+
+Required properties:
+
+ - compatible: Valid options are:
+- Tegra124: "nvidia,tegra124-xusb".
+- Tegra132: "nvidia,tegra132-xusb", "nvidia,tegra124-xusb".
+ - reg: Must contain the following entries, in the following order:
+- The xHCI host registers.
+- The IPFS registers.
+- The FPCI registers.
+ - interrupts: Must contain the following entries, in the following order:
+- The xHCI host interrupt
+- The XUSB mailbox interrupt.
+ - clocks: Must contain an entry for each entry in clock-names.
+   See ../clock/clock-bindings.txt for details.
+ - clock-names: Must include the following entries:
+- xusb_host
+- xusb_host_src
+- xusb_falcon_src
+- xusb_ss
+- xusb_ss_src
+- xusb_ss_div2
+- xusb_hs_src
+- xusb_fs_src
+- pll_u_480m
+- clk_m
+- pll_e
+ - resets: Must contain an entry for each entry in reset-names.
+   See ../reset/reset.txt for details.
+ - reset-names: Must include the following entries:
+   - xusb_host
+   - xusb_ss
+   - xusb_src
+   Note that xusb_src is the shared reset for xusb_{ss,hs,fs,falcon,host}_src.
+ - avddio-pex-supply: PCIe/USB3 analog logic power supply.  Must supply 1.05V.
+ - dvddio-pex-supply: PCIe/USB3 digital logic power supply.  Must supply 1.05V.
+ - avdd-usb-supply: USB controller power supply.  Must supply 3.3V.
+ - avdd-pll-utmip-supply: UTMI PLL power supply.  Must supply 1.8V.
+ - avdd-pll-erefe-supply: PLLE reference PLL power supply.  Must supply 1.05V.
+ - avdd-usb-ss-pll-supply: PCIe/USB3 PLL power supply.  Must supply 1.05V.
+ - hvdd-usb-ss-supply: High-voltage PCIe/USB3 power supply.  Must supply 3.3V.
+ - hvdd-usb-ss-pll-e-supply: High-voltage PLLE power supply.  Must supply 3.3V.
+
+Optional properties:
+
+ - phys: Must contain an entry for each entry in phy-names.
+   See ../phy/phy-bindings.txt for details.
+ - phy-names: Should include an entry for each PHY used by the controller.
+   Names must be of the form "-" where  is one of "utmi",
+   "hsic", or "usb3" and  is a 0-based index.  On Tegra124, there may
+   be up to 3 UTMI, 2 HSIC, and 2 USB3 PHYs.
+
+Example:
+
+   usb-host@0,7009 {
+   compatible = "nvidia,tegra124-xusb";
+   reg = <0x0 0x7009 0x0 0x8000>,
+ <0x0 0x70099000 0x0 0x1000>,
+ <0x0 0x70098000 0x0 0x1000>;
+   interrupts = ,
+;
+   clocks = <_car TEGRA124_CLK_XUSB_HOST>,
+<_car 

Re: [PATCH v6 3/6] power: Add support for DA9150 Fuel-Gauge

[kbuild test robot]

Hi Adam,

[auto build test WARNING on v4.3-rc4 -- if it's inappropriate base, please 
ignore]

config: s390-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390 

All warnings (new ones prefixed by >>):

   drivers/power/da9150-fg.c: In function 'da9150_fg_read_attr.isra.4':
>> drivers/power/da9150-fg.c:108:1: warning: 'da9150_fg_read_attr.isra.4' uses 
>> dynamic stack allocation
}
^

vim +108 drivers/power/da9150-fg.c

92  static u32 da9150_fg_read_attr(struct da9150_fg *fg, u8 code, u8 size)
93  
94  {
95  u8 buf[size];
96  u8 read_addr;
97  u32 res = 0;
98  int i;
99  
   100  /* Set QIF code (READ mode) */
   101  read_addr = (code & DA9150_QIF_CODE_MASK) | DA9150_QIF_READ;
   102  
   103  da9150_read_qif(fg->da9150, read_addr, size, buf);
   104  for (i = 0; i < size; ++i)
   105  res |= (buf[i] << (i * DA9150_QIF_BYTE_SIZE));
   106  
   107  return res;
 > 108  }
   109  
   110  static void da9150_fg_write_attr(struct da9150_fg *fg, u8 code, u8 size,
   111   u32 val)
   112  
   113  {
   114  u8 buf[size];
   115  u8 write_addr;
   116  int i;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH v3 1/5] dt-bindings: net: Broadcom iProc MDIO bus driver device tree binding

[Arun Parameswaran]

Add device tree binding documentation for the Broadcom iProc MDIO
bus driver.

Signed-off-by: Arun Parameswaran 
---
 .../devicetree/bindings/net/brcm,iproc-mdio.txt| 23 ++
 1 file changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt

diff --git a/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt 
b/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt
new file mode 100644
index 000..8ba9ed1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt
@@ -0,0 +1,23 @@
+* Broadcom iProc MDIO bus controller
+
+Required properties:
+- compatible: should be "brcm,iproc-mdio"
+- reg: address and length of the register set for the MDIO interface
+- #size-cells: must be 1
+- #address-cells: must be 0
+
+Child nodes of this MDIO bus controller node are standard Ethernet PHY device
+nodes as described in Documentation/devicetree/bindings/net/phy.txt
+
+Example:
+
+mdio@18002000 {
+   compatible = "brcm,iproc-mdio";
+   reg = <0x18002000 0x8>;
+   #size-cells = <1>;
+   #address-cells = <0>;
+
+   enet-gphy@0 {
+   reg = <0>;
+   };
+};
-- 
2.5.2

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

[PATCH v3 2/5] net: phy: Broadcom iProc MDIO bus driver

[Arun Parameswaran]

This patch adds support for the Broadcom iProc MDIO bus interface.
The MDIO interface can be found in the Broadcom iProc family Soc's.

The MDIO bus is accessed using a combination of command and data
registers. This MDIO driver provides access to the Etherent GPHY's
connected to the MDIO bus.

Signed-off-by: Arun Parameswaran 
---
 drivers/net/phy/Kconfig  |   9 ++
 drivers/net/phy/Makefile |   1 +
 drivers/net/phy/mdio-bcm-iproc.c | 213 +++
 3 files changed, 223 insertions(+)
 create mode 100644 drivers/net/phy/mdio-bcm-iproc.c

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index c5ad98a..b57f6c2 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -225,6 +225,15 @@ config MDIO_BCM_UNIMAC
  This hardware can be found in the Broadcom GENET Ethernet MAC
  controllers as well as some Broadcom Ethernet switches such as the
  Starfighter 2 switches.
+
+config MDIO_BCM_IPROC
+   tristate "Broadcom iProc MDIO bus controller"
+   depends on ARCH_BCM_IPROC || COMPILE_TEST
+   depends on HAS_IOMEM && OF_MDIO
+   help
+ This module provides a driver for the MDIO busses found in the
+ Broadcom iProc SoC's.
+
 endif # PHYLIB
 
 config MICREL_KS8995MA
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 87f079c..f4e6eb9 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_MDIO_SUN4I)  += mdio-sun4i.o
 obj-$(CONFIG_MDIO_MOXART)  += mdio-moxart.o
 obj-$(CONFIG_MDIO_BCM_UNIMAC)  += mdio-bcm-unimac.o
 obj-$(CONFIG_MICROCHIP_PHY)+= microchip.o
+obj-$(CONFIG_MDIO_BCM_IPROC)   += mdio-bcm-iproc.o
diff --git a/drivers/net/phy/mdio-bcm-iproc.c b/drivers/net/phy/mdio-bcm-iproc.c
new file mode 100644
index 000..c0b4e65
--- /dev/null
+++ b/drivers/net/phy/mdio-bcm-iproc.c
@@ -0,0 +1,213 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IPROC_GPHY_MDCDIV0x1a
+
+#define MII_CTRL_OFFSET  0x000
+
+#define MII_CTRL_DIV_SHIFT   0
+#define MII_CTRL_PRE_SHIFT   7
+#define MII_CTRL_BUSY_SHIFT  8
+
+#define MII_DATA_OFFSET  0x004
+#define MII_DATA_MASK0x
+#define MII_DATA_TA_SHIFT16
+#define MII_DATA_TA_VAL  2
+#define MII_DATA_RA_SHIFT18
+#define MII_DATA_PA_SHIFT23
+#define MII_DATA_OP_SHIFT28
+#define MII_DATA_OP_WRITE1
+#define MII_DATA_OP_READ 2
+#define MII_DATA_SB_SHIFT30
+
+struct iproc_mdio_priv {
+   struct mii_bus *mii_bus;
+   void __iomem *base;
+};
+
+static inline int iproc_mdio_wait_for_idle(void __iomem *base)
+{
+   u32 val;
+   unsigned int timeout = 1000; /* loop for 1s */
+
+   do {
+   val = readl(base + MII_CTRL_OFFSET);
+   if ((val & BIT(MII_CTRL_BUSY_SHIFT)) == 0)
+   return 0;
+
+   usleep_range(1000, 2000);
+   } while (timeout--);
+
+   return -ETIMEDOUT;
+}
+
+static inline void iproc_mdio_config_clk(void __iomem *base)
+{
+   u32 val;
+
+   val = (IPROC_GPHY_MDCDIV << MII_CTRL_DIV_SHIFT) |
+ BIT(MII_CTRL_PRE_SHIFT);
+   writel(val, base + MII_CTRL_OFFSET);
+}
+
+static int iproc_mdio_read(struct mii_bus *bus, int phy_id, int reg)
+{
+   struct iproc_mdio_priv *priv = bus->priv;
+   u32 cmd;
+   int rc;
+
+   rc = iproc_mdio_wait_for_idle(priv->base);
+   if (rc)
+   return rc;
+
+   iproc_mdio_config_clk(priv->base);
+
+   /* Prepare the read operation */
+   cmd = (MII_DATA_TA_VAL << MII_DATA_TA_SHIFT) |
+   (reg << MII_DATA_RA_SHIFT) |
+   (phy_id << MII_DATA_PA_SHIFT) |
+   BIT(MII_DATA_SB_SHIFT) |
+   (MII_DATA_OP_READ << MII_DATA_OP_SHIFT);
+
+   writel(cmd, priv->base + MII_DATA_OFFSET);
+
+   rc = iproc_mdio_wait_for_idle(priv->base);
+   if (rc)
+   return rc;
+
+   cmd = readl(priv->base + MII_DATA_OFFSET) & MII_DATA_MASK;
+
+   return cmd;
+}
+
+static int iproc_mdio_write(struct mii_bus *bus, int phy_id,
+   int reg, u16 val)
+{
+   struct iproc_mdio_priv *priv = bus->priv;
+   u32 cmd;
+   int rc;
+
+   rc = iproc_mdio_wait_for_idle(priv->base);
+   if (rc)
+   return rc;
+
+   iproc_mdio_config_clk(priv->base);
+
+   /* Prepare the 

[PATCH v3 0/5] Add support for Broadcom's iProc MDIO and Cygnus Ethernet PHY

[Arun Parameswaran]

Hi
This patchset adds support for the iProc MDIO interface and the
Broadcom Cygnus SoC's internal Ethernet PHY.

The internal Ethernet PHY(s) in the Cygnus SoC's are accessed
via the MDIO interface found in most of the iProc based chips.

The patch also consolidates the common API's used by the
Broadcom phys to a common library. Existing Broadcom phy
drivers have been modified to use the common library API's.

This patch series is based on Linux v4.3-rc1 and is avaliable in:
https://github.com/Broadcom/cygnus-linux/tree/cygnus-net-phy-mdio-v3

The Ethernet driver for the iProc family will be submitted soon,
as will the device tree configurations for the different iProc
family SoCs.

Changes from v2:
- Modified drivers/net/phy/Kconfig to modify the BCM_CYGNUS_PHY
  driver to 'depends on MDIO_BCM_IPROC' instead of 'select'.
- Added github branch to the cover letter

Changes from v1:
- Updated device tree documentation for the iProc MDIO driver
  based on Florian's feedback.
- Moved the core register defines from the Cygnus PHY driver to
  'include/linux/brcmphy.h' based on Florian's feedback.
- Created a new patch/commit to modify the bcm7xxx phy driver
  to use the new core register defines.
- Modified the Kconfig entry for the Broadcom PHY library to
  'tristate' instead of 'bool'

Arun Parameswaran (5):
  dt-bindings: net: Broadcom iProc MDIO bus driver device tree binding
  net: phy: Broadcom iProc MDIO bus driver
  net: phy: Add Broadcom phy library for common interfaces
  net: phy: Broadcom Cygnus internal Etherent PHY driver
  net: phy: bcm7xxx: Modified to use global core register defines

 .../devicetree/bindings/net/brcm,iproc-mdio.txt|  23 +++
 drivers/net/phy/Kconfig|  28 +++
 drivers/net/phy/Makefile   |   3 +
 drivers/net/phy/bcm-cygnus.c   | 158 +++
 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  | 136 +++--
 drivers/net/phy/broadcom.c | 149 +-
 drivers/net/phy/mdio-bcm-iproc.c   | 213 +
 include/linux/brcmphy.h|  29 +--
 11 files changed, 761 insertions(+), 262 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt
 create mode 100644 drivers/net/phy/bcm-cygnus.c
 create mode 100644 drivers/net/phy/bcm-phy-lib.c
 create mode 100644 drivers/net/phy/bcm-phy-lib.h
 create mode 100644 drivers/net/phy/mdio-bcm-iproc.c

-- 
2.5.2

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

Re: [PATCH v4 0/2] pwm: Broadcom BCM7038 PWM controller (v4)

[Florian Fainelli]

On 05/10/15 08:14, Thierry Reding wrote:
> On Mon, Sep 14, 2015 at 04:47:04PM -0700, Florian Fainelli wrote:
>> Hi,
>>
>> This patch series add PWM support for the Broadcom BCM7xxx
>> chips which feature one or more PWM controllers capable of
>> output periods from 148ns to ~622ms using a combination of
>> variable and fixed frequency settings.
>>
>> The controller does not support setting a polarity.
>>
>> This is based on Thierry's pwm/next branch.
>>
>> Florian Fainelli (2):
>>   Documentation: dt: add Broadcom BCM7038 PWM controller binding
>>   pwm: Add Broadcom BCM7038 PWM controller support
> 
> I've applied both of these patches with a couple of stylistic changes.

Thanks but:

1) you dropped the MODULE_DEVICE_TABLE while doing so which is useful
for auto-loading OF modules
2) you introduced a build failure in the CONFIG_PM_SLEEP

There was a patch just submitted for 2), but I can submit an incremental
for 1) maybe?
-- 
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 v2 4/5] net: phy: Broadcom Cygnus internal Etherent PHY driver

[Arun Parameswaran]

On 15-09-30 09:04 PM, kbuild test robot wrote:
> Hi Arun,
>
> [auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
> ignore]
>
> config: um-allyesconfig (attached as .config)
> reproduce:
> git checkout 0560b94805aa3bb38439b4f72b776d85d2aac394
> # save the attached .config to linux build tree
> make ARCH=um 
>
> All warnings (new ones prefixed by >>):
>
> warning: (BCM_CYGNUS_PHY) selects MDIO_BCM_IPROC which has unmet direct 
> dependencies (NETDEVICES && PHYLIB && (ARCH_BCM_IPROC || COMPILE_TEST) && 
> HAS_IOMEM && OF_MDIO)

Fixing this warning.
Changing from 'select MDIO_BCM_IPROC' to using 'depends on MDIO_BCM_IPROC' in 
the Cygnus PHY driver.

> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

--
To unsubscribe from this list: send the line "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] video: fbdev: add Marvell PXA framebuffer binding

[Robert Jarzmik]

Rob Herring  writes:

> On Sun, Oct 4, 2015 at 5:31 AM, Robert Jarzmik  wrote:
>> Add documentation for the PXA frambuffer devicetree binding.
>
> Strictly speaking this is a binding for PXA display controller, not a
> Linux FB driver. There are lots of "framebuffer" and "DRM" bindings
> which I'm trying to curb.
Yes, that's very true. That deserves a new commit message and a new file name
(marvell,pxa2xx-lcd).
>>  .../devicetree/bindings/video/marvell,pxafb.txt| 80 
>> ++
>
> Please put in bindings/display/ as I'm consolidating all the display
> related bindings there[1].
Of course, for v3.

>> +++ b/Documentation/devicetree/bindings/video/marvell,pxafb.txt
>> @@ -0,0 +1,80 @@
>> +PXA LCDC Framebuffer
>> +
>> +
>> +Required properties:
>> + - compatible :
>> +   "marvell,pxa2xx-lcdc",
>
> No differences in h/w for any of the chips?
All pxa25x, pxa27x and pxa3xx are compatible.
AFAIK, pxa3xx has an IP with additional registers. But :
 - these (this) register(s) is not necessary for the display controller to work
   (it's more a control to shift red/green/blue values, and energy management)
 - all the registers in pxa2{5,7}x are the same in pxa3xx

The pxafb driver acts today on the subset of registers which are the same across
all pxaXXX variants. This is what made me think only one compatible property was
required.

If I'm wrong, I could add "marvell,pxa3xx-lcdc", is that what you think I should
do ?
>
>> + - reg : Should contain 1 register ranges(address and length).
>> +Can contain an additional register range(address and length)
>> +for fixed framebuffer memory. Useful for dedicated memories.
>
> This is memory that can't be used for anything else? We already have
> reserved-memory for this if it is just RAM. There's also a binding for
> on-chip SRAM which should probably be used if the memory is usable for
> other things.
That is a wrong copy paste I made. I was more thinking of having only 1 register
range, and no video memory reservation ...

>> +PXA LCDC Display
>
> This should not be specific to PXA, but for this panel. This should be
> in bindings/display/panel/.
Sure, for v3.

>> +
>> +Required properties (as per of_videomode_helper):
>> + - lcd-type: either "mono-stn", "mono-dstn", "color-stn", "color-dstn",
>> +   "color-tft", "smart-panel"
>> +
>> +Optional properties (as per of_videomode_helper):
>> + - power-supply: power supply regulator to the LCD to power it on or off
>> +(see regulator.txt)
>> + - backlight: backlight control (see backlight.txt)
>> +
>> +Required nodes:
>> + - port: connection to the LCD controller
>> + - display-timings: panel timings (see display-timing.txt)
>
> If lcd-type is smart-panel, then this node would not make sense.
Ah I see, so this could be optional maybe ?

Actually when I'll move the panel definition to bindings/display/panel, is this
what I should do :
 - create a file marvell,pxa2xx-panel
 - input all these properties into this file

And then, when a board maintainer will create a devicetree description, he will
write something like :
  compatible = "toshiba,ltm0305a776";
  compatible = "marvell,pxa2xx-panel";
  lcd-type = "color-tft";
  ...

If that's the case, I wonder how to "enforce" that a panel used with
marvell,pxa2xx-lcdc (through the of_graph 'port' node) be compatible with
marvell,pxa2xx-panel ?

Cheers.

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

Re: [RFC PATCH v6 2/3] dtc: dts source location annotation

[Frank Rowand]

On 10/5/2015 9:56 PM, David Gibson wrote:
> On Fri, Oct 02, 2015 at 09:52:48PM -0700, Frank Rowand wrote:
>> From: Frank Rowand 
>>
>> Proof of concept patch.
>>
>> Annotates input source file and line number of nodes and properties
>> as comments in output .dts file when --annotate flag is supplied.

< snip >

> The two branches here aren't quite consistent - the first doesn't
> include the '/', the second does.  You could either change the second
> to just &@3, or use &@$ for the first.

< snip >

> This one doesn't include the name/label again

< snip>

> 
> .. and this one does.
> 
> Looking at all of these it's probably going to be simplest not to
> include the label/name (i.e. just use the srcpos from the nodedef).

This also shows how much I need to create a better "make check" test
suite to exercise all of the relevant paths (as is on my todo list).

I've been trying to capture the line that the name is on, since it
might be different than the line that the "{" is on, but maybe I'm
just trying too hard and should accept the simpler solution.  The
result will be obvious to the person using the output.

I'll fix this all up after I get back from the conference.

Thanks for checking the patch over at that level of detail!

-frank
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" 
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] video: fbdev: add Marvell PXA framebuffer binding

[Philipp Zabel]

On Sun, Oct 4, 2015 at 12:31 PM, Robert Jarzmik  wrote:
> Add documentation for the PXA frambuffer devicetree binding.
>
> Signed-off-by: Robert Jarzmik 
> ---
> Since v1: Philipp's review on the whole binding
> ---
>  .../devicetree/bindings/video/marvell,pxafb.txt| 80 
> ++
>  1 file changed, 80 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/marvell,pxafb.txt
>
> diff --git a/Documentation/devicetree/bindings/video/marvell,pxafb.txt 
> b/Documentation/devicetree/bindings/video/marvell,pxafb.txt
> new file mode 100644
> index ..4d6bd490680d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/marvell,pxafb.txt
> @@ -0,0 +1,80 @@
> +PXA LCDC Framebuffer
> +
> +
> +Required properties:
> + - compatible :
> +   "marvell,pxa2xx-lcdc",
> + - reg : Should contain 1 register ranges(address and length).
> +Can contain an additional register range(address and length)
> +for fixed framebuffer memory. Useful for dedicated memories.
> + - interrupts : framebuffer controller interrupt
> +
> +Required nodes:
> + - clocks: phandle to input clocks.
> + - port: connection to the LCD panel (see video-interfaces.txt)
> +This nodes must have its properties bus-width and remote-endpoint 
> set.
> +This should be in the board dts.
> +
> +Example:
> +
> +   lcd-controller@4050 {
> +   compatible = "marvell,pxa2xx-lcdc";
> +   reg = <0x4400 0x1>;
> +   interrupts = <17>;
> +   clocks = < CLK_LCD>;
> +   interrupts = <23>;

The interrupt line is duplicated in the example.

> +   status = "okay";
> +
> +   port {
> +   lcdc_out: endpoint {
> +   remote-endpoint = <_in>;
> +   bus-width = <16>;
> +   };
> +   };
> +   };
> +
> +PXA LCDC Display
> +
> +Required properties (as per of_videomode_helper):
> + - lcd-type: either "mono-stn", "mono-dstn", "color-stn", "color-dstn",
> +   "color-tft", "smart-panel"

Would it make sense to make this property optional and have the
default be "color-tft"? That is probably the most common one by far.

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

[PATCH] arm64: dts: mt8173: add MT8173 display PWM driver support node

[YH Huang]

Add display PWM node in mt8173-evb.dts and mt8173.dtsi.

Signed-off-by: YH Huang 
---
 arch/arm64/boot/dts/mediatek/mt8173-evb.dts |   13 +
 arch/arm64/boot/dts/mediatek/mt8173.dtsi|   22 ++
 2 files changed, 35 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts 
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 811cb76..1b3fabd 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -92,6 +92,13 @@
 };
 
  {
+   disp_pwm0_pins: disp_pwm0_pins {
+   pins1 {
+   pinmux = ;
+   output-low;
+   };
+   };
+
mmc0_pins_default: mmc0default {
pins_cmd_dat {
pinmux = ,
@@ -190,6 +197,12 @@
};
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pwm0_pins>;
+   status = "okay";
+};
+
  {
pmic: mt6397 {
compatible = "mediatek,mt6397";
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 4bce167..fd01134 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -500,6 +500,28 @@
clock-names = "source", "hclk";
status = "disabled";
};
+
+   pwm0: pwm@1401e000 {
+   compatible = "mediatek,mt8173-disp-pwm",
+"mediatek,mt6595-disp-pwm";
+   reg = <0 0x1401e000 0 0x1000>;
+   #pwm-cells = <2>;
+   clocks = < CLK_MM_DISP_PWM026M>,
+< CLK_MM_DISP_PWM0MM>;
+   clock-names = "main", "mm";
+   status = "disabled";
+   };
+
+   pwm1: pwm@1401f000 {
+   compatible = "mediatek,mt8173-disp-pwm",
+"mediatek,mt6595-disp-pwm";
+   reg = <0 0x1401f000 0 0x1000>;
+   #pwm-cells = <2>;
+   clocks = < CLK_MM_DISP_PWM126M>,
+< CLK_MM_DISP_PWM1MM>;
+   clock-names = "main", "mm";
+   status = "disabled";
+   };
};
 };
 
-- 
1.7.9.5

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

RE: [PATCH v7 1/2] pwm: Add device tree binding document for R-Car PWM Timer

[Yoshihiro Shimoda]

Hi Rob,

> Sent: Tuesday, October 06, 2015 12:39 AM
> 
> On Wed, Sep 30, 2015 at 3:47 AM, Yoshihiro Shimoda
>  wrote:
> > Add binding document for Renesas PWM Timer on R-Car SoCs.
> >
> > Signed-off-by: Yoshihiro Shimoda 
> > Acked-by: Geert Uytterhoeven 
> > Reviewed-by: Simon Horman 
> > ---
> >  .../devicetree/bindings/pwm/renesas,pwm-rcar.txt   | 27 
> > ++
> >  1 file changed, 27 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt
> b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt
> > new file mode 100644
> > index 000..ea0a27b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt
> > @@ -0,0 +1,27 @@
> > +* Renesas R-Car PWM Timer Controller
> > +
> > +Required Properties:
> > +- compatible: should be one of the following.
> > + - "renesas,pwm-rcar": for generic R-Car compatible PWM Timer
> 
> Should be this one and one of the following? That is what the example shows.

Thank you for the point.
Since this patch is already merged in linux-pwm repository, I will submit
a new patch to revise it.

Best regards,
Yoshihiro Shimoda

> > + - "renesas,pwm-r8a7778": for R-Car M1A
> > + - "renesas,pwm-r8a7779": for R-Car H1
> > + - "renesas,pwm-r8a7790": for R-Car H2
> > + - "renesas,pwm-r8a7791": for R-Car M2-W
> > + - "renesas,pwm-r8a7794": for R-Car E2
> > +- reg: base address and length of the registers block for the PWM.
> > +- #pwm-cells: should be 2. See pwm.txt in this directory for a description 
> > of
> > +  the cells format.
> > +- clocks: clock phandle and specifier pair.
> > +- pinctrl-0: phandle, referring to a default pin configuration node.
> > +- pinctrl-names: Set to "default".
> > +
> > +Example: R8A7790 (R-Car H2) PWM Timer node
> > +
> > +   pwm0: pwm@e6e3 {
> > +   compatible = "renesas,pwm-r8a7790", "renesas,pwm-rcar";
> > +   reg = <0 0xe6e3 0 0x8>;
> > +   #pwm-cells = <2>;
> > +   clocks = <_clks R8A7790_CLK_PWM>;
> > +   pinctrl-0 = <_pins>;
> > +   pinctrl-names = "default";
> > +   };
> > --
> > 1.9.1
> >

Re: [RFC PATCH v6 1/3] dtc: protect against null pointer dereference in srcpos_string()

[Frank Rowand]

On 10/5/2015 9:10 PM, David Gibson wrote:
> On Fri, Oct 02, 2015 at 09:49:08PM -0700, Frank Rowand wrote:
>> From: Frank Rowand 
>>
>> Check for NULL pos before dereferencing it in srcpos_string().
>>
>> Signed-off-by: Frank Rowand 
>> ---
>>  srcpos.c |6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> Index: b/srcpos.c
>> ===
>> --- a/srcpos.c
>> +++ b/srcpos.c
>> @@ -268,11 +268,13 @@ srcpos_string(struct srcpos *pos)
>>  char *pos_str;
>>  int rc;
>>  
>> -if (pos)
>> +if (pos && pos->file)
>>  fname = pos->file->name;
>>  
>>  
>> -if (pos->first_line != pos->last_line)
>> +if (!pos)
>> +rc = asprintf(_str, "%s:", fname);
>> +else if (pos->first_line != pos->last_line)
> 
> This logic still seems backwards to me.  I'd really prefer the !pos
> check to go first, then !pos->file, then the normal case.
> 

Checking !pos first results in either an early return, a goto,
or more deeply nesting the

   if (pos->first_line != pos->last_line)
  asprintf(...)
   else if (...)
  asprintf(...)
   else
  rc = asprintf(...)

all of which seemed worse.  In the next version I'll change it to:

char *
srcpos_string(struct srcpos *pos)
{
const char *fname = "";
char *pos_str;
int rc;

if (!pos) {
rc = asprintf(_str, "%s:", fname);
goto out;
} else if (pos->file) {
fname = pos->file->name;
}

if (pos->first_line != pos->last_line)
rc = asprintf(_str, "%s:%d.%d-%d.%d", fname,
  pos->first_line, pos->first_column,
  pos->last_line, pos->last_column);
else if (pos->first_column != pos->last_column)
rc = asprintf(_str, "%s:%d.%d-%d", fname,
  pos->first_line, pos->first_column,
  pos->last_column);
else
rc = asprintf(_str, "%s:%d.%d", fname,
  pos->first_line, pos->first_column);

out:
if (rc == -1)
die("Couldn't allocate in srcpos string");

return pos_str;
}

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

Re: [RFC PATCH v6 3/3] dtc: dts source location annotation, short location format

[Frank Rowand]

On 10/5/2015 10:01 PM, David Gibson wrote:
> On Fri, Oct 02, 2015 at 09:55:17PM -0700, Frank Rowand wrote:
> 
> Uh.. the actual patch seems to be missing.
> 

Ah, the fun of broken email tools.  I'll be changing my email tools
in the near future.

This version of the patch is intended to show what is involved
in creating the short input, given the changes to the other
patches.  If it looks reasonable, I will add the modifications
to --annotate to allow a choice of either short or long format.

This version also has a totally awkward:

   srcpost_string_short()
   {
 if (pos)
...

 if (!pos)
...
 else
...

which I will fix in the next version.

-Frank




From: Frank Rowand 

Show only the current line number in each source annotation instead
of the full range of the object.

TODO:
  - modify "--annotate" command line option to choose short or long annotation


Not-signed-off-by: Frank Rowand 
---
 srcpos.c |   34 ++
 srcpos.h |4 
 treesource.c |8 
 3 files changed, 42 insertions(+), 4 deletions(-)

Index: b/srcpos.c
===
--- a/srcpos.c
+++ b/srcpos.c
@@ -327,6 +327,40 @@ srcpos_string(struct srcpos *pos)
return pos_str;
 }
 
+char *
+srcpos_string_short(struct srcpos *pos, int first_line)
+{
+   const char *fname = "";
+   char *pos_str;
+   int rc;
+
+   if (pos)
+   fname = pos->file->name;
+
+   if (!pos)
+   rc = asprintf(_str, "%s:", fname);
+   else
+   rc = asprintf(_str, "%s:%d", fname,
+ (first_line) ? pos->first_line: pos->last_line);
+
+   if (rc == -1)
+   die("Couldn't allocate in srcpos_string_short");
+
+   return pos_str;
+}
+
+char *
+srcpos_string_first(struct srcpos *pos)
+{
+   return srcpos_string_short(pos, 1);
+}
+
+char *
+srcpos_string_last(struct srcpos *pos)
+{
+   return srcpos_string_short(pos, 0);
+}
+
 void srcpos_verror(struct srcpos *pos, const char *prefix,
   const char *fmt, va_list va)
 {
Index: b/treesource.c
===
--- a/treesource.c
+++ b/treesource.c
@@ -204,7 +204,7 @@ static void write_propval(FILE *f, struc
 
if (len == 0) {
if (annotate) {
-   srcstr = srcpos_string(prop->srcpos);
+   srcstr = srcpos_string_first(prop->srcpos);
fprintf(f, "; /* %s */\n", srcstr);
free(srcstr);
} else {
@@ -238,7 +238,7 @@ static void write_propval(FILE *f, struc
}
 
if (annotate) {
-   srcstr = srcpos_string(prop->srcpos);
+   srcstr = srcpos_string_first(prop->srcpos);
fprintf(f, "; /* %s */\n", srcstr);
free(srcstr);
} else {
@@ -262,7 +262,7 @@ static void write_tree_source_node(FILE
else
fprintf(f, "/ {");
if (annotate) {
-   srcstr = srcpos_string(tree->srcpos);
+   srcstr = srcpos_string_first(tree->srcpos);
fprintf(f, " /* %s */\n", srcstr);
free(srcstr);
} else {
@@ -282,7 +282,7 @@ static void write_tree_source_node(FILE
}
write_prefix(f, level);
if (annotate) {
-   srcstr = srcpos_string(tree->srcpos);
+   srcstr = srcpos_string_last(tree->srcpos);
fprintf(f, "}; /* %s */\n", srcstr);
free(srcstr);
} else {
Index: b/srcpos.h
===
--- a/srcpos.h
+++ b/srcpos.h
@@ -107,6 +107,10 @@ extern struct srcpos *srcpos_copy(struct
 extern struct srcpos *srcpos_copy_all(struct srcpos *pos);
 extern struct srcpos *srcpos_combine(struct srcpos *left_srcpos, struct srcpos 
*right_srcpos);
 extern char *srcpos_string(struct srcpos *pos);
+extern char *srcpos_string_short(struct srcpos *pos, int line);
+extern char *srcpos_string_first(struct srcpos *pos);
+extern char *srcpos_string_last(struct srcpos *pos);
+
 extern void srcpos_dump(struct srcpos *pos);
 
 extern void srcpos_verror(struct srcpos *pos, const char *prefix,
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" 
in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ARM: shmobile: silk: add SDHI1 DT support

[Sergei Shtylyov]

Hello.

  Sorry for tyhe long delay, I've been busy with other things. Now I'm 
dealing with SDHI again, this time for the Porter board.


On 09/29/2015 11:44 AM, Magnus Damm wrote:


Define the SILK board dependent part of the SDHI1 (connected to
micro-SD slot)
device nodes along with the necessary voltage regulators.

Based on the original patch by Vladimir Barinov
.

Signed-off-by: Sergei Shtylyov 

---
This patch is against 'renesas-devel-20150810-v4.2-rc6' tag of
Simon Horman's
'renesas.git' repo plus the R8A7794/SILK QSPI patches just
re-posted. It needs
the R8A7794 GPIO patches in order to compile.

Changes in version 2:
- removed not working SDHI0 stuff, renamed the patch;
- replaced SDHI1's "wp-gpios" property with "disable-wp".



I am wondering if you could explain the motivation for the
"disable-wp"
update



 Please see the comment in mmc_sd_get_ro().


and weather it is appropriate for other r8a779* dts files.



 In case of micro-SD slots, yes.



 The MMC binding document says it should only be specified if the
controller has WP detection logic. We, so far, seem to have been
replying on
the GPIOs despite this logic is present (according to the R-Car gen2
SDHI
manuals I have). The driver will first call mmc_gpio_get_ro() and when
that
fails due to "wp-gpios" not being specified, it proceeds to reading
the
register but that is forbidden by TMIO_MMC_WRPROTECT_DISABLE flag set
for
the R-Car gen1/2 chips, so 0 is always returned from
tmio_mmc_get_ro().
There seems to be no point in going that far (and doing the runtime PM
dances) --



 Alternatively, the driver could be fixed to check the flag before
the RPM
call unlike what it does now.



If the driver can be updated to do the right thing then that seems
preferable to me. If so would it be the case that the presence of the
"disable-wp" property would not have any run-time effect?




and MMC_CAP2_NO_WRITE_PROTECT (set when "disable-wp" is specified)
prohibits
doing that...



That sounds reasonable to me.



 I'm still wondering why TMIO_MMC_WRPROTECT_DISABLE is set for the
R-Car
SoCs. Morimoto-san, any comments? Your change logs are too terse. :-)



I will follow up on this.



[...]


Now what is the issue that you guys are having?



My main issue is that I don't understand why checking the write protect
bit is always prohibited for the R-Car SoCs (by setting
TMIO_MMC_WRPROTECT_DISABLE), i.e. it can only be read via GPIO (though that
GPIO is just an alias of the WP signal).



I believe the reason is that we decided to keep it simple - so we
preferred to use GPIO instead of native SDHI signals. So GPIO WP
instead of the not-always-present SDHI WP signal. Historically CD and
WP may on some boards be routed on different pins than the SDHI CD and
WP lines, and if we support both GPIO and native SDHI signals we need
to handle both cases.


   If you look at the driver code, it's already capable of handling both cases.


With GPIO there is only one case to handle. And
it is not exactly hot path to handle WP and CD so the overhead must be
minimal.


[...]


The on-chip SoC SDHI devices in DT and the driver on R-Car Gen2
assumes no WP and CD signals by default. It is up to each board to
opt-in to add the GPIOs for WP and CD. It is very simple and should
make it possible to power down the SDHI instances if no cards are
inserted and let the GPIO IRQ wake up things for us.


   Again, if you look at the driver code, it first powers up the controller, 
(thru runtime PM) and only then checks the TMIO_MMC_WRPROTECT_DISABLE flag. 
That's what I tried to change but didn't succeed because the current MMC code 
will have already powered up the controller by that time.



I still don't understand what the real problem is though...


   The original issue revolved around the "disable-wp" prop. The common MMC 
bindings say that this prop should only be used "when the controller has a 
dedicated write-protect detection logic". This logic is obviously present but 
its use seems suppressed on the R-Car SoCs by the infamous flag... :-)



Thanks,

/ magnus


MBR, Sergei

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

[RFC][PATCH 2/2] staging: ion: Add files for parsing the devicetree (WIP)

[Laura Abbott]

From: Laura Abbott 


Devicetree is the preferred mechanism for platform definition
these days. Add a set of files for supporting Ion with devicetree.
This includes a set of bindings for heaps common across all
devices and parsing methods. Clients may use the standard
bindings or they can call the parsing functions along with
their own parsing for platform specific heaps.

Signed-off-by: Laura Abbott 
Signed-off-by: Andrew Andrianov 
---
 drivers/staging/android/ion/Kconfig  |  10 ++
 drivers/staging/android/ion/Makefile |   7 +-
 drivers/staging/android/ion/ion_of.c | 185 +++
 drivers/staging/android/ion/ion_of.h |   3 +
 4 files changed, 202 insertions(+), 3 deletions(-)
 create mode 100644 drivers/staging/android/ion/ion_of.c
 create mode 100644 drivers/staging/android/ion/ion_of.h

diff --git a/drivers/staging/android/ion/Kconfig 
b/drivers/staging/android/ion/Kconfig
index 3452346..9b6d65d 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -33,3 +33,13 @@ config ION_TEGRA
help
  Choose this option if you wish to use ion on an nVidia Tegra.
 
+config ION_OF
+   bool "Devicetree support for Ion"
+   depends on ION && OF
+   help
+ Provides base support for defining Ion heaps in devicetree
+ and setting them up. Also includes functions for platforms
+ to parse the devicetree and expand for their own custom
+ extensions
+
+ If using Ion and devicetree, you should say Y here
diff --git a/drivers/staging/android/ion/Makefile 
b/drivers/staging/android/ion/Makefile
index b56fd2b..6602512 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -5,6 +5,7 @@ ifdef CONFIG_COMPAT
 obj-$(CONFIG_ION) += compat_ion.o
 endif
 
-obj-$(CONFIG_ION_DUMMY) += ion_dummy_driver.o
-obj-$(CONFIG_ION_TEGRA) += tegra/
-
+obj-$(CONFIG_ION_DUMMY)   += ion_dummy_driver.o
+obj-$(CONFIG_ION_PHYSMEM) += ion_physmem.o
+obj-$(CONFIG_ION_TEGRA)   += tegra/
+obj-$(CONFIG_ION_OF) +=ion_of.o ion_physmem.o
diff --git a/drivers/staging/android/ion/ion_of.c 
b/drivers/staging/android/ion/ion_of.c
new file mode 100644
index 000..3c9b1e5
--- /dev/null
+++ b/drivers/staging/android/ion/ion_of.c
@@ -0,0 +1,185 @@
+/*
+ * Based on work from:
+ *   Andrew Andrianov 
+ *   Google
+ *   The Linux Foundation
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include "ion.h"
+#include "ion_priv.h"
+
+/*
+ * Future work: allow callback function for each heap?
+ */
+
+int ion_parse_dt_heap_common(struct device_node *heap_node,
+   struct ion_platform_heap *heap)
+{
+   u32 ion_heap_id, ion_heap_align, ion_heap_type;
+   const char *ion_heap_name;
+   int ret;
+
+   ret =  of_property_read_string(heap_node, "linux,ion-heap-name",
+   _heap_name);
+   if (ret)
+   return ret;
+
+   ret = of_property_read_u32(heap_node, "linux,ion-heap-id",
+   _heap_id);
+   if (ret)
+   return ret;
+
+   ret = of_property_read_u32(heap_node, "linux,ion-heap-type",
+   _heap_type);
+   if (ret)
+   return ret;
+
+   ret = of_property_read_u32(heap_node, "linux,ion-heap-align",
+   _heap_align);
+   if (ret)
+   /* align is optional so make the alignemnt page size */
+   ion_heap_align = PAGE_SIZE;
+
+   heap->id = ion_heap_id;
+   heap->type = ion_heap_type;
+   heap->name = ion_heap_name;
+   heap->align = ion_heap_align;
+   pr_info("%s: id %d type %d name %s align %x\n",
+   __func__,
+   ion_heap_id, ion_heap_type,
+   ion_heap_name, ion_heap_align);
+   return 0;
+}
+
+int ion_setup_heap_common(struct platform_device *parent,
+   struct device_node *heap_node,
+   struct ion_platform_heap *heap)
+{
+   int ret = 0;
+
+   switch (heap->type) {
+   case ION_HEAP_TYPE_CARVEOUT:
+   case ION_HEAP_TYPE_CHUNK:
+   if (heap->base && heap->size)
+   return 0;
+
+   ret = of_reserved_mem_device_init(heap->priv);
+   break;
+   default:
+   break;
+   }
+
+   return ret;
+}
+
+struct ion_platform_data *ion_parse_dt(struct platform_device *pdev)
+{
+   int num_heaps, ret;
+   const 

[RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Laura Abbott]

From: Laura Abbott 


This adds a base set of devicetree bindings for the Ion memory
manager. This supports setting up the generic set of heaps and
their properties.

Signed-off-by: Laura Abbott 
Signed-off-by: Andrew Andrianov 
---
 drivers/staging/android/ion/devicetree.txt | 53 ++
 1 file changed, 53 insertions(+)
 create mode 100644 drivers/staging/android/ion/devicetree.txt

diff --git a/drivers/staging/android/ion/devicetree.txt 
b/drivers/staging/android/ion/devicetree.txt
new file mode 100644
index 000..4a0c941
--- /dev/null
+++ b/drivers/staging/android/ion/devicetree.txt
@@ -0,0 +1,53 @@
+Ion Memory Manager
+
+Ion is a memory manager that allows for sharing of buffers via dma-buf.
+Ion allows for different types of allocation via an abstraction called
+a 'heap'. A heap represents a specific type of memory. Each heap has
+a different type. There can be multiple instances of the same heap
+type.
+
+Required properties for Ion
+
+- compatible: "linux,ion"
+
+All child nodes of a linux,ion node are interpreted as heaps
+
+required properties for heaps
+
+- linux,ion-heap-id: The Ion heap id used for allocation selection
+- linux,ion-heap-type: Ion heap type defined in ion.h
+- linux,ion-heap-name: Human readble name of the heap
+
+
+Optional properties
+- memory-region: A phandle to a memory region. Required for DMA heap type
+(see reserved-memory.txt for details on the reservation)
+- linux,ion-heap-align: Alignment for the heap.
+
+Example:
+
+   ion {
+   compatbile = "linux,ion";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ion-system-heap {
+   linux,ion-heap-id = <0>;
+   linux,ion-heap-type = ;
+   linux,ion-heap-name = "system";
+   };
+
+   ion-camera-region {
+   linux,ion-heap-id = <1>;
+   linux,ion-heap-type = ;
+   linux,ion-heap-name = "camera"
+   memory-region = <_region>;
+   };
+
+   ion-fb-region {
+   linux,ion-heap-id = <2>;
+   linux,ion-heap-type = ;
+   linux,ion-heap-name = "fb"
+   memory-region = <_region>;
+   };
+   }
-- 
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

[RFC][PATCH 0/2] Devicetree bindings for Ion

[Laura Abbott]

From: Laura Abbott 


Hi,

At the last Plumbers and Linaro Connect, there was some discussion
related to Ion. One of the items that came up towards eventually
getting Ion out of staging was some concept of stable devicetree
bindings. This is a proof of concept for bindings.

Most of this is based on previously submitted work
(https://lkml.org/lkml/2015/6/30/425 thank you Andrew Andrianov for
getting this started!) and also the
out of tree qcom bindings (available somewhere on codeaurora.org).
As the title indicates, this is an RFC and the purpose here is to
get feedback on if these bindings would potentially work. If there
are platforms out there that don't use devicetree, the bindings
would hopefully also serve as a guide for how to setup the platform
data for heaps like CMA.

One of the big things this series improves on is giving a standard
mechanism for defining and allocating memory for all heap types.
DMA/CMA is handled as well as memory for carveout and chunk heaps.

Further TODO:
- Need to fixup include paths so heap types can be cleanly included
  in DTS files
- Figure out callbacks or similar for support custom platform heaps

Laura Abbott (2):
  WIP: Devicetree bindings for Ion
  staging: ion: Add files for parsing the devicetree (WIP)

 drivers/staging/android/ion/Kconfig|  10 ++
 drivers/staging/android/ion/Makefile   |   7 +-
 drivers/staging/android/ion/devicetree.txt |  53 +
 drivers/staging/android/ion/ion_of.c   | 185 +
 drivers/staging/android/ion/ion_of.h   |   3 +
 5 files changed, 255 insertions(+), 3 deletions(-)
 create mode 100644 drivers/staging/android/ion/devicetree.txt
 create mode 100644 drivers/staging/android/ion/ion_of.c
 create mode 100644 drivers/staging/android/ion/ion_of.h

-- 
2.4.3

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

[PATCH] pwm: fix Broadcom BCM7038 PWM driver

[Arnd Bergmann]

The newly added pwm-brcmstb driver fails to build if CONFIG_PM_SLEEP
is enabled:

drivers/pwm/pwm-brcmstb.c: In function 'brcmstb_pwm_suspend':
drivers/pwm/pwm-brcmstb.c:309:42: error: 'dev' undeclared (first use in this 
function)
  struct brcmstb_pwm *p = dev_get_drvdata(dev);

This changes the name of the function argument to match its user.

Signed-off-by: Arnd Bergmann 
---
On Monday 05 October 2015 17:14:15 Thierry Reding wrote:
> On Mon, Sep 14, 2015 at 04:47:04PM -0700, Florian Fainelli wrote:
> > Florian Fainelli (2):
> >   Documentation: dt: add Broadcom BCM7038 PWM controller binding
> >   pwm: Add Broadcom BCM7038 PWM controller support
> 
> I've applied both of these patches with a couple of stylistic changes.

As in the pwm-berlin driver, one of the fixups was broken.

diff --git a/drivers/pwm/pwm-brcmstb.c b/drivers/pwm/pwm-brcmstb.c
index 083e3ef5b8e5..423ce087cd9c 100644
--- a/drivers/pwm/pwm-brcmstb.c
+++ b/drivers/pwm/pwm-brcmstb.c
@@ -304,7 +304,7 @@ static int brcmstb_pwm_remove(struct platform_device *pdev)
 }
 
 #ifdef CONFIG_PM_SLEEP
-static int brcmstb_pwm_suspend(struct device *d)
+static int brcmstb_pwm_suspend(struct device *dev)
 {
struct brcmstb_pwm *p = dev_get_drvdata(dev);
 
@@ -313,7 +313,7 @@ static int brcmstb_pwm_suspend(struct device *d)
return 0;
 }
 
-static int brcmstb_pwm_resume(struct device *d)
+static int brcmstb_pwm_resume(struct device *dev)
 {
struct brcmstb_pwm *p = dev_get_drvdata(dev);
 

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

Re: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND controller

[Scott Branden]

Hi Brian,

On 15-10-06 06:41 AM, Brian Norris wrote:



Is there a reason not to do this reset unconditionally? I recall this came up in
discussion previously, when the OpenWRT folks were trying to integrate with
BCMA, where this reset was one of the few differences between the platform-
device-based driver (i.e., this one) and the BCMA based driver. Might it help
simplify things a bit if we just did the same thing everywhere?


This driver is currently shared by Cygnus and NS2.

We had similar suggestion when this patch was reviewed
internally in Broadcom.

The rationale for adding optional DT flag is as follows:
1. The NAND controller reset is currently required for NS2 only so
that it is in sane state before any NAND commands are issued. We
are not sure if Cygnus and all future iProc SoCs will require NAND
controller reset.


I'm not sure this is a very strong reason. It seems fairly reasonable in
general to reset a HW block before using it.


Efficient Boot time is a very strong reason for needing this actually. 
We use the NAND controller in the bootROM, boot1/BL1, u-boot/UEFI, and 
then Kernel stage.  By properly initializing the controller once we do 
not need to reset it 4 different times.





2. The NAND controller reset in probe would certainly increase
Linux boot time so for certain iProc SoCs we might choose avoid
NAND controller reset to reduce boot time if possible.


I recall this reason being mentioned before. I believe this only happens
because the brcmnand driver doesn't yet handle configuring the timing
registers, so iProc is implicitly relying on the bootloader to configure
the NAND timings. Perhaps it's time that we fix that. I'd rather not add
extra DT properties unless we actually need to [1]. And having proper
timing configuration in the Linux driver will help improve speeds for
all users (whose timings may not be configured in the bootloader).


This is the very reason we need the optional reset property.  We need to 
have timings configured by the linux driver or not.  Yes, in some cases 
we will be relying on earlier boot stages to configure some of the hardware.




I actually had some preliminary work to do some timing configuration
according to the new timing information from nand_base.c/nand_timing.c.
Unfortunately, I didn't complete this, and I'm no longer working at
Broadcom, so I don't exactly have access to the HW docs for all the NAND
controller revisions, nor do I have access to as much HW for testing...

Brian

[1] If we really do need a device tree differentiation, perhaps it would
be better to just differentiate the compatible string than to have
individual boolean properties. e.g.:

compatible = "brcm,iproc-nand-ns2", ...;

As described above - the option is not SoC specific.  It is system 
specific.  In some systems we may wish to reset the NAND controller in 
linux.  In some we may wish to rely on initialization that has already 
been done to speed up boot times.




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

Re: [RFC][PATCH 2/2] staging: ion: Add files for parsing the devicetree (WIP)

[Andrew]

Thanks a lot for starting again with dt bindings discussion.
I got carried away by work and never had a chance for a respin of my 
ion-physmem.


I'll try to test these on actual hardware next week and provide more 
detailed

feedback. For now just a small pick:


-
+obj-$(CONFIG_ION_DUMMY)   += ion_dummy_driver.o
+obj-$(CONFIG_ION_PHYSMEM) += ion_physmem.o
+obj-$(CONFIG_ION_TEGRA)   += tegra/
+obj-$(CONFIG_ION_OF) +=ion_of.o ion_physmem.o


ion_physmem.o looks like the one that shouldn't be here, right?

P.S. Anyone interested in a non-android port of libion with
a few helper utils? I had to call it liblinuxion, since libion is 
something

already present in repositories.

--
Regards,
Andrew
RC Module
--
To unsubscribe from this list: send the line "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] clk: bcm2835: Add support for programming the audio domain clocks.

[Stefan Wahren]

Hi Eric,

Am 02.10.2015 um 21:54 schrieb Eric Anholt:

This adds support for enabling, disabling, and setting the rate of the
audio domain clocks.  It will be necessary for setting the pixel clock
for HDMI in the VC4 driver and let us write a cpufreq driver.  It will
also improve compatibility with user changes to the firmware's
config.txt, since our previous fixed clocks are unaware of it.

The firmware also has support for configuring the clocks through the
mailbox channel, but the pixel clock setup by the firmware doesn't
work, and it's Raspberry Pi specific anyway.  The only conflicts we
should have with the firmware would be if we made firmware calls that
result in clock management (like opening firmware V3D or ISP access,
which we don't support in upstream), or on hardware over-thermal or
under-voltage (when the firmware would rewrite PLLB to take the ARM
out of overclock).  If that happens, our cached .recalc_rate() results
would be incorrect, but that's no worse than our current state where
we used fixed clocks.

The existing fixed clocks in the code are left in place to provide
backwards compatibility with old device tree files.


only a few nits.



Signed-off-by: Eric Anholt 
Tested-by: Martin Sperl 
---

This is the remaining driver patch to go on the clock tree's
clk-bcm2385 (oops, spelling :) ) tree for the bcm2835 driver.

v2: Fix onecell->clks[] allocation size.
v3: '/*' on otherwise-empty line for multiline comments, fix top
 comment, use more named initializers, do fewer separate
 allocations on probe, unwind allocations on failure in probe (from
 review by Stephen Warren).  Use new clk_hw_get_name().  Switch
 fb_prediv_bit to be fb_prediv_mask to avoid typing BIT() so many
 times.
v4: Incorporate feedback from Stephen Boyd, and use devm_kasprintf instead
 of bare kasprintf in driver init.

  drivers/clk/bcm/clk-bcm2835.c | 1509 -
  1 file changed, 1508 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index dd295e4..9498fd9 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
[...]
+/*
+ * PLLA is the auxiliary PLL, used to drive the CCP2 (Compact Camera
+ * Port 2) transmitter clock.
+ *
+ * It is in the PX LDO power domain, which is on when the AUDIO domain
+ * is on.
+ */
+static const struct bcm2835_pll_data bcm2835_plla_data = {
+   .name = "plla",
+   .cm_ctrl_reg = CM_PLLA,
+   .a2w_ctrl_reg = A2W_PLLA_CTRL,
+   .frac_reg = A2W_PLLA_FRAC,
+   .ana_reg_base = A2W_PLLA_ANA0,
+   .reference_enable_mask = A2W_XOSC_CTRL_PLLA_ENABLE,
+   .lock_mask = CM_LOCK_FLOCKA,
+
+   .ana = _ana_default,
+
+   .min_rate = 6u,
+   .max_rate = 24u,
+   .max_fb_rate = 175000u,


How about using a define for the max_fb_rate and use it for all PLLs?


+ [...]
+static int bcm2835_pll_set_rate(struct clk_hw *hw,
+   unsigned long rate, unsigned long parent_rate)
+{
+   struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw);
+   struct bcm2835_cprman *cprman = pll->cprman;
+   const struct bcm2835_pll_data *data = pll->data;
+   bool was_using_prediv, use_fb_prediv, do_ana_setup_first;
+   u32 ndiv, fdiv, pdiv = 1, a2w_ctl;
+   u32 ana[4];
+   int i;
+
+   if (rate < data->min_rate || rate > data->max_rate) {
+   dev_err(cprman->dev, "%s: rate out of spec: %ld vs (%ld, 
%ld)\n",


The format specifier looks wrong to me:

s/%ld/%lu


+   clk_hw_get_name(hw), rate,
+   data->min_rate, data->max_rate);
+   return -EINVAL;
+   }
+
+   if (rate > data->max_fb_rate) {
+   use_fb_prediv = true;
+   rate /= 2;
+   } else {
+   use_fb_prediv = false;
+   }
+
+   bcm2835_pll_choose_ndiv_and_fdiv(rate, parent_rate, , );
+
+   for (i = 3; i >= 0; i--)
+   ana[i] = cprman_read(cprman, data->ana_reg_base + i * 4);
+
+   was_using_prediv = ana[1] & data->ana->fb_prediv_mask;
+
+   ana[0] &= ~data->ana->mask0;
+   ana[0] |= data->ana->set0;
+   ana[1] &= ~data->ana->mask1;
+   ana[1] |= data->ana->set1;
+   ana[3] &= ~data->ana->mask3;
+   ana[3] |= data->ana->set3;
+
+   if (was_using_prediv && !use_fb_prediv) {
+   ana[1] &= ~data->ana->fb_prediv_mask;
+   do_ana_setup_first = true;
+   } else if (!was_using_prediv && use_fb_prediv) {
+   ana[1] |= data->ana->fb_prediv_mask;
+   do_ana_setup_first = false;
+   } else {
+   do_ana_setup_first = true;
+   }
+
+   /* Unmask the reference clock from the oscillator. */
+   cprman_write(cprman, A2W_XOSC_CTRL,
+cprman_read(cprman, A2W_XOSC_CTRL) |
+

Re: [PATCH] ARM: bcm2835: add label for uart0

[Eric Anholt]

Stefan Wahren  writes:

> This patch adds a label for uart0 to allow changing of uart0 pins.
>
> Signed-off-by: Stefan Wahren 

This patch seems innocuous, but could you clarify for me how exactly you
change the uart0 pins, and why one would do that?


signature.asc
Description: PGP signature

Re: [PATCH v5 3/3] PCI: st: Provide support for the sti PCIe controller

[Arnd Bergmann]

On Tuesday 06 October 2015 09:56:08 Gabriel Fernandez wrote:
> +
> +/*
> + * On ARM platforms, we actually get a bus error returned when the PCIe IP
> + * returns a UR or CRS instead of an OK.
> + */
> +static int st_pcie_abort_handler(unsigned long addr, unsigned int fsr,
> +struct pt_regs *regs)
> +{
> +   return 0;
> +}
> 

I'm not sure if we discussed this already for this driver. Usually
you should have a register in the PCI host that you can check to see
what caused the abort.

Try to make this as narrow as possible so you return nonzero for
any abort except the one you actually try to prevent.

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 3/4] ARM: dts: DRA7: Add timer12 node

[Tony Lindgren]

* Felipe Balbi  [151005 17:51]:
> 
> according to Tony we should avoid using status at all for in-SoC
> devices.
> 
> Tony, can you confirm I understood you correctly ?

Yes. With status = "disabled" kernel completely ignores the
device and struct device is not created at all even with the
device being there. In general we're better off trying to
probe the device and idle it.

The only time we really want to mark something with
status = "disabled" is if some coprocessor firmware is
using that device and the kernel should not touch it at
all.

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 v5 0/3] PCI: st: provide support for dw pcie

[Gabriel Fernandez]

This patchset is based on v4.3-rc3 and is based on 
[PATCH v9 0/6] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05
patchset from Zhou Wang (to disable IO support)

Changes in v5:
 - Move wait after link training completes
 - Minor fixes in devitree binding
 - Merge  'PCI: st: Provide support for the sti PCIe controller' and
 'MAINTAINERS: Add pci-st.c to ARCH/STI architecture' patches.

Changes in v4:
 - Remove pci: designware: remove my pci_common_init_dev() patch and
use [PATCH v8 3/6] PCI: designware: Add ARM64 support instead.
This patch is a good solution for me to disable IO support.
 - add __init to st_pcie_probe() and use module_init() instead
device_initcall() to prevent the probe function from being
deferred and to prevent module unloading.

Changes in v3:
 - Remove power management functions (was not fully tested)
 - Remove configuration space range from dt binding
 - Remove pci_common_init_dev() call in pcie-designware.c to avoid 
   default IO space declaration. 

Changes in v2:
 - comestic corrections in device tree binding
 - add pci-st.c into MAINTAINERS
 - remove st_pcie_ops structure to avoid another level of indirection
 - remove nasty busy-loop
 - remove useless test using virt_to_phys()
 - move disable io support into dw-pcie driver

I don't change the st_pcie_abort_handler() function because abort handling
is masked during boot.


This patch-set introduces a STMicroelectronics PCIe controller.
It's based on designware PCIe driver.

Gabriel Fernandez (3):
  ARM: STi: Kconfig update for PCIe support
  PCI: st: Add Device Tree bindings for sti pcie
  PCI: st: Provide support for the sti PCIe controller

 Documentation/devicetree/bindings/pci/st-pcie.txt |  56 +++
 MAINTAINERS   |   1 +
 arch/arm/mach-sti/Kconfig |   2 +
 drivers/pci/host/Kconfig  |   9 +
 drivers/pci/host/Makefile |   1 +
 drivers/pci/host/pci-st.c | 587 ++
 6 files changed, 656 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/st-pcie.txt
 create mode 100644 drivers/pci/host/pci-st.c

-- 
1.9.1

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

[PATCH v5 1/3] ARM: STi: Kconfig update for PCIe support

[Gabriel Fernandez]

Update Kconfig:
- MIGHT_HAVE_PCI
- PCI_DOMAINS

Signed-off-by: Fabrice Gasnier 
---
 arch/arm/mach-sti/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-sti/Kconfig b/arch/arm/mach-sti/Kconfig
index 125865d..5f99e93 100644
--- a/arch/arm/mach-sti/Kconfig
+++ b/arch/arm/mach-sti/Kconfig
@@ -9,6 +9,8 @@ menuconfig ARCH_STI
select ARCH_HAS_RESET_CONTROLLER
select HAVE_ARM_SCU if SMP
select ARCH_REQUIRE_GPIOLIB
+   select PCI_DOMAINS if PCI
+   select MIGHT_HAVE_PCI
select ARM_ERRATA_754322
select ARM_ERRATA_764369 if SMP
select ARM_ERRATA_775420
-- 
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 RESEND] ARM: dts: Fix Makefile target for sun4i-a10-itead-iteaduino-plus

[Maxime Ripard]

On Mon, Oct 05, 2015 at 11:55:17PM +0100, Ben Hutchings wrote:
> On Sun, 2015-09-06 at 13:20 +0200, Maxime Ripard wrote:
> > On Fri, Sep 04, 2015 at 08:49:34AM -0400, Josh Boyer wrote:
> > > Commit 79ae3e66f8d (ARM: dts: sun4i: Add Iteaduino Plus A10) added a new
> > > make target for the sun4i-a10-itead-iteaduino-plus dts file, but 
> > > mistakenly
> > > used .dts instead of the correct .dtb suffix.  This resulted in a build 
> > > error
> > > like:
> > > 
> > > scripts/Makefile.dtbinst:42: target 
> > > 'sun4i-a10-itead-iteaduino-plus.dts' doesn't match the target pattern
> > > 
> > > when doing a make dtbs_install.
> > > 
> > > Fix it to use the proper file name.
> > > 
> > > Signed-off-by: Josh Boyer 
> > 
> > Queued, thanks!
> 
> This still isn't in Linus's tree; please make sure it gets to him
> before 4.3.

The pull request has been sent on sunday to arm-soc.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [RFC PATCH v6 2/3] dtc: dts source location annotation

[Frank Rowand]

On 10/5/2015 9:56 PM, David Gibson wrote:
> On Fri, Oct 02, 2015 at 09:52:48PM -0700, Frank Rowand wrote:
>> From: Frank Rowand 
>>
>> Proof of concept patch.
>>
>> Annotates input source file and line number of nodes and properties
>> as comments in output .dts file when --annotate flag is supplied.

< snip >


>> Index: b/srcpos.c
>> ===
>> --- a/srcpos.c
>> +++ b/srcpos.c
>> @@ -246,6 +246,41 @@ srcpos_copy(struct srcpos *pos)
>>  return pos_new;
>>  }
>>  
>> +struct srcpos *
>> +srcpos_copy_all(struct srcpos *pos)
>> +{
>> +struct srcpos *pos_new;
>> +struct srcfile_state *srcfile_state;
>> +
>> +if (!pos)
>> +return NULL;
>> +
>> +pos_new = srcpos_copy(pos);
>> +
>> +if (pos_new) {
>> +/* allocate without free */
>> +srcfile_state = xmalloc(sizeof(struct srcfile_state));
>> +memcpy(srcfile_state, pos->file, sizeof(struct srcfile_state));
>> +
>> +pos_new->file = srcfile_state;
>> +}
>> +
>> +return pos_new;
>> +}
> 
> You still don't need this function.  srcfile_states have unlimited
> lifetime.

My observation about this is buried in a late reply to v5, so
copying here:

   If I don't allocate a new copy of pos->file, then the file names are
   incorrect.  I'm not sure why.  I can dig into this deeper to try to
   understand what is going on if you want me to.

It sounds like I do need to debug this.

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

[PATCH v5 3/3] PCI: st: Provide support for the sti PCIe controller

[Gabriel Fernandez]

sti pcie is built around a Synopsis Designware PCIe IP.

Signed-off-by: Fabrice Gasnier 
Signed-off-by: Gabriel Fernandez 
Reviewed-by: Pratyush Anand 
---
 MAINTAINERS   |   1 +
 drivers/pci/host/Kconfig  |   9 +
 drivers/pci/host/Makefile |   1 +
 drivers/pci/host/pci-st.c | 587 ++
 4 files changed, 598 insertions(+)
 create mode 100644 drivers/pci/host/pci-st.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 9f6685f..f616ca6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1533,6 +1533,7 @@ F:drivers/i2c/busses/i2c-st.c
 F: drivers/media/rc/st_rc.c
 F: drivers/media/platform/sti/c8sectpfe/
 F: drivers/mmc/host/sdhci-st.c
+F: drivers/pci/host/pci-st.c
 F: drivers/phy/phy-miphy28lp.c
 F: drivers/phy/phy-miphy365x.c
 F: drivers/phy/phy-stih407-usb.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d5e58ba..23ab538 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -145,4 +145,13 @@ config PCIE_IPROC_BCMA
  Say Y here if you want to use the Broadcom iProc PCIe controller
  through the BCMA bus interface
 
+config PCI_ST
+   bool "ST PCIe controller"
+   depends on ARCH_STI || (ARM && COMPILE_TEST)
+   select PCIE_DW
+   help
+ Enable PCIe controller support on ST Socs. This controller is based
+ on Designware hardware and therefore the driver re-uses the
+ Designware core functions to implement the driver.
+
 endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..c4024fa 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
 obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
 obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
 obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
+obj-$(CONFIG_PCI_ST) += pci-st.o
diff --git a/drivers/pci/host/pci-st.c b/drivers/pci/host/pci-st.c
new file mode 100644
index 000..575a25b
--- /dev/null
+++ b/drivers/pci/host/pci-st.c
@@ -0,0 +1,587 @@
+/*
+ * Copyright (C) 2014 STMicroelectronics
+ *
+ * STMicroelectronics PCI express Driver for sti SoCs.
+ * ST PCIe IPs are built around a Synopsys IP Core.
+ *
+ * Author: Fabrice Gasnier 
+ *
+ * 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 
+#include 
+#include 
+#include 
+
+#include "pcie-designware.h"
+
+#define TRANSLATION_CONTROL0x900
+/* Controls if area is inclusive or exclusive */
+#define RC_PASS_ADDR_RANGE BIT(1)
+
+/* Base of area reserved for config accesses. Fixed size of 64K. */
+#define CFG_BASE_ADDRESS   0x92c
+#define CFG_REGION_SIZE65536
+#define CFG_SPACE1_OFFSET  0x1000
+
+/* First 4K of config space has this BDF (bus,device,function) */
+#define FUNC0_BDF_NUM  0x930
+
+/* Mem regions */
+#define IN0_MEM_ADDR_START 0x964
+#define IN0_MEM_ADDR_LIMIT 0x968
+#define IN1_MEM_ADDR_START 0x974
+#define IN1_MEM_ADDR_LIMIT 0x978
+
+/* This actually contains the LTSSM state machine state */
+#define PORT_LOGIC_DEBUG_REG_0 0x728
+
+/* LTSSM state machine values  */
+#define DEBUG_REG_0_LTSSM_MASK 0x1f
+#define S_DETECT_QUIET 0x00
+#define S_DETECT_ACT   0x01
+#define S_POLL_ACTIVE  0x02
+#define S_POLL_COMPLIANCE  0x03
+#define S_POLL_CONFIG  0x04
+#define S_PRE_DETECT_QUIET 0x05
+#define S_DETECT_WAIT  0x06
+#define S_CFG_LINKWD_START 0x07
+#define S_CFG_LINKWD_ACEPT 0x08
+#define S_CFG_LANENUM_WAIT 0x09
+#define S_CFG_LANENUM_ACEPT0x0A
+#define S_CFG_COMPLETE 0x0B
+#define S_CFG_IDLE 0x0C
+#define S_RCVRY_LOCK   0x0D
+#define S_RCVRY_SPEED  0x0E
+#define S_RCVRY_RCVRCFG0x0F
+#define S_RCVRY_IDLE   0x10
+#define S_L0   0x11
+#define S_L0S  0x12
+#define S_L123_SEND_EIDLE  0x13
+#define S_L1_IDLE  0x14
+#define S_L2_IDLE  0x15
+#define S_L2_WAKE  0x16
+#define S_DISABLED_ENTRY   0x17
+#define S_DISABLED_IDLE0x18
+#define S_DISABLED 0x19
+#define S_LPBK_ENTRY   0x1A
+#define S_LPBK_ACTIVE  0x1B
+#define S_LPBK_EXIT0x1C
+#define S_LPBK_EXIT_TIMEOUT

[PATCH v5 2/3] PCI: st: Add Device Tree bindings for sti pcie

[Gabriel Fernandez]

sti pcie is built around a Synopsis Designware PCIe IP.

Signed-off-by: Fabrice Gasnier 
Signed-off-by: Gabriel Fernandez 
---
 Documentation/devicetree/bindings/pci/st-pcie.txt | 56 +++
 1 file changed, 56 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/st-pcie.txt

diff --git a/Documentation/devicetree/bindings/pci/st-pcie.txt 
b/Documentation/devicetree/bindings/pci/st-pcie.txt
new file mode 100644
index 000..32e76d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/st-pcie.txt
@@ -0,0 +1,56 @@
+STMicroelectronics STi PCIe controller
+
+This PCIe host controller is based on the Synopsis Designware PCIe IP
+and thus inherits all the common properties defined in designware-pcie.txt.
+
+Required properties:
+ - compatible: Should be "st,pcie", "snps,dw-pcie"
+
+ - reg: base address and length of the pcie controller, mem-window address
+   and length available to the controller.
+
+ - interrupts: one GIC interrupt line connected to PCI MSI interrupt line
+
+ - st,syscfg : should be a phandle of the syscfg node. Also contains syscfg
+   offset for IP configuration.
+
+ - resets: phandle to the powerdown and reset controller for the PCIe IP.
+   See ../reset/reset.txt for details.
+ - reset-names: should be "powerdown" and "softreset".
+
+ - phys: the phandle for the PHY device (used by generic PHY framework).
+ - phys-names: must be "pcie".
+
+Optional properties:
+ - reset-gpio: a GPIO spec to define which pin is connected to the bus reset.
+
+Example:
+
+pcie0: pcie@9b0 {
+   compatible = "st,pcie", "snps,dw-pcie";
+   device_type = "pci";
+   reg = <0x09b0 0x4000>,  /* dbi cntrl registers */
+ <0x2fff 0x0001>,  /* configuration space */
+ <0x4000 0x8000>;  /* lmi mem window */
+   reg-names = "dbi", "config", "mem-window";
+   st,syscfg = <_core 0xd8 0xe0>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   ranges = <0x8200 0 0x2000 0x2000 0 0x0FFF>; /* 
non-prefetchable memory */
+   num-lanes = <1>;
+   interrupts = ;
+   interrupt-names = "msi";
+   #interrupt-cells = <1>;
+   interrupt-map-mask = <0 0 0 7>;
+   interrupt-map = <0 0 0 1  GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>, /* INT 
A */
+   <0 0 0 2  GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>, /* INT 
B */
+   <0 0 0 3  GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>, /* INT 
C */
+   <0 0 0 4  GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>; /* INT 
D */
+
+   resets = < STIH407_PCIE0_POWERDOWN>,
+< STIH407_PCIE0_SOFTRESET>;
+   reset-names = "powerdown",
+ "softreset";
+   phys = <_port0 PHY_TYPE_PCIE>;
+   phy-names = "pcie";
+};
-- 
1.9.1

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

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* Roger Quadros  [150930 04:04]:
> Tony,
> 
> On 18/09/15 17:53, Roger Quadros wrote:
> > Hi,
> > 
> > We do a couple of things in this series which result in
> > cleaner device tree implementation, faster perfomance and
> > multi-platform support. As an added bonus we get new GPI/Interrupt pins
> > for use in the system.
> > 
> > - Establish a custom interface between NAND and GPMC driver. This is
> > needed because all of the NAND registers sit in the GPMC register space.
> > Some bits like NAND IRQ are even shared with GPMC.
> > 
> > - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
> > with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
> > This causes performance increase when using prefetch-irq mode.
> > 30% increase in read, 17% increase in write in prefetch-irq mode.
> > 
> > - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
> > driver can be used on non-OMAP platforms. e.g. Keystone.
> > 
> > - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
> > 2 to 4 of these and most of them would be unused otherwise. It also
> > allows a cleaner implementation of NAND Ready pin status for the NAND 
> > driver.
> > 
> > - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
> > 
> > This series is available at
> > g...@github.com:rogerq/linux.git
> > in branch
> > for-v4.4/gpmc-v3

In general, very nice work :)

> I've verified this series with the following boards
> -dra7-evm
> -am437x-gp-evm
> -am335x-evm
> -beagleboard-c4
> 
> For legacy boot I've checked only on beagleboard-c4.

Great.

Does build and boot and use NAND work throughtout the series?
Otherwise we'll have hard time bisecting anything..

> Test procedure was to read an existing ubifs partition,
> create a new one and read it back.
> 
> Need you to Ack if it looks good.
> Do you mind taking it via omap-soc once MTD maintainers ack their relevant 
> parts?

Sure. I'll try to do some testing on the series first too.

Can the dts changes be merged separtely? Otherwise we'll have
a dependency between dts branch and the GPMC/NAND changes.

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] ARM: dts: Use defined GPIO constants in flags cell for OMAP2+ boards

[Javier Martinez Canillas]

Many OMAP2+ DTS are not using the defined constants to express
the GPIO polarity. Replace these so the DTS are easier to read.

Signed-off-by: Javier Martinez Canillas 

---

 arch/arm/boot/dts/omap2420-n8x0-common.dtsi|  6 +++---
 arch/arm/boot/dts/omap3-beagle-xm.dts  |  2 +-
 arch/arm/boot/dts/omap3-beagle.dts |  2 +-
 arch/arm/boot/dts/omap3-cm-t3x.dtsi|  2 +-
 arch/arm/boot/dts/omap3-devkit8000-lcd-common.dtsi |  2 +-
 arch/arm/boot/dts/omap3-evm-common.dtsi|  4 ++--
 arch/arm/boot/dts/omap3-gta04.dtsi | 10 +-
 arch/arm/boot/dts/omap3-gta04a5.dts|  2 +-
 arch/arm/boot/dts/omap3-ldp.dts|  2 +-
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi|  2 +-
 arch/arm/boot/dts/omap3-lilly-dbb056.dts   |  4 ++--
 arch/arm/boot/dts/omap3-n950-n9.dtsi   |  2 +-
 arch/arm/boot/dts/omap3-overo-base.dtsi|  2 +-
 arch/arm/boot/dts/omap3-overo-common-lcd35.dtsi|  2 +-
 arch/arm/boot/dts/omap3-overo-common-lcd43.dtsi|  2 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi|  4 ++--
 arch/arm/boot/dts/omap3-tao3530.dtsi   |  4 ++--
 arch/arm/boot/dts/omap3-zoom3.dts  |  2 +-
 arch/arm/boot/dts/omap4-panda-common.dtsi  |  4 ++--
 arch/arm/boot/dts/omap4-sdp.dts|  6 +++---
 arch/arm/boot/dts/omap4-var-som-om44-wlan.dtsi |  2 +-
 arch/arm/boot/dts/omap4-var-som-om44.dtsi  |  2 +-
 arch/arm/boot/dts/omap4460.dtsi|  2 +-
 arch/arm/boot/dts/omap5-cm-t54.dts |  2 +-
 arch/arm/boot/dts/omap5-uevm.dts   |  2 +-
 25 files changed, 38 insertions(+), 38 deletions(-)

diff --git a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi 
b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
index c9f1e93a95ae..8491f46c61b7 100644
--- a/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
+++ b/arch/arm/boot/dts/omap2420-n8x0-common.dtsi
@@ -9,9 +9,9 @@
ocp {
i2c@0 {
compatible = "i2c-cbus-gpio";
-   gpios = < 2 0 /* gpio66 clk */
- 1 0 /* gpio65 dat */
- 0 0 /* gpio64 sel */
+   gpios = < 2 GPIO_ACTIVE_HIGH /* gpio66 clk */
+ 1 GPIO_ACTIVE_HIGH /* gpio65 dat */
+ 0 GPIO_ACTIVE_HIGH /* gpio64 sel */
>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts 
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 7c4dca122a91..73f1e3a8f62c 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -80,7 +80,7 @@
regulator-name = "hsusb2_vbus";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
-   gpio = <_gpio 18 0>;/* GPIO LEDA */
+   gpio = <_gpio 18 GPIO_ACTIVE_HIGH>; /* GPIO LEDA */
startup-delay-us = <7>;
};
 
diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 67659a0ed13e..274c2c482aaa 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -55,7 +55,7 @@
regulator-name = "hsusb2_vbus";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
-   gpio = <_gpio 18 0>;/* GPIO LEDA */
+   gpio = <_gpio 18 GPIO_ACTIVE_HIGH>; /* GPIO LEDA */
startup-delay-us = <7>;
};
 
diff --git a/arch/arm/boot/dts/omap3-cm-t3x.dtsi 
b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
index 4d091ca43e25..8c813e77b17f 100644
--- a/arch/arm/boot/dts/omap3-cm-t3x.dtsi
+++ b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
@@ -224,7 +224,7 @@
 
interrupt-parent = <>;
interrupts = <25 0>;/* gpio_57 */
-   pendown-gpio = < 25 0>;
+   pendown-gpio = < 25 GPIO_ACTIVE_HIGH>;
 
ti,x-min = /bits/ 16 <0x0>;
ti,x-max = /bits/ 16 <0x0fff>;
diff --git a/arch/arm/boot/dts/omap3-devkit8000-lcd-common.dtsi 
b/arch/arm/boot/dts/omap3-devkit8000-lcd-common.dtsi
index e84184de2a4a..4813e96157b3 100644
--- a/arch/arm/boot/dts/omap3-devkit8000-lcd-common.dtsi
+++ b/arch/arm/boot/dts/omap3-devkit8000-lcd-common.dtsi
@@ -54,7 +54,7 @@
 
interrupt-parent = <>;
interrupts = <27 0>;/* gpio_27 */
-   pendown-gpio = < 27 0>;
+   pendown-gpio = < 27 GPIO_ACTIVE_HIGH>;
 
ti,x-min = /bits/ 16 <0x0>;
ti,x-max = /bits/ 16 <0x0fff>;
diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi 
b/arch/arm/boot/dts/omap3-evm-common.dtsi
index 

Re: [PATCH][RESEND] drm: panel-simple: add URT UMSH-8596MD-xT panel support

[Thierry Reding]

On Mon, Oct 05, 2015 at 05:25:33PM +0200, Maciej S. Szmigiero wrote:
> Hi Thierry,
> 
> On 05.10.2015 13:01, Thierry Reding wrote:
> >> On 01.09.2015 15:50, Maciej S. Szmigiero wrote:
> >>> This patch adds support for United Radiant Technology
> >>> UMSH-8596MD-xT 7.0" WVGA TFT LCD panels
> >>> (both LVDS and parallel versions) to DRM
> >>> panel-simple driver.
> >>>
> >>> Signed-off-by: Maciej Szmigiero 
> >>> ---
> >>> This is a resend without changes.
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt 
> >>> b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt
> >>> new file mode 100644
> >>> index 000..2990e6b
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt
> >>> @@ -0,0 +1,11 @@
> >>> +United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel
> >>> +
> >>> +Supported are LVDS versions (-11T, -19T) and parallel ones
> >>> +(-T, -1T, -7T, -20T).
> > 
> > Please don't use this kind of wildcard compatible values. If these are
> > different models then each of them deserves a separate compatible
> > string.
> 
> The differences between these revisions are like different maximum backlight
> luminance or presence / absence of touch panel.
> 
> None of this changes panel timings - should they be split into different
> compatible values anyway?

Yes, absolutely. The compatible doesn't only define what the video
timings are, it defines the specific piece of hardware. While it is true
that the panel-simple driver currently doesn't use any other information
the DT compatible value characterizes the full hardware and therefore
should take into account all of the device's properties.

Presence of a touch panel sounds like a very important property and the
maximum backlight brightness might also become important at some ponit.

> >>> You might want to
> >>> split the DT binding and vendor prefix to separate patches.
> >>
> >> Do you mean to first submit new vendor prefix then panel patch with docs?
> >> Or even docs separately?
> > 
> > This should be three patches: the vendor prefix is usually a separate
> > patch and needs an Acked-by from one of the device tree bindings
> > maintainers. The binding itself should also be a separate patch and the
> > driver changes should come last.
> 
> I will split the patch and first submit DT binding docs.

Thanks,
Thierry


signature.asc
Description: PGP signature

[PATCH v4 2/2] iio: ti-ads8688: Add DT binding documentation

[Sean Nyekjaer]

Adding binding documentation for Texas Instruments ADS8688 ADC.

Signed-off-by: Sean Nyekjaer 
Reviewed-by: Martin Hundebøll 
---
Changes since v2:
- Moved vref-supply to Optional properties

 .../devicetree/bindings/iio/adc/ti-ads8688.txt   | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/ti-ads8688.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/ti-ads8688.txt 
b/Documentation/devicetree/bindings/iio/adc/ti-ads8688.txt
new file mode 100644
index 000..a02337d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ti-ads8688.txt
@@ -0,0 +1,20 @@
+* Texas Instruments' ADS8684 and ADS8688 ADC chip
+
+Required properties:
+ - compatible: Should be "ti,ads8684" or "ti,ads8688"
+ - reg: spi chip select number for the device
+
+Recommended properties:
+ - spi-max-frequency: Definition as per
+   Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Optional properties:
+ - vref-supply: The regulator supply for ADC reference voltage
+
+Example:
+adc@0 {
+   compatible = "ti,ads8688";
+   reg = <0>;
+   vref-supply = <_supply>;
+   spi-max-frequency = <100>;
+};
-- 
2.6.0

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

[PATCH v4 1/2] iio: adc: Add TI ADS8688

[Sean Nyekjaer]

This patch adds support for the Texas Intruments ADS8688 ADC.

Signed-off-by: Sean Nyekjaer 
Reviewed-by: Martin Hundebøll 
---
Changes since v3:
- fixed multiline comments
- write_raw_get_fmt _SCALE is nano, _OFFSET is int

Changes since v2:
- Removed unused variables
- Removed unnecessary mutex lock
- Range array is a enum
- Made the read and write functions less complex and easier to read
- Added inline comments
- Added callback to write_raw_get_fmt

Changes since v1:
- Now possible to read and write the actual offset and scale values
- Removed unused includes
- Removed unused buffer references
 drivers/iio/adc/Kconfig  |  10 +
 drivers/iio/adc/Makefile |   1 +
 drivers/iio/adc/ti-ads8688.c | 472 +++
 3 files changed, 483 insertions(+)
 create mode 100644 drivers/iio/adc/ti-ads8688.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 7868c74..4135d17 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -333,6 +333,16 @@ config TI_ADC128S052
  This driver can also be built as a module. If so, the module will be
  called ti-adc128s052.
 
+config TI_ADS8688
+   tristate "Texas Instruments ADS8688"
+   depends on SPI && OF
+   help
+ If you say yes here you get support for Texas Instruments ADS8684 and
+ and ADS8688 ADC chips
+
+ This driver can also be built as a module. If so, the module will be
+ called ti-ads8688.
+
 config TI_AM335X_ADC
tristate "TI's AM335X ADC driver"
depends on MFD_TI_AM335X_TSCADC
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 99b37a9..04ab2c8 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
 obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
 obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
 obj-$(CONFIG_TI_ADC128S052) += ti-adc128s052.o
+obj-$(CONFIG_TI_ADS8688) += ti-ads8688.o
 obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
 obj-$(CONFIG_TWL4030_MADC) += twl4030-madc.o
 obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
diff --git a/drivers/iio/adc/ti-ads8688.c b/drivers/iio/adc/ti-ads8688.c
new file mode 100644
index 000..537bb0a
--- /dev/null
+++ b/drivers/iio/adc/ti-ads8688.c
@@ -0,0 +1,472 @@
+/*
+ * Copyright (C) 2015 Prevas A/S
+ *
+ * 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 
+#include 
+
+#include 
+#include 
+
+#define ADS8688_CMD_REG(x) (x << 8)
+#define ADS8688_CMD_REG_NOOP   0x00
+#define ADS8688_CMD_REG_RST0x85
+#define ADS8688_CMD_REG_MAN_CH(chan)   (0xC0 | (4 * chan))
+#define ADS8688_CMD_DONT_CARE_BITS 16
+
+#define ADS8688_PROG_REG(x)(x << 9)
+#define ADS8688_PROG_REG_RANGE_CH(chan)(0x05 + chan)
+#define ADS8688_PROG_WR_BITBIT(8)
+#define ADS8688_PROG_DONT_CARE_BITS8
+
+#define ADS8688_REG_PLUSMINUS25VREF0
+#define ADS8688_REG_PLUSMINUS125VREF   1
+#define ADS8688_REG_PLUSMINUS0625VREF  2
+#define ADS8688_REG_PLUS25VREF 5
+#define ADS8688_REG_PLUS125VREF6
+
+#define ADS8688_VREF_MV4096
+#define ADS8688_REALBITS   16
+
+/*
+ * enum ads8688_range - ADS8688 reference voltage range
+ * @ADS8688_PLUSMINUS25VREF: Device is configured for input range ±2.5 * VREF
+ * @ADS8688_PLUSMINUS125VREF: Device is configured for input range ±1.25 * VREF
+ * @ADS8688_PLUSMINUS0625VREF: Device is configured for input range ±0.625 * 
VREF
+ * @ADS8688_PLUS25VREF: Device is configured for input range 0 - 2.5 * VREF
+ * @ADS8688_PLUS125VREF: Device is configured for input range 0 - 1.25 * VREF
+ */
+enum ads8688_range {
+   ADS8688_PLUSMINUS25VREF,
+   ADS8688_PLUSMINUS125VREF,
+   ADS8688_PLUSMINUS0625VREF,
+   ADS8688_PLUS25VREF,
+   ADS8688_PLUS125VREF,
+};
+
+struct ads8688_chip_info {
+   const struct iio_chan_spec *channels;
+   unsigned int num_channels;
+};
+
+struct ads8688_state {
+   const struct ads8688_chip_info  *chip_info;
+   struct spi_device   *spi;
+   struct regulator*reg;
+   unsigned intvref_mv;
+   enum ads8688_range  range[8];
+   union {
+   __be32 d32;
+   u8 d8[4];
+   } data[2] cacheline_aligned;
+};
+
+enum ads8688_id {
+   ID_ADS8684,
+   ID_ADS8688,
+};
+
+struct ads8688_ranges {
+   enum ads8688_range range;
+   unsigned int scale;
+   int offset;
+   u8 reg;
+};
+
+static const struct ads8688_ranges ads8688_range_def[5] = {
+   {
+   .range = ADS8688_PLUSMINUS25VREF,
+   .scale = 

Re: [PATCH v3 2/4] drivers: clk: st: PLL rate change implementation for DVFS

[Stephen Boyd]

On 10/05, Gabriel Fernandez wrote:
> @@ -452,7 +651,7 @@ static const struct clk_ops st_pll1200c32_ops = {
>  static struct clk * __init clkgen_pll_register(const char *parent_name,
>   struct clkgen_pll_data  *pll_data,
>   void __iomem *reg,
> - const char *clk_name)
> + const char *clk_name, spinlock_t *lock)

Is there a reason we pass lock here but never use it in this
function?

>  {
>   struct clkgen_pll *pll;
>   struct clk *clk;

-- 
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 0/2] pwm: Broadcom BCM7038 PWM controller (v4)

[Florian Fainelli]

On 06/10/15 11:14, Florian Fainelli wrote:
> On 05/10/15 08:14, Thierry Reding wrote:
>> On Mon, Sep 14, 2015 at 04:47:04PM -0700, Florian Fainelli wrote:
>>> Hi,
>>>
>>> This patch series add PWM support for the Broadcom BCM7xxx
>>> chips which feature one or more PWM controllers capable of
>>> output periods from 148ns to ~622ms using a combination of
>>> variable and fixed frequency settings.
>>>
>>> The controller does not support setting a polarity.
>>>
>>> This is based on Thierry's pwm/next branch.
>>>
>>> Florian Fainelli (2):
>>>   Documentation: dt: add Broadcom BCM7038 PWM controller binding
>>>   pwm: Add Broadcom BCM7038 PWM controller support
>>
>> I've applied both of these patches with a couple of stylistic changes.
> 
> Thanks but:
> 
> 1) you dropped the MODULE_DEVICE_TABLE while doing so which is useful
> for auto-loading OF modules
> 2) you introduced a build failure in the CONFIG_PM_SLEEP
> 
> There was a patch just submitted for 2), but I can submit an incremental
> for 1) maybe?

Disregard that, brainfart on my side, was diffing branches backwards...
oh well.
-- 
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

[PATCH v3 5/5] net: phy: bcm7xxx: Modified to use global core register defines

[Arun Parameswaran]

Modified the bcm7xxx phy driver to remove local core register
defines and use the common ones from "include/linux/brcmphy.h"

Signed-off-by: Arun Parameswaran 
---
 drivers/net/phy/bcm7xxx.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/net/phy/bcm7xxx.c b/drivers/net/phy/bcm7xxx.c
index efa31a6..03d4809 100644
--- a/drivers/net/phy/bcm7xxx.c
+++ b/drivers/net/phy/bcm7xxx.c
@@ -25,7 +25,6 @@
 #define MII_BCM7XXX_100TX_DISC 0x14
 #define MII_BCM7XXX_AUX_MODE   0x1d
 #define  MII_BCM7XX_64CLK_MDIO BIT(12)
-#define MII_BCM7XXX_CORE_BASE1E0x1e
 #define MII_BCM7XXX_TEST   0x1f
 #define  MII_BCM7XXX_SHD_MODE_2BIT(2)
 
@@ -46,8 +45,6 @@
 #define AFE_VDAC_OTHERS_0  MISC_ADDR(0x39, 3)
 #define AFE_HPF_TRIM_OTHERSMISC_ADDR(0x3a, 0)
 
-#define CORE_EXPB0 0xb0
-
 static void r_rc_cal_reset(struct phy_device *phydev)
 {
/* Reset R_CAL/RC_CAL Engine */
@@ -76,7 +73,7 @@ static int bcm7xxx_28nm_b0_afe_config_init(struct phy_device 
*phydev)
bcm_phy_write_misc(phydev, DSP_TAP10, 0x690b);
 
/* Switch to CORE_BASE1E */
-   phy_write(phydev, MII_BCM7XXX_CORE_BASE1E, 0xd);
+   phy_write(phydev, MII_BRCM_CORE_BASE1E, 0xd);
 
r_rc_cal_reset(phydev);
 
@@ -127,7 +124,7 @@ static int bcm7xxx_28nm_d0_afe_config_init(struct 
phy_device *phydev)
bcm_phy_write_misc(phydev, AFE_HPF_TRIM_OTHERS, 0x00e3);
 
/* CORE_BASE1E, force trim to overwrite and set I_ext trim to  */
-   phy_write(phydev, MII_BCM7XXX_CORE_BASE1E, 0x0010);
+   phy_write(phydev, MII_BRCM_CORE_BASE1E, 0x0010);
 
/* DSP_TAP10, adjust bias current trim (+0% swing, +0 tick) */
bcm_phy_write_misc(phydev, DSP_TAP10, 0x011b);
@@ -155,7 +152,7 @@ static int bcm7xxx_28nm_e0_plus_afe_config_init(struct 
phy_device *phydev)
bcm_phy_write_misc(phydev, AFE_HPF_TRIM_OTHERS, 0x00e3);
 
/* CORE_BASE1E, force trim to overwrite and set I_ext trim to  */
-   phy_write(phydev, MII_BCM7XXX_CORE_BASE1E, 0x0010);
+   phy_write(phydev, MII_BRCM_CORE_BASE1E, 0x0010);
 
/* DSP_TAP10, adjust bias current trim (+0% swing, +0 tick) */
bcm_phy_write_misc(phydev, DSP_TAP10, 0x011b);
-- 
2.5.2

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

[PATCH v3 4/5] net: phy: Broadcom Cygnus internal Etherent PHY driver

[Arun Parameswaran]

Add support for the Broadcom Cygnus SoCs internal PHY's.
The PHYs are 1000M/100M/10M capable with support for 'EEE'
and 'APD' (Auto Power Down).

This driver supports the following Broadcom Cygnus SoCs:
 - BCM583XX (BCM58300, BCM58302, BCM58303, BCM58305)
 - BCM113XX (BCM11300, BCM11320, BCM11350, BCM11360)

The PHY's on these SoC's require some workarounds for
stable operation, both during configuration time and
during suspend/resume. This driver handles the
application of the workarounds.

Signed-off-by: Arun Parameswaran 
---
 drivers/net/phy/Kconfig  |  13 
 drivers/net/phy/Makefile |   1 +
 drivers/net/phy/bcm-cygnus.c | 158 +++
 include/linux/brcmphy.h  |   7 ++
 4 files changed, 179 insertions(+)
 create mode 100644 drivers/net/phy/bcm-cygnus.c

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 606fdc9..9d097ae 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -79,6 +79,19 @@ config BROADCOM_PHY
  Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S, BCM5464,
  BCM5481 and BCM5482 PHYs.
 
+config BCM_CYGNUS_PHY
+   tristate "Drivers for Broadcom Cygnus SoC internal PHY"
+   depends on ARCH_BCM_CYGNUS || COMPILE_TEST
+   depends on MDIO_BCM_IPROC
+   select BCM_NET_PHYLIB
+   ---help---
+ This PHY driver is for the 1G internal PHYs of the Broadcom
+ Cygnus Family SoC.
+
+ Currently supports internal PHY's used in the BCM11300,
+ BCM11320, BCM11350, BCM11360, BCM58300, BCM58302,
+ BCM58303 & BCM58305 Broadcom Cygnus SoCs.
+
 config BCM63XX_PHY
tristate "Drivers for Broadcom 63xx SOCs internal PHY"
depends on BCM63XX
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 6932475..7655d47 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_BROADCOM_PHY)+= broadcom.o
 obj-$(CONFIG_BCM63XX_PHY)  += bcm63xx.o
 obj-$(CONFIG_BCM7XXX_PHY)  += bcm7xxx.o
 obj-$(CONFIG_BCM87XX_PHY)  += bcm87xx.o
+obj-$(CONFIG_BCM_CYGNUS_PHY)   += bcm-cygnus.o
 obj-$(CONFIG_ICPLUS_PHY)   += icplus.o
 obj-$(CONFIG_REALTEK_PHY)  += realtek.o
 obj-$(CONFIG_LSI_ET1011C_PHY)  += et1011c.o
diff --git a/drivers/net/phy/bcm-cygnus.c b/drivers/net/phy/bcm-cygnus.c
new file mode 100644
index 000..49bbc68
--- /dev/null
+++ b/drivers/net/phy/bcm-cygnus.c
@@ -0,0 +1,158 @@
+/*
+ * 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.
+ */
+
+/* Broadcom Cygnus SoC internal transceivers support. */
+#include "bcm-phy-lib.h"
+#include 
+#include 
+#include 
+#include 
+
+/* Broadcom Cygnus Phy specific registers */
+#define MII_BCM_CYGNUS_AFE_VDAC_ICTRL_0  0x91E5 /* VDAL Control register */
+
+static int bcm_cygnus_afe_config(struct phy_device *phydev)
+{
+   int rc;
+
+   /* ensure smdspclk is enabled */
+   rc = phy_write(phydev, MII_BCM54XX_AUX_CTL, 0x0c30);
+   if (rc < 0)
+   return rc;
+
+   /* AFE_VDAC_ICTRL_0 bit 7:4 Iq=1100 for 1g 10bt, normal modes */
+   rc = bcm_phy_write_misc(phydev, 0x39, 0x01, 0xA7C8);
+   if (rc < 0)
+   return rc;
+
+   /* AFE_HPF_TRIM_OTHERS bit11=1, short cascode enable for all modes*/
+   rc = bcm_phy_write_misc(phydev, 0x3A, 0x00, 0x0803);
+   if (rc < 0)
+   return rc;
+
+   /* AFE_TX_CONFIG_1 bit 7:4 Iq=1100 for test modes */
+   rc = bcm_phy_write_misc(phydev, 0x3A, 0x01, 0xA740);
+   if (rc < 0)
+   return rc;
+
+   /* AFE TEMPSEN_OTHERS rcal_HT, rcal_LT 1 */
+   rc = bcm_phy_write_misc(phydev, 0x3A, 0x03, 0x8400);
+   if (rc < 0)
+   return rc;
+
+   /* AFE_FUTURE_RSV bit 2:0 rccal <2:0>=100 */
+   rc = bcm_phy_write_misc(phydev, 0x3B, 0x00, 0x0004);
+   if (rc < 0)
+   return rc;
+
+   /* Adjust bias current trim to overcome digital offSet */
+   rc = phy_write(phydev, MII_BRCM_CORE_BASE1E, 0x02);
+   if (rc < 0)
+   return rc;
+
+   /* make rcal=100, since rdb default is 000 */
+   rc = bcm_phy_write_exp(phydev, MII_BRCM_CORE_EXPB1, 0x10);
+   if (rc < 0)
+   return rc;
+
+   /* CORE_EXPB0, Reset R_CAL/RC_CAL Engine */
+   rc = bcm_phy_write_exp(phydev, MII_BRCM_CORE_EXPB0, 0x10);
+   if (rc < 0)
+   return rc;
+
+   /* CORE_EXPB0, Disable Reset R_CAL/RC_CAL Engine */
+   rc = bcm_phy_write_exp(phydev, MII_BRCM_CORE_EXPB0, 0x00);
+
+   

Re: [PATCH v2] video: fbdev: add Marvell PXA framebuffer binding

[Robert Jarzmik]

Philipp Zabel  writes:

> On Sun, Oct 4, 2015 at 12:31 PM, Robert Jarzmik  
> wrote:
>> +   lcd-controller@4050 {
>> +   compatible = "marvell,pxa2xx-lcdc";
>> +   reg = <0x4400 0x1>;
>> +   interrupts = <17>;
>> +   clocks = < CLK_LCD>;
>> +   interrupts = <23>;
>
> The interrupt line is duplicated in the example.
Indeed, I'll fix that.
>
>> +   status = "okay";
>> +
>> +   port {
>> +   lcdc_out: endpoint {
>> +   remote-endpoint = <_in>;
>> +   bus-width = <16>;
>> +   };
>> +   };
>> +   };
>> +
>> +PXA LCDC Display
>> +
>> +Required properties (as per of_videomode_helper):
>> + - lcd-type: either "mono-stn", "mono-dstn", "color-stn", "color-dstn",
>> +   "color-tft", "smart-panel"
>
> Would it make sense to make this property optional and have the
> default be "color-tft"? That is probably the most common one by far.
Yes, sure, let's do it that way for v3.

Cheers.

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

Re: [PATCH] ARM: bcm2835: add label for uart0

[Stephen Warren]

On 10/06/2015 03:53 PM, Eric Anholt wrote:
> Stefan Wahren  writes:
> 
>> This patch adds a label for uart0 to allow changing of uart0
>> pins.
>> 
>> Signed-off-by: Stefan Wahren 
> 
> This patch seems innocuous, but could you clarify for me how
> exactly you change the uart0 pins, and why one would do that?

I /assume/ this is so that some other DT file (that includes the
edited file) can add some pinctrl-related properties to this DT node,
using syntax such as:

 {
new content;
};

If so, the patch,
Acked-by: Stephen Warren 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFT 1/3] dt-bindings: usb: usb5303: Document new 'phys' property

[Krzysztof Kozlowski]

Document new 'phys' and 'phys-names' properties.

Signed-off-by: Krzysztof Kozlowski 
Cc: Kevin Hilman 
Cc: Arnd Bergmann 
Cc: riku.voi...@linaro.org
Cc: Marek Szyprowski 
---
 Documentation/devicetree/bindings/usb/usb3503.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt 
b/Documentation/devicetree/bindings/usb/usb3503.txt
index 52493b1480e2..773c8d722c13 100644
--- a/Documentation/devicetree/bindings/usb/usb3503.txt
+++ b/Documentation/devicetree/bindings/usb/usb3503.txt
@@ -15,6 +15,8 @@ Optional properties:
 - reset-gpios: Should specify GPIO for reset.
 - initial-mode: Should specify initial mode.
 (1 for HUB mode, 2 for STANDBY mode)
+- phys: One PHY specifier (refer to generic PHY bindings).
+- phy-names: If 'phys' is present, then it must be 'usb2-phy'.
 - refclk: Clock used for driving REFCLK signal (optional, if not provided
the driver assumes that clock signal is always available, its
rate is specified by REF_SEL pins and a value from the primary
@@ -33,4 +35,6 @@ Examples:
intn-gpios = < 4 1>;
reset-gpios = < 5 1>;
initial-mode = <1>;
+   phys = <_phy_gen 3>;
+   phy-names = "usb2-phy";
};
-- 
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

[RFT 0/3] usb: usb3503: Fix probing on Arndale board (missing phy)

[Krzysztof Kozlowski]

Hi,


Introduction

This patchset tries to fix probing of usb3503 on Arndale board
if the Samsung PHY driver is probed later (or built as a module).

*The patchset was not tested on Arndale board.*
I don't have that board. Please test it and say if the usb3503 deferred probe
works fine and the issue is solved.

The patchset was tested on Odroid U3 board (which is different!)
in a simulated environment. It is not sufficient testing.


Difference
==
The usb3503 device driver can be used as a I2C device (on Odroid U3)
or as a platform device connected through phy (on Arndale). In the second
case the necessary phy reference has to be obtained and enabled.

For some details please look also at thread [0][1].

[0] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348524.html
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348875.html


Best regards,
Krzysztof


Krzysztof Kozlowski (3):
  dt-bindings: usb: usb5303: Document new 'phys' property
  usb: misc: usb3503: Allow usage of device through phy interface
  ARM: dts: Fix usb3503 probe by enabling phy on exynos5250-arndale

 Documentation/devicetree/bindings/usb/usb3503.txt |  4 ++
 arch/arm/boot/dts/exynos5250-arndale.dts  |  2 +
 drivers/usb/misc/usb3503.c| 65 +++
 3 files changed, 71 insertions(+)

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

[RFT 2/3] usb: misc: usb3503: Allow usage of device through phy interface

[Krzysztof Kozlowski]

The USB3503 hub controller can be connected through I2C interface (e.g.
on Odroid-U3 board) or directly by phy (e.g. on Arndale board). Thus the
usb3503 driver can act as a i2c or platform device.

In the second configuration (phy) the driver did not get a reference to
necessary phy to use it. This lead to probe failure if PHY driver was
probed after usb3503 probe.

The patch adds support for generic phy framework so the driver will the
phy reference (if provided) and use it.

Signed-off-by: Krzysztof Kozlowski 
Reported-by: Kevin Hilman 
Reported-by: Arnd Bergmann 
Cc: Kevin Hilman 
Cc: Arnd Bergmann 
Cc: riku.voi...@linaro.org
Cc: Marek Szyprowski 
---
 drivers/usb/misc/usb3503.c | 65 ++
 1 file changed, 65 insertions(+)

diff --git a/drivers/usb/misc/usb3503.c b/drivers/usb/misc/usb3503.c
index 64ff5b91752d..e9423fc28105 100644
--- a/drivers/usb/misc/usb3503.c
+++ b/drivers/usb/misc/usb3503.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define USB3503_VIDL   0x00
@@ -59,6 +60,7 @@ struct usb3503 {
struct regmap   *regmap;
struct device   *dev;
struct clk  *clk;
+   struct phy  *phy;
u8  port_off_mask;
int gpio_intn;
int gpio_reset;
@@ -66,6 +68,29 @@ struct usb3503 {
boolsecondary_ref_clk;
 };
 
+static int usb3503_phy_on(struct usb3503 *hub)
+{
+   int err;
+
+   err = phy_power_on(hub->phy);
+   if (err)
+   return err;
+
+   err = phy_init(hub->phy);
+   if (err) {
+   phy_power_off(hub->phy);
+   return err;
+   }
+
+   return 0;
+}
+
+static void usb3503_phy_off(struct usb3503 *hub)
+{
+   phy_exit(hub->phy);
+   phy_power_off(hub->phy);
+}
+
 static int usb3503_reset(struct usb3503 *hub, int state)
 {
if (!state && gpio_is_valid(hub->gpio_connect))
@@ -189,6 +214,13 @@ static int usb3503_probe(struct usb3503 *hub)
u32 rate = 0;
hub->port_off_mask = 0;
 
+   hub->phy = devm_phy_optional_get(dev, "usb2-phy");
+   if (IS_ERR(hub->phy)) {
+   err = PTR_ERR(hub->phy);
+   if (err != -EPROBE_DEFER)
+   dev_err(dev, "unable to get phy: %d\n", err);
+   return err;
+   }
if (!of_property_read_u32(np, "refclk-frequency", )) {
switch (rate) {
case 3840:
@@ -300,6 +332,10 @@ static int usb3503_probe(struct usb3503 *hub)
}
}
 
+   err = usb3503_phy_on(hub);
+   if (err)
+   return err;
+
usb3503_switch_mode(hub, hub->mode);
 
dev_info(dev, "%s: probed in %s mode\n", __func__,
@@ -339,9 +375,29 @@ static int usb3503_platform_probe(struct platform_device 
*pdev)
return -ENOMEM;
hub->dev = >dev;
 
+   platform_set_drvdata(pdev, hub);
+
return usb3503_probe(hub);
 }
 
+static int usb3503_i2c_remove(struct i2c_client *i2c)
+{
+   struct usb3503 *hub = i2c_get_clientdata(i2c);
+
+   usb3503_phy_off(hub);
+
+   return 0;
+}
+
+static int usb3503_platform_remove(struct platform_device *pdev)
+{
+   struct usb3503 *hub = platform_get_drvdata(pdev);
+
+   usb3503_phy_off(hub);
+
+   return 0;
+}
+
 #ifdef CONFIG_PM_SLEEP
 static int usb3503_i2c_suspend(struct device *dev)
 {
@@ -350,6 +406,8 @@ static int usb3503_i2c_suspend(struct device *dev)
 
usb3503_switch_mode(hub, USB3503_MODE_STANDBY);
 
+   usb3503_phy_off(hub);
+
if (hub->clk)
clk_disable_unprepare(hub->clk);
 
@@ -360,10 +418,15 @@ static int usb3503_i2c_resume(struct device *dev)
 {
struct i2c_client *client = to_i2c_client(dev);
struct usb3503 *hub = i2c_get_clientdata(client);
+   int err;
 
if (hub->clk)
clk_prepare_enable(hub->clk);
 
+   err = usb3503_phy_on(hub);
+   if (err)
+   return err;
+
usb3503_switch_mode(hub, hub->mode);
 
return 0;
@@ -395,6 +458,7 @@ static struct i2c_driver usb3503_i2c_driver = {
.of_match_table = of_match_ptr(usb3503_of_match),
},
.probe  = usb3503_i2c_probe,
+   .remove = usb3503_i2c_remove,
.id_table   = usb3503_id,
 };
 
@@ -404,6 +468,7 @@ static struct platform_driver usb3503_platform_driver = {
.of_match_table = of_match_ptr(usb3503_of_match),
},
.probe  = usb3503_platform_probe,
+   .remove = usb3503_platform_remove,
 };
 
 static int __init usb3503_init(void)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body 

[RFT 3/3] ARM: dts: Fix usb3503 probe by enabling phy on exynos5250-arndale

[Krzysztof Kozlowski]

On Arndale board (unlike Odroid U3) the USB3503 hub controller is
connected in phy mode (not through I2C). For successful probe it needs
to get reference to proper phy and enable it.

Signed-off-by: Krzysztof Kozlowski 
Reported-by: Kevin Hilman 
Reported-by: Arnd Bergmann 
Cc: Kevin Hilman 
Cc: Arnd Bergmann 
Cc: riku.voi...@linaro.org
Cc: Marek Szyprowski 
---
 arch/arm/boot/dts/exynos5250-arndale.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index c000532c1444..e213f31acbf3 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -114,6 +114,8 @@
 
reset-gpios = < 5 GPIO_ACTIVE_LOW>;
connect-gpios = < 7 GPIO_ACTIVE_LOW>;
+   phys = <_phy_gen 3>;
+   phy-names = "usb2-phy";
};
 };
 
-- 
1.9.1

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

[PATCH v2 2/3] mfd: dt-bindings: Document pulled down WRSTBI pin on S2MPS1X

[Krzysztof Kozlowski]

Document a new Device Tree property 'samsung,s2mps11-wrstbi-ground'
indicating that WRSTBI pin of S2MPS13 PMIC is pulled down so
corresponding buck warm reset function should be disabled.

Signed-off-by: Krzysztof Kozlowski 

---

Changs since v1:
None.
---
 Documentation/devicetree/bindings/mfd/s2mps11.txt | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index 90eaef393325..890f0b0e1643 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -19,6 +19,9 @@ Optional properties:
   connected to the ground so the PMIC must manually set PWRHOLD bit in CTRL1
   register to turn off the power. Usually the ACOKB is pulled up to VBATT so
   when PWRHOLD pin goes low, the rising ACOKB will trigger power off.
+- samsung,s2mps11-wrstbi-ground: Indicates that WRSTBI pin of PMIC is pulled
+  down. When the system is suspended it will always go down thus triggerring
+  unwanted buck warm reset (setting buck voltages to default values).
 
 Optional nodes:
 - clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 32.768
-- 
1.9.1

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

[PATCH v2 1/3] mfd: sec-core: Dump PMIC revision to find out the HW

[Krzysztof Kozlowski]

There are different revisions of the same chipset. For example S2MPS13 has
more than 2 revisions. They differ slightly in regulator constraints.
Print the revision number to easily find which PMIC is used on the board.

Signed-off-by: Krzysztof Kozlowski 

---

Changs since v1:
None.
---
 drivers/mfd/sec-core.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
index 2d1137a7a0ee..589e5efc2d7f 100644
--- a/drivers/mfd/sec-core.c
+++ b/drivers/mfd/sec-core.c
@@ -253,6 +253,15 @@ static const struct regmap_config s5m8767_regmap_config = {
.cache_type = REGCACHE_FLAT,
 };
 
+static void sec_pmic_dump_rev(struct sec_pmic_dev *sec_pmic)
+{
+   unsigned int val;
+
+   /* For each device type, the REG_ID is always the first register */
+   if (!regmap_read(sec_pmic->regmap_pmic, S2MPS11_REG_ID, ))
+   dev_dbg(sec_pmic->dev, "Revision: 0x%x\n", val);
+}
+
 #ifdef CONFIG_OF
 /*
  * Only the common platform data elements for s5m8767 are parsed here from the
@@ -425,6 +434,7 @@ static int sec_pmic_probe(struct i2c_client *i2c,
goto err_mfd;
 
device_init_wakeup(sec_pmic->dev, sec_pmic->wakeup);
+   sec_pmic_dump_rev(sec_pmic);
 
return ret;
 
-- 
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] pwm: fix Broadcom BCM7038 PWM driver

[Florian Fainelli]

On 06/10/15 12:59, Arnd Bergmann wrote:
> The newly added pwm-brcmstb driver fails to build if CONFIG_PM_SLEEP
> is enabled:
> 
> drivers/pwm/pwm-brcmstb.c: In function 'brcmstb_pwm_suspend':
> drivers/pwm/pwm-brcmstb.c:309:42: error: 'dev' undeclared (first use in this 
> function)
>   struct brcmstb_pwm *p = dev_get_drvdata(dev);
> 
> This changes the name of the function argument to match its user.

Thanks, maybe, to avoid similar issues in the future, we should start
removing the ifdef CONFIG_PM_SLEEP and instead annotate such functions
with __maybe_unused. I wonder if we could magically make that happen
with a coccinelle script that looks for SIMPLE_DEV_PM_OPS to know which
functions to annotate... humm.

> 
> Signed-off-by: Arnd Bergmann 
> ---
> On Monday 05 October 2015 17:14:15 Thierry Reding wrote:
>> On Mon, Sep 14, 2015 at 04:47:04PM -0700, Florian Fainelli wrote:
>>> Florian Fainelli (2):
>>>   Documentation: dt: add Broadcom BCM7038 PWM controller binding
>>>   pwm: Add Broadcom BCM7038 PWM controller support
>>
>> I've applied both of these patches with a couple of stylistic changes.
> 
> As in the pwm-berlin driver, one of the fixups was broken.
> 
> diff --git a/drivers/pwm/pwm-brcmstb.c b/drivers/pwm/pwm-brcmstb.c
> index 083e3ef5b8e5..423ce087cd9c 100644
> --- a/drivers/pwm/pwm-brcmstb.c
> +++ b/drivers/pwm/pwm-brcmstb.c
> @@ -304,7 +304,7 @@ static int brcmstb_pwm_remove(struct platform_device 
> *pdev)
>  }
>  
>  #ifdef CONFIG_PM_SLEEP
> -static int brcmstb_pwm_suspend(struct device *d)
> +static int brcmstb_pwm_suspend(struct device *dev)
>  {
>   struct brcmstb_pwm *p = dev_get_drvdata(dev);
>  
> @@ -313,7 +313,7 @@ static int brcmstb_pwm_suspend(struct device *d)
>   return 0;
>  }
>  
> -static int brcmstb_pwm_resume(struct device *d)
> +static int brcmstb_pwm_resume(struct device *dev)
>  {
>   struct brcmstb_pwm *p = dev_get_drvdata(dev);
>  
> 


-- 
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] clk: bcm2835: Add support for programming the audio domain clocks.

[Eric Anholt]

Stefan Wahren  writes:

> Hi Eric,
>
> Am 02.10.2015 um 21:54 schrieb Eric Anholt:
>> This adds support for enabling, disabling, and setting the rate of the
>> audio domain clocks.  It will be necessary for setting the pixel clock
>> for HDMI in the VC4 driver and let us write a cpufreq driver.  It will
>> also improve compatibility with user changes to the firmware's
>> config.txt, since our previous fixed clocks are unaware of it.
>>
>> The firmware also has support for configuring the clocks through the
>> mailbox channel, but the pixel clock setup by the firmware doesn't
>> work, and it's Raspberry Pi specific anyway.  The only conflicts we
>> should have with the firmware would be if we made firmware calls that
>> result in clock management (like opening firmware V3D or ISP access,
>> which we don't support in upstream), or on hardware over-thermal or
>> under-voltage (when the firmware would rewrite PLLB to take the ARM
>> out of overclock).  If that happens, our cached .recalc_rate() results
>> would be incorrect, but that's no worse than our current state where
>> we used fixed clocks.
>>
>> The existing fixed clocks in the code are left in place to provide
>> backwards compatibility with old device tree files.
>
> only a few nits.

I think I've done all of these now, sending out v5.


signature.asc
Description: PGP signature

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 06/10/15 11:33, Tony Lindgren wrote:
> * Roger Quadros  [150930 04:04]:
>> Tony,
>>
>> On 18/09/15 17:53, Roger Quadros wrote:
>>> Hi,
>>>
>>> We do a couple of things in this series which result in
>>> cleaner device tree implementation, faster perfomance and
>>> multi-platform support. As an added bonus we get new GPI/Interrupt pins
>>> for use in the system.
>>>
>>> - Establish a custom interface between NAND and GPMC driver. This is
>>> needed because all of the NAND registers sit in the GPMC register space.
>>> Some bits like NAND IRQ are even shared with GPMC.
>>>
>>> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
>>> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
>>> This causes performance increase when using prefetch-irq mode.
>>> 30% increase in read, 17% increase in write in prefetch-irq mode.
>>>
>>> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
>>> driver can be used on non-OMAP platforms. e.g. Keystone.
>>>
>>> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
>>> 2 to 4 of these and most of them would be unused otherwise. It also
>>> allows a cleaner implementation of NAND Ready pin status for the NAND 
>>> driver.
>>>
>>> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
>>>
>>> This series is available at
>>> g...@github.com:rogerq/linux.git
>>> in branch
>>> for-v4.4/gpmc-v3
> 
> In general, very nice work :)

Thanks :)

> 
>> I've verified this series with the following boards
>> -dra7-evm
>> -am437x-gp-evm
>> -am335x-evm
>> -beagleboard-c4
>>
>> For legacy boot I've checked only on beagleboard-c4.
> 
> Great.
> 
> Does build and boot and use NAND work throughtout the series?
> Otherwise we'll have hard time bisecting anything..

Yes it does with the following exceptions.

- Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq mode
but none of the boards seem to be using it so it shouldn't break NAND on 
existing boards.
At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode is 
working again.
Do you want me to squash patches 7,8,9 so that pre-fetch irq is not broken at 
any point?

- Then at patch 11 "mtd: nand: omap: Clean up device tree support" we break 
NAND on all DT
boards as we expect NAND to be a real child node with compatible id. Simply 
applying the
DT patch at this point makes it work again.

> 
>> Test procedure was to read an existing ubifs partition,
>> create a new one and read it back.
>>
>> Need you to Ack if it looks good.
>> Do you mind taking it via omap-soc once MTD maintainers ack their relevant 
>> parts?
> 
> Sure. I'll try to do some testing on the series first too.
> 
Thanks.

> Can the dts changes be merged separtely? Otherwise we'll have
> a dependency between dts branch and the GPMC/NAND changes.

I'm afraid no. Patch 11 makes us incompatible with the old DT.

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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* Roger Quadros  [151006 02:59]:
> On 06/10/15 11:33, Tony Lindgren wrote:
> > Does build and boot and use NAND work throughtout the series?
> > Otherwise we'll have hard time bisecting anything..
> 
> Yes it does with the following exceptions.
> 
> - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq mode
> but none of the boards seem to be using it so it shouldn't break NAND on 
> existing boards.
> At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode is 
> working again.
> Do you want me to squash patches 7,8,9 so that pre-fetch irq is not broken at 
> any point?

OK, no that's fine, no need to squash them together then.

> - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we break 
> NAND on all DT
> boards as we expect NAND to be a real child node with compatible id. Simply 
> applying the
> DT patch at this point makes it work again.

Hmm can we at least warn about incompatible DT entry when somebody boots
with an older dtb?

> >> Test procedure was to read an existing ubifs partition,
> >> create a new one and read it back.
> >>
> >> Need you to Ack if it looks good.
> >> Do you mind taking it via omap-soc once MTD maintainers ack their relevant 
> >> parts?
> > 
> > Sure. I'll try to do some testing on the series first too.
> > 
> Thanks.
> 
> > Can the dts changes be merged separtely? Otherwise we'll have
> > a dependency between dts branch and the GPMC/NAND changes.
> 
> I'm afraid no. Patch 11 makes us incompatible with the old DT.

OK. If we can warn about that, then the out of tree users will
have easier time to update their dts file.

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: [RFC PATCH v3 1/3] mmc: sprd: Add MMC host driver for Spreadtrum SoC

[Ulf Hansson]

+Russell

On 28 September 2015 at 09:18, Hongtao Wu  wrote:
>>>
>
> On Thu, Sep 10, 2015 at 9:28 PM, Ulf Hansson  wrote:
>>
>> On 14 August 2015 at 18:55, Hongtao Wu  wrote:
>> > the Spreadtrum MMC host driver is used to supply EMMC, SD, and
>> > SDIO types of memory cards
>>
>> Perhaps some more information about the controller. Are there any
>> specific features it support or doesn't support!?
>
> Thanks for kindly reply.
> Yes, spreadtrum MMC host controllers have some specific features as follows:
> (1) We don't have controls for sampling clock tuning and re-tuning, we take
>   place of them with three registers as follows:
>(a) CLK_WR_DL(Offset 080h): Data write clock delay line.
>(b) CLK_RD_POS_DL(Offset 0x84h): Posedge data read clock delay line.
>(c) CLK_RD_NEG_DL(Offset 088h): Negedge data read clock delay line.
>
> (2) We don't have Power Control Register(Offset 029h), all our controller's
> power
>   come from PMIC, rather than directly from CPU.
>
> (3) We don't have bit[6](Card Insertion), bit[7] (Card Removal), bit[8]
> (Card Interrupt)
> and bit[12:9] in Normal Interrupt Status Register(Offset 030h). Because the
> detect
> gpio pin doesn't connect to the register of our host controller. So we can't
> operate bit[18:16](Card Detect Pin Level, Card State stable and Card
> Inserted)
> in Present State Register(Offset 024h).

Thanks for clarifying!

You have some differences towards the "standard" sdhci variant, but
that doesn't mean you should go off and implement a new driver from
scratch, instead you should create a new sdhci variant and re-use code
from the generic sdhci driver.

The current problem with such approach, is that the sdhci driver isn't
designed as a library but instead a driver consisting of too many
quirks and callbacks. While you start to adopt your driver towards
sdhci, you will need to add yet another bunch of new quirks and
callbacks to suite your hw.

Now, as the number of callbacks and quirks continues to increase I
will sooner or later give up maintaining it, as each line of code will
depend on a quirk. So, we need to start turning sdhci into a library
*right now*! Russell King, has pointed out this several times as well,
but unfortunate I haven't yet seen anyone willing to help out in this
field.

I would of course be very happy if you would like to have a look at
that, but I realize it's a difficult task, So, unless you are happy
with taking on such a challenge, I suggest you go for an intermediate
step, which thus means convert your driver to a sdhci variant driver
and add the quirks/callbacks you need to suite your hw.

[...]

Kind regards
Uffe
--
To unsubscribe from this list: send the line "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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 06/10/15 13:00, Tony Lindgren wrote:
> * Roger Quadros  [151006 02:59]:
>> On 06/10/15 11:33, Tony Lindgren wrote:
>>> Does build and boot and use NAND work throughtout the series?
>>> Otherwise we'll have hard time bisecting anything..
>>
>> Yes it does with the following exceptions.
>>
>> - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq mode
>> but none of the boards seem to be using it so it shouldn't break NAND on 
>> existing boards.
>> At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode is 
>> working again.
>> Do you want me to squash patches 7,8,9 so that pre-fetch irq is not broken 
>> at any point?
> 
> OK, no that's fine, no need to squash them together then.
> 
>> - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we break 
>> NAND on all DT
>> boards as we expect NAND to be a real child node with compatible id. Simply 
>> applying the
>> DT patch at this point makes it work again.
> 
> Hmm can we at least warn about incompatible DT entry when somebody boots
> with an older dtb?

Yes that could be done. It looks like we can use the missing compatible 
property to identify
that it is and old DT entry.

I'll send a v4 of patch 11.

cheers,
-roger


> 
 Test procedure was to read an existing ubifs partition,
 create a new one and read it back.

 Need you to Ack if it looks good.
 Do you mind taking it via omap-soc once MTD maintainers ack their relevant 
 parts?
>>>
>>> Sure. I'll try to do some testing on the series first too.
>>>
>> Thanks.
>>
>>> Can the dts changes be merged separtely? Otherwise we'll have
>>> a dependency between dts branch and the GPMC/NAND changes.
>>
>> I'm afraid no. Patch 11 makes us incompatible with the old DT.
> 
> OK. If we can warn about that, then the out of tree users will
> have easier time to update their dts file.
> 
> 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 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND controller

[Florian Fainelli]

On 06/10/15 15:25, Scott Branden wrote:
> Hi Brian,
> 
> On 15-10-06 06:41 AM, Brian Norris wrote:
> 

 Is there a reason not to do this reset unconditionally? I recall
 this came up in
 discussion previously, when the OpenWRT folks were trying to
 integrate with
 BCMA, where this reset was one of the few differences between the
 platform-
 device-based driver (i.e., this one) and the BCMA based driver.
 Might it help
 simplify things a bit if we just did the same thing everywhere?
>>>
>>> This driver is currently shared by Cygnus and NS2.
>>>
>>> We had similar suggestion when this patch was reviewed
>>> internally in Broadcom.
>>>
>>> The rationale for adding optional DT flag is as follows:
>>> 1. The NAND controller reset is currently required for NS2 only so
>>> that it is in sane state before any NAND commands are issued. We
>>> are not sure if Cygnus and all future iProc SoCs will require NAND
>>> controller reset.
>>
>> I'm not sure this is a very strong reason. It seems fairly reasonable in
>> general to reset a HW block before using it.
> 
> Efficient Boot time is a very strong reason for needing this actually.
> We use the NAND controller in the bootROM, boot1/BL1, u-boot/UEFI, and
> then Kernel stage.  By properly initializing the controller once we do
> not need to reset it 4 different times.

This could be used as a reverse argument, issuing a reset will increase
the boot time.

> 
>>
>>> 2. The NAND controller reset in probe would certainly increase
>>> Linux boot time so for certain iProc SoCs we might choose avoid
>>> NAND controller reset to reduce boot time if possible.
>>
>> I recall this reason being mentioned before. I believe this only happens
>> because the brcmnand driver doesn't yet handle configuring the timing
>> registers, so iProc is implicitly relying on the bootloader to configure
>> the NAND timings. Perhaps it's time that we fix that. I'd rather not add
>> extra DT properties unless we actually need to [1]. And having proper
>> timing configuration in the Linux driver will help improve speeds for
>> all users (whose timings may not be configured in the bootloader).
> 
> This is the very reason we need the optional reset property.  We need to
> have timings configured by the linux driver or not.  Yes, in some cases
> we will be relying on earlier boot stages to configure some of the
> hardware.

Then instead of adding a "reset flag" to Device Tree, another approach
could be to put the desired or currently configured exhaustive list of
NAND timings in Device Tree, and based on that you could have this:

- the NAND controller driver finds that these timings match the current
configuration, you are good to go

- the NAND controller drivers finds a difference in how current timings
are configured vs. desired timings, and issues a controller reset, prior
to applying new timing configuration

- no timings are configured, reset the controller and use existing
auto-detection capabilities like ONFI modes

Typically you would put the desired timings instead of the currently
configured timings though..

> 
>>
>> I actually had some preliminary work to do some timing configuration
>> according to the new timing information from nand_base.c/nand_timing.c.
>> Unfortunately, I didn't complete this, and I'm no longer working at
>> Broadcom, so I don't exactly have access to the HW docs for all the NAND
>> controller revisions, nor do I have access to as much HW for testing...
>>
>> Brian
>>
>> [1] If we really do need a device tree differentiation, perhaps it would
>> be better to just differentiate the compatible string than to have
>> individual boolean properties. e.g.:
>>
>> compatible = "brcm,iproc-nand-ns2", ...;
>>
> As described above - the option is not SoC specific.  It is system
> specific.  In some systems we may wish to reset the NAND controller in
> linux.  In some we may wish to rely on initialization that has already
> been done to speed up boot times.

It seems to me like having this property is fine as long as you are
describing that the controller *needs* a reset to operate properly, it
does not strike me as a particularly well suited property if its side
effect and main usage is to keep or wipe-out existing NAND timings.
-- 
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] ARM: dts: exynos4412-odroid: remove redundant pinctrl settings

[Tobias Jakobi]

Gentle ping!

- Tobias


Tobias Jakobi wrote:
> The pinctrl settings in i2c_0 and i2c_1 are already provided
> through the exynos4 dtsi.
> 
> Signed-off-by: Tobias Jakobi 
> ---
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index 3f8bc7b..3c34e74 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -217,8 +217,6 @@
>  };
>  
>  _0 {
> - pinctrl-0 = <_bus>;
> - pinctrl-names = "default";
>   samsung,i2c-sda-delay = <100>;
>   samsung,i2c-max-bus-freq = <40>;
>   status = "okay";
> @@ -444,8 +442,6 @@
>  };
>  
>  _1 {
> - pinctrl-names = "default";
> - pinctrl-0 = <_bus>;
>   status = "okay";
>   max98090: max98090@10 {
>   compatible = "maxim,max98090";
> @@ -460,8 +456,6 @@
>  
>  _2 {
>   status = "okay";
> - pinctrl-names = "default";
> - pinctrl-0 = <_bus>;
>  };
>  
>  _8 {
> 

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

Re: [RFC][PATCH 1/2] WIP: Devicetree bindings for Ion

[Laura Abbott]

On 10/6/15 3:35 PM, Rob Herring wrote:

On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott  wrote:

From: Laura Abbott 


This adds a base set of devicetree bindings for the Ion memory
manager. This supports setting up the generic set of heaps and
their properties.

Signed-off-by: Laura Abbott 
Signed-off-by: Andrew Andrianov 
---
  drivers/staging/android/ion/devicetree.txt | 53 ++


I have no issue with this going in here, but I do have lots of issues
with this binding.


  1 file changed, 53 insertions(+)
  create mode 100644 drivers/staging/android/ion/devicetree.txt

diff --git a/drivers/staging/android/ion/devicetree.txt 
b/drivers/staging/android/ion/devicetree.txt
new file mode 100644
index 000..4a0c941
--- /dev/null
+++ b/drivers/staging/android/ion/devicetree.txt
@@ -0,0 +1,53 @@
+Ion Memory Manager
+
+Ion is a memory manager that allows for sharing of buffers via dma-buf.
+Ion allows for different types of allocation via an abstraction called
+a 'heap'. A heap represents a specific type of memory. Each heap has
+a different type. There can be multiple instances of the same heap
+type.
+
+Required properties for Ion
+
+- compatible: "linux,ion"
+
+All child nodes of a linux,ion node are interpreted as heaps
+
+required properties for heaps
+
+- linux,ion-heap-id: The Ion heap id used for allocation selection
+- linux,ion-heap-type: Ion heap type defined in ion.h
+- linux,ion-heap-name: Human readble name of the heap
+
+
+Optional properties
+- memory-region: A phandle to a memory region. Required for DMA heap type
+(see reserved-memory.txt for details on the reservation)
+- linux,ion-heap-align: Alignment for the heap.
+
+Example:
+
+   ion {
+   compatbile = "linux,ion";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ion-system-heap {
+   linux,ion-heap-id = <0>;
+   linux,ion-heap-type = ;
+   linux,ion-heap-name = "system";


How does this vary across platforms? Is all of this being pushed down
to DT, because there is no coordination of this at the kernel ABI
level across platforms. In other words, why can't heap 0 be hardcoded
as system heap in the driver. It seems to me any 1 of these 3
properties could be used to derive the other 2.



Right now there is no guarantee heap IDs will be the same across
platforms. The heap IDs are currently part of the userspace ABI
as well since userspace clients must pass in a mask of the heap
IDs to allocate from. If we assume all existing clients could change,
heaps such as the system heap could be mandated to have the same
heap ID but we'd still run into problems if you have multiple
heaps of the same type (e.g. multiple carveouts)

An alternative might be to have each heap just be a compatible string
and pull everything (id, type etc.) into C files for setup. I debated
doing that but decided to try putting everything in DT for my first
pass.




+   };
+
+   ion-camera-region {
+   linux,ion-heap-id = <1>;
+   linux,ion-heap-type = ;
+   linux,ion-heap-name = "camera"
+   memory-region = <_region>;


Couldn't the memory-region node with addition properties or some
standardization of existing ones provide enough information for ION's
needs?



I think we could probably derive most of it from the memory-region right
now. If it's reusable, it's DMA, if not it goes to a carveout. Name can
come from the node name. heap ID and whether or not a region is a chunk
heap could be added as properties.

We'd still need to be able to get the same information for heaps that
don't correspond to a specific region like the system heap.


+   };
+
+   ion-fb-region {
+   linux,ion-heap-id = <2>;
+   linux,ion-heap-type = ;
+   linux,ion-heap-name = "fb"
+   memory-region = <_region>;
+   };
+   }
--
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] ARM: dts: exynos4412-odroid: unify voltage regulator style

[Tobias Jakobi]

Gentle ping!

- Tobias

Tobias Jakobi wrote:
> Use 'ldoN_reg: LDON' syntax and drop the deprecated
> 'regulator-compatible' property.
> 
> Signed-off-by: Tobias Jakobi 
> ---
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
> b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> index 518230f..9f381bd 100644
> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
> @@ -294,15 +294,13 @@
>   regulator-always-on;
>   };
>  
> - ldo8_reg: ldo@8 {
> - regulator-compatible = "LDO8";
> + ldo8_reg: LDO8 {
>   regulator-name = "VDD10_HDMI_1.0V";
>   regulator-min-microvolt = <100>;
>   regulator-max-microvolt = <100>;
>   };
>  
> - ldo10_reg: ldo@10 {
> - regulator-compatible = "LDO10";
> + ldo10_reg: LDO10 {
>   regulator-name = "VDDQ_MIPIHSI_1.8V";
>   regulator-min-microvolt = <180>;
>   regulator-max-microvolt = <180>;
> 

--
To unsubscribe from this list: send the line "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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 06/10/15 13:05, Roger Quadros wrote:
> On 06/10/15 13:00, Tony Lindgren wrote:
>> * Roger Quadros  [151006 02:59]:
>>> On 06/10/15 11:33, Tony Lindgren wrote:
 Does build and boot and use NAND work throughtout the series?
 Otherwise we'll have hard time bisecting anything..
>>>
>>> Yes it does with the following exceptions.
>>>
>>> - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq mode
>>> but none of the boards seem to be using it so it shouldn't break NAND on 
>>> existing boards.
>>> At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode is 
>>> working again.
>>> Do you want me to squash patches 7,8,9 so that pre-fetch irq is not broken 
>>> at any point?
>>
>> OK, no that's fine, no need to squash them together then.
>>
>>> - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we break 
>>> NAND on all DT
>>> boards as we expect NAND to be a real child node with compatible id. Simply 
>>> applying the
>>> DT patch at this point makes it work again.
>>
>> Hmm can we at least warn about incompatible DT entry when somebody boots
>> with an older dtb?
> 
> Yes that could be done. It looks like we can use the missing compatible 
> property to identify
> that it is and old DT entry.
> 
> I'll send a v4 of patch 11.

There is another issue. Some of the old DT nodes set the NAND IO address to 0.
As we prevent mapping into first 16MB we see the following message for those 
nodes. e.g. dra7-evm

[1.727598] omap-gpmc 5000.gpmc: cannot remap GPMC CS 0 to 0x
[1.727605] omap-gpmc 5000.gpmc: GPMC CS 0 start cannot be lesser than 
0x100
[1.727611] omap-gpmc 5000.gpmc: failed to probe DT children

Hope this is good enough information that DT needs to be updated?

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 1/3] dt-bindings: Add document of Rockchip mailbox

[Jassi Brar]

On Mon, Sep 14, 2015 at 4:36 PM, Caesar Wang  wrote:
> This add the necessary binding documentation for mailbox
> found on RK3368 SoC.
>
> Signed-off-by: Caesar Wang 
> ---
>
>  .../bindings/mailbox/rockchip-mailbox.txt  | 33 
> ++
>  1 file changed, 33 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
>
> diff --git a/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt 
> b/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
> new file mode 100644
> index 000..b9b4768
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
> @@ -0,0 +1,33 @@
> +Rockchip mailbox
> +
> +The Rockchip mailbox is used by the Rockchip CPU cores to communicate
> +requests to MCU processor.
> +
> +Refer to ./mailbox.txt for generic information about mailbox device-tree
> +bindings.
> +
> +Required properties:
> +
> + - compatible: should be one of the following.
> +   - "rockchip,rk3368-mbox" for rk3368
> + - reg: physical base address of the controller and length of memory mapped
> +   region.
> +   physical base address of the share buffer and length of memory mapped
> +   region.
Please make shared-sram a property of user drivers.

Location and size of shared-memory is a platform property, mailbox
controller doesn't need sram to function.
  For example, protocol on some platform, with this controller, may be
trivial enough to not need a shared sram... say only 32-bits wide
requests and responses which can be passed via mailbox registers
directly.   mbox_client.tx_prepare() is where the user driver sets up
the shared-memory.
--
To unsubscribe from this list: send the line "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 11/27] mtd: nand: omap: Clean up device tree support

[Roger Quadros]

Move NAND specific device tree parsing to NAND driver.

The NAND controller node must have a compatible id, register space
resource and interrupt resource.

Signed-off-by: Roger Quadros 
---
v4: Warn if using older incompatible DT i.e. compatible property not present
in nand node.

 arch/arm/mach-omap2/gpmc-nand.c  |   5 +-
 drivers/memory/omap-gpmc.c   | 143 +++
 drivers/mtd/nand/omap2.c | 136 +
 include/linux/platform_data/mtd-nand-omap2.h |   3 +-
 4 files changed, 155 insertions(+), 132 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index ffe646a..e07ca27 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -95,10 +95,7 @@ int gpmc_nand_init(struct omap_nand_platform_data 
*gpmc_nand_data,
gpmc_nand_res[1].start = gpmc_get_irq();
 
memset(, 0, sizeof(struct gpmc_settings));
-   if (gpmc_nand_data->of_node)
-   gpmc_read_settings_dt(gpmc_nand_data->of_node, );
-   else
-   gpmc_set_legacy(gpmc_nand_data, );
+   gpmc_set_legacy(gpmc_nand_data, );
 
s.device_nand = true;
 
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index e75226d..318c187 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -29,7 +29,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -1716,105 +1715,6 @@ static void __maybe_unused gpmc_read_timings_dt(struct 
device_node *np,
of_property_read_bool(np, "gpmc,time-para-granularity");
 }
 
-#if IS_ENABLED(CONFIG_MTD_NAND)
-
-static const char * const nand_xfer_types[] = {
-   [NAND_OMAP_PREFETCH_POLLED] = "prefetch-polled",
-   [NAND_OMAP_POLLED]  = "polled",
-   [NAND_OMAP_PREFETCH_DMA]= "prefetch-dma",
-   [NAND_OMAP_PREFETCH_IRQ]= "prefetch-irq",
-};
-
-static int gpmc_probe_nand_child(struct platform_device *pdev,
-struct device_node *child)
-{
-   u32 val;
-   const char *s;
-   struct gpmc_timings gpmc_t;
-   struct omap_nand_platform_data *gpmc_nand_data;
-
-   if (of_property_read_u32(child, "reg", ) < 0) {
-   dev_err(>dev, "%s has no 'reg' property\n",
-   child->full_name);
-   return -ENODEV;
-   }
-
-   gpmc_nand_data = devm_kzalloc(>dev, sizeof(*gpmc_nand_data),
- GFP_KERNEL);
-   if (!gpmc_nand_data)
-   return -ENOMEM;
-
-   gpmc_nand_data->cs = val;
-   gpmc_nand_data->of_node = child;
-
-   /* Detect availability of ELM module */
-   gpmc_nand_data->elm_of_node = of_parse_phandle(child, "ti,elm-id", 0);
-   if (gpmc_nand_data->elm_of_node == NULL)
-   gpmc_nand_data->elm_of_node =
-   of_parse_phandle(child, "elm_id", 0);
-
-   /* select ecc-scheme for NAND */
-   if (of_property_read_string(child, "ti,nand-ecc-opt", )) {
-   pr_err("%s: ti,nand-ecc-opt not found\n", __func__);
-   return -ENODEV;
-   }
-
-   if (!strcmp(s, "sw"))
-   gpmc_nand_data->ecc_opt = OMAP_ECC_HAM1_CODE_SW;
-   else if (!strcmp(s, "ham1") ||
-!strcmp(s, "hw") || !strcmp(s, "hw-romcode"))
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_HAM1_CODE_HW;
-   else if (!strcmp(s, "bch4"))
-   if (gpmc_nand_data->elm_of_node)
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH4_CODE_HW;
-   else
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH4_CODE_HW_DETECTION_SW;
-   else if (!strcmp(s, "bch8"))
-   if (gpmc_nand_data->elm_of_node)
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH8_CODE_HW;
-   else
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH8_CODE_HW_DETECTION_SW;
-   else if (!strcmp(s, "bch16"))
-   if (gpmc_nand_data->elm_of_node)
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH16_CODE_HW;
-   else
-   pr_err("%s: BCH16 requires ELM support\n", __func__);
-   else
-   pr_err("%s: ti,nand-ecc-opt invalid value\n", __func__);
-
-   /* select data transfer mode for NAND controller */
-   if (!of_property_read_string(child, "ti,nand-xfer-type", ))
-   for (val = 0; val < ARRAY_SIZE(nand_xfer_types); val++)
-   if (!strcasecmp(s, nand_xfer_types[val])) {
-   gpmc_nand_data->xfer_type = val;
-   break;
-   }
-
- 

Re: [PATCH v6 21/22] driver core: Start processing deferred probes earlier

[Mark Brown]

On Mon, Oct 05, 2015 at 09:49:38PM -0500, Rob Herring wrote:
> On Mon, Oct 5, 2015 at 6:52 PM, Frank Rowand  wrote:

> > The purpose of the *_sync initcall levels is to allow the corresponding
> > initcall level to use multiple threads of execution instead of a single
> > thread.  The *_sync level provides a location for a wait for all of the
> > threads at the corresponding init level to complete.  This is better
> > explained in the git log:

> The things I was worried about like clk and regulator disabling are
> actually late_initcall_sync, so maybe late_initcall is fine here after
> all.

> However, looking at other *_initcall_sync users, I'm not so sure they
> are doing the same abuse.

They're trying to run at the point where we've completed deferred
probe processing - in other words, at the sync point.  What they really
want is an additional callback at the point where the syncs have
actually happened.


signature.asc
Description: Digital signature

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Tony Lindgren]

* Roger Quadros  [151006 03:32]:
> On 06/10/15 13:05, Roger Quadros wrote:
> > On 06/10/15 13:00, Tony Lindgren wrote:
> >> * Roger Quadros  [151006 02:59]:
> >>> On 06/10/15 11:33, Tony Lindgren wrote:
>  Does build and boot and use NAND work throughtout the series?
>  Otherwise we'll have hard time bisecting anything..
> >>>
> >>> Yes it does with the following exceptions.
> >>>
> >>> - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq 
> >>> mode
> >>> but none of the boards seem to be using it so it shouldn't break NAND on 
> >>> existing boards.
> >>> At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode 
> >>> is working again.
> >>> Do you want me to squash patches 7,8,9 so that pre-fetch irq is not 
> >>> broken at any point?
> >>
> >> OK, no that's fine, no need to squash them together then.
> >>
> >>> - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we 
> >>> break NAND on all DT
> >>> boards as we expect NAND to be a real child node with compatible id. 
> >>> Simply applying the
> >>> DT patch at this point makes it work again.
> >>
> >> Hmm can we at least warn about incompatible DT entry when somebody boots
> >> with an older dtb?
> > 
> > Yes that could be done. It looks like we can use the missing compatible 
> > property to identify
> > that it is and old DT entry.
> > 
> > I'll send a v4 of patch 11.
> 
> There is another issue. Some of the old DT nodes set the NAND IO address to 0.
> As we prevent mapping into first 16MB we see the following message for those 
> nodes. e.g. dra7-evm
> 
> [1.727598] omap-gpmc 5000.gpmc: cannot remap GPMC CS 0 to 0x
> [1.727605] omap-gpmc 5000.gpmc: GPMC CS 0 start cannot be lesser than 
> 0x100
> [1.727611] omap-gpmc 5000.gpmc: failed to probe DT children
> 
> Hope this is good enough information that DT needs to be updated?

Yes I think that should allow users update the out of tree dts file
easily.

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 RFC] ASoC: simple-card: Update clocks binding for simple-card DAI subnodes

[Mark Brown]

On Mon, Sep 28, 2015 at 09:49:35PM +0300, Jyri Sarha wrote:
> On 09/19/15 21:42, Mark Brown wrote:

> >What's the use case again?  Can we address this by converting the
> >relevant drivers to the clock API (or improving their clock API
> >support)?

> Sorry, I forgot to reply this earlier. The reason why we need this is the
> way McASP driver uses and provides clocks for different purposes. The most
> pressing need is to be able to select if we want to use some external clock
> pin as an input for McASP clock divider that produces the i2s bit-clock or
> if we want to use McASP's internal clock source.

> There are several other things this binding would allow us, and others with
> flexible i2s HW, to do. Some TI codecs would also benefit from a flexible
> way of describing the used clock configuration, but Peter know that part
> better.

> I tried to make the binding as flexible and generic as possible. But I do
> not currently see any immediate need for more than one set_sysclk() call per
> dai. I just did not see any reason to not allow it either.

This explains why you want to do this but what about the clock API
portion of the question - it would be good to move the ASoC clocking
more into the clock API, this would help integration with wider clock
trees.


signature.asc
Description: Digital signature

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 06/10/15 14:01, Tony Lindgren wrote:
> * Roger Quadros  [151006 03:32]:
>> On 06/10/15 13:05, Roger Quadros wrote:
>>> On 06/10/15 13:00, Tony Lindgren wrote:
 * Roger Quadros  [151006 02:59]:
> On 06/10/15 11:33, Tony Lindgren wrote:
>> Does build and boot and use NAND work throughtout the series?
>> Otherwise we'll have hard time bisecting anything..
>
> Yes it does with the following exceptions.
>
> - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq 
> mode
> but none of the boards seem to be using it so it shouldn't break NAND on 
> existing boards.
> At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode 
> is working again.
> Do you want me to squash patches 7,8,9 so that pre-fetch irq is not 
> broken at any point?

 OK, no that's fine, no need to squash them together then.

> - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we 
> break NAND on all DT
> boards as we expect NAND to be a real child node with compatible id. 
> Simply applying the
> DT patch at this point makes it work again.

 Hmm can we at least warn about incompatible DT entry when somebody boots
 with an older dtb?
>>>
>>> Yes that could be done. It looks like we can use the missing compatible 
>>> property to identify
>>> that it is and old DT entry.
>>>
>>> I'll send a v4 of patch 11.
>>
>> There is another issue. Some of the old DT nodes set the NAND IO address to 
>> 0.
>> As we prevent mapping into first 16MB we see the following message for those 
>> nodes. e.g. dra7-evm
>>
>> [1.727598] omap-gpmc 5000.gpmc: cannot remap GPMC CS 0 to 0x
>> [1.727605] omap-gpmc 5000.gpmc: GPMC CS 0 start cannot be lesser 
>> than 0x100
>> [1.727611] omap-gpmc 5000.gpmc: failed to probe DT children
>>
>> Hope this is good enough information that DT needs to be updated?
> 
> Yes I think that should allow users update the out of tree dts file
> easily.

Fine. The updated series is now at

g...@github.com:rogerq/linux.git
 * [new branch]  for-v4.4/gpmc-v4

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

[PATCH] pwm: pwm-rcar: Revise the device tree binding document about compatible

[Yoshihiro Shimoda]

The compatible should be "renesas,pwm-rcar", and one the the SoC
specific string. So, this patch revises the documentation.

Reported-by: Rob Herring 
Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt 
b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt
index ea0a27b..0822a08 100644
--- a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt
+++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt
@@ -1,8 +1,7 @@
 * Renesas R-Car PWM Timer Controller
 
 Required Properties:
-- compatible: should be one of the following.
- - "renesas,pwm-rcar": for generic R-Car compatible PWM Timer
+- compatible: should be "renesas,pwm-rcar" and one of the following.
  - "renesas,pwm-r8a7778": for R-Car M1A
  - "renesas,pwm-r8a7779": for R-Car H1
  - "renesas,pwm-r8a7790": for R-Car H2
-- 
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 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND controller

[Brian Norris]

Hi Anup,

On Mon, Oct 05, 2015 at 06:27:16AM +, Anup Patel wrote:
> > -Original Message-
> > From: Brian Norris [mailto:computersforpe...@gmail.com]
> > Sent: 05 October 2015 03:20
> > To: Anup Patel
> > Cc: linux-arm-ker...@lists.infradead.org; Rob Herring; Pawel Moll; Mark
> > Rutland; Ian Campbell; Kumar Gala; Catalin Marinas; Will Deacon; David
> > Woodhouse; Ray Jui; Scott Branden; Florian Fainelli; Pramod Kumar; Vikram
> > Prakash; Sandeep Tripathy; devicetree@vger.kernel.org; linux-
> > ker...@vger.kernel.org; linux-...@lists.infradead.org; bcm-kernel-feedback-
> > list; Rafal Milecki
> > Subject: Re: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND
> > controller
> > 
> > + Rafal (to extend this mighty CC list)
> > 
> > On Fri, Oct 02, 2015 at 11:26:44PM +0530, Anup Patel wrote:
> > > The BRCM NAND controller on NS2 SoC requires a reset to cleanup
> > > previously configured NAND controller state.
> > >
> > > This patch adds optional boolean device tree flag named
> > > "brcm,nand-iproc-reset". If this flag is present in NAND controller DT
> > > node then BRCM IPROC NAND driver will reset the NAND controller before
> > > any commands are issued.
> > 
> > Is there a reason not to do this reset unconditionally? I recall this came 
> > up in
> > discussion previously, when the OpenWRT folks were trying to integrate with
> > BCMA, where this reset was one of the few differences between the platform-
> > device-based driver (i.e., this one) and the BCMA based driver. Might it 
> > help
> > simplify things a bit if we just did the same thing everywhere?
> 
> This driver is currently shared by Cygnus and NS2.
> 
> We had similar suggestion when this patch was reviewed
> internally in Broadcom.
> 
> The rationale for adding optional DT flag is as follows:
> 1. The NAND controller reset is currently required for NS2 only so
> that it is in sane state before any NAND commands are issued. We
> are not sure if Cygnus and all future iProc SoCs will require NAND
> controller reset.

I'm not sure this is a very strong reason. It seems fairly reasonable in
general to reset a HW block before using it.

> 2. The NAND controller reset in probe would certainly increase
> Linux boot time so for certain iProc SoCs we might choose avoid
> NAND controller reset to reduce boot time if possible.

I recall this reason being mentioned before. I believe this only happens
because the brcmnand driver doesn't yet handle configuring the timing
registers, so iProc is implicitly relying on the bootloader to configure
the NAND timings. Perhaps it's time that we fix that. I'd rather not add
extra DT properties unless we actually need to [1]. And having proper
timing configuration in the Linux driver will help improve speeds for
all users (whose timings may not be configured in the bootloader).

I actually had some preliminary work to do some timing configuration
according to the new timing information from nand_base.c/nand_timing.c.
Unfortunately, I didn't complete this, and I'm no longer working at
Broadcom, so I don't exactly have access to the HW docs for all the NAND
controller revisions, nor do I have access to as much HW for testing...

Brian

[1] If we really do need a device tree differentiation, perhaps it would
be better to just differentiate the compatible string than to have
individual boolean properties. e.g.:

compatible = "brcm,iproc-nand-ns2", ...;
--
To unsubscribe from this list: send the line "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] mailbox: rockchip: Add Rockchip mailbox driver

[Jassi Brar]

On Mon, Sep 14, 2015 at 4:36 PM, Caesar Wang  wrote:
> This driver is found on RK3368 SoCs.
>
> The Mailbox module is a simple APB peripheral that allows both
> the Cortex-A53 MCU system to communicate by writing operation to
> generate interrupt.
> The registers are accessible by both CPU via APB interface.
>
> The Mailbox has the following main features:
>
> @ Support dual-core system: Cortex-A53 and MCU.
> @ Support APB interface.
> @ Support four mailbox elements, each element includes one data word, one
>   command word register and one flag bit that can represent one interrupt.
> @ Four interrupts to Cortex-A53.
> @ Four interrupts to MCU.
> @ Provide 32 lock registers for software to use to indicate whether mailbox
>   is occupied.
>
> Signed-off-by: Caesar Wang 
> ---
>
>  drivers/mailbox/Kconfig|   9 ++
>  drivers/mailbox/Makefile   |   2 +
>  drivers/mailbox/rockchip-mailbox.c | 317 
> +
>  3 files changed, 328 insertions(+)
>  create mode 100644 drivers/mailbox/rockchip-mailbox.c
>
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index bbec500..a548d700 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -43,6 +43,15 @@ config OMAP_MBOX_KFIFO_SIZE
>   This can also be changed at runtime (via the mbox_kfifo_size
>   module parameter).
>
> +config ROCKCHIP_MBOX
> +   bool "Rockchip Soc Intergrated Mailbox Support"
> +   depends on ARCH_ROCKCHIP
> +   help
> + This driver provides support for inter-processor communication
> + between CPU cores and MCU processor on Some Rockchip SOCs.
> + Please check it that the Soc you use have Mailbox hardware.
> + Say Y here if you want to use the Rockchip Mailbox support.
> +
>  config PCC
> bool "Platform Communication Channel Driver"
> depends on ACPI
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index 8e6d822..730cb5d 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -8,6 +8,8 @@ obj-$(CONFIG_PL320_MBOX)+= pl320-ipc.o
>
>  obj-$(CONFIG_OMAP2PLUS_MBOX)   += omap-mailbox.o
>
> +obj-$(CONFIG_ROCKCHIP_MBOX)+= rockchip-mailbox.o
> +
>  obj-$(CONFIG_PCC)  += pcc.o
>
>  obj-$(CONFIG_ALTERA_MBOX)  += mailbox-altera.o
> diff --git a/drivers/mailbox/rockchip-mailbox.c 
> b/drivers/mailbox/rockchip-mailbox.c
> new file mode 100644
> index 000..715ab96
> --- /dev/null
> +++ b/drivers/mailbox/rockchip-mailbox.c
> @@ -0,0 +1,317 @@
> +/*
> + * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * Authors:Addy Ke 
> + * Caesar Wang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope 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 
> +
> +#define MAILBOX_A2B_INTEN  0x00
> +#define MAILBOX_A2B_STATUS 0x04
> +#define MAILBOX_A2B_CMD(x) (0x08 + (x) * 8)
> +#define MAILBOX_A2B_DAT(x) (0x0c + (x) * 8)
> +
> +#define MAILBOX_B2A_INTEN  0x28
> +#define MAILBOX_B2A_STATUS 0x2C
> +#define MAILBOX_B2A_CMD(x) (0x30 + (x) * 8)
> +#define MAILBOX_B2A_DAT(x) (0x34 + (x) * 8)
> +
> +#define MAILBOX_ATOMIC_LOCK(x) (0x100 + (x) * 8)
> +
> +/* A2B: 0 - 2k */
> +#define A2B_BUF(size, idx) ((idx) * (size))
> +
> +/* B2A: 2k - 4k */
> +#define B2A_BUF(size, idx) (((idx) + 4) * (size))
> +
> +struct rockchip_mbox_msg {
> +   u32 cmd;
> +   int tx_size;
> +   void *tx_buf;
> +   int rx_size;
> +   void *rx_buf;
> +   void *cl_data;
> +};
> +
> +struct rockchip_mbox_data {
> +   int num_chans;
> +};
> +
> +struct rockchip_mbox_chan {
> +   int idx;
> +   int irq;
> +   struct rockchip_mbox_msg *msg;
> +   struct rockchip_mbox *mb;
> +};
> +
> +struct rockchip_mbox {
> +   struct mbox_controller mbox;
> +   struct clk *pclk;
> +   void __iomem *mbox_base;
> +
> +   /* The base address of share memory to transfer data */
> +   void __iomem *buf_base;
> +
> +   /* The maximum size of buf for each channel */
> +   u32 buf_size;
> +
> +   struct rockchip_mbox_chan *chans;
> +};
> +
> +static inline int chan_to_idx(struct rockchip_mbox *mb,
> + struct mbox_chan *chan)
> +{
> +   return (chan - mb->mbox.chans);
> +}

Re: [PATCH v6 2/4] spi: bcm2835: add bcm2835 auxiliary spi device driver

[Mark Brown]

On Fri, Sep 11, 2015 at 11:22:04AM +, ker...@martin.sperl.org wrote:

> + bs->irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
> + if (bs->irq <= 0) {
> + dev_err(>dev, "could not get IRQ: %d\n", bs->irq);
> + err = bs->irq ? bs->irq : -ENODEV;
> + goto out_master_put;
> + }

Why are we using this unusual DT specific API here?  I'd expect to see
just use platform_get_irq() here and this seems to be the only DT
dependency in the driver. 

> + err = devm_request_irq(>dev, bs->irq,
> +bcm2835aux_spi_interrupt,
> +IRQF_SHARED,
> +dev_name(>dev), master);
> + if (err) {
> + dev_err(>dev, "could not request IRQ: %d\n", err);
> + goto out_clk_disable;
> + }
> +
> + /* reset SPI-HW block */
> + bcm2835aux_spi_reset_hw(bs);

I'd expect to request the IRQ after we reset the hardware in order to
ensure that the hardware is in a known good state 

> +
> + err = devm_spi_register_master(>dev, master);
> + if (err) {
> + dev_err(>dev, "could not register SPI master: %d\n", err);
> + goto out_clk_disable;
> + }
> +
> + return 0;
> +
> +out_clk_disable:
> + clk_disable_unprepare(bs->clk);
> +out_master_put:
> + spi_master_put(master);
> + return err;
> +}
> +
> +static int bcm2835aux_spi_remove(struct platform_device *pdev)
> +{
> + struct spi_master *master = platform_get_drvdata(pdev);
> + struct bcm2835aux_spi *bs = spi_master_get_devdata(master);
> +
> + bcm2835aux_spi_reset_hw(bs);
> +
> + /* disable the HW block by releasing the clock */
> + clk_disable_unprepare(bs->clk);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id bcm2835aux_spi_match[] = {
> + { .compatible = "brcm,bcm2835-aux-spi", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, bcm2835aux_spi_match);
> +
> +static struct platform_driver bcm2835aux_spi_driver = {
> + .driver = {
> + .name   = "spi-bcm2835aux",
> + .of_match_table = bcm2835aux_spi_match,
> + },
> + .probe  = bcm2835aux_spi_probe,
> + .remove = bcm2835aux_spi_remove,
> +};
> +module_platform_driver(bcm2835aux_spi_driver);
> +
> +MODULE_DESCRIPTION("SPI controller driver for Broadcom BCM2835 aux");
> +MODULE_AUTHOR("Martin Sperl ");
> +MODULE_LICENSE("GPL v2");
> --
> 1.7.10.4
> 
> 


signature.asc
Description: Digital signature

Re: [RFC PATCH v6 1/3] dtc: protect against null pointer dereference in srcpos_string()

[David Gibson]

On Tue, Oct 06, 2015 at 12:32:20AM -0700, Frank Rowand wrote:
> On 10/5/2015 9:10 PM, David Gibson wrote:
> > On Fri, Oct 02, 2015 at 09:49:08PM -0700, Frank Rowand wrote:
> >> From: Frank Rowand 
> >>
> >> Check for NULL pos before dereferencing it in srcpos_string().
> >>
> >> Signed-off-by: Frank Rowand 
> >> ---
> >>  srcpos.c |6 --
> >>  1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> Index: b/srcpos.c
> >> ===
> >> --- a/srcpos.c
> >> +++ b/srcpos.c
> >> @@ -268,11 +268,13 @@ srcpos_string(struct srcpos *pos)
> >>char *pos_str;
> >>int rc;
> >>  
> >> -  if (pos)
> >> +  if (pos && pos->file)
> >>fname = pos->file->name;
> >>  
> >>  
> >> -  if (pos->first_line != pos->last_line)
> >> +  if (!pos)
> >> +  rc = asprintf(_str, "%s:", fname);
> >> +  else if (pos->first_line != pos->last_line)
> > 
> > This logic still seems backwards to me.  I'd really prefer the !pos
> > check to go first, then !pos->file, then the normal case.
> > 
> 
> Checking !pos first results in either an early return, a goto,
> or more deeply nesting the

Early return is fine by me.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH v6 2/4] spi: bcm2835: add bcm2835 auxiliary spi device driver

[Martin Sperl]

On 06.10.2015 13:23, Mark Brown wrote:

On Fri, Sep 11, 2015 at 11:22:04AM +, ker...@martin.sperl.org wrote:


+   bs->irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
+   if (bs->irq <= 0) {
+   dev_err(>dev, "could not get IRQ: %d\n", bs->irq);
+   err = bs->irq ? bs->irq : -ENODEV;
+   goto out_master_put;
+   }


Why are we using this unusual DT specific API here?  I'd expect to see
just use platform_get_irq() here and this seems to be the only DT
dependency in the driver.


I copied it from spi-bcm2835.c, where it is also used in exactly that
fashion.

You want me to move to your recommended api instead for both drivers?




+   err = devm_request_irq(>dev, bs->irq,
+  bcm2835aux_spi_interrupt,
+  IRQF_SHARED,
+  dev_name(>dev), master);
+   if (err) {
+   dev_err(>dev, "could not request IRQ: %d\n", err);
+   goto out_clk_disable;
+   }
+
+   /* reset SPI-HW block */
+   bcm2835aux_spi_reset_hw(bs);


I'd expect to request the IRQ after we reset the hardware in order to
ensure that the hardware is in a known good state


Same copy/paste in this case - i can change the order for both
drivers if you want.

Martin

--
To unsubscribe from this list: send the line "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] video: fbdev: add Marvell PXA framebuffer binding

[Rob Herring]

On Sun, Oct 4, 2015 at 5:31 AM, Robert Jarzmik  wrote:
> Add documentation for the PXA frambuffer devicetree binding.

Strictly speaking this is a binding for PXA display controller, not a
Linux FB driver. There are lots of "framebuffer" and "DRM" bindings
which I'm trying to curb.

> Signed-off-by: Robert Jarzmik 
> ---
> Since v1: Philipp's review on the whole binding
> ---
>  .../devicetree/bindings/video/marvell,pxafb.txt| 80 
> ++

Please put in bindings/display/ as I'm consolidating all the display
related bindings there[1].

>  1 file changed, 80 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/video/marvell,pxafb.txt
>
> diff --git a/Documentation/devicetree/bindings/video/marvell,pxafb.txt 
> b/Documentation/devicetree/bindings/video/marvell,pxafb.txt
> new file mode 100644
> index ..4d6bd490680d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/video/marvell,pxafb.txt
> @@ -0,0 +1,80 @@
> +PXA LCDC Framebuffer
> +
> +
> +Required properties:
> + - compatible :
> +   "marvell,pxa2xx-lcdc",

No differences in h/w for any of the chips?

> + - reg : Should contain 1 register ranges(address and length).
> +Can contain an additional register range(address and length)
> +for fixed framebuffer memory. Useful for dedicated memories.

This is memory that can't be used for anything else? We already have
reserved-memory for this if it is just RAM. There's also a binding for
on-chip SRAM which should probably be used if the memory is usable for
other things.

> + - interrupts : framebuffer controller interrupt
> +
> +Required nodes:
> + - clocks: phandle to input clocks.
> + - port: connection to the LCD panel (see video-interfaces.txt)
> +This nodes must have its properties bus-width and remote-endpoint 
> set.
> +This should be in the board dts.
> +
> +Example:
> +
> +   lcd-controller@4050 {
> +   compatible = "marvell,pxa2xx-lcdc";
> +   reg = <0x4400 0x1>;
> +   interrupts = <17>;
> +   clocks = < CLK_LCD>;
> +   interrupts = <23>;
> +   status = "okay";
> +
> +   port {
> +   lcdc_out: endpoint {
> +   remote-endpoint = <_in>;
> +   bus-width = <16>;
> +   };
> +   };
> +   };
> +
> +PXA LCDC Display

This should not be specific to PXA, but for this panel. This should be
in bindings/display/panel/.

> +
> +Required properties (as per of_videomode_helper):
> + - lcd-type: either "mono-stn", "mono-dstn", "color-stn", "color-dstn",
> +   "color-tft", "smart-panel"
> +
> +Optional properties (as per of_videomode_helper):
> + - power-supply: power supply regulator to the LCD to power it on or off
> +(see regulator.txt)
> + - backlight: backlight control (see backlight.txt)
> +
> +Required nodes:
> + - port: connection to the LCD controller
> + - display-timings: panel timings (see display-timing.txt)

If lcd-type is smart-panel, then this node would not make sense.

> +
> +Example:
> +   panel {
> +   compatible = "toshiba,ltm0305a776";
> +   lcd-type = "color-tft";
> +
> +   power-supply = <_supply>;
> +   backlight = <_backlight>;
> +
> +   port {
> +   panel_in: endpoint {
> +   remote-endpoint = <_out>;
> +   };
> +   };
> +
> +   display-timings {
> +   native-mode = <>;
> +   timing0: 240p {
> +   /* 240x320p24 */
> +   clock-frequency = <4545000>;
> +   hactive = <240>;
> +   vactive = <320>;
> +   hfront-porch = <4>;
> +   hback-porch = <6>;
> +   hsync-len = <4>;
> +   vback-porch = <5>;
> +   vfront-porch = <3>;
> +   vsync-len = <2>;
> +   };
> +   };
> +   };
> --
> 2.1.4
>

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

Re: [PATCH v2 3/4] ARM: dts: DRA7: Add timer12 node

[Suman Anna]

On 10/06/2015 02:52 AM, Tony Lindgren wrote:
> * Felipe Balbi  [151005 17:51]:
>>
>> according to Tony we should avoid using status at all for in-SoC
>> devices.
>>
>> Tony, can you confirm I understood you correctly ?
> 
> Yes. With status = "disabled" kernel completely ignores the
> device and struct device is not created at all even with the
> device being there. In general we're better off trying to
> probe the device and idle it.
> 
> The only time we really want to mark something with
> status = "disabled" is if some coprocessor firmware is
> using that device and the kernel should not touch it at
> all.

Not always, since some of the PM clocking logic depends on the state
machine variables within the kernel.

We are also using this to deal with paper-spins (atleast in the DRA7
case) and the DTS include model, wherein certain instances may not be
present on all variations of the SoC, and enabled specifically on the
instances that matter. Obviously, it could be done the other way too,
but as far as what Nishanth mentioned sometime back, we are following
the former for DRA7.

In anycase, the status property on the Timer12 node can be removed, it
doesn't fall into the above category, and we are fixing it up properly
on HS devices in the kernel.

regards
Suman

--
To unsubscribe from this list: send the line "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] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Bharat Kumar Gogada]

Subject: Re: [PATCH v3] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe 
Host Controller

Hi Bharat,

On 06/10/15 16:44, Bharat Kumar Gogada wrote:
> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> 
> Signed-off-by: Bharat Kumar Gogada 
> Signed-off-by: Ravi Kiran Gummaluri 
> ---
> Added interrupt-map, interrupt-map-mask properties
> ---
>  .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   56 ++
>  drivers/pci/host/Kconfig   |9 +
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/pcie-xilinx-nwl.c | 1029 
> 
>  4 files changed, 1095 insertions(+), 0 deletions(-)  create mode 
> 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
>  create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
> 
> diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt 
> b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> new file mode 100644
> index 000..81006ab
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> @@ -0,0 +1,56 @@
> +* Xilinx NWL PCIe Root Port Bridge DT description
> +
> +Required properties:
> +- compatible: Should contain "xlnx,nwl-pcie-2.11"
> +- #address-cells: Address representation for root ports, set to <3>
> +- #size-cells: Size representation for root ports, set to <2>
> +- #interrupt-cells: specifies the number of cells needed to encode an
> + interrupt source. The value must be 1.
> +- reg: Should contain Bridge, PCIe Controller registers location,
> + configuration sapce, and length
> +- reg-names: Must include the following entries:
> + "breg": bridge registers
> + "pcireg": PCIe controller registers
> + "cfg": configuration space region
> +- device_type: must be "pci"
> +- interrupts: Should contain NWL PCIe interrupt
> +- interrupt-names: Must include the following entries:
> + "misc": interrupt asserted when miscellaneous is recieved
> + "intx": interrupt that is asserted when an legacy interrupt is received
> + "msi_1, msi_0": interrupt asserted when msi is recieved
> +- interrupt-map-mask and interrupt-map: standard PCI properties to define the
> + mapping of the PCI interface to interrupt numbers.
> +- ranges: ranges for the PCI memory regions (I/O space region is not
> + supported by hardware)
> + Please refer to the standard PCI bus binding document for a more
> + detailed explanation
> +
> +Optional properties:
> +- xlnx,msi-fifo: To enable MSI FIFO mode
> + - This feature can be used to queue multiple MSI interrupts
> +
> +Example:
> +
> +nwl_pcie: pcie@fd0e {
> + compatible = "xlnx,nwl-pcie-2.11";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + #interrupt-cells = <1>;
> + device_type = "pci";
> + interrupt-parent = <>;
> + interrupts = < 0 118 4
> +0 116 4
> +0 115 4  // MSI_1 [63...32]
> +0 114 4 >;   // MSI_0 [31...0]
> + interrupt-names = "misc", "intx", "msi_1", "msi_0";
> + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> + interrupt-map = <0x0 0x0 0x0 0x1  0x0 116 0x4
> + 0x0 0x0 0x0 0x2  0x0 116 0x4
> + 0x0 0x0 0x0 0x3  0x0 116 0x4
> + 0x0 0x0 0x0 0x4  0x0 116 0x4>;
> + reg = <0x0 0xfd0e 0x1000
> +0x0 0xfd48 0x1000
> +0x0 0xE000 0x100>;
> + reg-names = "breg", "pcireg", "cfg";
> + ranges = <0x0200 0x 0xE100 0x 0xE100 0 
> +0x0F00>; };

Please move this to a separate patch. This is big enough, and hard enough to 
review.

> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index 
> c132bdd..7f5f35e 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -15,6 +15,15 @@ config PCI_MVEBU
>   depends on ARCH_MVEBU || ARCH_DOVE
>   depends on OF
> 
> +config PCIE_XILINX_NWL
> + bool "NWL PCIe Core && PCI_MSI"
> + depends on ARCH_ZYNQMP
> + help
> +  Say 'Y' here if you want kernel to support for Xilinx
> +  NWL PCIe controller.The controller can act as Root Port
> +  or End Point.The current option selection will only

Add a space after the dot.

> +  support root port enabling.
> +
>  config PCIE_DW
>   bool
> 
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile 
> index 140d66f..6a56df7 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
>  obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
>  obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
>  obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
> +obj-$(CONFIG_PCIE_XILINX_NWL) += pcie-xilinx-nwl.o
>  obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
>  obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
>  

Re: [GIT PULL]Hisilicon arm64 dt changes for 4.3

[Wei Xu]

On 10/6/2015 3:24 PM, Arnd Bergmann wrote:
> On Monday 21 September 2015 17:36:35 Wei Xu wrote:
>> ARM64: DT: Hisilicon hip05 soc and D02 board updates for 4.3
>>
>> - Updated the hisilicon devicetree bindings document to support hip05-D02 
>> board
>> - Added dts files for hip05 SoC and D02 board
>>
> 

Hi Arnd,

> Sorry for the long delay on our side, I've now merged these
> into the next/dt branch. Thanks for waiting,

Thanks!

Best Regards,
Wei

> 
>   Arnd
> ___
> linuxarm mailing list
> linux...@huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
> 
> .
> 

--
To unsubscribe from this list: send the line "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] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

Hi Bharat,

On 06/10/15 16:44, Bharat Kumar Gogada wrote:
> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> 
> Signed-off-by: Bharat Kumar Gogada 
> Signed-off-by: Ravi Kiran Gummaluri 
> ---
> Added interrupt-map, interrupt-map-mask properties
> ---
>  .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   56 ++
>  drivers/pci/host/Kconfig   |9 +
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/pcie-xilinx-nwl.c | 1029 
> 
>  4 files changed, 1095 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
>  create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
> 
> diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt 
> b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> new file mode 100644
> index 000..81006ab
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> @@ -0,0 +1,56 @@
> +* Xilinx NWL PCIe Root Port Bridge DT description
> +
> +Required properties:
> +- compatible: Should contain "xlnx,nwl-pcie-2.11"
> +- #address-cells: Address representation for root ports, set to <3>
> +- #size-cells: Size representation for root ports, set to <2>
> +- #interrupt-cells: specifies the number of cells needed to encode an
> + interrupt source. The value must be 1.
> +- reg: Should contain Bridge, PCIe Controller registers location,
> + configuration sapce, and length
> +- reg-names: Must include the following entries:
> + "breg": bridge registers
> + "pcireg": PCIe controller registers
> + "cfg": configuration space region
> +- device_type: must be "pci"
> +- interrupts: Should contain NWL PCIe interrupt
> +- interrupt-names: Must include the following entries:
> + "misc": interrupt asserted when miscellaneous is recieved
> + "intx": interrupt that is asserted when an legacy interrupt is received
> + "msi_1, msi_0": interrupt asserted when msi is recieved
> +- interrupt-map-mask and interrupt-map: standard PCI properties to define the
> + mapping of the PCI interface to interrupt numbers.
> +- ranges: ranges for the PCI memory regions (I/O space region is not
> + supported by hardware)
> + Please refer to the standard PCI bus binding document for a more
> + detailed explanation
> +
> +Optional properties:
> +- xlnx,msi-fifo: To enable MSI FIFO mode
> + - This feature can be used to queue multiple MSI interrupts
> +
> +Example:
> +
> +nwl_pcie: pcie@fd0e {
> + compatible = "xlnx,nwl-pcie-2.11";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + #interrupt-cells = <1>;
> + device_type = "pci";
> + interrupt-parent = <>;
> + interrupts = < 0 118 4
> +0 116 4
> +0 115 4  // MSI_1 [63...32]
> +0 114 4 >;   // MSI_0 [31...0]
> + interrupt-names = "misc", "intx", "msi_1", "msi_0";
> + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> + interrupt-map = <0x0 0x0 0x0 0x1  0x0 116 0x4
> + 0x0 0x0 0x0 0x2  0x0 116 0x4
> + 0x0 0x0 0x0 0x3  0x0 116 0x4
> + 0x0 0x0 0x0 0x4  0x0 116 0x4>;
> + reg = <0x0 0xfd0e 0x1000
> +0x0 0xfd48 0x1000
> +0x0 0xE000 0x100>;
> + reg-names = "breg", "pcireg", "cfg";
> + ranges = <0x0200 0x 0xE100 0x 0xE100 0 
> 0x0F00>;
> +};

Please move this to a separate patch. This is big enough, and hard
enough to review.

> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> index c132bdd..7f5f35e 100644
> --- a/drivers/pci/host/Kconfig
> +++ b/drivers/pci/host/Kconfig
> @@ -15,6 +15,15 @@ config PCI_MVEBU
>   depends on ARCH_MVEBU || ARCH_DOVE
>   depends on OF
> 
> +config PCIE_XILINX_NWL
> + bool "NWL PCIe Core && PCI_MSI"
> + depends on ARCH_ZYNQMP
> + help
> +  Say 'Y' here if you want kernel to support for Xilinx
> +  NWL PCIe controller.The controller can act as Root Port
> +  or End Point.The current option selection will only

Add a space after the dot.

> +  support root port enabling.
> +
>  config PCIE_DW
>   bool
> 
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> index 140d66f..6a56df7 100644
> --- a/drivers/pci/host/Makefile
> +++ b/drivers/pci/host/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
>  obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
>  obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-dw.o pci-keystone.o
>  obj-$(CONFIG_PCIE_XILINX) += pcie-xilinx.o
> +obj-$(CONFIG_PCIE_XILINX_NWL) += pcie-xilinx-nwl.o
>  obj-$(CONFIG_PCI_XGENE) += pci-xgene.o
>  obj-$(CONFIG_PCI_XGENE_MSI) += pci-xgene-msi.o
>  obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
> diff --git a/drivers/pci/host/pcie-xilinx-nwl.c 
> 

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

[Rob Herring]

On Tue, Oct 6, 2015 at 10:47 AM, Daniel Walker  wrote:
> It looks like there's some seepage of cmdline stuff into
> the generic device tree code. This conflicts with the
> generic cmdline implementation so I remove it in the case
> when that's enabled.

Nice series in general. I've had passing desire to do this every time
I run into the command line code.

The DT handling of the command line is generic across architectures.
The current design is working around that the kernel command line code
is not that way. I think we can take this a bit further by making the
generic DT code add the command line string directly rather than
relying on the arch to do that. Then we can remove all command line
handling from the arch code. I would also look at whether we can make
boot_command_line static rather than directly accessed. We might have
to leave it public for now, but could treat it as static for generic
cmdline case.

Rob

> Cc: xe-ker...@external.cisco.com
> Cc: Daniel Walker 
> Signed-off-by: Daniel Walker 
> ---
>  drivers/of/fdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 6e82bc42..80f1e48 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -953,7 +953,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, 
> const char *uname,
>  * managed to set the command line, unless CONFIG_CMDLINE_FORCE
>  * is set in which case we override whatever was found earlier.
>  */
> -#ifdef CONFIG_CMDLINE
> +#if defined(CONFIG_CMDLINE) && !defined(CONFIG_GENERIC_CMDLINE)
>  #ifndef CONFIG_CMDLINE_FORCE
> if (!((char *)data)[0])
>  #endif
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

[Marc Zyngier]

On 06/10/15 17:27, Bharat Kumar Gogada wrote:
> Subject: Re: [PATCH v3] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL 
> PCIe Host Controller

[...]

Please use an email client that does proper quoting - I cannot see what
you are replying to. Or at least annotate your answers so that I can
spot them.

>> +struct nwl_msi {/* struct nwl_msi - MSI information */
>> +struct msi_controller chip; /* chip: MSI controller */
> 
>> We're moving away from msi_controller altogether, as the kernel now
>> has all the necessary infrastructure to do this properly.
> 
> Our current GIC version does not have separate msi controller (we are
> not using GICv2m or GICv3), so is it necessary to have separate msi
> controller node ? Please give me clarity on this.

This has nothing to do with the version of the GIC you are using (XGene
doesn't have GICv2m or v3 either). This is about reducing code
duplication and having something that we can maintain. See also
https://lkml.org/lkml/2015/9/20/193 for yet another example.

I still plan to kill msi_controller, and I'd like to avoid more
dependencies with it. MSI domains are the way to do it.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "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 v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

[Harvey Hunt]

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>;
+
+   ingenic,nemc-tAS = <10>;
+   ingenic,nemc-tAH = <5>;
+   ingenic,nemc-tBP = <10>;
+   ingenic,nemc-tAW = <15>;
+   ingenic,nemc-tSTRV = <100>;
+
+   ingenic,bch-controller = <>;
+   ingenic,ecc-size = <1024>;
+   ingenic,ecc-strength = <24>;
+
+   nand-ecc-mode = "hw";
+   nand-on-flash-bbt;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   partition@0 {
+   label = "u-boot-spl";
+   reg = <0x0 0x0 0x0 0x80>;
+   };
+
+   partition@0x80 {
+   label = "u-boot";
+   reg = <0x0 0x80 0x0 0x20>;
+   };
+
+   partition@0xa0 {
+   label = "u-boot-env";
+   reg = <0x0 0xa0 0x0 0x20>;
+   };
+
+   partition@0xc0 {
+   label = "boot";
+   reg = <0x0 0xc0 0x0 0x400>;
+   };
+
+   partition@0x8c0 {
+   label = "system";
+   reg = <0x0 0x4c0 0x1 0xfb40>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi 
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index 65389f6..b868b42 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -108,4 +108,30 @@
 
status = "disabled";
};
+
+   nemc: nemc@1341 {
+   compatible = "ingenic,jz4780-nemc";
+   reg = <0x1341 0x1>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <1 0 0x1b00 0x100
+ 2 0 0x1a00 0x100
+ 3 0 0x1900 0x100
+ 4 0 0x1800 0x100
+ 5 0 0x1700 0x100
+ 6 0 0x1600 0x100>;
+
+   clocks = < JZ4780_CLK_NEMC>;
+
+   status = "disabled";
+   };
+
+   bch: bch@134d {
+   compatible = "ingenic,jz4780-bch";
+   reg = <0x134d 0x1>;
+
+   clocks = < JZ4780_CLK_BCH>;
+
+   status = "disabled";
+   };
 };
-- 
2.6.0

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

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

[Daniel Walker]

It looks like there's some seepage of cmdline stuff into
the generic device tree code. This conflicts with the
generic cmdline implementation so I remove it in the case
when that's enabled.

Cc: xe-ker...@external.cisco.com
Cc: Daniel Walker 
Signed-off-by: Daniel Walker 
---
 drivers/of/fdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 6e82bc42..80f1e48 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -953,7 +953,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, 
const char *uname,
 * managed to set the command line, unless CONFIG_CMDLINE_FORCE
 * is set in which case we override whatever was found earlier.
 */
-#ifdef CONFIG_CMDLINE
+#if defined(CONFIG_CMDLINE) && !defined(CONFIG_GENERIC_CMDLINE)
 #ifndef CONFIG_CMDLINE_FORCE
if (!((char *)data)[0])
 #endif
-- 
2.1.4

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

Re: [PATCH v2] arm64: dts: add all hi6220 uart nodes

[Arnd Bergmann]

On Wednesday 30 September 2015 18:19:48 Tyler Baker wrote:
> This patch adds all UART nodes for the Hi6220 SoC. Recently a board[1] has
> been developed to standardize UART access across all the 96boards consumer
> edition boards. To use this hardware on HiKey we must configure and enable
> UART3. However, to ensure backward compatibility we must keep UART0 enabled
> as well.
> 
> I have removed the hard coded clock index values in favor of using the ones
> already defined in include/dt-bindings/clock/hi6220-clock.h.
> 
> Since UART0 needs to be soldered, it has been suggested to use the UART3 as
> the default console.
> 
> This patch was boot tested on top of next-20150930, with both UART
> configurations.
> 
> [1] http://www.seeedstudio.com/depot/96Boards-UART-p-2525.html?ref=newInBazaar
> 
> Signed-off-by: Tyler Baker 
> 

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/3] dt-bindings: Add document of Rockchip mailbox

[Rob Herring]

On Mon, Sep 14, 2015 at 6:06 AM, Caesar Wang  wrote:
> This add the necessary binding documentation for mailbox
> found on RK3368 SoC.
>
> Signed-off-by: Caesar Wang 
> ---
>
>  .../bindings/mailbox/rockchip-mailbox.txt  | 33 
> ++
>  1 file changed, 33 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
>
> diff --git a/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt 
> b/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
> new file mode 100644
> index 000..b9b4768
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/rockchip-mailbox.txt
> @@ -0,0 +1,33 @@
> +Rockchip mailbox
> +
> +The Rockchip mailbox is used by the Rockchip CPU cores to communicate
> +requests to MCU processor.
> +
> +Refer to ./mailbox.txt for generic information about mailbox device-tree
> +bindings.
> +
> +Required properties:
> +
> + - compatible: should be one of the following.
> +   - "rockchip,rk3368-mbox" for rk3368
> + - reg: physical base address of the controller and length of memory mapped
> +   region.
> +   physical base address of the share buffer and length of memory mapped

s/share/shared/

> +   region.
> + - interrupts: The interrupt number to the cpu. The interrupt specifier 
> format
> +   depends on the interrupt controller.

Need to specify the value of #mbox-cells.

> +
> +Example:
> +
> +
> +/* RK3368 */
> +mbox: mbox@ff6b {
> +   compatible = "rockchip,rk3368-mailbox";
> +   reg = <0x0 0xff6b 0x0 0x1000>,
> + <0x0 0xff8cf000 0x0 0x1000>; /* the end 4k of sram */

If this is just onchip SRAM usable for anything, then use the SRAM
binding (misc/sram.txt). It has provisions for defining the use.

> +   interrupts = ,
> +,
> +,
> +;
> +   #mbox-cells = <1>;
> +};
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html