[PATCH 1/3] ahci: qoriq: Rename LS2085A SoC support code to LS2080A

[Tang Yuantian]

Freescale is renaming the LS2085A SoC to LS2080A.
This patch addresses the same.

Signed-off-by: Tang Yuantian 
---
 Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt | 2 +-
 drivers/ata/ahci_qoriq.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt 
b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
index b614e3b..3aafe27 100644
--- a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
@@ -3,7 +3,7 @@ Binding for Freescale QorIQ AHCI SATA Controller
 Required properties:
   - reg: Physical base address and size of the controller's register area.
   - compatible: Compatibility string. Must be 'fsl,-ahci', where
-chip could be ls1021a, ls2085a, ls1043a etc.
+chip could be ls1021a, ls2080a, ls1043a etc.
   - clocks: Input clock specifier. Refer to common clock bindings.
   - interrupts: Interrupt specifier. Refer to interrupt binding.
 
diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index 58c1a94..b9b691e 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -45,7 +45,7 @@
 enum ahci_qoriq_type {
AHCI_LS1021A,
AHCI_LS1043A,
-   AHCI_LS2085A,
+   AHCI_LS2080A,
 };
 
 struct ahci_qoriq_priv {
@@ -57,7 +57,7 @@ struct ahci_qoriq_priv {
 static const struct of_device_id ahci_qoriq_of_match[] = {
{ .compatible = "fsl,ls1021a-ahci", .data = (void *)AHCI_LS1021A},
{ .compatible = "fsl,ls1043a-ahci", .data = (void *)AHCI_LS1043A},
-   { .compatible = "fsl,ls2085a-ahci", .data = (void *)AHCI_LS2085A},
+   { .compatible = "fsl,ls2080a-ahci", .data = (void *)AHCI_LS2080A},
{},
 };
 MODULE_DEVICE_TABLE(of, ahci_qoriq_of_match);
@@ -159,7 +159,7 @@ static int ahci_qoriq_phy_init(struct ahci_host_priv *hpriv)
break;
 
case AHCI_LS1043A:
-   case AHCI_LS2085A:
+   case AHCI_LS2080A:
writel(AHCI_PORT_PHY_1_CFG, reg_base + PORT_PHY1);
break;
}
-- 
2.1.0.27.g96db324

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

[PATCH 2/3] ahci: qoriq: Disable NCQ on ls2080a SoC

[Tang Yuantian]

NCQ feature can't be used due to the erratum A-008473.
This patch disabled NCQ as a workaround.

Signed-off-by: Tang Yuantian 
---
 drivers/ata/ahci_qoriq.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c
index b9b691e..686d804 100644
--- a/drivers/ata/ahci_qoriq.c
+++ b/drivers/ata/ahci_qoriq.c
@@ -131,7 +131,7 @@ static struct ata_port_operations ahci_qoriq_ops = {
.hardreset  = ahci_qoriq_hardreset,
 };
 
-static const struct ata_port_info ahci_qoriq_port_info = {
+static struct ata_port_info ahci_qoriq_port_info = {
.flags  = AHCI_FLAG_COMMON | ATA_FLAG_NCQ,
.pio_mask   = ATA_PIO4,
.udma_mask  = ATA_UDMA6,
@@ -208,6 +208,12 @@ static int ahci_qoriq_probe(struct platform_device *pdev)
if (rc)
goto disable_resources;
 
+   /* Workaround for ls2080a */
+   if (qoriq_priv->type == AHCI_LS2080A) {
+   hpriv->flags |= AHCI_HFLAG_NO_NCQ;
+   ahci_qoriq_port_info.flags &= ~(ATA_FLAG_NCQ);
+   }
+
rc = ahci_platform_init_host(pdev, hpriv, &ahci_qoriq_port_info,
 &ahci_qoriq_sht);
if (rc)
-- 
2.1.0.27.g96db324

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

[PATCH 3/3] devicetree: bindings: Fixed a few typos

[Tang Yuantian]

There is a few typos in Freescale QorIQ AHCI bindings, This
patch fixed them.

Signed-off-by: Tang Yuantian 
---
 Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt 
b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
index 3aafe27..032a760 100644
--- a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt
@@ -8,8 +8,8 @@ Required properties:
   - interrupts: Interrupt specifier. Refer to interrupt binding.
 
 Optional properties:
-  - dma-coherent: Enable ACHI coherency DMA operation.
-  - reg-names: register area names when there are more then 1 regster area.
+  - dma-coherent: Enable AHCI coherent DMA operation.
+  - reg-names: register area names when there are more than 1 register area.
 
 Examples:
sata@320 {
-- 
2.1.0.27.g96db324

--
To unsubscribe from this list: send the line "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: Enable Exynos RNG module

[Krzysztof Kozlowski]

On 25.10.2015 08:58, Tobias Jakobi wrote:
> Hello Krzysztof,
> 
> 
> Krzysztof Kozlowski wrote:
>> On 20.10.2015 01:11, Tobias Jakobi wrote:
>>> Hello Krzysztof,
>>>
>>> I can confirm that this also works on a Odroid-X2, so I guess it's safe
>>> to enable the PRNG for all Exynos4412-based Odroid devices.
>>
>> Sure, I can send a patch for that. I can test it later also on Odroid-U3.
> Thanks already!
> 
> 
> 
>>> Any chance that you might also take a look at the other hwcrypto stuff
>>> on the SoC ('samsung,exynos4210-secss' compatible)?
>>
>> What do you mean? The s5p-sss driver already supports Device Tree.
> The driver supports DT, but it doesn't really work.
> 
> I'm using the following DT entry to let the driver probe correctly:
> https://github.com/tobiasjakobi/linux-odroid/commit/82c00cddb5cbf89fad994784c28c8125beae8e13
> 
> But the crypto self-test fails on boot:
> alg: skcipher: encryption failed on test 1 for ecb-aes-s5p: ret=22
> 
> 
> Another problems is that SSS and PRNG can't be used at the same time,
> since they both use common hardware resources (I think it was IO).
> 

Thanks for explaining this. I added the issue to the long TODO list but
I don't know when I will be able to dig into this.

If anyone wants to look into this, please go ahead...

Best regards,
Krzysztof

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

Re: [PATCH v4 1/4] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC

[Krzysztof Kozlowski]

On 29.10.2015 13:58, Alim Akhtar wrote:
> From: Thomas Abraham 
> 
> Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device
> is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators.
> 
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Thomas Abraham 
> Signed-off-by: Alim Akhtar 
> Reviewed-by: Krzysztof Kozlowski 
> Acked-by: Lee Jones 
> ---
>  Documentation/devicetree/bindings/mfd/s2mps11.txt |   23 
> ++---
>  1 file changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
> b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> index 890f0b0e1643..c0427c9d0886 100644
> --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
> +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> @@ -1,5 +1,5 @@
>  
> -* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current Regulator
> +* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator
>  
>  The Samsung S2MPS11 is a multi-function device which includes voltage and
>  current regulators, RTC, charger controller and other sub-blocks. It is
> @@ -7,8 +7,12 @@ interfaced to the host controller using an I2C interface. 
> Each sub-block is
>  addressed by the host system using different I2C slave addresses.
>  
>  Required properties:
> -- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic"
> -   or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic".
> +- compatible: Should be one of the following
> + - "samsung,s2mps11-pmic"
> + - "samsung,s2mps13-pmic"
> + - "samsung,s2mps14-pmic"
> + - "samsung,s2mps15-pmic"
> + - "samsung,s2mpu02-pmic".
>  - reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
>  
>  Optional properties:
> @@ -24,7 +28,7 @@ Optional properties:
>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
> +- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) 
> buffered 32.768
>KHz outputs, so to register these as clocks with common clock framework
>instantiate a sub-node named "clocks". It uses the common clock binding
>documented in :
> @@ -37,12 +41,13 @@ Optional nodes:
>  the clock which they consume.
>  Clock   ID   Devices
>  --
> -32KhzAP  0S2MPS11, S2MPS13, S2MPS14, S5M8767
> -32KhzCP  1S2MPS11, S2MPS13, S5M8767
> -32KhzBT  2S2MPS11, S2MPS13, S2MPS14, S5M8767
> +32KhzAP  0S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767
> +32KhzCP  1S2MPS11, S2MPS13, S2MPS15, S5M8767
> +32KhzBT  2S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767
>  
>- compatible: Should be one of: "samsung,s2mps11-clk", 
> "samsung,s2mps13-clk",
> - "samsung,s2mps14-clk", "samsung,s5m8767-clk"
> + "samsung,s2mps14-clk", "samsung,s2mps15-clk",
> + "samsung,s5m8767-clk"

N. Why "samsung,s2mps15-clk"?

Adding a new compatible to bindings is a major change so my review tag
(from v1 where there was no such compatible) should be dropped. Please
drop it.

Best regards,
Krzysztof

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

[PATCH v4 1/4] dt-bindings: mfd: s2mps11: add documentation for s2mps15 PMIC

[Alim Akhtar]

From: Thomas Abraham 

Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device
is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators.

Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Abraham 
Signed-off-by: Alim Akhtar 
Reviewed-by: Krzysztof Kozlowski 
Acked-by: Lee Jones 
---
 Documentation/devicetree/bindings/mfd/s2mps11.txt |   23 ++---
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt 
b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index 890f0b0e1643..c0427c9d0886 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -1,5 +1,5 @@
 
-* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current Regulator
+* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator
 
 The Samsung S2MPS11 is a multi-function device which includes voltage and
 current regulators, RTC, charger controller and other sub-blocks. It is
@@ -7,8 +7,12 @@ interfaced to the host controller using an I2C interface. Each 
sub-block is
 addressed by the host system using different I2C slave addresses.
 
 Required properties:
-- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic"
- or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic".
+- compatible: Should be one of the following
+   - "samsung,s2mps11-pmic"
+   - "samsung,s2mps13-pmic"
+   - "samsung,s2mps14-pmic"
+   - "samsung,s2mps15-pmic"
+   - "samsung,s2mpu02-pmic".
 - reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
 
 Optional properties:
@@ -24,7 +28,7 @@ Optional properties:
   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
+- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) 
buffered 32.768
   KHz outputs, so to register these as clocks with common clock framework
   instantiate a sub-node named "clocks". It uses the common clock binding
   documented in :
@@ -37,12 +41,13 @@ Optional nodes:
 the clock which they consume.
 Clock   ID   Devices
 --
-32KhzAP0S2MPS11, S2MPS13, S2MPS14, S5M8767
-32KhzCP1S2MPS11, S2MPS13, S5M8767
-32KhzBT2S2MPS11, S2MPS13, S2MPS14, S5M8767
+32KhzAP0S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767
+32KhzCP1S2MPS11, S2MPS13, S2MPS15, S5M8767
+32KhzBT2S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767
 
   - compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps13-clk",
-   "samsung,s2mps14-clk", "samsung,s5m8767-clk"
+   "samsung,s2mps14-clk", "samsung,s2mps15-clk",
+   "samsung,s5m8767-clk"
 
 - regulators: The regulators of s2mps11 that have to be instantiated should be
 included in a sub-node named 'regulators'. Regulator nodes included in this
@@ -90,6 +95,7 @@ as per the datasheet of s2mps11.
- S2MPS11: 1 to 38
- S2MPS13: 1 to 40
- S2MPS14: 1 to 25
+   - S2MPS15: 1 to 27
- S2MPU02: 1 to 28
  - Example: LDO1, LDO2, LDO28
- BUCKn
@@ -97,6 +103,7 @@ as per the datasheet of s2mps11.
- S2MPS11: 1 to 10
- S2MPS13: 1 to 10
- S2MPS14: 1 to 5
+   - S2MPS15: 1 to 10
- S2MPU02: 1 to 7
  - Example: BUCK1, BUCK2, BUCK9
 
-- 
1.7.10.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 14/15] MIPS: malta: setup RAM regions via DT

[Rob Herring]

On Fri, May 22, 2015 at 10:51 AM, Paul Burton  wrote:
> Move memory configuration to be performed via device tree for the Malta
> board. This moves more Malta specific code to malta-dtshim.c, leaving
> the rest of the mti-malta code a little more board-agnostic. This will
> be useful to share more code between boards, with the device tree
> providing the board specifics as intended.
>
> Since we can't rely upon Malta boards running a bootloader capable of
> handling devictrees & filling in the required information, the
> malta_dt_shim code is extended to consume the (e)memsize variables
> provided as part of the bootloader environment (or on the kernel command
> line) then generate the DT memory node using the provided values.

IMO, I think this all belongs in a shim outside of the kernel. This is
how ARM and powerpc generally deal with old or broken bootloaders. But
then MIPS is such a mess of DT code with every platform doing things
their own way.

Rob

>
> Signed-off-by: Paul Burton 
> ---
>
>  arch/mips/boot/dts/mti/malta.dts   |   4 ++
>  arch/mips/mti-malta/malta-dtshim.c | 104 
> +
>  arch/mips/mti-malta/malta-memory.c |  88 ---
>  3 files changed, 108 insertions(+), 88 deletions(-)
>
> diff --git a/arch/mips/boot/dts/mti/malta.dts 
> b/arch/mips/boot/dts/mti/malta.dts
> index 9720c66..2fe2364 100644
> --- a/arch/mips/boot/dts/mti/malta.dts
> +++ b/arch/mips/boot/dts/mti/malta.dts
> @@ -1,5 +1,9 @@
>  /dts-v1/;
>
> +/memreserve/ 0x 0x1000;/* reserved */
> +/memreserve/ 0x1000 0x000ef000;/* YAMON */
> +/memreserve/ 0x000f 0x0001;/* PIIX4 ISA memory */
> +
>  #include 
>  #include 
>
> diff --git a/arch/mips/mti-malta/malta-dtshim.c 
> b/arch/mips/mti-malta/malta-dtshim.c
> index ca33201..9074951 100644
> --- a/arch/mips/mti-malta/malta-dtshim.c
> +++ b/arch/mips/mti-malta/malta-dtshim.c
> @@ -20,6 +20,109 @@
>
>  static unsigned char fdt_buf[16 << 10] __initdata;
>
> +/* determined physical memory size, not overridden by command line args  
>*/
> +extern unsigned long physical_memsize;
> +
> +#define MAX_MEM_ARRAY_ENTRIES 1
> +
> +static unsigned __init gen_fdt_mem_array(__be32 *mem_array, unsigned long 
> size)
> +{
> +   unsigned long size_preio;
> +   unsigned entries;
> +
> +   entries = 1;
> +   mem_array[0] = cpu_to_be32(PHYS_OFFSET);
> +   if (config_enabled(CONFIG_EVA)) {
> +   mem_array[1] = cpu_to_be32(PHYS_OFFSET + size);
> +   } else {
> +   size_preio = min_t(unsigned long, size, 256 << 20);
> +   mem_array[1] = cpu_to_be32(PHYS_OFFSET + size_preio);
> +   }
> +
> +   BUG_ON(entries > MAX_MEM_ARRAY_ENTRIES);
> +   return entries;
> +}
> +
> +static void __init append_memory(void *fdt, int root_off)
> +{
> +   __be32 mem_array[2 * MAX_MEM_ARRAY_ENTRIES];
> +   unsigned long memsize;
> +   unsigned mem_entries;
> +   int i, err, mem_off;
> +   char *var, param_name[10], *var_names[] = {
> +   "ememsize", "memsize",
> +   };
> +
> +   /* if a memory node already exists, leave it alone */
> +   mem_off = fdt_path_offset(fdt, "/memory");
> +   if (mem_off >= 0)
> +   return;
> +
> +   /* find memory size from the bootloader environment */
> +   for (i = 0; i < ARRAY_SIZE(var_names); i++) {
> +   var = fw_getenv(var_names[i]);
> +   if (!var)
> +   continue;
> +
> +   err = kstrtoul(var, 0, &physical_memsize);
> +   if (!err)
> +   break;
> +
> +   pr_warn("Failed to read the '%s' env variable '%s'\n",
> +   var_names[i], var);
> +   }
> +
> +   if (!physical_memsize) {
> +   pr_warn("The bootloader didn't provide memsize: defaulting to 
> 32MB\n");
> +   physical_memsize = 32 << 20;
> +   }
> +
> +   if (config_enabled(CONFIG_CPU_BIG_ENDIAN)) {
> +   /*
> +* SOC-it swaps, or perhaps doesn't swap, when DMA'ing
> +* the last word of physical memory.
> +*/
> +   physical_memsize -= PAGE_SIZE;
> +   }
> +
> +   /* default to using all available RAM */
> +   memsize = physical_memsize;
> +
> +   /* allow the user to override the usable memory */
> +   for (i = 0; i < ARRAY_SIZE(var_names); i++) {
> +   snprintf(param_name, sizeof(param_name), "%s=", var_names[i]);
> +   var = strstr(arcs_cmdline, param_name);
> +   if (!var)
> +   continue;
> +
> +   memsize = memparse(var + strlen(param_name), NULL);
> +   }
> +
> +   /* if the user says there's more RAM than we thought, believe them */
> +   physical_memsize = max_t(unsigned long, physical_memsize, memsize);
> +
> +   /* append memory to the DT */
> +   mem_off = fdt_a

Re: [RFC] rpi: add support to enable usb power domain

[Stephen Warren]

On 10/28/2015 02:40 PM, Alexander Aring wrote:
> This patch adds support for RPi several Power Domains and enable support
> to enable the USB Power Domain when it's not enabled before.
> 
> This patch based on Eric Anholt's patch to support Power Domains. He had
> an issue about -EPROBE_DEFER inside the power domain subsystem, this
> issue was solved by commit <311fa6a> ("PM / Domains: Return -EPROBE_DEFER
> if we fail to init or turn-on domain").

> diff --git 
> a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt 
> b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt

>  firmware {
>   compatible = "raspberrypi,bcm2835-firmware";
>   mboxes = <&mailbox>;
> + #power-domain-cells = <1>;
> +};

I would have expected a separate DT node for the power domains driver
that referenced the firmware node by phandle. I believe that's why the
firmware node exports mailboxes to other drivers. If the firmware driver
was going to implement all the features directly, it wouldn't need to
act as a mailbox provider, since all the mailbox programming would be
internal.

> diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c

> +#define RPI_POWER_DOMAIN(_domain, _name) \
> + [_domain] = \
> + {   \

I'd expect { wrapped onto the previous line.

> +static int raspberrypi_firmware_set_power(struct rpi_firmware *fw,
> +   u32 domain, bool on)

> + packet.on = on;
> + ret = rpi_firmware_property(fw, RPI_FIRMWARE_SET_POWER_STATE, &packet,
> + sizeof(packet));
> + if (!ret && !packet.on)
> + ret = -EINVAL;

The error is only reported for power off requests?

> +/* Asks the firmware to if power is on for a specific power domain. */
> +static int raspberrypi_firmware_power_is_on(struct rpi_firmware *fw,
> + u32 domain)

> + packet.domain = domain;
> + ret = rpi_firmware_property(fw, RPI_FIRMWARE_GET_POWER_STATE, &packet,
> + sizeof(packet));
> + if (ret < 0)
> + return ret;

Hmm. If rpi_firmware_property() returns <0 on error, I'm confused what
the test I commented on above is intended to do.

> +/*
> + * IMPORTANT: be sure this array has no entries which are not specified
> + * between others by RPI_POWER_DOMAIN, otherwise mapping between
> + * generic_pm_domain array doesn't work anymore.
> + */

"has no entries which are not specified between others by
RPI_POWER_DOMAIN" might be better phrased as "is contiguous" or
"contains only contiguous entries".

> @@ -208,15 +312,44 @@ static int rpi_firmware_probe(struct platform_device 
> *pdev)

> + for (i = 0; i < num_domains; i++) {
> + bool is_off;
> +
> + rpi_power_domains[i].fw = fw;
> + power_domains[i] = &rpi_power_domains[i].base;
> +
> + /* get the initial state */
> + ret = raspberrypi_firmware_power_is_on(fw, i);
> + if (ret < 0)
> + goto mbox;

The label name "mbox" doesn't give a clue that it's an error handler.
"free_mbox" might be better.

> +mbox:
> + mbox_free_channel(fw->chan);
> + return ret;
>  }

Does the pm_genpd_init() call for all the power domains need to be
undone at all?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 22/22] of/platform: Defer probes of registered devices

[Rob Herring]

On Wed, Oct 28, 2015 at 9:40 AM, Tomeu Vizoso
 wrote:
> On 22 October 2015 at 23:27, Scott Wood  wrote:
>> On Thu, 2015-10-22 at 15:04 +0200, Tomeu Vizoso wrote:
>>> On 22 October 2015 at 00:51, Scott Wood  wrote:
>>> > On Wed, 2015-10-21 at 08:44 -0500, Rob Herring wrote:
>>> > > On Wed, Oct 21, 2015 at 12:54 AM, Scott Wood 
>>> > > wrote:
>>> > > > On Mon, 2015-09-21 at 16:03 +0200, Tomeu Vizoso wrote:
>>> > > > > Instead of trying to match and probe platform and AMBA devices right
>>> > > > > after each is registered, delay their probes until
>>> > > > > device_initcall_sync.
>>> > > > >
>>> > > > > This means that devices will start probing once all built-in drivers
>>> > > > > have registered, and after all platform and AMBA devices from the DT
>>> > > > > have been registered already.
>>> > > > >
>>> > > > > This allows us to prevent deferred probes by probing dependencies on
>>> > > > > demand.
>>> > > > >
>>> > > > > Signed-off-by: Tomeu Vizoso 
>>> > > > > ---
>>> > > > >
>>> > > > > Changes in v4:
>>> > > > > - Also defer probes of AMBA devices registered from the DT as they
>>> > > > > can
>>> > > > >   also request resources.
>>> > > > >
>>> > > > >  drivers/of/platform.c | 11 ---
>>> > > > >  1 file changed, 8 insertions(+), 3 deletions(-)
>>> > > >
>>> > > > This breaks arch/powerpc/sysdev/fsl_pci.c.  The PCI bus is an OF
>>> > > > platform
>>> > > > device, and it must be probed before pcibios_init() which is a
>>> > > > subsys_initcall(), or else the PCI bus never gets scanned.
>>> > >
>>> > > Thanks for the report. This is probably getting dropped, but it could
>>> > > be disabled for PPC.
>>> >
>>> > I don't think that adding another arbitrary arch difference would be the
>>> > right solution.
>>>
>>> I think Rob meant temporarily disable it while things get fixed. At
>>> least,
>>
>> So, what is the permanent fix for the swiotlb issue (or more generally, the
>> inability to have a late_initcall that runs after non-module, non-hotplug
>> platform devices have been probed)?
>
> If the code in pcibios_init() depends on the PCI bus device having
> probed, then I would recommend making that dependency explicit by
> calling of_device_probe() on the OF node of the PCI controller when
> looking it up.
>
>>> I don't see any reason why PPC wouldn't benefit from this
>>> series.
>>
>> It's not clear to me what the benefit of this is at all, much less for PPC.
>> What is the fundamental problem with deferred probes?  In the cover letter
>> you say this change saves 2.3 seconds, but where is that time being consumed?
>>  Are the drivers taking too long in their probe function trying to initialize
>> and then deferring, rather than checking for dependencies up front?  Or are
>> there really so many devices and such a pessimal ordering that most of the
>> time is spent iterating through and reordering the list, with each defer
>> happening quickly?
>
> The problem is that a device that defers its probe is currently sent
> to the back of the queue, and that's undesired in some use cases in
> which there's a device that should be up as soon as possible during
> boot (and boot takes a long time). So the goal is to change the order
> in which devices with dependencies end up probing.
>
>> Even if something different does need to be done at this level, forcing all
>> OF platform devices to be probed at the late_initcall level seems quite
>> intrusive.  You limited it to OF because people complained that other things
>> will break.  Things still broke.  Surely there's a better way to address the
>> problem.  Can't the delay be requested by drivers that might otherwise need
>> to defer (which could be done incrementally, focusing on the worst
>> performance problems), rather than enabling it for everything?
>
> Yes, given the amount of breakage that's a sensible option. But in any
> case and even if this series is most likely to be dropped, I recommend
> to make explicit as many implicit dependencies as possible.

It is dropped for now, but I expect much of this to still integrate
with Rafael's proposal. However, it will need to be opt-in it seems.
That is somewhat unfortunate because things like async probe are
opt-in and seem to rarely get used. As to how we can make it opt-in, I
think we can make of_platform_populate() callable multiple times at
the root level. This will allow a platform to skip calling it and then
a late call to it can register the devices after drivers have
registered. This late call will then be a nop for platforms that don't
opt-in and call of_platform_populate themselves.

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

Re: [PATCH] of/fdt: fix error checking for earlycon address

[Rob Herring]

On Fri, Oct 23, 2015 at 6:47 AM, Masahiro Yamada
 wrote:
> fdt_translate_address() returns OF_BAD_ADDR on error.  It is defined as
> a u64 value, so the variable "addr" should be defined as u64 as well.
>
> Fixes: fb11ffe74c79 ("of/fdt: add FDT serial scanning for earlycon")
> Signed-off-by: Masahiro Yamada 

Applied, thanks.

Rob

> ---
>
>  drivers/of/fdt.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 9fc3568..196e449 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -822,14 +822,15 @@ static int __init early_init_dt_scan_chosen_serial(void)
> return -ENODEV;
>
> while (match->compatible[0]) {
> -   unsigned long addr;
> +   u64 addr;
> +
> if (fdt_node_check_compatible(fdt, offset, 
> match->compatible)) {
> match++;
> continue;
> }
>
> addr = fdt_translate_address(fdt, offset);
> -   if (!addr)
> +   if (addr == OF_BAD_ADDR)
> return -ENXIO;
>
> of_setup_earlycon(addr, match->data);
> --
> 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 v12 3/6] fpga: add simple-fpga-bus

[Rob Herring]

On Wed, Oct 28, 2015 at 11:18 AM, Josh Cartwright  wrote:
> On Wed, Oct 28, 2015 at 08:37:51AM -0700, Moritz Fischer wrote:
>> On Wed, Oct 28, 2015 at 3:07 AM, Josh Cartwright  wrote:
>> > On Tue, Oct 27, 2015 at 05:09:12PM -0500, at...@opensource.altera.com 
>> > wrote:
>> >> From: Alan Tull 
>> >>
>> >> The Simple FPGA bus uses the FPGA Manager Framework and the
>> >> FPGA Bridge Framework to provide a manufactorer-agnostic
>> >> interface for reprogramming FPGAs that is Device Tree
>> >> Overlays-based.
>> >
>> > Do you intend the "simple-fpga-bus" to be used on Zynq as well?  The
>> > whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq at
>> > all, from what I can tell.
>>
>> For Zynq the zynq-fpga driver takes care of the level shifters on full
>> reconfiguration,
>> and doesn't for partial reconfiguration. Now depending on which parts
>> of the fabric
>> are partial reconfigured (say AXI masters), one might run into issues
>> with a setup like that.
>>
>> My first plan was to counter that by using zynq-reset to hold the
>> reset high during
>> reconfiguration of that part of the FPGA.
>>
>> I'm happy to rethink that part and maybe redo the level shifters and
>> resets together in a bridge
>> driver under devicetree control gives finer grained control.
>
> There is already a framework which is used to describe and manipulate
> level shifting/other IO properties, and that is pinctrl, and if we
> wanted to use an appropriate abstraction, I think pinctrl would be the
> best bet.

I'm not all that familiar with FPGAs, but using pinctrl seems like
overkill to me. We're talking about isolating things while doing
reconfiguration, right? That seems more similar to power domain
controls than I/O pin control to me.

> Implementing the FPGA Bridge interface in the Zynq driver because it's
> what the core expects is just backwards.  It's an abstraction inversion.

+1

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

{{ U.N.O/W.B.O }}

[U / N]

Please view the attached file for your payment code.

United Nations Compensation Unit.pdf
Description: Adobe PDF document

Re: [PATCH v12 0/8] PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05

[Zhou Wang]

On 2015/10/28 6:32, Bjorn Helgaas wrote:
> Hi Zhou,
> 
> On Mon, Oct 26, 2015 at 07:35:42PM +0800, Zhou Wang wrote:
>> This patchset adds PCIe host support for HiSilicon SoC Hip05. The PCIe hosts
>> use PCIe IP core from Synopsys, So this driver is based on designware PCIe 
>> driver.
>>
>> Hip05 is an ARMv8 architecture SoC. It should be able to use ARM64 PCIe API 
>> in
>> designware PCIe driver. So this patch also adds ARM64 support for designware
>> pcie.
>>
>> This patchset is based on v4.3-rc1.
> 
> OK, this is pretty close to being ready to go.  But the patch ordering is
> more complicated than it needs to be.  You have:
> 
>   PCI: designware: move calculation of bus addresses to DRA7xx
>   ARM/PCI: remove align_resource in pci_sys_data
>   PCI: designware: Replace DT PCI ranges parse with 
> of_pci_get_host_bridge_resources
>   PCI: designware: Add ARM64 support
>   PCI: designware: Remove *_mod_base
>   PCI: hisi: Add PCIe host support for HiSilicon SoC Hip05
>   Documentation: DT: Add HiSilicon PCIe host binding
>   MAINTAINERS: Add pcie-hisi maintainer
> 
> But you should have this:
> 
>   PCI: designware: Move calculation of bus addresses to DRA7xx
>   PCI: designware: Remove *_mod_base
>   PCI: designware: Replace DT PCI ranges parse with 
> of_pci_get_host_bridge_resources
>   ARM/PCI: remove align_resource in pci_sys_data
>   PCI: designware: Add ARM64 support
>   PCI: hisi: Add HiSilicon SoC Hip05 driver
>

Hi Bjorn,

I will reorder patchset in new version.
In fact, a temporary variable need to be introduced to solve a problem,
will show this in new version.

> In other words,
> 
>   - capitalize the subject lines correctly (follow previous practice),
>   - do all the bus address patches together,
>   - then the ARM sysdata tweak,
>   - then add ARM64 support,
>   - then add HiSilicon,
>   - and merge the hisi driver, DT update, and maintainer update into one
> patch since they're all one package.

OK, will merge driver, DT binding, maintainer update into one patch.

Thanks,
Zhou

> 
> If you do them out of order, the changes get tangled up and it makes them
> harder to backport and harder to revert individually.
> 
> Bjorn
> 
>> Change from v11:
>> - Split 3/6 in v11 to 3/8, 4/8, 5/8 in v12.
>> - Add print in pcie-hisi.c to indicate read/write hardware defect.
>> - Modify macro in 1/8 pointed by Bjorn.
>>
>> Change from v10:
>> - Remove MSI related setting and VMID/ASID table setting, they will be
>>   implemented in BIOS.
>> - Use module_platform_driver to init pcie-hisi.c
>> - Add necessary comments.
>>
>> Change from v9:
>> - Use syscon to get subctrl base address.
>> - 5/6 is based on [PATCH v3 0/2] arm64: Support Hisilicon Hip05-D02 board
>>   from Ding Tianhong
>> - Add hisi_pcie_cfg_read in pcie-hisi.c to match
>>   [PATCH v6 0/3] PCI: designware: change dw_pcie_cfg_write() and 
>> dw_pcie_cfg_read()
>>   from Gabriele.
>>
>> Change from v8:
>> - Rebase on v4.3-rc1.
>> - Add Tested-by from Gabriel and Minghuan.
>> - Remove ITS domain parsing in msi_host_init in pcie-hisi.c, no need this as 
>> PCI
>>   core does related job. Add ITS base address parsing in msi_host_init.
>> - Change vmid/asid table configuration, previous configuration was wrong.
>> - Add wr_own_conf callback in pcie-hisi.c.
>> - Use subsys_initcall to init hisi PCIe.
>>
>> Change from v7:
>> - Remove pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone, layerscape,
>>   spear13xx. Pass pp->busn->start to pci_create_root_bus as root bus number.
>> - Remove bus-range parsing in pcie-hisi.c.
>>
>> Change from v6:
>> - Add Pratyush's Acked-by for 1/6 and 2/6.
>> - Add James' Tested-by for 3/6.
>>
>> Change from v5:
>> - Merge 1/6 in this series, discussion about this can be found in [1]
>>
>> Change from v4:
>> - Change the author of 1/5 to Gabriele.
>> - Modify problems in 3/5 pointed by Bjorn.
>> - Modify spelling problems in 4/5.
>>
>> Change from v3:
>> - Change 1/5 to what Gabriele suggested.
>> - Use win->__res.start to get *_mod_base in 2/5, this fix a bug in v3 series.
>>
>> Change from v2:
>> - Move struct pci_dev *dev and struct pci_sys_data *sys in
>>   pcibios_align_resource in 1/5.
>> - Add Gabriele's codes in 2/5 which delete unnecessary information parse and
>>   use of_pci_get_host_bridge_resources for both ARM32 and ARM64.
>> - Add maintainer patch 5/5.
>>
>> Change from RFC v1:
>> - Add 1/4 patch by Arnd which removes align_resource callback in ARM
>>   pcibios_align_resource.
>> - Change head file in pcie-designware from asm/hardirq.h to linux/hardirq.h.
>> - Set pp->root_bus_nr = 0 in dra7xx, exynos, imx6, keystone, layerscape,
>>   spear13xx.
>> - Remove unnecessary parentheses of some macros in pcie-hisi.
>> - Use macro to replace some magic values.
>> - Merge two loops together and add some comments about it in context_config
>>   function in pcie-hisi.
>> - Modify some value of items in pcie node example in binding document. 
>>
>> Change from RFC:
>> - delete dw_pcie_setup, dw_pcie_scan_b

RE:

Hello,

I am Major. Alan Edward, in the military unit here in Afghanistan and i need an 
urgent assistance with someone i can trust,It's risk free and legal.

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

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

Re: [RFC PATCH v8 10/10] arm: zx_defconfig: remove CONFIG_MMC_DW_IDMAC

[Jaehoon Chung]

Hi, All.

Is there any other opinion about this patch?


Best Regards,
Jaehoon Chung

On 09/16/2015 03:43 PM, Shawn Lin wrote:
> DesignWare MMC Controller's transfer mode should be decided
> at runtime instead of compile-time. So we remove this config
> option and read dw_mmc's register to select DMA master.
> 
> Signed-off-by: Shawn Lin 
> ---
> 
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/configs/zx_defconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/configs/zx_defconfig b/arch/arm/configs/zx_defconfig
> index b200bb0..ab683fb 100644
> --- a/arch/arm/configs/zx_defconfig
> +++ b/arch/arm/configs/zx_defconfig
> @@ -83,7 +83,6 @@ CONFIG_MMC=y
>  CONFIG_MMC_UNSAFE_RESUME=y
>  CONFIG_MMC_BLOCK_MINORS=16
>  CONFIG_MMC_DW=y
> -CONFIG_MMC_DW_IDMAC=y
>  CONFIG_EXT2_FS=y
>  CONFIG_EXT4_FS=y
>  CONFIG_EXT4_FS_POSIX_ACL=y
> 

--
To unsubscribe from this list: send the line "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 v8 09/10] arm: multi_v7_defconfig: remove CONFIG_MMC_DW_IDMAC

[Jaehoon Chung]

Hi, All.

Is there any other opinion about this patch?

Best Regards,
Jaehoon Chung

On 09/16/2015 03:43 PM, Shawn Lin wrote:
> DesignWare MMC Controller's transfer mode should be decided
> at runtime instead of compile-time. So we remove this config
> option and read dw_mmc's register to select DMA master.
> 
> Signed-off-by: Shawn Lin 
> ---
> 
> Changes in v8: None
> Changes in v7: None
> Changes in v6: None
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/configs/multi_v7_defconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/configs/multi_v7_defconfig 
> b/arch/arm/configs/multi_v7_defconfig
> index 03deb7f..ad929ea 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -539,7 +539,6 @@ CONFIG_MMC_ATMELMCI=y
>  CONFIG_MMC_MVSDIO=y
>  CONFIG_MMC_SDHI=y
>  CONFIG_MMC_DW=y
> -CONFIG_MMC_DW_IDMAC=y
>  CONFIG_MMC_DW_PLTFM=y
>  CONFIG_MMC_DW_EXYNOS=y
>  CONFIG_MMC_DW_ROCKCHIP=y
> 

--
To unsubscribe from this list: send the line "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 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Krzysztof Kozlowski]

On 28.10.2015 16:57, Pavel Fedin wrote:
> Add documentation for new properties, allowing bank configuration.
> 
> Signed-off-by: Pavel Fedin 
> ---
>  .../bindings/arm/samsung/exynos-srom.txt   | 24 
> +-
>  1 file changed, 23 insertions(+), 1 deletion(-)

You missed here a lot of potential Cc. Please use get_maintainer.pl
script. It *must* be sent to devicetree list.

Please send it also to DeviceTree maintainers because you are adding
quite generic names for bindings so they may have interesting thoughts
on this.

LKML list is also missing.

> 
> diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt 
> b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> index 33886d5..9e4a40b 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> +++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
> @@ -5,8 +5,30 @@ Required properties:
>  
>  - reg: offset and length of the register set
>  
> -Example:
> +Bank configurations can be defined in optional subnodes. Each subnode
> +describes one bank and contains the following:
> +
> +Required properties:
> +- bank : bank number (0 - 3)

I wonder whether this should be maybe "reg"?

> +
> +- srom-timing : array of 7 integers: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs

Missing "pmc"? Where is the seventh?

This looks vendor specific, so prefix with "samsung,exynos-".

> +
> +Optional properties:
> +- width : data width in bytes (1 or 2). If omitted, default of 1 is used.

This is not bank-width? So data-width? Any vendor prefix here? How
generic is this?

These are first things which came to my mind. Maybe DT maintainers will
come with something more...

Best regards,
Krzysztof

> +
> +Example: basic definition, no banks are configured
> + sromc@1257 {
> + compatible = "samsung,exynos-srom";
> + reg = <0x1257 0x10>;
> + };
> +
> +Example: SROMc with bank3 configuration
>   sromc@1257 {
>   compatible = "samsung,exynos-srom";
>   reg = <0x1257 0x10>;
> + bank@3 {
> + bank = <3>;
> + width = <2>;
> + srom-timing = <1 9 12 1 9 1 1>;
> + };
>   };
> 

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

Re: [PATCH v12 7/8] Documentation: DT: Add HiSilicon PCIe host binding

[Zhou Wang]

On 2015/10/28 3:19, Rob Herring wrote:
> On Mon, Oct 26, 2015 at 6:35 AM, Zhou Wang  wrote:
>> This patch adds related DTS binding document for HiSilicon PCIe host driver.
>>
>> Signed-off-by: Zhou Wang 
> 
> Acked-by: Rob Herring 
>

Thanks for your review.
Zhou

>> ---
>>  .../bindings/arm/hisilicon/hisilicon.txt   | 17 +
>>  .../devicetree/bindings/pci/hisilicon-pcie.txt | 44 
>> ++
>>  2 files changed, 61 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt 
>> b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
>> index 3504dca..6ac7c00 100644
>> --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
>> +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
>> @@ -171,6 +171,23 @@ Example:
>> };
>>
>>  ---
>> +Hisilicon HiP05 PCIe-SAS system controller
>> +
>> +Required properties:
>> +- compatible : "hisilicon,pcie-sas-subctrl", "syscon";
>> +- reg : Register address and size
>> +
>> +The HiP05 PCIe-SAS system controller is shared by PCIe and SAS controllers 
>> in
>> +HiP05 Soc to implement some basic configurations.
>> +
>> +Example:
>> +   /* for HiP05 PCIe-SAS system */
>> +   pcie_sas: system_controller@0xb000 {
>> +   compatible = "hisilicon,pcie-sas-subctrl", "syscon";
>> +   reg = <0xb000 0x1>;
>> +   };
>> +
>> +---
>>  Hisilicon CPU controller
>>
>>  Required properties:
>> diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt 
>> b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
>> new file mode 100644
>> index 000..17c6ed9
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt
>> @@ -0,0 +1,44 @@
>> +HiSilicon PCIe host bridge DT description
>> +
>> +HiSilicon PCIe host controller is based on Designware PCI core.
>> +It shares common functions with PCIe Designware core driver and inherits
>> +common properties defined in
>> +Documentation/devicetree/bindings/pci/designware-pci.txt.
>> +
>> +Additional properties are described here:
>> +
>> +Required properties:
>> +- compatible: Should contain "hisilicon,hip05-pcie".
>> +- reg: Should contain rc_dbi, config registers location and length.
>> +- reg-names: Must include the following entries:
>> +  "rc_dbi": controller configuration registers;
>> +  "config": PCIe configuration space registers.
>> +- msi-parent: Should be its_pcie which is an ITS receiving MSI interrupts.
>> +- port-id: Should be 0, 1, 2 or 3.
> 
> 
>> +
>> +Optional properties:
>> +- status: Either "ok" or "disabled".
>> +- dma-coherent: Present if DMA operations are coherent.
>> +
>> +Example:
>> +   pcie@0xb008 {
>> +   compatible = "hisilicon,hip05-pcie", "snps,dw-pcie";
>> +   reg = <0 0xb008 0 0x1>, <0x220 0x 0 0x2000>;
>> +   reg-names = "rc_dbi", "config";
>> +   bus-range = <0  15>;
>> +   msi-parent = <&its_pcie>;
>> +   #address-cells = <3>;
>> +   #size-cells = <2>;
>> +   device_type = "pci";
>> +   dma-coherent;
>> +   ranges = <0x8200 0 0x 0x220 0x 0 
>> 0x1000>;
>> +   num-lanes = <8>;
>> +   port-id = <1>;
>> +   #interrupts-cells = <1>;
>> +   interrupts-map-mask = <0xf800 0 0 7>;
>> +   interrupts-map = <0x0 0 0 1 &mbigen_pcie 1 10
>> + 0x0 0 0 2 &mbigen_pcie 2 11
>> + 0x0 0 0 3 &mbigen_pcie 3 12
>> + 0x0 0 0 4 &mbigen_pcie 4 13>;
>> +   status = "ok";
>> +   };
>> --
>> 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
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> .
> 


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

[PATCH v9 10/17] phy: Add driver for rockchip Display Port PHY

[Yakir Yang]

Add phy driver for the Rockchip DisplayPort PHY module. This
is required to get DisplayPort working in Rockchip SoCs.

Reviewed-by: Heiko Stuebner 
Signed-off-by: Yakir Yang 
---
Changes in v9:
- Removed the unused the variable "res" in probe function. (Heiko)
- Removed the unused head file.

Changes in v8:
- Fix the mixed spacers on macro definitions. (Heiko)
- Remove the unnecessary empty line after clk_prepare_enable. (Heiko)

Changes in v7:
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)

Changes in v6: None
Changes in v5:
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
  the exist "grf" syscon already. And rename the example DT node from
  "edp_phy: phy@ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
  struct" to "static const struct". And correct the input paramters of
  devm_phy_create() interfaces. (Heiko)

Changes in v4:
- Add commit message, and remove the redundant rockchip_dp_phy_init()
  function, move those code to probe() method. And remove driver .owner
  number. (Kishon)

Changes in v3:
- Suggest, add rockchip dp phy driver, collect the phy clocks and
  power control. (Heiko)

Changes in v2: None

 drivers/phy/Kconfig   |   7 ++
 drivers/phy/Makefile  |   1 +
 drivers/phy/phy-rockchip-dp.c | 151 ++
 3 files changed, 159 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-dp.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 7eb5859d..7355819 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -319,6 +319,13 @@ config PHY_ROCKCHIP_USB
help
  Enable this to support the Rockchip USB 2.0 PHY.
 
+config PHY_ROCKCHIP_DP
+   tristate "Rockchip Display Port PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   help
+ Enable this to support the Rockchip Display Port PHY.
+
 config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 075db1a..b1700cd 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -35,6 +35,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+= 
phy-s5pv210-usb2.o
 obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
 obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..f3e0058
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,151 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GRF_SOC_CON12   0x0274
+
+#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK   BIT(4)
+#define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)
+
+#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK   BIT(21)
+#define GRF_EDP_PHY_SIDDQ_ON0
+#define GRF_EDP_PHY_SIDDQ_OFF   BIT(5)
+
+struct rockchip_dp_phy {
+   struct device  *dev;
+   struct regmap  *grf;
+   struct clk *phy_24m;
+};
+
+static int rockchip_set_phy_state(struct phy *phy, bool enable)
+{
+   struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
+   int ret;
+
+   if (enable) {
+   ret = regmap_write(dp->grf, GRF_SOC_CON12,
+  GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+  GRF_EDP_PHY_SIDDQ_ON);
+   if (ret < 0) {
+   dev_err(dp->dev, "Can't enable PHY power %d\n", ret);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(dp->phy_24m);
+   } else {
+   clk_disable_unprepare(dp->phy_24m);
+
+   ret = regmap_write(dp->grf, GRF_SOC_CON12,
+  GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+  GRF_EDP_PHY_SIDDQ_OFF);
+   }
+
+   return ret;
+}
+
+static int rockchip_dp_phy_power_on(struct phy *phy)
+{
+   return rockchip_set_phy_state(phy, true);
+}
+
+static int rockchip_dp_phy_power_off(struct phy *phy)
+{
+   return rockchip_set_phy_state(phy, false);
+}
+
+static const struct phy_ops rockchip_dp_phy_ops = {
+   .pow

Re: [PATCH v4 2/3] mtd: mtk-nor: mtk serial flash controller driver

[Brian Norris]

Hi Bayi,

I'm looking over your v5, and I still have a lot of comments. I'll send
those soon. But I still question one of your responses here:

On Sun, Oct 18, 2015 at 10:20:35PM +0800, bayi.cheng wrote:
> On Fri, 2015-10-16 at 00:39 -0700, Brian Norris wrote:
> > On Tue, Oct 13, 2015 at 05:39:19PM +0800, Bayi Cheng wrote:

> > > diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c 
> > > b/drivers/mtd/spi-nor/mtk-quadspi.c
> > > new file mode 100644
> > > index 000..c6ac366
> > > --- /dev/null
> > > +++ b/drivers/mtd/spi-nor/mtk-quadspi.c
> > > @@ -0,0 +1,486 @@
[...]
> > > +#define MTK_NOR_CMD_REG  0x00
> > > +#define MTK_NOR_CNT_REG  0x04
> > > +#define MTK_NOR_RDSR_REG 0x08
> > > +#define MTK_NOR_RDATA_REG0x0c
> > > +#define MTK_NOR_RADR0_REG0x10
> > > +#define MTK_NOR_RADR1_REG0x14
> > > +#define MTK_NOR_RADR2_REG0x18
> > > +#define MTK_NOR_WDATA_REG0x1c
> > > +#define MTK_NOR_PRGDATA0_REG 0x20
> > > +#define MTK_NOR_PRGDATA1_REG 0x24
> > > +#define MTK_NOR_PRGDATA2_REG 0x28
> > > +#define MTK_NOR_PRGDATA3_REG 0x2c
> > > +#define MTK_NOR_PRGDATA4_REG 0x30
> > > +#define MTK_NOR_PRGDATA5_REG 0x34

^^ so you have 6 "TX" registers.

> > > +#define MTK_NOR_SHREG0_REG   0x38
> > > +#define MTK_NOR_SHREG1_REG   0x3c
> > > +#define MTK_NOR_SHREG2_REG   0x40
> > > +#define MTK_NOR_SHREG3_REG   0x44
> > > +#define MTK_NOR_SHREG4_REG   0x48
> > > +#define MTK_NOR_SHREG5_REG   0x4c

^^ and you have at least 6 "RX" registers (looking at the mt8173 manual,
I'm not sure what the SHREG{6..9} are for). So I don't see why you can't
program MTK_NOR_CNT_REG to 48 (6 bytes * 8 bits/byte) to get 6 bytes
TX/RX, or IOW, 1 byte of opcode and 5 bytes of either RX or TX data. So
I'm still not convinced about your claim below.

I was able to rewrite your driver to do the above, and I can read out 5
bytes no problem, but unfortunately, the flash device I have has only 3
bytes of ID, so the last two bytes are zero, which doesn't tell me too
much if this is working right.

> > > +#define MTK_NOR_SHREG6_REG   0x50
> > > +#define MTK_NOR_SHREG7_REG   0x54
> > > +#define MTK_NOR_SHREG8_REG   0x58
> > > +#define MTK_NOR_SHREG9_REG   0x5c
> > > +#define MTK_NOR_CFG1_REG 0x60
> > > +#define MTK_NOR_CFG2_REG 0x64
> > > +#define MTK_NOR_CFG3_REG 0x68
> > > +#define MTK_NOR_STATUS0_REG  0x70
> > > +#define MTK_NOR_STATUS1_REG  0x74
> > > +#define MTK_NOR_STATUS2_REG  0x78
> > > +#define MTK_NOR_STATUS3_REG  0x7c
> > > +#define MTK_NOR_FLHCFG_REG   0x84
> > > +#define MTK_NOR_TIME_REG 0x94
> > > +#define MTK_NOR_PP_DATA_REG  0x98
> > > +#define MTK_NOR_PREBUF_STUS_REG  0x9c
> > > +#define MTK_NOR_DELSEL0_REG  0xa0
> > > +#define MTK_NOR_DELSEL1_REG  0xa4
> > > +#define MTK_NOR_INTRSTUS_REG 0xa8
> > > +#define MTK_NOR_INTREN_REG   0xac
> > > +#define MTK_NOR_CHKSUM_CTL_REG   0xb8
> > > +#define MTK_NOR_CHKSUM_REG   0xbc
> > > +#define MTK_NOR_CMD2_REG 0xc0
> > > +#define MTK_NOR_WRPROT_REG   0xc4
> > > +#define MTK_NOR_RADR3_REG0xc8
> > > +#define MTK_NOR_DUAL_REG 0xcc
> > > +#define MTK_NOR_DELSEL2_REG  0xd0
> > > +#define MTK_NOR_DELSEL3_REG  0xd4
> > > +#define MTK_NOR_DELSEL4_REG  0xd8

...

> > > +static int mt8173_nor_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf, 
> > > int len)
> > > +{
> > > + int ret;
> > > + struct mt8173_nor *mt8173_nor = nor->priv;
> > > +
> > > + /* mtk nor controller doesn't supoort SPINOR_OP_RDCR */
> > > + switch (opcode) {
> > > + case SPINOR_OP_RDID:
> > > + /* read JEDEC ID need 4 bytes commands */
> > > + ret = mt8173_nor_set_cmd(mt8173_nor, 0, 32, SPINOR_OP_RDID);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > > + /* mtk nor flash controller only support 3 bytes IDs */
> > 
> > Are you absolutely sure of this? That would be highly unfortunate, but
> > I also don't believe it's true.
> > 
> Yes, for this issue I have asked our designer of nor flash controller,
> unfortunately, it is true, and I have tried to read more IDs, but our
> controller just accept 3 IDs from nor flash, and our next generation IC
> may solve this problem.

How exactly did you try? Did you do what I suggested above? Are the
"shift registers" not all actually functional?

> > > + buf[2] = readb(mt8173_nor->base + MTK_NOR_SHREG0_REG);
> > > + buf[1] = readb(mt8173_nor->base + MTK_NOR_SHREG1_REG);
> > > + buf[0] = readb(mt8173_nor->base + MTK_NOR_SHREG2_REG);
> > > + break;

[...]

Brian

Re: [PATCH v8 10/17] phy: Add driver for rockchip Display Port PHY

[Yakir Yang]

Hi Heiko,

On 10/29/2015 04:36 AM, Heiko Stuebner wrote:

Hi Yakir,

Am Mittwoch, 28. Oktober 2015, 16:30:33 schrieb Yakir Yang:

+static int rockchip_dp_phy_probe(struct platform_device *pdev)
+{
+   struct device *dev = &pdev->dev;
+   struct device_node *np = dev->of_node;
+   struct phy_provider *phy_provider;
+   struct rockchip_dp_phy *dp;
+   struct resource *res;

drivers/phy/phy-rockchip-dp.c: In function 'rockchip_dp_phy_probe':
drivers/phy/phy-rockchip-dp.c:86:19: warning: unused variable 'res' 
[-Wunused-variable]


Oh, thanks, would send v9 of this one alone.

- Yakir


+   struct phy *phy;
+   int ret;
+
+   if (!np)
+   return -ENODEV;
+
+   dp = devm_kzalloc(dev, sizeof(*dp), GFP_KERNEL);
+   if (IS_ERR(dp))
+   return -ENOMEM;
+
+   dp->dev = dev;
+
+   dp->phy_24m = devm_clk_get(dev, "24m");
+   if (IS_ERR(dp->phy_24m)) {
+   dev_err(dev, "cannot get clock 24m\n");
+   return PTR_ERR(dp->phy_24m);
+   }
+
+   ret = clk_set_rate(dp->phy_24m, 2400);
+   if (ret < 0) {
+   dev_err(dp->dev, "cannot set clock phy_24m %d\n", ret);
+   return ret;
+   }
+







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

Re: [PATCH v8 06/17] dt-bindings: add document for analogix display port driver

[Yakir Yang]

Hi Heiko,

On 10/29/2015 04:02 AM, Heiko Stuebner wrote:

Hi Yakir,

Am Mittwoch, 28. Oktober 2015, 16:26:33 schrieb Yakir Yang:

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 7a3a9cd..9905081 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -31,45 +31,31 @@ Required properties for dp-controller:
from general PHY binding: the phandle for the PHY device.
-phy-names:
from general PHY binding: Should be "dp".
-   -samsung,color-space:
-   input video data format.
-   COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
-   -samsung,dynamic-range:
-   dynamic range for input video data.
-   VESA = 0, CEA = 1
-   -samsung,ycbcr-coeff:
-   YCbCr co-efficients for input video.
-   COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
-   -samsung,color-depth:
-   number of bits per colour component.
-   COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
-   -samsung,link-rate:
-   link rate supported by the panel.
-   LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A
-   -samsung,lane-count:
-   number of lanes supported by the panel.
-   LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
-   - display-timings: timings for the connected panel as described by
-   Documentation/devicetree/bindings/video/display-timing.txt


^^ display/display-timings.txt
otherwise this patch does not apply.


I thought I have deleted this old path of "display-timing.txt", and 
changed it to


-   Documentation/devicetree/bindings/video/display-timing.txt

+   
Documentation/devicetree/bindings/display/panel/display-timing.txt

And the real path of "display-timing.txt" in linux-next [tag 20151022] 
do under

the "display/panel/", those change should be right.

Thanks,
- Yakir


--
To unsubscribe from this list: send the line "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] Input: tsc2005 - Add support for tsc2004

[Michael Welling]

Adds support for the i2c based tsc2004.

Due to the overlapping functionality of the tsc2004 and tsc2005
the common code was moved to a core driver (tsc200x-core).

Signed-off-by: Michael Welling 
---
v3: Splits the tsc2004 and tsc2005 into separate drivers with
with common routines in tsc200x-core.
v2: Fixes Kconfig based on report for 0-day build bot.
 .../bindings/input/touchscreen/tsc2004.txt |  38 +
 drivers/input/touchscreen/Kconfig  |  17 +
 drivers/input/touchscreen/Makefile |   2 +
 drivers/input/touchscreen/tsc2004.c|  73 ++
 drivers/input/touchscreen/tsc2005.c| 707 +-
 drivers/input/touchscreen/tsc200x-core.c   | 790 +
 drivers/input/touchscreen/tsc200x-core.h   |  13 +
 7 files changed, 938 insertions(+), 702 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/tsc2004.txt
 create mode 100644 drivers/input/touchscreen/tsc2004.c
 create mode 100644 drivers/input/touchscreen/tsc200x-core.c
 create mode 100644 drivers/input/touchscreen/tsc200x-core.h

diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2004.txt 
b/Documentation/devicetree/bindings/input/touchscreen/tsc2004.txt
new file mode 100644
index 000..14a37fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2004.txt
@@ -0,0 +1,38 @@
+* Texas Instruments tsc2004 touchscreen controller
+
+Required properties:
+ - compatible: "ti,tsc2004"
+ - interrupts: IRQ specifier
+ - vio-supply : Regulator specifier
+
+Optional properties:
+ - reset-gpios   : GPIO specifier
+ - ti,x-plate-ohms   : integer, resistance of the touchscreen's X 
plates
+   in ohm (defaults to 280)
+ - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond 
after
+   the configured time (in milli seconds), the 
driver
+   will reset it. This is disabled by default.
+ - properties defined in touchscreen.txt
+
+Example:
+
+&i2c3 {
+   tsc2004@48 {
+   compatible = "ti,tsc2004";
+   reg = <0x48>;
+   vio-supply = <&vio>;
+
+   reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>;
+   interrupts-extended = <&gpio1 27 IRQ_TYPE_EDGE_RISING>;
+
+   touchscreen-fuzz-x = <4>;
+   touchscreen-fuzz-y = <7>;
+   touchscreen-fuzz-pressure = <2>;
+   touchscreen-size-x = <4096>;
+   touchscreen-size-y = <4096>;
+   touchscreen-max-pressure = <2048>;
+
+   ti,x-plate-ohms = <280>;
+   ti,esd-recovery-timeout-ms = <8000>;
+   };
+}
diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 80cc698..e574f8c 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -939,10 +939,27 @@ config TOUCHSCREEN_TSC_SERIO
  To compile this driver as a module, choose M here: the
  module will be called tsc40.
 
+config TOUCHSCREEN_TSC200X
+   tristate
+
+config TOUCHSCREEN_TSC2004
+   tristate "TSC2004 based touchscreens"
+   depends on I2C
+   select REGMAP_I2C
+   select TOUCHSCREEN_TSC200X
+   help
+ Say Y here if you have a TSC2004 based touchscreen.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tsc2004.
+
 config TOUCHSCREEN_TSC2005
tristate "TSC2005 based touchscreens"
depends on SPI_MASTER
select REGMAP_SPI
+   select TOUCHSCREEN_TSC200X
help
  Say Y here if you have a TSC2005 based touchscreen.
 
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 17435c7..810b047 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -69,6 +69,8 @@ obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213)  += touchit213.o
 obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT)   += touchright.o
 obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o
 obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO)+= tsc40.o
+obj-$(CONFIG_TOUCHSCREEN_TSC200X)  += tsc200x-core.o
+obj-$(CONFIG_TOUCHSCREEN_TSC2004)  += tsc2004.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2005)  += tsc2005.o
 obj-$(CONFIG_TOUCHSCREEN_TSC2007)  += tsc2007.o
 obj-$(CONFIG_TOUCHSCREEN_UCB1400)  += ucb1400_ts.o
diff --git a/drivers/input/touchscreen/tsc2004.c 
b/drivers/input/touchscreen/tsc2004.c
new file mode 100644
index 000..01457a2
--- /dev/null
+++ b/drivers/input/touchscreen/tsc2004.c
@@ -0,0 +1,73 @@
+/*
+ * TSC2004 touchscreen driver
+ *
+ * Copyright (C) 2015 EMAC Inc.
+ * Copyright (C) 2015 QWERTY Embedded Design
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published 

Re: [PATCH v12 5/6] ARM: socfpga: add bindings document for fpga bridge drivers

[Rob Herring]

On Tue, Oct 27, 2015 at 5:09 PM,   wrote:
> From: Alan Tull 
>
> Add bindings documentation for Altera SOCFPGA bridges:
>  * fpga2sdram
>  * fpga2hps
>  * hps2fpga
>  * lwhps2fpga
>
> Signed-off-by: Alan Tull 

Oops...

> Signed-off-by: Dinh Nguyen 
> Signed-off-by: Matthew Gerlach 

These should be roughly in order of who did modifications. I'd expect
you to be last.

> ---
> v2:  separate into 2 documents for the 2 drivers
> v12: bump version to line up with simple-fpga-bus version
>  remove Linux specific notes such as references to sysfs
>  move non-DT specific documentation elsewhere
>  remove bindings that would have been used to pass configuration
>  clean up formatting
> ---
>  .../bindings/fpga/altera-fpga2sdram-bridge.txt |   18 ++
>  .../bindings/fpga/altera-hps2fpga-bridge.txt   |   36 
> 
>  2 files changed, 54 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
>  create mode 100644 
> Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
>
> diff --git 
> a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt 
> b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
> new file mode 100644
> index 000..11eb5b7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
> @@ -0,0 +1,18 @@
> +Altera FPGA To SDRAM Bridge Driver
> +
> +Required properties:
> +- compatible   : Should contain "altr,socfpga-fpga2sdram-bridge"
> +
> +Optional properties:
> +- label: User-readable name for this bridge.
> + Default is br

Why does the user need label? We generally use label to match physical
labels like "Rear USB port" or "disk LED" or something.

> +- init-val : 0 if driver should disable bridge at startup
> + 1 if driver should enable bridge at startup

Perhaps "bridge-enable" would be a more descriptive name.

And to comment on other replies, I have no problem with this type of
property in the DT. But yes, configuration type properties will get
more scrutiny.

> + Default is to leave bridge in current state.
> +
> +Example:
> +   fpga2sdram_br: fpgabridge@3 {
> +   compatible = "altr,socfpga-fpga2sdram-bridge";
> +   label = "fpga2sdram";
> +   init-val = <0>;
> +   };
> diff --git 
> a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt 
> b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> new file mode 100644
> index 000..eb52f3b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> @@ -0,0 +1,36 @@
> +Altera FPGA/HPS Bridge Driver
> +
> +Required properties:
> +- compatible   : Should contain one of:
> + "altr,socfpga-hps2fpga-bridge",
> + "altr,socfpga-lwhps2fpga-bridge", or
> + "altr,socfpga-fpga2hps-bridge"
> +- clocks   : Clocks used by this module.
> +
> +Optional properties:
> +- label: User-readable name for this bridge.
> + Default is br
> +- init-val : 0 if driver should disable bridge at startup.
> + 1 if driver should enable bridge at startup.
> + Default is to leave bridge in its current state.
> +
> +Example:
> +   hps_fpgabridge0: fpgabridge@0 {
> +   compatible = "altr,socfpga-hps2fpga-bridge";
> +   label = "hps2fpga";
> +   clocks = <&l4_main_clk>;
> +   init-val = <1>;
> +   };
> +
> +   hps_fpgabridge1: fpgabridge@1 {
> +   compatible = "altr,socfpga-lwhps2fpga-bridge";
> +   label = "lwhps2fpga";
> +   clocks = <&l4_main_clk>;
> +   init-val = <0>;
> +   };
> +
> +   hps_fpgabridge2: fpgabridge@2 {
> +   compatible = "altr,socfpga-fpga2hps-bridge";
> +   label = "fpga2hps";
> +   clocks = <&l4_main_clk>;
> +   };
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [alsa-devel] [PATCH V2 02/10] ASoC: img: Add driver for I2S input controller

[Mark Brown]

On Wed, Oct 28, 2015 at 09:18:20PM +, Damien Horsley wrote:
> On 28/10/15 01:04, Mark Brown wrote:

> >> I think it also makes sense to keep the blocks consistent with each
> >> other. The spdif (out and in), and parallel out, all flush automatically
> >> when stopped, and the fifo for the i2s out block is cleared when the
> >> reset is asserted.

> > This seems like an issue that got missed in the other drivers then.  I'd
> > expect the trigger operation to be a minimal operation which starts and
> > stops the data transfer, not doing anything else.

> The spdif out, spdif in, and parallel out blocks auto-flush whenever
> they are stopped. It is not possible for software to prevent this behavior.

Oh, so this isn't the drivers doing this?  In that case it's fine for
them to do that, if it's what the hardware does it's what the hardware
does.  It sounded like you were saying that there was similar code in
the other drivers.


signature.asc
Description: PGP signature

Re: [PATCH v3 3/3] ARM: dts: BCM63xx: Add ARMPLL device tree nodes

[Florian Fainelli]

On 27/10/15 16:56, Florian Fainelli wrote:
> Add the ARM PLL controller which comes standard with the Cortex-A9 found
> on the BCM63138 SoCs. This is the same controller as the one found in
> the Broadcom iProc architecture, however, we have a separate compatible
> string to indicate the integration difference.
> 
> While at it, properly rename references to the 50Mhz clock which is in
> fact a crystal/oscillator and updates references to it.

The periph_clk is actually the correct one, and is different from the
oscillator, I will resubmit these patches shortly to better match the
chip clocking.

> 
> Signed-off-by: Florian Fainelli 
> ---
> No changes in v2 or v3
> 
>  arch/arm/boot/dts/bcm63138.dtsi | 39 +--
>  1 file changed, 29 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/bcm63138.dtsi b/arch/arm/boot/dts/bcm63138.dtsi
> index 34cd64051250..c146325eebdb 100644
> --- a/arch/arm/boot/dts/bcm63138.dtsi
> +++ b/arch/arm/boot/dts/bcm63138.dtsi
> @@ -43,17 +43,29 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>  
> - arm_timer_clk: arm_timer_clk {
> + osc: oscillator {
>   #clock-cells = <0>;
>   compatible = "fixed-clock";
> - clock-frequency = <5>;
> + clock-frequency = <5000>;
> + clock-output-names = "periph";
>   };
>  
> - periph_clk: periph_clk {
> + /* peripheral clock for system timer */
> + axi_clk: axi_clk {
>   #clock-cells = <0>;
> - compatible = "fixed-clock";
> - clock-frequency = <5000>;
> - clock-output-names = "periph";
> + compatible = "fixed-factor-clock";
> + clocks = <&armpll>;
> + clock-div = <2>;
> + clock-mult = <1>;
> + };
> +
> + /* APB bus clock */
> + apb_clk: apb_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-factor-clock";
> + clocks = <&armpll>;
> + clock-div = <4>;
> + clock-mult = <1>;
>   };
>   };
>  
> @@ -93,14 +105,14 @@
>   compatible = "arm,cortex-a9-global-timer";
>   reg = <0x1e200 0x20>;
>   interrupts = ;
> - clocks = <&arm_timer_clk>;
> + clocks = <&axi_clk>;
>   };
>  
>   local_timer: local-timer@1e600 {
>   compatible = "arm,cortex-a9-twd-timer";
>   reg = <0x1e600 0x20>;
>   interrupts = ;
> - clocks = <&arm_timer_clk>;
> + clocks = <&axi_clk>;
>   };
>  
>   twd_watchdog: watchdog@1e620 {
> @@ -109,6 +121,13 @@
>   interrupts = ;
>   };
>  
> + armpll: armpll {
> + #clock-cells = <0>;
> + compatible = "brcm,bcm63138-armpll";
> + clocks = <&osc>;
> + reg = <0x2 0xf00>;
> + };
> +
>   pmb0: reset-controller@4800c0 {
>   compatible = "brcm,bcm63138-pmb";
>   reg = <0x4800c0 0x10>;
> @@ -138,7 +157,7 @@
>   compatible = "brcm,bcm6345-uart";
>   reg = <0x600 0x1b>;
>   interrupts = ;
> - clocks = <&periph_clk>;
> + clocks = <&osc>;
>   clock-names = "periph";
>   status = "disabled";
>   };
> @@ -147,7 +166,7 @@
>   compatible = "brcm,bcm6345-uart";
>   reg = <0x620 0x1b>;
>   interrupts = ;
> - clocks = <&periph_clk>;
> + clocks = <&osc>;
>   clock-names = "periph";
>   status = "disabled";
>   };
> 


-- 
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 v12 2/6] fpga: add bindings document for simple fpga bus

[Rob Herring]

On Tue, Oct 27, 2015 at 5:09 PM,   wrote:
> From: Alan Tull 
>
> New bindings document for simple fpga bus.
>
> Signed-off-by: Alan Tull 
> ---
> v9:  initial version added to this patchset
> v10: s/fpga/FPGA/g
>  replace DT overlay example with slightly more complicated example
>  move to staging/simple-fpga-bus
> v11: No change in this patch for v11 of the patch set
> v12: Moved out of staging.
>  Changed to use FPGA bridges framework instead of resets
>  for bridges.
> ---
>  .../devicetree/bindings/fpga/simple-fpga-bus.txt   |   81 
> 
>  1 file changed, 81 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
>
> diff --git a/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt 
> b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
> new file mode 100644
> index 000..2e742f7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
> @@ -0,0 +1,81 @@
> +Simple FPGA Bus
> +===
> +
> +A Simple FPGA Bus is a bus that handles configuring an FPGA and its bridges
> +before populating the devices below its node.  All this happens when a device
> +tree overlay is added to the live tree.  This document describes that device
> +tree overlay.
> +
> +Required properties:
> +- compatible : should contain "simple-fpga-bus"
> +- #address-cells, #size-cells, ranges: must be present to handle address 
> space
> +  mapping for children.
> +
> +Optional properties:
> +- fpga-mgr : should contain a phandle to a FPGA manager.
> +- fpga-firmware : should contain the name of a FPGA image file located on the
> +  firmware search path.

Putting firmware filename in DT has come up in other cases recently[1]
and we concluded it should not be in the DT. Maybe the conclusion
would be different here, and if so we should have a common property
here.

> +- partial-reconfig : boolean property should be defined if partial
> +  reconfiguration of the FPGA is to be done, otherwise full reconfiguration
> +  is done.
> +- fpga-bridges : should contain a list of bridges that the bus will disable
> +  before   programming the FPGA and then enable after the FPGA has been
> +
> +Example:
> +
> +/dts-v1/;
> +/plugin/;
> +/ {
> +   fragment@0 {
> +   target-path="/soc";
> +   __overlay__ {
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +
> +   bridge@0xff20 {
> +   compatible = "simple-fpga-bus";
> +   reg = <0xc000 0x2000>,
> + <0xff20 0x0020>;

You have registers for the bus, so therefore it is not simple. I think
the bus or bridge needs a specific compatible

Rob

[1] http://www.spinics.net/lists/devicetree/msg92462.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4] doc: dt: mtd: support partitions in a special 'partitions' subnode

[Brian Norris]

On Wed, Oct 28, 2015 at 03:48:06PM -0700, Brian Norris wrote:
> From: Michal Suchanek 
> 
> To avoid conflict with other drivers using subnodes of the mtd device
> create only one ofpart-specific node rather than any number of
> arbitrary partition subnodes.
> 
> Signed-off-by: Michal Suchanek 
> Acked-by: Rob Herring 
> Signed-off-by: Brian Norris 
> ---

Ugh, I wrote this up to stick below the '---' but I forgot to send it
out with the patch. Here goes:

This is a resend with only slight modifications of Michal's v3 patch, for 
clarity:

http://thread.gmane.org/gmane.linux.drivers.mtd/60890/focus=60889

It's been reviewed by me and Rob and I plan to take it for v4.4. But at Rob's
suggestion, I'm sending this to the devicetree-spec list too, as this is a
binding for somewhat generic infrastructure, rather than just drivers.

Regards,
Brian

>  .../devicetree/bindings/mtd/partition.txt  | 71 
> +-
>  1 file changed, 42 insertions(+), 29 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mtd/partition.txt 
> b/Documentation/devicetree/bindings/mtd/partition.txt
> index 8e5557da1955..f1e2a02381a4 100644
> --- a/Documentation/devicetree/bindings/mtd/partition.txt
> +++ b/Documentation/devicetree/bindings/mtd/partition.txt
> @@ -4,10 +4,17 @@ Partitions can be represented by sub-nodes of an mtd 
> device. This can be used
>  on platforms which have strong conventions about which portions of a flash 
> are
>  used for what purposes, but which don't use an on-flash partition table such
>  as RedBoot.
> -NOTE: if the sub-node has a compatible string, then it is not a partition.
>  
> -#address-cells & #size-cells must both be present in the mtd device. There 
> are
> -two valid values for both:
> +The partition table should be a subnode of the mtd node and should be named
> +'partitions'. Partitions are defined in subnodes of the partitions node.
> +
> +For backwards compatibility partitions as direct subnodes of the mtd device 
> are
> +supported. This use is discouraged.
> +NOTE: also for backwards compatibility, direct subnodes that have a 
> compatible
> +string are not considered partitions, as they may be used for other bindings.
> +
> +#address-cells & #size-cells must both be present in the partitions subnode 
> of the
> +mtd device. There are two valid values for both:
>  <1>: for partitions that require a single 32-bit cell to represent their
>   size/address (aka the value is below 4 GiB)
>  <2>: for partitions that require two 32-bit cells to represent their
> @@ -28,44 +35,50 @@ Examples:
>  
>  
>  flash@0 {
> - #address-cells = <1>;
> - #size-cells = <1>;
> + partitions {
> + #address-cells = <1>;
> + #size-cells = <1>;
>  
> - partition@0 {
> - label = "u-boot";
> - reg = <0x000 0x10>;
> - read-only;
> - };
> + partition@0 {
> + label = "u-boot";
> + reg = <0x000 0x10>;
> + read-only;
> + };
>  
> - uimage@10 {
> - reg = <0x010 0x20>;
> + uimage@10 {
> + reg = <0x010 0x20>;
> + };
>   };
>  };
>  
>  flash@1 {
> - #address-cells = <1>;
> - #size-cells = <2>;
> + partitions {
> + #address-cells = <1>;
> + #size-cells = <2>;
>  
> - /* a 4 GiB partition */
> - partition@0 {
> - label = "filesystem";
> - reg = <0x 0x1 0x>;
> + /* a 4 GiB partition */
> + partition@0 {
> + label = "filesystem";
> + reg = <0x 0x1 0x>;
> + };
>   };
>  };
>  
>  flash@2 {
> - #address-cells = <2>;
> - #size-cells = <2>;
> + partitions {
> + #address-cells = <2>;
> + #size-cells = <2>;
>  
> - /* an 8 GiB partition */
> - partition@0 {
> - label = "filesystem #1";
> - reg = <0x0 0x 0x2 0x>;
> - };
> + /* an 8 GiB partition */
> + partition@0 {
> + label = "filesystem #1";
> + reg = <0x0 0x 0x2 0x>;
> + };
>  
> - /* a 4 GiB partition */
> - partition@2 {
> - label = "filesystem #2";
> - reg = <0x2 0x 0x1 0x>;
> + /* a 4 GiB partition */
> + partition@2 {
> + label = "filesystem #2";
> + reg = <0x2 0x 0x1 0x>;
> + };
>   };
>  };
> -- 
> 2.6.0.rc2.230.g3dd15c0
> 
--
To unsubscribe from this list: send the line "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] doc: dt: mtd: support partitions in a special 'partitions' subnode

[Brian Norris]

From: Michal Suchanek 

To avoid conflict with other drivers using subnodes of the mtd device
create only one ofpart-specific node rather than any number of
arbitrary partition subnodes.

Signed-off-by: Michal Suchanek 
Acked-by: Rob Herring 
Signed-off-by: Brian Norris 
---
 .../devicetree/bindings/mtd/partition.txt  | 71 +-
 1 file changed, 42 insertions(+), 29 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/partition.txt 
b/Documentation/devicetree/bindings/mtd/partition.txt
index 8e5557da1955..f1e2a02381a4 100644
--- a/Documentation/devicetree/bindings/mtd/partition.txt
+++ b/Documentation/devicetree/bindings/mtd/partition.txt
@@ -4,10 +4,17 @@ Partitions can be represented by sub-nodes of an mtd device. 
This can be used
 on platforms which have strong conventions about which portions of a flash are
 used for what purposes, but which don't use an on-flash partition table such
 as RedBoot.
-NOTE: if the sub-node has a compatible string, then it is not a partition.
 
-#address-cells & #size-cells must both be present in the mtd device. There are
-two valid values for both:
+The partition table should be a subnode of the mtd node and should be named
+'partitions'. Partitions are defined in subnodes of the partitions node.
+
+For backwards compatibility partitions as direct subnodes of the mtd device are
+supported. This use is discouraged.
+NOTE: also for backwards compatibility, direct subnodes that have a compatible
+string are not considered partitions, as they may be used for other bindings.
+
+#address-cells & #size-cells must both be present in the partitions subnode of 
the
+mtd device. There are two valid values for both:
 <1>: for partitions that require a single 32-bit cell to represent their
  size/address (aka the value is below 4 GiB)
 <2>: for partitions that require two 32-bit cells to represent their
@@ -28,44 +35,50 @@ Examples:
 
 
 flash@0 {
-   #address-cells = <1>;
-   #size-cells = <1>;
+   partitions {
+   #address-cells = <1>;
+   #size-cells = <1>;
 
-   partition@0 {
-   label = "u-boot";
-   reg = <0x000 0x10>;
-   read-only;
-   };
+   partition@0 {
+   label = "u-boot";
+   reg = <0x000 0x10>;
+   read-only;
+   };
 
-   uimage@10 {
-   reg = <0x010 0x20>;
+   uimage@10 {
+   reg = <0x010 0x20>;
+   };
};
 };
 
 flash@1 {
-   #address-cells = <1>;
-   #size-cells = <2>;
+   partitions {
+   #address-cells = <1>;
+   #size-cells = <2>;
 
-   /* a 4 GiB partition */
-   partition@0 {
-   label = "filesystem";
-   reg = <0x 0x1 0x>;
+   /* a 4 GiB partition */
+   partition@0 {
+   label = "filesystem";
+   reg = <0x 0x1 0x>;
+   };
};
 };
 
 flash@2 {
-   #address-cells = <2>;
-   #size-cells = <2>;
+   partitions {
+   #address-cells = <2>;
+   #size-cells = <2>;
 
-   /* an 8 GiB partition */
-   partition@0 {
-   label = "filesystem #1";
-   reg = <0x0 0x 0x2 0x>;
-   };
+   /* an 8 GiB partition */
+   partition@0 {
+   label = "filesystem #1";
+   reg = <0x0 0x 0x2 0x>;
+   };
 
-   /* a 4 GiB partition */
-   partition@2 {
-   label = "filesystem #2";
-   reg = <0x2 0x 0x1 0x>;
+   /* a 4 GiB partition */
+   partition@2 {
+   label = "filesystem #2";
+   reg = <0x2 0x 0x1 0x>;
+   };
};
 };
-- 
2.6.0.rc2.230.g3dd15c0

--
To unsubscribe from this list: send the line "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: shmobile: henninger: remove board DT

[Simon Horman]

On Thu, Oct 29, 2015 at 12:34:29AM +0300, Sergei Shtylyov wrote:
> The Henninger low cost board was never sold and so  had  no  users outside
> Renesas (and Cogent Embedded). Instead Renesas  has made the Porter  board
> which has mostly similar hardware. Now that the Porter board support is on
> par with Henninger, we can remove  the Henninger's device tree file.
> 
> Signed-off-by: Sergei Shtylyov 

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

[PATCH] ARM: shmobile: henninger: remove board DT

[Sergei Shtylyov]

The Henninger low cost board was never sold and so  had  no  users outside
Renesas (and Cogent Embedded). Instead Renesas  has made the Porter  board
which has mostly similar hardware. Now that the Porter board support is on
par with Henninger, we can remove  the Henninger's device tree file.

Signed-off-by: Sergei Shtylyov 

---
This patch is against 'renesas-devel-20151028-v4.3-rc7' tag of Simon Horman's
'renesas.git' repo.

 arch/arm/boot/dts/Makefile  |1 
 arch/arm/boot/dts/r8a7791-henninger.dts |  320 
 2 files changed, 321 deletions(-)

Index: renesas/arch/arm/boot/dts/Makefile
===
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -530,7 +530,6 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += \
r8a7778-bockw.dtb \
r8a7779-marzen.dtb \
r8a7790-lager.dtb \
-   r8a7791-henninger.dtb \
r8a7791-koelsch.dtb \
r8a7791-porter.dtb \
r8a7793-gose.dtb \
Index: renesas/arch/arm/boot/dts/r8a7791-henninger.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-henninger.dts
+++ /dev/null
@@ -1,320 +0,0 @@
-/*
- * Device Tree Source for the Henninger board
- *
- * Copyright (C) 2014 Renesas Solutions Corp.
- * Copyright (C) 2014 Cogent Embedded, Inc.
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2.  This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
- */
-
-/dts-v1/;
-#include "r8a7791.dtsi"
-#include 
-
-/ {
-   model = "Henninger";
-   compatible = "renesas,henninger", "renesas,r8a7791";
-
-   aliases {
-   serial0 = &scif0;
-   };
-
-   chosen {
-   bootargs = "console=ttySC0,38400 ignore_loglevel rw 
root=/dev/nfs ip=dhcp";
-   stdout-path = &scif0;
-   };
-
-   memory@4000 {
-   device_type = "memory";
-   reg = <0 0x4000 0 0x4000>;
-   };
-
-   memory@2 {
-   device_type = "memory";
-   reg = <2 0x 0 0x4000>;
-   };
-
-   vcc_sdhi0: regulator@0 {
-   compatible = "regulator-fixed";
-
-   regulator-name = "SDHI0 Vcc";
-   regulator-min-microvolt = <330>;
-   regulator-max-microvolt = <330>;
-   regulator-always-on;
-   };
-
-   vccq_sdhi0: regulator@1 {
-   compatible = "regulator-gpio";
-
-   regulator-name = "SDHI0 VccQ";
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <330>;
-
-   gpios = <&gpio2 12 GPIO_ACTIVE_HIGH>;
-   gpios-states = <1>;
-   states = <330 1
- 180 0>;
-   };
-
-   vcc_sdhi2: regulator@2 {
-   compatible = "regulator-fixed";
-
-   regulator-name = "SDHI2 Vcc";
-   regulator-min-microvolt = <330>;
-   regulator-max-microvolt = <330>;
-   regulator-always-on;
-   };
-
-   vccq_sdhi2: regulator@3 {
-   compatible = "regulator-gpio";
-
-   regulator-name = "SDHI2 VccQ";
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <330>;
-
-   gpios = <&gpio2 26 GPIO_ACTIVE_HIGH>;
-   gpios-states = <1>;
-   states = <330 1
- 180 0>;
-   };
-};
-
-&extal_clk {
-   clock-frequency = <2000>;
-};
-
-&pfc {
-   scif0_pins: serial0 {
-   renesas,groups = "scif0_data_d";
-   renesas,function = "scif0";
-   };
-
-   ether_pins: ether {
-   renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
-   renesas,function = "eth";
-   };
-
-   phy1_pins: phy1 {
-   renesas,groups = "intc_irq0";
-   renesas,function = "intc";
-   };
-
-   sdhi0_pins: sd0 {
-   renesas,groups = "sdhi0_data4", "sdhi0_ctrl";
-   renesas,function = "sdhi0";
-   };
-
-   sdhi2_pins: sd2 {
-   renesas,groups = "sdhi2_data4", "sdhi2_ctrl";
-   renesas,function = "sdhi2";
-   };
-
-   i2c2_pins: i2c2 {
-   renesas,groups = "i2c2";
-   renesas,function = &qu

[PATCH v2] arm64: dts: Added syscon-reboot node for FSL's LS2085A SoC

[J. German Rivera]

Added sys-reboot node to the FSL's LS2085A SoC DT to leverage
the ARM-generic reboot mechanism for this SoC. This mechanism
is enabled through CONFIG_POWER_RESET_SYSCON.

Signed-off-by: J. German Rivera 
---
CHANGE HISTORY

Changes in v2:
- Address comment form Stuart Yoder:
  * Removed "@" from reboot node

 arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi
index e281ceb..8fb3646 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2085a.dtsi
@@ -131,6 +131,18 @@
interrupts = <1 9 0x4>;
};

+   rst_ccsr: rstccsr@1E6 {
+   compatible = "syscon";
+   reg = <0x0 0x1E6 0x0 0x1>;
+   };
+
+   reboot {
+   compatible ="syscon-reboot";
+   regmap = <&rst_ccsr>;
+   offset = <0x0>;
+   mask = <0x2>;
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low */
--
2.3.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: [alsa-devel] [PATCH V2 02/10] ASoC: img: Add driver for I2S input controller

[Damien Horsley]

On 28/10/15 01:04, Mark Brown wrote:
> On Tue, Oct 27, 2015 at 01:55:27PM +, Damien Horsley wrote:
>> On 23/10/15 23:57, Mark Brown wrote:
> 
>>> Shouldn't we be doing that flush on stream close instead?  If nothing
>>> else the flush is going to discard a bit of data if the stream is just
>>> paused.
> 
>> The FIFOs are only 8 frames in size, so I am not sure there is an
>> issue with these frames being lost.
> 
>> I think it also makes sense to keep the blocks consistent with each
>> other. The spdif (out and in), and parallel out, all flush automatically
>> when stopped, and the fifo for the i2s out block is cleared when the
>> reset is asserted.
> 
> This seems like an issue that got missed in the other drivers then.  I'd
> expect the trigger operation to be a minimal operation which starts and
> stops the data transfer, not doing anything else.
> 

The spdif out, spdif in, and parallel out blocks auto-flush whenever
they are stopped. It is not possible for software to prevent this behavior.
--
To unsubscribe from this list: send the line "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] rpi: add support to enable usb power domain

[Alexander Aring]

This patch adds support for RPi several Power Domains and enable support
to enable the USB Power Domain when it's not enabled before.

This patch based on Eric Anholt's patch to support Power Domains. He had
an issue about -EPROBE_DEFER inside the power domain subsystem, this
issue was solved by commit <311fa6a> ("PM / Domains: Return -EPROBE_DEFER
if we fail to init or turn-on domain").

It was tested with barebox and the following scripts before booting
linux:

/env/a_off:

 # cat /env/a_off
 #turn off which are enabled by default
 regulator -n bcm2835_mci0 -s disable
 regulator -n uart0-pl0110 -s disable

/env/a_on:

 # cat /env/a_on
 #turn off which are enabled by default
 regulator -n bcm2835_mci0 -s disable
 regulator -n uart0-pl0110 -s disable

 regulator -n bcm2835_mci0 -s enable
 regulator -n uart0-pl0110 -s enable
 regulator -n uart0-pl0111 -s enable
 regulator -n bcm2835_usb -s enable
 regulator -n bcm2835_i2c0 -s enable
 regulator -n bcm2835_i2c1 -s enable
 regulator -n bcm2835_i2c2 -s enable
 regulator -n bcm2835_spi -s enable
 regulator -n bcm2835_ccp2tx -s enable
 regulator -n bcm2835_dsi -s enable

/env/b:

 # cat /env/b
 sh /env/a_on

 regulator -n bcm2835_mci0 -s disable
 regulator -n uart0-pl0110 -s disable
 regulator -n uart0-pl0111 -s disable
 regulator -n bcm2835_usb -s disable
 regulator -n bcm2835_i2c0 -s disable
 regulator -n bcm2835_i2c1 -s disable
 regulator -n bcm2835_i2c2 -s disable
 regulator -n bcm2835_spi -s disable
 regulator -n bcm2835_ccp2tx -s disable
 regulator -n bcm2835_dsi -s disable

/env/c:

 # cat /env/c
 sh ./env/b

 regulator -n bcm2835_mci0 -s enable
 regulator -n uart0-pl0110 -s enable
 regulator -n uart0-pl0111 -s enable
 regulator -n bcm2835_usb -s enable
 regulator -n bcm2835_i2c0 -s enable
 regulator -n bcm2835_i2c1 -s enable
 regulator -n bcm2835_i2c2 -s enable
 regulator -n bcm2835_spi -s enable
 regulator -n bcm2835_ccp2tx -s enable
 regulator -n bcm2835_dsi -s enable

These scripts enables/disable all regulators inside the bootloader. It
was running with a "hard" and "soft" reset without any issues. These
testcases should fit to Stephen Warren suggestions:

"(a) before having explicitly turned the power domain on or off at all (b)
after having turned it on (c) after having turned it off, and for all
power domains."

Cc: Stephen Warren 
Cc: Lee Jones 
Cc: Eric Anholt 
Cc: Andy Whitcroft 
Cc: Joe Perches 
Signed-off-by: Alexander Aring 
---
First:
I cc'ed Andy Whitcroft and Joe Perches here, because this patch will
generate a false positive for checkpatch and checkpatch told me to
cc checkpatch maintainers if this occurs:

ERROR: Macros with complex values should be enclosed in parentheses
#191: FILE: drivers/firmware/raspberrypi.c:26:
+#define RPI_POWER_DOMAIN(_domain, _name)   \
+   [_domain] = \
+   {   \
...

Second:
This patch based on linus/master and requires the rpi-firmware patch.

Third:
The barebox regulator doesn't support right now to enable/disable
regulators at runtime but I want to bring this mainline in the next
days. So you can't check yourself if the above scripts working right
now. I describe it here to show you what exactly I tested.

changes since Eric Anholts "power domain" patch:
 - add for me all known power domains of the RPi, it contains the domains
   0 - 9.
 - Add devicetree documentation.
 - move implementation to drivers/firmware/... (also Kconfig dependencies)
 - add macro RPI_POWER_DOMAIN.
 - add function "raspberrypi_firmware_power_is_on" to get the initial value
   for a "power domain", which can be assign over the "is_off" parameter,
   while power domain init.
 - Put generic_pm_domain on the heap with amount of entries which
   comes from ARRAY_SIZE(rpi_power_domains). So we don't need to care
   about both arrays anymore. But only works so far rpi_power_domains has
   not empty entries in the middle. I added a note about that, if it's
   too ugly I will remove it or accept other solutions. Maybe make
   rpi_power_domains as double pointer (and care about NULL entries, anyway.
   It should working and I think there are no other domains and if there are
   other domains and we have missing entries then something is wrong.

Notes:

I wonder myself when I disable domain 0 (SDHC) I can still access the card,
as well uart is also still working after turn off power.

 .../arm/bcm/raspberrypi,bcm2835-firmware.txt   |  15 +++
 arch/arm/boot/dts/bcm2835-rpi.dtsi |   6 +
 arch/arm/boot/dts/bcm2835.dtsi |   2 +-
 drivers/firmware/Kconfig   |   2 +
 drivers/firmware/raspberrypi.c | 133 +
 .../dt-bindings/arm/raspberrypi-firmware-power.h   |  23 
 6 files changed, 180 insertions(+), 1 deletion(-)
 create mode 100644 include/dt-bindings/arm/raspberrypi-firmware-power.h

diff --git 
a/Documentation/device

Re: [PATCH v8 10/17] phy: Add driver for rockchip Display Port PHY

[Heiko Stuebner]

Hi Yakir,

Am Mittwoch, 28. Oktober 2015, 16:30:33 schrieb Yakir Yang:
> +static int rockchip_dp_phy_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + struct phy_provider *phy_provider;
> + struct rockchip_dp_phy *dp;
> + struct resource *res;

drivers/phy/phy-rockchip-dp.c: In function 'rockchip_dp_phy_probe':
drivers/phy/phy-rockchip-dp.c:86:19: warning: unused variable 'res' 
[-Wunused-variable]

> + struct phy *phy;
> + int ret;
> +
> + if (!np)
> + return -ENODEV;
> +
> + dp = devm_kzalloc(dev, sizeof(*dp), GFP_KERNEL);
> + if (IS_ERR(dp))
> + return -ENOMEM;
> +
> + dp->dev = dev;
> +
> + dp->phy_24m = devm_clk_get(dev, "24m");
> + if (IS_ERR(dp->phy_24m)) {
> + dev_err(dev, "cannot get clock 24m\n");
> + return PTR_ERR(dp->phy_24m);
> + }
> +
> + ret = clk_set_rate(dp->phy_24m, 2400);
> + if (ret < 0) {
> + dev_err(dp->dev, "cannot set clock phy_24m %d\n", ret);
> + return ret;
> + }
> +

--
To unsubscribe from this list: send the line "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 v12 3/6] fpga: add simple-fpga-bus

[Moritz Fischer]

[..]
> I do not think it's a good fit for the socfpga, or for the lower level
> fpga drivers _in general_.  Nor do I think that the FPGA Bridge
> framework, as written, is a good fit for fpgas in general.

Could you elaborate a bit more on why you feel that way? For all
configurations that I could
create in my mind (even hierarchical) I could come up with a way to
model that using the
proposed architecture in a very natural way. I'm of course aware that
my imagination is limited ;-)

Cheers,

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

Re: [PATCH v8 06/17] dt-bindings: add document for analogix display port driver

[Heiko Stuebner]

Hi Yakir,

Am Mittwoch, 28. Oktober 2015, 16:26:33 schrieb Yakir Yang:
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> index 7a3a9cd..9905081 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> @@ -31,45 +31,31 @@ Required properties for dp-controller:
>   from general PHY binding: the phandle for the PHY device.
>   -phy-names:
>   from general PHY binding: Should be "dp".
> - -samsung,color-space:
> - input video data format.
> - COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
> - -samsung,dynamic-range:
> - dynamic range for input video data.
> - VESA = 0, CEA = 1
> - -samsung,ycbcr-coeff:
> - YCbCr co-efficients for input video.
> - COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
> - -samsung,color-depth:
> - number of bits per colour component.
> - COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
> - -samsung,link-rate:
> - link rate supported by the panel.
> - LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A
> - -samsung,lane-count:
> - number of lanes supported by the panel.
> - LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
> - - display-timings: timings for the connected panel as described by
> - Documentation/devicetree/bindings/video/display-timing.txt

^^ display/display-timings.txt
otherwise this patch does not apply.

--
To unsubscribe from this list: send the line "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 v12 2/6] fpga: add bindings document for simple fpga bus

[atull]

On Wed, 28 Oct 2015, Steffen Trumtrar wrote:

> On Tue, Oct 27, 2015 at 05:09:11PM -0500, at...@opensource.altera.com wrote:
> > From: Alan Tull 
> > 
> > New bindings document for simple fpga bus.
> > 
> > Signed-off-by: Alan Tull 
> > ---
> > v9:  initial version added to this patchset
> > v10: s/fpga/FPGA/g
> >  replace DT overlay example with slightly more complicated example
> >  move to staging/simple-fpga-bus
> > v11: No change in this patch for v11 of the patch set
> > v12: Moved out of staging.
> >  Changed to use FPGA bridges framework instead of resets
> >  for bridges.
> > ---
> >  .../devicetree/bindings/fpga/simple-fpga-bus.txt   |   81 
> > 
> >  1 file changed, 81 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt 
> > b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
> > new file mode 100644
> > index 000..2e742f7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
> > @@ -0,0 +1,81 @@
> > +Simple FPGA Bus
> > +===
> > +
> > +A Simple FPGA Bus is a bus that handles configuring an FPGA and its bridges
> > +before populating the devices below its node.  All this happens when a 
> > device
> > +tree overlay is added to the live tree.  This document describes that 
> > device
> > +tree overlay.
> > +
> > +Required properties:
> > +- compatible : should contain "simple-fpga-bus"
> > +- #address-cells, #size-cells, ranges: must be present to handle address 
> > space
> > +  mapping for children.
> > +
> > +Optional properties:
> > +- fpga-mgr : should contain a phandle to a FPGA manager.
> > +- fpga-firmware : should contain the name of a FPGA image file located on 
> > the
> > +  firmware search path.
> > +- partial-reconfig : boolean property should be defined if partial
> > +  reconfiguration of the FPGA is to be done, otherwise full reconfiguration
> > +  is done.
> > +- fpga-bridges : should contain a list of bridges that the bus will disable
> > +  before   programming the FPGA and then enable after the FPGA has been
> > +
> > +Example:
> > +
> > +/dts-v1/;
> > +/plugin/;
> > +/ {
> > +   fragment@0 {
> > +   target-path="/soc";
> > +   __overlay__ {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +
> > +   bridge@0xff20 {
> > +   compatible = "simple-fpga-bus";
> > +   reg = <0xc000 0x2000>,
> > + <0xff20 0x0020>;
> > +   reg-names = "axi_h2f", "axi_h2f_lw";
> > +
> > +   #address-cells = <0x2>;
> > +   #size-cells = <0x1>;
> > +
> > +   ranges = <0x 0x 0xc000 
> > 0x0001>,
> > +<0x0001 0x0002 0xff22 
> > 0x0008>,
> > +<0x0001 0x00010040 0xff210040 
> > 0x0020>;
> > +
> > +   clocks = <0x2 0x2>;
> > +   clock-names = "h2f_lw_axi_clock", 
> > "f2h_sdram0_clock";
> > +
> > +   fpga-mgr = <&hps_0_fpgamgr>;
> > +   fpga-firmware = "soc_system.rbf";
> > +
> > +   fpga-bridges = <&hps_fpgabridge0>, 
> > <&hps_fpgabridge1>, <&hps_fpgabridge2>;
> 
> At least for Socfpga the HPS2FPGA and FPGA2HPS bridges can be configured to 
> have
> a bus width of 32, 64, 128 depending on the bitstream. How does this fit into 
> here?
> For DMA over this bus this is an interesting property to know, isn't it?

It's interesting if you want to change bridge width.

Most of the time I think people are not going to want or even be able to change
the width of their bridges dynamically.

> I guess something like "<&hps_fpgabridge0 64>" could be a possible solution,

Yes that does seem possible and easy to implement on the level of the simple
fpga bus and fpga bridge framework.  Each low level FPGA Bridge driver would
have #bridge-cells = <1> to support having a parameter.  Specifying
#bridge-cells = <0> would bring back to the current behaviour of no parameter.
A parameter could be added to struct fpga_bridge so that when the simple fpga
bus enables the bridge, it could pass the parameter back to the fpga bridge
driver.  All without changing any parameters of the functions.  Thanks for the
suggestion!

> but
> what is with the GPV registers of the bridges? Do they depend on the bitstream
> loaded? Then this would get really messy I guess as it not a generic property.

Not all low level drivers will be able to support this.  Those that can't 
support
this won't have to.  But it is a possibility without adding much code to the 
bridge
framework.

Alan

> 
> -- 
> Pengutronix e.K. 

Re: [PATCH 3/3] ARM: BCM: Add SMP support for Broadcom NSP

[Hauke Mehrtens]

On 10/28/2015 03:24 PM, Kapil Hali wrote:
> 
> 
> On 10/16/2015 2:47 AM, Jon Mason wrote:
>> On Thu, Oct 15, 2015 at 11:12:09PM +0200, Hauke Mehrtens wrote:
>>> On 10/15/2015 06:10 PM, Kapil Hali wrote:


 On 10/15/2015 3:56 AM, Hauke Mehrtens wrote:
> On 10/14/2015 07:47 PM, Kapil Hali wrote:
>> Add SMP support for Broadcom's Northstar Plus SoC,
>> cpu enable method and pen_release procedures. This
>> changes also consolidates iProc family's - BCM NSP
>> and BCM Kona, SMP handling in a common file.
>
> This will probably also work on normal Northstar CPUs without changes.
>
 I think, it should work for most of the variants of Northstar family, 
 except for those which have a BOOTROM bug.
>>>
>>> Which SoC are affected by this BOOTROM bug?
>>
>> 53012 is the one I am seeing.  Not seeing it on 4708 (and assuming it is
>> not present on 4709).  Internally, we do the ugly bug workaround on
>> all Northstar SoCs.  The workaround is not acceptable upstream, so I
>> am not pushing it. :)
>>
>> Thanks,
>> Jon
>>
> 
> Hi Hauke,
> 
> Now that you have tested Jon's patch which is based on my changes for
> SMP, shall I take his changes and add it on top of my changes and resend?
> Also, do I consider your Acked-by and Tested-by for the change?
> 
> Thanks,
> Kapil
> 

Hi Kapil,

I tested this on Northstar 1.

Acked-by: Hauke Mehrtens 
Tested-by: Hauke Mehrtens 

I think Florian has to take the patches and you should hurry up because
the merge window probably opens on Monday.

You can send all patches again with the bcm501x patch or just that one,
I assume there are no changes needed for the other patches?

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

Re: [PATCH v3 2/2] arm64: dts: Add BRCM IPROC NAND DT node for NS2

[Florian Fainelli]

On 28/10/15 09:08, Ray Jui wrote:
> 
> 
> On 10/28/2015 2:06 AM, Anup Patel wrote:
>>
>>
>>> -Original Message-
>>> From: Ray Jui [mailto:r...@broadcom.com]
>>> Sent: 28 October 2015 06:17
>>> To: Brian Norris
>>> Cc: Anup Patel; David Woodhouse; Linux MTD; Rob Herring; Pawel Moll;
>>> Mark
>>> Rutland; Catalin Marinas; Will Deacon; Sudeep Holla; Ian Campbell;
>>> Kumar Gala;
>>> Scott Branden; Florian Fainelli; Pramod Kumar; Vikram Prakash; Sandeep
>>> Tripathy; Linux ARM Kernel; Device Tree; Linux Kernel;
>>> bcm-kernel-feedback-list
>>> Subject: Re: [PATCH v3 2/2] arm64: dts: Add BRCM IPROC NAND DT node for
>>> NS2
>>>
>>>
>>>
>>> On 10/27/2015 5:39 PM, Brian Norris wrote:
 On Tue, Oct 27, 2015 at 05:25:32PM -0700, Ray Jui wrote:
> On 10/27/2015 5:19 PM, Brian Norris wrote:
>> On Fri, Oct 23, 2015 at 10:46:13AM +0530, Anup Patel wrote:
>>> diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
>>> b/arch/arm64/boot/dts/broadcom/ns2.dtsi
>>> index f603277..9610822 100644
>>> --- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
>>> +++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
>>> @@ -212,5 +212,19 @@
>>>compatible = "brcm,iproc-rng200";
>>>reg = <0x6622 0x28>;
>>>};
>>> +
>>> +nand: nand@6646 {
>>> +compatible = "brcm,nand-iproc", "brcm,brcmnand-
>>> v6.1";
>>
>> Technically, the binding says you should also have "brcm,brcmnand"
>> as a last resort. Otherwise (for the NAND parts):
>>
>
> I believe Anup was seeing issues when both "brcm,nand-iproc" and
> "brcm,brcmnand" are present.
>
> Note "brcm,nand-iproc" invokes 'iproc_nand_probe', which calls
> 'brcmnand_probe' in the end.
>
> "brcm,brcmnand" invokes 'brcmstb_nand_probe', which also calls
> 'brcmstb_probe', but without all the prep configuration required for
> "brcm,nand-iproc".

 Ah, I forgot about that problem. That seems like an OF infrastructure
 issue that could be fixed. We could lump these drivers back together,
 and make sure that "brcm,nand-iproc" gets the priority in the
 of_device_id list.

 Or we could just relax the DT binding.

 But wait, wouldn't cygnus already have that problem? You're using the
 binding I suggested in arch/arm/boot/dts/bcm-cygnus.dtsi.
>>>
>>> Interestingly, we do not see this problem with Cygnus or NSP, but
>>> only on NS2
>>> (arm64 based). There may be a difference between how OF devices are
>>> instantiated between arm and arm64?
>>
>> Alternately, it could be also about order in-which platform drivers
>> are matched
>> for newly created OF device.
>>
>>>

 Oh, and I see we hacked this one in drivers/mtd/nand/brcmnand/Makefile:

 # link order matters; don't link the more generic brcmstb_nand.o
 before the
 # more specific iproc_nand.o, for instance
>>>
>>> Yes, I see that too (after sending out my previous email, :)). Maybe
>>> Anup can help to elaborate on the problem. I'm now getting a bit
>>> confused on how the problem can surface on NS2.
>>
>> I think for a newly created OF devices the Linux device driver
>> framework will
>> match the platform drivers in the order in which they are registered
>> by module
>> init functions. Now the order of module init function calls will be
>> based how
>> the .initcall section is formed by linker and order in which objects
>> are linked.
>>
> 
> Yes, what you said is my understanding as well, but then here is the
> mystery. This is the link order in brcmnand/Makefile:
> 
> 1 # link order matters; don't link the more generic brcmstb_nand.o
> before the
> 2 # more specific iproc_nand.o, for instance
> 3 obj-$(CONFIG_MTD_NAND_BRCMNAND) += iproc_nand.o
> 4 obj-$(CONFIG_MTD_NAND_BRCMNAND) += bcm63138_nand.o
> 5 obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmstb_nand.o
> 6 obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand.o
> 
> Based on the order above, probe from iproc_nand should always be called
> first if a matching compatible string is found. If so, then why having
> both compatible strings "brcm,brcmnand" and "brcm,nand-iproc" causes
> issues for NS2 (I remember it broke smoketest in the past when you
> submitted the change)? I'm not saying we should have "brcm,brcmnand" for
> iProc devices, but I don't get why it would cause any issue.
> 
> Does the order of the compatible string matter when they are assigned to
> the same 'compatible' property like this?
> 
> compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1","brcm,brcmnand";

It is possible that by the time this was designed and tested, and the
baseline you are now using, there have been changes in how probing is
done and resolved. I have not been able to pin point which commit would
be responsible for that, but it would not surprise me that something
changed in that area, especially with all the on-going on-demand probing
business happening.
-- 
Florian
--
To unsubscribe from

Re: [PATCH v12 3/6] fpga: add simple-fpga-bus

[atull]

On Wed, 28 Oct 2015, Josh Cartwright wrote:

> On Wed, Oct 28, 2015 at 12:03:41PM -0500, atull wrote:
> > On Wed, 28 Oct 2015, Moritz Fischer wrote:
> > 
> > > On Wed, Oct 28, 2015 at 9:18 AM, Josh Cartwright  wrote:
> > > > On Wed, Oct 28, 2015 at 08:37:51AM -0700, Moritz Fischer wrote:
> > > >> On Wed, Oct 28, 2015 at 3:07 AM, Josh Cartwright  wrote:
> > > >> > On Tue, Oct 27, 2015 at 05:09:12PM -0500, 
> > > >> > at...@opensource.altera.com wrote:
> > > >> >> From: Alan Tull 
> > > >> >>
> > > >> >> The Simple FPGA bus uses the FPGA Manager Framework and the
> > > >> >> FPGA Bridge Framework to provide a manufactorer-agnostic
> > > >> >> interface for reprogramming FPGAs that is Device Tree
> > > >> >> Overlays-based.
> > > >> >
> > > >> > Do you intend the "simple-fpga-bus" to be used on Zynq as well?  The
> > > >> > whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq 
> > > >> > at
> > > >> > all, from what I can tell.
> > > >>
> > > >> For Zynq the zynq-fpga driver takes care of the level shifters on full
> > > >> reconfiguration,
> > > >> and doesn't for partial reconfiguration. Now depending on which parts
> > > >> of the fabric
> > > >> are partial reconfigured (say AXI masters), one might run into issues
> > > >> with a setup like that.
> > > >>
> > > >> My first plan was to counter that by using zynq-reset to hold the
> > > >> reset high during
> > > >> reconfiguration of that part of the FPGA.
> > > >>
> > > >> I'm happy to rethink that part and maybe redo the level shifters and
> > > >> resets together in a bridge
> > > >> driver under devicetree control gives finer grained control.
> > > >
> > > > There is already a framework which is used to describe and manipulate
> > > > level shifting/other IO properties, and that is pinctrl, and if we
> > > > wanted to use an appropriate abstraction, I think pinctrl would be the
> > > > best bet.
> > > 
> > > Alright, I'll investigate that. Again, for the non-partial reconfig
> > > case I'm happy
> > > with the behavior as implemented, for the partial reconfig I just
> > > haven't run into
> > > issues with not dealing with the level shifters.
> > 
> > Are you suggesting pinctrl instead of introducing a FPGA Bridge Framework?
> 
> I'm suggesting that for the set of operations/configuration states that
> need to be managed _for the Zynq[1]_ during reprogramming, I think
> pinctrl might be a good fit.

Hi Josh,

OK, thanks for the clarification.  Communication is hard :)

> 
> But the pinctrl state activation would happen in the context of the zynq
> fpga_mgr_ops write
> 
> I do not think it's a good fit for the socfpga, or for the lower level
> fpga drivers _in general_.  Nor do I think that the FPGA Bridge
> framework, as written, is a good fit for fpgas in general.

OK so about that last sentence...

For full reconfiguration, we could control the hardware bridges from the
FPGA Manager and that would be fine, because the area affected by the bridge
is the whole area, which is what the FPGA Manager will reprogram.

For partial reconfiguration, we can have one FPGA Manager programming
several PR areas.  Each PR area will need its own bridge within the
FPGA.  It no longer makes sense to control bridges from the manager.
So Xilinx may need this yet, for PR.

And again, if you don't need it, you won't have to deal with it.  I'll make
it so that the simple fpga bus works fine with the fpga bridges compiled out
even.

Alan

> 
>   Josh
> 
> [1]: Speaking only of the Zynq 7000-series, I don't know anything about
>  the fancy new Zynq MPSoC :)
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 02/19] Documentation: devicetree: fix reference to legacy wakeup properties

[Sudeep Holla]

On 21/10/15 23:04, Rob Herring wrote:

On Wed, Oct 21, 2015 at 5:09 AM, Sudeep Holla  wrote:

This patch marks all the reference to the legacy wakeup bindings
and replaces them with the standard "wakeup-source" property.

All these legacy property are also listed under a separate section in
the generic wakeup-source binding document.

Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Ian Campbell 
Signed-off-by: Sudeep Holla 


Acked-by: Rob Herring 



Thanks Rob, can you take these couple(first two) of DT binding patches
via devicetree. I can then push remaining patches via respective trees
later.

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

Re: [PATCH v12 3/6] fpga: add simple-fpga-bus

[Josh Cartwright]

On Wed, Oct 28, 2015 at 12:59:16PM -0500, Josh Cartwright wrote:
> On Wed, Oct 28, 2015 at 12:03:41PM -0500, atull wrote:
> > On Wed, 28 Oct 2015, Moritz Fischer wrote:
> > 
> > > On Wed, Oct 28, 2015 at 9:18 AM, Josh Cartwright  wrote:
> > > > On Wed, Oct 28, 2015 at 08:37:51AM -0700, Moritz Fischer wrote:
> > > >> On Wed, Oct 28, 2015 at 3:07 AM, Josh Cartwright  wrote:
> > > >> > On Tue, Oct 27, 2015 at 05:09:12PM -0500, 
> > > >> > at...@opensource.altera.com wrote:
> > > >> >> From: Alan Tull 
> > > >> >>
> > > >> >> The Simple FPGA bus uses the FPGA Manager Framework and the
> > > >> >> FPGA Bridge Framework to provide a manufactorer-agnostic
> > > >> >> interface for reprogramming FPGAs that is Device Tree
> > > >> >> Overlays-based.
> > > >> >
> > > >> > Do you intend the "simple-fpga-bus" to be used on Zynq as well?  The
> > > >> > whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq 
> > > >> > at
> > > >> > all, from what I can tell.
> > > >>
> > > >> For Zynq the zynq-fpga driver takes care of the level shifters on full
> > > >> reconfiguration,
> > > >> and doesn't for partial reconfiguration. Now depending on which parts
> > > >> of the fabric
> > > >> are partial reconfigured (say AXI masters), one might run into issues
> > > >> with a setup like that.
> > > >>
> > > >> My first plan was to counter that by using zynq-reset to hold the
> > > >> reset high during
> > > >> reconfiguration of that part of the FPGA.
> > > >>
> > > >> I'm happy to rethink that part and maybe redo the level shifters and
> > > >> resets together in a bridge
> > > >> driver under devicetree control gives finer grained control.
> > > >
> > > > There is already a framework which is used to describe and manipulate
> > > > level shifting/other IO properties, and that is pinctrl, and if we
> > > > wanted to use an appropriate abstraction, I think pinctrl would be the
> > > > best bet.
> > > 
> > > Alright, I'll investigate that. Again, for the non-partial reconfig
> > > case I'm happy
> > > with the behavior as implemented, for the partial reconfig I just
> > > haven't run into
> > > issues with not dealing with the level shifters.
> > 
> > Are you suggesting pinctrl instead of introducing a FPGA Bridge Framework?
> 
> I'm suggesting that for the set of operations/configuration states that
> need to be managed _for the Zynq[1]_ during reprogramming, I think
> pinctrl might be a good fit.
> 
> But the pinctrl state activation would happen in the context of the zynq
> fpga_mgr_ops write

*grr*... in the context of the zynq's write_init(), and write_complete()
callbacks.

  Josh
--
To unsubscribe from this list: send the line "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 v12 3/6] fpga: add simple-fpga-bus

[Josh Cartwright]

On Wed, Oct 28, 2015 at 12:03:41PM -0500, atull wrote:
> On Wed, 28 Oct 2015, Moritz Fischer wrote:
> 
> > On Wed, Oct 28, 2015 at 9:18 AM, Josh Cartwright  wrote:
> > > On Wed, Oct 28, 2015 at 08:37:51AM -0700, Moritz Fischer wrote:
> > >> On Wed, Oct 28, 2015 at 3:07 AM, Josh Cartwright  wrote:
> > >> > On Tue, Oct 27, 2015 at 05:09:12PM -0500, at...@opensource.altera.com 
> > >> > wrote:
> > >> >> From: Alan Tull 
> > >> >>
> > >> >> The Simple FPGA bus uses the FPGA Manager Framework and the
> > >> >> FPGA Bridge Framework to provide a manufactorer-agnostic
> > >> >> interface for reprogramming FPGAs that is Device Tree
> > >> >> Overlays-based.
> > >> >
> > >> > Do you intend the "simple-fpga-bus" to be used on Zynq as well?  The
> > >> > whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq at
> > >> > all, from what I can tell.
> > >>
> > >> For Zynq the zynq-fpga driver takes care of the level shifters on full
> > >> reconfiguration,
> > >> and doesn't for partial reconfiguration. Now depending on which parts
> > >> of the fabric
> > >> are partial reconfigured (say AXI masters), one might run into issues
> > >> with a setup like that.
> > >>
> > >> My first plan was to counter that by using zynq-reset to hold the
> > >> reset high during
> > >> reconfiguration of that part of the FPGA.
> > >>
> > >> I'm happy to rethink that part and maybe redo the level shifters and
> > >> resets together in a bridge
> > >> driver under devicetree control gives finer grained control.
> > >
> > > There is already a framework which is used to describe and manipulate
> > > level shifting/other IO properties, and that is pinctrl, and if we
> > > wanted to use an appropriate abstraction, I think pinctrl would be the
> > > best bet.
> > 
> > Alright, I'll investigate that. Again, for the non-partial reconfig
> > case I'm happy
> > with the behavior as implemented, for the partial reconfig I just
> > haven't run into
> > issues with not dealing with the level shifters.
> 
> Are you suggesting pinctrl instead of introducing a FPGA Bridge Framework?

I'm suggesting that for the set of operations/configuration states that
need to be managed _for the Zynq[1]_ during reprogramming, I think
pinctrl might be a good fit.

But the pinctrl state activation would happen in the context of the zynq
fpga_mgr_ops write

I do not think it's a good fit for the socfpga, or for the lower level
fpga drivers _in general_.  Nor do I think that the FPGA Bridge
framework, as written, is a good fit for fpgas in general.

  Josh

[1]: Speaking only of the Zynq 7000-series, I don't know anything about
 the fancy new Zynq MPSoC :)
--
To unsubscribe from this list: send the line "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 v4 05/11] dt-bindings: drm/mediatek: Add Mediatek HDMI dts binding

[Philipp Zabel]

Hi Rob,

thank you for the comments.

Am Freitag, den 23.10.2015, 07:29 -0500 schrieb Rob Herring:
[...]
> > +Mediatek HDMI Encoder
> > +=
> > +
> > +The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from
> > +its parallel input.
> 
> How do you know whether it is HDMI or MHL on a given board? You should
> have a connector node perhaps.

Sounds sensible. I haven't really thought about MHL, my test board has a
slimport bridge. For HDMI we already have the "hdmi-connector"
compatible. I suppose for MHL we'd have to add a new "usb-connector"?

> > +
> > +Required properties:
> > +- compatible: Should be "mediatek,-hdmi".
> > +- reg: Physical base address and length of the controller's registers
> > +- interrupts: The interrupt signal from the function block.
> > +- clocks: device clocks
> > +  See Documentation/devicetree/bindings/clock/clock-bindings.txt for 
> > details.
> > +- clock-names: must contain "pixel", "pll", "bclk", and "spdif".
> > +- mediatek,cec: phandle link to the HDMI CEC node.
> 
> Do you have more than 1 CEC block? If not, just find the compatible
> node with of_find_compatible_node.

MT8173 only has one CEC block, so I will drop this property again.

> > +- ddc-i2c-bus: phandle link to the I2C controller used for DDC EDID probing
> 
> This really should be part of a connector node as I2C bus goes to the
> connector, not the HDMI block.

So I should add that as an optional property to the hdmi-connector
binding. I'll have to check how DDC is handled for MHL.

[...]
> > +HDMI PHY
> > +
> > +
> > +The HDMI PHY serializes the HDMI encoder's three channel 10-bit parallel
> > +output and drives the HDMI pads.
> > +
> > +Required properties:
[...]
> > +
> > +Optional properties:
> > +- ibias: TX DRV bias current for <1.65Gbps, defaults to 0xa
> > +- ibias_up: TX DRV bias current for >1.65Gbps, defaults to 0x1c
> 
> prefix with "mediatek,"

Will do.

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

Re: [PATCH v12 3/6] fpga: add simple-fpga-bus

[atull]

On Wed, 28 Oct 2015, atull wrote:

> On Wed, 28 Oct 2015, Moritz Fischer wrote:
> 
> > On Wed, Oct 28, 2015 at 9:18 AM, Josh Cartwright  wrote:
> > > On Wed, Oct 28, 2015 at 08:37:51AM -0700, Moritz Fischer wrote:
> > >> On Wed, Oct 28, 2015 at 3:07 AM, Josh Cartwright  wrote:
> > >> > On Tue, Oct 27, 2015 at 05:09:12PM -0500, at...@opensource.altera.com 
> > >> > wrote:
> > >> >> From: Alan Tull 
> > >> >>
> > >> >> The Simple FPGA bus uses the FPGA Manager Framework and the
> > >> >> FPGA Bridge Framework to provide a manufactorer-agnostic
> > >> >> interface for reprogramming FPGAs that is Device Tree
> > >> >> Overlays-based.
> > >> >
> > >> > Do you intend the "simple-fpga-bus" to be used on Zynq as well?  The
> > >> > whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq at
> > >> > all, from what I can tell.
> > >>
> > >> For Zynq the zynq-fpga driver takes care of the level shifters on full
> > >> reconfiguration,
> > >> and doesn't for partial reconfiguration. Now depending on which parts
> > >> of the fabric
> > >> are partial reconfigured (say AXI masters), one might run into issues
> > >> with a setup like that.
> > >>
> > >> My first plan was to counter that by using zynq-reset to hold the
> > >> reset high during
> > >> reconfiguration of that part of the FPGA.
> > >>
> > >> I'm happy to rethink that part and maybe redo the level shifters and
> > >> resets together in a bridge
> > >> driver under devicetree control gives finer grained control.
> > >
> > > There is already a framework which is used to describe and manipulate
> > > level shifting/other IO properties, and that is pinctrl, and if we
> > > wanted to use an appropriate abstraction, I think pinctrl would be the
> > > best bet.
> > 
> > Alright, I'll investigate that. Again, for the non-partial reconfig
> > case I'm happy
> > with the behavior as implemented, for the partial reconfig I just
> > haven't run into
> > issues with not dealing with the level shifters.
> 
> Are you suggesting pinctrl instead of introducing a FPGA Bridge Framework?
> If it fits, that's great.  Steffen is urging us to include reconfiguring
> width of the bridge so I'm trying to figure how and if that all fits in
> here.
> 

Hi Josh,

I don't think pinctrl is a good match here or even could be made to do
what we need here.  Simple FPGA Bus needs, at minimum, an API to call
to enable/disable data through a bridge to protect the processor bus
from spurious data while the FPGA is being programmed.

Alan
--
To unsubscribe from this list: send the line "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 v4 02/11] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.

[Philipp Zabel]

Hi Daniel,

Am Montag, den 19.10.2015, 10:56 +0200 schrieb Daniel Vetter:
> On Fri, Oct 16, 2015 at 10:12:04PM +0200, Philipp Zabel wrote:
> > From: CK Hu 
> > 
> > This patch adds an initial DRM driver for the Mediatek MT8173 DISP
> > subsystem. It currently supports two fixed output streams from the
> > OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively.
> > 
> > Signed-off-by: CK Hu 
> > Signed-off-by: YT Shen 
> > Signed-off-by: Philipp Zabel 
> 
> Bunch of drive-by comments below to point out deprecated functions and
> more common approaches used by other drivers. Don't consider this a full
> review ;-)

Much appreciated all the same.

> Cheers, Daniel
> 
> > ---
> > Changes since v3:
> >  - Removed crtc enabling/disabling on bind/unbind, the enable/disable
> >callbacks should suffice.
> >  - Find sibling components in the device tree via compatible value
> 
> btw for DT components stuff there's piles of RFCs floating around to
> extract this into helper libraries. Would be great we could push one of
> them forward.

The non-mediatek-specific part currently is the

for_each_child_of_node(bus_node, node) {
of_id = of_match_node(dt_ids, node);
if (!of_id)
continue;
if (!of_device_is_available(node))
continue;

/* ... */
}

loop. This is somewhat similar to a combination of
for_each_matching_node_and_match and for_each_available_child_of_node.
for_each_available_matching_child_of_node_and_match would be quite a
mouthful though.

[...]
> > +struct mtk_drm_crtc {
> > +   struct drm_crtc base;
> > +   unsigned intpipe;
> > +   boolenabled;
> > +   struct mtk_crtc_ddp_context *ctx;
> > +
> > +   struct drm_pending_vblank_event *event;
> > +   boolpending_needs_vblank;
> > +};
> > +
> > +struct mtk_crtc_ddp_context {
> > +   struct device   *dev;
> > +   struct drm_device   *drm_dev;
> > +   struct mtk_drm_crtc *crtc;
> > +   struct mtk_drm_planeplanes[OVL_LAYER_NR];
> > +   int pipe;
> > +
> > +   void __iomem*config_regs;
> > +   struct device   *mutex_dev;
> > +   u32 ddp_comp_nr;
> > +   struct mtk_ddp_comp *ddp_comp;
> 
> All the above probably should just be moved into mtk_drm_crtc. At least I
> don't understand why you need this indirection.

Agreed. This was needed for a debugfs patch that I have left out for
now.

> > +
> > +   boolpending_config;
> > +   unsigned intpending_width;
> > +   unsigned intpending_height;
> > +
> > +   boolpending_ovl_config[OVL_LAYER_NR];
> > +   boolpending_ovl_enable[OVL_LAYER_NR];
> > +   unsigned intpending_ovl_addr[OVL_LAYER_NR];
> > +   unsigned intpending_ovl_pitch[OVL_LAYER_NR];
> > +   unsigned intpending_ovl_format[OVL_LAYER_NR];
> > +   int pending_ovl_x[OVL_LAYER_NR];
> > +   int pending_ovl_y[OVL_LAYER_NR];
> > +   unsigned intpending_ovl_size[OVL_LAYER_NR];
> > +   boolpending_ovl_dirty[OVL_LAYER_NR];
> 
> This works since you only touch these in the atomic_commit phase, but the
> recommend way to do this with atomic is to subclass drm_crtc_state:
>
> struct mtk_crtc_state {
>   struct drm_crtc_state base;
> 
>   /* all the pending_ stuff above */
> };
> 
> Then you just pass the mtk to your irq handler to do the update.

I'll move these into mtk_crtc_state, but I'm not sure what you mean with
the last sentence. Currently I pass the mtk_crtc_ddp_context to the irq
handler. I can get to the mtk_crtc_state from that.

> > +static int mtk_drm_bind(struct device *dev)
> > +{
> > +   return drm_platform_init(&mtk_drm_driver, to_platform_device(dev));
> 
> This is deprecated, please use drm_dev_alloc/drm_dev_register instead and
> remove your ->load driver callback.

Will replace drm_platform_init with drm_dev_alloc/drm_dev_register and
integrate mtk_drm_load into mtk_drm_bind.

> > +int mtk_drm_gem_dumb_map_offset(struct drm_file *file_priv,
> > +   struct drm_device *dev, uint32_t handle,
> > +   uint64_t *offset)
> > +{
> > +   struct drm_gem_object *obj;
> > +   int ret;
> > +
> > +   mutex_lock(&dev->struct_mutex);
> 
> struct_mutex isn't needed here (gem object lookup and the vma stuff are
> all protected by looks already). Please drop it.
[...]
> > +out:
> > +   drm_gem_object_unreference(obj);
> 
> But then you need unreference_unlocked here.

Ok, dropped the lock.

[...]
> > +int mtk_drm_g

Re: [RFC v4 02/11] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.

[Philipp Zabel]

Hi Daniel,

Am Montag, den 19.10.2015, 10:56 +0200 schrieb Daniel Vetter:
> On Fri, Oct 16, 2015 at 10:12:04PM +0200, Philipp Zabel wrote:
> > From: CK Hu 
> > 
> > This patch adds an initial DRM driver for the Mediatek MT8173 DISP
> > subsystem. It currently supports two fixed output streams from the
> > OVL0/OVL1 sources to the DSI0/DPI0 sinks, respectively.
> > 
> > Signed-off-by: CK Hu 
> > Signed-off-by: YT Shen 
> > Signed-off-by: Philipp Zabel 
> 
> Bunch of drive-by comments below to point out deprecated functions and
> more common approaches used by other drivers. Don't consider this a full
> review ;-)

Much appreciated all the same.

> Cheers, Daniel
> 
> > ---
> > Changes since v3:
> >  - Removed crtc enabling/disabling on bind/unbind, the enable/disable
> >callbacks should suffice.
> >  - Find sibling components in the device tree via compatible value
> 
> btw for DT components stuff there's piles of RFCs floating around to
> extract this into helper libraries. Would be great we could push one of
> them forward.

The non-mediatek-specific part currently is the

for_each_child_of_node(bus_node, node) {
of_id = of_match_node(dt_ids, node);
if (!of_id)
continue;
if (!of_device_is_available(node))
continue;

/* ... */
}

loop. This is somewhat similar to a combination of
for_each_matching_node_and_match and for_each_available_child_of_node.
for_each_available_matching_child_of_node_and_match would be quite a
mouthful though.

[...]
> > +struct mtk_drm_crtc {
> > +   struct drm_crtc base;
> > +   unsigned intpipe;
> > +   boolenabled;
> > +   struct mtk_crtc_ddp_context *ctx;
> > +
> > +   struct drm_pending_vblank_event *event;
> > +   boolpending_needs_vblank;
> > +};
> > +
> > +struct mtk_crtc_ddp_context {
> > +   struct device   *dev;
> > +   struct drm_device   *drm_dev;
> > +   struct mtk_drm_crtc *crtc;
> > +   struct mtk_drm_planeplanes[OVL_LAYER_NR];
> > +   int pipe;
> > +
> > +   void __iomem*config_regs;
> > +   struct device   *mutex_dev;
> > +   u32 ddp_comp_nr;
> > +   struct mtk_ddp_comp *ddp_comp;
> 
> All the above probably should just be moved into mtk_drm_crtc. At least I
> don't understand why you need this indirection.

Agreed. This was needed for a debugfs patch that I have left out for
now.

> > +
> > +   boolpending_config;
> > +   unsigned intpending_width;
> > +   unsigned intpending_height;
> > +
> > +   boolpending_ovl_config[OVL_LAYER_NR];
> > +   boolpending_ovl_enable[OVL_LAYER_NR];
> > +   unsigned intpending_ovl_addr[OVL_LAYER_NR];
> > +   unsigned intpending_ovl_pitch[OVL_LAYER_NR];
> > +   unsigned intpending_ovl_format[OVL_LAYER_NR];
> > +   int pending_ovl_x[OVL_LAYER_NR];
> > +   int pending_ovl_y[OVL_LAYER_NR];
> > +   unsigned intpending_ovl_size[OVL_LAYER_NR];
> > +   boolpending_ovl_dirty[OVL_LAYER_NR];
> 
> This works since you only touch these in the atomic_commit phase, but the
> recommend way to do this with atomic is to subclass drm_crtc_state:
>
> struct mtk_crtc_state {
>   struct drm_crtc_state base;
> 
>   /* all the pending_ stuff above */
> };
> 
> Then you just pass the mtk to your irq handler to do the update.

I'll move these into mtk_crtc_state, but I'm not sure what you mean with
the last sentence. Currently I pass the mtk_crtc_ddp_context to the irq
handler. I can get to the mtk_crtc_state from that.

> > +static int mtk_drm_bind(struct device *dev)
> > +{
> > +   return drm_platform_init(&mtk_drm_driver, to_platform_device(dev));
> 
> This is deprecated, please use drm_dev_alloc/drm_dev_register instead and
> remove your ->load driver callback.

Will replace drm_platform_init with drm_dev_alloc/drm_dev_register and
integrate mtk_drm_load into mtk_drm_bind.

> > +int mtk_drm_gem_dumb_map_offset(struct drm_file *file_priv,
> > +   struct drm_device *dev, uint32_t handle,
> > +   uint64_t *offset)
> > +{
> > +   struct drm_gem_object *obj;
> > +   int ret;
> > +
> > +   mutex_lock(&dev->struct_mutex);
> 
> struct_mutex isn't needed here (gem object lookup and the vma stuff are
> all protected by looks already). Please drop it.
[...]
> > +out:
> > +   drm_gem_object_unreference(obj);
> 
> But then you need unreference_unlocked here.

Ok, dropped the lock.

[...]
> > +int mtk_drm_g

Re: [PATCH v12 3/6] fpga: add simple-fpga-bus

[atull]

On Wed, 28 Oct 2015, Moritz Fischer wrote:

> On Wed, Oct 28, 2015 at 9:18 AM, Josh Cartwright  wrote:
> > On Wed, Oct 28, 2015 at 08:37:51AM -0700, Moritz Fischer wrote:
> >> On Wed, Oct 28, 2015 at 3:07 AM, Josh Cartwright  wrote:
> >> > On Tue, Oct 27, 2015 at 05:09:12PM -0500, at...@opensource.altera.com 
> >> > wrote:
> >> >> From: Alan Tull 
> >> >>
> >> >> The Simple FPGA bus uses the FPGA Manager Framework and the
> >> >> FPGA Bridge Framework to provide a manufactorer-agnostic
> >> >> interface for reprogramming FPGAs that is Device Tree
> >> >> Overlays-based.
> >> >
> >> > Do you intend the "simple-fpga-bus" to be used on Zynq as well?  The
> >> > whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq at
> >> > all, from what I can tell.
> >>
> >> For Zynq the zynq-fpga driver takes care of the level shifters on full
> >> reconfiguration,
> >> and doesn't for partial reconfiguration. Now depending on which parts
> >> of the fabric
> >> are partial reconfigured (say AXI masters), one might run into issues
> >> with a setup like that.
> >>
> >> My first plan was to counter that by using zynq-reset to hold the
> >> reset high during
> >> reconfiguration of that part of the FPGA.
> >>
> >> I'm happy to rethink that part and maybe redo the level shifters and
> >> resets together in a bridge
> >> driver under devicetree control gives finer grained control.
> >
> > There is already a framework which is used to describe and manipulate
> > level shifting/other IO properties, and that is pinctrl, and if we
> > wanted to use an appropriate abstraction, I think pinctrl would be the
> > best bet.
> 
> Alright, I'll investigate that. Again, for the non-partial reconfig
> case I'm happy
> with the behavior as implemented, for the partial reconfig I just
> haven't run into
> issues with not dealing with the level shifters.

Are you suggesting pinctrl instead of introducing a FPGA Bridge Framework?
If it fits, that's great.  Steffen is urging us to include reconfiguring
width of the bridge so I'm trying to figure how and if that all fits in
here.

> 
> > Implementing the FPGA Bridge interface in the Zynq driver because it's
> > what the core expects is just backwards.  It's an abstraction inversion.
> 
> Yeah, you're probably right.

Sorry I wasn't clear earlier, but I am going to change simple FPGA bus
to be OK with the "fpga-bridges" property being left out.  The change is
to do that should just be for simple_fpga_bus_get_bridges() to return 0
if it doesn't find any bridges.  The FPGA can still get programmed and
the child devices get populated.  All the other FPGA bridge-related
function calls (simple_fpga_bus_bridge_enable/disable and
simple_fpga_bus_put_bridges) won't have any effect when
simple_fpga_bus_get_bridges leaves num_bridges==0 and bridges==NULL.

So if you don't need bridges, you can leave that out (once I've fixed
that).

Actually if you want to use simple fpga bus with FPGA bridges compiled out,
I could even have the fpga bridge APIs become empty functions.

Alan

> 
> Thanks,
> 
> Moritz
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "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/4] watchdog: ts4800: add new driver for TS-4800 watchdog

[Damien Riegel]

On Tue, Oct 27, 2015 at 07:05:01PM -0700, Guenter Roeck wrote:
> In general, naming a driver for the first chip it supports is not
> problematic. Making it too generic is, on the other side, problematic.
> What are you going to do if ts4900 (or ts4801) implements a different
> watchdog ?

Okay, I will keep the current name.

I noticed that other boards might have their feed register at different
offsets from syscon base. For instance, feed register is at offset 0x6
on TS-4720 and offset 0xE on TS-4800 (syscon registers are 16-bit wide).
So I need to address that as well (it is related to the next point).

Currently, the driver maps all syscon registers even if it uses only one
of them. I was thinking about adding a "syscon" node and define the
watchdog as a child of it, but the syscon driver set
syscon_regmap_config.val_bits to 32. Do I have to create a new driver if
I want to use val_bits = 16, or is there another way ?

Damien
--
To unsubscribe from this list: send the line "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] EDAC: Add ARM64 EDAC

[Mark Rutland]

Hi,

On Wed, Oct 28, 2015 at 11:13:49AM -0500, Brijesh Singh wrote:
> Add support for Cortex A57 and A53 EDAC driver.
> 
> Signed-off-by: Brijesh Singh 
> CC: robh...@kernel.org
> CC: pawel.m...@arm.com
> CC: mark.rutl...@arm.com
> CC: ijc+devicet...@hellion.org.uk
> CC: ga...@codeaurora.org
> CC: dougthomp...@xmission.com
> CC: b...@alien8.de
> CC: mche...@osg.samsung.com
> CC: devicetree@vger.kernel.org
> CC: guohan...@huawei.com
> CC: andre.przyw...@arm.com
> CC: a...@arndb.de
> CC: sb...@codeaurora.org
> CC: linux-ker...@vger.kernel.org
> CC: linux-e...@vger.kernel.org
> ---
> Tested error reporting via rasdeamon on AMD seattle platform.
> 
> v4:
> * remove THIS_MODULE assignment from platform_driver
> * use module_platform_driver(), remove module_init() and module_exit()
> * remove default n from Kconfig
> 
> v3:
> * change DT binding compatibilty string to 'cortex-a57-edac'
> * remove A57/A53 prefix from register bit definition
> * unify A57 and A53 L1/L2 error parsing functions
> * use mc trace event function to report the error
> * update Kconfig default to 'n'
> 
> v2:
> * convert into generic arm64 edac driver
> * remove AMD specific references from dt binding
> * remove poll_msec property from dt binding
> * add poll_msec as a module param, default is 100ms
> * update copyright text
> * define macro mnemonics for L1 and L2 RAMID
> * check L2 error per-cluster instead of per core
> * update function names
> * use get_online_cpus() and put_online_cpus() to make L1 and L2 register 
>   read hotplug-safe
> * add error check in probe routine
> 
>  .../devicetree/bindings/edac/cortex-arm64-edac.txt |  15 +
>  drivers/edac/Kconfig   |   7 +
>  drivers/edac/Makefile  |   1 +
>  drivers/edac/cortex_arm64_edac.c   | 336 
> +
>  4 files changed, 359 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/edac/cortex-arm64-edac.txt
>  create mode 100644 drivers/edac/cortex_arm64_edac.c
> 
> diff --git a/Documentation/devicetree/bindings/edac/cortex-arm64-edac.txt 
> b/Documentation/devicetree/bindings/edac/cortex-arm64-edac.txt
> new file mode 100644
> index 000..552f0c7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/edac/cortex-arm64-edac.txt
> @@ -0,0 +1,15 @@
> +* ARM Cortex A57 and A53 L1/L2 cache error reporting
> +
> +CPU Memory Error Syndrome and L2 Memory Error Syndrome registers can be used
> +for checking L1 and L2 memory errors.
> +
> +The following section describes the Cortex A57/A53 EDAC DT node binding.
> +
> +Required properties:
> +- compatible: Should be "arm,cortex-a57-edac" or "arm,cortex-a53-edac"
> +
> +Example:
> + edac {
> + compatible = "arm,cortex-a57-edac";
> + };
> +

This is insufficient for big.LITTLE, no interrupt is possible, and we
haven't defined the rules for accessing the registers (e.g. whether
write backs are permitted).

Please see my prior comments [1] on those points.

If we're going to use this feature directly within the kernel, we need
to consider the envelope of possible implementations rather than your
use-case alone.

> +static void parse_cpumerrsr(void *arg)
> +{
> + int cpu, partnum, way;
> + unsigned int index = 0;
> + u64 val = read_cpumerrsr_el1();
> + int repeat_err, other_err;
> +
> + /* we do not support fatal error handling so far */
> + if (CPUMERRSR_EL1_FATAL(val))
> + return;

Silently ignoring fatal errors doesn't seem good.

Shouldn't this be checked after the valid bit?

> + /* check if we have valid error before continuing */
> + if (!CPUMERRSR_EL1_VALID(val))
> + return;
> +
> + cpu = smp_processor_id();
> + partnum = read_cpuid_part_number();
> + repeat_err = CPUMERRSR_EL1_REPEAT(val);
> + other_err = CPUMERRSR_EL1_OTHER(val);
> +
> + /* way/bank and index address bit ranges are different between
> +  * A57 and A53 */
> + if (partnum == ARM_CPU_PART_CORTEX_A57) {
> + index = CPUMERRSR_EL1_INDEX(val, 0x1);
> + way = CPUMERRSR_EL1_BANK_WAY(val, 0x1f);
> + } else {
> + index = CPUMERRSR_EL1_INDEX(val, 0xfff);
> + way = CPUMERRSR_EL1_BANK_WAY(val, 0x7);
> + }

Can the bit ranges not be determined at probe time rather than reading
the MIDR repeatedly?

> + edac_printk(KERN_CRIT, EDAC_MOD_STR, "CPU%d L1 error detected!\n", cpu);
> + edac_printk(KERN_CRIT, EDAC_MOD_STR, "index=%#x, RAMID=", index);
> +
> + switch (CPUMERRSR_EL1_RAMID(val)) {
> + case L1_I_TAG_RAM:
> + pr_cont("'L1-I Tag RAM' (way %d)", way);
> + break;
> + case L1_I_DATA_RAM:
> + pr_cont("'L1-I Data RAM' (bank %d)", way);
> + break;
> + case L1_D_TAG_RAM:
> + pr_cont("'L1-D Tag RAM' (way %d)", way);
> + break;
> + case L1_D_DATA_RAM:
> + pr_cont("'L1-D Data RAM' (bank %d)", way);
> +

Re: [PATCH v12 3/6] fpga: add simple-fpga-bus

[Moritz Fischer]

On Wed, Oct 28, 2015 at 9:18 AM, Josh Cartwright  wrote:
> On Wed, Oct 28, 2015 at 08:37:51AM -0700, Moritz Fischer wrote:
>> On Wed, Oct 28, 2015 at 3:07 AM, Josh Cartwright  wrote:
>> > On Tue, Oct 27, 2015 at 05:09:12PM -0500, at...@opensource.altera.com 
>> > wrote:
>> >> From: Alan Tull 
>> >>
>> >> The Simple FPGA bus uses the FPGA Manager Framework and the
>> >> FPGA Bridge Framework to provide a manufactorer-agnostic
>> >> interface for reprogramming FPGAs that is Device Tree
>> >> Overlays-based.
>> >
>> > Do you intend the "simple-fpga-bus" to be used on Zynq as well?  The
>> > whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq at
>> > all, from what I can tell.
>>
>> For Zynq the zynq-fpga driver takes care of the level shifters on full
>> reconfiguration,
>> and doesn't for partial reconfiguration. Now depending on which parts
>> of the fabric
>> are partial reconfigured (say AXI masters), one might run into issues
>> with a setup like that.
>>
>> My first plan was to counter that by using zynq-reset to hold the
>> reset high during
>> reconfiguration of that part of the FPGA.
>>
>> I'm happy to rethink that part and maybe redo the level shifters and
>> resets together in a bridge
>> driver under devicetree control gives finer grained control.
>
> There is already a framework which is used to describe and manipulate
> level shifting/other IO properties, and that is pinctrl, and if we
> wanted to use an appropriate abstraction, I think pinctrl would be the
> best bet.

Alright, I'll investigate that. Again, for the non-partial reconfig
case I'm happy
with the behavior as implemented, for the partial reconfig I just
haven't run into
issues with not dealing with the level shifters.

> Implementing the FPGA Bridge interface in the Zynq driver because it's
> what the core expects is just backwards.  It's an abstraction inversion.

Yeah, you're probably right.

Thanks,

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

Re: [PATCH v12 3/6] fpga: add simple-fpga-bus

[Josh Cartwright]

On Wed, Oct 28, 2015 at 08:37:51AM -0700, Moritz Fischer wrote:
> On Wed, Oct 28, 2015 at 3:07 AM, Josh Cartwright  wrote:
> > On Tue, Oct 27, 2015 at 05:09:12PM -0500, at...@opensource.altera.com wrote:
> >> From: Alan Tull 
> >>
> >> The Simple FPGA bus uses the FPGA Manager Framework and the
> >> FPGA Bridge Framework to provide a manufactorer-agnostic
> >> interface for reprogramming FPGAs that is Device Tree
> >> Overlays-based.
> >
> > Do you intend the "simple-fpga-bus" to be used on Zynq as well?  The
> > whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq at
> > all, from what I can tell.
> 
> For Zynq the zynq-fpga driver takes care of the level shifters on full
> reconfiguration,
> and doesn't for partial reconfiguration. Now depending on which parts
> of the fabric
> are partial reconfigured (say AXI masters), one might run into issues
> with a setup like that.
> 
> My first plan was to counter that by using zynq-reset to hold the
> reset high during
> reconfiguration of that part of the FPGA.
> 
> I'm happy to rethink that part and maybe redo the level shifters and
> resets together in a bridge
> driver under devicetree control gives finer grained control.

There is already a framework which is used to describe and manipulate
level shifting/other IO properties, and that is pinctrl, and if we
wanted to use an appropriate abstraction, I think pinctrl would be the
best bet.

Implementing the FPGA Bridge interface in the Zynq driver because it's
what the core expects is just backwards.  It's an abstraction inversion.

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

Re: [PATCH v3 2/2] arm64: dts: Add BRCM IPROC NAND DT node for NS2

[Ray Jui]

On 10/28/2015 2:06 AM, Anup Patel wrote:




-Original Message-
From: Ray Jui [mailto:r...@broadcom.com]
Sent: 28 October 2015 06:17
To: Brian Norris
Cc: Anup Patel; David Woodhouse; Linux MTD; Rob Herring; Pawel Moll; Mark
Rutland; Catalin Marinas; Will Deacon; Sudeep Holla; Ian Campbell; Kumar Gala;
Scott Branden; Florian Fainelli; Pramod Kumar; Vikram Prakash; Sandeep
Tripathy; Linux ARM Kernel; Device Tree; Linux Kernel; bcm-kernel-feedback-list
Subject: Re: [PATCH v3 2/2] arm64: dts: Add BRCM IPROC NAND DT node for
NS2



On 10/27/2015 5:39 PM, Brian Norris wrote:

On Tue, Oct 27, 2015 at 05:25:32PM -0700, Ray Jui wrote:

On 10/27/2015 5:19 PM, Brian Norris wrote:

On Fri, Oct 23, 2015 at 10:46:13AM +0530, Anup Patel wrote:

diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index f603277..9610822 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -212,5 +212,19 @@
compatible = "brcm,iproc-rng200";
reg = <0x6622 0x28>;
};
+
+   nand: nand@6646 {
+   compatible = "brcm,nand-iproc", "brcm,brcmnand-

v6.1";


Technically, the binding says you should also have "brcm,brcmnand"
as a last resort. Otherwise (for the NAND parts):



I believe Anup was seeing issues when both "brcm,nand-iproc" and
"brcm,brcmnand" are present.

Note "brcm,nand-iproc" invokes 'iproc_nand_probe', which calls
'brcmnand_probe' in the end.

"brcm,brcmnand" invokes 'brcmstb_nand_probe', which also calls
'brcmstb_probe', but without all the prep configuration required for
"brcm,nand-iproc".


Ah, I forgot about that problem. That seems like an OF infrastructure
issue that could be fixed. We could lump these drivers back together,
and make sure that "brcm,nand-iproc" gets the priority in the
of_device_id list.

Or we could just relax the DT binding.

But wait, wouldn't cygnus already have that problem? You're using the
binding I suggested in arch/arm/boot/dts/bcm-cygnus.dtsi.


Interestingly, we do not see this problem with Cygnus or NSP, but only on NS2
(arm64 based). There may be a difference between how OF devices are
instantiated between arm and arm64?


Alternately, it could be also about order in-which platform drivers are matched
for newly created OF device.





Oh, and I see we hacked this one in drivers/mtd/nand/brcmnand/Makefile:

# link order matters; don't link the more generic brcmstb_nand.o before the
# more specific iproc_nand.o, for instance


Yes, I see that too (after sending out my previous email, :)). Maybe
Anup can help to elaborate on the problem. I'm now getting a bit
confused on how the problem can surface on NS2.


I think for a newly created OF devices the Linux device driver framework will
match the platform drivers in the order in which they are registered by module
init functions. Now the order of module init function calls will be based how
the .initcall section is formed by linker and order in which objects are linked.



Yes, what you said is my understanding as well, but then here is the 
mystery. This is the link order in brcmnand/Makefile:


1 # link order matters; don't link the more generic brcmstb_nand.o 
before the

2 # more specific iproc_nand.o, for instance
3 obj-$(CONFIG_MTD_NAND_BRCMNAND) += iproc_nand.o
4 obj-$(CONFIG_MTD_NAND_BRCMNAND) += bcm63138_nand.o
5 obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmstb_nand.o
6 obj-$(CONFIG_MTD_NAND_BRCMNAND) += brcmnand.o

Based on the order above, probe from iproc_nand should always be called 
first if a matching compatible string is found. If so, then why having 
both compatible strings "brcm,brcmnand" and "brcm,nand-iproc" causes 
issues for NS2 (I remember it broke smoketest in the past when you 
submitted the change)? I'm not saying we should have "brcm,brcmnand" for 
iProc devices, but I don't get why it would cause any issue.


Does the order of the compatible string matter when they are assigned to 
the same 'compatible' property like this?


compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1","brcm,brcmnand";



IMHO, if multiple platform drivers match given OF device then platform driver
with longest matching compatible string should only be probed. I don't know
how big change this would be for OF framework.



But in general, I think it's a good idea to relax the requirement in the
DT binding document to not require "brcm,brcmnand", in the case when
"brcm,nand-iproc" and "brcm,nand-bcm63138" are present.


Even I think, it will be good to relax the DT bindings requirement for
BRCM NAND driver.

Regards,
Anup


--
To unsubscribe from this list: send the line "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] EDAC: Add ARM64 EDAC

[Brijesh Singh]

Add support for Cortex A57 and A53 EDAC driver.

Signed-off-by: Brijesh Singh 
CC: robh...@kernel.org
CC: pawel.m...@arm.com
CC: mark.rutl...@arm.com
CC: ijc+devicet...@hellion.org.uk
CC: ga...@codeaurora.org
CC: dougthomp...@xmission.com
CC: b...@alien8.de
CC: mche...@osg.samsung.com
CC: devicetree@vger.kernel.org
CC: guohan...@huawei.com
CC: andre.przyw...@arm.com
CC: a...@arndb.de
CC: sb...@codeaurora.org
CC: linux-ker...@vger.kernel.org
CC: linux-e...@vger.kernel.org
---
Tested error reporting via rasdeamon on AMD seattle platform.

v4:
* remove THIS_MODULE assignment from platform_driver
* use module_platform_driver(), remove module_init() and module_exit()
* remove default n from Kconfig

v3:
* change DT binding compatibilty string to 'cortex-a57-edac'
* remove A57/A53 prefix from register bit definition
* unify A57 and A53 L1/L2 error parsing functions
* use mc trace event function to report the error
* update Kconfig default to 'n'

v2:
* convert into generic arm64 edac driver
* remove AMD specific references from dt binding
* remove poll_msec property from dt binding
* add poll_msec as a module param, default is 100ms
* update copyright text
* define macro mnemonics for L1 and L2 RAMID
* check L2 error per-cluster instead of per core
* update function names
* use get_online_cpus() and put_online_cpus() to make L1 and L2 register 
  read hotplug-safe
* add error check in probe routine

 .../devicetree/bindings/edac/cortex-arm64-edac.txt |  15 +
 drivers/edac/Kconfig   |   7 +
 drivers/edac/Makefile  |   1 +
 drivers/edac/cortex_arm64_edac.c   | 336 +
 4 files changed, 359 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/edac/cortex-arm64-edac.txt
 create mode 100644 drivers/edac/cortex_arm64_edac.c

diff --git a/Documentation/devicetree/bindings/edac/cortex-arm64-edac.txt 
b/Documentation/devicetree/bindings/edac/cortex-arm64-edac.txt
new file mode 100644
index 000..552f0c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/edac/cortex-arm64-edac.txt
@@ -0,0 +1,15 @@
+* ARM Cortex A57 and A53 L1/L2 cache error reporting
+
+CPU Memory Error Syndrome and L2 Memory Error Syndrome registers can be used
+for checking L1 and L2 memory errors.
+
+The following section describes the Cortex A57/A53 EDAC DT node binding.
+
+Required properties:
+- compatible: Should be "arm,cortex-a57-edac" or "arm,cortex-a53-edac"
+
+Example:
+   edac {
+   compatible = "arm,cortex-a57-edac";
+   };
+
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index ef25000..e8f5306 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -390,4 +390,11 @@ config EDAC_XGENE
  Support for error detection and correction on the
  APM X-Gene family of SOCs.
 
+config EDAC_CORTEX_ARM64
+   tristate "ARM Cortex A57/A53"
+   depends on EDAC_MM_EDAC && ARM64
+   help
+ Support for error detection and correction on the
+ ARM Cortex A57 and A53.
+
 endif # EDAC
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index ae3c5f3..ac01660 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -68,3 +68,4 @@ obj-$(CONFIG_EDAC_OCTEON_PCI) += octeon_edac-pci.o
 obj-$(CONFIG_EDAC_ALTERA_MC)   += altera_edac.o
 obj-$(CONFIG_EDAC_SYNOPSYS)+= synopsys_edac.o
 obj-$(CONFIG_EDAC_XGENE)   += xgene_edac.o
+obj-$(CONFIG_EDAC_CORTEX_ARM64)+= cortex_arm64_edac.o
diff --git a/drivers/edac/cortex_arm64_edac.c b/drivers/edac/cortex_arm64_edac.c
new file mode 100644
index 000..b2a8723
--- /dev/null
+++ b/drivers/edac/cortex_arm64_edac.c
@@ -0,0 +1,336 @@
+/*
+ * Cortex A57 and A53 EDAC
+ *
+ * Copyright (c) 2015, Advanced Micro Devices
+ * Author: Brijesh Singh 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ *
+ * 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 "edac_core.h"
+
+#define DRV_NAME   "cortex_edac"
+
+#define CPUMERRSR_EL1_INDEX(x, y)  ((x) & (y))
+#define CPUMERRSR_EL1_BANK_WAY(x, y)   (((x) >> 18) & (y))
+#define CPUMERRSR_EL1_RAMID(x) (((x) >> 24) & 0x7f)
+#define CPUMERRSR_EL1_VALID(x) ((x) & (1 << 31))
+#define CPUMERRSR_EL1_REPEAT(x)(((x) >> 32) & 0x7f)
+#define CPUMERRSR_EL1_OTHER(x) (((x) >> 40) & 0xff)
+#define CPUMERRSR_EL1_FATAL(x) ((x) & (1UL << 63))
+#define L1_I_TAG_RAM   0x00
+#define L1_I_DATA_RAM  0x01
+#define L1_D_TAG_RAM  

Re: Which is better to specify console, "console= " or "stdout-path" ?

[Peter Hurley]

Hi Masahiro,

On 10/22/2015 12:20 AM, Masahiro Yamada wrote:
> 2015-10-22 1:26 GMT+09:00 Peter Hurley :
>> On 10/21/2015 11:38 AM, Masahiro Yamada wrote:
>>> 2015-10-21 21:46 GMT+09:00 Peter Hurley :
 On 10/21/2015 04:58 AM, Sudeep Holla wrote:
> On 21/10/15 06:09, Masahiro Yamada wrote:
>> I think there exist two ways to specify the console port and baudrate.
>>
>>
>> [1] Specify console in bootargs
>>
>>chosen {
>>  bootargs = "console=ttyS0,115200";
>>};
>>
>>
>> [2] Specify stdout-path
>>
>> chosen {
>>   stdout-path = "serial0:115200n8";
>
> This will work for even early/boot console, so this is better than
> option [1]

 Be aware that options specified via /chosen/stdout-path are
 currently ignored by earlycon. There were some hiccups getting the
 initial support upstream; when 4.4 hits mainline, I'll resubmit
 my series that implements the of_serial i/o properties and
 options passthrough to earlycon setup.
>>>
>>>
>>> As I said in another thread ("serial: earlycon: allow to specify
>>> uartclk in earlycon kernel-parameter"),
>>> stdout-path can pass dev->baud, but not port->uartclk.
>>
>> That's true but I'm not seeing in that thread where you wrote that?
> 
> Sorry, I made you confused.  I was talking about the kernel parameter 
> (console=)
> in the thread.
> 
>> My replies there were specific to uartclk on the kernel command line,
>> which isn't necessary if the bootloader has already initialized the
>> uart.
>>
>>> It is usually specified "clocks" phandle, but
>>> clk is not ready at the point of earlycon.
>>>
>>> It seems impossible to set up the baudrate even if the options are passed.
>>
>> It's difficult to understand what you're trying to do when I can't
>> see the code you're referring to.  For example, I only recently
>> understood that you're talking about a earlycon implementation
>> that you're working on and not the 8250 earlycon itself.
> 
> Sorry again for making you confused.
> 
> I was talking both.
> 
> Now I am tackling on some ARM board porting.
> 
> 
> The board has a pure 8250 family device (compatible = "ns16550a") on it.
> 
> In addition, there exist 8250-variant IPs inside the SoC.
> (this is similar to 8250, but slightly different.
> drivers/tty/serial/8250/8250_uniphier.c)
> 
> 
> What I want to do is:
>   [1] To use  drivers/tty/serial/8250/8250_early.c  for the on-board ns16550a.
>   [2] To implement my own EARLYCON_DECLARE() in
> drivers/tty/serial/8250/8250_uniphier.c
> 
> 
> 
>> If you look at other non-8250 earlycons, you'll see they all ignore
>> the baud rate, on the assumption the bootloader already set it up.
> 
> OK, I will do so for [2].
> 
> 
>> The 8250 earlycon is a little different because legacy platforms
>> do not initialize the uart.
> 
> 
> Make sense.
> 
> For legacy platforms, earlycon initializes the uart,
> assuming the hard-coded "port->uartclk = BASE_BAUD * 16"
> is the value.
> 
> 
> For embedded boards such as ARM, the boot-loader should initialize the UART
> and the earlycon should preserve it because port->uartclk varies from
> board to board.
> (For example, the ns16550a on my board expects   BASE_BAUD is 1228000,
> but it does not match the one in include/asm-generic/serial.h )

I want to clarify one point: if you have a configuration for which the
earlycon uart is not initialized by the bootloader (or boot prom), then
we can add a way for the ASoC init to set BASE_BAUD. This was done for
the ARC arch, but I would like to use this as a last resort for the ARM
arch.

An example configuration I can envision that would require this solution
is u-boot's so-called 'falcon mode' without devicetree (or boot prom).

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

Re: [PATCH v12 5/6] ARM: socfpga: add bindings document for fpga bridge drivers

[atull]

On Wed, 28 Oct 2015, Steffen Trumtrar wrote:

> Hi!
> 
> On Tue, Oct 27, 2015 at 05:09:14PM -0500, at...@opensource.altera.com wrote:
> > From: Alan Tull 
> > 
> > Add bindings documentation for Altera SOCFPGA bridges:
> >  * fpga2sdram
> >  * fpga2hps
> >  * hps2fpga
> >  * lwhps2fpga
> > 
> > Signed-off-by: Alan Tull 
> > Signed-off-by: Dinh Nguyen 
> > Signed-off-by: Matthew Gerlach 
> > ---
> > v2:  separate into 2 documents for the 2 drivers
> > v12: bump version to line up with simple-fpga-bus version
> >  remove Linux specific notes such as references to sysfs
> >  move non-DT specific documentation elsewhere
> >  remove bindings that would have been used to pass configuration
> >  clean up formatting
> > ---
> >  .../bindings/fpga/altera-fpga2sdram-bridge.txt |   18 ++
> >  .../bindings/fpga/altera-hps2fpga-bridge.txt   |   36 
> > 
> >  2 files changed, 54 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
> >  create mode 100644 
> > Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt 
> > b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
> > new file mode 100644
> > index 000..11eb5b7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
> > @@ -0,0 +1,18 @@
> > +Altera FPGA To SDRAM Bridge Driver
> > +
> > +Required properties:
> > +- compatible   : Should contain 
> > "altr,socfpga-fpga2sdram-bridge"
> > +
> > +Optional properties:
> > +- label: User-readable name for this bridge.
> > + Default is br
> > +- init-val : 0 if driver should disable bridge at startup
> > + 1 if driver should enable bridge at startup
> > + Default is to leave bridge in current state.
> 
> I know, that there are bindings, that configure via devicetree, but AFAIK
> this is not okay.

Yes there is configuration in the DT. I attended a presentation at ELC in 
Dublin 3 weeks ago - Frank Rowand on "Solving Device Tree Issues."  He said in 
addition to non-probable hardware information, it was a "dirty secret" that DT
includes configuration information and some policy.

Alan
--
To unsubscribe from this list: send the line "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 v12 3/6] fpga: add simple-fpga-bus

[atull]

On Wed, 28 Oct 2015, Steffen Trumtrar wrote:

> > +static int simple_fpga_bus_probe(struct platform_device *pdev)
> > +{
> > +   struct device *dev = &pdev->dev;
> > +   struct device_node *np = dev->of_node;
> > +   struct simple_fpga_bus *priv;
> > +   struct fpga_manager *mgr;
> > +   int ret;
> > +
> > +   pr_err("%s line %d\n", __func__, __LINE__);
> 
> Debugging residue, I guess, please remove.

OK

Thanks,

Alan
--
To unsubscribe from this list: send the line "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/2] thermal: mediatek: Add cpu power cooling model

[Viresh Kumar]

On 22-10-15, 20:02, Dawei Chien wrote:
> Use Intelligent Power Allocation (IPA) technical to add static/dynamic power 
> model for binding CPU thermal zone.
> The power allocator governor allocates power budget to control CPU 
> temperature.
> 
> Power Allocator governor is able to keep SOC temperature within a defined 
> temperature range to avoid SOC overheat and keep it's performance. 
> mt8173-cpufreq.c need to register its' own power model with power allocator 
> thermal governor, so that power allocator governor can allocates suitable 
> power budget to control CPU temperature.
> 
> PATCH1 is base on
> https://patchwork.kernel.org/patch/7034601/
> 
> PATCH2 is base on Sascha's thermal driver V9
> https://patchwork.kernel.org/patch/7249821/
> https://patchwork.kernel.org/patch/7249861/
> https://patchwork.kernel.org/patch/7249891/
> 
> Change since V1:
> include mt8171.h and sort header file for mt8173.dtsi
> 
> Change since V2:
> Move dynamic/static power model in device tree
> 
> Dawei.Chien (2):
>   thermal: mediatek: Add cpu power cooling model.
>   arm64: dts: mt8173: Add thermal zone node for mt8173.

Sorry for being extremely late in reviewing this stuff. You are
already on v3 and I haven't reviewed it once. Mostly due to bad timing
of my holidays and other work pressure.

Now, there are few things that I feel are not properly addressed here,
and I may be wrong:
- Where are the bindings for static-power-points and
  dynamic-power-coefficient. Sorry I failed to see them in this or
  other series you mentioned.
- Even then, why should we be adding another table into DT for
  voltage/power ? And not reuse and extend the opp-v2 stuff which is
  already mainlined now.
- There are few issues with the code as well, but I want to see where
  the bindings should go first. And then only discuss the code
  further.

-- 
viresh
--
To unsubscribe from this list: send the line "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 v12 2/6] fpga: add bindings document for simple fpga bus

[atull]

On Wed, 28 Oct 2015, Moritz Fischer wrote:

> On Wed, Oct 28, 2015 at 7:53 AM, atull  wrote:
> 
> >> > +A Simple FPGA Bus is a bus that handles configuring an FPGA and its 
> >> > bridges
> >> > +before populating the devices below its node.  All this happens when a 
> >> > device
> >> > +tree overlay is added to the live tree.  This document describes that 
> >> > device
> >> > +tree overlay.
> >> > +
> >>
> >> This is not really true, is it?
> >> The driver should work without applying the overlay, e.g. the bootloader
> >> might have already done it.
> >>
> >
> > Yes it's true.  I'm not clear what you are saying.  If the bootloader has
> > programmed the FPGA, the overlay can leave out the optional properties
> > and the FPGA won't get reprogrammed; the child devices will still get
> > added and probed.  So this handles both the case where you want to reprogram
> > the FPGA under Linux and where the FPGA was programmed by a bootloader.
> 
> I think what he means is that the document explicitly calls out the overlay,
> when in theory it also works without an overlay. While being the most 
> 'natural'
> use-case, it is not the only one ;-)
> 
> Moritz
> 

Yes, I can just take out the two sentences that refer to overlays and just 
leave:

A Simple FPGA Bus is a bus that handles configuring an FPGA and its bridges
before populating the devices below its node.

Alan

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

Re: [PATCH 07/11] pinctrl: use ngpios propety from DT

[Ray Jui]

On 10/28/2015 4:52 AM, Pramod Kumar wrote:

Hi Linus,


-Original Message-
From: Linus Walleij [mailto:linus.wall...@linaro.org]
Sent: 27 October 2015 15:22
To: Pramod Kumar
Cc: Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Ray Jui;
Scott Branden; Russell King; linux-g...@vger.kernel.org; bcm-kernel-feedback-
list; Jason Uy; Masahiro Yamada; Thomas Gleixner; Laurent Pinchart;
devicetree@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
ker...@vger.kernel.org; Jonas Gorski
Subject: Re: [PATCH 07/11] pinctrl: use ngpios propety from DT

On Mon, Oct 19, 2015 at 7:43 AM, Pramod Kumar 
wrote:


Since identical hardware is used in several instances and all pins are
not routed to pinctrl hence getting total number of gpios from DT make
more sense hence stop using total number of gpios pins from drivers
and extract it from DT.

Signed-off-by: Pramod Kumar 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 


This patch is wrong.

Keep this per-compatible code, and only overrid the ngpios if and only if:

- The ngpios is set in the DT node
- The ngpios in the DT node is *smaller* than the hardware
   defined number of GPIOs.

ngpios is for restricting the number of available lines due to routing etc, not 
to
define what the hardware has, because the hardware most certainly have all the
lines, it's just that you're not using all of them.

Yours,
Linus Walleij


I discussed with ASIC team regarding this iProc GPIO block. They use a library to create 
the GPIOs block where "total number of GPIO pins( let say N) in GPIO block" is 
used as an parameter.
Library uses a construct for *a* GPIO pin. This gets instantiated N times to 
create a complete GPIO block with N pins.


Just to confirm, N can be *any number*, and when it exceeds 32, 
additional registers will be created by the library, correct? I think 
that's what I saw with Cygnus, where 3 instances of this GPIO controller 
was used, with two of them less supporting less than 32 GPIOs and one of 
them (ASIU) supporting 146 GPIOs, in which case, 5 register banks are 
used with 0x200 segment each.




All iProc based SoCs uses this library. So I'm not sure whether attaching "total 
number of GPIOs pins" to compatible-string make sense in this case.


The closest I can think of is to tie a very large number of N to the 
"brcm,iproc-gpio" compatible string for all new iProc SoCs, but even 
that, one can argue how large is *large*



I personally feel that passing this number from the DT makes more sense here. 
Any iProc based future as well as current SoCs would be able to use this driver 
without any change.

Please advise us in this case.

Regards,
Pramod


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

Re: [PATCH v3 2/2] arm64: dts: mt8173: Add thermal zone node for mt8173.

[Viresh Kumar]

On 22-10-15, 20:02, Dawei Chien wrote:
> Add thermal zone node to mt8173.dtsi.
> 
> Signed-off-by: Dawei Chien 
> ---
> This patch is base on
> https://patchwork.kernel.org/patch/7249821/
> https://patchwork.kernel.org/patch/7249861/
> https://patchwork.kernel.org/patch/7249891/
> ---
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi |   90 
> ++
>  1 file changed, 90 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 3b18f37..eaf12bf 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "mt8173-pinfunc.h"
>  
>  / {
> @@ -54,6 +55,18 @@
>   reg = <0x000>;
>   enable-method = "psci";
>   cpu-idle-states = <&CPU_SLEEP_0>;
> + static-power-points = <
> + 859000  43
> + 908000  52
> + 983000  86
> + 1009000 123
> + 1028000 138
> + 1083000 172
> + 1110900 180
> + 1125000 192

What's the unit of power here? Is this power accurate? Or just a
number representing the power ?

> + >;
> + dynamic-power-coefficient = <263>;
> + #cooling-cells = <2>;
>   };

@Rob: Looks like another good candidate for the OPP-v2 table? Power.

-- 
viresh
--
To unsubscribe from this list: send the line "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 v12 3/6] fpga: add simple-fpga-bus

[Moritz Fischer]

On Wed, Oct 28, 2015 at 3:07 AM, Josh Cartwright  wrote:
> On Tue, Oct 27, 2015 at 05:09:12PM -0500, at...@opensource.altera.com wrote:
>> From: Alan Tull 
>>
>> The Simple FPGA bus uses the FPGA Manager Framework and the
>> FPGA Bridge Framework to provide a manufactorer-agnostic
>> interface for reprogramming FPGAs that is Device Tree
>> Overlays-based.
>
> Do you intend the "simple-fpga-bus" to be used on Zynq as well?  The
> whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq at
> all, from what I can tell.

For Zynq the zynq-fpga driver takes care of the level shifters on full
reconfiguration,
and doesn't for partial reconfiguration. Now depending on which parts
of the fabric
are partial reconfigured (say AXI masters), one might run into issues
with a setup like that.

My first plan was to counter that by using zynq-reset to hold the
reset high during
reconfiguration of that part of the FPGA.

I'm happy to rethink that part and maybe redo the level shifters and
resets together in a bridge
driver under devicetree control gives finer grained control.

Cheers,

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

Re: [PATCH v12 4/6] fpga: add fpga bridge framework

[atull]

On Wed, 28 Oct 2015, Steffen Trumtrar wrote:

> > +int fpga_bridge_enable(struct fpga_bridge *bridge)
> > +{
> > +   pr_err("%s %s\n", __func__, dev_name(&bridge->dev));
> 
> Please clean this...
> 
> > +
> > +   return bridge->br_ops->enable_set(bridge, 1);
> > +}
> > +EXPORT_SYMBOL_GPL(fpga_bridge_enable);
> > +
> > +/**
> > + * fpga_bridge_disable
> > + * @bridge: fpga bridge
> > + *
> > + * Disable transactions on the bridge
> > + *
> > + * Return: 0 for success, error code otherwise.
> > + */
> > +int fpga_bridge_disable(struct fpga_bridge *bridge)
> > +{
> > +   pr_err("%s %s\n", __func__, dev_name(&bridge->dev));
> 
> and this up.
> 

OK

> > +void fpga_bridge_unregister(struct device *dev)
> > +{
> > +   struct fpga_bridge *bridge = dev_get_drvdata(dev);
> > +
> > +   dev_info(&bridge->dev, "%s : %s\n", __func__, bridge->name);
> 
> Is this necessary information?

I can remove it.

> > +static int __init fpga_bridge_dev_init(void)
> > +{
> > +   pr_info("FPGA bridge framework driver\n");
> 
> Dito.
> IMHO unnecessary log spam. Maybe change this to dbg?

Sure.

> > --- /dev/null
> > +++ b/include/linux/fpga/fpga-bridge.h
> > @@ -0,0 +1,49 @@
> > +#include 
> 
> You don't seem to use this.

Correct.  I'll take it out.

Thanks for the review!

Alan
--
To unsubscribe from this list: send the line "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 v12 2/6] fpga: add bindings document for simple fpga bus

[Moritz Fischer]

On Wed, Oct 28, 2015 at 7:53 AM, atull  wrote:

>> > +A Simple FPGA Bus is a bus that handles configuring an FPGA and its 
>> > bridges
>> > +before populating the devices below its node.  All this happens when a 
>> > device
>> > +tree overlay is added to the live tree.  This document describes that 
>> > device
>> > +tree overlay.
>> > +
>>
>> This is not really true, is it?
>> The driver should work without applying the overlay, e.g. the bootloader
>> might have already done it.
>>
>
> Yes it's true.  I'm not clear what you are saying.  If the bootloader has
> programmed the FPGA, the overlay can leave out the optional properties
> and the FPGA won't get reprogrammed; the child devices will still get
> added and probed.  So this handles both the case where you want to reprogram
> the FPGA under Linux and where the FPGA was programmed by a bootloader.

I think what he means is that the document explicitly calls out the overlay,
when in theory it also works without an overlay. While being the most 'natural'
use-case, it is not the only one ;-)

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

Re: [PATCH v12 1/6] fpga: add usage documentation for simple fpga bus

[atull]

On Wed, 28 Oct 2015, Moritz Fischer wrote:

Hi Moritz!

> Hi Alan,
> 
> great docs! Couple of nits inline below
> 
> On Tue, Oct 27, 2015 at 3:09 PM,   wrote:
> > From: Alan Tull 
> >
> > Add a document spelling out usage of the simple fpga bus.
> >
> > Signed-off-by: Alan Tull 
> > ---
> > v9:  Initial version of this patch in patchset
> > v10: s/fpga/FPGA/g
> >  improve formatting
> >  some rewriting
> >  move to staging/simple-fpga-bus
> > v11: No change in this patch for v11 of the patch set
> > v12: Moved out of staging
> >  Small changes due to using FPGA bridge framework and not
> >  representing the bridges as resets.
> > ---
> >  Documentation/fpga/simple-fpga-bus.txt |   58 
> > 
> >  1 file changed, 58 insertions(+)
> >  create mode 100644 Documentation/fpga/simple-fpga-bus.txt
> >
> > diff --git a/Documentation/fpga/simple-fpga-bus.txt 
> > b/Documentation/fpga/simple-fpga-bus.txt
> > new file mode 100644
> > index 000..bd43478
> > --- /dev/null
> > +++ b/Documentation/fpga/simple-fpga-bus.txt
> > @@ -0,0 +1,58 @@
> > +Simple FPGA Bus
> > +
> > +Alan Tull 2015
> > +
> > +Overview
> > +
> > +
> > +The simple FPGA bus adds device tree overlay support for FPGA's.  Loading a
> 
> FPGAs

D'oh!

> > +DT overlay will result in the FPGA getting an image loaded, its bridges 
> > will
> 
> I'd prefer 'will result in the FPGA being programmed with an image'

OK

> 
> > +be released, and the DT populated for nodes below the simple-fpga-bus.  
> > This
> > +results in drivers getting probed for the hardware that just got added.  
> > This
> > +is intended to support the FPGA usage where the FPGA has hardware that
> > +requires drivers.  Removing the overlay will result in the drivers getting
> > +removed and the bridges being disabled.
> > +
> > +The simple FPGA bus will need to disable and enable bridges that will only
> > +affect the child devices that are below the bus.  If partial 
> > reconfiguration
> > +is to be done, then bridges will need to be added within the FPGA design to
> > +protect the rest of the bus when one part of the FPGA design is being
> > +reconfigured.
> > +
> > +
> > +Sequence
> > +
> > +
> > +Load the DT overlay.  One way to do that from user space is to use 
> > Pantelis'
> > +DT-Overlay configfs interface.
> > +
> > +This causes the simple FPGA bus go be probed and will do the following:
> 
> I think you mean *to* be probed

Yes

> > + 1. Disable the FPGA bridges.
> > + 2. Call the FPGA manager core to program the FPGA.
> > + 3. Release the FPGA bridges.
> > + 4. Call of_platform_populate resulting in device drivers getting probed.
> > +
> > +
> > +Requirements
> > +
> > +
> > + 1. An FPGA image that has a hardware block or blocks that use drivers 
> > that are
> > +supported in the kernel.
> > + 2. A device tree overlay (example is in the simple-fpga-bus bindings 
> > document).
> > + 3. A FPGA manager driver supporting writing the FPGA.
> > + 4. FPGA bridge drivers.
> > +
> > +The DT overlay includes bindings (documented in 
> > bindings/simple-fpga-bus.txt)
> > +that specify:
> > + * Which FPGA manager to use.
> > + * Which image file to load.
> > + * Flags indicating whether this this image is for full reconfiguration or
> > +   partial.
> > + * A list of FPGA bridges.
> > + * Child nodes specifying the devices that will be added with appropriate
> > +   compatible strings, etc.
> > +
> > +Since this code uses the firmware interface to get the image and DT 
> > overlay,
> > +they currently have to be files on the file system.  It doesn't have to be 
> > that
> > +way forever as DT bindings could be added to point to other sources for the
> > +image.
> 
> Having this will be really useful, but I agree this can be a follow up patch.
> > --
> > 1.7.9.5
> >
> 
> I'll take a closer look but feel free to add a:
> 
> Reviewed-by: Moritz Fischer 
> 
> Cheers,
> 
> Moritz
> 

Thanks for the review, I'll fix the nits.

Alan
--
To unsubscribe from this list: send the line "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 v12 2/6] fpga: add bindings document for simple fpga bus

[atull]

On Wed, 28 Oct 2015, Steffen Trumtrar wrote:

> Hi!
> 
> On Tue, Oct 27, 2015 at 05:09:11PM -0500, at...@opensource.altera.com wrote:
> > From: Alan Tull 
> > 
> > New bindings document for simple fpga bus.
> > 
> > Signed-off-by: Alan Tull 
> > ---
> > v9:  initial version added to this patchset
> > v10: s/fpga/FPGA/g
> >  replace DT overlay example with slightly more complicated example
> >  move to staging/simple-fpga-bus
> > v11: No change in this patch for v11 of the patch set
> > v12: Moved out of staging.
> >  Changed to use FPGA bridges framework instead of resets
> >  for bridges.
> > ---
> >  .../devicetree/bindings/fpga/simple-fpga-bus.txt   |   81 
> > 
> >  1 file changed, 81 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt 
> > b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
> > new file mode 100644
> > index 000..2e742f7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
> > @@ -0,0 +1,81 @@
> > +Simple FPGA Bus
> > +===
> > +
> > +A Simple FPGA Bus is a bus that handles configuring an FPGA and its bridges
> > +before populating the devices below its node.  All this happens when a 
> > device
> > +tree overlay is added to the live tree.  This document describes that 
> > device
> > +tree overlay.
> > +
> 
> This is not really true, is it?
> The driver should work without applying the overlay, e.g. the bootloader
> might have already done it.
> 

Yes it's true.  I'm not clear what you are saying.  If the bootloader has
programmed the FPGA, the overlay can leave out the optional properties
and the FPGA won't get reprogrammed; the child devices will still get
added and probed.  So this handles both the case where you want to reprogram
the FPGA under Linux and where the FPGA was programmed by a bootloader.

I'll fix the minor nits you are pointing out below.  Thanks for the feedback.

Alan

> > +Required properties:
> > +- compatible : should contain "simple-fpga-bus"
> > +- #address-cells, #size-cells, ranges: must be present to handle address 
> > space
> > +  mapping for children.
> > +
> > +Optional properties:
> > +- fpga-mgr : should contain a phandle to a FPGA manager.
> > +- fpga-firmware : should contain the name of a FPGA image file located on 
> > the
> > +  firmware search path.
> > +- partial-reconfig : boolean property should be defined if partial
> > +  reconfiguration of the FPGA is to be done, otherwise full reconfiguration
> > +  is done.
> > +- fpga-bridges : should contain a list of bridges that the bus will disable
> > +  before   programming the FPGA and then enable after the FPGA has been
>^^^???
> 
> > +
> > +Example:
> > +
> > +/dts-v1/;
> > +/plugin/;
> > +/ {
> > +   fragment@0 {
> > +   target-path="/soc";
> > +   __overlay__ {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +
> > +   bridge@0xff20 {
>^^
> 
> > +   compatible = "simple-fpga-bus";
> > +   reg = <0xc000 0x2000>,
> > + <0xff20 0x0020>;
> > +   reg-names = "axi_h2f", "axi_h2f_lw";
> > +
> > +   #address-cells = <0x2>;
> > +   #size-cells = <0x1>;
> > +
> > +   ranges = <0x 0x 0xc000 
> > 0x0001>,
> > +<0x0001 0x0002 0xff22 
> > 0x0008>,
> > +<0x0001 0x00010040 0xff210040 
> > 0x0020>;
> > +
> > +   clocks = <0x2 0x2>;
> > +   clock-names = "h2f_lw_axi_clock", 
> > "f2h_sdram0_clock";
> > +
> > +   fpga-mgr = <&hps_0_fpgamgr>;
> > +   fpga-firmware = "soc_system.rbf";
> > +
> > +   fpga-bridges = <&hps_fpgabridge0>, 
> > <&hps_fpgabridge1>, <&hps_fpgabridge2>;
> > +
> > +   onchip_memory2_0: memory@0x0 {
>  ^^
> 
> > +   device_type = "memory";
> > +   compatible = "ALTR,onchipmem-15.1";
> > +   reg = <0x 0x 
> > 0x0001>;
> > +   };
> > +
> > +   jtag_uart: serial@0x10002 {
>   ^^
> 
> > +   compatible = "altr,juart-15.1", 
> > "altr,juart-1.0";
> > +   reg = <0x0001 0x0002 
> > 0x0008>;
> > + 

Re: [PATCH] of/fdt: fix error checking for earlycon address

[Peter Hurley]

On 10/27/2015 04:46 PM, Rob Herring wrote:
> On Fri, Oct 23, 2015 at 8:15 AM, Peter Hurley  
> wrote:
>> Hi Masahiro,
>>
>> On 10/23/2015 07:47 AM, Masahiro Yamada wrote:
>>> fdt_translate_address() returns OF_BAD_ADDR on error.  It is defined as
>>> a u64 value, so the variable "addr" should be defined as u64 as well.
>>
>> Good catch.
>>
>> I would prefer if fdt_translate_address() returned resource_size_t (which
>> is the proper type for handling addresses as integers) and that type
>> was propagated through early_init_dt_scan_chosen_serial => of_setup_earlycon.
> 
> That can be problematic in the DT code. The size of resource_size_t
> can vary on 32-bit as it is based on phys_addr_t which in turn is
> based on CONFIG_LPAE setting. However, the address sizes in DT are
> fixed and may be 64-bit. So we stick with u64 in the DT code.

I think I see your point about fdt_translate_address(); you want it to
mirror of_translate_address(), yes?  If so, then I have no objection
to this patch and will mark it reviewed.

But the u64 value from fdt_translate_address() should be preserved
at least to the ioremap()/set_fixmap() in earlycon_map() .
I could roll that change into my earlycon series that moves
fdt_translate_address() into of_setup_earlycon(), thus preserving
the u64 value until it's assigned to a phys_addr_t.

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

Re: [PATCH v6 22/22] of/platform: Defer probes of registered devices

[Tomeu Vizoso]

On 22 October 2015 at 23:27, Scott Wood  wrote:
> On Thu, 2015-10-22 at 15:04 +0200, Tomeu Vizoso wrote:
>> On 22 October 2015 at 00:51, Scott Wood  wrote:
>> > On Wed, 2015-10-21 at 08:44 -0500, Rob Herring wrote:
>> > > On Wed, Oct 21, 2015 at 12:54 AM, Scott Wood 
>> > > wrote:
>> > > > On Mon, 2015-09-21 at 16:03 +0200, Tomeu Vizoso wrote:
>> > > > > Instead of trying to match and probe platform and AMBA devices right
>> > > > > after each is registered, delay their probes until
>> > > > > device_initcall_sync.
>> > > > >
>> > > > > This means that devices will start probing once all built-in drivers
>> > > > > have registered, and after all platform and AMBA devices from the DT
>> > > > > have been registered already.
>> > > > >
>> > > > > This allows us to prevent deferred probes by probing dependencies on
>> > > > > demand.
>> > > > >
>> > > > > Signed-off-by: Tomeu Vizoso 
>> > > > > ---
>> > > > >
>> > > > > Changes in v4:
>> > > > > - Also defer probes of AMBA devices registered from the DT as they
>> > > > > can
>> > > > >   also request resources.
>> > > > >
>> > > > >  drivers/of/platform.c | 11 ---
>> > > > >  1 file changed, 8 insertions(+), 3 deletions(-)
>> > > >
>> > > > This breaks arch/powerpc/sysdev/fsl_pci.c.  The PCI bus is an OF
>> > > > platform
>> > > > device, and it must be probed before pcibios_init() which is a
>> > > > subsys_initcall(), or else the PCI bus never gets scanned.
>> > >
>> > > Thanks for the report. This is probably getting dropped, but it could
>> > > be disabled for PPC.
>> >
>> > I don't think that adding another arbitrary arch difference would be the
>> > right solution.
>>
>> I think Rob meant temporarily disable it while things get fixed. At
>> least,
>
> So, what is the permanent fix for the swiotlb issue (or more generally, the
> inability to have a late_initcall that runs after non-module, non-hotplug
> platform devices have been probed)?

If the code in pcibios_init() depends on the PCI bus device having
probed, then I would recommend making that dependency explicit by
calling of_device_probe() on the OF node of the PCI controller when
looking it up.

>> I don't see any reason why PPC wouldn't benefit from this
>> series.
>
> It's not clear to me what the benefit of this is at all, much less for PPC.
> What is the fundamental problem with deferred probes?  In the cover letter
> you say this change saves 2.3 seconds, but where is that time being consumed?
>  Are the drivers taking too long in their probe function trying to initialize
> and then deferring, rather than checking for dependencies up front?  Or are
> there really so many devices and such a pessimal ordering that most of the
> time is spent iterating through and reordering the list, with each defer
> happening quickly?

The problem is that a device that defers its probe is currently sent
to the back of the queue, and that's undesired in some use cases in
which there's a device that should be up as soon as possible during
boot (and boot takes a long time). So the goal is to change the order
in which devices with dependencies end up probing.

> Even if something different does need to be done at this level, forcing all
> OF platform devices to be probed at the late_initcall level seems quite
> intrusive.  You limited it to OF because people complained that other things
> will break.  Things still broke.  Surely there's a better way to address the
> problem.  Can't the delay be requested by drivers that might otherwise need
> to defer (which could be done incrementally, focusing on the worst
> performance problems), rather than enabling it for everything?

Yes, given the amount of breakage that's a sensible option. But in any
case and even if this series is most likely to be dropped, I recommend
to make explicit as many implicit dependencies as possible.

Regards,

Tomeu

> -Scott
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 8/9] ARM: dts: Add leds support to STM32F429 Discovery board

[Maxime Coquelin]

2015-10-28 9:09 GMT+01:00 Daniel Thompson :
> On 27/10/15 21:52, Andreas Färber wrote:
>>
>> Am 27.10.2015 um 22:46 schrieb Linus Walleij:
>>>
>>> Heartbeat is awesome.
>>
>>
>> Yes, it's awesome for testing, but not for a .dts file that ends up in a
>> distro (not the case here, of course) and keeps blinking on the desk.
>>
>> If someone wants LEDs to blink, they can set that via sysfs or by
>> modifying their .dts locally.
>>
>> sunxi chose to keep LEDs off my default. For qcom we had a similar
>> discussion some weeks ago. I don't regularly read Linux patches, so feel
>> free to skim the archives yourself.
>
>
> Among the existing DTS files there is pretty significant use of heartbeat
> although its not absolute.
>
> There are 119 files that set a default-trigger, of these 91 (~75%) include a
> line to configure a heartbeat.
>
> Personally I'd be very happy with heartbeat by default on STM32... I've
> seldom worked on a board without a default-enabled heartbeat so they make me
> feel comfortable. ;-)

I will add heartbeat in next version, which will arrive when the
pinctrl driver first review is done.

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

Re: [PATCH 3/3] ARM: BCM: Add SMP support for Broadcom NSP

[Kapil Hali]

On 10/16/2015 2:47 AM, Jon Mason wrote:
> On Thu, Oct 15, 2015 at 11:12:09PM +0200, Hauke Mehrtens wrote:
>> On 10/15/2015 06:10 PM, Kapil Hali wrote:
>>>
>>>
>>> On 10/15/2015 3:56 AM, Hauke Mehrtens wrote:
 On 10/14/2015 07:47 PM, Kapil Hali wrote:
> Add SMP support for Broadcom's Northstar Plus SoC,
> cpu enable method and pen_release procedures. This
> changes also consolidates iProc family's - BCM NSP
> and BCM Kona, SMP handling in a common file.

 This will probably also work on normal Northstar CPUs without changes.

>>> I think, it should work for most of the variants of Northstar family, 
>>> except for those which have a BOOTROM bug.
>>
>> Which SoC are affected by this BOOTROM bug?
> 
> 53012 is the one I am seeing.  Not seeing it on 4708 (and assuming it is
> not present on 4709).  Internally, we do the ugly bug workaround on
> all Northstar SoCs.  The workaround is not acceptable upstream, so I
> am not pushing it. :)
> 
> Thanks,
> Jon
> 

Hi Hauke,

Now that you have tested Jon's patch which is based on my changes for
SMP, shall I take his changes and add it on top of my changes and resend?
Also, do I consider your Acked-by and Tested-by for the change?

Thanks,
Kapil

>>
> Northstar Plus SoC is based on ARM Cortex-A9
> revision r3p0 which requires configuration for ARM
> Errata 764369 for SMP. This change adds the needed
> configuration option.
>
> Signed-off-by: Kapil Hali 
> ---
>  arch/arm/mach-bcm/Kconfig   |   2 +
>  arch/arm/mach-bcm/Makefile  |   8 +-
>  arch/arm/mach-bcm/bcm_nsp.h |  19 
>  arch/arm/mach-bcm/headsmp.S |  37 
>  arch/arm/mach-bcm/{kona_smp.c => platsmp.c} | 142 
> ++--
>  5 files changed, 197 insertions(+), 11 deletions(-)
>  create mode 100644 arch/arm/mach-bcm/bcm_nsp.h
>  create mode 100644 arch/arm/mach-bcm/headsmp.S
>  rename arch/arm/mach-bcm/{kona_smp.c => platsmp.c} (63%)
>
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index 1679fa4..2e9dbb5 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -40,6 +40,8 @@ config ARCH_BCM_NSP
>   select ARCH_BCM_IPROC
>   select ARM_ERRATA_754322
>   select ARM_ERRATA_775420
> + select ARM_ERRATA_764369 if SMP
> + select HAVE_SMP
>   help
> Support for Broadcom Northstar Plus SoC.
> Broadcom Northstar Plus family of SoCs are used for switching control
> diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
> index 892261f..36a4ca30 100644
> --- a/arch/arm/mach-bcm/Makefile
> +++ b/arch/arm/mach-bcm/Makefile
> @@ -14,7 +14,11 @@
>  obj-$(CONFIG_ARCH_BCM_CYGNUS) +=  bcm_cygnus.o
>  
>  # Northstar Plus
> -obj-$(CONFIG_ARCH_BCM_NSP) += bcm_nsp.o
> +obj-$(CONFIG_ARCH_BCM_NSP)   += bcm_nsp.o
> +
> +ifeq ($(CONFIG_ARCH_BCM_NSP),y)
> +obj-$(CONFIG_SMP)+= headsmp.o platsmp.o
> +endif
>  
>  # BCM281XX
>  obj-$(CONFIG_ARCH_BCM_281XX) += board_bcm281xx.o
> @@ -23,7 +27,7 @@ obj-$(CONFIG_ARCH_BCM_281XX)+= board_bcm281xx.o
>  obj-$(CONFIG_ARCH_BCM_21664) += board_bcm21664.o
>  
>  # BCM281XX and BCM21664 SMP support
> -obj-$(CONFIG_ARCH_BCM_MOBILE_SMP) += kona_smp.o
> +obj-$(CONFIG_ARCH_BCM_MOBILE_SMP) += platsmp.o
>  
>  # BCM281XX and BCM21664 L2 cache control
>  obj-$(CONFIG_ARCH_BCM_MOBILE_L2_CACHE) += kona_l2_cache.o
> diff --git a/arch/arm/mach-bcm/bcm_nsp.h b/arch/arm/mach-bcm/bcm_nsp.h
> new file mode 100644
> index 000..58e1e80
> --- /dev/null
> +++ b/arch/arm/mach-bcm/bcm_nsp.h
> @@ -0,0 +1,19 @@
> +/*
> + * 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.
> + */
> +
> +#ifndef __BCM_NSP_H
> +#define __BCM_NSP_H
> +
> +extern void nsp_secondary_startup(void);
> +
> +#endif /* __BCM_NSP_H */
> diff --git a/arch/arm/mach-bcm/headsmp.S b/arch/arm/mach-bcm/headsmp.S
> new file mode 100644
> index 000..0da13b2
> --- /dev/null
> +++ b/arch/arm/mach-bcm/headsmp.S
> @@ -0,0 +1,37 @@
> +/*
> + * 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 Lice

Re: [PATCH v4 11/11] scsi: ufs-exynos: add UFS host support for Exynos SoCs

[Kishon Vijay Abraham I]

Hi,

On Sunday 25 October 2015 05:34 PM, Alim Akhtar wrote:
> Hi Kishon
> Thanks again for you review.
> 
> On Fri, Oct 23, 2015 at 8:48 PM, Kishon Vijay Abraham I  wrote:
>> Hi,
>>
>> On Thursday 15 October 2015 08:38 AM, Alim Akhtar wrote:
>>> +CCing kishon Vijay,
>>>
>>> On 10/14/2015 06:25 PM, Alim Akhtar wrote:
 From: Seungwon Jeon 

 This patch introduces Exynos UFS host controller driver,
 which mainly handles vendor-specific operations including
 link startup, power mode change and hibernation/unhibernation.

 Signed-off-by: Seungwon Jeon 
 Signed-off-by: Alim Akhtar 
 ---
   drivers/scsi/ufs/Kconfig |   12 +
   drivers/scsi/ufs/Makefile|1 +
   drivers/scsi/ufs/ufs-exynos-hw.c |  131 
   drivers/scsi/ufs/ufs-exynos-hw.h |   43 ++
   drivers/scsi/ufs/ufs-exynos.c| 1317
 ++
   drivers/scsi/ufs/ufs-exynos.h|  247 +++
   drivers/scsi/ufs/ufshci.h|   26 +-
   drivers/scsi/ufs/unipro.h|   47 ++
   8 files changed, 1823 insertions(+), 1 deletion(-)
   create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.c
   create mode 100644 drivers/scsi/ufs/ufs-exynos-hw.h
   create mode 100644 drivers/scsi/ufs/ufs-exynos.c
   create mode 100644 drivers/scsi/ufs/ufs-exynos.h

>> .
>> .
>> 
>> .
>> .
 diff --git a/drivers/scsi/ufs/ufs-exynos-hw.c
 b/drivers/scsi/ufs/ufs-exynos-hw.c
 new file mode 100644
 index ..be6c61541a8f
 --- /dev/null
 +++ b/drivers/scsi/ufs/ufs-exynos-hw.c
 @@ -0,0 +1,131 @@
>> .
>> .
>> 
>> .
>> .
 +
 +#define PWR_MODE_STR_LEN64
 +static int exynos_ufs_post_pwr_mode(struct ufs_hba *hba,
 +struct ufs_pa_layer_attr *pwr_max,
 +struct ufs_pa_layer_attr *pwr_req)
 +{
 +struct exynos_ufs *ufs = to_exynos_ufs(hba);
 +struct exynos_ufs_phy_info *phy_info = phy_get_drvdata(ufs->phy);
>>
>> This is abusing the interface. phy_get_drvdata is meant to be used only
>> by the PHY driver.
 +struct exynos_ufs_phy_specific_ops *phy_ops =
 +phy_info->phy_specific_ops;
>>
>> I'm really not happy about having platform specific ops for PHY. We have
>> to see if existing PHY ops can be used for this or in worst case add new
>> PHY ops.
> Well you said you like the controller driver to use only PHY ops[1], I
> am sorry If I misunderstood that point, can you please help me to
> understand that?

I meant PHY generic ops and not PHY ops.
> [1]-> https://lkml.org/lkml/2015/9/18/29
> 
 +struct uic_pwr_mode *pwr = &ufs->pwr_act;
 +char pwr_str[PWR_MODE_STR_LEN] = "";
 +int ret = 0;
 +
 +if (ufs->drv_data->post_pwr_change)
 +ufs->drv_data->post_pwr_change(ufs, pwr);
 +
 +if (IS_UFS_PWR_MODE_HS(pwr->mode)) {
 +switch (pwr->hs_series) {
 +case PA_HS_MODE_A:
 +case PA_HS_MODE_B:
 +phy_ops->calibrate_phy(ufs->phy, CFG_POST_PWR_HS,
 +PWR_MODE_HS(pwr->gear, pwr->hs_series));
 +break;
 +}
 +
 +ret = phy_ops->wait_for_lock_acq(ufs->phy);
 +snprintf(pwr_str, sizeof(pwr_str), "Fast%s series_%s G_%d L_%d",
 +pwr->mode == FASTAUTO_MODE ? "_Auto" : "",
 +pwr->hs_series == PA_HS_MODE_A ? "A" : "B",
 +pwr->gear, pwr->lane);
 +} else if (IS_UFS_PWR_MODE_PWM(pwr->mode)) {
 +snprintf(pwr_str, sizeof(pwr_str), "Slow%s G_%d L_%d",
 +pwr->mode == SLOWAUTO_MODE ? "_Auto" : "",
 +pwr->gear, pwr->lane);
 +}
 +
 +dev_info(hba->dev, "Power mode change %d : %s\n", ret, pwr_str);
 +return ret;
 +}
 +
 +static void exynos_ufs_specify_nexus_t_xfer_req(struct ufs_hba *hba,
 +int tag, struct scsi_cmnd *cmd)
 +{
 +struct exynos_ufs *ufs = to_exynos_ufs(hba);
 +u32 type;
 +
 +type =  hci_readl(ufs, HCI_UTRL_NEXUS_TYPE);
 +
 +if (cmd)
 +hci_writel(ufs, type | (1 << tag), HCI_UTRL_NEXUS_TYPE);
 +else
 +hci_writel(ufs, type & ~(1 << tag), HCI_UTRL_NEXUS_TYPE);
 +}
 +
 +static void exynos_ufs_specify_nexus_t_tm_req(struct ufs_hba *hba,
 +int tag, u8 func)
 +{
 +struct exynos_ufs *ufs = to_exynos_ufs(hba);
 +u32 type;
 +
 +type =  hci_readl(ufs, HCI_UTMRL_NEXUS_TYPE);
 +
 +switch (func) {
 +case UFS_ABORT_TASK:
 +case UFS_QUERY_TASK:
 +hci_writel(ufs, type | (1 << tag), HCI_UTMRL_NEXUS_TYPE);
 +break;
 +case UFS_ABORT_TASK_SET:
 +case UFS_CLEAR_TASK_SET:
 +case UFS_LOGICAL_RESET:
 +case UFS_QUERY_TASK_SET:
 +hci_writel(ufs, type & ~(1 << tag), HCI_UTMRL

Re: [PATCH v12 6/6] ARM: socfpga: fpga bridge driver support

[atull]

On Wed, 28 Oct 2015, Steffen Trumtrar wrote:

> On Tue, Oct 27, 2015 at 05:09:15PM -0500, at...@opensource.altera.com wrote:
> > From: Alan Tull 
> > 
> > Supports Altera SOCFPGA bridges:
> >  * fpga2sdram
> >  * fpga2hps
> >  * hps2fpga
> >  * lwhps2fpga
> > 
> > Allows enabling/disabling the bridges through the FPGA
> > Bridge Framework API functions.
> > 
> > The fpga2sdram driver only supports enabling and disabling
> > of the ports that been configured early on.  This is due to
> > a hardware limitation where the read, write, and command
> > ports on the fpga2sdram bridge can only be reconfigured
> > while there are no transactions to the sdram, i.e. when
> > running out of OCRAM before the kernel boots.
> > 
> > Device tree property 'init-val' configures the driver to
> > enable or disable the bridge during probe.  If the property
> > does not exist, the driver will leave the bridge in its
> > current state.
> > 
> > Signed-off-by: Alan Tull 
> > Signed-off-by: Dinh Nguyen 
> > Signed-off-by: Matthew Gerlach 
> > ---
> > v2:  Use resets instead of directly writing reset registers
> > v12: Bump version to align with simple-fpga-bus version
> >  Get rid of the sysfs interface
> >  fpga2sdram: get configuration stored in handoff register
> > ---
> >  drivers/fpga/Kconfig |7 ++
> >  drivers/fpga/Makefile|1 +
> >  drivers/fpga/altera-fpga2sdram.c |  185 ++
> >  drivers/fpga/altera-hps2fpga.c   |  234 
> > ++
> >  4 files changed, 427 insertions(+)
> >  create mode 100644 drivers/fpga/altera-fpga2sdram.c
> >  create mode 100644 drivers/fpga/altera-hps2fpga.c
> > 
> > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > index 143072b..004b83a 100644
> > --- a/drivers/fpga/Kconfig
> > +++ b/drivers/fpga/Kconfig
> > @@ -39,6 +39,13 @@ config FPGA_BRIDGE
> >   Say Y here if you want to support bridges connected between host
> >  processors and FPGAs or between FPGAs.
> >  
> > +config SOCFPGA_FPGA_BRIDGE
> > +   bool "Altera SoCFPGA FPGA Bridges"
> > +   depends on ARCH_SOCFPGA && FPGA_BRIDGE
> > +   help
> > + Say Y to enable drivers for FPGA bridges for Altera SOCFPGA
> > + devices.
> > +
> >  endif # FPGA
> >  
> >  endmenu
> > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> > index 9302662..cc01db3 100644
> > --- a/drivers/fpga/Makefile
> > +++ b/drivers/fpga/Makefile
> > @@ -11,6 +11,7 @@ obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10)+= socfpga-a10.o
> >  
> >  # FPGA Bridge Drivers
> >  obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
> > +obj-$(CONFIG_SOCFPGA_FPGA_BRIDGE)  += altera-hps2fpga.o altera-fpga2sdram.o
> >  
> >  # High Level Interfaces
> >  obj-$(CONFIG_SIMPLE_FPGA_BUS)  += simple-fpga-bus.o
> > diff --git a/drivers/fpga/altera-fpga2sdram.c 
> > b/drivers/fpga/altera-fpga2sdram.c
> > new file mode 100644
> > index 000..ee56903
> > --- /dev/null
> > +++ b/drivers/fpga/altera-fpga2sdram.c
> > @@ -0,0 +1,185 @@
> > +/*
> > + * FPGA to SDRAM Bridge Driver for Altera SoCFPGA Devices
> > + *
> > + *  Copyright (C) 2013-2015 Altera Corporation, All Rights Reserved.
> > + *
> > + * 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.
> > + *
> > + * You should have received a copy of the GNU General Public License along 
> > with
> > + * this program.  If not, see .
> > + */
> > +
> > +/*
> > + * This driver manages a bridge between an FPGA and the SDRAM used by the 
> > ARM
> > + * host processor system (HPS).
> > + *
> > + * The bridge contains 4 read ports, 4 write ports, and 6 command ports.
> > + * Reconfiguring these ports requires that no SDRAM transactions occur 
> > during
> > + * reconfiguration.  The code reconfiguring the ports cannot run out of 
> > SDRAM
> > + * nor can the FPGA access the SDRAM during reconfiguration.  This driver 
> > does
> > + * not support reconfiguring the ports.  The ports are configured by code
> > + * running out of on chip ram before Linux is started and the configuration
> > + * is passed in a handoff register in the system manager.
> > + *
> > + * This driver supports enabling and disabling of the configured ports, 
> > which
> > + * allows for safe reprogramming of the FPGA, assuming that the new FPGA 
> > image
> > + * uses the same port configuration.  Bridges must be disabled before
> > + * reprogramming the FPGA and re-enabled after the FPGA has been 
> > programmed.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
>

Re: [PATCH v12 3/6] fpga: add simple-fpga-bus

[atull]

On Wed, 28 Oct 2015, Josh Cartwright wrote:

> On Tue, Oct 27, 2015 at 05:09:12PM -0500, at...@opensource.altera.com wrote:
> > From: Alan Tull 
> > 
> > The Simple FPGA bus uses the FPGA Manager Framework and the
> > FPGA Bridge Framework to provide a manufactorer-agnostic
> > interface for reprogramming FPGAs that is Device Tree
> > Overlays-based.
> 
> Do you intend the "simple-fpga-bus" to be used on Zynq as well?

Yes

>  The
> whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq at
> all, from what I can tell.

I want to make this useful for all of us.  I'll make some minor changes so
the simple fpga bus will not exit when it encounters an overlay that doesn't
specify any bridges.

Zynq doesn't have bridges to disable during reconfiguration?  I guess
that's handled automatically in hardware somehow?

> 
> Therefore, I would have expected the FPGA Bridge drivers to sit under
> the fpga-socfpga driver, and not be a first class feature of the
> kernels' FPGA manager subsystem.

I need some way for simple FPGA bus to be able to configure bridges during
the reconfiguration cycle.  That will have to hook into the simple fpga bus,
even if not everybody uses it.  I'll submit minor changes that make it
convenient to either have bridges if you need them or leave them out if
you don't.

Alan

> 
>   Josh
> 


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

[Bjorn Helgaas]

On Wed, Oct 28, 2015 at 10:17:22AM +, Bharat Kumar Gogada wrote:
> > On Mon, Oct 26, 2015 at 08:26:26PM +0530, Bharat Kumar Gogada wrote:
> > > Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> 
> > > +
> > > + while ((status = nwl_bridge_readl(pcie, MSGF_MSI_STATUS_LO)) !=
> > 0) {
> > > + for_each_set_bit(bit, &status, 32) {
> > > + nwl_bridge_writel(pcie, 1 << bit,
> > MSGF_MSI_STATUS_LO);
> > > + virq = irq_find_mapping(msi->dev_domain, bit);
> > > + if (virq)
> > > + generic_handle_irq(virq);
> > > + }
> > > + }
> > > +
> > > + chained_irq_exit(chip, desc);
> > > +}
> > 
> > These are basically identical.  Can you factor them out somehow to avoid
> > repeating the code?
> 
> Is it okay if irq_set_chained_handler_and_data being invoked with two 
> different interrupt numbers, but pointing to 
> same interrupt handler?

Yes, that should be fine.

> > > +
> > > + pcie->legacy_irq_domain =
> > irq_domain_add_linear(legacy_intc_node, 4,
> > > +
> > &legacy_domain_ops,
> > > + pcie);
> > > +
> > > + if (!pcie->legacy_irq_domain) {
> > > + dev_err(pcie->dev, "failed to create IRQ domain\n");
> > > + return -ENOMEM;
> > > + }
> > > +
> > > +#ifdef CONFIG_PCI_MSI
> > > + msi->dev_domain = irq_domain_add_linear(NULL,
> > INT_PCI_MSI_NR,
> > > + &dev_msi_domain_ops, pcie);
> > > + if (!msi->dev_domain) {
> > > + dev_err(pcie->dev, "failed to create dev IRQ domain\n");
> > > + return -ENOMEM;
> > > + }
> > > + msi->msi_chip.domain = pci_msi_create_irq_domain(node,
> > > +
> > &nwl_msi_domain_info,
> > > + msi->dev_domain);
> > > + if (!msi->msi_chip.domain) {
> > > + dev_err(pcie->dev, "failed to create msi IRQ domain\n");
> > > + irq_domain_remove(msi->dev_domain);
> > > + return -ENOMEM;
> > > + }
> > > +#endif
> > > + return 0;
> > > +}
> > > +
> > > +static int nwl_pcie_enable_msi(struct nwl_pcie *pcie, struct pci_bus
> > > +*bus) {
> > 
> > It looks strange to have all the "#ifdef CONFIG_PCI_MSI" above, and here
> > we have this long MSI-related function without any ifdefs around it.  Seems
> > like this should be ifdef'ed also?  What about nwl_pcie_msi_handler_high(),
> > nwl_pcie_msi_handler_low(), nwl_compose_msi_msg(),
> > nwl_msi_set_affinity(), etc.?
> > 
> In probe I'm invoking "nwl_pcie_enable_msi" using "if 
> (IS_ENABLED(CONFIG_PCI_MSI)) " check, since this is at run time 
> I haven't kept above mentioned functions under #ifdef CONFIG_PCI_MSI.
> The above MSI domain allocation was under ifdef, since if driver was compiled 
> for legacy some of the MSI hierarchy API's and structures aren't available.

OK.  It *looks* strange, but maybe it's the best we can do.  I'm not
enamored of IS_ENABLED() thing yet; I guess I just haven't
internalized the combination compile-time and run-time behavior.

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

RE: [RFC PATCH 1/2] usb: doc: Add bindings for ULPI platform driver

[Subbaraya Sundeep Bhatta]

Hi Kishon,

> -Original Message-
> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
> Sent: Sunday, October 11, 2015 8:11 PM
> To: Punnaiah Choudary Kalluri; ba...@ti.com
> Cc: Rob Herring; Subbaraya Sundeep Bhatta; Peter Chen;
> devicetree@vger.kernel.org; gre...@linuxfoundation.org; linux-
> u...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [RFC PATCH 1/2] usb: doc: Add bindings for ULPI platform driver
> 
> Hi,
> 
> On Sunday 11 October 2015 04:45 PM, punnaiah choudary kalluri wrote:
> > On Wed, Sep 30, 2015 at 9:48 PM, Felipe Balbi  wrote:
> >> On Thu, Sep 24, 2015 at 11:18:01AM -0500, Rob Herring wrote:
> >>> On Thu, Sep 24, 2015 at 4:26 AM, Subbaraya Sundeep Bhatta
> >>>  wrote:
>  Hi Peter,
> 
> > -Original Message-
> > From: Peter Chen [mailto:peter.c...@freescale.com]
> > Sent: Thursday, September 24, 2015 2:41 PM
> > To: Subbaraya Sundeep Bhatta
> > Cc: ba...@ti.com; devicetree@vger.kernel.org; kis...@ti.com;
> > gre...@linuxfoundation.org; linux-...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; Punnaiah Choudary Kalluri; Subbaraya
> > Sundeep Bhatta; linux-arm-ker...@lists.infradead.org
> > Subject: Re: [RFC PATCH 1/2] usb: doc: Add bindings for ULPI
> > platform driver
> >
> > On Wed, Sep 23, 2015 at 06:24:01PM +0530, Subbaraya Sundeep
> Bhatta
> > wrote:
> >> This patch adds binding doc info for generic ULPI PHYs platform
> >> driver.
> >>
> >> Signed-off-by: Subbaraya Sundeep Bhatta 
> >> ---
> >>  .../devicetree/bindings/usb/ulpi-platform-phy.txt  |   34
> > 
> >>  1 files changed, 34 insertions(+), 0 deletions(-)  create mode
> >> 100644
> >> Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
> >> b/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
> >> new file mode 100644
> >> index 000..7b8cbb4
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/usb/ulpi-platform-phy.txt
> >> @@ -0,0 +1,34 @@
> >> +Platform driver for generic ULPI PHYs
> >> +
> >> +Required properties:
> >> +- compatible   : Should be "ulpi-phy"
> >> +- reg  : Physical base address and size of the USB
> >> + controller registers map to which this PHY
> >> + is connected.
> >> +- view-port: Should contain viewport register offset 
> >> of the
> >> + USB controller to which this PHY is
> >> +connected Optional
> >> +properties:
> >> +- drv-vbus : required if turning VBUS on/off has to be driven
> >> + by writing to PHY. This feature depends on board
> >> + design.
> >> +
> >> +Example:
> >> +Below example shows the PHY binding for Chipidea USB controller
> >> +which has ulpi viewport register at 0x0170
> >> +
> >> +   usb_phy0: phy0 {
> >> +   compatible = "ulpi-phy";
> >> +   reg = <0xe0002000 0x1000>;
> >> +   view-port = <0x0170>;
> >> +   drv-vbus;
> >> +   };
> >> +
> >> +   usb0: usb@e0002000 {
> >> +compatible = "chipidea,usb2";
> >> +interrupt-parent = <&intc>;
> >> +interrupts = <0 21 4>;
> >> +reg = <0xe0002000 0x1000>;
> >
> > Although just call devm_ioremap twice for the same register region
> > does not cause any errors, I am not sure if it will has other
> > potential problems. Cc: arm list.
> 
>  Yes Peter I was also in doubt to call devm_ioremap twice for same 
>  register
> region.
>  devm_ioremap_resource complained hence modified to devm_ioremap.
>  Thanks for adding arm-list.
> >>>
> >>> Don't put overlapping resources in the DT. Having 2 drivers
> >>> accessing the same registers is not a clean or safe design.
> >>
> >> thanks, saves me the trouble of saying the same thing.
> >>
> >> Bottom line, if devm_ioremap_resource() fails, you're wrong. Just fix
> >> your driver and move on.
> >
> > Any suggestions on how to move further?
> > Chipidea controller provides ulpi view port register for accessing the
> > usb phy registers. Now we want to add new driver for ulpi phy
> > configuration and that obviously it need of ulpi view port register
> > access. So, sharing the register space between these two drivers is 
> > necessary
> here.
> 
> Why not program ULPI the same way as DWC3 does?

Sorry for delay in response, back from long vacation.
Can we call generic PHY phy->power_on and power_off functions to do similar 
function as usb2_phy->set_vbus?
I assume i

RE: [PATCH 07/11] pinctrl: use ngpios propety from DT

[Pramod Kumar]

Hi Linus,

> -Original Message-
> From: Linus Walleij [mailto:linus.wall...@linaro.org]
> Sent: 27 October 2015 15:22
> To: Pramod Kumar
> Cc: Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Ray Jui;
> Scott Branden; Russell King; linux-g...@vger.kernel.org; bcm-kernel-feedback-
> list; Jason Uy; Masahiro Yamada; Thomas Gleixner; Laurent Pinchart;
> devicetree@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; Jonas Gorski
> Subject: Re: [PATCH 07/11] pinctrl: use ngpios propety from DT
> 
> On Mon, Oct 19, 2015 at 7:43 AM, Pramod Kumar 
> wrote:
> 
> > Since identical hardware is used in several instances and all pins are
> > not routed to pinctrl hence getting total number of gpios from DT make
> > more sense hence stop using total number of gpios pins from drivers
> > and extract it from DT.
> >
> > Signed-off-by: Pramod Kumar 
> > Reviewed-by: Ray Jui 
> > Reviewed-by: Scott Branden 
> 
> This patch is wrong.
> 
> Keep this per-compatible code, and only overrid the ngpios if and only if:
> 
> - The ngpios is set in the DT node
> - The ngpios in the DT node is *smaller* than the hardware
>   defined number of GPIOs.
> 
> ngpios is for restricting the number of available lines due to routing etc, 
> not to
> define what the hardware has, because the hardware most certainly have all the
> lines, it's just that you're not using all of them.
> 
> Yours,
> Linus Walleij

I discussed with ASIC team regarding this iProc GPIO block. They use a library 
to create the GPIOs block where "total number of GPIO pins( let say N) in GPIO 
block" is used as an parameter. 
Library uses a construct for *a* GPIO pin. This gets instantiated N times to 
create a complete GPIO block with N pins.

All iProc based SoCs uses this library. So I'm not sure whether attaching 
"total number of GPIOs pins" to compatible-string make sense in this case. 
I personally feel that passing this number from the DT makes more sense here. 
Any iProc based future as well as current SoCs would be able to use this driver 
without any change.

Please advise us in this case.

Regards,
Pramod
N�r��yb�X��ǧv�^�)޺{.n�+���z��z��z)w*jg����ݢj/���z�ޖ��2�ޙ&�)ߡ�a�����G���h��j:+v���w��٥

Re: [PATCH v4 4/6] reset: sunxi: Add Allwinner H3 bus resets

[Philipp Zabel]

Hi Jens,

Am Dienstag, den 27.10.2015, 17:50 +0100 schrieb Jens Kuske:
[...]
> --- a/drivers/reset/reset-sunxi.c
> +++ b/drivers/reset/reset-sunxi.c
> @@ -75,7 +75,9 @@ static struct reset_control_ops sunxi_reset_ops = {
>   .deassert   = sunxi_reset_deassert,
>  };
>  
> -static int sunxi_reset_init(struct device_node *np)
> +static int sunxi_reset_init(struct device_node *np,
> + int (*of_xlate)(struct reset_controller_dev *rcdev,
> + const struct of_phandle_args *reset_spec))

I'd add a tab to the indentation and drop the of_xlate parameter names.
If you agree to this change, I'll fix it up when I apply it.

best 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

Re: [PATCH v2 2/3] gpio: arizona: Support Cirrus Logic CS47L24 and WM1831

[Lee Jones]

On Tue, 27 Oct 2015, Linus Walleij wrote:

> On Mon, Oct 19, 2015 at 4:13 PM, Richard Fitzgerald
>  wrote:
> 
> > The CS47L24 and WM1831 codecs only have two GPIO lines, but are
> > otherwise similar to the WM8280.
> >
> > Signed-off-by: Richard Fitzgerald 
> 
> Acked-by: Linus Walleij 
> 
> Lee can merge this into the MFD tree with patch 1/3 if he likes,
> I guess that's simplest.

I can do.  Do you require a pull-request?

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

[PATCH v9 6/8] scsi: ufs: make the UFS variant a platform device

[Yaniv Gardi]

This change turns the UFS variant (SCSI_UFS_QCOM) into a UFS
a platform device.
In order to do so a few additional changes are required:
1. The ufshcd-pltfrm is no longer serves as a platform device.
   Now it only serves as a group of platform APIs such as PM APIs
   (runtime suspend/resume, system suspend/resume etc), parsers of
   clocks, regulators and pm_levels from DT.
2. What used to be the old platform "probe" is now "only"
   a pltfrm_init() routine, that does exactly the same, but only
   being called by the new probe function of the UFS variant.

Reviewed-by: Rob Herring 
Reviewed-by: Gilad Broner 
Signed-off-by: Yaniv Gardi 

---
 Documentation/devicetree/bindings/ufs/ufs-qcom.txt | 58 +
 .../devicetree/bindings/ufs/ufshcd-pltfrm.txt  | 11 ++-
 drivers/scsi/ufs/ufs-qcom.c| 62 +-
 drivers/scsi/ufs/ufshcd-pltfrm.c   | 98 ++
 drivers/scsi/ufs/ufshcd-pltfrm.h   | 41 +
 drivers/scsi/ufs/ufshcd.c  | 10 +++
 drivers/scsi/ufs/ufshcd.h  |  1 +
 7 files changed, 207 insertions(+), 74 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/ufs/ufs-qcom.txt
 create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.h

diff --git a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt 
b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt
new file mode 100644
index 000..070baf4
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt
@@ -0,0 +1,58 @@
+* Qualcomm Technologies Inc Universal Flash Storage (UFS) PHY
+
+UFSPHY nodes are defined to describe on-chip UFS PHY hardware macro.
+Each UFS PHY node should have its own node.
+
+To bind UFS PHY with UFS host controller, the controller node should
+contain a phandle reference to UFS PHY node.
+
+Required properties:
+- compatible: compatible list, contains "qcom,ufs-phy-qmp-20nm"
+ or "qcom,ufs-phy-qmp-14nm" according to the relevant phy 
in use.
+- reg   : should contain PHY register address space (mandatory),
+- reg-names : indicates various resources passed to driver (via reg 
proptery) by name.
+  Required "reg-names" is "phy_mem".
+- #phy-cells: This property shall be set to 0
+- vdda-phy-supply   : phandle to main PHY supply for analog domain
+- vdda-pll-supply   : phandle to PHY PLL and Power-Gen block power supply
+- clocks   : List of phandle and clock specifier pairs
+- clock-names   : List of clock input name strings sorted in the same
+ order as the clocks property. "ref_clk_src", "ref_clk",
+ "tx_iface_clk" & "rx_iface_clk" are mandatory but
+ "ref_clk_parent" is optional
+
+Optional properties:
+- vdda-phy-max-microamp : specifies max. load that can be drawn from phy supply
+- vdda-pll-max-microamp : specifies max. load that can be drawn from pll supply
+- vddp-ref-clk-supply   : phandle to UFS device ref_clk pad power supply
+- vddp-ref-clk-max-microamp : specifies max. load that can be drawn from this 
supply
+- vddp-ref-clk-always-on : specifies if this supply needs to be kept always on
+
+Example:
+
+   ufsphy1: ufsphy@0xfc597000 {
+   compatible = "qcom,ufs-phy-qmp-20nm";
+   reg = <0xfc597000 0x800>;
+   reg-names = "phy_mem";
+   #phy-cells = <0>;
+   vdda-phy-supply = <&pma8084_l4>;
+   vdda-pll-supply = <&pma8084_l12>;
+   vdda-phy-max-microamp = <5>;
+   vdda-pll-max-microamp = <1000>;
+   clock-names = "ref_clk_src",
+   "ref_clk_parent",
+   "ref_clk",
+   "tx_iface_clk",
+   "rx_iface_clk";
+   clocks = <&clock_rpm clk_ln_bb_clk>,
+   <&clock_gcc clk_pcie_1_phy_ldo >,
+   <&clock_gcc clk_ufs_phy_ldo>,
+   <&clock_gcc clk_gcc_ufs_tx_cfg_clk>,
+   <&clock_gcc clk_gcc_ufs_rx_cfg_clk>;
+   };
+
+   ufshc@0xfc598000 {
+   ...
+   phys = <&ufsphy1>;
+   phy-names = "ufsphy";
+   };
diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt 
b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
index 5357919..03c0e98 100644
--- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
+++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
@@ -4,11 +4,18 @@ UFSHC nodes are defined to describe on-chip UFS host 
controllers.
 Each UFS controller instance should have its own node.
 
 Required properties:
-- compatible: compatible list, contains "jedec,ufs-1.1"
+- compatible   : must contain "jedec,ufs-1.1", may also list one or 
more
+ of the following:
+ "qcom,msm8994-ufshc"
+ 

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

[Bharat Kumar Gogada]

> On Mon, Oct 26, 2015 at 08:26:26PM +0530, Bharat Kumar Gogada wrote:
> > Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.

> > +
> > +   while ((status = nwl_bridge_readl(pcie, MSGF_MSI_STATUS_LO)) !=
> 0) {
> > +   for_each_set_bit(bit, &status, 32) {
> > +   nwl_bridge_writel(pcie, 1 << bit,
> MSGF_MSI_STATUS_LO);
> > +   virq = irq_find_mapping(msi->dev_domain, bit);
> > +   if (virq)
> > +   generic_handle_irq(virq);
> > +   }
> > +   }
> > +
> > +   chained_irq_exit(chip, desc);
> > +}
> 
> These are basically identical.  Can you factor them out somehow to avoid
> repeating the code?

Is it okay if irq_set_chained_handler_and_data being invoked with two different 
interrupt numbers, but pointing to 
same interrupt handler?

> > +
> > +   pcie->legacy_irq_domain =
> irq_domain_add_linear(legacy_intc_node, 4,
> > +
>   &legacy_domain_ops,
> > +   pcie);
> > +
> > +   if (!pcie->legacy_irq_domain) {
> > +   dev_err(pcie->dev, "failed to create IRQ domain\n");
> > +   return -ENOMEM;
> > +   }
> > +
> > +#ifdef CONFIG_PCI_MSI
> > +   msi->dev_domain = irq_domain_add_linear(NULL,
> INT_PCI_MSI_NR,
> > +   &dev_msi_domain_ops, pcie);
> > +   if (!msi->dev_domain) {
> > +   dev_err(pcie->dev, "failed to create dev IRQ domain\n");
> > +   return -ENOMEM;
> > +   }
> > +   msi->msi_chip.domain = pci_msi_create_irq_domain(node,
> > +
>   &nwl_msi_domain_info,
> > +   msi->dev_domain);
> > +   if (!msi->msi_chip.domain) {
> > +   dev_err(pcie->dev, "failed to create msi IRQ domain\n");
> > +   irq_domain_remove(msi->dev_domain);
> > +   return -ENOMEM;
> > +   }
> > +#endif
> > +   return 0;
> > +}
> > +
> > +static int nwl_pcie_enable_msi(struct nwl_pcie *pcie, struct pci_bus
> > +*bus) {
> 
> It looks strange to have all the "#ifdef CONFIG_PCI_MSI" above, and here
> we have this long MSI-related function without any ifdefs around it.  Seems
> like this should be ifdef'ed also?  What about nwl_pcie_msi_handler_high(),
> nwl_pcie_msi_handler_low(), nwl_compose_msi_msg(),
> nwl_msi_set_affinity(), etc.?
> 
In probe I'm invoking "nwl_pcie_enable_msi" using "if 
(IS_ENABLED(CONFIG_PCI_MSI)) " check, since this is at run time 
I haven't kept above mentioned functions under #ifdef CONFIG_PCI_MSI.
The above MSI domain allocation was under ifdef, since if driver was compiled 
for legacy some of the MSI hierarchy API's and structures aren't available.

> > +   struct platform_device *pdev = to_platform_device(pcie->dev);
> > +   struct nwl_msi *msi = &pcie->msi;

Regards,
Bharat
--
To unsubscribe from this list: send the line "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 v12 6/6] ARM: socfpga: fpga bridge driver support

[Steffen Trumtrar]

On Tue, Oct 27, 2015 at 05:09:15PM -0500, at...@opensource.altera.com wrote:
> From: Alan Tull 
> 
> Supports Altera SOCFPGA bridges:
>  * fpga2sdram
>  * fpga2hps
>  * hps2fpga
>  * lwhps2fpga
> 
> Allows enabling/disabling the bridges through the FPGA
> Bridge Framework API functions.
> 
> The fpga2sdram driver only supports enabling and disabling
> of the ports that been configured early on.  This is due to
> a hardware limitation where the read, write, and command
> ports on the fpga2sdram bridge can only be reconfigured
> while there are no transactions to the sdram, i.e. when
> running out of OCRAM before the kernel boots.
> 
> Device tree property 'init-val' configures the driver to
> enable or disable the bridge during probe.  If the property
> does not exist, the driver will leave the bridge in its
> current state.
> 
> Signed-off-by: Alan Tull 
> Signed-off-by: Dinh Nguyen 
> Signed-off-by: Matthew Gerlach 
> ---
> v2:  Use resets instead of directly writing reset registers
> v12: Bump version to align with simple-fpga-bus version
>  Get rid of the sysfs interface
>  fpga2sdram: get configuration stored in handoff register
> ---
>  drivers/fpga/Kconfig |7 ++
>  drivers/fpga/Makefile|1 +
>  drivers/fpga/altera-fpga2sdram.c |  185 ++
>  drivers/fpga/altera-hps2fpga.c   |  234 
> ++
>  4 files changed, 427 insertions(+)
>  create mode 100644 drivers/fpga/altera-fpga2sdram.c
>  create mode 100644 drivers/fpga/altera-hps2fpga.c
> 
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index 143072b..004b83a 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -39,6 +39,13 @@ config FPGA_BRIDGE
>   Say Y here if you want to support bridges connected between host
>processors and FPGAs or between FPGAs.
>  
> +config SOCFPGA_FPGA_BRIDGE
> + bool "Altera SoCFPGA FPGA Bridges"
> + depends on ARCH_SOCFPGA && FPGA_BRIDGE
> + help
> +   Say Y to enable drivers for FPGA bridges for Altera SOCFPGA
> +   devices.
> +
>  endif # FPGA
>  
>  endmenu
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 9302662..cc01db3 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -11,6 +11,7 @@ obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10)  += socfpga-a10.o
>  
>  # FPGA Bridge Drivers
>  obj-$(CONFIG_FPGA_BRIDGE)+= fpga-bridge.o
> +obj-$(CONFIG_SOCFPGA_FPGA_BRIDGE)+= altera-hps2fpga.o altera-fpga2sdram.o
>  
>  # High Level Interfaces
>  obj-$(CONFIG_SIMPLE_FPGA_BUS)+= simple-fpga-bus.o
> diff --git a/drivers/fpga/altera-fpga2sdram.c 
> b/drivers/fpga/altera-fpga2sdram.c
> new file mode 100644
> index 000..ee56903
> --- /dev/null
> +++ b/drivers/fpga/altera-fpga2sdram.c
> @@ -0,0 +1,185 @@
> +/*
> + * FPGA to SDRAM Bridge Driver for Altera SoCFPGA Devices
> + *
> + *  Copyright (C) 2013-2015 Altera Corporation, All Rights Reserved.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +/*
> + * This driver manages a bridge between an FPGA and the SDRAM used by the ARM
> + * host processor system (HPS).
> + *
> + * The bridge contains 4 read ports, 4 write ports, and 6 command ports.
> + * Reconfiguring these ports requires that no SDRAM transactions occur during
> + * reconfiguration.  The code reconfiguring the ports cannot run out of SDRAM
> + * nor can the FPGA access the SDRAM during reconfiguration.  This driver 
> does
> + * not support reconfiguring the ports.  The ports are configured by code
> + * running out of on chip ram before Linux is started and the configuration
> + * is passed in a handoff register in the system manager.
> + *
> + * This driver supports enabling and disabling of the configured ports, which
> + * allows for safe reprogramming of the FPGA, assuming that the new FPGA 
> image
> + * uses the same port configuration.  Bridges must be disabled before
> + * reprogramming the FPGA and re-enabled after the FPGA has been programmed.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ALT_SDR_CTL_FPGAPORTRST_OFST 0x80
> +#define ALT_SDR_CTL_FPGAPORTRST_PORTRSTN_MSK 0x3fff
> +#define ALT_SDR_CTL_FPGAPORTRST_RD_SHIFT 0
> +#define ALT_SDR_CTL_FPGAPORTRST_WR_SHIFT 4
> +#define ALT_SDR_CTL_FPGAPORTRST_CTRL_SHIFT   8
> +
> +#define SY

Re: [PATCH v12 3/6] fpga: add simple-fpga-bus

[Josh Cartwright]

On Tue, Oct 27, 2015 at 05:09:12PM -0500, at...@opensource.altera.com wrote:
> From: Alan Tull 
> 
> The Simple FPGA bus uses the FPGA Manager Framework and the
> FPGA Bridge Framework to provide a manufactorer-agnostic
> interface for reprogramming FPGAs that is Device Tree
> Overlays-based.

Do you intend the "simple-fpga-bus" to be used on Zynq as well?  The
whole concept of the socfpga's "FPGA Bridge" doesn't map to the Zynq at
all, from what I can tell.

Therefore, I would have expected the FPGA Bridge drivers to sit under
the fpga-socfpga driver, and not be a first class feature of the
kernels' FPGA manager subsystem.

  Josh
--
To unsubscribe from this list: send the line "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 v12 4/6] fpga: add fpga bridge framework

[Steffen Trumtrar]

On Tue, Oct 27, 2015 at 05:09:13PM -0500, at...@opensource.altera.com wrote:
> From: Alan Tull 
> 
> This framework adds API functions for enabling/
> disabling FPGA bridges under kernel control.
> 
> This allows the Linux kernel to disable FPGA bridges
> during FPGA reprogramming and to enable FPGA bridges
> when FPGA reprogramming is done.  This framework is
> be manufacturer-agnostic, allowing it to be used in
> interfaces that use the FPGA Manager Framework to
> reprogram FPGAs.
> 
> The functions are:
> * of_fpga_bridge_get
> * fpga_bridge_put
>Get/put a reference to a FPGA bridge.
> 
> * fpga_bridge_enable
> * fpga_bridge_disable
>Enable/Disable traffic through a bridge.
> 
> * fpga_bridge_register
> * fpga_bridge_unregister
>Register/unregister a device-specific low level FPGA
>Bridge driver.
> 
> Signed-off-by: Alan Tull 
> ---
> v2:  Minor cleanup
> v12: Bump version to line up with simple fpga bus
>  Remove sysfs
>  Improve get/put functions, get the low level driver too.
>  Clean up class implementation
>  Add kernel doc documentation
>  Rename (un)register_fpga_bridge -> fpga_bridge_(un)register
> ---
>  drivers/fpga/Kconfig |7 ++
>  drivers/fpga/Makefile|3 +
>  drivers/fpga/fpga-bridge.c   |  242 
> ++
>  include/linux/fpga/fpga-bridge.h |   49 
>  4 files changed, 301 insertions(+)
>  create mode 100644 drivers/fpga/fpga-bridge.c
>  create mode 100644 include/linux/fpga/fpga-bridge.h
> 
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index e8f5453..143072b 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -32,6 +32,13 @@ config FPGA_MGR_SOCFPGA_A10
>   help
> FPGA manager driver support for Altera Arria10 SoCFPGA.
>  
> +config FPGA_BRIDGE
> +   bool "FPGA Bridge Drivers"
> +   depends on OF
> +   help
> + Say Y here if you want to support bridges connected between host
> +  processors and FPGAs or between FPGAs.
> +
>  endif # FPGA
>  
>  endmenu
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 0385622..9302662 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -9,5 +9,8 @@ obj-$(CONFIG_FPGA)+= fpga-mgr.o
>  obj-$(CONFIG_FPGA_MGR_SOCFPGA)   += socfpga.o
>  obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10)   += socfpga-a10.o
>  
> +# FPGA Bridge Drivers
> +obj-$(CONFIG_FPGA_BRIDGE)+= fpga-bridge.o
> +
>  # High Level Interfaces
>  obj-$(CONFIG_SIMPLE_FPGA_BUS)+= simple-fpga-bus.o
> diff --git a/drivers/fpga/fpga-bridge.c b/drivers/fpga/fpga-bridge.c
> new file mode 100644
> index 000..c135988
> --- /dev/null
> +++ b/drivers/fpga/fpga-bridge.c
> @@ -0,0 +1,242 @@
> +/*
> + * fpga bridge driver
> + *
> + *  Copyright (C) 2013-2015 Altera Corporation, All Rights Reserved.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static DEFINE_IDA(fpga_bridge_ida);
> +static struct class *fpga_bridge_class;
> +
> +/**
> + * fpga_bridge_enable
> + * @bridge: fpga bridge
> + *
> + * Enable transactions on the bridge
> + *
> + * Return: 0 for success, error code otherwise.
> + */
> +int fpga_bridge_enable(struct fpga_bridge *bridge)
> +{
> + pr_err("%s %s\n", __func__, dev_name(&bridge->dev));

Please clean this...

> +
> + return bridge->br_ops->enable_set(bridge, 1);
> +}
> +EXPORT_SYMBOL_GPL(fpga_bridge_enable);
> +
> +/**
> + * fpga_bridge_disable
> + * @bridge: fpga bridge
> + *
> + * Disable transactions on the bridge
> + *
> + * Return: 0 for success, error code otherwise.
> + */
> +int fpga_bridge_disable(struct fpga_bridge *bridge)
> +{
> + pr_err("%s %s\n", __func__, dev_name(&bridge->dev));

and this up.

> +
> + return bridge->br_ops->enable_set(bridge, 0);
> +}
> +EXPORT_SYMBOL_GPL(fpga_bridge_disable);
> +
> +static int fpga_bridge_of_node_match(struct device *dev, const void *data)
> +{
> + return dev->of_node == data;
> +}
> +
> +/**
> + * of_fpga_bridge_get - get an exclusive reference to a fpga bridge
> + * @node: device node
> + *
> + * Given a device node, get an exclusive reference to a fpga bridge.
> + *
> + * Returns a fpga manager struct or IS_ERR() condition containing errno.
> + */
> +struct fpga_bridge *of_fpga_bridge_get(struc

Re: [PATCH v12 3/6] fpga: add simple-fpga-bus

[Steffen Trumtrar]

On Tue, Oct 27, 2015 at 05:09:12PM -0500, at...@opensource.altera.com wrote:
> From: Alan Tull 
> 
> The Simple FPGA bus uses the FPGA Manager Framework and the
> FPGA Bridge Framework to provide a manufactorer-agnostic
> interface for reprogramming FPGAs that is Device Tree
> Overlays-based.
> 
> When a Device Tree Overlay containing a Simple FPGA Bus is
> applied, the Simple FPGA Bus will be probed and will:
>  * Disable the FPGA bridges specified in the overlay
>  * Reprogram a specified FPGA with a specified image file
>  * Enable the specified FPGA bridges
>  * Populate the child devices
> 
> Removing the Device Tree Overlay is also supported.
> 
> This supports fpga use where hardware blocks on a fpga will
> need drivers.
> 
> Signed-off-by: Alan Tull 
> ---
> v9:  initial version (this patch added during rest of patchset's v9)
> v10: request deferral if fpga mgr or bridges not available yet
>  cleanup as fpga manager core goes into the real kernel
>  Don't assume bridges are disabled before programming FPGA
>  Don't hang onto reference for fpga manager
>  Move to staging/simple-fpga-bus
> v11: No change in this patch for v11 of the patch set
> v12: Moved out of staging.
>  Use fpga bridges framework.
> ---
>  drivers/fpga/Kconfig   |7 +
>  drivers/fpga/Makefile  |3 +
>  drivers/fpga/simple-fpga-bus.c |  327 
> 
>  3 files changed, 337 insertions(+)
>  create mode 100644 drivers/fpga/simple-fpga-bus.c
> 
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index 348e1dea..e8f5453 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -13,6 +13,13 @@ config FPGA
>  
>  if FPGA
>  
> +config SIMPLE_FPGA_BUS
> +   bool "Simple FPGA Bus"
> +   depends on OF
> +   help
> + Simple FPGA Bus allows loading FPGA images under control of
> +  Device Tree.
> +
>  config FPGA_MGR_SOCFPGA
>   tristate "Altera SOCFPGA FPGA Manager"
>   depends on ARCH_SOCFPGA
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index bf0c0d2..0385622 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -8,3 +8,6 @@ obj-$(CONFIG_FPGA)+= fpga-mgr.o
>  # FPGA Manager Drivers
>  obj-$(CONFIG_FPGA_MGR_SOCFPGA)   += socfpga.o
>  obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10)   += socfpga-a10.o
> +
> +# High Level Interfaces
> +obj-$(CONFIG_SIMPLE_FPGA_BUS)+= simple-fpga-bus.o
> diff --git a/drivers/fpga/simple-fpga-bus.c b/drivers/fpga/simple-fpga-bus.c
> new file mode 100644
> index 000..6318cf1
> --- /dev/null
> +++ b/drivers/fpga/simple-fpga-bus.c
> @@ -0,0 +1,327 @@
> +/*
> + * Simple FPGA Bus
> + *
> + *  Copyright (C) 2013-2015 Altera Corporation
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * struct simple_fpga_bus - simple fpga bus private data
> + * @dev: device from pdev
> + * @bridges: FPGA bridges associated with this bus
> + * @num_bridges: size of the bridges array
> + */
> +struct simple_fpga_bus {
> + struct device *dev;
> + struct fpga_bridge **bridges;
> + int num_bridges;
> +};
> +
> +/**
> + * simple_fpga_bus_get_mgr - get associated fpga manager
> + * @priv: simple fpga bus private data
> + * pointer to fpga manager in priv->mgr on success
> + *
> + * Given a simple fpga bus, get a reference to its the fpga manager specified
> + * by its "fpga-mgr" device tree property.
> + *
> + * Return: 0 if the fpga manager is not specified.
> + * pointer to struct fpga_manager if successful.
> + * Negative error code otherwise.
> + */
> +static struct fpga_manager *simple_fpga_bus_get_mgr(
> + struct simple_fpga_bus *priv)
> +{
> + struct device *dev = priv->dev;
> + struct device_node *np = dev->of_node;
> + struct device_node *mgr_node;
> +
> + /*
> +  * Return 0 (not an error) if fpga manager is not specified.
> +  * This supports the case where fpga was already configured.
> +  */
> + mgr_node = of_parse_phandle(np, "fpga-mgr", 0);
> + if (!mgr_node) {
> + dev_dbg(dev, "could not find fpga-mgr DT property\n");
> + return 0;
> + }
> +
> + return of_fpga_mgr_get(mgr_node);
> +}
> +
> +/**
> + * si

Re: [PATCH v12 2/6] fpga: add bindings document for simple fpga bus

[Steffen Trumtrar]

On Tue, Oct 27, 2015 at 05:09:11PM -0500, at...@opensource.altera.com wrote:
> From: Alan Tull 
> 
> New bindings document for simple fpga bus.
> 
> Signed-off-by: Alan Tull 
> ---
> v9:  initial version added to this patchset
> v10: s/fpga/FPGA/g
>  replace DT overlay example with slightly more complicated example
>  move to staging/simple-fpga-bus
> v11: No change in this patch for v11 of the patch set
> v12: Moved out of staging.
>  Changed to use FPGA bridges framework instead of resets
>  for bridges.
> ---
>  .../devicetree/bindings/fpga/simple-fpga-bus.txt   |   81 
> 
>  1 file changed, 81 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
> 
> diff --git a/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt 
> b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
> new file mode 100644
> index 000..2e742f7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
> @@ -0,0 +1,81 @@
> +Simple FPGA Bus
> +===
> +
> +A Simple FPGA Bus is a bus that handles configuring an FPGA and its bridges
> +before populating the devices below its node.  All this happens when a device
> +tree overlay is added to the live tree.  This document describes that device
> +tree overlay.
> +
> +Required properties:
> +- compatible : should contain "simple-fpga-bus"
> +- #address-cells, #size-cells, ranges: must be present to handle address 
> space
> +  mapping for children.
> +
> +Optional properties:
> +- fpga-mgr : should contain a phandle to a FPGA manager.
> +- fpga-firmware : should contain the name of a FPGA image file located on the
> +  firmware search path.
> +- partial-reconfig : boolean property should be defined if partial
> +  reconfiguration of the FPGA is to be done, otherwise full reconfiguration
> +  is done.
> +- fpga-bridges : should contain a list of bridges that the bus will disable
> +  before   programming the FPGA and then enable after the FPGA has been
> +
> +Example:
> +
> +/dts-v1/;
> +/plugin/;
> +/ {
> + fragment@0 {
> + target-path="/soc";
> + __overlay__ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + bridge@0xff20 {
> + compatible = "simple-fpga-bus";
> + reg = <0xc000 0x2000>,
> +   <0xff20 0x0020>;
> + reg-names = "axi_h2f", "axi_h2f_lw";
> +
> + #address-cells = <0x2>;
> + #size-cells = <0x1>;
> +
> + ranges = <0x 0x 0xc000 
> 0x0001>,
> +  <0x0001 0x0002 0xff22 
> 0x0008>,
> +  <0x0001 0x00010040 0xff210040 
> 0x0020>;
> +
> + clocks = <0x2 0x2>;
> + clock-names = "h2f_lw_axi_clock", 
> "f2h_sdram0_clock";
> +
> + fpga-mgr = <&hps_0_fpgamgr>;
> + fpga-firmware = "soc_system.rbf";
> +
> + fpga-bridges = <&hps_fpgabridge0>, 
> <&hps_fpgabridge1>, <&hps_fpgabridge2>;

At least for Socfpga the HPS2FPGA and FPGA2HPS bridges can be configured to have
a bus width of 32, 64, 128 depending on the bitstream. How does this fit into 
here?
For DMA over this bus this is an interesting property to know, isn't it?
I guess something like "<&hps_fpgabridge0 64>" could be a possible solution, but
what is with the GPV registers of the bridges? Do they depend on the bitstream
loaded? Then this would get really messy I guess as it not a generic property.

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v12 5/6] ARM: socfpga: add bindings document for fpga bridge drivers

[Steffen Trumtrar]

Hi!

On Tue, Oct 27, 2015 at 05:09:14PM -0500, at...@opensource.altera.com wrote:
> From: Alan Tull 
> 
> Add bindings documentation for Altera SOCFPGA bridges:
>  * fpga2sdram
>  * fpga2hps
>  * hps2fpga
>  * lwhps2fpga
> 
> Signed-off-by: Alan Tull 
> Signed-off-by: Dinh Nguyen 
> Signed-off-by: Matthew Gerlach 
> ---
> v2:  separate into 2 documents for the 2 drivers
> v12: bump version to line up with simple-fpga-bus version
>  remove Linux specific notes such as references to sysfs
>  move non-DT specific documentation elsewhere
>  remove bindings that would have been used to pass configuration
>  clean up formatting
> ---
>  .../bindings/fpga/altera-fpga2sdram-bridge.txt |   18 ++
>  .../bindings/fpga/altera-hps2fpga-bridge.txt   |   36 
> 
>  2 files changed, 54 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
>  create mode 100644 
> Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt 
> b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
> new file mode 100644
> index 000..11eb5b7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
> @@ -0,0 +1,18 @@
> +Altera FPGA To SDRAM Bridge Driver
> +
> +Required properties:
> +- compatible : Should contain "altr,socfpga-fpga2sdram-bridge"
> +
> +Optional properties:
> +- label  : User-readable name for this bridge.
> +   Default is br
> +- init-val   : 0 if driver should disable bridge at startup
> +   1 if driver should enable bridge at startup
> +   Default is to leave bridge in current state.

I know, that there are bindings, that configure via devicetree, but AFAIK
this is not okay.

> +
> +Example:
> + fpga2sdram_br: fpgabridge@3 {
> + compatible = "altr,socfpga-fpga2sdram-bridge";
> + label = "fpga2sdram";
> + init-val = <0>;
> + };
> diff --git 
> a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt 
> b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> new file mode 100644
> index 000..eb52f3b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> @@ -0,0 +1,36 @@
> +Altera FPGA/HPS Bridge Driver
> +
> +Required properties:
> +- compatible : Should contain one of:
> +   "altr,socfpga-hps2fpga-bridge",
> +   "altr,socfpga-lwhps2fpga-bridge", or
> +   "altr,socfpga-fpga2hps-bridge"
> +- clocks : Clocks used by this module.
> +
> +Optional properties:
> +- label  : User-readable name for this bridge.
> +   Default is br
> +- init-val   : 0 if driver should disable bridge at startup.
> +   1 if driver should enable bridge at startup.
> +   Default is to leave bridge in its current state.
> +
> +Example:
> + hps_fpgabridge0: fpgabridge@0 {
> + compatible = "altr,socfpga-hps2fpga-bridge";
> + label = "hps2fpga";
> + clocks = <&l4_main_clk>;
> + init-val = <1>;
> + };
> +
> + hps_fpgabridge1: fpgabridge@1 {
> + compatible = "altr,socfpga-lwhps2fpga-bridge";
> + label = "lwhps2fpga";
> + clocks = <&l4_main_clk>;
> + init-val = <0>;
> + };
> +
> + hps_fpgabridge2: fpgabridge@2 {
> + compatible = "altr,socfpga-fpga2hps-bridge";
> + label = "fpga2hps";
> + clocks = <&l4_main_clk>;
> + };

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/4] extcon: arizona: Add extcon specific device tree binding document

[Lee Jones]

On Tue, 27 Oct 2015, Charles Keepax wrote:

> Subsystem specific bindings for the Arizona devices are being factored
> out of the MFD binding document into separate documents for each
> subsystem. This patch adds a binding document that covers the existing
> extcon specific bindings.
> 
> Signed-off-by: Charles Keepax 
> Acked-by: Chanwoo Choi 
> ---
> 
> Changes since v2:
>  - Moved the maintainer updates into a separate patch
> 
> Thanks,
> Charles
> 
>  .../devicetree/bindings/extcon/extcon-arizona.txt  |   15 +++
>  1 files changed, 15 insertions(+), 0 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/extcon/extcon-arizona.txt

Replied on Chanwoo's request.

> diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt 
> b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> new file mode 100644
> index 000..e1705fa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> @@ -0,0 +1,15 @@
> +Cirrus Logic Arizona class audio SoCs
> +
> +These devices are audio SoCs with extensive digital capabilities and a range
> +of analogue I/O.
> +
> +This document lists Extcon specific bindings, see the primary binding 
> document:
> +  ../mfd/arizona.txt
> +
> +Optional properties:
> +
> +  - wlf,hpdet-channel : Headphone detection channel.
> +ARIZONA_ACCDET_MODE_HPL or 1 - Headphone detect mode is set to HPDETL
> +ARIZONA_ACCDET_MODE_HPR or 2 - Headphone detect mode is set to HPDETR
> +If this node is not mentioned or if the value is unknown, then
> +headphone detection mode is set to HPDETL.

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

Re: [PATCH v3 3/4] mfd: arizona: Remove bindings covered in new subsystem specific docs

[Lee Jones]

On Wed, 28 Oct 2015, Chanwoo Choi wrote:
> On 2015년 10월 28일 18:03, Lee Jones wrote:
> > On Tue, 27 Oct 2015, Charles Keepax wrote:
> > 
> >> Binding documentation has been added in new subsystem specific binding
> >> documents. This patch removes the now duplicate documentation from the
> >> MFD documentation.
> >>
> >> Signed-off-by: Charles Keepax 
> >> ---
> >>
> >> Changes since v2:
> >>  - No longer moving the core regulators into the regulator binding 
> >> document,
> >>as they are properties of the device as a whole not just the regulators
> >>  - Moved the maintainer updates into a seperate patch
> >>
> >> Lee, I have removed your ack because the patch has changed a fair amount.
> >> Apologies if this would not have been your preference.
> > 
> > That was the right thing to do.
> > 
> >> Thanks,
> >> Charles
> >>
> >>  Documentation/devicetree/bindings/mfd/arizona.txt |   15 +++
> >>  1 files changed, 3 insertions(+), 12 deletions(-)
> > 
> > Applied, thanks.
> 
> If you possible, could you pick patch1[1] which has already the acked tag of 
> me?
> [1] [PATCH v3 1/4] extcon: arizona: Add extcon specific device tree binding 
> document

Yes, no problem.

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

Re: [PATCH v3 4/4] MAINTAINERS: Add binding docs for Cirrus Logic/Wolfson Arizona devices

[Lee Jones]

On Wed, 28 Oct 2015, Chanwoo Choi wrote:

> Hi Charles,
> 
> On 2015년 10월 28일 01:01, Charles Keepax wrote:
> > Add device tree binding documentation for the Arizona drivers
> > to the MAINTAINERS file.
> >
> > Signed-off-by: Charles Keepax 
> > ---
> >
> > Changes since v2:
> >  - Moved all the maintainer updates into this patch
> >
> > Thanks,
> > Charles
> >
> >  MAINTAINERS |3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 0658fec..4dc45de 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -11392,6 +11392,9 @@ T:  git 
> > https://github.com/CirrusLogic/linux-drivers.git
> >  W: https://github.com/CirrusLogic/linux-drivers/wiki
> >  S: Supported
> >  F: Documentation/hwmon/wm83??
> > +F: Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> > +F: Documentation/devicetree/bindings/regulator/arizona-regulator.txt
> > +F: Documentation/devicetree/bindings/mfd/arizona.txt
> >  F: arch/arm/mach-s3c64xx/mach-crag6410*
> >  F: drivers/clk/clk-wm83*.c
> >  F: drivers/extcon/extcon-arizona.c
> >
> 
> [for extcon]
> Acked-by: Chanwoo Choi 

Will apply this retroactively.  Thanks.

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

[PATCH v8 16/17] drm: bridge: analogix/dp: move hpd detect to connector detect function

[Yakir Yang]

This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().

Tested-by: Javier Martinez Canillas 
Signed-off-by: Yakir Yang 
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Take Jingoo suggest, add commit messages.

Changes in v3:
- move dp hpd detect to connector detect function.

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 3842dbd..216d33d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -901,12 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to disable the panel\n");
}
 
-   ret = analogix_dp_detect_hpd(dp);
-   if (ret) {
-   /* Cable has been disconnected, we're done */
-   return;
-   }
-
ret = analogix_dp_handle_edid(dp);
if (ret) {
dev_err(dp->dev, "unable to handle edid\n");
@@ -941,6 +935,11 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
 
 enum drm_connector_status analogix_dp_detect(struct device *dev, bool force)
 {
+   struct analogix_dp_device *dp = dev_get_drvdata(dev);
+
+   if (analogix_dp_detect_hpd(dp))
+   return connector_status_disconnected;
+
return connector_status_connected;
 }
 EXPORT_SYMBOL_GPL(analogix_dp_detect);
-- 
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 v8 17/17] drm: bridge: analogix/dp: add edid modes parse in get_modes method

[Yakir Yang]

Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.

Tested-by: Javier Martinez Canillas 
Signed-off-by: Yakir Yang 
---
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Call drm_panel_prepare() in .get_modes function, ensure panel should
  power on before driver try to read edid message.

Changes in v3:
- Add edid modes parse support

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 24 +++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 46 +++---
 2 files changed, 40 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 216d33d..4fa5f69 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -107,7 +107,7 @@ static unsigned char 
analogix_dp_calc_edid_check_sum(unsigned char *edid_data)
 
 static int analogix_dp_read_edid(struct analogix_dp_device *dp)
 {
-   unsigned char edid[EDID_BLOCK_LENGTH * 2];
+   unsigned char *edid = dp->edid;
unsigned int extend_block = 0;
unsigned char sum;
unsigned char test_vector;
@@ -901,12 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to disable the panel\n");
}
 
-   ret = analogix_dp_handle_edid(dp);
-   if (ret) {
-   dev_err(dp->dev, "unable to handle edid\n");
-   return;
-   }
-
ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
 dp->video_info.max_link_rate);
if (ret) {
@@ -947,8 +941,24 @@ EXPORT_SYMBOL_GPL(analogix_dp_detect);
 int analogix_dp_get_modes(struct device *dev)
 {
struct analogix_dp_device *dp = dev_get_drvdata(dev);
+   struct edid *edid = (struct edid *)dp->edid;
int num_modes = 0;
 
+   if (dp->plat_data && dp->plat_data->panel) {
+   if (drm_panel_prepare(dp->plat_data->panel)) {
+   DRM_ERROR("failed to setup the panel\n");
+   return -EINVAL;
+   }
+   }
+
+   if (analogix_dp_handle_edid(dp)) {
+   dev_err(dp->dev, "unable to handle edid\n");
+   return -EINVAL;
+   }
+
+   drm_mode_connector_update_edid_property(dp->connector, edid);
+   num_modes += drm_add_edid_modes(dp->connector, edid);
+
if (dp->plat_data->panel)
num_modes += drm_panel_get_modes(dp->plat_data->panel);
 
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index d3c7e0a..2bd2e0d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,28 @@
 #define MAX_CR_LOOP 5
 #define MAX_EQ_LOOP 5
 
+/* I2C EDID Chip ID, Slave Address */
+#define I2C_EDID_DEVICE_ADDR   0x50
+#define I2C_E_EDID_DEVICE_ADDR 0x30
+
+#define EDID_BLOCK_LENGTH  0x80
+#define EDID_HEADER_PATTERN0x00
+#define EDID_EXTENSION_FLAG0x7e
+#define EDID_CHECKSUM  0x7f
+
+/* DP_MAX_LANE_COUNT */
+#define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
+#define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
+
+/* DP_LANE_COUNT_SET */
+#define DPCD_LANE_COUNT_SET(x) ((x) & 0x1f)
+
+/* DP_TRAINING_LANE0_SET */
+#define DPCD_PRE_EMPHASIS_SET(x)   (((x) & 0x3) << 3)
+#define DPCD_PRE_EMPHASIS_GET(x)   (((x) >> 3) & 0x3)
+#define DPCD_VOLTAGE_SWING_SET(x)  (((x) & 0x3) << 0)
+#define DPCD_VOLTAGE_SWING_GET(x)  (((x) >> 0) & 0x3)
+
 enum link_rate_type {
LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
@@ -161,6 +183,7 @@ struct analogix_dp_device {
int dpms_mode;
int hpd_gpio;
boolneed_force_hpd;
+   unsigned char   edid[EDID_BLOCK_LENGTH * 2];
 
struct analogix_dp_plat_data *plat_data;
 };
@@ -260,27 +283,4 @@ int analogix_dp_is_video_stream_on(struct 
analogix_dp_device *dp);
 void analogix_dp_config_video_slave_mode(struct analogix_dp_device *dp);
 void analogix_dp_enable_scrambling(struct analogix_dp_device *dp);
 void analogix_dp_disable_scrambling(struct analogix_dp_device *dp);
-
-/* I2C EDID Chip ID, Slave Address */
-#define I2C_EDID_DEVICE_ADDR   0x50
-#define I2C_E_EDID_DEVICE_ADDR 0x30
-
-#define EDID_BLOCK_LENGTH  0x80
-#define EDID_HEADER_PATTERN0x00
-#define EDID_EXTENSION_FLAG0x7e

RE: [PATCH v3 1/2] mtd: brcmnand: Force 8bit mode before doing nand_scan_ident()

[Anup Patel]

> -Original Message-
> From: Brian Norris [mailto:computersforpe...@gmail.com]
> Sent: 28 October 2015 05:45
> To: Anup Patel
> Cc: David Woodhouse; Linux MTD; Rob Herring; Pawel Moll; Mark Rutland;
> Catalin Marinas; Will Deacon; Sudeep Holla; Ian Campbell; Kumar Gala; Ray Jui;
> Scott Branden; Florian Fainelli; Pramod Kumar; Vikram Prakash; Sandeep
> Tripathy; Linux ARM Kernel; Device Tree; Linux Kernel; 
> bcm-kernel-feedback-list
> Subject: Re: [PATCH v3 1/2] mtd: brcmnand: Force 8bit mode before doing
> nand_scan_ident()
> 
> On Fri, Oct 23, 2015 at 10:46:12AM +0530, Anup Patel wrote:
> > Just like other NAND controllers, the NAND READID command only works
> > in 8bit mode for all versions of BRCMNAND controller.
> >
> > This patch forces 8bit mode for each NAND CS in brcmnand_init_cs()
> > before doing nand_scan_ident() to ensure that BRCMNAND controller is
> > in 8bit mode when NAND READID command is issued.
> >
> > Signed-off-by: Anup Patel 
> > Reviewed-by: Ray Jui 
> > Reviewed-by: Scott Branden 
> > ---
> >  drivers/mtd/nand/brcmnand/brcmnand.c | 9 +
> >  1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
> > b/drivers/mtd/nand/brcmnand/brcmnand.c
> > index 4cba03d..0be8ef9 100644
> > --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> > +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> > @@ -1888,6 +1888,7 @@ static int brcmnand_init_cs(struct brcmnand_host
> *host)
> > struct mtd_info *mtd;
> > struct nand_chip *chip;
> > int ret;
> > +   u16 cfg_offs;
> > struct mtd_part_parser_data ppdata = { .of_node = dn };
> >
> > ret = of_property_read_u32(dn, "reg", &host->cs); @@ -1930,6
> > +1931,14 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
> >
> > chip->controller = &ctrl->controller;
> >
> > +   /*
> > +* The bootloader might have configured 16bit mode but
> > +* NAND READID command only works in 8bit mode. We force
> > +* 8bit mode here to ensure that NAND READID commands works.
> > +*/
> > +   cfg_offs = brcmnand_cs_offset(ctrl, host->cs, BRCMNAND_CS_CFG);
> > +   nand_writereg(ctrl, cfg_offs, nand_readreg(ctrl, cfg_offs) &
> > +~BIT(23));
> 
> Can we get a new enum for cfg bits? Unfortunately, I never managed that in
> brcmnand_set_cfg(); just magic numbers :( But I'd like to stop that if we're 
> going
> to have to touch these bits outside of brcmnand_set_cfg().

Even I felt the need to have enum for cfg bits, just like other parts of the
BRCM NAND driver.

> 
> > +
> > if (nand_scan_ident(mtd, 1, NULL))
> > return -ENXIO;
> >
> 
> How about the following, as a preparatory patch? Only compile tested.
> 
> From c5423a86dbfa33b550d2b170bda3c12ecf4d5313 Mon Sep 17 00:00:00
> 2001
> From: Brian Norris 
> Date: Tue, 27 Oct 2015 17:12:13 -0700
> Subject: [PATCH] mtd: brcmnand: factor out CFG and CFG_EXT bitfields
> 
> These used magic numbers. Shame on me.
> 
> Signed-off-by: Brian Norris 
> Cc: Anup Patel 
> ---
>  drivers/mtd/nand/brcmnand/brcmnand.c | 38
> +---
>  1 file changed, 31 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c
> b/drivers/mtd/nand/brcmnand/brcmnand.c
> index d694d876631e..c93fbc3869ee 100644
> --- a/drivers/mtd/nand/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/brcmnand/brcmnand.c
> @@ -344,6 +344,28 @@ static const u8 brcmnand_cs_offsets_cs0[] = {
>   [BRCMNAND_CS_TIMING2]   = 0x14,
>  };
> 
> +/*
> + * Bitfields for the CFG and CFG_EXT registers. Pre-v7.1 controllers
> +only had
> + * one config register, but once the bitfields overflowed, newer
> +controllers
> + * (v7.1 and newer) added a CFG_EXT register and shuffled a few fields 
> around.
> + */
> +enum {
> + CFG_BLK_ADR_BYTES_SHIFT = 8,
> + CFG_COL_ADR_BYTES_SHIFT = 12,
> + CFG_FUL_ADR_BYTES_SHIFT = 16,
> + CFG_BUS_WIDTH_SHIFT = 23,
> + CFG_BUS_WIDTH   =
> BIT(CFG_BUS_WIDTH_SHIFT),
> + CFG_DEVICE_SIZE_SHIFT   = 24,
> +
> + /* Only for pre-v7.1 (with no CFG_EXT register) */
> + CFG_PAGE_SIZE_SHIFT = 20,
> + CFG_BLK_SIZE_SHIFT  = 28,
> +
> + /* Only for v7.1+ (with CFG_EXT register) */
> + CFG_EXT_PAGE_SIZE_SHIFT = 0,
> + CFG_EXT_BLK_SIZE_SHIFT  = 4,
> +};
> +
>  /* BRCMNAND_INTFC_STATUS */
>  enum {
>   INTFC_FLASH_STATUS  = GENMASK(7, 0),
> @@ -1710,17 +1732,19 @@ static int brcmnand_set_cfg(struct brcmnand_host
> *host,
>   }
>   device_size = fls64(cfg->device_size) -
> fls64(BRCMNAND_MIN_DEVSIZE);
> 
> - tmp = (cfg->blk_adr_bytes << 8) |
> - (cfg->col_adr_bytes << 12) |
> - (cfg->ful_adr_bytes << 16) |
> - (!!(cfg->device_width == 16) << 23) |
> - (device_size << 24);
> + tmp = (cfg->blk_adr_bytes << CFG_BLK_ADR_BYTES_SHIFT) |
> + (cfg->col_adr_bytes << CFG_BLK_ADR_BYTES_SHIFT) |
> + 

Re: [PATCH v3 3/4] mfd: arizona: Remove bindings covered in new subsystem specific docs

[Chanwoo Choi]

Hi Lee,

On 2015년 10월 28일 18:03, Lee Jones wrote:
> On Tue, 27 Oct 2015, Charles Keepax wrote:
> 
>> Binding documentation has been added in new subsystem specific binding
>> documents. This patch removes the now duplicate documentation from the
>> MFD documentation.
>>
>> Signed-off-by: Charles Keepax 
>> ---
>>
>> Changes since v2:
>>  - No longer moving the core regulators into the regulator binding document,
>>as they are properties of the device as a whole not just the regulators
>>  - Moved the maintainer updates into a seperate patch
>>
>> Lee, I have removed your ack because the patch has changed a fair amount.
>> Apologies if this would not have been your preference.
> 
> That was the right thing to do.
> 
>> Thanks,
>> Charles
>>
>>  Documentation/devicetree/bindings/mfd/arizona.txt |   15 +++
>>  1 files changed, 3 insertions(+), 12 deletions(-)
> 
> Applied, thanks.

If you possible, could you pick patch1[1] which has already the acked tag of me?
[1] [PATCH v3 1/4] extcon: arizona: Add extcon specific device tree binding 
document

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

RE: [PATCH v3 2/2] arm64: dts: Add BRCM IPROC NAND DT node for NS2

[Anup Patel]

> -Original Message-
> From: Ray Jui [mailto:r...@broadcom.com]
> Sent: 28 October 2015 06:17
> To: Brian Norris
> Cc: Anup Patel; David Woodhouse; Linux MTD; Rob Herring; Pawel Moll; Mark
> Rutland; Catalin Marinas; Will Deacon; Sudeep Holla; Ian Campbell; Kumar Gala;
> Scott Branden; Florian Fainelli; Pramod Kumar; Vikram Prakash; Sandeep
> Tripathy; Linux ARM Kernel; Device Tree; Linux Kernel; 
> bcm-kernel-feedback-list
> Subject: Re: [PATCH v3 2/2] arm64: dts: Add BRCM IPROC NAND DT node for
> NS2
> 
> 
> 
> On 10/27/2015 5:39 PM, Brian Norris wrote:
> > On Tue, Oct 27, 2015 at 05:25:32PM -0700, Ray Jui wrote:
> >> On 10/27/2015 5:19 PM, Brian Norris wrote:
> >>> On Fri, Oct 23, 2015 at 10:46:13AM +0530, Anup Patel wrote:
>  diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
>  b/arch/arm64/boot/dts/broadcom/ns2.dtsi
>  index f603277..9610822 100644
>  --- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
>  +++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
>  @@ -212,5 +212,19 @@
>   compatible = "brcm,iproc-rng200";
>   reg = <0x6622 0x28>;
>   };
>  +
>  +nand: nand@6646 {
>  +compatible = "brcm,nand-iproc", "brcm,brcmnand-
> v6.1";
> >>>
> >>> Technically, the binding says you should also have "brcm,brcmnand"
> >>> as a last resort. Otherwise (for the NAND parts):
> >>>
> >>
> >> I believe Anup was seeing issues when both "brcm,nand-iproc" and
> >> "brcm,brcmnand" are present.
> >>
> >> Note "brcm,nand-iproc" invokes 'iproc_nand_probe', which calls
> >> 'brcmnand_probe' in the end.
> >>
> >> "brcm,brcmnand" invokes 'brcmstb_nand_probe', which also calls
> >> 'brcmstb_probe', but without all the prep configuration required for
> >> "brcm,nand-iproc".
> >
> > Ah, I forgot about that problem. That seems like an OF infrastructure
> > issue that could be fixed. We could lump these drivers back together,
> > and make sure that "brcm,nand-iproc" gets the priority in the
> > of_device_id list.
> >
> > Or we could just relax the DT binding.
> >
> > But wait, wouldn't cygnus already have that problem? You're using the
> > binding I suggested in arch/arm/boot/dts/bcm-cygnus.dtsi.
> 
> Interestingly, we do not see this problem with Cygnus or NSP, but only on NS2
> (arm64 based). There may be a difference between how OF devices are
> instantiated between arm and arm64?

Alternately, it could be also about order in-which platform drivers are matched
for newly created OF device.

> 
> >
> > Oh, and I see we hacked this one in drivers/mtd/nand/brcmnand/Makefile:
> >
> ># link order matters; don't link the more generic brcmstb_nand.o before 
> > the
> ># more specific iproc_nand.o, for instance
> 
> Yes, I see that too (after sending out my previous email, :)). Maybe
> Anup can help to elaborate on the problem. I'm now getting a bit
> confused on how the problem can surface on NS2.

I think for a newly created OF devices the Linux device driver framework will
match the platform drivers in the order in which they are registered by module
init functions. Now the order of module init function calls will be based how
the .initcall section is formed by linker and order in which objects are linked.

IMHO, if multiple platform drivers match given OF device then platform driver
with longest matching compatible string should only be probed. I don't know
how big change this would be for OF framework.

> 
> But in general, I think it's a good idea to relax the requirement in the
> DT binding document to not require "brcm,brcmnand", in the case when
> "brcm,nand-iproc" and "brcm,nand-bcm63138" are present.

Even I think, it will be good to relax the DT bindings requirement for
BRCM NAND driver.

Regards,
Anup
--
To unsubscribe from this list: send the line "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 4/4] MAINTAINERS: Add binding docs for Cirrus Logic/Wolfson Arizona devices

[Chanwoo Choi]

Hi Charles,

On 2015년 10월 28일 01:01, Charles Keepax wrote:
> Add device tree binding documentation for the Arizona drivers
> to the MAINTAINERS file.
> 
> Signed-off-by: Charles Keepax 
> ---
> 
> Changes since v2:
>  - Moved all the maintainer updates into this patch
> 
> Thanks,
> Charles
> 
>  MAINTAINERS |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0658fec..4dc45de 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11392,6 +11392,9 @@ T:git 
> https://github.com/CirrusLogic/linux-drivers.git
>  W:   https://github.com/CirrusLogic/linux-drivers/wiki
>  S:   Supported
>  F:   Documentation/hwmon/wm83??
> +F:   Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> +F:   Documentation/devicetree/bindings/regulator/arizona-regulator.txt
> +F:   Documentation/devicetree/bindings/mfd/arizona.txt
>  F:   arch/arm/mach-s3c64xx/mach-crag6410*
>  F:   drivers/clk/clk-wm83*.c
>  F:   drivers/extcon/extcon-arizona.c
> 

[for extcon]
Acked-by: Chanwoo Choi 

Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line "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 4/4] MAINTAINERS: Add binding docs for Cirrus Logic/Wolfson Arizona devices

[Lee Jones]

On Wed, 28 Oct 2015, Lee Jones wrote:

> On Tue, 27 Oct 2015, Charles Keepax wrote:
> 
> > Add device tree binding documentation for the Arizona drivers
> > to the MAINTAINERS file.
> > 
> > Signed-off-by: Charles Keepax 
> > ---
> > 
> > Changes since v2:
> >  - Moved all the maintainer updates into this patch
> > 
> > Thanks,
> > Charles
> > 
> >  MAINTAINERS |3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 0658fec..4dc45de 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -11392,6 +11392,9 @@ T:  git 
> > https://github.com/CirrusLogic/linux-drivers.git
> >  W: https://github.com/CirrusLogic/linux-drivers/wiki
> >  S: Supported
> >  F: Documentation/hwmon/wm83??
> > +F: Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> > +F: Documentation/devicetree/bindings/regulator/arizona-regulator.txt
> > +F: Documentation/devicetree/bindings/mfd/arizona.txt
> 
> Acked-by: Lee Jones 

Actually, this patch is so uncontroversial:

Applied, thanks.

> >  F: arch/arm/mach-s3c64xx/mach-crag6410*
> >  F: drivers/clk/clk-wm83*.c
> >  F: drivers/extcon/extcon-arizona.c
> 

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

Re: [PATCH v3 3/4] mfd: arizona: Remove bindings covered in new subsystem specific docs

[Lee Jones]

On Tue, 27 Oct 2015, Charles Keepax wrote:

> Binding documentation has been added in new subsystem specific binding
> documents. This patch removes the now duplicate documentation from the
> MFD documentation.
> 
> Signed-off-by: Charles Keepax 
> ---
> 
> Changes since v2:
>  - No longer moving the core regulators into the regulator binding document,
>as they are properties of the device as a whole not just the regulators
>  - Moved the maintainer updates into a seperate patch
> 
> Lee, I have removed your ack because the patch has changed a fair amount.
> Apologies if this would not have been your preference.

That was the right thing to do.

> Thanks,
> Charles
> 
>  Documentation/devicetree/bindings/mfd/arizona.txt |   15 +++
>  1 files changed, 3 insertions(+), 12 deletions(-)

Applied, thanks.

> diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
> b/Documentation/devicetree/bindings/mfd/arizona.txt
> index a8fee60..18be0cb 100644
> --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> @@ -44,7 +44,6 @@ Required properties:
>  Optional properties:
>  
>- wlf,reset : GPIO specifier for the GPIO controlling /RESET
> -  - wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
>  
>- wlf,gpio-defaults : A list of GPIO configuration register values. Defines
>  for the appropriate values can found in . If
> @@ -67,21 +66,13 @@ Optional properties:
>  present, the number of values should be less than or equal to the
>  number of inputs, unspecified inputs will use the chip default.
>  
> -  - wlf,hpdet-channel : Headphone detection channel.
> -ARIZONA_ACCDET_MODE_HPL or 1 - Headphone detect mode is set to HPDETL
> -ARIZONA_ACCDET_MODE_HPR or 2 - Headphone detect mode is set to HPDETR
> -If this node is not mentioned or if the value is unknown, then
> -headphone detection mode is set to HPDETL.
> -
>- DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified 
> if
>  they are being externally supplied. As covered in
>  Documentation/devicetree/bindings/regulator/regulator.txt
>  
> -Optional subnodes:
> -  - ldo1 : Initial data for the LDO1 regulator, as covered in
> -Documentation/devicetree/bindings/regulator/regulator.txt
> -  - micvdd : Initial data for the MICVDD regulator, as covered in
> -Documentation/devicetree/bindings/regulator/regulator.txt
> +Also see child specific device properties:
> +  Regulator - ../regulator/arizona-regulator.txt
> +  Extcon- ../extcon/extcon-arizona.txt
>  
>  Example:
>  

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

Re: [PATCH v12 2/6] fpga: add bindings document for simple fpga bus

[Steffen Trumtrar]

Hi!

On Tue, Oct 27, 2015 at 05:09:11PM -0500, at...@opensource.altera.com wrote:
> From: Alan Tull 
> 
> New bindings document for simple fpga bus.
> 
> Signed-off-by: Alan Tull 
> ---
> v9:  initial version added to this patchset
> v10: s/fpga/FPGA/g
>  replace DT overlay example with slightly more complicated example
>  move to staging/simple-fpga-bus
> v11: No change in this patch for v11 of the patch set
> v12: Moved out of staging.
>  Changed to use FPGA bridges framework instead of resets
>  for bridges.
> ---
>  .../devicetree/bindings/fpga/simple-fpga-bus.txt   |   81 
> 
>  1 file changed, 81 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
> 
> diff --git a/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt 
> b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
> new file mode 100644
> index 000..2e742f7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/simple-fpga-bus.txt
> @@ -0,0 +1,81 @@
> +Simple FPGA Bus
> +===
> +
> +A Simple FPGA Bus is a bus that handles configuring an FPGA and its bridges
> +before populating the devices below its node.  All this happens when a device
> +tree overlay is added to the live tree.  This document describes that device
> +tree overlay.
> +

This is not really true, is it?
The driver should work without applying the overlay, e.g. the bootloader
might have already done it.

> +Required properties:
> +- compatible : should contain "simple-fpga-bus"
> +- #address-cells, #size-cells, ranges: must be present to handle address 
> space
> +  mapping for children.
> +
> +Optional properties:
> +- fpga-mgr : should contain a phandle to a FPGA manager.
> +- fpga-firmware : should contain the name of a FPGA image file located on the
> +  firmware search path.
> +- partial-reconfig : boolean property should be defined if partial
> +  reconfiguration of the FPGA is to be done, otherwise full reconfiguration
> +  is done.
> +- fpga-bridges : should contain a list of bridges that the bus will disable
> +  before   programming the FPGA and then enable after the FPGA has been
   ^^^???

> +
> +Example:
> +
> +/dts-v1/;
> +/plugin/;
> +/ {
> + fragment@0 {
> + target-path="/soc";
> + __overlay__ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + bridge@0xff20 {
   ^^

> + compatible = "simple-fpga-bus";
> + reg = <0xc000 0x2000>,
> +   <0xff20 0x0020>;
> + reg-names = "axi_h2f", "axi_h2f_lw";
> +
> + #address-cells = <0x2>;
> + #size-cells = <0x1>;
> +
> + ranges = <0x 0x 0xc000 
> 0x0001>,
> +  <0x0001 0x0002 0xff22 
> 0x0008>,
> +  <0x0001 0x00010040 0xff210040 
> 0x0020>;
> +
> + clocks = <0x2 0x2>;
> + clock-names = "h2f_lw_axi_clock", 
> "f2h_sdram0_clock";
> +
> + fpga-mgr = <&hps_0_fpgamgr>;
> + fpga-firmware = "soc_system.rbf";
> +
> + fpga-bridges = <&hps_fpgabridge0>, 
> <&hps_fpgabridge1>, <&hps_fpgabridge2>;
> +
> + onchip_memory2_0: memory@0x0 {
 ^^

> + device_type = "memory";
> + compatible = "ALTR,onchipmem-15.1";
> + reg = <0x 0x 
> 0x0001>;
> + };
> +
> + jtag_uart: serial@0x10002 {
  ^^

> + compatible = "altr,juart-15.1", 
> "altr,juart-1.0";
> + reg = <0x0001 0x0002 
> 0x0008>;
> + interrupt-parent = <&intc>;
> + interrupts = <0 42 4>;
> + };
> +
> + led_pio: gpio@0x100010040 {
  ^^

No 0x, please.

> + compatible = "altr,pio-15.1", 
> "altr,pio-1.0";
> + reg = <0x0001 0x00010040 
> 0x0020>;
> + altr,gpio-bank-width = <4>;
> + resetvalue = <0>;
> + #gpio-cells = <2>;
> + gpio-con

Re: [PATCH v3 4/4] MAINTAINERS: Add binding docs for Cirrus Logic/Wolfson Arizona devices

[Lee Jones]

On Tue, 27 Oct 2015, Charles Keepax wrote:

> Add device tree binding documentation for the Arizona drivers
> to the MAINTAINERS file.
> 
> Signed-off-by: Charles Keepax 
> ---
> 
> Changes since v2:
>  - Moved all the maintainer updates into this patch
> 
> Thanks,
> Charles
> 
>  MAINTAINERS |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0658fec..4dc45de 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11392,6 +11392,9 @@ T:git 
> https://github.com/CirrusLogic/linux-drivers.git
>  W:   https://github.com/CirrusLogic/linux-drivers/wiki
>  S:   Supported
>  F:   Documentation/hwmon/wm83??
> +F:   Documentation/devicetree/bindings/extcon/extcon-arizona.txt
> +F:   Documentation/devicetree/bindings/regulator/arizona-regulator.txt
> +F:   Documentation/devicetree/bindings/mfd/arizona.txt

Acked-by: Lee Jones 

>  F:   arch/arm/mach-s3c64xx/mach-crag6410*
>  F:   drivers/clk/clk-wm83*.c
>  F:   drivers/extcon/extcon-arizona.c

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