Re: [linux-sunxi] Re: [PATCH v10 4/5] crypto: Add Allwinner Security System crypto accelerator

[LABBE Corentin]

On Tue, Jul 07, 2015 at 09:49:36PM +0800, Herbert Xu wrote:
> On Mon, Jul 06, 2015 at 09:10:47PM +0200, LABBE Corentin wrote:
> >
> > +int sun4i_hash_init(struct ahash_request *areq)
> > +{
> > +   const char *hash_type;
> > +   struct sun4i_req_ctx *op = ahash_request_ctx(areq);
> > +   struct crypto_ahash *tfm = crypto_ahash_reqtfm(areq);
> > +   struct ahash_alg *alg = __crypto_ahash_alg(tfm->base.__crt_alg);
> > +   struct sun4i_ss_alg_template *algt;
> > +   struct sun4i_ss_ctx *ss;
> > +
> > +   memset(op, 0, sizeof(struct sun4i_req_ctx));
> > +
> > +   algt = container_of(alg, struct sun4i_ss_alg_template, alg.hash);
> > +   ss = algt->ss;
> > +   op->ss = algt->ss;
> > +
> > +   hash_type = crypto_tfm_alg_name(areq->base.tfm);
> > +
> > +   if (strcmp(hash_type, "sha1") == 0)
> > +   op->mode = SS_OP_SHA1;
> > +   else if (strcmp(hash_type, "md5") == 0)
> > +   op->mode = SS_OP_MD5;
> 
> Please store these modes in algt and then you wouldn't need to do
> the strcmp.
> 

thanks, that's better

> > +int sun4i_hash_import_md5(struct ahash_request *areq, const void *in)
> > +{
> > +   struct sun4i_req_ctx *op = ahash_request_ctx(areq);
> > +   const struct md5_state *ictx = in;
> > +   int i;
> 
> You need to initialise op->ss here.  Ditto for SHA.
> 

Ok

> > +   /* get the partial hash only if something was written */
> > +   if (op->mode == SS_OP_SHA1) {
> > +   for (i = 0; i < 5; i++)
> > +   op->hash[i] = readl(ss->base + SS_MD0 + i * 4);
> > +   } else {
> > +   for (i = 0; i < 4; i++)
> > +   op->hash[i] = readl(ss->base + SS_MD0 + i * 4);
> > +   }
> 
> You can avoid the op->mode check by storing the hash size in algt.
> 

It seems that I can use crypto_ahash_digestsize() that do the same thing.

> > +int sun4i_hash_finup(struct ahash_request *areq)
> > +{
> > +   int err;
> > +
> > +   err = sun4i_hash_update(areq);
> > +   if (err != 0)
> > +   return err;
> > +
> > +   return sun4i_hash_final(areq);
> 
> You can drop finup since the API provides a default finup that's
> exactly the same as this.  You only need to provide finup if it
> can optimise on this.
> 
> Ditto for digest.

If I remove digest(), loading the driver crash the kernel with:

Unable to handle kernel NULL pointer dereference at virtual address 
pgd = c0004000
[] *pgd=
Internal error: Oops: 8007 [#1] PREEMPT SMP ARM
CPU: 0 PID: 10120 Comm: cryptomgr_test Tainted: GE   4.2.0-rc1+ #78
LR is at crypto_ahash_op+0x30/0x68

For using the default one does I need to do something particular ?

Thanks

LABBE Corentin

--
To unsubscribe from this list: send the line "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/3] dt-bindings: pwm: add MediaTek display PWM bindings

[YH Huang]

On Thu, 2015-07-09 at 12:47 +0800, Daniel Kurtz wrote:
> On Thu, Jul 9, 2015 at 10:45 AM, YH Huang  wrote:
> >
> > On Wed, 2015-07-08 at 20:11 +0800, Daniel Kurtz wrote:
> > > On Mon, Jul 6, 2015 at 9:29 PM, YH Huang  wrote:
> > > > Document the device-tree binding of MediatTek display PWM.
> > > > The PWM has one channel to control the backlight brightness for display.
> > > > It supports MT8173 and MT6595.
> > > >
> > > > Signed-off-by: YH Huang 
> > > > ---
> > > >  .../devicetree/bindings/pwm/pwm-mtk-disp.txt   | 24 
> > > > ++
> > > >  1 file changed, 24 insertions(+)
> > > >  create mode 100644 
> > > > Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt 
> > > > b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > > > new file mode 100644
> > > > index 000..757b974
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > > > @@ -0,0 +1,24 @@
> > > > +MediaTek display PWM controller
> > > > +
> > > > +Required properties:
> > > > + - compatible: should be "mediatek,-disp-pwm"
> > > > +   - "mediatek,mt8173-disp-pwm": found on mt8173 SoC
> > > > +   - "mediatek,mt6595-disp-pwm": found on mt6595 SoC
> > > > + - reg: physical base address and length of the controller's registers
> > > > + - #pwm-cells: must be 2. See pwm.txt in this directory for a 
> > > > description of
> > > > +   the cell format
> > > > + - clocks: phandle and clock specifier of the PWM reference clock
> > > > + - clock-names: must contain the following
> > > > +   - "main": clock used to generate PWM signals
> > > > +   - "mm": sync signals from the modules of mmsys

- pinctrl-names: Must contain a "default" entry.
- pinctrl-0: One property must exist for each entry in pinctrl-names.
  See pinctrl/pinctrl-bindings.txt for details of the property values.

> > > > +
> > > > +Example:
> > > > +   pwm0: pwm@1401e000 {
> > > > +   compatible = "mediatek,mt8173-disp-pwm",
> > > > +"mediatek,mt6595-disp-pwm";
> > > > +   reg = <0 0x1401e000 0 0x1000>;
> > > > +   #pwm-cells = <2>;
> > > > +   clocks = <&mmsys CLK_MM_DISP_PWM026M>,
> > > > +<&mmsys CLK_MM_DISP_PWM0MM>;
> > > > +   clock-names = "main", "mm";

pio: pinctrl@10005000 {
...

   disp_pwm0_pins: disp_pwm0_pins {
pins1 {
pinmux = ;
bias-pull-up;
};
   };

...
}

pwm0: pwm@1401e000 {
compatible = "mediatek,mt8173-disp-pwm";
reg = <0 0x1401e000 0 0x1000>;
#pwm-cells = <2>;
clocks = <&mmsys CLK_MM_DISP_PWM0MM>,
 <&mmsys CLK_MM_DISP_PWM026M>;
clock-names = "mm", "main";
pinctrl-names = "default";
pinctrl-0 = <&disp_pwm0_pins>;
status = "disabled";
};

So should I change dtsi like this?

Regards,
YH Huang

> > >
> > > Should we include the pinctrl settings here to enable the PWM output?
> > >
> >
> > Since we use pwm-backlight driver to control backlight, we should enable
> > PWM output in the backlight node.
> >
> > Ref:
> > https://www.kernel.org/doc/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
> >
> 
> The pwm-backlight binding specifies which pwm the backlight driver
> should use, and how to use it.
> 
> I believe actually configuring the output pin for the pwm via pinctl
> belongs to the pwm binding.
> 
> Regards,
> 0Dan
> 
> >
> > Regards,
> > YH Huang
> >


--
To unsubscribe from this list: send the line "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/1] Add support for esdhc0 on Vybrid.

[Stefan Agner]

On 2015-07-09 08:07, Holger Schurig wrote:
>> Cory Tusar (1):
>>   ARM: dts: vfxxx: Include support for esdhc0 functionality.
>>
>>  arch/arm/boot/dts/vfxxx.dtsi | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> --
>> 2.3.6
> 
> Your patch looks empty.

This is a cover letter which provides overview over a whole patchset.
The patch is a separate reply message of this mail (PATCH 1/1). 

@Cory
However, it is unusual to use a cover letter when there is only a single
patch. If you want to add additional comments which should not be part
of the commit message, you can edit the patch and insert text after the
three dashes, just before the diffstat. This text won't be part of the
commit when applied later.

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

Re: [PATCH 0/1] Add support for esdhc0 on Vybrid.

[Holger Schurig]

> Cory Tusar (1):
>   ARM: dts: vfxxx: Include support for esdhc0 functionality.
>
>  arch/arm/boot/dts/vfxxx.dtsi | 11 +++
>  1 file changed, 11 insertions(+)
>
> --
> 2.3.6

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

Re: [PATCH v2 2/2] iio: light: add APDS9960 ALS + promixity driver

[Matt Ranostay]

On Tue, Jul 7, 2015 at 10:16 PM, Matt Ranostay  wrote:
> APDS9960 is a combination of ALS, proximity, and gesture sensors.
>
> This patch adds support for these functions along with gain control,
> integration time, and event thresholds.
>
> Signed-off-by: Matt Ranostay 
> ---
>  .../ABI/testing/sysfs-bus-iio-light-apds9960   |  128 +++
>  drivers/iio/light/Kconfig  |   12 +
>  drivers/iio/light/Makefile |1 +
>  drivers/iio/light/apds9960.c   | 1214 
> 
>  4 files changed, 1355 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-light-apds9960
>  create mode 100644 drivers/iio/light/apds9960.c
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-light-apds9960 
> b/Documentation/ABI/testing/sysfs-bus-iio-light-apds9960
> new file mode 100644
> index 000..010b8c8
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-iio-light-apds9960
> @@ -0,0 +1,128 @@
> +What:  /sys/bus/iio/devices/triggerX/name = "apds9960-gestureX"
> +KernelVersion: 4.2
> +Contact:   Matt Ranostay 
> +Description:
> +   The APDS9960 kernel module provides a trigger which enables
> +   the gesture engine that pushes motion data to the buffer when
> +   it becomes available.
> +
> +What   /sys/bus/iio/devices/iio:deviceX/in_proximity0_raw
> +Date:  July 2015
> +KernelVersion: 4.2
> +Contact:   Matt Ranostay 
> +Description:
> +   Get the non-gesture proximity sensor value.
> +
> +What   /sys/bus/iio/devices/iio:deviceX/in_proximity1_raw
> +Date:  July 2015
> +KernelVersion: 4.2
> +Contact:   Matt Ranostay 
> +Description:
> +   Get the UP gesture photodiode proximity value.
> +   Access is disabled to prevent the side effect of
> +   userspace clearing the hardware FIFO.
> +
> +What   /sys/bus/iio/devices/iio:deviceX/in_proximity2_raw
> +Date:  July 2015
> +KernelVersion: 4.2
> +Contact:   Matt Ranostay 
> +Description:
> +   Get the DOWN gesture photodiode proximity value.
> +   Access is disabled to prevent the side effect of
> +   userspace clearing the hardware FIFO.
> +
> +What   /sys/bus/iio/devices/iio:deviceX/in_proximity3_raw
> +Date:  July 2015
> +KernelVersion: 4.2
> +Contact:   Matt Ranostay 
> +Description:
> +   Get the LEFT gesture photodiode proximity value.
> +   Access is disabled to prevent the side effect of
> +   userspace clearing the hardware FIFO.
> +
> +What   /sys/bus/iio/devices/iio:deviceX/in_proximity4_raw
> +Date:  July 2015
> +KernelVersion: 4.2
> +Contact:   Matt Ranostay 
> +Description:
> +   Get the RIGHT gesture photodiode proximity value.
> +   Access is disabled to prevent the side effect of
> +   userspace clearing the hardware FIFO.
> +
> +What   /sys/bus/iio/devices/iio:deviceX/in_intensity_clear_raw
> +Date:  July 2015
> +KernelVersion: 4.2
> +Contact:   Matt Ranostay 
> +Description:
> +   Get the current unprocessed illuminance for the clear/ALS
> +   photodiode.
> +
> +What   /sys/bus/iio/devices/iio:deviceX/in_intensity_red_raw
> +Date:  July 2015
> +KernelVersion: 4.2
> +Contact:   Matt Ranostay 
> +Description:
> +   Get the current unprocessed illuminance value for the
> +   red light wavelength photodiode.
> +
> +What   /sys/bus/iio/devices/iio:deviceX/in_intensity_green_raw
> +Date:  July 2015
> +KernelVersion: 4.2
> +Contact:   Matt Ranostay 
> +Description:
> +   Get the current unprocessed illuminance value for the
> +   green light wavelength photodiode.
> +
> +What   /sys/bus/iio/devices/iio:deviceX/in_intensity_blue_raw
> +Date:  July 2015
> +KernelVersion: 4.2
> +Contact:   Matt Ranostay 
> +Description:
> +   Get the current unprocessed illuminance value for the
> +   blue light wavelength photodiode.
> +
> +What   /sys/bus/iio/devices/iio:deviceX/integration_time_available
> +Date:  July 2015
> +KernelVersion: 4.2
> +Contact:   Matt Ranostay 
> +Description:
> +   Provide allowed integration time values in fractions of a 
> second
> +   for the ALS + RGB sensor engines.
> +
> +What   /sys/bus/iio/devices/iio:deviceX/in_intensity_integration_time
> +Date:  July 2015
> +KernelVersion: 4.2
> +Contact:   Matt Ranostay 
> +Description:
> +   Set integration time in fractions of a second for the ALS + 
> RGB
> +   sensor engines.
> +
> +What   /sys/bus/iio/devices/iio:deviceX/proximity_scale_available
> +Date:  July 2015
> +KernelVersion: 4.2
> +Contact:   Matt Ranostay 
> +De

Re: [PATCH 2/2] arm64: dts: mediatek: add mt6795 support

[Mars Cheng]

> > +   chosen {
> > +   bootargs = "console=ttyS0,921600n8 earlyprintk";
> 
> PLease get rid of bootargs here; earlyprintk doesn't do anything on
> arm64 (it's earlycon these days), and you can specify the serial
> configuration in stdout-path, so please use that instead.
> 
Got it. Will remove bootargs & use stdout-path only.
> > +   stdout-path = &uart0;
> > +   };
> > +};
> > +
> > +&uart0 {
> > +   status = "okay";
> > +};
> > diff --git a/arch/arm64/boot/dts/mediatek/mt6795.dtsi 
> > b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
> > new file mode 100644
> > index 000..832be20
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
> > @@ -0,0 +1,164 @@
> > +/*
> > + * Copyright (c) 2015 MediaTek Inc.
> > + * Author: Mars.C 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> > +#include 
> > +
> > +/ {
> > +   compatible = "mediatek,mt6795";
> > +   interrupt-parent = <&sysirq>;
> > +   #address-cells = <2>;
> > +   #size-cells = <2>;
> > +
> > +   cpus {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   cpu0: cpu@0 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53";
> > +   reg = <0x000>;
> > +   };
> > +
> > +   cpu1: cpu@1 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53";
> > +   reg = <0x001>;
> > +   };
> 
> No enable-method? Does your FW patch that in?
This patch only provides single core to boot.The proper enable-method
for SMP boot is under discussion in our site. Will complete
enable-method when providing our solution to SMP boot in the other patch
set.
> 
> > +
> > +   cpu2: cpu@2 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53";
> > +   reg = <0x002>;
> > +   };
> > +
> > +   cpu3: cpu@3 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53";
> > +   reg = <0x003>;
> > +   };
> > +
> > +   cpu4: cpu@4 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53";
> > +   reg = <0x100>;
> > +   };
> 
> The unit-address should match the reg (e.g. this should be cpu@100).
Got it. Will fix this.
> 
> > +
> > +   cpu5: cpu@5 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53";
> > +   reg = <0x101>;
> > +   };
> > +
> > +   cpu6: cpu@6 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53";
> > +   reg = <0x102>;
> > +   };
> > +
> > +   cpu7: cpu@7 {
> > +   device_type = "cpu";
> > +   compatible = "arm,cortex-a53";
> > +   reg = <0x103>;
> > +   };
> > +   };
> > +
> > +   clocks {
> > +   system_clk: dummy13m {
> > +   compatible = "fixed-clock";
> > +   clock-frequency = <1300>;
> > +   #clock-cells = <0>;
> > +   };
> > +
> > +   rtc_clk: dummy32k {
> > +   compatible = "fixed-clock";
> > +   clock-frequency = <32000>;
> > +   #clock-cells = <0>;
> > +   };
> > +
> > +   uart_clk: dummy26m {
> > +   compatible = "fixed-clock";
> > +   clock-frequency = <2600>;
> > +   #clock-cells = <0>;
> > +   };
> > +   };
> 
> Get rid of the clocks node and place these directly under the root node.
Got it. Will fix it.
> 
> > +
> > +   timer {
> > +   compatible = "arm,armv8-timer";
> > +   interrupt-parent = <&gic>;
> > +   interrupts =  > +(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + > +(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + > +(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
> > + > +(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>;
> > +   };
> 
> The mask is wrong.
They should be GIC_CPU_MASK_SIMPLE(8). Will fix these.

Thanks for your suggestions.
> 
> Thanks,
> Mark.


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

Re: [PATCH v5 2/2] cpufreq: mediatek: Add MT8173 cpufreq driver

[Viresh Kumar]

On 09-07-15, 09:55, Pi-Cheng Chen wrote:
> That's what I did in previous version. But the reason I use the device-
> driver model is to handle the defer probing issue. Since there's no
> arch/arm64/mach-mediatek/ directory to hold the device registration
> code anymore, no device tree way to match cpufreq driver
> (please correct me if there's any), and initcall seems not handle
> defer probing either, therefore I put both device and driver
> registration in this function. I know it's crappy. :(
> Do you have any suggestion to do it right and handle defer probing
> properly?

Sounds reasonable. Just add proper comment in code to explain that.

-- 
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 v7 0/3] Add arm pl353 smc nand driver for xilinx zynq soc

[Michal Simek]

On 07/08/2015 09:40 PM, Josh Cartwright wrote:
> On Mon, Jun 08, 2015 at 11:38:35PM +0530, Punnaiah Choudary Kalluri wrote:
>> The following patches add arm pl353 static memory controller driver for
>> xilinx zynq soc. The arm pl353 smc supports two interfaces i.e nand and
>> nor/sram memory interfaces. The current implementation supports only a
>> single SMC instance and nand specific configuration.
> 
> What's the integration plan for this guy?  Looks like we missed 4.2.
> It'd be swell to get have NAND support land for Zynq in 4.3.
> 
> Assuming there is nothing else holding it back:
> 
> Brian- I'm assuming you'll want to take this through your tree.
> 
> It looks like most of the stuff in drivers/memory have historically gone
> through arm-soc/drivers, Michal- does it make sense for you to pick up
> http://lkml.kernel.org/r/1433786857-32575-1-git-send-email-punn...@xilinx.com?

I am happy to take this via zynq tree and arm-soc tree if this is the
right way.

Josh: Also none can stop you to give us you ACK or Tested-by line.

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

Re: [PATCH v4 1/3] dt-bindings: pwm: add MediaTek display PWM bindings

[Daniel Kurtz]

On Thu, Jul 9, 2015 at 10:45 AM, YH Huang  wrote:
>
> On Wed, 2015-07-08 at 20:11 +0800, Daniel Kurtz wrote:
> > On Mon, Jul 6, 2015 at 9:29 PM, YH Huang  wrote:
> > > Document the device-tree binding of MediatTek display PWM.
> > > The PWM has one channel to control the backlight brightness for display.
> > > It supports MT8173 and MT6595.
> > >
> > > Signed-off-by: YH Huang 
> > > ---
> > >  .../devicetree/bindings/pwm/pwm-mtk-disp.txt   | 24 
> > > ++
> > >  1 file changed, 24 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > >
> > > diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt 
> > > b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > > new file mode 100644
> > > index 000..757b974
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > > @@ -0,0 +1,24 @@
> > > +MediaTek display PWM controller
> > > +
> > > +Required properties:
> > > + - compatible: should be "mediatek,-disp-pwm"
> > > +   - "mediatek,mt8173-disp-pwm": found on mt8173 SoC
> > > +   - "mediatek,mt6595-disp-pwm": found on mt6595 SoC
> > > + - reg: physical base address and length of the controller's registers
> > > + - #pwm-cells: must be 2. See pwm.txt in this directory for a 
> > > description of
> > > +   the cell format
> > > + - clocks: phandle and clock specifier of the PWM reference clock
> > > + - clock-names: must contain the following
> > > +   - "main": clock used to generate PWM signals
> > > +   - "mm": sync signals from the modules of mmsys
> > > +
> > > +Example:
> > > +   pwm0: pwm@1401e000 {
> > > +   compatible = "mediatek,mt8173-disp-pwm",
> > > +"mediatek,mt6595-disp-pwm";
> > > +   reg = <0 0x1401e000 0 0x1000>;
> > > +   #pwm-cells = <2>;
> > > +   clocks = <&mmsys CLK_MM_DISP_PWM026M>,
> > > +<&mmsys CLK_MM_DISP_PWM0MM>;
> > > +   clock-names = "main", "mm";
> >
> > Should we include the pinctrl settings here to enable the PWM output?
> >
>
> Since we use pwm-backlight driver to control backlight, we should enable
> PWM output in the backlight node.
>
> Ref:
> https://www.kernel.org/doc/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
>

The pwm-backlight binding specifies which pwm the backlight driver
should use, and how to use it.

I believe actually configuring the output pin for the pwm via pinctl
belongs to the pwm binding.

Regards,
0Dan

>
> Regards,
> YH Huang
>
--
To unsubscribe from this list: send the line "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 01/11] soc: qcom: Add device tree binding for SMEM

[Andy Gross]

On Wed, Jul 08, 2015 at 04:56:34PM -0700, Stephen Boyd wrote:
> On 06/26/2015 02:50 PM, bj...@kryo.se wrote:
> > += EXAMPLE
> > +The following example shows the SMEM setup for MSM8974, with a main SMEM 
> > region
> > +at 0xfa0 and an auxiliary region at 0xfc428000:
> > +
> > +   reserved-memory {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   ranges;
> > +
> > +   smem_region: smem@fa0 {
> > +   reg = <0xfa0 0x20>;
> > +   no-map;
> > +   };
> > +   };
> > +
> > +   smem@fa0 {
> 
> This should be smem@fc428000 matching the first reg property. It's weird
> though, because if smem is using a secondary region it will be under the
> SoC node and have a reg property. Otherwise it would be directly under
> the root node and only have a memory-region. It would be nice if we
> could somehow move the rpm message ram (0xfc428000) into the
> reserved-memory node so that we could use memory-region for both regions.

The memory-region is just used to describe 'real' memory.  The RPM message is IO
memory and part of the SOC.  Thats my take at least.

> 
> > +   compatible = "qcom,smem";
> > +
> > +   memory-region = <&smem_region>;
> > +   reg = <0xfc428000 0x4000>;
> > +
> > +   hwlocks = <&tcsr_mutex 3>;
> > +   };

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

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

[PATCH v2] arm64: dts: mt8173: Add afe device node

[Koro Chen]

This adds afe (audio front end) device node to the MT8173 dtsi file.

Signed-off-by: Koro Chen 
---
This patch is based on Matthias's tree:
https://github.com/mbgg/linux-mediatek
branch: v4.2-next/arm64

Changes since v1:
- change node name to afe: audio-controller@1122
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 0696f8f..ce9255a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "mt8173-pinfunc.h"
 
@@ -393,6 +394,37 @@
#size-cells = <0>;
status = "disabled";
};
+
+   afe: audio-controller@1122  {
+   compatible = "mediatek,mt8173-afe-pcm";
+   reg = <0 0x1122 0 0x1000>;
+   interrupts = ;
+   power-domains = <&scpsys MT8173_POWER_DOMAIN_AUDIO>;
+   clocks = <&infracfg CLK_INFRA_AUDIO>,
+<&topckgen CLK_TOP_AUDIO_SEL>,
+<&topckgen CLK_TOP_AUD_INTBUS_SEL>,
+<&topckgen CLK_TOP_APLL1_DIV0>,
+<&topckgen CLK_TOP_APLL2_DIV0>,
+<&topckgen CLK_TOP_I2S0_M_SEL>,
+<&topckgen CLK_TOP_I2S1_M_SEL>,
+<&topckgen CLK_TOP_I2S2_M_SEL>,
+<&topckgen CLK_TOP_I2S3_M_SEL>,
+<&topckgen CLK_TOP_I2S3_B_SEL>;
+   clock-names = "infra_sys_audio_clk",
+ "top_pdn_audio",
+ "top_pdn_aud_intbus",
+ "bck0",
+ "bck1",
+ "i2s0_m",
+ "i2s1_m",
+ "i2s2_m",
+ "i2s3_m",
+ "i2s3_b";
+   assigned-clocks = <&topckgen CLK_TOP_AUD_1_SEL>,
+ <&topckgen CLK_TOP_AUD_2_SEL>;
+   assigned-clock-parents = <&topckgen CLK_TOP_APLL1>,
+<&topckgen CLK_TOP_APLL2>;
+   };
};
 };
 
-- 
1.8.1.1.dirty

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

[PATCH V4 5/7] i2c: qup: Add bam dma capabilities

[Sricharan R]

QUP cores can be attached to a BAM module, which acts as a dma engine for the
QUP core. When DMA with BAM is enabled, the BAM consumer pipe transmitted data
is written to the output FIFO and the BAM producer pipe received data is read
from the input FIFO.

With BAM capabilities, qup-i2c core can transfer more than 256 bytes, without a
'stop' which is not possible otherwise.

Signed-off-by: Sricharan R 
---
 drivers/i2c/busses/i2c-qup.c | 431 +--
 1 file changed, 415 insertions(+), 16 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index c0757d9..810b021 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -24,6 +24,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 /* QUP Registers */
 #define QUP_CONFIG 0x000
@@ -33,6 +38,7 @@
 #define QUP_OPERATIONAL0x018
 #define QUP_ERROR_FLAGS0x01c
 #define QUP_ERROR_FLAGS_EN 0x020
+#define QUP_OPERATIONAL_MASK   0x028
 #define QUP_HW_VERSION 0x030
 #define QUP_MX_OUTPUT_CNT  0x100
 #define QUP_OUT_FIFO_BASE  0x110
@@ -53,6 +59,7 @@
 
 #define QUP_STATE_VALIDBIT(2)
 #define QUP_I2C_MAST_GEN   BIT(4)
+#define QUP_I2C_FLUSH  BIT(6)
 
 #define QUP_OPERATIONAL_RESET  0x000ff0
 #define QUP_I2C_STATUS_RESET   0xfc
@@ -78,7 +85,10 @@
 
 /* Packing/Unpacking words in FIFOs, and IO modes */
 #define QUP_OUTPUT_BLK_MODE(1 << 10)
+#define QUP_OUTPUT_BAM_MODE(3 << 10)
 #define QUP_INPUT_BLK_MODE (1 << 12)
+#define QUP_INPUT_BAM_MODE (3 << 12)
+#define QUP_BAM_MODE   (QUP_OUTPUT_BAM_MODE | QUP_INPUT_BAM_MODE)
 #define QUP_UNPACK_EN  BIT(14)
 #define QUP_PACK_ENBIT(15)
 
@@ -95,6 +105,8 @@
 #define QUP_TAG_DATA   (2 << 8)
 #define QUP_TAG_STOP   (3 << 8)
 #define QUP_TAG_REC(4 << 8)
+#define QUP_BAM_INPUT_EOT  0x93
+#define QUP_BAM_FLUSH_STOP 0x96
 
 /* QUP v2 tags */
 #define QUP_TAG_V2_START   0x81
@@ -115,6 +127,12 @@
 #define ONE_BYTE   0x1
 #define QUP_I2C_MX_CONFIG_DURING_RUN   BIT(31)
 
+#define MX_TX_RX_LEN   SZ_64K
+#define MX_BLOCKS  (MX_TX_RX_LEN / QUP_READ_LIMIT)
+
+/* Max timeout in ms for 32k bytes */
+#define TOUT_MAX   300
+
 struct qup_i2c_block {
int count;
int pos;
@@ -125,6 +143,23 @@ struct qup_i2c_block {
int config_run;
 };
 
+struct qup_i2c_tag {
+   u8 *start;
+   dma_addr_t addr;
+};
+
+struct qup_i2c_bam_rx {
+   struct  qup_i2c_tag scratch_tag;
+   struct  dma_chan *dma_rx;
+   struct  scatterlist *sg_rx;
+};
+
+struct qup_i2c_bam_tx {
+   struct  qup_i2c_tag footer_tag;
+   struct  dma_chan *dma_tx;
+   struct  scatterlist *sg_tx;
+};
+
 struct qup_i2c_dev {
struct device   *dev;
void __iomem*base;
@@ -154,14 +189,20 @@ struct qup_i2c_dev {
 
int (*qup_i2c_write_one)(struct qup_i2c_dev *qup,
 struct i2c_msg *msg);
+   int (*qup_i2c_read_one)(struct qup_i2c_dev *qup,
+   struct i2c_msg *msg);
+
/* Current i2c_msg in i2c_msgs */
int cmsg;
/* total num of i2c_msgs */
int num;
 
-   int (*qup_i2c_read_one)(struct qup_i2c_dev *qup,
-   struct i2c_msg *msg);
-
+   /* dma parameters */
+   boolis_dma;
+   struct  dma_pool *dpool;
+   struct  qup_i2c_tag start_tag;
+   struct  qup_i2c_bam_rx brx;
+   struct  qup_i2c_bam_tx btx;
struct completion   xfer;
 };
 
@@ -238,6 +279,14 @@ static int qup_i2c_poll_state(struct qup_i2c_dev *qup, u32 
req_state)
return qup_i2c_poll_state_mask(qup, req_state, QUP_STATE_MASK);
 }
 
+static void qup_i2c_flush(struct qup_i2c_dev *qup)
+{
+   u32 val = readl(qup->base + QUP_STATE);
+
+   val |= QUP_I2C_FLUSH;
+   writel(val, qup->base + QUP_STATE);
+}
+
 static int qup_i2c_poll_state_valid(struct qup_i2c_dev *qup)
 {
return qup_i2c_poll_state_mask(qup, 0, 0);
@@ -437,12 +486,15 @@ static int qup_i2c_get_data_len(struct qup_i2c_dev *qup)
 }
 
 static int qup_i2c_get_tags(u8 *tags, struct qup_i2c_dev *qup,
-   struct i2c_msg *msg)
+   struct i2c_msg *msg, int is_dma)
 {
u16 addr = (msg->addr << 1) | ((msg->flags & I2C_M_RD) == I2C_M_RD);
int len = 0;
int data_len;
 
+   int last = (qup->blk.pos == (qup->blk.count - 1)) &&
+   (qup->cmsg == (qup->num - 1));
+
if (qup->blk.pos == 0) {
tags[len++] = QUP_TAG_V2_START;
tags[len++] = addr & 0xff;
@@ -452,8 +504,7 

Re: [PATCH v2] power_supply: rt9455_charger: Properly notify userspace about charging events

[Sebastian Reichel]

Hi,

On Tue, Jul 07, 2015 at 03:25:53PM +0300, Anda-Maria Nicolae wrote:
> Charging events this patch refers to are:
> - charger is connected to/disconnected from the power source
> - battery is reconnected to the charger, after it was absent.
> 
> When the charger is connected to/disconnected from the power source, CHRVPI
> interrupt occurs and PWR_RDY bit is either set or cleared. PWR_RDY bit is
> updated after 1-2 seconds CHRVPI interrupt has occurred.
> power_supply_changed() should be called after PWR_RDY bit is updated.
> /sys/class/power_supply/rt9455-charger/online file displays the value of
> PWR_RDY bit.
> This way, if the userspace is notified that a charging event has occurred
> and the userspace reads /sys/class/power_supply/rt9455-charger/online file,
> this file is properly updated when the userspace reads it.
> This is the reason why power_supply_changed() is called in
> rt9455_pwr_rdy_work_callback(), instead of being called in interrupt
> handler.
> 
> Since no interrupt is triggered when the battery is reconnected to the
> charger, the userspace is never notified that the battery is reconnected.
> This is why power_supply_changed() is called in
> rt9455_max_charging_time_work_callback(), so that the userspace is notified
> that the battery is reconnected.
> 
> Signed-off-by: Anda-Maria Nicolae 

Thanks, queued with Kzrysztof's Reviewed-By.

-- Sebastian


signature.asc
Description: Digital signature

[PATCH V4 6/7] dts: msm8974: Add blsp2_bam dma node

[Sricharan R]

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-msm8974.dtsi | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 37b47b5..f138202 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -1,6 +1,6 @@
 /dts-v1/;
 
-#include 
+#include 
 #include 
 #include "skeleton.dtsi"
 
@@ -301,5 +301,15 @@
interrupt-controller;
#interrupt-cells = <4>;
};
+
+   blsp2_dma: dma-controller@f9944000 {
+   compatible = "qcom,bam-v1.4.0";
+   reg = <0xf9944000 0x19000>;
+   interrupts = ;
+   clocks = <&gcc GCC_BLSP2_AHB_CLK>;
+   clock-names = "bam_clk";
+   #dma-cells = <1>;
+   qcom,ee = <0>;
+   };
};
 };
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

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

[PATCH V4 2/7] qup: i2c: factor out common code for reuse

[Sricharan R]

The qup_i2c_write/read_one functions can be split to have
the common initialization code and function to loop around
the data bytes separately. This way the initialization code
can be reused while adding v2 tags functionality.

Signed-off-by: Sricharan R 
---
 drivers/i2c/busses/i2c-qup.c | 147 +--
 1 file changed, 87 insertions(+), 60 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 81ed120..131dc28 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -324,53 +324,72 @@ static int qup_i2c_issue_write(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
return ret;
 }
 
-static int qup_i2c_write_one(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+static int qup_i2c_wait_for_complete(struct qup_i2c_dev *qup,
+struct i2c_msg *msg)
 {
unsigned long left;
-   int ret;
-
-   qup->msg = msg;
-   qup->pos = 0;
+   int ret = 0;
 
-   enable_irq(qup->irq);
+   left = wait_for_completion_timeout(&qup->xfer, HZ);
+   if (!left) {
+   writel(1, qup->base + QUP_SW_RESET);
+   ret = -ETIMEDOUT;
+   }
 
-   qup_i2c_set_write_mode(qup, msg);
+   if (qup->bus_err || qup->qup_err) {
+   if (qup->bus_err & QUP_I2C_NACK_FLAG) {
+   dev_err(qup->dev, "NACK from %x\n", msg->addr);
+   ret = -EIO;
+   }
+   }
 
-   ret = qup_i2c_change_state(qup, QUP_RUN_STATE);
-   if (ret)
-   goto err;
+   return ret;
+}
 
-   writel(qup->clk_ctl, qup->base + QUP_I2C_CLK_CTL);
+static int qup_i2c_write_one(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+{
+   int ret = 0;
 
do {
ret = qup_i2c_change_state(qup, QUP_PAUSE_STATE);
if (ret)
-   goto err;
+   return ret;
 
ret = qup_i2c_issue_write(qup, msg);
if (ret)
-   goto err;
+   return ret;
 
ret = qup_i2c_change_state(qup, QUP_RUN_STATE);
if (ret)
-   goto err;
-
-   left = wait_for_completion_timeout(&qup->xfer, HZ);
-   if (!left) {
-   writel(1, qup->base + QUP_SW_RESET);
-   ret = -ETIMEDOUT;
-   goto err;
-   }
+   return ret;
 
-   if (qup->bus_err || qup->qup_err) {
-   if (qup->bus_err & QUP_I2C_NACK_FLAG)
-   dev_err(qup->dev, "NACK from %x\n", msg->addr);
-   ret = -EIO;
-   goto err;
-   }
+   ret = qup_i2c_wait_for_complete(qup, msg);
+   if (ret)
+   return ret;
} while (qup->pos < msg->len);
 
-   /* Wait for the outstanding data in the fifo to drain */
+   return ret;
+}
+
+static int qup_i2c_write(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+{
+   int ret;
+
+   qup->msg = msg;
+   qup->pos = 0;
+   enable_irq(qup->irq);
+   qup_i2c_set_write_mode(qup, msg);
+
+   ret = qup_i2c_change_state(qup, QUP_RUN_STATE);
+   if (ret)
+   goto err;
+
+   writel(qup->clk_ctl, qup->base + QUP_I2C_CLK_CTL);
+
+   ret = qup_i2c_write_one(qup, msg);
+   if (ret)
+   goto err;
+
ret = qup_i2c_wait_ready(qup, QUP_OUT_NOT_EMPTY, RESET_BIT, ONE_BYTE);
 
 err:
@@ -436,51 +455,59 @@ static int qup_i2c_read_fifo(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
 
 static int qup_i2c_read_one(struct qup_i2c_dev *qup, struct i2c_msg *msg)
 {
-   unsigned long left;
-   int ret;
+   int ret = 0;
 
-   qup->msg = msg;
-   qup->pos  = 0;
+   /*
+* The QUP block will issue a NACK and STOP on the bus when reaching
+* the end of the read, the length of the read is specified as one byte
+* which limits the possible read to 256 (QUP_READ_LIMIT) bytes.
+*/
+   if (msg->len > QUP_READ_LIMIT) {
+   dev_err(qup->dev, "HW not capable of reads over %d bytes\n",
+   QUP_READ_LIMIT);
+   return -EINVAL;
+   }
 
-   enable_irq(qup->irq);
+   ret = qup_i2c_change_state(qup, QUP_PAUSE_STATE);
+   if (ret)
+   return ret;
 
-   qup_i2c_set_read_mode(qup, msg->len);
+   qup_i2c_issue_read(qup, msg);
 
ret = qup_i2c_change_state(qup, QUP_RUN_STATE);
if (ret)
-   goto err;
+   return ret;
 
-   writel(qup->clk_ctl, qup->base + QUP_I2C_CLK_CTL);
+   do {
+   ret = qup_i2c_wait_for_complete(qup, msg);
+   if (ret)
+   return ret;
+   ret = qup_i2c_read_fifo(qup, msg);
+   if (ret)
+   re

[PATCH V4 3/7] i2c: qup: Add V2 tags support

[Sricharan R]

QUP from version 2.1.1 onwards, supports a new format of
i2c command tags. Tag codes instructs the controller to
perform a operation like read/write. This new tagging version
supports bam dma and transfers of more than 256 bytes without 'stop'
in between. Adding the support for the same.

For each block a data_write/read tag and data_len tag is added to
the output fifo. For the final block of data write_stop/read_stop
tag is used.

Signed-off-by: Andy Gross 
Signed-off-by: Sricharan R 
---
 drivers/i2c/busses/i2c-qup.c | 330 ++-
 1 file changed, 323 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 131dc28..a4e20d9 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -43,6 +43,8 @@
 #define QUP_I2C_CLK_CTL0x400
 #define QUP_I2C_STATUS 0x404
 
+#define QUP_I2C_MASTER_GEN 0x408
+
 /* QUP States and reset values */
 #define QUP_RESET_STATE0
 #define QUP_RUN_STATE  1
@@ -69,6 +71,8 @@
 #define QUP_CLOCK_AUTO_GATEBIT(13)
 #define I2C_MINI_CORE  (2 << 8)
 #define I2C_N_VAL  15
+#define I2C_N_VAL_V2   7
+
 /* Most significant word offset in FIFO port */
 #define QUP_MSW_SHIFT  (I2C_N_VAL + 1)
 
@@ -79,6 +83,7 @@
 #define QUP_PACK_ENBIT(15)
 
 #define QUP_REPACK_EN  (QUP_UNPACK_EN | QUP_PACK_EN)
+#define QUP_V2_TAGS_EN 1
 
 #define QUP_OUTPUT_BLOCK_SIZE(x)(((x) >> 0) & 0x03)
 #define QUP_OUTPUT_FIFO_SIZE(x)(((x) >> 2) & 0x07)
@@ -91,6 +96,13 @@
 #define QUP_TAG_STOP   (3 << 8)
 #define QUP_TAG_REC(4 << 8)
 
+/* QUP v2 tags */
+#define QUP_TAG_V2_START   0x81
+#define QUP_TAG_V2_DATAWR  0x82
+#define QUP_TAG_V2_DATAWR_STOP 0x83
+#define QUP_TAG_V2_DATARD  0x85
+#define QUP_TAG_V2_DATARD_STOP 0x87
+
 /* Status, Error flags */
 #define I2C_STATUS_WR_BUFFER_FULL  BIT(0)
 #define I2C_STATUS_BUS_ACTIVE  BIT(8)
@@ -102,6 +114,15 @@
 #define RESET_BIT  0x0
 #define ONE_BYTE   0x1
 
+struct qup_i2c_block {
+   int count;
+   int pos;
+   int tx_tag_len;
+   int rx_tag_len;
+   int data_len;
+   u8  tags[6];
+};
+
 struct qup_i2c_dev {
struct device   *dev;
void __iomem*base;
@@ -117,6 +138,7 @@ struct qup_i2c_dev {
int in_blk_sz;
 
unsigned long   one_byte_t;
+   struct qup_i2c_blockblk;
 
struct i2c_msg  *msg;
/* Current posion in user message buffer */
@@ -126,6 +148,14 @@ struct qup_i2c_dev {
/* QUP core errors */
u32 qup_err;
 
+   int use_v2_tags;
+
+   int (*qup_i2c_write_one)(struct qup_i2c_dev *qup,
+struct i2c_msg *msg);
+
+   int (*qup_i2c_read_one)(struct qup_i2c_dev *qup,
+   struct i2c_msg *msg);
+
struct completion   xfer;
 };
 
@@ -266,7 +296,7 @@ static int qup_i2c_wait_ready(struct qup_i2c_dev *qup, int 
op, bool val,
 static void qup_i2c_set_write_mode(struct qup_i2c_dev *qup, struct i2c_msg 
*msg)
 {
/* Number of entries to shift out, including the start */
-   int total = msg->len + 1;
+   int total = msg->len + qup->blk.tx_tag_len;
 
if (total < qup->out_fifo_sz) {
/* FIFO mode */
@@ -324,6 +354,134 @@ static int qup_i2c_issue_write(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
return ret;
 }
 
+static void qup_i2c_get_blk_data(struct qup_i2c_dev *qup,
+struct i2c_msg *msg)
+{
+   memset(&qup->blk, 0, sizeof(qup->blk));
+
+   if (!qup->use_v2_tags) {
+   if (!(msg->flags & I2C_M_RD))
+   qup->blk.tx_tag_len = 1;
+   return;
+   }
+
+   qup->blk.data_len = msg->len;
+   qup->blk.count = (msg->len + QUP_READ_LIMIT - 1) / QUP_READ_LIMIT;
+
+   /* 4 bytes for first block and 2 writes for rest */
+   qup->blk.tx_tag_len = 4 + (qup->blk.count - 1) * 2;
+
+   /* There are 2 tag bytes that are read in to fifo for every block */
+   if (msg->flags & I2C_M_RD)
+   qup->blk.rx_tag_len = qup->blk.count * 2;
+}
+
+static int qup_i2c_send_data(struct qup_i2c_dev *qup, int tlen, u8 *tbuf,
+int dlen, u8 *dbuf)
+{
+   u32 val = 0, idx = 0, pos = 0, i = 0, t;
+   int  len = tlen + dlen;
+   u8 *buf = tbuf;
+   int ret = 0;
+
+   while (len > 0) {
+   ret = qup_i2c_wait_ready(qup, QUP_OUT_FULL,
+RESET_BIT, 4 * ONE_BYTE);
+   if (ret) {
+   dev_err(qup->dev, "timeout for fifo out full");
+   return ret;
+   }
+
+ 

[PATCH V4 7/7] dts: msm8974: Add dma channels for blsp2_i2c1 node

[Sricharan R]

Signed-off-by: Sricharan R 
---
 arch/arm/boot/dts/qcom-msm8974.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index f138202..17dcda3 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -284,6 +284,8 @@
clock-names = "core", "iface";
#address-cells = <1>;
#size-cells = <0>;
+   dmas = <&blsp2_dma 20>, <&blsp2_dma 21>;
+   dma-names = "tx", "rx";
};
 
spmi_bus: spmi@fc4cf000 {
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

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

[PATCH V4 0/7] i2c: qup: Add support for v2 tags and bam dma

[Sricharan R]

QUP from version 2.1.1 onwards, supports a new format of i2c command tags.
Tag codes instructs the controller to perform a operation like read/write.
This new tagging version supports and is required for adding bam dma
capabilities. V2 tags supports transfer of more than 256 bytes in a single
i2c transaction. Also adding bam dma support facilitates transferring each
i2c_msg in i2c_msgs without a 'stop' bit in between which is required for some
of the clients.

Tested this series on apq8074 dragon board eeprom client on i2c bus1

[V4] Added a patch to factor out some common code.
 Removed support for freq > 400KHZ as per comments.
 Addressed comments from Ivan T. Ivanov to keep the code for
 V2 support in a separate path. 
 Changed the authorship of V2 tags support patch.

[V3] Added support to coalesce each i2c_msg in i2c_msgs for fifo and
 block mode in Patch 2. Also addressed further code comments.

 http://comments.gmane.org/gmane.linux.drivers.i2c/22497

[V2] Addressed comments from Ivan T. Ivanov, Andy Gross [v1] Initial Version

Sricharan R (7):
  i2c: qup: Change qup_wait_writeready function to use for all timeouts
  qup: i2c: factor out common code for reuse
  i2c: qup: Add V2 tags support
  i2c: qup: Transfer each i2c_msg in i2c_msgs without a stop bit
  i2c: qup: Add bam dma capabilities
  dts: msm8974: Add blsp2_bam dma node
  dts: msm8974: Add dma channels for blsp2_i2c1 node

 arch/arm/boot/dts/qcom-msm8974.dtsi |  14 +-
 drivers/i2c/busses/i2c-qup.c| 943 +---
 2 files changed, 880 insertions(+), 77 deletions(-)

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "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 4/7] i2c: qup: Transfer each i2c_msg in i2c_msgs without a stop bit

[Sricharan R]

The definition of i2c_msg says that

"If this is the last message in a group, it is followed by a STOP.
Otherwise it is followed by the next @i2c_msg transaction segment,
beginning with a (repeated) START"

So the expectation is that there is no 'STOP' bit inbetween individual
i2c_msg segments with repeated 'START'. The QUP i2c hardware has no way
to inform that there should not be a 'STOP' at the end of transaction.
The only way to implement this is to coalesce all the i2c_msg in i2c_msgs
in to one transaction and transfer them. Adding the support for the same.

This is required for some clients like touchscreen which keeps
incrementing counts across individual transfers and 'STOP' bit inbetween
resets the counter, which is not required.

This patch adds the support in non-dma mode.

Signed-off-by: Sricharan R 
---
 drivers/i2c/busses/i2c-qup.c | 40 ++--
 1 file changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index a4e20d9..c0757d9 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -113,6 +113,7 @@
 #define SET_BIT0x1
 #define RESET_BIT  0x0
 #define ONE_BYTE   0x1
+#define QUP_I2C_MX_CONFIG_DURING_RUN   BIT(31)
 
 struct qup_i2c_block {
int count;
@@ -121,6 +122,7 @@ struct qup_i2c_block {
int rx_tag_len;
int data_len;
u8  tags[6];
+   int config_run;
 };
 
 struct qup_i2c_dev {
@@ -152,6 +154,10 @@ struct qup_i2c_dev {
 
int (*qup_i2c_write_one)(struct qup_i2c_dev *qup,
 struct i2c_msg *msg);
+   /* Current i2c_msg in i2c_msgs */
+   int cmsg;
+   /* total num of i2c_msgs */
+   int num;
 
int (*qup_i2c_read_one)(struct qup_i2c_dev *qup,
struct i2c_msg *msg);
@@ -278,7 +284,8 @@ static int qup_i2c_wait_ready(struct qup_i2c_dev *qup, int 
op, bool val,
status = readl(qup->base + QUP_I2C_STATUS);
 
if (((opflags & op) >> shift) == val) {
-   if (op == QUP_OUT_NOT_EMPTY) {
+   if ((op == QUP_OUT_NOT_EMPTY) &&
+   (qup->cmsg == (qup->num - 1))) {
if (!(status & I2C_STATUS_BUS_ACTIVE))
return 0;
} else {
@@ -301,12 +308,14 @@ static void qup_i2c_set_write_mode(struct qup_i2c_dev 
*qup, struct i2c_msg *msg)
if (total < qup->out_fifo_sz) {
/* FIFO mode */
writel(QUP_REPACK_EN, qup->base + QUP_IO_MODE);
-   writel(total, qup->base + QUP_MX_WRITE_CNT);
+   writel(total | qup->blk.config_run,
+  qup->base + QUP_MX_WRITE_CNT);
} else {
/* BLOCK mode (transfer data on chunks) */
writel(QUP_OUTPUT_BLK_MODE | QUP_REPACK_EN,
   qup->base + QUP_IO_MODE);
-   writel(total, qup->base + QUP_MX_OUTPUT_CNT);
+   writel(total | qup->blk.config_run,
+  qup->base + QUP_MX_OUTPUT_CNT);
}
 }
 
@@ -374,6 +383,9 @@ static void qup_i2c_get_blk_data(struct qup_i2c_dev *qup,
/* There are 2 tag bytes that are read in to fifo for every block */
if (msg->flags & I2C_M_RD)
qup->blk.rx_tag_len = qup->blk.count * 2;
+
+   if (qup->cmsg)
+   qup->blk.config_run = QUP_I2C_MX_CONFIG_DURING_RUN;
 }
 
 static int qup_i2c_send_data(struct qup_i2c_dev *qup, int tlen, u8 *tbuf,
@@ -440,7 +452,8 @@ static int qup_i2c_get_tags(u8 *tags, struct qup_i2c_dev 
*qup,
}
 
/* Send _STOP commands for the last block */
-   if (qup->blk.pos == (qup->blk.count - 1)) {
+   if (qup->blk.pos == (qup->blk.count - 1)
+   && (qup->cmsg == (qup->num - 1))) {
if (msg->flags & I2C_M_RD)
tags[len++] = QUP_TAG_V2_DATARD_STOP;
else
@@ -571,7 +584,6 @@ static int qup_i2c_write(struct qup_i2c_dev *qup, struct 
i2c_msg *msg)
goto err;
 
ret = qup_i2c_wait_ready(qup, QUP_OUT_NOT_EMPTY, RESET_BIT, ONE_BYTE);
-
 err:
disable_irq(qup->irq);
qup->msg = NULL;
@@ -584,18 +596,19 @@ static void qup_i2c_set_read_mode(struct qup_i2c_dev 
*qup, int len)
int tx_len = qup->blk.tx_tag_len;
 
len += qup->blk.rx_tag_len;
+   tx_len |= qup->blk.config_run;
 
if (len < qup->in_fifo_sz) {
/* FIFO mode */
writel(QUP_REPACK_EN, qup->base + QUP_IO_MODE);
-   writel(len, qup->base + QUP_MX_READ_CNT);
writel(tx_len, qup->base + QUP_MX_WRITE_CNT);
+   writel(len | qup->blk.config_run, qup->base + QUP_MX_READ_CNT);
} else {
/* BLOCK mo

[PATCH V4 1/7] i2c: qup: Change qup_wait_writeready function to use for all timeouts

[Sricharan R]

qup_wait_writeready waits only on a output fifo empty event.
Change the same function to accept the event and data length
to wait as parameters. This way the same function can be used for
timeouts in otherplaces as well.

Signed-off-by: Sricharan R 
---
 drivers/i2c/busses/i2c-qup.c | 67 +++-
 1 file changed, 48 insertions(+), 19 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index fdcbdab..81ed120 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -98,6 +98,9 @@
 #define QUP_STATUS_ERROR_FLAGS 0x7c
 
 #define QUP_READ_LIMIT 256
+#define SET_BIT0x1
+#define RESET_BIT  0x0
+#define ONE_BYTE   0x1
 
 struct qup_i2c_dev {
struct device   *dev;
@@ -221,26 +224,42 @@ static int qup_i2c_change_state(struct qup_i2c_dev *qup, 
u32 state)
return 0;
 }
 
-static int qup_i2c_wait_writeready(struct qup_i2c_dev *qup)
+/**
+ * qup_i2c_wait_ready - wait for a give number of bytes in tx/rx path
+ * @qup: The qup_i2c_dev device
+ * @op: The bit/event to wait on
+ * @val: value of the bit to wait on, 0 or 1
+ * @len: The length the bytes to be transferred
+ */
+static int qup_i2c_wait_ready(struct qup_i2c_dev *qup, int op, bool val,
+ int len)
 {
unsigned long timeout;
u32 opflags;
u32 status;
+   u32 shift = __ffs(op);
 
-   timeout = jiffies + HZ;
+   len *= qup->one_byte_t;
+   /* timeout after a wait of twice the max time */
+   timeout = jiffies + len * 4;
 
for (;;) {
opflags = readl(qup->base + QUP_OPERATIONAL);
status = readl(qup->base + QUP_I2C_STATUS);
 
-   if (!(opflags & QUP_OUT_NOT_EMPTY) &&
-   !(status & I2C_STATUS_BUS_ACTIVE))
-   return 0;
+   if (((opflags & op) >> shift) == val) {
+   if (op == QUP_OUT_NOT_EMPTY) {
+   if (!(status & I2C_STATUS_BUS_ACTIVE))
+   return 0;
+   } else {
+   return 0;
+   }
+   }
 
if (time_after(jiffies, timeout))
return -ETIMEDOUT;
 
-   usleep_range(qup->one_byte_t, qup->one_byte_t * 2);
+   usleep_range(len, len * 2);
}
 }
 
@@ -261,13 +280,13 @@ static void qup_i2c_set_write_mode(struct qup_i2c_dev 
*qup, struct i2c_msg *msg)
}
 }
 
-static void qup_i2c_issue_write(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+static int qup_i2c_issue_write(struct qup_i2c_dev *qup, struct i2c_msg *msg)
 {
u32 addr = msg->addr << 1;
u32 qup_tag;
-   u32 opflags;
int idx;
u32 val;
+   int ret = 0;
 
if (qup->pos == 0) {
val = QUP_TAG_START | addr;
@@ -279,9 +298,10 @@ static void qup_i2c_issue_write(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
 
while (qup->pos < msg->len) {
/* Check that there's space in the FIFO for our pair */
-   opflags = readl(qup->base + QUP_OPERATIONAL);
-   if (opflags & QUP_OUT_FULL)
-   break;
+   ret = qup_i2c_wait_ready(qup, QUP_OUT_FULL, RESET_BIT,
+4 * ONE_BYTE);
+   if (ret)
+   return ret;
 
if (qup->pos == msg->len - 1)
qup_tag = QUP_TAG_STOP;
@@ -300,6 +320,8 @@ static void qup_i2c_issue_write(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
qup->pos++;
idx++;
}
+
+   return ret;
 }
 
 static int qup_i2c_write_one(struct qup_i2c_dev *qup, struct i2c_msg *msg)
@@ -325,7 +347,9 @@ static int qup_i2c_write_one(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
if (ret)
goto err;
 
-   qup_i2c_issue_write(qup, msg);
+   ret = qup_i2c_issue_write(qup, msg);
+   if (ret)
+   goto err;
 
ret = qup_i2c_change_state(qup, QUP_RUN_STATE);
if (ret)
@@ -347,7 +371,7 @@ static int qup_i2c_write_one(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
} while (qup->pos < msg->len);
 
/* Wait for the outstanding data in the fifo to drain */
-   ret = qup_i2c_wait_writeready(qup);
+   ret = qup_i2c_wait_ready(qup, QUP_OUT_NOT_EMPTY, RESET_BIT, ONE_BYTE);
 
 err:
disable_irq(qup->irq);
@@ -384,18 +408,19 @@ static void qup_i2c_issue_read(struct qup_i2c_dev *qup, 
struct i2c_msg *msg)
 }
 
 
-static void qup_i2c_read_fifo(struct qup_i2c_dev *qup, struct i2c_msg *msg)
+static int qup_i2c_read_fifo(struct qup_i2c_dev *qup, struct i2c_msg *msg)
 {
-   u32 opflags;
u32 val = 0;
int

Re: [PATCH 5/8] ARM: dts: add i.mx6ul pin function include file

[Shawn Guo]

On Wed, Jun 17, 2015 at 11:39:26PM +0800, frank...@freescale.com wrote:
> From: Frank Li 
> 
> add pin mux define file
> 
> Signed-off-by: Bai Ping 
> Signed-off-by: Anson Huang 
> Signed-off-by: Frank Li 
> ---
>  arch/arm/boot/dts/imx6ul-pinfunc.h | 938 
> +
>  1 file changed, 938 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6ul-pinfunc.h
> 
> diff --git a/arch/arm/boot/dts/imx6ul-pinfunc.h 
> b/arch/arm/boot/dts/imx6ul-pinfunc.h
> new file mode 100644
> index 000..1bb774b9
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6ul-pinfunc.h
> @@ -0,0 +1,938 @@
> +/*
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#ifndef __DTS_IMX6UL_PINFUNC_H
> +#define __DTS_IMX6UL_PINFUNC_H
> +
> +/*
> + * The pin function ID is a tuple of
> + * 
> + */
> +#define  MX6UL_PAD_BOOT_MODE0__GPIO5_IO10
> 0x0014 0x02A0 0x 5 0

Please use space instead of tab between #define and macro.  And if
possible, please change your scripts to use lowercase in hex value,
so that we are consistent with other i.MX pinfunc headers.

Shawn
--
To unsubscribe from this list: send the line "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] ASoC: mediatek: Use platform_of_node for machine drivers

[Koro Chen]

This replaces the platform_name in snd_soc_dai_link by device tree node.

Signed-off-by: Koro Chen 
---
 .../devicetree/bindings/sound/mt8173-max98090.txt |  2 ++
 .../bindings/sound/mt8173-rt5650-rt5676.txt   |  2 ++
 sound/soc/mediatek/mt8173-max98090.c  | 17 +
 sound/soc/mediatek/mt8173-rt5650-rt5676.c | 19 +++
 4 files changed, 32 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/mt8173-max98090.txt 
b/Documentation/devicetree/bindings/sound/mt8173-max98090.txt
index 829bd26..519e97c 100644
--- a/Documentation/devicetree/bindings/sound/mt8173-max98090.txt
+++ b/Documentation/devicetree/bindings/sound/mt8173-max98090.txt
@@ -3,11 +3,13 @@ MT8173 with MAX98090 CODEC
 Required properties:
 - compatible : "mediatek,mt8173-max98090"
 - mediatek,audio-codec: the phandle of the MAX98090 audio codec
+- mediatek,platform: the phandle of MT8173 ASoC platform
 
 Example:
 
sound {
compatible = "mediatek,mt8173-max98090";
mediatek,audio-codec = <&max98090>;
+   mediatek,platform = <&afe>;
};
 
diff --git a/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5676.txt 
b/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5676.txt
index 61e98c9..f205ce9 100644
--- a/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5676.txt
+++ b/Documentation/devicetree/bindings/sound/mt8173-rt5650-rt5676.txt
@@ -3,11 +3,13 @@ MT8173 with RT5650 RT5676 CODECS
 Required properties:
 - compatible : "mediatek,mt8173-rt5650-rt5676"
 - mediatek,audio-codec: the phandles of rt5650 and rt5676 codecs
+- mediatek,platform: the phandle of MT8173 ASoC platform
 
 Example:
 
sound {
compatible = "mediatek,mt8173-rt5650-rt5676";
mediatek,audio-codec = <&rt5650 &rt5676>;
+   mediatek,platform = <&afe>;
};
 
diff --git a/sound/soc/mediatek/mt8173-max98090.c 
b/sound/soc/mediatek/mt8173-max98090.c
index 4d44b58..2d2536a 100644
--- a/sound/soc/mediatek/mt8173-max98090.c
+++ b/sound/soc/mediatek/mt8173-max98090.c
@@ -103,7 +103,6 @@ static struct snd_soc_dai_link mt8173_max98090_dais[] = {
.name = "MAX98090 Playback",
.stream_name = "MAX98090 Playback",
.cpu_dai_name = "DL1",
-   .platform_name = "1122.mt8173-afe-pcm",
.codec_name = "snd-soc-dummy",
.codec_dai_name = "snd-soc-dummy-dai",
.trigger = {SND_SOC_DPCM_TRIGGER_POST, 
SND_SOC_DPCM_TRIGGER_POST},
@@ -114,7 +113,6 @@ static struct snd_soc_dai_link mt8173_max98090_dais[] = {
.name = "MAX98090 Capture",
.stream_name = "MAX98090 Capture",
.cpu_dai_name = "VUL",
-   .platform_name = "1122.mt8173-afe-pcm",
.codec_name = "snd-soc-dummy",
.codec_dai_name = "snd-soc-dummy-dai",
.trigger = {SND_SOC_DPCM_TRIGGER_POST, 
SND_SOC_DPCM_TRIGGER_POST},
@@ -125,7 +123,6 @@ static struct snd_soc_dai_link mt8173_max98090_dais[] = {
{
.name = "Codec",
.cpu_dai_name = "I2S",
-   .platform_name = "1122.mt8173-afe-pcm",
.no_pcm = 1,
.codec_dai_name = "HiFi",
.init = mt8173_max98090_init,
@@ -152,9 +149,21 @@ static struct snd_soc_card mt8173_max98090_card = {
 static int mt8173_max98090_dev_probe(struct platform_device *pdev)
 {
struct snd_soc_card *card = &mt8173_max98090_card;
-   struct device_node *codec_node;
+   struct device_node *codec_node, *platform_node;
int ret, i;
 
+   platform_node = of_parse_phandle(pdev->dev.of_node,
+"mediatek,platform", 0);
+   if (!platform_node) {
+   dev_err(&pdev->dev, "Property 'platform' missing or invalid\n");
+   return -EINVAL;
+   }
+   for (i = 0; i < card->num_links; i++) {
+   if (mt8173_max98090_dais[i].platform_name)
+   continue;
+   mt8173_max98090_dais[i].platform_of_node = platform_node;
+   }
+
codec_node = of_parse_phandle(pdev->dev.of_node,
  "mediatek,audio-codec", 0);
if (!codec_node) {
diff --git a/sound/soc/mediatek/mt8173-rt5650-rt5676.c 
b/sound/soc/mediatek/mt8173-rt5650-rt5676.c
index 0940553..6f52eca 100644
--- a/sound/soc/mediatek/mt8173-rt5650-rt5676.c
+++ b/sound/soc/mediatek/mt8173-rt5650-rt5676.c
@@ -138,7 +138,6 @@ static struct snd_soc_dai_link mt8173_rt5650_rt5676_dais[] 
= {
.name = "rt5650_rt5676 Playback",
.stream_name = "rt5650_rt5676 Playback",
.cpu_dai_name = "DL1",
-   .platform_name = "1122.mt8173-afe-pcm",
.codec_name = "snd-soc-dummy",
.codec_dai_name = "snd-soc-dummy-dai",
  

Re: [PATCH v4 1/3] dt-bindings: pwm: add MediaTek display PWM bindings

[YH Huang]

On Wed, 2015-07-08 at 20:11 +0800, Daniel Kurtz wrote:
> On Mon, Jul 6, 2015 at 9:29 PM, YH Huang  wrote:
> > Document the device-tree binding of MediatTek display PWM.
> > The PWM has one channel to control the backlight brightness for display.
> > It supports MT8173 and MT6595.
> >
> > Signed-off-by: YH Huang 
> > ---
> >  .../devicetree/bindings/pwm/pwm-mtk-disp.txt   | 24 
> > ++
> >  1 file changed, 24 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt 
> > b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > new file mode 100644
> > index 000..757b974
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> > @@ -0,0 +1,24 @@
> > +MediaTek display PWM controller
> > +
> > +Required properties:
> > + - compatible: should be "mediatek,-disp-pwm"
> > +   - "mediatek,mt8173-disp-pwm": found on mt8173 SoC
> > +   - "mediatek,mt6595-disp-pwm": found on mt6595 SoC
> > + - reg: physical base address and length of the controller's registers
> > + - #pwm-cells: must be 2. See pwm.txt in this directory for a description 
> > of
> > +   the cell format
> > + - clocks: phandle and clock specifier of the PWM reference clock
> > + - clock-names: must contain the following
> > +   - "main": clock used to generate PWM signals
> > +   - "mm": sync signals from the modules of mmsys
> > +
> > +Example:
> > +   pwm0: pwm@1401e000 {
> > +   compatible = "mediatek,mt8173-disp-pwm",
> > +"mediatek,mt6595-disp-pwm";
> > +   reg = <0 0x1401e000 0 0x1000>;
> > +   #pwm-cells = <2>;
> > +   clocks = <&mmsys CLK_MM_DISP_PWM026M>,
> > +<&mmsys CLK_MM_DISP_PWM0MM>;
> > +   clock-names = "main", "mm";
> 
> Should we include the pinctrl settings here to enable the PWM output?
> 

Since we use pwm-backlight driver to control backlight, we should enable
PWM output in the backlight node.

Ref:
https://www.kernel.org/doc/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt

Regards,
YH Huang

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

Re: [PATCH 4/8] ARM: pinctrl: imx: add i.mx6ul pinctrl driver

[Shawn Guo]

On Wed, Jun 17, 2015 at 11:39:25PM +0800, frank...@freescale.com wrote:
> From: Frank Li 
> 
> Add i.MX6UL pinctrl driver support.
> 
> Signed-off-by: Anson Huang 
> Signed-off-by: Frank Li 

Acked-by: Shawn Guo 
--
To unsubscribe from this list: send the line "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/8] Document: dt: binding: imx: update document for imx6ul support

[Shawn Guo]

On Wed, Jun 17, 2015 at 11:39:24PM +0800, frank...@freescale.com wrote:
> From: Frank Li 
> 
> This part just add necessary change to boot imx6ul.
> Update clock and pinctrl for imx6ul
> 
> Signed-off-by: Frank Li 
> Signed-off-by: Frank Li 

Double SoB.  Drop one.

> ---
>  .../devicetree/bindings/clock/imx6ul-clock.txt | 13 
>  .../bindings/pinctrl/fsl,imx6ul-pinctrl.txt| 36 
> ++
>  2 files changed, 49 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/clock/imx6ul-clock.txt
>  create mode 100644 
> Documentation/devicetree/bindings/pinctrl/fsl,imx6ul-pinctrl.txt
> 
> diff --git a/Documentation/devicetree/bindings/clock/imx6ul-clock.txt 
> b/Documentation/devicetree/bindings/clock/imx6ul-clock.txt
> new file mode 100644
> index 000..3ff362e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/imx6ul-clock.txt
> @@ -0,0 +1,13 @@
> +* Clock bindings for Freescale i.MX6 UltraLite
> +
> +Required properties:
> +- compatible: Should be "fsl,imx6ul-ccm"
> +- reg: Address and length of the register set
> +- #clock-cells: Should be <1>
> +- clocks: list of clock specifiers, must contain an entry for each required
> +  entry in clock-names
> +- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
> +
> +The clock consumer should specify the desired clock by having the clock
> +ID in its "clocks" phandle cell.  See 
> include/dt-bindings/clock/imx6ul-clock.h
> +for the full list of i.MX6 UltraLite  clock IDs.
   ^^
Double spaces.  Drop one.

Shawn

> diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6ul-pinctrl.txt 
> b/Documentation/devicetree/bindings/pinctrl/fsl,imx6ul-pinctrl.txt
> new file mode 100644
> index 000..a81bbf3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6ul-pinctrl.txt
> @@ -0,0 +1,36 @@
> +* Freescale i.MX6 UltraLite IOMUX Controller
> +
> +Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
> +and usage.
> +
> +Required properties:
> +- compatible: "fsl,imx6ul-iomuxc"
> +- fsl,pins: each entry consists of 6 integers and represents the mux and 
> config
> +  setting for one pin.  The first 5 integers  mux_val
> +  input_val> are specified using a PIN_FUNC_ID macro, which can be found in
> +  imx6ul-pinfunc.h under device tree source folder.  The last integer CONFIG 
> is
> +  the pad setting value like pull-up on this pin.  Please refer to i.MX6 
> UltraLite
> +  Reference Manual for detailed CONFIG settings.
> +
> +CONFIG bits definition:
> +PAD_CTL_HYS (1 << 16)
> +PAD_CTL_PUS_100K_DOWN   (0 << 14)
> +PAD_CTL_PUS_47K_UP  (1 << 14)
> +PAD_CTL_PUS_100K_UP (2 << 14)
> +PAD_CTL_PUS_22K_UP  (3 << 14)
> +PAD_CTL_PUE (1 << 13)
> +PAD_CTL_PKE (1 << 12)
> +PAD_CTL_ODE (1 << 11)
> +PAD_CTL_SPEED_LOW   (0 << 6)
> +PAD_CTL_SPEED_MED   (1 << 6)
> +PAD_CTL_SPEED_HIGH  (3 << 6)
> +PAD_CTL_DSE_DISABLE (0 << 3)
> +PAD_CTL_DSE_260ohm  (1 << 3)
> +PAD_CTL_DSE_130ohm  (2 << 3)
> +PAD_CTL_DSE_87ohm   (3 << 3)
> +PAD_CTL_DSE_65ohm   (4 << 3)
> +PAD_CTL_DSE_52ohm   (5 << 3)
> +PAD_CTL_DSE_43ohm   (6 << 3)
> +PAD_CTL_DSE_37ohm   (7 << 3)
> +PAD_CTL_SRE_FAST(1 << 0)
> +PAD_CTL_SRE_SLOW(0 << 0)
> -- 
> 1.9.1
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/8] ARM: imx: add i.mx6ul msl support

[Shawn Guo]

On Wed, Jun 17, 2015 at 11:39:22PM +0800, frank...@freescale.com wrote:
> From: Frank Li 
> 
> i.MX6UL is a new SOC, add MSL support
> 
> Signed-off-by: Frank Li 
> ---
>  arch/arm/mach-imx/Kconfig   |  8 
>  arch/arm/mach-imx/Makefile  |  1 +
>  arch/arm/mach-imx/mach-imx6ul.c | 43 
> +
>  3 files changed, 52 insertions(+)
>  create mode 100644 arch/arm/mach-imx/mach-imx6ul.c
> 
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 573536f..8ceda28 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -548,6 +548,14 @@ config SOC_IMX6SX
>   help
> This enables support for Freescale i.MX6 SoloX processor.
>  
> +config SOC_IMX6UL
> + bool "i.MX6 UltraLite support"
> + select PINCTRL_IMX6UL
> + select SOC_IMX6
> +
> + help
> +   This enables support for Freescale i.MX6 UltraLite processor.
> +
>  config SOC_IMX7D
>   bool "i.MX7 Dual support"
>   select PINCTRL_IMX7D
> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> index 37c502a..fb689d8 100644
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@ -83,6 +83,7 @@ endif
>  obj-$(CONFIG_SOC_IMX6Q) += mach-imx6q.o
>  obj-$(CONFIG_SOC_IMX6SL) += mach-imx6sl.o
>  obj-$(CONFIG_SOC_IMX6SX) += mach-imx6sx.o
> +obj-$(CONFIG_SOC_IMX6UL) += mach-imx6ul.o
>  obj-$(CONFIG_SOC_IMX7D) += mach-imx7d.o
>  
>  ifeq ($(CONFIG_SUSPEND),y)
> diff --git a/arch/arm/mach-imx/mach-imx6ul.c b/arch/arm/mach-imx/mach-imx6ul.c
> new file mode 100644
> index 000..706d5f6
> --- /dev/null
> +++ b/arch/arm/mach-imx/mach-imx6ul.c
> @@ -0,0 +1,43 @@
> +/*
> + * Copyright (C) 2015 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "common.h"
> +
> +static void __init imx6ul_init_machine(void)
> +{
> + struct device *parent;
> +
> + parent = imx_soc_device_init();

How does the soc_id of soc_device work?  I do not see any patch adding
imx6ul soc_id.

Shawn

> + if (parent == NULL)
> + pr_warn("failed to initialize soc device\n");
> +
> + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> + imx_anatop_init();
> +}
> +
> +static void __init imx6ul_init_irq(void)
> +{
> + imx_init_revision_from_anatop();
> + imx_src_init();
> + irqchip_init();
> +}
> +
> +static const char *imx6ul_dt_compat[] __initconst = {
> + "fsl,imx6ul",
> + NULL,
> +};
> +
> +DT_MACHINE_START(IMX7D, "Freescale i.MX6 Ultralite (Device Tree)")
> + .init_irq   = imx6ul_init_irq,
> + .init_machine   = imx6ul_init_machine,
> + .dt_compat  = imx6ul_dt_compat,
> +MACHINE_END
> -- 
> 1.9.1
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/2] cpufreq: mediatek: Add MT8173 cpufreq driver

[Pi-Cheng Chen]

Hi Viresh,

On Wed, Jul 8, 2015 at 7:34 PM, Viresh Kumar  wrote:
> On 01-07-15, 10:16, Pi-Cheng Chen wrote:
>> This patch implements MT8173 cpufreq driver.
>
> Now that you are going to resend this patchset, a few more comments.
>
> Please describe your SoC a bit here, so that reviewers know what are
> we going to implement.

Yes. I will add it.

>
>> +static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
>> +{
>> + struct device *cpu_dev;
>> + struct regulator *proc_reg = ERR_PTR(-ENODEV);
>> + struct regulator *sram_reg = ERR_PTR(-ENODEV);
>> + struct clk *cpu_clk = ERR_PTR(-ENODEV);
>> + struct clk *inter_clk = ERR_PTR(-ENODEV);
>> + struct dev_pm_opp *opp;
>> + unsigned long rate;
>> + int ret;
>> +
>> + cpu_dev = get_cpu_device(cpu);
>> + if (!cpu_dev) {
>> + pr_err("failed to get cpu%d device\n", cpu);
>> + return -ENODEV;
>> + }
>> +
>> + ret = of_init_opp_table(cpu_dev);
>> + if (ret) {
>> + pr_warn("no OPP table for cpu%d\n", cpu);
>> + return ret;
>> + }
>
> Initialize opp table only when you know other resources are available.
> i.e. we aren't going to abort due to EPROBE_DEFER.

Will do it.

>
>> + cpu_clk = clk_get(cpu_dev, "cpu");
>> + if (IS_ERR(cpu_clk)) {
>> + if (PTR_ERR(cpu_clk) == -EPROBE_DEFER)
>> + pr_warn("cpu clk for cpu%d not ready, retry.\n", cpu);
>> + else
>> + pr_err("failed to get cpu clk for cpu%d\n", cpu);
>> +
>> + ret = PTR_ERR(cpu_clk);
>> + goto out_free_opp_table;
>> + }
>> +}
>
>
>> +static int mt8173_cpufreq_probe(struct platform_device *pdev)
>> +{
>> + int ret;
>> +
>> + ret = cpufreq_register_driver(&mt8173_cpufreq_driver);
>> + if (ret)
>> + pr_err("failed to register mtk cpufreq driver\n");
>> +
>> + return ret;
>> +}
>> +
>> +static struct platform_driver mt8173_cpufreq_platdrv = {
>> + .driver = {
>> + .name   = "mt8173-cpufreq",
>> + },
>> + .probe  = mt8173_cpufreq_probe,
>> +};
>> +
>> +static int mt8173_cpufreq_driver_init(void)
>> +{
>> + struct platform_device *pdev;
>> + int err;
>> +
>> + if (!of_machine_is_compatible("mediatek,mt8173"))
>> + return -ENODEV;
>
> Why do you need to check this ? Its going to be the right SoC, others
> can't even compile it.

Originally I was thinking this driver should be generic to other Mediatek
SoCs, so I add this check to filter out those SoCs that are not yet
confirmed with this driver supported. Since it's targeted to MT8173 only
now, I will remove this check.

>
>> + err = platform_driver_register(&mt8173_cpufreq_platdrv);
>> + if (err)
>> + return err;
>> +
>> + pdev = platform_device_register_simple("mt8173-cpufreq", -1, NULL, 0);
>> + if (IS_ERR(pdev)) {
>> + pr_err("failed to register mtk-cpufreq platform device\n");
>> + return PTR_ERR(pdev);
>> + }
>
> This is simply crap. You register the driver and then its device from
> the same function. If you are so sure that this driver is required,
> then why to get into the shit of device-driver model ?
>
> Just call cpufreq_register_driver() from here :), no device/driver
> required.

That's what I did in previous version. But the reason I use the device-
driver model is to handle the defer probing issue. Since there's no
arch/arm64/mach-mediatek/ directory to hold the device registration
code anymore, no device tree way to match cpufreq driver
(please correct me if there's any), and initcall seems not handle
defer probing either, therefore I put both device and driver
registration in this function. I know it's crappy. :(
Do you have any suggestion to do it right and handle defer probing
properly?

Thanks.

Best Regards,
Pi-Cheng

>
> --
> 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 v6 4/6] ARM: vf610: enable NAND Flash Controller

[Shawn Guo]

On Wed, Jul 08, 2015 at 10:32:54AM -0400, Bill Pringlemeir wrote:
> 
> On  8 Jul 2015, shawn...@kernel.org wrote:
> > On Fri, Jun 19, 2015 at 12:58:37AM +0200, Stefan Agner wrote:
> >> Enable the NAND Flash Controller driver which is part of the Vybrid
> >> SoC by default.
> >>
> >> Signed-off-by: Stefan Agner 
> >> ---
> >> arch/arm/mach-imx/Kconfig | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> >> index 3a3d3e9..9358135 100644
> >> --- a/arch/arm/mach-imx/Kconfig
> >> +++ b/arch/arm/mach-imx/Kconfig
>  -589,6 +589,7 @@ config SOC_VF610
> >>select PINCTRL_VF610
> >>select PL310_ERRATA_769419 if CACHE_L2X0
> >>select SMP_ON_UP if SMP
> >> +  select HAVE_NAND_VF610_NFC
> 
> > I'm not sure about the benefit of having this option, except we have
> > to have this additional architecture patch.
> 
> For other SOC, like the PowerPC or ColdFire CPUs with this controller,
> it was a way to mark the controller as populated.  Otherwise, the
> Kconfig entry to select the controller will pop up for everybody.

IMHO, having the option pop up for everybody isn't really a problem.  On
the other hand, we can even compile test the driver on any architecture
without the COMPILE_TEST dependency.

But if MTD maintainer has a different opinion, we can still have a
'depends on SOC_VF610' to save this patch.

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

Re: [PATCH 5/7] tty: 8250: workaround errata on disabling UART after using DMA

[Peter Hurley]

Hi Sekhar,

Patch title should start "serial: 8250_omap: .." since the patch
is specific to the 8250_omap serial driver.

On 07/06/2015 05:47 AM, Sekhar Nori wrote:
> AM335x, AM437x and DRA7x SoCs have an errata due to which UART
> cannot be disabled after it has been used with DMA.
 ^^
 idled

> OMAP3 has a similar sounding errata which has been worked around
> in a2fc36613ac1af2e9 ("ARM: OMAP3: Use manual idle for UARTs
> because of DMA errata"). But the workaround used there does not
> apply to AM335x, AM437x SoCs.

> These SoCs need a softreset of UART before disabling them.

"The UART module on these SoCs must be soft reset to go idle."
 
> This patch implements that errata workaround. It is expected that
> UART will be used with DMA so no explicit check for DMA usage
> has been added for errata applicability.

This changelog should also:

1. Reference the errata document.
2. Explain why SCR register has to be the context loss canary
   rather than MDR1.

> Signed-off-by: Sekhar Nori 
> ---
>  drivers/tty/serial/8250/8250_omap.c | 55 
> +
>  1 file changed, 49 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_omap.c 
> b/drivers/tty/serial/8250/8250_omap.c
> index 52566387ec37..af25869d145f 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -33,6 +33,11 @@
>  #define UART_ERRATA_i202_MDR1_ACCESS (1 << 0)
>  #define OMAP_UART_WER_HAS_TX_WAKEUP  (1 << 1)
>  #define OMAP_DMA_TX_KICK (1 << 2)
> +/*
> + * See Advisory 21 in AM437x errata SPRZ408B, updated April 2015.
> + * The same errata is applicable to AM335x and DRA7x processors too.
> + */
> +#define UART_ERRATA_CLOCK_DISABLE(1 << 3)
>  
>  #define OMAP_UART_FCR_RX_TRIG6
>  #define OMAP_UART_FCR_TX_TRIG4
> @@ -54,6 +59,12 @@
>  #define OMAP_UART_MVR_MAJ_SHIFT  8
>  #define OMAP_UART_MVR_MIN_MASK   0x3f
>  
> +/* SYSC register bitmasks */
> +#define OMAP_UART_SYSC_SOFTRESET (1 << 1)
> +
> +/* SYSS register bitmasks */
> +#define OMAP_UART_SYSS_RESETDONE (1 << 0)
> +
>  #define UART_TI752_TLR_TX0
>  #define UART_TI752_TLR_RX4
>  
> @@ -1062,13 +1073,15 @@ static int omap8250_no_handle_irq(struct uart_port 
> *port)
>   return 0;
>  }
>  
> -static const u8 am3352_habit = OMAP_DMA_TX_KICK;
> +static const u8 am3352_habit = OMAP_DMA_TX_KICK | UART_ERRATA_CLOCK_DISABLE;
> +static const u8 am4372_habit = UART_ERRATA_CLOCK_DISABLE;
>  
>  static const struct of_device_id omap8250_dt_ids[] = {
>   { .compatible = "ti,omap2-uart" },
>   { .compatible = "ti,omap3-uart" },
>   { .compatible = "ti,omap4-uart" },
>   { .compatible = "ti,am3352-uart", .data = &am3352_habit, },
> + { .compatible = "ti,am4372-uart", .data = &am4372_habit, },
>   {},
>  };
>  MODULE_DEVICE_TABLE(of, omap8250_dt_ids);
> @@ -1279,13 +1292,13 @@ static int omap8250_lost_context(struct 
> uart_8250_port *up)
>  {
>   u32 val;
>  
> - val = serial_in(up, UART_OMAP_MDR1);
> + val = serial_in(up, UART_OMAP_SCR);
>   /*
> -  * If we lose context, then MDR1 is set to its reset value which is
> -  * UART_OMAP_MDR1_DISABLE. After set_termios() we set it either to 13x
> -  * or 16x but never to disable again.
> +  * If we lose context, then SCR is set to its reset value of zero.
> +  * After set_termios() we set bit 3 of SCR (TX_EMPTY_CTL_IT) to 1,
> +  * among other bits, to never set the register back to zero again.
>*/
> - if (val == UART_OMAP_MDR1_DISABLE)
> + if (!val)
>   return 1;
>   return 0;
>  }
> @@ -1307,6 +1320,36 @@ static int omap8250_runtime_suspend(struct device *dev)
>   return -EBUSY;
>   }
>  
> + if (priv->habit & UART_ERRATA_CLOCK_DISABLE) {
> + int sysc;
> + int syss;
> + int timeout = 100;
> +
> + sysc = serial_in(up, UART_OMAP_SYSC);
> +
> + /* softreset the UART */
> + sysc |= OMAP_UART_SYSC_SOFTRESET;
> + serial_out(up, UART_OMAP_SYSC, sysc);
> +
> + /* By experiments, 1us enough for reset complete on AM335x */
> + do {
> + udelay(1);
> + syss = serial_in(up, UART_OMAP_SYSS);
> + } while (--timeout && !(syss & OMAP_UART_SYSS_RESETDONE));


If there is not a omap helper function to reset modules, there should be.
Open-coding the module reset is not appropriate.

> + if (!timeout) {
> + dev_err(dev, "timed out waiting for reset done\n");
> + return -ETIMEDOUT;
> + }
> +
> + /*
> +  * For UART module wake-up to work, MDR1.MODESELECT should
> +  * not be set to "Disable", so update it.
> +  */
> + if (device_may_wakeup(dev))
> + 

Re: [PATCH v4 3/5] tee: generic TEE subsystem

[Dmitry Torokhov]

On Wed, Jul 08, 2015 at 04:52:03PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Jul 08, 2015 at 04:28:26PM -0700, Dmitry Torokhov wrote:
> > On Wed, Jul 08, 2015 at 03:33:25PM -0700, Greg Kroah-Hartman wrote:
> > > On Wed, Jul 08, 2015 at 04:26:49PM -0600, Jason Gunthorpe wrote:
> > > > On Wed, Jul 08, 2015 at 02:11:29PM -0700, Greg Kroah-Hartman wrote:
> > > > > > > +   cdev_init(&teedev->cdev, &tee_fops);
> > > > > > > +   teedev->cdev.owner = teedesc->owner;
> > > > > > 
> > > > > > This also needs to set teedev->cdev.kobj.parent.
> > > > > > I'm guessing:
> > > > > > 
> > > > > >  teedev->cdev.kobj.parent = &teedev->dev.kobj;
> > > > > > 
> > > > > > TPM had the same mistake..
> > > > > 
> > > > > Really?  As of a few years ago, A cdev's kobject should not be touched
> > > > > by anything other than the cdev core.  It's not a "real" kobject in 
> > > > > that
> > > > > it is never registered in sysfs, and no one sees it.  I keep meaning 
> > > > > to
> > > > 
> > > > Well, when I looked at it, it looked like it was necessary to maintain
> > > > the refcount on the memory that is holding cdev.
> > > > 
> > > > The basic issue is that cdev_del doesn't seem to be synchronizing.
> > > > 
> > > > The use after free race is then something like:
> > > > 
> > > >struct tpm_chip {
> > > > struct device dev;
> > > > struct cdev cdev;
> > > 
> > > Oops, right there's your problem.  You can't have two reference counted
> > > objects trying to manage the memory of a single structure.  No matter
> > > what you do, it's going to be a pain to deal with this, so don't :)
> > > 
> > > > 
> > > >CPU0CPU1
> > > > = ==
> > > > tpm_chip = kalloc
> > > > cdev_add(&tpm_chip->cdev)
> > > > device_add(&tpm_chip->dev)
> > > > chrdev_open
> > > >  filp->f_op->open
> > > > cdev_del(&tpm_chip->cdev)
> > > > device_unregister
> > > >(&tpm_chip->dev)
> > > >  kfree(tpm_chip)
> > > >   tpm_chip = container_of
> > > >  fput
> > > >   cdev_put(.. cdev)
> > > > 
> > > > Ie we need cdev to hold a ref on tpm_chip->dev until cdev_put is
> > > > called.
> > > 
> > > No, separate them, make the cdev a pointer and all should be fine.
> > > 
> > > > > just use something else one of these days for that structure, as lots 
> > > > > of
> > > > > people get it wrong.  Or has things changed there?
> > > > 
> > > > Not recently, but this is the commit:
> > > > 
> > > > commit 2f0157f13f42800aa3d9017ebb0fb80a65f7b2de
> > > > Author: Dmitry Torokhov 
> > > > Date:   Sun Oct 21 17:57:19 2012 -0700
> > > > 
> > > > char_dev: pin parent kobject
> > > > 
> > > > In certain cases (for example when a cdev structure is embedded into
> > > > another object whose lifetime is controlled by a separate kobject) 
> > > > it is
> > > > beneficial to tie lifetime of another object to the lifetime of
> > > > character device so that related object is not freed until after
> > > > char_dev object is freed.
> > > > 
> > > > To achieve this let's pin kobject's parent when doing cdev_add() and
> > > > unpin when last reference to cdev structure is being released.
> > > > 
> > > > Signed-off-by: Dmitry Torokhov 
> > > > Acked-by: Al Viro 
> > > > Signed-off-by: Linus Torvalds 
> > > > 
> > > > It doesn't seem the be the best situation, this is the 3rd time this
> > > > week I've noticed cdev with a kalloc'd struct being used improperly.
> > > > 
> > > > Perhaps cdev_init should accept the module and kref parent as an
> > > > argument?
> > > 
> > > Oh yeah, that commit :(
> > > 
> > > If you know _exactly_ what you are doing, you can get away with this,
> > > but I strongly recommend not doing that.  As proof of that, in some new
> > > code I'm working on, I did not do this, just because I'm not smart
> > > enough to ensure it's all working properly...
> > 
> > I know you like to allocate everything separately and access it via
> > pointers (ala device_create) but cdevs explicitly allow embedding them
> > into other structures (cdev_init vs cdev_alloc). I do not think there is
> > anything wrong with this, as well as there is nothing wrong in embedding
> > a struct device into other structures, but it does require coordinating
> > lifetime rules and selecting a "master" kobject. I think having
> > cdev_init accept such "master" kobject would bring author's attention to
> > the issue and avoid such mistakes in the future.
> 
> Embedding cdevs into other structures is great, I like that.  What I
> don't like is having two different reference counts for the same
> structure based on the lifetime rules of two different embedded
> structures.  That's a very difficult thing to get right and I would
> argue, is something that should almost never be done.

Re: [PATCH v4 3/5] tee: generic TEE subsystem

[Dmitry Torokhov]

On Wed, Jul 08, 2015 at 04:53:21PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Jul 08, 2015 at 05:16:12PM -0600, Jason Gunthorpe wrote:
> > On Wed, Jul 08, 2015 at 03:33:25PM -0700, Greg Kroah-Hartman wrote:
> > > > The basic issue is that cdev_del doesn't seem to be synchronizing.
> > > > 
> > > > The use after free race is then something like:
> > > > 
> > > >struct tpm_chip {
> > > > struct device dev;
> > > > struct cdev cdev;
> > > 
> > > Oops, right there's your problem.  You can't have two reference counted
> > > objects trying to manage the memory of a single structure.  No matter
> > > what you do, it's going to be a pain to deal with this, so don't :)
> > 
> > Sure, generally, yes, but that isn't done for no reason, it is to make
> > open straightforward:
> > 
> > static int tpm_open(struct inode *inode, struct file *file)
> > {
> > struct tpm_chip *chip =
> > container_of(inode->i_cdev, struct tpm_chip, cdev);
> > 
> > We need to recover the tpm_chip associated with the char device
> > node, in a way that is holding a kref on it, without racing with
> > cdev_del/etc
> > 
> > This scheme does mean that if we have a struct file we have a kref on
> > the cdev, and if we have cdev then we have a kref on the tpm_chip,
> > which is really easy to use properly.
> > 
> > > > Ie we need cdev to hold a ref on tpm_chip->dev until cdev_put is
> > > > called.
> > > 
> > > No, separate them, make the cdev a pointer and all should be fine.
> > 
> > Okay, cdev_alloc takes care of the cdev lifetime.
> > 
> > Do you have a simple solution to replace container_of as well?
> > 
> > What would you think about something like:
> > 
> >  cdev_alloc(&chip->dev.kref)
> 
> Just pick either the cdev to handle the lifetime rules, or the struct
> device, you'll still need a container_of().  Just don't do both as odds
> are the lifetime rules is going to get really hard to debug and ensure
> that everything is correct on the shutdown/release path.

It is not that simple. The issue is that we need to ensure that cdev
does not outlive the structure that represents the device, otherwise it
may disappear while cdev code tries to access it. So we need a way to
pin the "main" structure in memory until cdev is gone. But as I
mentioned in [1] cdev is "sealed" and does not give us a way of hooking
into add/release so that we can try to pin the object we need. And given
that the main driver model primitive is kobject even if we "unseal" cdev
everyone will end up doing pretty much what the above commit did.

Thanks.

-- 
Dmitry

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

Re: [PATCH v2 2/2] clk: mediatek: Add MT8173 MMPLL change rate support

[Stephen Boyd]

On 07/08/2015 01:37 AM, James Liao wrote:
> diff --git a/drivers/clk/mediatek/clk-pll.c b/drivers/clk/mediatek/clk-pll.c
> index 68af518..622e7b6 100644
> --- a/drivers/clk/mediatek/clk-pll.c
> +++ b/drivers/clk/mediatek/clk-pll.c
> @@ -138,16 +138,28 @@ static void mtk_pll_calc_values(struct mtk_clk_pll 
> *pll, u32 *pcw, u32 *postdiv,
>   u32 freq, u32 fin)
>  {
>   unsigned long fmin = 1000 * MHZ;
> + const struct mtk_pll_div_table *div_table = pll->data->div_table;
>   u64 _pcw;
>   u32 val;
>  
>   if (freq > pll->data->fmax)
>   freq = pll->data->fmax;
>  
> - for (val = 0; val < 4; val++) {
> + if (div_table) {
> + if (freq > div_table[0].freq)
> + freq = div_table[0].freq;
> +
> + for (val = 0; div_table[val + 1].freq != 0; val++) {
> + if (freq > div_table[val + 1].freq)
> + break;
> + }
>   *postdiv = 1 << val;
> - if (freq * *postdiv >= fmin)
> - break;
> + } else {
> + for (val = 0; val < 5; val++) {
> + *postdiv = 1 << val;
> + if ((u64)freq * *postdiv >= fmin)
>

No mention of this cast in the commit text. Is this fixing a bug? If so,
please mention it and/or split this bug fix off of this patch.

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

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

Re: [PATCH 0/2] Add MT8173 MMPLL change rate support

[Stephen Boyd]

On 07/08/2015 01:37 AM, James Liao wrote:
> MT8173 MMPLL frequency settings are different from common PLLs.
> It needs different post divider settings for some ranges of frequency.
> This patch add support for MT8173 MMPLL frequency setting, includes:
>
> 1. Add div-rate table for PLLs.
> 2. Increase the max ost divider setting from 3 (/8) to 4 (/16).
> 3. Write postdiv and pcw settings at the same time.
>
> James Liao (2):
>   clk: mediatek: Fix PLL registers setting flow
>   clk: mediatek: Add MT8173 MMPLL change rate support
>

Are these fixing regressions in 4.2-rc1? I don't see any "Fixes:" tag so
it's not clear and makes me want to defer these until v4.3. Furthermore,
the subject starts with "Add" so it sounds like a new feature.

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

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

Re: [PATCH 3/7] tty: 8250: omap: introduce function to update mdr1

[Peter Hurley]

Hi Sekhar,

On 07/06/2015 05:47 AM, Sekhar Nori wrote:
> updating mdr1 register on OMAP needs to take care of
> errata i202. Introduce a function to update mdr1.
> 
> This will be useful later on when mdr1 needs to be
> written to from other places. No functional change.

This changelog is not clear. May I suggest:

serial: 8250_omap: Refactor MDR1 update

The errata [1] workaround implemented in follow-on patch,
"serial: 8250_omap: workaround errata on disabling UART after using DMA",
requires MDR1 register programming.

Extract MDR1 register update into helper function, omap8250_update_mdr1().

[1] Advisory 21 in http://www.ti.com/lit/er/sprz408b/sprz408b.pdf


Regards,
Peter Hurley

> Signed-off-by: Sekhar Nori 
> ---
>  drivers/tty/serial/8250/8250_omap.c | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_omap.c 
> b/drivers/tty/serial/8250/8250_omap.c
> index 20c5b9c4c288..d9c96b993a84 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -232,6 +232,15 @@ static void omap8250_update_scr(struct uart_8250_port 
> *up,
>   serial_out(up, UART_OMAP_SCR, priv->scr);
>  }
>  
> +static void omap8250_update_mdr1(struct uart_8250_port *up,
> +  struct omap8250_priv *priv)
> +{
> + if (priv->habit & UART_ERRATA_i202_MDR1_ACCESS)
> + omap_8250_mdr1_errataset(up, priv);
> + else
> + serial_out(up, UART_OMAP_MDR1, priv->mdr1);
> +}
> +
>  static void omap8250_restore_regs(struct uart_8250_port *up)
>  {
>   struct omap8250_priv *priv = up->port.private_data;
> @@ -282,11 +291,9 @@ static void omap8250_restore_regs(struct uart_8250_port 
> *up)
>   serial_out(up, UART_XOFF1, priv->xoff);
>  
>   serial_out(up, UART_LCR, up->lcr);
> - /* need mode A for FCR */
> - if (priv->habit & UART_ERRATA_i202_MDR1_ACCESS)
> - omap_8250_mdr1_errataset(up, priv);
> - else
> - serial_out(up, UART_OMAP_MDR1, priv->mdr1);
> +
> + omap8250_update_mdr1(up, priv);
> +
>   up->port.ops->set_mctrl(&up->port, up->port.mctrl);
>  }
>  
> 

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

Re: [PATCH 4/7] tty: 8250: omap eliminate use of of_machine_is_compatible()

[Peter Hurley]

Hi Sekhar,

On 07/06/2015 05:47 AM, Sekhar Nori wrote:
> Use of of_machine_is_compatible() for AM335x specific DMA
> quirk in 8250_omap driver makes it ugly to extend the
> quirk for other platforms. Instead use a new compatible.
> 
> The new compatible will also make it easier to care of other
> quirks specific to AM335x and like SoCs.
> 
> This patch does break backward DTB compatibility for users of
> 8250_omap driver on AM335x boards.

Not ok.

8250_omap was released with 3.19 and has been the default driver for
BeagleBone since 4.0.

Regards,
Peter Hurley

> However, the 8250_omap driver
> is new and omap_serial is still the default choice driver for UART
> and so choosing to break compatibility over keeping the code
> around forever.
> 
> Signed-off-by: Sekhar Nori 
> ---
>  .../devicetree/bindings/serial/omap_serial.txt |  1 +
>  arch/arm/boot/dts/am33xx.dtsi  | 12 
>  drivers/tty/serial/8250/8250_omap.c| 35 
> +-
>  3 files changed, 28 insertions(+), 20 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt 
> b/Documentation/devicetree/bindings/serial/omap_serial.txt
> index d3bd2b1ec401..0ee88209b341 100644
> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
> @@ -5,6 +5,7 @@ Required properties:
>  - compatible : should be "ti,omap3-uart" for OMAP3 controllers
>  - compatible : should be "ti,omap4-uart" for OMAP4 controllers
>  - compatible : should be "ti,am4372-uart" for AM437x controllers
> +- compatible : should be "ti,am3352-uart" for AM335x controllers
>  - reg : address and length of the register space
>  - interrupts or interrupts-extended : Should contain the uart interrupt
>specifier or both the interrupt
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 21fcc440fc1a..b76f9a2ce05d 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -210,7 +210,7 @@
>   };
>  
>   uart0: serial@44e09000 {
> - compatible = "ti,omap3-uart";
> + compatible = "ti,am3352-uart", "ti,omap3-uart";
>   ti,hwmods = "uart1";
>   clock-frequency = <4800>;
>   reg = <0x44e09000 0x2000>;
> @@ -221,7 +221,7 @@
>   };
>  
>   uart1: serial@48022000 {
> - compatible = "ti,omap3-uart";
> + compatible = "ti,am3352-uart", "ti,omap3-uart";
>   ti,hwmods = "uart2";
>   clock-frequency = <4800>;
>   reg = <0x48022000 0x2000>;
> @@ -232,7 +232,7 @@
>   };
>  
>   uart2: serial@48024000 {
> - compatible = "ti,omap3-uart";
> + compatible = "ti,am3352-uart", "ti,omap3-uart";
>   ti,hwmods = "uart3";
>   clock-frequency = <4800>;
>   reg = <0x48024000 0x2000>;
> @@ -243,7 +243,7 @@
>   };
>  
>   uart3: serial@481a6000 {
> - compatible = "ti,omap3-uart";
> + compatible = "ti,am3352-uart", "ti,omap3-uart";
>   ti,hwmods = "uart4";
>   clock-frequency = <4800>;
>   reg = <0x481a6000 0x2000>;
> @@ -252,7 +252,7 @@
>   };
>  
>   uart4: serial@481a8000 {
> - compatible = "ti,omap3-uart";
> + compatible = "ti,am3352-uart", "ti,omap3-uart";
>   ti,hwmods = "uart5";
>   clock-frequency = <4800>;
>   reg = <0x481a8000 0x2000>;
> @@ -261,7 +261,7 @@
>   };
>  
>   uart5: serial@481aa000 {
> - compatible = "ti,omap3-uart";
> + compatible = "ti,am3352-uart", "ti,omap3-uart";
>   ti,hwmods = "uart6";
>   clock-frequency = <4800>;
>   reg = <0x481aa000 0x2000>;
> diff --git a/drivers/tty/serial/8250/8250_omap.c 
> b/drivers/tty/serial/8250/8250_omap.c
> index d9c96b993a84..52566387ec37 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -537,14 +538,14 @@ static void omap_serial_fill_features_erratas(struct 
> uart_8250_port *up,
>  
>   switch (revision) {
>   case OMAP_UART_REV_46:
> - priv->habit = UART_ERRATA_i202_MDR1_ACCESS;
> + priv->habit |= UART_ERRATA_i202_MDR1_ACCESS;
>   break;
>   case OMAP_UART_REV_52:
> - priv->habit = UART_ERRATA_i202_MDR1_ACCESS |
> + priv->habit

Re: [PATCH v2 01/11] soc: qcom: Add device tree binding for SMEM

[Stephen Boyd]

On 06/26/2015 02:50 PM, bj...@kryo.se wrote:
> += EXAMPLE
> +The following example shows the SMEM setup for MSM8974, with a main SMEM 
> region
> +at 0xfa0 and an auxiliary region at 0xfc428000:
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + smem_region: smem@fa0 {
> + reg = <0xfa0 0x20>;
> + no-map;
> + };
> + };
> +
> + smem@fa0 {

This should be smem@fc428000 matching the first reg property. It's weird
though, because if smem is using a secondary region it will be under the
SoC node and have a reg property. Otherwise it would be directly under
the root node and only have a memory-region. It would be nice if we
could somehow move the rpm message ram (0xfc428000) into the
reserved-memory node so that we could use memory-region for both regions.

> + compatible = "qcom,smem";
> +
> + memory-region = <&smem_region>;
> + reg = <0xfc428000 0x4000>;
> +
> + hwlocks = <&tcsr_mutex 3>;
> + };


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

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

Re: [PATCH 2/4] ARM: dts: Extend exynos5250-pinctrl nodes using labels instead of paths

[Krzysztof Kozlowski]

On 08.07.2015 23:05, Javier Martinez Canillas wrote:
> Hello Krzysztof,
> 
> On 07/08/2015 01:29 AM, Krzysztof Kozlowski wrote:
>> On 08.07.2015 14:36, Javier Martinez Canillas wrote:
>>> A previously defined Device Tree node, can be extended either by defining
>>> a node using the same full path or by creating a label for the node and
>>> referencing to it.
>>>
>>> Using full paths is more error prone since if there was a typo error, a
>>> new node will be created instead of extending the node as it was desired.
>>> This will lead to run-time errors that could be hard to detect.
>>>
>>> A misstyped label on the other hand, will cause a dtc compile error which
>>
>> s/misstyped/mistyped/
>>
> 
> sigh, it's so ironic that I mistyped that.
> 
> Do you want me to re-post the whole series with the typo fixed or you /
> Kukjin would fix in both patches when applying?

I'll fix it when applying to my tree. As for Kukjin, it depends whether
he will pick it up from LKML or from me.

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 3/5] tee: generic TEE subsystem

[Greg Kroah-Hartman]

On Wed, Jul 08, 2015 at 05:16:12PM -0600, Jason Gunthorpe wrote:
> On Wed, Jul 08, 2015 at 03:33:25PM -0700, Greg Kroah-Hartman wrote:
> > > The basic issue is that cdev_del doesn't seem to be synchronizing.
> > > 
> > > The use after free race is then something like:
> > > 
> > >struct tpm_chip {
> > >   struct device dev;
> > >   struct cdev cdev;
> > 
> > Oops, right there's your problem.  You can't have two reference counted
> > objects trying to manage the memory of a single structure.  No matter
> > what you do, it's going to be a pain to deal with this, so don't :)
> 
> Sure, generally, yes, but that isn't done for no reason, it is to make
> open straightforward:
> 
> static int tpm_open(struct inode *inode, struct file *file)
> {
>   struct tpm_chip *chip =
>   container_of(inode->i_cdev, struct tpm_chip, cdev);
> 
> We need to recover the tpm_chip associated with the char device
> node, in a way that is holding a kref on it, without racing with
> cdev_del/etc
> 
> This scheme does mean that if we have a struct file we have a kref on
> the cdev, and if we have cdev then we have a kref on the tpm_chip,
> which is really easy to use properly.
> 
> > > Ie we need cdev to hold a ref on tpm_chip->dev until cdev_put is
> > > called.
> > 
> > No, separate them, make the cdev a pointer and all should be fine.
> 
> Okay, cdev_alloc takes care of the cdev lifetime.
> 
> Do you have a simple solution to replace container_of as well?
> 
> What would you think about something like:
> 
>  cdev_alloc(&chip->dev.kref)

Just pick either the cdev to handle the lifetime rules, or the struct
device, you'll still need a container_of().  Just don't do both as odds
are the lifetime rules is going to get really hard to debug and ensure
that everything is correct on the shutdown/release path.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "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 3/5] tee: generic TEE subsystem

[Greg Kroah-Hartman]

On Wed, Jul 08, 2015 at 04:28:26PM -0700, Dmitry Torokhov wrote:
> On Wed, Jul 08, 2015 at 03:33:25PM -0700, Greg Kroah-Hartman wrote:
> > On Wed, Jul 08, 2015 at 04:26:49PM -0600, Jason Gunthorpe wrote:
> > > On Wed, Jul 08, 2015 at 02:11:29PM -0700, Greg Kroah-Hartman wrote:
> > > > > > +   cdev_init(&teedev->cdev, &tee_fops);
> > > > > > +   teedev->cdev.owner = teedesc->owner;
> > > > > 
> > > > > This also needs to set teedev->cdev.kobj.parent.
> > > > > I'm guessing:
> > > > > 
> > > > >  teedev->cdev.kobj.parent = &teedev->dev.kobj;
> > > > > 
> > > > > TPM had the same mistake..
> > > > 
> > > > Really?  As of a few years ago, A cdev's kobject should not be touched
> > > > by anything other than the cdev core.  It's not a "real" kobject in that
> > > > it is never registered in sysfs, and no one sees it.  I keep meaning to
> > > 
> > > Well, when I looked at it, it looked like it was necessary to maintain
> > > the refcount on the memory that is holding cdev.
> > > 
> > > The basic issue is that cdev_del doesn't seem to be synchronizing.
> > > 
> > > The use after free race is then something like:
> > > 
> > >struct tpm_chip {
> > >   struct device dev;
> > >   struct cdev cdev;
> > 
> > Oops, right there's your problem.  You can't have two reference counted
> > objects trying to manage the memory of a single structure.  No matter
> > what you do, it's going to be a pain to deal with this, so don't :)
> > 
> > > 
> > >CPU0CPU1
> > > = ==
> > > tpm_chip = kalloc
> > > cdev_add(&tpm_chip->cdev)
> > > device_add(&tpm_chip->dev)
> > > chrdev_open
> > >filp->f_op->open
> > > cdev_del(&tpm_chip->cdev)
> > > device_unregister
> > >(&tpm_chip->dev)
> > >  kfree(tpm_chip)
> > > tpm_chip = container_of
> > >fput
> > > cdev_put(.. cdev)
> > > 
> > > Ie we need cdev to hold a ref on tpm_chip->dev until cdev_put is
> > > called.
> > 
> > No, separate them, make the cdev a pointer and all should be fine.
> > 
> > > > just use something else one of these days for that structure, as lots of
> > > > people get it wrong.  Or has things changed there?
> > > 
> > > Not recently, but this is the commit:
> > > 
> > > commit 2f0157f13f42800aa3d9017ebb0fb80a65f7b2de
> > > Author: Dmitry Torokhov 
> > > Date:   Sun Oct 21 17:57:19 2012 -0700
> > > 
> > > char_dev: pin parent kobject
> > > 
> > > In certain cases (for example when a cdev structure is embedded into
> > > another object whose lifetime is controlled by a separate kobject) it 
> > > is
> > > beneficial to tie lifetime of another object to the lifetime of
> > > character device so that related object is not freed until after
> > > char_dev object is freed.
> > > 
> > > To achieve this let's pin kobject's parent when doing cdev_add() and
> > > unpin when last reference to cdev structure is being released.
> > > 
> > > Signed-off-by: Dmitry Torokhov 
> > > Acked-by: Al Viro 
> > > Signed-off-by: Linus Torvalds 
> > > 
> > > It doesn't seem the be the best situation, this is the 3rd time this
> > > week I've noticed cdev with a kalloc'd struct being used improperly.
> > > 
> > > Perhaps cdev_init should accept the module and kref parent as an
> > > argument?
> > 
> > Oh yeah, that commit :(
> > 
> > If you know _exactly_ what you are doing, you can get away with this,
> > but I strongly recommend not doing that.  As proof of that, in some new
> > code I'm working on, I did not do this, just because I'm not smart
> > enough to ensure it's all working properly...
> 
> I know you like to allocate everything separately and access it via
> pointers (ala device_create) but cdevs explicitly allow embedding them
> into other structures (cdev_init vs cdev_alloc). I do not think there is
> anything wrong with this, as well as there is nothing wrong in embedding
> a struct device into other structures, but it does require coordinating
> lifetime rules and selecting a "master" kobject. I think having
> cdev_init accept such "master" kobject would bring author's attention to
> the issue and avoid such mistakes in the future.

Embedding cdevs into other structures is great, I like that.  What I
don't like is having two different reference counts for the same
structure based on the lifetime rules of two different embedded
structures.  That's a very difficult thing to get right and I would
argue, is something that should almost never be done.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "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/4] ARM: dts: Use labels instead of full paths for Exynos5 pinctrl nodes

[Krzysztof Kozlowski]

On 08.07.2015 23:15, Javier Martinez Canillas wrote:
> Krzysztof,
> 
> On 07/08/2015 01:27 AM, Krzysztof Kozlowski wrote:
>> On 08.07.2015 14:36, Javier Martinez Canillas wrote:
>>> Hello Kukjin and Krzysztof,
>>>
>>> This is a trivial series that changes Exynos5 pinctrl dtsi files to extend
>>> the pinctrl nodes using labels instead of full paths.
>>>
>>> Using labels is less error prone since a misstyped label leads to a build
>>> error while full paths can lead to the creation of a new node instead of
>>> overriding the original which makes the mistake harder to detect.
>>>
>>> I tested the changes by decompiling the Exynos5* dtbs and comparing before
>>> and after. The resulting dts were identical modulo some node ordering due
>>> the pinctrl include change.
>>
>> Is the DTB before and after the same? It should not change by re-ordering.
>>
> 
> The DTB differ but I'm not that familiar with how dtc represents the FDT
> to know what is changing in the binary.
> 
> But as mentioned, the decompiled DTS only changes in which position the
> pinctrl are defined and both DTS are identical if I do:
> 
> $ cat decompiled.dts | sort

Right, the DTB may differ because of change of definition's location. If
sorting fixes this then I'm convinced.

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 3/5] tee: generic TEE subsystem

[Dmitry Torokhov]

On Wed, Jul 08, 2015 at 03:33:25PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Jul 08, 2015 at 04:26:49PM -0600, Jason Gunthorpe wrote:
> > On Wed, Jul 08, 2015 at 02:11:29PM -0700, Greg Kroah-Hartman wrote:
> > > > > +   cdev_init(&teedev->cdev, &tee_fops);
> > > > > +   teedev->cdev.owner = teedesc->owner;
> > > > 
> > > > This also needs to set teedev->cdev.kobj.parent.
> > > > I'm guessing:
> > > > 
> > > >  teedev->cdev.kobj.parent = &teedev->dev.kobj;
> > > > 
> > > > TPM had the same mistake..
> > > 
> > > Really?  As of a few years ago, A cdev's kobject should not be touched
> > > by anything other than the cdev core.  It's not a "real" kobject in that
> > > it is never registered in sysfs, and no one sees it.  I keep meaning to
> > 
> > Well, when I looked at it, it looked like it was necessary to maintain
> > the refcount on the memory that is holding cdev.
> > 
> > The basic issue is that cdev_del doesn't seem to be synchronizing.
> > 
> > The use after free race is then something like:
> > 
> >struct tpm_chip {
> > struct device dev;
> > struct cdev cdev;
> 
> Oops, right there's your problem.  You can't have two reference counted
> objects trying to manage the memory of a single structure.  No matter
> what you do, it's going to be a pain to deal with this, so don't :)
> 
> > 
> >CPU0CPU1
> > = ==
> > tpm_chip = kalloc
> > cdev_add(&tpm_chip->cdev)
> > device_add(&tpm_chip->dev)
> > chrdev_open
> >  filp->f_op->open
> > cdev_del(&tpm_chip->cdev)
> > device_unregister
> >(&tpm_chip->dev)
> >  kfree(tpm_chip)
> >   tpm_chip = container_of
> >  fput
> >   cdev_put(.. cdev)
> > 
> > Ie we need cdev to hold a ref on tpm_chip->dev until cdev_put is
> > called.
> 
> No, separate them, make the cdev a pointer and all should be fine.
> 
> > > just use something else one of these days for that structure, as lots of
> > > people get it wrong.  Or has things changed there?
> > 
> > Not recently, but this is the commit:
> > 
> > commit 2f0157f13f42800aa3d9017ebb0fb80a65f7b2de
> > Author: Dmitry Torokhov 
> > Date:   Sun Oct 21 17:57:19 2012 -0700
> > 
> > char_dev: pin parent kobject
> > 
> > In certain cases (for example when a cdev structure is embedded into
> > another object whose lifetime is controlled by a separate kobject) it is
> > beneficial to tie lifetime of another object to the lifetime of
> > character device so that related object is not freed until after
> > char_dev object is freed.
> > 
> > To achieve this let's pin kobject's parent when doing cdev_add() and
> > unpin when last reference to cdev structure is being released.
> > 
> > Signed-off-by: Dmitry Torokhov 
> > Acked-by: Al Viro 
> > Signed-off-by: Linus Torvalds 
> > 
> > It doesn't seem the be the best situation, this is the 3rd time this
> > week I've noticed cdev with a kalloc'd struct being used improperly.
> > 
> > Perhaps cdev_init should accept the module and kref parent as an
> > argument?
> 
> Oh yeah, that commit :(
> 
> If you know _exactly_ what you are doing, you can get away with this,
> but I strongly recommend not doing that.  As proof of that, in some new
> code I'm working on, I did not do this, just because I'm not smart
> enough to ensure it's all working properly...

I know you like to allocate everything separately and access it via
pointers (ala device_create) but cdevs explicitly allow embedding them
into other structures (cdev_init vs cdev_alloc). I do not think there is
anything wrong with this, as well as there is nothing wrong in embedding
a struct device into other structures, but it does require coordinating
lifetime rules and selecting a "master" kobject. I think having
cdev_init accept such "master" kobject would bring author's attention to
the issue and avoid such mistakes in the future.

Thanks.

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

Re: [PATCH v4 3/5] tee: generic TEE subsystem

[Jason Gunthorpe]

On Wed, Jul 08, 2015 at 03:33:25PM -0700, Greg Kroah-Hartman wrote:
> > The basic issue is that cdev_del doesn't seem to be synchronizing.
> > 
> > The use after free race is then something like:
> > 
> >struct tpm_chip {
> > struct device dev;
> > struct cdev cdev;
> 
> Oops, right there's your problem.  You can't have two reference counted
> objects trying to manage the memory of a single structure.  No matter
> what you do, it's going to be a pain to deal with this, so don't :)

Sure, generally, yes, but that isn't done for no reason, it is to make
open straightforward:

static int tpm_open(struct inode *inode, struct file *file)
{
struct tpm_chip *chip =
container_of(inode->i_cdev, struct tpm_chip, cdev);

We need to recover the tpm_chip associated with the char device
node, in a way that is holding a kref on it, without racing with
cdev_del/etc

This scheme does mean that if we have a struct file we have a kref on
the cdev, and if we have cdev then we have a kref on the tpm_chip,
which is really easy to use properly.

> > Ie we need cdev to hold a ref on tpm_chip->dev until cdev_put is
> > called.
> 
> No, separate them, make the cdev a pointer and all should be fine.

Okay, cdev_alloc takes care of the cdev lifetime.

Do you have a simple solution to replace container_of as well?

What would you think about something like:

 cdev_alloc(&chip->dev.kref)

?

Jason
--
To unsubscribe from this list: send the line "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 3/5] tee: generic TEE subsystem

[Greg Kroah-Hartman]

On Wed, Jul 08, 2015 at 04:26:49PM -0600, Jason Gunthorpe wrote:
> On Wed, Jul 08, 2015 at 02:11:29PM -0700, Greg Kroah-Hartman wrote:
> > > > +   cdev_init(&teedev->cdev, &tee_fops);
> > > > +   teedev->cdev.owner = teedesc->owner;
> > > 
> > > This also needs to set teedev->cdev.kobj.parent.
> > > I'm guessing:
> > > 
> > >  teedev->cdev.kobj.parent = &teedev->dev.kobj;
> > > 
> > > TPM had the same mistake..
> > 
> > Really?  As of a few years ago, A cdev's kobject should not be touched
> > by anything other than the cdev core.  It's not a "real" kobject in that
> > it is never registered in sysfs, and no one sees it.  I keep meaning to
> 
> Well, when I looked at it, it looked like it was necessary to maintain
> the refcount on the memory that is holding cdev.
> 
> The basic issue is that cdev_del doesn't seem to be synchronizing.
> 
> The use after free race is then something like:
> 
>struct tpm_chip {
>   struct device dev;
>   struct cdev cdev;

Oops, right there's your problem.  You can't have two reference counted
objects trying to manage the memory of a single structure.  No matter
what you do, it's going to be a pain to deal with this, so don't :)

> 
>CPU0CPU1
> = ==
> tpm_chip = kalloc
> cdev_add(&tpm_chip->cdev)
> device_add(&tpm_chip->dev)
> chrdev_open
>filp->f_op->open
> cdev_del(&tpm_chip->cdev)
> device_unregister
>(&tpm_chip->dev)
>  kfree(tpm_chip)
> tpm_chip = container_of
>fput
> cdev_put(.. cdev)
> 
> Ie we need cdev to hold a ref on tpm_chip->dev until cdev_put is
> called.

No, separate them, make the cdev a pointer and all should be fine.

> > just use something else one of these days for that structure, as lots of
> > people get it wrong.  Or has things changed there?
> 
> Not recently, but this is the commit:
> 
> commit 2f0157f13f42800aa3d9017ebb0fb80a65f7b2de
> Author: Dmitry Torokhov 
> Date:   Sun Oct 21 17:57:19 2012 -0700
> 
> char_dev: pin parent kobject
> 
> In certain cases (for example when a cdev structure is embedded into
> another object whose lifetime is controlled by a separate kobject) it is
> beneficial to tie lifetime of another object to the lifetime of
> character device so that related object is not freed until after
> char_dev object is freed.
> 
> To achieve this let's pin kobject's parent when doing cdev_add() and
> unpin when last reference to cdev structure is being released.
> 
> Signed-off-by: Dmitry Torokhov 
> Acked-by: Al Viro 
> Signed-off-by: Linus Torvalds 
> 
> It doesn't seem the be the best situation, this is the 3rd time this
> week I've noticed cdev with a kalloc'd struct being used improperly.
> 
> Perhaps cdev_init should accept the module and kref parent as an
> argument?

Oh yeah, that commit :(

If you know _exactly_ what you are doing, you can get away with this,
but I strongly recommend not doing that.  As proof of that, in some new
code I'm working on, I did not do this, just because I'm not smart
enough to ensure it's all working properly...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "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 4/6] ARM: vf610: enable NAND Flash Controller

[Sebastian Andrzej Siewior]

On Wed, Jul 08, 2015 at 10:32:54AM -0400, Bill Pringlemeir wrote:
> >> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> >> index 3a3d3e9..9358135 100644
> >> --- a/arch/arm/mach-imx/Kconfig
> >> +++ b/arch/arm/mach-imx/Kconfig
>  -589,6 +589,7 @@ config SOC_VF610
> >>select PINCTRL_VF610
> >>select PL310_ERRATA_769419 if CACHE_L2X0
> >>select SMP_ON_UP if SMP
> >> +  select HAVE_NAND_VF610_NFC
> 
> > I'm not sure about the benefit of having this option, except we have
> > to have this additional architecture patch.
> 
> For other SOC, like the PowerPC or ColdFire CPUs with this controller,
> it was a way to mark the controller as populated.  Otherwise, the
> Kconfig entry to select the controller will pop up for everybody.
> 
> Is there a better way to do this?

use
depends on SOC_VF610
instead.

Sebastian
--
To unsubscribe from this list: send the line "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 3/5] tee: generic TEE subsystem

[Jason Gunthorpe]

On Wed, Jul 08, 2015 at 02:11:29PM -0700, Greg Kroah-Hartman wrote:
> > > +   cdev_init(&teedev->cdev, &tee_fops);
> > > +   teedev->cdev.owner = teedesc->owner;
> > 
> > This also needs to set teedev->cdev.kobj.parent.
> > I'm guessing:
> > 
> >  teedev->cdev.kobj.parent = &teedev->dev.kobj;
> > 
> > TPM had the same mistake..
> 
> Really?  As of a few years ago, A cdev's kobject should not be touched
> by anything other than the cdev core.  It's not a "real" kobject in that
> it is never registered in sysfs, and no one sees it.  I keep meaning to

Well, when I looked at it, it looked like it was necessary to maintain
the refcount on the memory that is holding cdev.

The basic issue is that cdev_del doesn't seem to be synchronizing.

The use after free race is then something like:

   struct tpm_chip {
struct device dev;
struct cdev cdev;

   CPU0CPU1
= ==
tpm_chip = kalloc
cdev_add(&tpm_chip->cdev)
device_add(&tpm_chip->dev)
chrdev_open
 filp->f_op->open
cdev_del(&tpm_chip->cdev)
device_unregister
   (&tpm_chip->dev)
 kfree(tpm_chip)
  tpm_chip = container_of
 fput
  cdev_put(.. cdev)

Ie we need cdev to hold a ref on tpm_chip->dev until cdev_put is
called.

> just use something else one of these days for that structure, as lots of
> people get it wrong.  Or has things changed there?

Not recently, but this is the commit:

commit 2f0157f13f42800aa3d9017ebb0fb80a65f7b2de
Author: Dmitry Torokhov 
Date:   Sun Oct 21 17:57:19 2012 -0700

char_dev: pin parent kobject

In certain cases (for example when a cdev structure is embedded into
another object whose lifetime is controlled by a separate kobject) it is
beneficial to tie lifetime of another object to the lifetime of
character device so that related object is not freed until after
char_dev object is freed.

To achieve this let's pin kobject's parent when doing cdev_add() and
unpin when last reference to cdev structure is being released.

Signed-off-by: Dmitry Torokhov 
Acked-by: Al Viro 
Signed-off-by: Linus Torvalds 

It doesn't seem the be the best situation, this is the 3rd time this
week I've noticed cdev with a kalloc'd struct being used improperly.

Perhaps cdev_init should accept the module and kref parent as an
argument?

Jason
--
To unsubscribe from this list: send the line "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] GICv3: Add ITS entry to THUNDER dts

[Kevin Hilman]

Catalin Marinas  writes:

> On Thu, Jul 02, 2015 at 08:26:02PM +, Chalamarla, Tirumalesh wrote:
>> > On Jun 26, 2015, at 12:12 PM, Tirumalesh Chalamarla 
>> >  wrote:
>> > 
>> > From: Tirumalesh Chalamarla 
>> > 
>> > The PCIe host controller uses MSIs provided by GICv3 ITS. Enable it on
>> > Thunder SoCs by adding an entry to DT.
>> > 
>> > Signed-off-by: Tirumalesh Chalamarla 
>> > Acked-by: Marc Zyngier 
>> > ---
>> > arch/arm64/boot/dts/cavium/thunder-88xx.dtsi | 9 +
>> > 1 file changed, 9 insertions(+)
>> > 
>> > diff --git a/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi 
>> > b/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
>> > index d8c0bdc..9cb7cf9 100644
>> > --- a/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
>> > +++ b/arch/arm64/boot/dts/cavium/thunder-88xx.dtsi
>> > @@ -376,10 +376,19 @@
>> >gic0: interrupt-controller@8010, {
>> >compatible = "arm,gic-v3";
>> >#interrupt-cells = <3>;
>> > +  #address-cells = <2>;
>> > +  #size-cells = <2>;
>> > +  ranges;
>> >interrupt-controller;
>> >reg = <0x8010 0x 0x0 0x01>, /* GICD */
>> >  <0x8010 0x8000 0x0 0x60>; /* GICR */
>> >interrupts = <1 9 0xf04>;
>> > +
>> > +  its: gic-its@8010,0002 {
>> > +  compatible = "arm,gic-v3-its";
>> > +  msi-controller;
>> > +  reg = <0x8010 0x2 0x0 0x20>;
>> > +  };
>> >};
>> > 
>> >uaa0: serial@87e0,2400 {
>> 
>> is it possible to pull this for 4.2?
>
> The dts files go in via the arm-soc tree (cc'ing a...@kernel.org).

Picked this up for v4.2-rc,

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

Re: [PATCH v4 3/5] tee: generic TEE subsystem

[Greg Kroah-Hartman]

On Wed, Jul 08, 2015 at 11:10:26AM -0600, Jason Gunthorpe wrote:
> On Wed, Jul 08, 2015 at 12:16:30PM +0200, Jens Wiklander wrote:
> 
> > +static void tee_device_complete_unused(struct kref *kref)
> > +{
> > +   struct tee_device *teedev;
> > +
> > +   teedev = container_of(kref, struct tee_device, users);
> > +   /* When the mutex is released, no other tee_device_get() will succeed */
> > +   teedev->desc = NULL;
> > +   complete(&teedev->c_no_users);
> > +}
> > +
> > +void tee_device_put(struct tee_device *teedev)
> > +{
> > +   mutex_lock(&teedev->mutex);
> > +   /* Shouldn't put in this state */
> > +   if (!WARN_ON(!teedev->desc))
> > +   kref_put(&teedev->users, tee_device_complete_unused);
> > +   mutex_unlock(&teedev->mutex);
> > +}
> > +
> > +bool tee_device_get(struct tee_device *teedev)
> > +{
> > +   mutex_lock(&teedev->mutex);
> > +   if (!teedev->desc) {
> > +   mutex_unlock(&teedev->mutex);
> > +   return false;
> > +   }
> > +   kref_get(&teedev->users);
> > +   mutex_unlock(&teedev->mutex);
> > +   return true;
> > +}
> 
> If you are holding the mutex then you don't really need a kref, just a
> simple active count counter.
> 
> I've been a bit learly lately about seeing krefs used for something
> other than kfree, I've seen a few subtle mistakes in those schemes -
> yours looks OK, only because of the lock, and the lock makes the kref
> redundant..
> 
> > +   cdev_init(&teedev->cdev, &tee_fops);
> > +   teedev->cdev.owner = teedesc->owner;
> 
> This also needs to set teedev->cdev.kobj.parent.
> I'm guessing:
> 
>  teedev->cdev.kobj.parent = &teedev->dev.kobj;
> 
> TPM had the same mistake..

Really?  As of a few years ago, A cdev's kobject should not be touched
by anything other than the cdev core.  It's not a "real" kobject in that
it is never registered in sysfs, and no one sees it.  I keep meaning to
just use something else one of these days for that structure, as lots of
people get it wrong.  Or has things changed there?

thanks,

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

Re: [PATCH v1] arm64: dts: Add poweroff button device node for APM X-Gene platform

[Kevin Hilman]

Y Vo  writes:

> This patch adds poweroff button device node to support poweroff feature
> on APM X-Gene Mustang platform.
>
> Signed-off-by: Y Vo 

Picking this up for v4.2-rc.

Applied to fixes branch,

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

Re: [PATCH v1 3/3] ARM: tegra: Add gpio-ranges property

[Stephen Warren]

On 07/01/2015 06:45 AM, Tomeu Vizoso wrote:

Specify how the GPIOs map to the pins in Tegra SoCs, so the dependency is
explicit.

This currently will add a duplicated entry in the map from pins to gpios
in the pinmux controller but it should be harmless and will be fixed in a
later commit.


Isn't it in an earlier commit now (patch 2/3)? :-)

At a quick glance, I think this approach will be fine, so the series,
Acked-by: Stephen Warren 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/1] Add support for esdhc0 on Vybrid.

[Cory Tusar]

Currently, only esdhc1 is described in vfxxx.dtsi.  This quick patch
adds support for esdhc0 also.

Regards,
-Cory


Cory Tusar (1):
  ARM: dts: vfxxx: Include support for esdhc0 functionality.

 arch/arm/boot/dts/vfxxx.dtsi | 11 +++
 1 file changed, 11 insertions(+)

-- 
2.3.6

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

[PATCH 1/1] ARM: dts: vfxxx: Include support for esdhc0 functionality.

[Cory Tusar]

Extend the existing Vybrid eSDHC devicetree implementation to also
describe the esdhc0 functional block.

Tested on a custom VF610-based board with a Toshiba THGBM1G5D2EBAI7 eMMC
module attached to esdhc0.

Signed-off-by: Cory Tusar 
---
 arch/arm/boot/dts/vfxxx.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 4aa3351..7e97017 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -445,6 +445,17 @@
status = "disabled";
};
 
+   esdhc0: esdhc@400b1000 {
+   compatible = "fsl,imx53-esdhc";
+   reg = <0x400b1000 0x1000>;
+   interrupts = <27 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks VF610_CLK_IPG_BUS>,
+   <&clks VF610_CLK_PLATFORM_BUS>,
+   <&clks VF610_CLK_ESDHC0>;
+   clock-names = "ipg", "ahb", "per";
+   status = "disabled";
+   };
+
esdhc1: esdhc@400b2000 {
compatible = "fsl,imx53-esdhc";
reg = <0x400b2000 0x1000>;
-- 
2.3.6

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

[PATCH v1 7/7] ARM: dts: vf610-twr: Enable QSPI and map flash devices.

[Cory Tusar]

This commit enables the qspi0 functional block, and maps the two
flash devices connected to QSPI0_A_CS0 and QSPI0_B_CS0 to individual MTD
devices.

Tested using mtd_readtest, mtd_speedtest, and mtd_stresstest on a Rev. H
TWR board.

Signed-off-by: Cory Tusar 
---
 arch/arm/boot/dts/vf610-twr.dts | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 375ab23..6ae2e7c 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -246,6 +246,23 @@
>;
};
 
+   pinctrl_qspi0: qspi0grp {
+   fsl,pins = <
+   VF610_PAD_PTD0__QSPI0_A_QSCK0x31e2
+   VF610_PAD_PTD1__QSPI0_A_CS0 0x31e2
+   VF610_PAD_PTD2__QSPI0_A_DATA3   0x31e3
+   VF610_PAD_PTD3__QSPI0_A_DATA2   0x31e3
+   VF610_PAD_PTD4__QSPI0_A_DATA1   0x31e3
+   VF610_PAD_PTD5__QSPI0_A_DATA0   0x31e3
+   VF610_PAD_PTD7__QSPI0_B_QSCK0x31e2
+   VF610_PAD_PTD8__QSPI0_B_CS0 0x31e2
+   VF610_PAD_PTD9__QSPI0_B_DATA3   0x31e3
+   VF610_PAD_PTD10__QSPI0_B_DATA2  0x31e3
+   VF610_PAD_PTD11__QSPI0_B_DATA1  0x31e3
+   VF610_PAD_PTD12__QSPI0_B_DATA0  0x31e3
+   >;
+   };
+
pinctrl_sai2: sai2grp {
fsl,pins = <
VF610_PAD_PTA16__SAI2_TX_BCLK   0x02ed
@@ -280,6 +297,28 @@
status = "okay";
 };
 
+&qspi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_qspi0>;
+   status = "okay";
+
+   flash0: s25fl128s@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spansion,s25fl128s";
+   spi-max-frequency = <6600>;
+   reg = <0>;
+   };
+
+   flash1: s25fl128s@2 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spansion,s25fl128s";
+   spi-max-frequency = <6600>;
+   reg = <2>;
+   };
+};
+
 &sai2 {
#sound-dai-cells = <0>;
pinctrl-names = "default";
-- 
2.3.6

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

[PATCH v1 5/7] mtd: fsl-quadspi: Allow non-contiguous flash layouts.

[Cory Tusar]

The current fsl-quadspi implementation assumes that the first NOR device
is always physically connected to QSPIn_A_CS0, and that all connected
devices are of the same type.

This commit separates the DT parsing and flash probe logic into two
passes, allowing devices of different sizes and types to be attached in
arbitrary order to the various chip selects associated with each QSPI
interface.

Tested on a custom VF610-based board with a single SPI NOR connected to
QSPI0_B_CS0, and also on a Rev. H TWR board with dual SPI NOR devices
connected to QSPI0_A_CS0 and QSPI0_B_CS0.

Signed-off-by: Cory Tusar 
---
 .../devicetree/bindings/mtd/fsl-quadspi.txt|  15 +-
 drivers/mtd/spi-nor/fsl-quadspi.c  | 166 +
 2 files changed, 106 insertions(+), 75 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt 
b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
index 4461dc7..e392156 100644
--- a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
@@ -9,15 +9,6 @@ Required properties:
   - clocks : The clocks needed by the QuadSPI controller
   - clock-names : the name of the clocks
 
-Optional properties:
-  - fsl,qspi-has-second-chip: The controller has two buses, bus A and bus B.
-  Each bus can be connected with two NOR flashes.
- Most of the time, each bus only has one NOR flash
- connected, this is the default case.
- But if there are two NOR flashes connected to the
- bus, you should enable this property.
- (Please check the board's schematic.)
-
 Example:
 
 qspi0: quadspi@40044000 {
@@ -30,6 +21,12 @@ qspi0: quadspi@40044000 {
clock-names = "qspi_en", "qspi";
 
flash0: s25fl128s@0 {
+   reg = <0>;  /* QSPI0_A_CS0 */
+   
+   };
+
+   flash1: s25fl128s@3 {
+   reg = <3>;  /* QSPI0_B_CS1 */

};
 };
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c 
b/drivers/mtd/spi-nor/fsl-quadspi.c
index d0cf0b7..3c378f0 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -221,6 +221,7 @@ static struct fsl_qspi_devtype_data imx6sx_data = {
 };
 
 #define FSL_QSPI_MAX_CHIP  4
+#define MODALIAS_NBYTES40
 struct fsl_qspi {
struct mtd_info mtd[FSL_QSPI_MAX_CHIP];
struct spi_nor nor[FSL_QSPI_MAX_CHIP];
@@ -231,11 +232,10 @@ struct fsl_qspi {
struct device *dev;
struct completion c;
struct fsl_qspi_devtype_data *devtype_data;
-   u32 nor_size;
-   u32 nor_num;
+   char modalias[FSL_QSPI_MAX_CHIP][MODALIAS_NBYTES];
+   u32 nor_size[FSL_QSPI_MAX_CHIP];
u32 clk_rate[FSL_QSPI_MAX_CHIP];
unsigned int chip_base_addr; /* We may support two chips. */
-   bool has_second_chip;
 };
 
 static inline int is_vybrid_qspi(struct fsl_qspi *q)
@@ -429,8 +429,9 @@ static int fsl_qspi_get_seqid(struct fsl_qspi *q, u8 cmd, 
u8 addr_width)
 }
 
 static int
-fsl_qspi_runcmd(struct fsl_qspi *q, u8 cmd, unsigned int addr, int len)
+fsl_qspi_runcmd(struct spi_nor *nor, u8 cmd, unsigned int addr, int len)
 {
+   struct fsl_qspi *q = nor->priv;
void __iomem *base = q->iobase;
int seqid;
u32 reg, reg2;
@@ -459,7 +460,7 @@ fsl_qspi_runcmd(struct fsl_qspi *q, u8 cmd, unsigned int 
addr, int len)
} while (1);
 
/* trigger the LUT now */
-   seqid = fsl_qspi_get_seqid(q, cmd, q->nor[0].addr_width);
+   seqid = fsl_qspi_get_seqid(q, cmd, nor->addr_width);
writel((seqid << QUADSPI_IPCR_SEQID_SHIFT) | len, base + QUADSPI_IPCR);
 
/* Wait for the interrupt. */
@@ -550,7 +551,7 @@ static int fsl_qspi_nor_write(struct fsl_qspi *q, struct 
spi_nor *nor,
}
 
/* Trigger it */
-   ret = fsl_qspi_runcmd(q, opcode, to, count);
+   ret = fsl_qspi_runcmd(nor, opcode, to, count);
 
if (ret == 0 && retlen)
*retlen += count;
@@ -560,13 +561,17 @@ static int fsl_qspi_nor_write(struct fsl_qspi *q, struct 
spi_nor *nor,
 
 static void fsl_qspi_set_map_addr(struct fsl_qspi *q)
 {
-   int nor_size = q->nor_size;
void __iomem *base = q->iobase;
-
-   writel(nor_size + q->memmap_phy, base + QUADSPI_SFA1AD);
-   writel(nor_size * 2 + q->memmap_phy, base + QUADSPI_SFA2AD);
-   writel(nor_size * 3 + q->memmap_phy, base + QUADSPI_SFB1AD);
-   writel(nor_size * 4 + q->memmap_phy, base + QUADSPI_SFB2AD);
+   int offset = 0;
+
+   offset += q->nor_size[0];
+   writel(q->memmap_phy + offset, base + QUADSPI_SFA1AD);
+   offset += q->nor_size[1];
+   writel(q->memmap_phy + offset, base + QUADSPI_SFA2AD);
+   offset += q->nor_size[2];
+   writel(q->memmap_phy + offset, base + QUADSPI_SFB1AD);
+   offset += q->nor

[PATCH v1 6/7] mtd: spi-nor: Add support for Micron MT25QL02GC serial flash.

[Cory Tusar]

Add Micron (mt25ql02gc) 256 MiB flash to the list of supported devices.

Signed-off-by: Cory Tusar 
---
 drivers/mtd/spi-nor/spi-nor.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index d78831b..7a8896d 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -596,6 +596,7 @@ static const struct spi_device_id spi_nor_ids[] = {
{ "n25q512a",INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ) },
{ "n25q512ax3",  INFO(0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ) },
{ "n25q00",  INFO(0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | 
SPI_NOR_QUAD_READ) },
+   { "mt25ql02gc",  INFO(0x20ba22, 0, 64 * 1024, 4096, SPI_NOR_QUAD_READ) 
},
 
/* PMC */
{ "pm25lv512",   INFO(0,0, 32 * 1024,2, SECT_4K_PMC) },
-- 
2.3.6

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

[PATCH v1 2/7] ARM: dts: vfxxx: Include support for qspi1 functionality.

[Cory Tusar]

This commit extends the existing Vybrid QSPI devicetree implementation
to also describe the qspi1 functional block.

Signed-off-by: Cory Tusar 
Reviewed-by: Stefan Agner 
---
 arch/arm/boot/dts/vfxxx.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 089a263..9554f3d 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -489,6 +489,19 @@
status = "disabled";
};
 
+   qspi1: quadspi@400c4000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-qspi";
+   reg = <0x400c4000 0x1000>, <0x5000 
0x1000>;
+   reg-names = "QuadSPI", "QuadSPI-memory";
+   interrupts = <25 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks VF610_CLK_QSPI1_EN>,
+   <&clks VF610_CLK_QSPI1>;
+   clock-names = "qspi_en", "qspi";
+   status = "disabled";
+   };
+
fec0: ethernet@400d {
compatible = "fsl,mvf600-fec";
reg = <0x400d 0x1000>;
-- 
2.3.6

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

[PATCH v1 3/7] mtd: fsl-quadspi: Support both 24- and 32-bit addressed commands.

[Cory Tusar]

The current fsl-quadspi implementation assumes that all connected
devices are of the same size and type.  This commit adds lookup table
entries for both 24- and 32-bit addressed variants of the read, sector
erase, and page program operations as a precursor to later changes which
generalize the flash layout parsing logic and allow for non-contiguous
and non-homogeneous chip combinations.

Signed-off-by: Cory Tusar 
---
 drivers/mtd/spi-nor/fsl-quadspi.c | 116 --
 1 file changed, 60 insertions(+), 56 deletions(-)

diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c 
b/drivers/mtd/spi-nor/fsl-quadspi.c
index 52a872f..4b8038b 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -178,18 +178,21 @@
 #define QUADSPI_LUT_NUM64
 
 /* SEQID -- we can have 16 seqids at most. */
-#define SEQID_QUAD_READ0
-#define SEQID_WREN 1
-#define SEQID_WRDI 2
-#define SEQID_RDSR 3
-#define SEQID_SE   4
-#define SEQID_CHIP_ERASE   5
-#define SEQID_PP   6
-#define SEQID_RDID 7
-#define SEQID_WRSR 8
-#define SEQID_RDCR 9
-#define SEQID_EN4B 10
-#define SEQID_BRWR 11
+#define SEQID_QUAD_READ_24 0
+#define SEQID_QUAD_READ_32 1
+#define SEQID_WREN 2
+#define SEQID_WRDI 3
+#define SEQID_RDSR 4
+#define SEQID_SE_245
+#define SEQID_SE_325
+#define SEQID_CHIP_ERASE   7
+#define SEQID_PP_248
+#define SEQID_PP_328
+#define SEQID_RDID 9
+#define SEQID_WRSR 10
+#define SEQID_RDCR 11
+#define SEQID_EN4B 12
+#define SEQID_BRWR 13
 
 enum fsl_qspi_devtype {
FSL_QUADSPI_VYBRID,
@@ -287,7 +290,6 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
void __iomem *base = q->iobase;
int rxfifo = q->devtype_data->rxfifo;
u32 lut_base;
-   u8 cmd, addrlen, dummy;
int i;
 
fsl_qspi_unlock_lut(q);
@@ -297,22 +299,16 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
writel(0, base + QUADSPI_LUT_BASE + i * 4);
 
/* Quad Read */
-   lut_base = SEQID_QUAD_READ * 4;
-
-   if (q->nor_size <= SZ_16M) {
-   cmd = SPINOR_OP_READ_1_1_4;
-   addrlen = ADDR24BIT;
-   dummy = 8;
-   } else {
-   /* use the 4-byte address */
-   cmd = SPINOR_OP_READ_1_1_4;
-   addrlen = ADDR32BIT;
-   dummy = 8;
-   }
+   lut_base = SEQID_QUAD_READ_24 * 4;
+   writel(LUT0(CMD, PAD1, SPINOR_OP_READ_1_1_4) | LUT1(ADDR, PAD1, 
ADDR24BIT),
+   base + QUADSPI_LUT(lut_base));
+   writel(LUT0(DUMMY, PAD1, 8) | LUT1(READ, PAD4, rxfifo),
+   base + QUADSPI_LUT(lut_base + 1));
 
-   writel(LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
+   lut_base = SEQID_QUAD_READ_32 * 4;
+   writel(LUT0(CMD, PAD1, SPINOR_OP_READ_1_1_4) | LUT1(ADDR, PAD1, 
ADDR32BIT),
base + QUADSPI_LUT(lut_base));
-   writel(LUT0(DUMMY, PAD1, dummy) | LUT1(READ, PAD4, rxfifo),
+   writel(LUT0(DUMMY, PAD1, 8) | LUT1(READ, PAD4, rxfifo),
base + QUADSPI_LUT(lut_base + 1));
 
/* Write enable */
@@ -320,18 +316,13 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
writel(LUT0(CMD, PAD1, SPINOR_OP_WREN), base + QUADSPI_LUT(lut_base));
 
/* Page Program */
-   lut_base = SEQID_PP * 4;
-
-   if (q->nor_size <= SZ_16M) {
-   cmd = SPINOR_OP_PP;
-   addrlen = ADDR24BIT;
-   } else {
-   /* use the 4-byte address */
-   cmd = SPINOR_OP_PP;
-   addrlen = ADDR32BIT;
-   }
+   lut_base = SEQID_PP_24 * 4;
+   writel(LUT0(CMD, PAD1, SPINOR_OP_PP) | LUT1(ADDR, PAD1, ADDR24BIT),
+   base + QUADSPI_LUT(lut_base));
+   writel(LUT0(WRITE, PAD1, 0), base + QUADSPI_LUT(lut_base + 1));
 
-   writel(LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
+   lut_base = SEQID_PP_32 * 4;
+   writel(LUT0(CMD, PAD1, SPINOR_OP_PP) | LUT1(ADDR, PAD1, ADDR32BIT),
base + QUADSPI_LUT(lut_base));
writel(LUT0(WRITE, PAD1, 0), base + QUADSPI_LUT(lut_base + 1));
 
@@ -341,18 +332,12 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
base + QUADSPI_LUT(lut_base));
 
/* Erase a sector */
-   lut_base = SEQID_SE * 4;
-
-   if (q->nor_size <= SZ_16M) {
-   cmd = SPINOR_OP_SE;
-   addrlen = ADDR24BIT;
-   } else {
-   /* use the 4-byte address */
-   cmd = SPINOR_OP_SE;
-   addrlen = ADDR32BIT;
-   }
+   lut_base = SEQID_SE_24 * 4;
+   writel(LUT0(CMD, PAD1, SPINOR_OP_SE) | LUT1(ADDR, PAD1, ADDR24BIT),
+

[PATCH v1 4/7] mtd: fsl-quadspi: Use per-device clk_rate.

[Cory Tusar]

The current fsl-quadspi implementation re-parses the 'spi-max-frequency'
property for each device, potentially allowing for an earlier, lower
frequency to be overwritten with a greater value.  This commit modifies
the parsing logic to extract the clock frequency for each flash device
and then configures for that frequency as part of the prepare() method
prior to accessing a given device.

Signed-off-by: Cory Tusar 
---
 drivers/mtd/spi-nor/fsl-quadspi.c | 41 +++
 1 file changed, 16 insertions(+), 25 deletions(-)

diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c 
b/drivers/mtd/spi-nor/fsl-quadspi.c
index 4b8038b..d0cf0b7 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -233,7 +233,7 @@ struct fsl_qspi {
struct fsl_qspi_devtype_data *devtype_data;
u32 nor_size;
u32 nor_num;
-   u32 clk_rate;
+   u32 clk_rate[FSL_QSPI_MAX_CHIP];
unsigned int chip_base_addr; /* We may support two chips. */
bool has_second_chip;
 };
@@ -645,25 +645,13 @@ static int fsl_qspi_nor_setup(struct fsl_qspi *q)
return 0;
 }
 
-static int fsl_qspi_nor_setup_last(struct fsl_qspi *q)
+static void fsl_qspi_nor_setup_last(struct fsl_qspi *q)
 {
-   unsigned long rate = q->clk_rate;
-   int ret;
-
-   if (is_imx6sx_qspi(q))
-   rate *= 4;
-
-   ret = clk_set_rate(q->clk, rate);
-   if (ret)
-   return ret;
-
/* Init the LUT table again. */
fsl_qspi_init_lut(q);
 
/* Init for AHB read */
fsl_qspi_init_abh_read(q);
-
-   return 0;
 }
 
 static const struct of_device_id fsl_qspi_dt_ids[] = {
@@ -763,6 +751,8 @@ static int fsl_qspi_erase(struct spi_nor *nor, loff_t offs)
 static int fsl_qspi_prep(struct spi_nor *nor, enum spi_nor_ops ops)
 {
struct fsl_qspi *q = nor->priv;
+   int nor_idx = nor - q->nor;
+   unsigned long rate = q->clk_rate[nor_idx];
int ret;
 
ret = clk_enable(q->clk_en);
@@ -775,6 +765,16 @@ static int fsl_qspi_prep(struct spi_nor *nor, enum 
spi_nor_ops ops)
return ret;
}
 
+   if (is_imx6sx_qspi(q))
+   rate *= 4;
+
+   ret = clk_set_rate(q->clk, rate);
+   if (ret) {
+   clk_disable(q->clk);
+   clk_disable(q->clk_en);
+   return ret;
+   }
+
fsl_qspi_set_base_addr(q, nor);
return 0;
 }
@@ -899,7 +899,7 @@ static int fsl_qspi_probe(struct platform_device *pdev)
goto irq_failed;
 
ret = of_property_read_u32(np, "spi-max-frequency",
-   &q->clk_rate);
+   &q->clk_rate[i]);
if (ret < 0)
goto irq_failed;
 
@@ -939,21 +939,12 @@ static int fsl_qspi_probe(struct platform_device *pdev)
}
 
/* finish the rest init. */
-   ret = fsl_qspi_nor_setup_last(q);
-   if (ret)
-   goto last_init_failed;
+   fsl_qspi_nor_setup_last(q);
 
clk_disable(q->clk);
clk_disable(q->clk_en);
return 0;
 
-last_init_failed:
-   for (i = 0; i < q->nor_num; i++) {
-   /* skip the holes */
-   if (!q->has_second_chip)
-   i *= 2;
-   mtd_device_unregister(&q->mtd[i]);
-   }
 irq_failed:
clk_disable_unprepare(q->clk);
 clk_failed:
-- 
2.3.6

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

[PATCH v1 0/7] fsl-quadspi: Allow additional device combinations.

[Cory Tusar]

This patch series fixes and extends the fsl-quadspi driver to allow for
non-contiguous and non-homogeneous SPI NOR device layouts.  The current
driver assumes that attached devices are all of the same type, and are
populated "in order" beginning with QSPIn_A_CS0.

The updated driver and DT changes make use of the 'reg' property
for each flash to determine the interface and chip select to which each
device is attached.

Patchset was tested on a custom VF610-based board with a single SPI NOR
connected to QSPI0_B_CS0, and also on a Rev. H TWR board with dual SPI
NOR devices connected to QSPI0_A_CS0 and QSPI0_B_CS0.  MTD tests passed
for all devices (readtest, speedtest, and stresstest), and independent
access to both devices was verified on the TWR system.

Regards,
-Cory


Changes since RFC:
- Rebased onto 4.2-rc1
- Moved the qspi1 node under aips1 where it belongs.


Cory Tusar (7):
  ARM: dts: vf610: Add missing QuadSPI register mapping and names.
  ARM: dts: vfxxx: Include support for qspi1 functionality.
  mtd: fsl-quadspi: Support both 24- and 32-bit addressed commands.
  mtd: fsl-quadspi: Use per-device clk_rate.
  mtd: fsl-quadspi: Allow non-contiguous flash layouts.
  mtd: spi-nor: Add support for Micron MT25QL02GC serial flash.
  ARM: dts: vf610-twr: Enable QSPI and map flash devices.

 .../devicetree/bindings/mtd/fsl-quadspi.txt|  15 +-
 arch/arm/boot/dts/vf610-twr.dts|  39 +++
 arch/arm/boot/dts/vfxxx.dtsi   |  16 +-
 drivers/mtd/spi-nor/fsl-quadspi.c  | 313 +++--
 drivers/mtd/spi-nor/spi-nor.c  |   1 +
 5 files changed, 232 insertions(+), 152 deletions(-)

-- 
2.3.6

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

[PATCH v1 1/7] ARM: dts: vf610: Add missing QuadSPI register mapping and names.

[Cory Tusar]

Both 'reg' and 'reg-names' are required properties according to binding
documentation, and both should contain two items.

Signed-off-by: Cory Tusar 
Acked-by: Stefan Agner 
---
 arch/arm/boot/dts/vfxxx.dtsi | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 4aa3351..089a263 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -242,7 +242,8 @@
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,vf610-qspi";
-   reg = <0x40044000 0x1000>;
+   reg = <0x40044000 0x1000>, <0x2000 
0x1000>;
+   reg-names = "QuadSPI", "QuadSPI-memory";
interrupts = <24 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks VF610_CLK_QSPI0_EN>,
<&clks VF610_CLK_QSPI0>;
-- 
2.3.6

--
To unsubscribe from this list: send the line "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] usb: common: add API to set usb otg capabilities by device tree

[Stephen Warren]

On 06/23/2015 05:56 AM, Roger Quadros wrote:

+ Kukjin, Stephen,

for board specific USB question.

On Tue, 23 Jun 2015 16:35:49 +0800
Li Jun  wrote:


On Tue, Jun 23, 2015 at 10:43:28AM +0300, Roger Quadros wrote:


If the dr_mode was "otg" for such case and we want OTG disabled then it is 
really the DT fault.


It's ID pin detect for dual role switch as many current OTG controllers have.
not DT fault, its dt only has a dr_mode = "otg".


We don't need to tackle this case. Just fix up the DT to dr_mode = "peripheral" 
if
OTG behaviour is not needed.


OTG behaviour is not needed, so we need disable HNP/SRP/ADP. but dr_mode =
"otg" as it already works fine with ID pin detect.


Do you know which platform has plain non-otg dual-role working as of today
with dr_mode set to "otg"?


I don't know.
The dt property dr_mode is already there, and currently there are some platforms
as its user, so I assume those platforms either are non-otg dual-role, or real 
OTG
with HNP supported, I guess most are the former cases; chipidea is the later 
case.


For TI platforms none of them have it working currently.


So for Ti platforms, some enables non-otg dual-role function but do not use
dr_mode = "otg"?


for TI we have only musb based and dwc3 based platforms. MUSB based are OTG.
dwc3 doesn't support dual-role or OTG yet so we use either "peripheral" or 
"Host"



For those only have non-otg dual-role platforms, no matter using dr_mode or not,
we need keep it's real OTG disabled for legacy users after it's controller
driver adds real OTG later.


I wouldn't even bother about platforms expecting dual-role behaviour
with dr_mode not set to "otg". That is just plain wrong and can't be supported.

These are the dts files having dr_mode == "otg".
I've sorted them as per Soc vendor and USB controller

...

Nvidia
--
arm/boot/dts/tegra20-seaboard.dts:  dr_mode = "otg";
compatible = "nvidia,tegra20-ehci", "usb-ehci";
arm/boot/dts/tegra30-colibri-eval-v3.dts:   dr_mode = "otg";
compatible = "nvidia,tegra30-ehci", "usb-ehci";

I couldn't find gadget side implementation for this.
Stephen, any comments on whether this board supports true OTG operation or just 
dual-role operation?


Sorry for the slow reply; I was on vacation.

I'm not sure what the difference is?

I won't be able to answer for the Colibri board since I'm not familiar 
with the HW. I have the schematics for Seaboard, so I should be able to 
answer once I understand the question:-)

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

Re: [PATCH v7 0/3] Add arm pl353 smc nand driver for xilinx zynq soc

[Josh Cartwright]

On Mon, Jun 08, 2015 at 11:38:35PM +0530, Punnaiah Choudary Kalluri wrote:
> The following patches add arm pl353 static memory controller driver for
> xilinx zynq soc. The arm pl353 smc supports two interfaces i.e nand and
> nor/sram memory interfaces. The current implementation supports only a
> single SMC instance and nand specific configuration.

What's the integration plan for this guy?  Looks like we missed 4.2.
It'd be swell to get have NAND support land for Zynq in 4.3.

Assuming there is nothing else holding it back:

Brian- I'm assuming you'll want to take this through your tree.

It looks like most of the stuff in drivers/memory have historically gone
through arm-soc/drivers, Michal- does it make sense for you to pick up
http://lkml.kernel.org/r/1433786857-32575-1-git-send-email-punn...@xilinx.com?

Thanks,
  Josh


signature.asc
Description: PGP signature

Re: [PATCH v4 3/5] tee: generic TEE subsystem

[Jason Gunthorpe]

On Wed, Jul 08, 2015 at 12:16:30PM +0200, Jens Wiklander wrote:

> +static void tee_device_complete_unused(struct kref *kref)
> +{
> + struct tee_device *teedev;
> +
> + teedev = container_of(kref, struct tee_device, users);
> + /* When the mutex is released, no other tee_device_get() will succeed */
> + teedev->desc = NULL;
> + complete(&teedev->c_no_users);
> +}
> +
> +void tee_device_put(struct tee_device *teedev)
> +{
> + mutex_lock(&teedev->mutex);
> + /* Shouldn't put in this state */
> + if (!WARN_ON(!teedev->desc))
> + kref_put(&teedev->users, tee_device_complete_unused);
> + mutex_unlock(&teedev->mutex);
> +}
> +
> +bool tee_device_get(struct tee_device *teedev)
> +{
> + mutex_lock(&teedev->mutex);
> + if (!teedev->desc) {
> + mutex_unlock(&teedev->mutex);
> + return false;
> + }
> + kref_get(&teedev->users);
> + mutex_unlock(&teedev->mutex);
> + return true;
> +}

If you are holding the mutex then you don't really need a kref, just a
simple active count counter.

I've been a bit learly lately about seeing krefs used for something
other than kfree, I've seen a few subtle mistakes in those schemes -
yours looks OK, only because of the lock, and the lock makes the kref
redundant..

> +   cdev_init(&teedev->cdev, &tee_fops);
> +   teedev->cdev.owner = teedesc->owner;

This also needs to set teedev->cdev.kobj.parent.
I'm guessing:

 teedev->cdev.kobj.parent = &teedev->dev.kobj;

TPM had the same mistake..

> +void tee_device_unregister(struct tee_device *teedev)
> +{
> + if (IS_ERR_OR_NULL(teedev))
> + return;

See for some general colour on IS_ERR_OR_NULL

https://www.mail-archive.com/linux-omap@vger.kernel.org/msg78030.html

IMHO, you should never, store an ERR pointer into long term storage,
so I wonder why this is like this...

> + if (teedev->flags & TEE_DEVICE_FLAG_REGISTERED) {
> + cdev_del(&teedev->cdev);
> + device_del(&teedev->dev);
> + }
> +
> + tee_device_put(teedev);
> + wait_for_completion(&teedev->c_no_users);

Generally in a scheme like this we'd see open and release get/put the
underlying module handle to prevent driver removal while the char dev
is open. Otherwise module removal will hang here.

Jason
--
To unsubscribe from this list: send the line "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/2] iio: light: add support for TI's opt3001 light sensor

[Andreas Dannenberg]

On 07/05/2015 09:08 AM, Jonathan Cameron wrote:

> Looking pretty good to me, though I'd like to give Peter time to take
> another look and give his reviewed-by etc.
> 
> One really minor suggestion from me...
> 
>> +
>> +static int opt3001_probe(struct i2c_client *client,
>> +const struct i2c_device_id *id)
>> +{
>> +struct device *dev = &client->dev;
>> +
>> +struct iio_dev *iio;
>> +struct opt3001 *opt;
>> +int irq = client->irq;
>> +int ret = -ENOMEM;
>> +
>> +iio = devm_iio_device_alloc(dev, sizeof(*opt));
>> +if (!iio)
> return -ENOMEM; would be cleaner, then there is no need to initialize
> ret either.

Hi Jonathan,
thanks for looking at my code. While we are waiting for additional feedback 
would you
like me to go ahead and re-spin/re-test the patch with your latest suggestion?

Regards,

-- 
Andreas Dannenberg
Texas Instruments Inc.

--
To unsubscribe from this list: send the line "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/7] dmaengine: st_fdma: Add STMicroelectronics FDMA xbar DT binding documentation

[Peter Griffin]

This patch adds the DT binding documentation for the FDMA xbar hw
found on STi based chipsets from STMicroelectronics.

Signed-off-by: Ludovic Barre 
Signed-off-by: Peter Griffin 
---
 Documentation/devicetree/bindings/dma/st_fdma.txt | 24 +++
 1 file changed, 24 insertions(+)

diff --git a/Documentation/devicetree/bindings/dma/st_fdma.txt 
b/Documentation/devicetree/bindings/dma/st_fdma.txt
index 1ec7470..655ee57 100644
--- a/Documentation/devicetree/bindings/dma/st_fdma.txt
+++ b/Documentation/devicetree/bindings/dma/st_fdma.txt
@@ -3,6 +3,24 @@
 The FDMA is a general-purpose direct memory access controller capable of
 supporting 16 independent DMA channels. It accepts up to 32 DMA requests.
 The FDMA is based on a Slim processor which require a firmware.
+To increase the number of peripheral request, the FDMA crossbar can mutiplex
+up to 96 peripheral requests to one of 3 fdma controlers engine.
+
+* FDMA crossbar
+
+Required properties:
+- compatible   : Should be "st,fdma-xbar-1.0"
+- reg  : Should contain XBAR registers location and length
+- dma-requests : Should contain the number of peripheral request 
supported
+- #st,fdma-xbar-cells  : Must be <1>
+
+Example:
+   xbar0: fdma-xbar-mpe@0 {
+   compatible = "st,fdma-xbar-1.0";
+   reg = <0x8e8 0x1000>;
+   dma-requests = <79>;
+   #st,fdma-xbar-cells = <1>;
+   };
 
 * FDMA Controller
 
@@ -18,6 +36,11 @@ Required properties:
 See: Documentation/devicetree/bindings/clock/clock-bindings.txt
 
 
+Optional properties:
+- st,fdma-xbar : Allow to plug controller behind the crossbar at offset X
+  1. A phandle pointing to the FDMA crossbar
+  2. Output offset <2..0>
+
 Example:
 
fdma1: fdma-app@1 {
@@ -26,6 +49,7 @@ Example:
interrupts = ;
dma-channels = <16>;
#dma-cells = <3>;
+   st,fdma-xbar = <&xbar0 0>;
st,fw-name = "fdma_STiH407_1.elf";
clocks = <&CLK_S_C0_FLEXGEN CLK_FDMA>,
 <&CLK_S_C0_FLEXGEN CLK_TX_ICN_DMU>,
-- 
1.9.1

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

[PATCH 1/7] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

[Peter Griffin]

This patch adds the DT binding documentation for the FDMA constroller
found on STi based chipsets from STMicroelectronics.

Signed-off-by: Ludovic Barre 
Signed-off-by: Peter Griffin 
---
 Documentation/devicetree/bindings/dma/st_fdma.txt | 76 +++
 1 file changed, 76 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/st_fdma.txt

diff --git a/Documentation/devicetree/bindings/dma/st_fdma.txt 
b/Documentation/devicetree/bindings/dma/st_fdma.txt
new file mode 100644
index 000..1ec7470
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/st_fdma.txt
@@ -0,0 +1,76 @@
+* STMicroelectronics Flexible Direct Memory Access Device Tree bindings
+
+The FDMA is a general-purpose direct memory access controller capable of
+supporting 16 independent DMA channels. It accepts up to 32 DMA requests.
+The FDMA is based on a Slim processor which require a firmware.
+
+* FDMA Controller
+
+Required properties:
+- compatible   : Should be "st,fdma_mpe31"
+- reg  : Should contain DMA registers location and length
+- interrupts   : Should contain one interrupt shared by all channel
+- dma-channels : Number of channels supported by the controller
+- #dma-cells   : Must be <3>.
+- st,fw-name   : Should contain the name of the firmware to be loaded
+- clocks   : Must contain an entry for each name in clock-names
+- clock-names  : Must contain "fdma_slim, fdma_hi, fdma_low, fdma_ic" entries
+See: Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+
+Example:
+
+   fdma1: fdma-app@1 {
+   compatible = "st,fdma_mpe31";
+   reg = <0x8e4 0x2>;
+   interrupts = ;
+   dma-channels = <16>;
+   #dma-cells = <3>;
+   st,fw-name = "fdma_STiH407_1.elf";
+   clocks = <&CLK_S_C0_FLEXGEN CLK_FDMA>,
+<&CLK_S_C0_FLEXGEN CLK_TX_ICN_DMU>,
+<&CLK_S_C0_FLEXGEN CLK_TX_ICN_DMU>,
+<&CLK_S_C0_FLEXGEN CLK_EXT2F_A9>;
+   clock-names = "fdma_slim",
+ "fdma_hi",
+ "fdma_low",
+ "fdma_ic";
+
+* DMA client
+
+Required properties:
+- dmas: Comma separated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 4 cells:
+1. A phandle pointing to the FDMA controller
+2. The request line number
+3. A 32bit mask specifying (see include/linux/platform_data/dma-st-fdma.h)
+ -bit 2-0: Holdoff value, dreq will be masked for
+   0x0: 0-0.5us
+   0x1: 0.5-1us
+   0x2: 1-1.5us
+ -bit 17: data swap
+   0x0: disabled
+   0x1: enabled
+ -bit 21: Increment Address
+   0x0: no address increment between transfers
+   0x1: increment address between transfers
+ -bit 22: 2 STBus Initiator Coprocessor interface
+   0x0: high priority port
+   0x1: low priority port
+4. transfers type
+ 0 free running
+ 1 paced
+
+Example:
+
+   snd_uni_player2: snd-uni-player@2 {
+   compatible = "st,snd_uni_player";
+   status = "okay";
+   reg = <0x8D82000  0x158>;
+   interrupts = ;
+   version = <5>;
+   dmas = <&fdma0 4 0 1>;
+   dma-names = "tx";
+   description = "Uni Player #2 (DAC)";
-- 
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 5/7] ARM: STi: DT: STiH407: Add FDMA driver and xbar driver dt nodes.

[Peter Griffin]

These nodes are required to get the fdma and xbar driver working
on STiH407 based silicon.

Signed-off-by: Peter Griffin 
---
 arch/arm/boot/dts/stih407-family.dtsi | 59 +++
 1 file changed, 59 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index 838b812..b6d9e20 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -565,5 +565,64 @@
  <&phy_port2 PHY_TYPE_USB3>;
};
};
+
+   xbar0: fdma-xbar-mpe@0 {
+   compatible = "st,fdma-xbar-1.0";
+   reg = <0x8e8 0x1000>;
+   dma-requests = <79>;
+   #st,fdma-xbar-cells = <1>;
+   };
+
+   fdma0: fdma-audio@0 {
+   compatible = "st,fdma_mpe31";
+   reg = <0x8e2 0x2>;
+   interrupts = ;
+   dma-channels = <16>;
+   #dma-cells = <3>;
+   st,fw-name = "fdma_STiH407_0.elf";
+   clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+<&clk_s_c0_flexgen CLK_EXT2F_A9>,
+<&clk_s_c0_flexgen CLK_EXT2F_A9>,
+<&clk_s_c0_flexgen CLK_EXT2F_A9>;
+   clock-names = "fdma_slim",
+ "fdma_hi",
+ "fdma_low",
+ "fdma_ic";
+   };
+
+   fdma1: fdma-app@1 {
+   compatible = "st,fdma_mpe31";
+   reg = <0x8e4 0x2>;
+   interrupts = ;
+   dma-channels = <16>;
+   #dma-cells = <3>;
+   st,fdma-xbar = <&xbar0 0>;
+   st,fw-name = "fdma_STiH407_1.elf";
+   clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
+<&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
+<&clk_s_c0_flexgen CLK_EXT2F_A9>;
+   clock-names = "fdma_slim",
+ "fdma_hi",
+ "fdma_low",
+ "fdma_ic";
+   };
+
+   fdma2: fdma-free_running@2 {
+   compatible = "st,fdma_mpe31";
+   reg = <0x8e6 0x2>;
+   interrupts = ;
+   dma-channels = <16>;
+   #dma-cells = <3>;
+   st,fw-name = "fdma_STiH407_2.elf";
+   clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+<&clk_s_c0_flexgen CLK_EXT2F_A9>,
+<&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
+<&clk_s_c0_flexgen CLK_EXT2F_A9>;
+   clock-names = "fdma_slim",
+ "fdma_hi",
+ "fdma_low",
+ "fdma_ic";
+   };
};
 };
-- 
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 7/7] ARM: multi_v7_defconfig: Enable STi FDMA driver

[Peter Griffin]

This DMA controller is found on all STi chipsets.

Signed-off-by: Peter Griffin 
---
 arch/arm/configs/multi_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 6d83a1b..370dd85 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -588,6 +588,8 @@ CONFIG_IMX_DMA=y
 CONFIG_MXS_DMA=y
 CONFIG_DMA_OMAP=y
 CONFIG_XILINX_VDMA=y
+CONFIG_ST_FDMA=y
+CONFIG_ST_FDMA_XBAR=y
 CONFIG_STAGING=y
 CONFIG_SENSORS_ISL29018=y
 CONFIG_SENSORS_ISL29028=y
-- 
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 6/7] MAINTAINERS: Add FDMA driver files to STi section.

[Peter Griffin]

This patch adds the FDMA driver files to the STi
section of the maintainers file.

Signed-off-by: Peter Griffin 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8133cef..8cb1ad9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1503,6 +1503,8 @@ S:Maintained
 F: arch/arm/mach-sti/
 F: arch/arm/boot/dts/sti*
 F: drivers/clocksource/arm_global_timer.c
+F: drivers/dma/st_fdma.*
+F: drivers/dma/st_fdma_xbar.c
 F: drivers/i2c/busses/i2c-st.c
 F: drivers/media/rc/st_rc.c
 F: drivers/mmc/host/sdhci-st.c
-- 
1.9.1

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

[PATCH 0/7] Add support for FDMA DMA controller found on STi chipsets

[Peter Griffin]

Hi,

This patchset adds support for the Flexible Direct Memory Access (FDMA) core
found on STi chipsets from STMicroelectronics. The FDMA is a slim core CPU
with a dedicated firmware. It is a general purpose DMA controller supporting
16 independent channels and data can be moved from memory to memory or between
memory and paced latency critical real time targets.

To increase the number of peripheral request, support is also added for the
FDMA crossbar hardware, which can be used to multiplex up to 96 peripheral
requests, to the 3 fdma engines.

regards,

Peter.

Peter Griffin (7):
  dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding
documentation
  dmaengine: st_fdma: Add STMicroelectronics FDMA xbar DT binding
documentation
  dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support
  dmaengine: st_fdma: Add xbar support
  ARM: STi: DT: STiH407: Add FDMA driver and xbar driver dt nodes.
  MAINTAINERS: Add FDMA driver files to STi section.
  ARM: multi_v7_defconfig: Enable STi FDMA driver

 Documentation/devicetree/bindings/dma/st_fdma.txt |  100 ++
 MAINTAINERS   |2 +
 arch/arm/boot/dts/stih407-family.dtsi |   59 +
 arch/arm/configs/multi_v7_defconfig   |2 +
 drivers/dma/Kconfig   |   26 +
 drivers/dma/Makefile  |2 +
 drivers/dma/st_fdma.c | 1203 +
 drivers/dma/st_fdma.h |  266 +
 drivers/dma/st_fdma_xbar.c|  149 +++
 include/linux/platform_data/dma-st_fdma.h |   70 ++
 10 files changed, 1879 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/st_fdma.txt
 create mode 100644 drivers/dma/st_fdma.c
 create mode 100644 drivers/dma/st_fdma.h
 create mode 100644 drivers/dma/st_fdma_xbar.c
 create mode 100644 include/linux/platform_data/dma-st_fdma.h

-- 
1.9.1

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

[PATCH 4/7] dmaengine: st_fdma: Add xbar support

[Peter Griffin]

To increase the number of peripheral requests, the FDMA crossbar
can multiplex up to 96 peripheral requests to one of 3 fdma
controllers.

Signed-off-by: Ludovic Barre 
Signed-off-by: Peter Griffin 
---
 drivers/dma/Kconfig|  11 
 drivers/dma/Makefile   |   1 +
 drivers/dma/st_fdma.c  |  25 +++-
 drivers/dma/st_fdma.h  |  32 ++
 drivers/dma/st_fdma_xbar.c | 149 +
 5 files changed, 216 insertions(+), 2 deletions(-)
 create mode 100644 drivers/dma/st_fdma_xbar.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 7a016e0..21802b1 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -522,4 +522,15 @@ config ST_FDMA
  Say Y here if you have such a chipset.
  If unsure, say N.
 
+config ST_FDMA_XBAR
+   bool "ST FDMA crossbar"
+   depends on ST_FDMA
+   default y
+   help
+ Enable support for ST FDMA crossbar.
+ xbar add flexibility and increase the number of peripheral request
+ can be used by fdma xbar can multiplex until 96 peripheral requests
+ to one of 3 fdma controller
+
+
 endif
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index f68e6d8..19f18b1 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_MOXART_DMA) += moxart-dma.o
 obj-$(CONFIG_FSL_RAID) += fsl_raid.o
 obj-$(CONFIG_FSL_EDMA) += fsl-edma.o
 obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
+obj-$(CONFIG_ST_FDMA_XBAR) += st_fdma_xbar.o
 obj-$(CONFIG_ST_FDMA) += st_fdma.o
 obj-y += xilinx/
 obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
index 07a6df1..a870902 100644
--- a/drivers/dma/st_fdma.c
+++ b/drivers/dma/st_fdma.c
@@ -336,7 +336,9 @@ static int st_fdma_dreq_get(struct st_fdma_chan *fchan)
return -EINVAL;
}
 
-   if (try || req_line_cfg >= ST_FDMA_NR_DREQS) {
+   if (fdev->xbar_dev)
+   dreq_line = ffz(fdev->dreq_mask);
+   else if (try || req_line_cfg >= ST_FDMA_NR_DREQS) {
dev_err(fdev->dev, "Invalid or used req line\n");
return -EINVAL;
} else {
@@ -903,6 +905,15 @@ static int st_fdma_slave_config(struct dma_chan *chan,
else
return -EINVAL;
 
+   if (fdev->xbar_dev) {
+   if (st_fdma_xbar_mux(fdev->xbar_dev, fchan->cfg.req_line,
+fchan->dreq_line)) {
+   dev_err(fdev->dev, "Error routing req line\n");
+   clear_bit(fchan->dreq_line, &fdev->dreq_mask);
+   return -EINVAL;
+   }
+   }
+
fchan->cfg.req_ctrl |= REQ_CTRL_NUM_OPS(maxburst-1);
dreq_write(fchan, fchan->cfg.req_ctrl, REQ_CTRL);
 
@@ -1044,6 +1055,13 @@ static int st_fdma_probe(struct platform_device *pdev)
if (ret)
goto err_clk;
 
+   fdev->xbar_dev = st_fdma_xbar_request(&pdev->dev);
+   if (IS_ERR(fdev->xbar_dev)) {
+   dev_err(&pdev->dev, "Failed to request xbar:%ld\n",
+   PTR_ERR(fdev->xbar_dev));
+   goto err_clk;
+   }
+
/* Initialise the FDMA dreq (reserve 0 & 31 for FDMA use) */
fdev->dreq_mask = BIT(0) | BIT(31);
 
@@ -1081,7 +1099,10 @@ static int st_fdma_probe(struct platform_device *pdev)
goto err_dma_dev;
}
 
-   dev_info(&pdev->dev, "ST FDMA engine driver, irq:%d\n", irq);
+   dev_info(&pdev->dev, "ST FDMA engine driver, irq:%d xbar(%s, id:%d)\n",
+irq, fdev->xbar_dev ?
+dev_name(&fdev->xbar_dev->pdev->dev) : "no",
+fdev->xbar_dev ? fdev->xbar_dev->fdma_id : 0);
 
return 0;
 
diff --git a/drivers/dma/st_fdma.h b/drivers/dma/st_fdma.h
index 533c811..dd46780 100644
--- a/drivers/dma/st_fdma.h
+++ b/drivers/dma/st_fdma.h
@@ -17,6 +17,20 @@
 #define ST_FDMA_NR_DREQS 32
 #define EM_SLIM102 /* No official SLIM ELF ID */
 
+struct st_fdma_xbar {
+   void __iomem *io_base;
+   struct clk *clk;
+   u32 nr_requests;
+   u32 max_nr_requests;
+};
+
+struct st_fdma_xbar_dev {
+   struct platform_device *pdev;
+   struct st_fdma_xbar *xbar;
+   struct device *fdev;
+   u32 fdma_id;
+};
+
 enum {
CLK_SLIM,
CLK_HI,
@@ -135,6 +149,7 @@ struct st_fdma_dev {
 
struct st_fdma_chan *chans;
 
+   struct st_fdma_xbar_dev *xbar_dev;
spinlock_t dreq_lock;
unsigned long dreq_mask;
 
@@ -142,6 +157,23 @@ struct st_fdma_dev {
atomic_t fw_loaded;
 };
 
+#if defined(CONFIG_ST_FDMA_XBAR)
+struct st_fdma_xbar_dev *st_fdma_xbar_request(struct device *device);
+int st_fdma_xbar_mux(struct st_fdma_xbar_dev *xbar_dev,
+u32 in_dreq, u32 fdma_dreq);
+#else
+struct st_fdma_xbar_dev *st_fdma_xbar_request(struct device *d

[PATCH 3/7] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support

[Peter Griffin]

This patch adds support for the Flexible Direct Memory Access (FDMA) core
driver. The FDMA is a slim core CPU with a dedicated firmware.
It is a general purpose DMA controller capable of supporting 16
independent DMA channels. Data moves maybe from memory to memory
or between memory and paced latency critical real time targets and it
is found on al STi based chipsets.

Signed-off-by: Ludovic Barre 
Signed-off-by: Peter Griffin 
---
 drivers/dma/Kconfig   |   15 +
 drivers/dma/Makefile  |1 +
 drivers/dma/st_fdma.c | 1182 +
 drivers/dma/st_fdma.h |  234 ++
 include/linux/platform_data/dma-st_fdma.h |   70 ++
 5 files changed, 1502 insertions(+)
 create mode 100644 drivers/dma/st_fdma.c
 create mode 100644 drivers/dma/st_fdma.h
 create mode 100644 include/linux/platform_data/dma-st_fdma.h

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 88d474b..7a016e0 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -507,4 +507,19 @@ config QCOM_BAM_DMA
  Enable support for the QCOM BAM DMA controller.  This controller
  provides DMA capabilities for a variety of on-chip devices.
 
+config ST_FDMA
+   bool "ST FDMA dmaengine support"
+   depends on ARCH_STI
+   select DMA_ENGINE
+   select FW_LOADER
+   select FW_LOADER_USER_HELPER_FALLBACK
+   select LIBELF_32
+   select DMA_VIRTUAL_CHANNELS
+   help
+ Enable support for ST FDMA controller.
+ It supports 16 independent DMA channels, accepts up to 32 DMA requests
+
+ Say Y here if you have such a chipset.
+ If unsure, say N.
+
 endif
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 6a4d6f2..f68e6d8 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_MOXART_DMA) += moxart-dma.o
 obj-$(CONFIG_FSL_RAID) += fsl_raid.o
 obj-$(CONFIG_FSL_EDMA) += fsl-edma.o
 obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
+obj-$(CONFIG_ST_FDMA) += st_fdma.o
 obj-y += xilinx/
 obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
 obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
new file mode 100644
index 000..07a6df1
--- /dev/null
+++ b/drivers/dma/st_fdma.c
@@ -0,0 +1,1182 @@
+/*
+ * st_fdma.c
+ *
+ * Copyright (C) 2014 STMicroelectronics
+ * Author: Ludovic Barre 
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "st_fdma.h"
+#include "dmaengine.h"
+#include "virt-dma.h"
+
+static char *fdma_clk_name[CLK_MAX_NUM] = {
+   [CLK_SLIM]  = "fdma_slim",
+   [CLK_HI]= "fdma_hi",
+   [CLK_LOW]   = "fdma_low",
+   [CLK_IC]= "fdma_ic",
+};
+
+static int st_fdma_clk_get(struct st_fdma_dev *fdev)
+{
+   int i;
+
+   for (i = 0; i < CLK_MAX_NUM; i++) {
+   fdev->clks[i] = devm_clk_get(fdev->dev, fdma_clk_name[i]);
+   if (IS_ERR(fdev->clks[i])) {
+   dev_err(fdev->dev,
+   "failed to get clock: %s\n", fdma_clk_name[i]);
+   return PTR_ERR(fdev->clks[i]);
+   }
+   }
+
+   if (i != CLK_MAX_NUM) {
+   dev_err(fdev->dev, "all clocks are not defined\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int st_fdma_clk_enable(struct st_fdma_dev *fdev)
+{
+   int i, ret;
+
+   for (i = 0; i < CLK_MAX_NUM; i++) {
+   ret = clk_prepare_enable(fdev->clks[i]);
+   if (ret < 0)
+   return ret;
+   }
+
+   return 0;
+}
+
+static void st_fdma_clk_disable(struct st_fdma_dev *fdev)
+{
+   int i;
+
+   for (i = 0; i < CLK_MAX_NUM; i++)
+   clk_disable_unprepare(fdev->clks[i]);
+}
+
+static inline struct st_fdma_chan *to_st_fdma_chan(struct dma_chan *c)
+{
+   return container_of(c, struct st_fdma_chan, vchan.chan);
+}
+
+static struct st_fdma_desc *to_st_fdma_desc(struct virt_dma_desc *vd)
+{
+   return container_of(vd, struct st_fdma_desc, vdesc);
+}
+
+void *st_fdma_seg_to_mem(struct st_fdma_dev *fdev, u64 da, int len)
+{
+   int i;
+   resource_size_t base = fdev->io_res->start;
+   const struct st_fdma_ram *fdma_mem = fdev->drvdata->fdma_mem;
+   void *ptr = NULL;
+
+   for (i = 0; i < fdev->drvdata->num_mem; i++) {
+   int mem_off = da - (base + fdma_mem[i].offset);
+
+   /* next mem if da is too small */
+   if (mem_off < 0)
+   continue;
+
+   /* next mem if da is too large */
+   if (mem_off + len > fdma_mem[i].size)
+   continue;
+
+   ptr = fdev->io_base + fdma_mem[i].offset + mem_off;
+   bre

Re: Master-aware devices and sideband ID data

[Will Deacon]

On Wed, Jul 08, 2015 at 02:30:50PM +0100, Mark Rutland wrote:
> On Tue, Jun 09, 2015 at 11:17:54AM +0100, Mark Rutland wrote:
> > On Fri, Jun 05, 2015 at 10:05:34AM +0100, Will Deacon wrote:
> > > Mark: how do you see this co-existing/merging with the current bindings?
> > 
> > As I mentioned in my initial mail, it's not clear to me how this can be
> > reconciled with the current bindings. Everything I've been able to come
> > up with so far at best ends up describing the same thing repeatedly.
> > 
> > I'll see what I can come up with. Any sugestions are welcome!
> 
> I can't see a way of keeping the ID transformations explicit with the
> existing bindings, but I think we can simply fold these down into
> properties in the master nodes, given we expect each ID to be derived
> from some initial master ID anyway.
> 
> So, to cater for the ITS we would need to pass master IDs along with the
> MSI parent information, which we could do by extending msi-parent or by
> introducing a new msis property which behaves similarly to the iommus
> property, describing the MSI controllers the device can address (via any
> IOMMUs), along with any controller-specific identification data.
> 
> Which means we'd have DT fragments like the following for an arbitrary
> platform device:
> 
> its0: its {
>   ...
>   msi-controller;
>   #msi-cells = <1>; // DeviceId
> };
> 
> its1: its {
>   ...
>   msi-controller;
>   #msi-cells = <1>; // DeviceId
> };
> 
> smmu: smmu {
>   ...
>   iommu-cells = <1>; // StreamId
> };
> 
> device {
>   ...
>   iommus = <&its 0>;
>   /* Can use either ITS, but has a different ID at each */
>   msis = <&its0 0x0>, <&its1 0x400>;
> };
> 
> That doesn't allow you to describe a device with multiple mater ports
> where each master port might want to generate MSIs, but I'm not sure if
> that's a real case.

In this case, I think we'd need something extra to define precisely how
those master ports relate to the rest of the system anyway. That would
likely be a device-specific property, I reckon.

> For PCIe root complexes, we'd need to describe the BDF -> iommu-cells
> and BDF -> msi-cells translations separately with new properties on the
> node for the root complex itself.
> 
> Is there anything obviously broken with the above approach?

Works for me. Can you write this up as a binding extension to msi-parent,
please?

Will
--
To unsubscribe from this list: send the line "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] usb: phy: qcom: New APQ8016/MSM8916 USB transceiver driver

[Ivan T. Ivanov]

Driver handles PHY initialization, clock management, power
management and workarounds required after resetting the hardware.

Signed-off-by: Ivan T. Ivanov 
---
 .../devicetree/bindings/usb/qcom,usb-8x16-phy.txt  |  76 
 drivers/usb/phy/Kconfig|  14 +
 drivers/usb/phy/Makefile   |   1 +
 drivers/usb/phy/phy-qcom-8x16-usb.c| 436 +
 4 files changed, 527 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/qcom,usb-8x16-phy.txt
 create mode 100644 drivers/usb/phy/phy-qcom-8x16-usb.c

diff --git a/Documentation/devicetree/bindings/usb/qcom,usb-8x16-phy.txt 
b/Documentation/devicetree/bindings/usb/qcom,usb-8x16-phy.txt
new file mode 100644
index 000..2cb2168
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/qcom,usb-8x16-phy.txt
@@ -0,0 +1,76 @@
+Qualcomm's APQ8016/MSM8916 USB transceiver controller
+
+- compatible:
+Usage: required
+Value type: 
+Definition: Should contain "qcom,usb-8x16-phy".
+
+- reg:
+Usage: required
+Value type: 
+Definition: USB PHY base address and length of the register map
+
+- clocks:
+Usage: required
+Value type: 
+Definition: See clock-bindings.txt section "consumers". List of
+two clock specifiers for interface and core controller
+clocks.
+
+- clock-names:
+Usage: required
+Value type: 
+Definition: Must contain "iface" and "core" strings.
+
+- vddcx-supply:
+Usage: required
+Value type: 
+Definition: phandle to the regulator VDCCX supply node.
+
+- v1p8-supply:
+Usage: required
+Value type: 
+Definition: phandle to the regulator 1.8V supply node.
+
+- v3p3-supply:
+Usage: required
+Value type: 
+Definition: phandle to the regulator 3.3V supply node.
+
+- resets:
+Usage: required
+Value type: 
+Definition: See reset.txt section "consumers". PHY reset specifier.
+
+- reset-names:
+Usage: required
+Value type: 
+Definition: Must contain "phy" string.
+
+- switch-gpio:
+Usage: optional
+Value type: 
+Definition: Some boards are using Dual SPDT USB Switch, witch is
+controlled by GPIO to de/multiplex D+/D- USB lines
+between connectors.
+
+Example:
+   usb_phy: phy@78d9000 {
+   compatible = "qcom,usb-8x16-phy";
+   reg = <0x78d9000 0x400>;
+
+   vddcx-supply = <&pm8916_s1_corner>;
+   v1p8-supply = <&pm8916_l7>;
+   v3p3-supply = <&pm8916_l13>;
+
+   clocks = <&gcc GCC_USB_HS_AHB_CLK>,
+<&gcc GCC_USB_HS_SYSTEM_CLK>;
+   clock-names = "iface", "core";
+
+   resets = <&gcc GCC_USB2A_PHY_BCR>;
+   reset-names = "phy";
+
+   // D+/D- lines: 1 - Routed to HUB, 0 - Device connector
+   switch-gpio = <&pm8916_gpios 4 GPIO_ACTIVE_HIGH>;
+   };
+
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 869c0cfcad..7d3beee 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -152,6 +152,20 @@ config USB_MSM_OTG
  This driver is not supported on boards like trout which
  has an external PHY.

+config USB_QCOM_8X16_PHY
+   tristate "Qualcomm APQ8016/MSM8916 on-chip USB PHY controller support"
+   depends on ARCH_QCOM || COMPILE_TEST
+   depends on RESET_CONTROLLER
+   select USB_PHY
+   select USB_ULPI_VIEWPORT
+   help
+ Enable this to support the USB transceiver on Qualcomm 8x16 chipsets.
+ It handles PHY initialization, clock management, power management,
+ and workarounds required after resetting the hardware.
+
+ To compile this driver as a module, choose M here: the
+ module will be called phy-qcom-8x16-usb.
+
 config USB_MV_OTG
tristate "Marvell USB OTG support"
depends on USB_EHCI_MV && USB_MV_UDC && PM
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index e36ab1d..19c0dcc 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_USB_EHCI_TEGRA)  += phy-tegra-usb.o
 obj-$(CONFIG_USB_GPIO_VBUS)+= phy-gpio-vbus-usb.o
 obj-$(CONFIG_USB_ISP1301)  += phy-isp1301.o
 obj-$(CONFIG_USB_MSM_OTG)  += phy-msm-usb.o
+obj-$(CONFIG_USB_QCOM_8X16_PHY)+= phy-qcom-8x16-usb.o
 obj-$(CONFIG_USB_MV_OTG)   += phy-mv-usb.o
 obj-$(CONFIG_USB_MXS_PHY)  += phy-mxs-usb.o
 obj-$(CONFIG_USB_RCAR_PHY) += phy-rcar-usb.o
diff --git a/drivers/usb/phy/phy-qcom-8x16-usb.c 
b/drivers/usb/phy/phy-qcom-8x16-usb.c
new file mode 100644
index 000..5d357a9
--- /dev/null
+++ b/drivers/usb/phy/phy-qcom-8x16-usb.c
@@ -0,0 +1,436 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Publ

[PATCH v6 4/4] musb: sunxi: Add support for musb controller in A33 SoC

[Hans de Goede]

The A33 SoC uses the same musb controller as found on the A31 and later,
but allwinner has removed the configdata register, this commit adds special
handling for this.

Signed-off-by: Hans de Goede 
---
 .../devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt  |  3 ++-
 drivers/usb/musb/sunxi.c  | 15 +++
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt 
b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
index fde180b..862cd7c 100644
--- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
@@ -2,7 +2,8 @@ Allwinner sun4i A10 musb DRC/OTG controller
 ---
 
 Required properties:
- - compatible  : "allwinner,sun4i-a10-musb" or "allwinner,sun6i-a31-musb"
+ - compatible  : "allwinner,sun4i-a10-musb", "allwinner,sun6i-a31-musb"
+ or "allwinner,sun8i-a33-musb"
  - reg : mmio address range of the musb controller
  - clocks  : clock specifier for the musb controller ahb gate clock
  - reset   : reset specifier for the ahb reset (A31 and newer only)
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index df2f75e..f9f6304 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -73,6 +73,7 @@
 #define SUNXI_MUSB_FL_PHY_ON   4
 #define SUNXI_MUSB_FL_HAS_SRAM 5
 #define SUNXI_MUSB_FL_HAS_RESET6
+#define SUNXI_MUSB_FL_NO_CONFIGDATA7
 
 /* Our read/write methods need access and do not get passed in a musb ref :| */
 static struct musb *sunxi_musb;
@@ -370,6 +371,8 @@ static u32 sunxi_musb_busctl_offset(u8 epnum, u16 offset)
 
 static u8 sunxi_musb_readb(const void __iomem *addr, unsigned offset)
 {
+   struct sunxi_glue *glue;
+
if (addr == sunxi_musb->mregs) {
/* generic control or fifo control reg access */
switch (offset) {
@@ -392,6 +395,12 @@ static u8 sunxi_musb_readb(const void __iomem *addr, 
unsigned offset)
case MUSB_RXFIFOSZ:
return readb(addr + SUNXI_MUSB_RXFIFOSZ);
case MUSB_CONFIGDATA + 0x10: /* See musb_read_configdata() */
+   glue = dev_get_drvdata(sunxi_musb->controller->parent);
+   /* A33 saves a reg, and we get to hardcode this */
+   if (test_bit(SUNXI_MUSB_FL_NO_CONFIGDATA,
+&glue->flags))
+   return 0xde;
+
return readb(addr + SUNXI_MUSB_CONFIGDATA);
/* Offset for these is fixed by sunxi_musb_busctl_offset() */
case SUNXI_MUSB_TXFUNCADDR:
@@ -643,6 +652,11 @@ static int sunxi_musb_probe(struct platform_device *pdev)
if (of_device_is_compatible(np, "allwinner,sun6i-a31-musb"))
set_bit(SUNXI_MUSB_FL_HAS_RESET, &glue->flags);
 
+   if (of_device_is_compatible(np, "allwinner,sun8i-a33-musb")) {
+   set_bit(SUNXI_MUSB_FL_HAS_RESET, &glue->flags);
+   set_bit(SUNXI_MUSB_FL_NO_CONFIGDATA, &glue->flags);
+   }
+
glue->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(glue->clk)) {
dev_err(&pdev->dev, "Error getting clock: %ld\n",
@@ -723,6 +737,7 @@ static int sunxi_musb_remove(struct platform_device *pdev)
 static const struct of_device_id sunxi_musb_match[] = {
{ .compatible = "allwinner,sun4i-a10-musb", },
{ .compatible = "allwinner,sun6i-a31-musb", },
+   { .compatible = "allwinner,sun8i-a33-musb", },
{}
 };
 
-- 
2.4.3

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

[PATCH v6 2/4] musb: sunxi: Add support for the Allwinner sunxi musb controller

[Hans de Goede]

This is based on initial code to get the Allwinner sunxi musb controller
supported by Chen-Yu Tsai and Roman Byshko.

This adds support for the Allwinner sunxi musb controller in both host only
and otg mode. Peripheral only mode is not supported, as no boards use that.

This has been tested on a cubietruck (A20 SoC) and an UTOO P66 tablet
(A13 SoC) with a variety of devices in host mode and with the g_serial gadget
driver in peripheral mode, plugging otg / host cables in/out a lot of times
in all possible imaginable plug orders.

Signed-off-by: Hans de Goede 
---
Changes in v2:
-Move polling of id and vbus-det gpio-s to the phy driver
-Use extcon to get id (USB_HOST mode) status changes from the phy driver
-Stop using syscon, instead use Maxime Ripard's sunxi SRAM controller driver
Changes in v3:
-Check that USB_MUSB_FOO config is compatible with the dr_mode setting from dt
Changes in v4:
-Squash in "musb: sunxi: Add pre/post root reset end platform functions" patch
-Adjust for sunxi_sram controller driver changes
-Stop musb work from turning vbus off again when in host mode
Changes in v5:
-Squash in "musb: sunxi: Remove special MUSB_SUN4I flag" patch, as it was
 mostly reverting changes done by this patch
-Adjust for extcon api changes landing in 4.2
Changes in v6:
-Mark private variables and functions static
---
 .../bindings/usb/allwinner,sun4i-a10-musb.txt  |  27 +
 drivers/usb/musb/Kconfig   |  13 +-
 drivers/usb/musb/Makefile  |   1 +
 drivers/usb/musb/sunxi.c   | 703 +
 4 files changed, 743 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
 create mode 100644 drivers/usb/musb/sunxi.c

diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt 
b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
new file mode 100644
index 000..9254a6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
@@ -0,0 +1,27 @@
+Allwinner sun4i A10 musb DRC/OTG controller
+---
+
+Required properties:
+ - compatible  : "allwinner,sun4i-a10-musb"
+ - reg : mmio address range of the musb controller
+ - clocks  : clock specifier for the musb controller ahb gate clock
+ - interrupts  : interrupt to which the musb controller is connected
+ - interrupt-names : must be "mc"
+ - phys: phy specifier for the otg phy
+ - phy-names   : must be "usb"
+ - dr_mode : Dual-Role mode must be "host" or "otg"
+ - extcon  : extcon specifier for the otg phy
+
+Example:
+
+   usb_otg: usb@01c13000 {
+   compatible = "allwinner,sun4i-a10-musb";
+   reg = <0x01c13000 0x0400>;
+   clocks = <&ahb_gates 0>;
+   interrupts = <38>;
+   interrupt-names = "mc";
+   phys = <&usbphy 0>;
+   phy-names = "usb";
+   extcon = <&usbphy 0>;
+   status = "disabled";
+   };
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 39db8b6..37081ed 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -5,7 +5,7 @@
 
 # (M)HDRC = (Multipoint) Highspeed Dual-Role Controller
 config USB_MUSB_HDRC
-   tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, ...)'
+   tristate 'Inventra Highspeed Dual Role Controller (TI, ADI, AW, ...)'
depends on (USB || USB_GADGET)
help
  Say Y here if your system has a dual role high speed USB
@@ -20,6 +20,8 @@ config USB_MUSB_HDRC
  Analog Devices parts using this IP include Blackfin BF54x,
  BF525 and BF527.
 
+ Allwinner SoCs using this IP include A10, A13, A20, ...
+
  If you do not know what this is, please say N.
 
  To compile this driver as a module, choose M here; the
@@ -60,6 +62,15 @@ endchoice
 
 comment "Platform Glue Layer"
 
+config USB_MUSB_SUNXI
+   tristate "Allwinner (sunxi)"
+   depends on ARCH_SUNXI
+   depends on NOP_USB_XCEIV
+   depends on PHY_SUN4I_USB
+   depends on EXTCON
+   depends on GENERIC_PHY
+   select SUNXI_SRAM
+
 config USB_MUSB_DAVINCI
tristate "DaVinci"
depends on ARCH_DAVINCI_DMx
diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
index ba49501..f95befe 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_USB_MUSB_DA8XX)  += da8xx.o
 obj-$(CONFIG_USB_MUSB_BLACKFIN)+= blackfin.o
 obj-$(CONFIG_USB_MUSB_UX500)   += ux500.o
 obj-$(CONFIG_USB_MUSB_JZ4740)  += jz4740.o
+obj-$(CONFIG_USB_MUSB_SUNXI)   += sunxi.o
 
 
 obj-$(CONFIG_USB_MUSB_AM335X_CHILD)+= musb_am335x.o
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
new file mode 1006

[PATCH v6 1/4] phy-sun4i-usb: Add missing EXPORT_SYMBOL for sun4i_usb_phy_set_squelch_detect

[Hans de Goede]

sun4i_usb_phy_set_squelch_detect is used by other code, which may be built
as a module, so it should be exported.

Signed-off-by: Hans de Goede 
---
Changes in v6:
-New patch in v6 of the sunxi musb support series
---
 drivers/phy/phy-sun4i-usb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index e17c539..b82aa26 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -212,6 +212,7 @@ void sun4i_usb_phy_set_squelch_detect(struct phy *_phy, 
bool enabled)
 
sun4i_usb_phy_write(phy, PHY_SQUELCH_DETECT, enabled ? 0 : 2, 2);
 }
+EXPORT_SYMBOL(sun4i_usb_phy_set_squelch_detect);
 
 static struct phy_ops sun4i_usb_phy_ops = {
.init   = sun4i_usb_phy_init,
-- 
2.4.3

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

[PATCH v6 3/4] musb: sunxi: Add support for musb controller in A31 SoC

[Hans de Goede]

The A31 SoC uses the same musb controller as found in earlier SoCs, but it
is hooked up slightly different. Its SRAM is private and no longer controlled
through the SRAM controller, and its reset is controlled via a separate
reset controller. This commit adds support for this setup.

Signed-off-by: Hans de Goede 
---
 .../bindings/usb/allwinner,sun4i-a10-musb.txt  |  3 +-
 drivers/usb/musb/sunxi.c   | 50 +++---
 2 files changed, 46 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt 
b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
index 9254a6c..fde180b 100644
--- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
+++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.txt
@@ -2,9 +2,10 @@ Allwinner sun4i A10 musb DRC/OTG controller
 ---
 
 Required properties:
- - compatible  : "allwinner,sun4i-a10-musb"
+ - compatible  : "allwinner,sun4i-a10-musb" or "allwinner,sun6i-a31-musb"
  - reg : mmio address range of the musb controller
  - clocks  : clock specifier for the musb controller ahb gate clock
+ - reset   : reset specifier for the ahb reset (A31 and newer only)
  - interrupts  : interrupt to which the musb controller is connected
  - interrupt-names : must be "mc"
  - phys: phy specifier for the otg phy
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index 00d7248..df2f75e 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -70,6 +71,8 @@
 #define SUNXI_MUSB_FL_HOSTMODE_PEND2
 #define SUNXI_MUSB_FL_VBUS_ON  3
 #define SUNXI_MUSB_FL_PHY_ON   4
+#define SUNXI_MUSB_FL_HAS_SRAM 5
+#define SUNXI_MUSB_FL_HAS_RESET6
 
 /* Our read/write methods need access and do not get passed in a musb ref :| */
 static struct musb *sunxi_musb;
@@ -78,6 +81,7 @@ struct sunxi_glue {
struct device   *dev;
struct platform_device  *musb;
struct clk  *clk;
+   struct reset_control*rst;
struct phy  *phy;
struct platform_device  *usb_phy;
struct usb_phy  *xceiv;
@@ -229,14 +233,22 @@ static int sunxi_musb_init(struct musb *musb)
musb->phy = glue->phy;
musb->xceiv = glue->xceiv;
 
-   ret = sunxi_sram_claim(musb->controller->parent);
-   if (ret)
-   return ret;
+   if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, &glue->flags)) {
+   ret = sunxi_sram_claim(musb->controller->parent);
+   if (ret)
+   return ret;
+   }
 
ret = clk_prepare_enable(glue->clk);
if (ret)
goto error_sram_release;
 
+   if (test_bit(SUNXI_MUSB_FL_HAS_RESET, &glue->flags)) {
+   ret = reset_control_deassert(glue->rst);
+   if (ret)
+   goto error_clk_disable;
+   }
+
writeb(SUNXI_MUSB_VEND0_PIO_MODE, musb->mregs + SUNXI_MUSB_VEND0);
 
/* Register notifier before calling phy_init() */
@@ -244,7 +256,7 @@ static int sunxi_musb_init(struct musb *musb)
ret = extcon_register_notifier(glue->extcon, EXTCON_USB_HOST,
   &glue->host_nb);
if (ret)
-   goto error_clk_disable;
+   goto error_reset_assert;
}
 
ret = phy_init(glue->phy);
@@ -273,10 +285,14 @@ error_unregister_notifier:
if (musb->port_mode == MUSB_PORT_MODE_DUAL_ROLE)
extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST,
   &glue->host_nb);
+error_reset_assert:
+   if (test_bit(SUNXI_MUSB_FL_HAS_RESET, &glue->flags))
+   reset_control_assert(glue->rst);
 error_clk_disable:
clk_disable_unprepare(glue->clk);
 error_sram_release:
-   sunxi_sram_release(musb->controller->parent);
+   if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, &glue->flags))
+   sunxi_sram_release(musb->controller->parent);
return ret;
 }
 
@@ -296,8 +312,12 @@ static int sunxi_musb_exit(struct musb *musb)
extcon_unregister_notifier(glue->extcon, EXTCON_USB_HOST,
   &glue->host_nb);
 
+   if (test_bit(SUNXI_MUSB_FL_HAS_RESET, &glue->flags))
+   reset_control_assert(glue->rst);
+
clk_disable_unprepare(glue->clk);
-   sunxi_sram_release(musb->controller->parent);
+   if (test_bit(SUNXI_MUSB_FL_HAS_SRAM, &glue->flags))
+   sunxi_sram_release(musb->controller->parent);
 
return 0;
 }
@@ -617,6 +637,12 @@ static int sunxi_musb_probe(struct platform_device *pdev)
INIT_WORK(

[PATCH v6 0/4] musb: sunxi: Add support for the Allwinner sunxi musb

[Hans de Goede]

Hi Felipe,

As requested here is a new version of my "musb: sunxi: Add support for the
Allwinner sunxi musb controller" patch, fixing the "Should it be static?"
compiler warning.

While working on this I noticed that sun4i_usb_phy_set_squelch_detect()
from phy-sun4i-usb.c is missing an EXPORT_SYMBOL, something which I did
not notice before I was always building both phy-sun4i-usb and musb
into the kernel.

I've added a patch fixing this, and I'm posting a new version of the
entire set including this patch.

I believe that like the original patch adding the
sun4i_usb_phy_set_squelch_detect function, this patch should go upstream
through your (Felipe's) tree as the musb-sunxi patches depend on this.

The other oustanding phy-sun4i-usb patches can still go upstream through
Kishon's tree, they do not conflict with the small patch fixing the
missing EXPORT_SYMBOL.

Thanks & Regards,

Hans
--
To unsubscribe from this list: send the line "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 4/6] ARM: vf610: enable NAND Flash Controller

[Bill Pringlemeir]

On  8 Jul 2015, shawn...@kernel.org wrote:
> On Fri, Jun 19, 2015 at 12:58:37AM +0200, Stefan Agner wrote:
>> Enable the NAND Flash Controller driver which is part of the Vybrid
>> SoC by default.
>>
>> Signed-off-by: Stefan Agner 
>> ---
>> arch/arm/mach-imx/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
>> index 3a3d3e9..9358135 100644
>> --- a/arch/arm/mach-imx/Kconfig
>> +++ b/arch/arm/mach-imx/Kconfig
 -589,6 +589,7 @@ config SOC_VF610
>>  select PINCTRL_VF610
>>  select PL310_ERRATA_769419 if CACHE_L2X0
>>  select SMP_ON_UP if SMP
>> +select HAVE_NAND_VF610_NFC

> I'm not sure about the benefit of having this option, except we have
> to have this additional architecture patch.

For other SOC, like the PowerPC or ColdFire CPUs with this controller,
it was a way to mark the controller as populated.  Otherwise, the
Kconfig entry to select the controller will pop up for everybody.

Is there a better way to do this?


>>
>>  help
>>This enables support for Freescale Vybrid VF610 processor.
--
To unsubscribe from this list: send the line "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/4] ARM: dts: Use labels instead of full paths for Exynos5 pinctrl nodes

[Javier Martinez Canillas]

Krzysztof,

On 07/08/2015 01:27 AM, Krzysztof Kozlowski wrote:
> On 08.07.2015 14:36, Javier Martinez Canillas wrote:
>> Hello Kukjin and Krzysztof,
>>
>> This is a trivial series that changes Exynos5 pinctrl dtsi files to extend
>> the pinctrl nodes using labels instead of full paths.
>>
>> Using labels is less error prone since a misstyped label leads to a build
>> error while full paths can lead to the creation of a new node instead of
>> overriding the original which makes the mistake harder to detect.
>>
>> I tested the changes by decompiling the Exynos5* dtbs and comparing before
>> and after. The resulting dts were identical modulo some node ordering due
>> the pinctrl include change.
> 
> Is the DTB before and after the same? It should not change by re-ordering.
>

The DTB differ but I'm not that familiar with how dtc represents the FDT
to know what is changing in the binary.

But as mentioned, the decompiled DTS only changes in which position the
pinctrl are defined and both DTS are identical if I do:

$ cat decompiled.dts | sort

> Best regards,
> Krzysztof
> 

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

Re: [PATCH 2/4] ARM: dts: Extend exynos5250-pinctrl nodes using labels instead of paths

[Javier Martinez Canillas]

Hello Krzysztof,

On 07/08/2015 01:29 AM, Krzysztof Kozlowski wrote:
> On 08.07.2015 14:36, Javier Martinez Canillas wrote:
>> A previously defined Device Tree node, can be extended either by defining
>> a node using the same full path or by creating a label for the node and
>> referencing to it.
>>
>> Using full paths is more error prone since if there was a typo error, a
>> new node will be created instead of extending the node as it was desired.
>> This will lead to run-time errors that could be hard to detect.
>>
>> A misstyped label on the other hand, will cause a dtc compile error which
> 
> s/misstyped/mistyped/
>

sigh, it's so ironic that I mistyped that.

Do you want me to re-post the whole series with the typo fixed or you /
Kukjin would fix in both patches when applying?

>> makes it easier to detect the mistake since happens at build-time instead.
>>
>> Signed-off-by: Javier Martinez Canillas 
>> ---
>>
>>  arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 1600 
>> ++---
>>  1 file changed, 799 insertions(+), 801 deletions(-)
>>
> 
> I didn't look carefully enough to call it a review (I trust the 'diff'
> of yours) but it seems fine to me:
> 
> Acked-by: Krzysztof Kozlowski 
> 

Thanks a lot for.

> Best regards,
> Krzysztof
>

Best regards,

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

Re: [PATCH RESEND 1/7] tty: serial: 8250: omap: fix kernel crash in suspend-to-ram

[Peter Hurley]

Hi Sekhar,

On 07/06/2015 05:47 AM, Sekhar Nori wrote:
> omap_device infrastructure has a suspend_noirq hook which
> runtime suspends all devices late in the suspend cycle (see
> _od_suspend_noirq() in arch/arm/mach-omap2/omap_device.c)

Why is omap2 the only arch/SoC that does this; ie., call the runtime
callbacks after the system pm callbacks?

Whatever positive it brings, it's a mess at the driver level.
For example, this driver has to hook prepare()/complete() so it can
set local state so that it can detect when the runtime suspend
is being called during system suspend.

Regards,
Peter Hurley


> This leads to a NULL pointer exception in 8250_omap driver
> since by the time omap8250_runtime_suspend() is called, 8250_dma
> driver has already set rxchan to NULL via serial8250_release_dma().
> 
> Make an explicit check to see if rxchan is NULL in
> runtime_{suspend|resume} hooks to fix this.
> 
> Signed-off-by: Sekhar Nori 
> ---
> Previous version: http://www.spinics.net/lists/linux-omap/msg119459.html
> No change in this version except rebased to v4.2-rc1
> 
>  drivers/tty/serial/8250/8250_omap.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tty/serial/8250/8250_omap.c 
> b/drivers/tty/serial/8250/8250_omap.c
> index d75a66c72750..20c5b9c4c288 100644
> --- a/drivers/tty/serial/8250/8250_omap.c
> +++ b/drivers/tty/serial/8250/8250_omap.c
> @@ -1285,7 +1285,7 @@ static int omap8250_runtime_suspend(struct device *dev)
>   return -EBUSY;
>   }
>  
> - if (up->dma)
> + if (up->dma && up->dma->rxchan)
>   omap_8250_rx_dma(up, UART_IIR_RX_TIMEOUT);
>  
>   priv->latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
> @@ -1310,7 +1310,7 @@ static int omap8250_runtime_resume(struct device *dev)
>   if (loss_cntx)
>   omap8250_restore_regs(up);
>  
> - if (up->dma)
> + if (up->dma && up->dma->rxchan)
>   omap_8250_rx_dma(up, 0);
>  
>   priv->latency = priv->calc_latency;
> 

--
To unsubscribe from this list: send the line "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/8] Documentation: add DT binding for ARM System Control and Power Interface(SCPI) protocol

[Sudeep Holla]

Hi Mark,

On 08/06/15 11:39, Sudeep Holla wrote:

This patch adds devicetree binding for System Control and Power
Interface (SCPI) Message Protocol used between the Application Cores(AP)
and the System Control Processor(SCP). The MHU peripheral provides a
mechanism for inter-processor communication between SCP's M3 processor
and AP.

SCP offers control and management of the core/cluster power states,
various power domain DVFS including the core/cluster, certain system
clocks configuration, thermal sensors and many others.

Signed-off-by: Sudeep Holla 
Cc: Rob Herring 
Cc: Mark Rutland 


Can you review this version ?

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: Master-aware devices and sideband ID data

[Mark Rutland]

On Tue, Jun 09, 2015 at 11:17:54AM +0100, Mark Rutland wrote:
> On Fri, Jun 05, 2015 at 10:05:34AM +0100, Will Deacon wrote:
> > On Thu, Jun 04, 2015 at 11:19:30PM +0100, Chalamarla, Tirumalesh wrote:
> > > > On Jun 1, 2015, at 3:22 AM, Mark Rutland  wrote:
> > > > It's possible to specify that the paths exist. I expect that software
> > > > would select which to use at runtime.
> > > > 
> > > My worry is how to define any priorities/preferences between masters. 
> > > in general the proposal looks reasonable.
> > 
> > I agree that the proposal looks reasonable (in terms of the ability to
> > describe the sort of topologies that we will face) but I still don't
> > understand what I need to do in e.g. my IOMMU driver to support this
> > binding whilst continuing to support the existing iommus binding, which
> > is relied upon to configure dma-mapping.
> > 
> > Mark: how do you see this co-existing/merging with the current bindings?
> 
> As I mentioned in my initial mail, it's not clear to me how this can be
> reconciled with the current bindings. Everything I've been able to come
> up with so far at best ends up describing the same thing repeatedly.
> 
> I'll see what I can come up with. Any sugestions are welcome!

I can't see a way of keeping the ID transformations explicit with the
existing bindings, but I think we can simply fold these down into
properties in the master nodes, given we expect each ID to be derived
from some initial master ID anyway.

So, to cater for the ITS we would need to pass master IDs along with the
MSI parent information, which we could do by extending msi-parent or by
introducing a new msis property which behaves similarly to the iommus
property, describing the MSI controllers the device can address (via any
IOMMUs), along with any controller-specific identification data.

Which means we'd have DT fragments like the following for an arbitrary
platform device:

its0: its {
...
msi-controller;
#msi-cells = <1>; // DeviceId
};

its1: its {
...
msi-controller;
#msi-cells = <1>; // DeviceId
};

smmu: smmu {
...
iommu-cells = <1>; // StreamId
};

device {
...
iommus = <&its 0>;
/* Can use either ITS, but has a different ID at each */
msis = <&its0 0x0>, <&its1 0x400>;
};

That doesn't allow you to describe a device with multiple mater ports
where each master port might want to generate MSIs, but I'm not sure if
that's a real case.

For PCIe root complexes, we'd need to describe the BDF -> iommu-cells
and BDF -> msi-cells translations separately with new properties on the
node for the root complex itself.

Is there anything obviously broken with the above approach?

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

[PATCH-v6 6/6] mfd: devicetree: bindings: Add new 88pm800 mfd binding

[Vaibhav Hiremath]

With addition of DT support to 88pm800 mfd driver, this patch
adds new DT binding documentation along with respective properties.

Signed-off-by: Vaibhav Hiremath 
Reviewed-by: Krzysztof Kozlowski 
Acked-by: Rob Herring 
Acked-by: Lee Jones 
---
 Documentation/devicetree/bindings/mfd/88pm800.txt | 53 +++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/88pm800.txt

diff --git a/Documentation/devicetree/bindings/mfd/88pm800.txt 
b/Documentation/devicetree/bindings/mfd/88pm800.txt
new file mode 100644
index 000..dec842f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/88pm800.txt
@@ -0,0 +1,53 @@
+* Marvell 88PM80x Power Management IC
+
+Required parent device properties:
+- compatible   : "marvell,88pm800", "marvell,88pm805", 
"marvell,88pm860"
+- reg  : the I2C slave address for the 88pm80x family chip
+- interrupts   : IRQ line for the 88pm80x family chip
+- interrupt-controller : describes the 88pm80x family chip as an interrupt
+ controller
+- #interrupt-cells : should be 1.
+ The cell is the 88pm80x local IRQ number
+
+88pm80x family of devices consists of varied group of sub-devices:
+
+Device Supply Names Description
+--  ---
+88pm80x-onkey  :   : On key
+88pm80x-rtc:   : RTC
+88pm80x-regulator  :   : Regulators
+
+Example:
+
+   pmic: 88pm800@30 {
+   compatible = "marvell,88pm800";
+   reg = <0x30>;
+   interrupts = ;
+   interrupt-parent = <&gic>;
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   regulators {
+   compatible = "marvell,88pm80x-regulator";
+
+   buck1a: BUCK1A {
+   regulator-name = "BUCK1A";
+   regulator-min-microvolt = <60>;
+   regulator-max-microvolt = <180>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   ldo1: LDO1 {
+   regulator-name = "LDO1";
+   regulator-min-microvolt = <170>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+   };
+
+   rtc {
+   compatible = "marvell,88pm80x-rtc";
+   };
+   };
-- 
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-V5 3/4] mfd: 88pm800: Set default interrupt clear method

[Vaibhav Hiremath]

On Tuesday 07 July 2015 08:27 PM, Lee Jones wrote:

On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:




On Tuesday 07 July 2015 06:24 PM, Lee Jones wrote:

On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:




On Tuesday 07 July 2015 04:48 PM, Vaibhav Hiremath wrote:



On Tuesday 07 July 2015 04:42 PM, Lee Jones wrote:

On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:

On Tuesday 07 July 2015 04:10 PM, Lee Jones wrote:

On Tue, 07 Jul 2015, Vaibhav Hiremath wrote:

On Tuesday 07 July 2015 12:59 PM, Lee Jones wrote:

On Mon, 29 Jun 2015, Vaibhav Hiremath wrote:


As per the spec, bit 1 (INT_CLEAR_MODE) of reg addr 0xe
(page 0) controls the method of clearing interrupt
status of 88pm800 family of devices;

   0: clear on read
   1: clear on write

If pdata is not coming from board file, then set the
default irq clear method to "irq clear on write"

Also, as suggested by "Lee Jones" renaming variable field
to appropriate name.

Signed-off-by: Zhao Ye 
Signed-off-by: Vaibhav Hiremath 
---
  drivers/mfd/88pm800.c   | 15 ++-
  include/linux/mfd/88pm80x.h | 10 --
  2 files changed, 18 insertions(+), 7 deletions(-)







Yes certainly, this is another option (rather preferred one).

But to be consistent with other's I proposed this, please refer to the
fn device_800_init(), where all xxx_init() are taking 2 arguments, and
second argument is pdata.


There is room for cleanup, I agree.
I can put this too in the next cleanup series.



Note that this is init function, called from probe.

So both approach looks ok to me.


Please clean up the other.  Function and put it at the front of the
set when you re-submit.



Sorry for dumb question here :)
I did not understand what do you mean by "in front of the set"?

You want to see all the patches into one single series?
Or
have separate series,
1. existing DT addition series
2. new clean-up series


[PATCH v6 0/5] mfd: 88pm800: Add Device tree support
├>[PATCH v6 1/5] mfd: 88pm800: Obtain pdata from 'device' rather than passing 
as parameter
├>[PATCH v6 2/5] mfd: 88pm800: Add device tree support
├>[PATCH v6 3/5] mfd: 88pm800: Remove unnecessary protection around pdata
├>[PATCH v6 4/5] mfd: 88pm800: Set default interrupt clear method
├>[PATCH v6 5/5] mfd: devicetree: bindings: Add new 88pm800 mfd binding



Thanks Lee,

Just FYI,
I have done some reordering here, because of obvious reasons.

Submitting patches shortly...

Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "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/3] dt-bindings: pwm: add MediaTek display PWM bindings

[Daniel Kurtz]

On Mon, Jul 6, 2015 at 9:29 PM, YH Huang  wrote:
> Document the device-tree binding of MediatTek display PWM.
> The PWM has one channel to control the backlight brightness for display.
> It supports MT8173 and MT6595.
>
> Signed-off-by: YH Huang 
> ---
>  .../devicetree/bindings/pwm/pwm-mtk-disp.txt   | 24 
> ++
>  1 file changed, 24 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
>
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt 
> b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> new file mode 100644
> index 000..757b974
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
> @@ -0,0 +1,24 @@
> +MediaTek display PWM controller
> +
> +Required properties:
> + - compatible: should be "mediatek,-disp-pwm"
> +   - "mediatek,mt8173-disp-pwm": found on mt8173 SoC
> +   - "mediatek,mt6595-disp-pwm": found on mt6595 SoC
> + - reg: physical base address and length of the controller's registers
> + - #pwm-cells: must be 2. See pwm.txt in this directory for a description of
> +   the cell format
> + - clocks: phandle and clock specifier of the PWM reference clock
> + - clock-names: must contain the following
> +   - "main": clock used to generate PWM signals
> +   - "mm": sync signals from the modules of mmsys
> +
> +Example:
> +   pwm0: pwm@1401e000 {
> +   compatible = "mediatek,mt8173-disp-pwm",
> +"mediatek,mt6595-disp-pwm";
> +   reg = <0 0x1401e000 0 0x1000>;
> +   #pwm-cells = <2>;
> +   clocks = <&mmsys CLK_MM_DISP_PWM026M>,
> +<&mmsys CLK_MM_DISP_PWM0MM>;
> +   clock-names = "main", "mm";

Should we include the pinctrl settings here to enable the PWM output?

> +   };
> --
> 1.8.1.1.dirty
>
> --
> 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 v5 2/2] cpufreq: mediatek: Add MT8173 cpufreq driver

[Viresh Kumar]

On 01-07-15, 10:16, Pi-Cheng Chen wrote:
> This patch implements MT8173 cpufreq driver.

Now that you are going to resend this patchset, a few more comments.

Please describe your SoC a bit here, so that reviewers know what are
we going to implement.

> +static int mtk_cpu_dvfs_info_init(struct mtk_cpu_dvfs_info *info, int cpu)
> +{
> + struct device *cpu_dev;
> + struct regulator *proc_reg = ERR_PTR(-ENODEV);
> + struct regulator *sram_reg = ERR_PTR(-ENODEV);
> + struct clk *cpu_clk = ERR_PTR(-ENODEV);
> + struct clk *inter_clk = ERR_PTR(-ENODEV);
> + struct dev_pm_opp *opp;
> + unsigned long rate;
> + int ret;
> +
> + cpu_dev = get_cpu_device(cpu);
> + if (!cpu_dev) {
> + pr_err("failed to get cpu%d device\n", cpu);
> + return -ENODEV;
> + }
> +
> + ret = of_init_opp_table(cpu_dev);
> + if (ret) {
> + pr_warn("no OPP table for cpu%d\n", cpu);
> + return ret;
> + }

Initialize opp table only when you know other resources are available.
i.e. we aren't going to abort due to EPROBE_DEFER.

> + cpu_clk = clk_get(cpu_dev, "cpu");
> + if (IS_ERR(cpu_clk)) {
> + if (PTR_ERR(cpu_clk) == -EPROBE_DEFER)
> + pr_warn("cpu clk for cpu%d not ready, retry.\n", cpu);
> + else
> + pr_err("failed to get cpu clk for cpu%d\n", cpu);
> +
> + ret = PTR_ERR(cpu_clk);
> + goto out_free_opp_table;
> + }
> +}


> +static int mt8173_cpufreq_probe(struct platform_device *pdev)
> +{
> + int ret;
> +
> + ret = cpufreq_register_driver(&mt8173_cpufreq_driver);
> + if (ret)
> + pr_err("failed to register mtk cpufreq driver\n");
> +
> + return ret;
> +}
> +
> +static struct platform_driver mt8173_cpufreq_platdrv = {
> + .driver = {
> + .name   = "mt8173-cpufreq",
> + },
> + .probe  = mt8173_cpufreq_probe,
> +};
> +
> +static int mt8173_cpufreq_driver_init(void)
> +{
> + struct platform_device *pdev;
> + int err;
> +
> + if (!of_machine_is_compatible("mediatek,mt8173"))
> + return -ENODEV;

Why do you need to check this ? Its going to be the right SoC, others
can't even compile it.

> + err = platform_driver_register(&mt8173_cpufreq_platdrv);
> + if (err)
> + return err;
> +
> + pdev = platform_device_register_simple("mt8173-cpufreq", -1, NULL, 0);
> + if (IS_ERR(pdev)) {
> + pr_err("failed to register mtk-cpufreq platform device\n");
> + return PTR_ERR(pdev);
> + }

This is simply crap. You register the driver and then its device from
the same function. If you are so sure that this driver is required,
then why to get into the shit of device-driver model ?

Just call cpufreq_register_driver() from here :), no device/driver
required.

-- 
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 v2 3/4] spi: mediatek: Add spi bus for Mediatek MT8173

[leilk liu]

Hello Daniel,

On Wed, 2015-07-01 at 12:06 +0800, Daniel Kurtz wrote:
> Hi Leilk,
> 
> Please see comments inline...
> 
> On Mon, Jun 29, 2015 at 9:04 PM, Leilk Liu  wrote:
> > This patch adds basic spi bus for MT8173.
> >
> > Signed-off-by: Leilk Liu 
> > Signed-off-by: Eddie Huang 
> > ---
> >  drivers/spi/Kconfig  |   9 +
> >  drivers/spi/Makefile |   1 +
> >  drivers/spi/spi-mt65xx.c | 656 
> > +++
> >  3 files changed, 666 insertions(+)
> >  create mode 100644 drivers/spi/spi-mt65xx.c
> >
> > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> > index 198f96b..06f9514 100644
> > --- a/drivers/spi/Kconfig
> > +++ b/drivers/spi/Kconfig
> > @@ -324,6 +324,15 @@ config SPI_MESON_SPIFC
> >   This enables master mode support for the SPIFC (SPI flash
> >   controller) available in Amlogic Meson SoCs.
> >
> > +config SPI_MT65XX
> > +   tristate "MediaTek SPI controller"
> > +   depends on ARCH_MEDIATEK || COMPILE_TEST
> > +   help
> > + This selects the MediaTek(R) SPI bus driver.
> > + If you want to use MediaTek(R) SPI interface,
> > + say Y or M here.If you are not sure, say N.
> > + SPI drivers for Mediatek mt65XX series ARM SoCs.
> > +
> >  config SPI_OC_TINY
> > tristate "OpenCores tiny SPI"
> > depends on GPIOLIB
> > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> > index d8cbf65..ab332ef 100644
> > --- a/drivers/spi/Makefile
> > +++ b/drivers/spi/Makefile
> > @@ -48,6 +48,7 @@ obj-$(CONFIG_SPI_MESON_SPIFC) += spi-meson-spifc.o
> >  obj-$(CONFIG_SPI_MPC512x_PSC)  += spi-mpc512x-psc.o
> >  obj-$(CONFIG_SPI_MPC52xx_PSC)  += spi-mpc52xx-psc.o
> >  obj-$(CONFIG_SPI_MPC52xx)  += spi-mpc52xx.o
> > +obj-$(CONFIG_SPI_MT65XX)+= spi-mt65xx.o
> >  obj-$(CONFIG_SPI_MXS)  += spi-mxs.o
> >  obj-$(CONFIG_SPI_NUC900)   += spi-nuc900.o
> >  obj-$(CONFIG_SPI_OC_TINY)  += spi-oc-tiny.o
> > diff --git a/drivers/spi/spi-mt65xx.c b/drivers/spi/spi-mt65xx.c
> > new file mode 100644
> > index 000..6cb54587
> > --- /dev/null
> > +++ b/drivers/spi/spi-mt65xx.c
> > @@ -0,0 +1,656 @@
> > +/*
> > + * Copyright (c) 2015 MediaTek Inc.
> > + * Author: Leilk Liu 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> It would be nicer if you can alphabetize these headers.
> 

OK, I'll fix it.

> > +
> > +#define SPI_CFG0_REG  0x
> > +#define SPI_CFG1_REG  0x0004
> > +#define SPI_TX_SRC_REG0x0008
> > +#define SPI_RX_DST_REG0x000c
> > +#define SPI_CMD_REG   0x0018
> > +#define SPI_STATUS0_REG   0x001c
> > +#define SPI_PAD_SEL_REG   0x0024
> > +
> > +#define SPI_CFG0_SCK_HIGH_OFFSET  0
> > +#define SPI_CFG0_SCK_LOW_OFFSET   8
> > +#define SPI_CFG0_CS_HOLD_OFFSET   16
> > +#define SPI_CFG0_CS_SETUP_OFFSET  24
> > +
> > +#define SPI_CFG0_SCK_HIGH_MASK0xff
> > +#define SPI_CFG0_SCK_LOW_MASK 0xff00
> > +#define SPI_CFG0_CS_HOLD_MASK 0xff
> > +#define SPI_CFG0_CS_SETUP_MASK0xff00
> > +
> > +#define SPI_CFG1_CS_IDLE_OFFSET   0
> > +#define SPI_CFG1_PACKET_LOOP_OFFSET   8
> > +#define SPI_CFG1_PACKET_LENGTH_OFFSET 16
> > +#define SPI_CFG1_GET_TICK_DLY_OFFSET  30
> > +
> > +#define SPI_CFG1_CS_IDLE_MASK 0xff
> > +#define SPI_CFG1_PACKET_LOOP_MASK 0xff00
> > +#define SPI_CFG1_PACKET_LENGTH_MASK   0x3ff
> > +#define SPI_CFG1_GET_TICK_DLY_MASK0xc000
> > +
> > +#define SPI_CMD_ACT_OFFSET0
> > +#define SPI_CMD_RESUME_OFFSET 1
> > +#define SPI_CMD_RST_OFFSET2
> > +#define SPI_CMD_PAUSE_EN_OFFSET   4
> > +#define SPI_CMD_DEASSERT_OFFSET   5
> > +#define SPI_CMD_CPHA_OFFSET   8
> > +#define SPI_CMD_CPOL_OFFSET   9
> > +#define SPI_CMD_RX_DMA_OFFSET 10
> > +#define SPI_CMD_TX_DMA_OFFSET 11
> > +#define SPI_CMD_TXMSBF_OFFSET   

Re: [PATCH v2 0/9] cpufreq: Introduce support for ST's cpufreq functionality

[Viresh Kumar]

On 08-07-15, 11:59, Lee Jones wrote:
> No problem.  So long as it's still on your radar.

So, for the first 7 patches:

Reviewed-by: Viresh Kumar 

but for the last two:
- I thought we agreed that you will have a look at opp-v2 bindings and
  create your new bindings as an extension of those ? As we support
  extending opp-v2 bindings per vendor basis.
- And I don't really think you need to create a device for your STM
  driver, why not move your stm-cpufreq file to arch/arm/- and call it
  from .init_late, from where you call init_cpufreq() today. Your
  driver doesn't have anything related to cpufreq-core really and
  isn't required to stay in drivers/cpufreq, unless you want it that
  way.

I haven't reviewed the driver yet and waiting for an answer to opp-v2
question I asked above. opp-v2 is created because we didn't wanted
platforms to create new separate bindings for OPPs :)

-- 
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 v5 1/2] dt-bindings: mediatek: Add MT8173 cpufreq driver binding

[Viresh Kumar]

On 01-07-15, 10:16, Pi-Cheng Chen wrote:
> This patch adds device tree binding document for MT8173 cpufreq driver.
> 
> Signed-off-by: Pi-Cheng Chen 
> Reviewed-by: Michael Turquette 
> ---
>  .../devicetree/bindings/cpufreq/cpufreq-mt8173.txt | 145 
> +
>  1 file changed, 145 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/cpufreq/cpufreq-mt8173.txt
> 
> diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mt8173.txt 
> b/Documentation/devicetree/bindings/cpufreq/cpufreq-mt8173.txt
> new file mode 100644
> index 000..65701c5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mt8173.txt
> @@ -0,0 +1,145 @@
> +
> +Mediatek MT8173 cpufreq driver
> +--
> +
> +Mediatek MT8173 cpufreq driver for CPU frequency scaling.
> +
> +Required properties:
> +- clocks: A list of phandle + clock-specifier pairs for the clocks listed in 
> clock names.
> +- clock-names: Should contain the following:
> + "cpu"   - The multiplexer for clock input of CPU cluster.
> + "intermediate"  - A parent of "cpu" clock which is used as 
> "intermediate" clock
> +   source (usually MAINPLL) when the original CPU PLL is 
> under
> +   transition and not stable yet.
> + Please refer to 
> Documentation/devicetree/bindings/clk/clock-bindings.txt for
> + generic clock consumer properties.

Don't have any intentions to halt this series anymore, I have
irritated you enough already :)

But, what about moving these bindings in something like a clock
driver?

@Mike: ?

I am asking because these really belong to the clock driver, as I
understood it from Mike. And clearly asked me to not take care of such
things in cpufreq core/drivers.

Another reason is that, later you will kill this driver one day and
use cpufreq-dt. And then you will be required to move these bindings
to a clock driver, as these will stay.

-- 
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 v2 0/9] cpufreq: Introduce support for ST's cpufreq functionality

[Lee Jones]

On Wed, 08 Jul 2015, Viresh Kumar wrote:

> On 24-06-15, 14:58, Lee Jones wrote:
> > This driver reads very platform specific information in from Device Tree
> > and translates it into frequency tables.  The generic drivers then use the
> > tables to conduct frequency and voltage scaling in the normal way.
> > 
> > There are 'ARM' patches in the set which are not necessarily related to 
> > CPUFreq,
> > but are required to get it to work.  Anyone who is not interested in 
> > general STi
> > DT changes can safely ignore these.
> > 
> > v1 => v2:
> >  - CPUFreq is no longer it's own device in DT; instead:
> >- It is probed from the platform area
> >- Key properties have been moved into the CPU's node
> >  - Driver is less generic [ST => STI]
> >  - Documentation has been updated
> >- Point one (above) has been accounted for
> >- Example of bootloader supplied node has been provided
> >  - GPL licensing has been updated to reflected the header
> >  - Kconfig disparity has been rectified [bool => tristate]
> 
> Sorry for being so late to get back to this.. Was tooo busy :(

No problem.  So long as it's still on your radar.

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

Re: [PATCH v2 0/9] cpufreq: Introduce support for ST's cpufreq functionality

[Viresh Kumar]

On 24-06-15, 14:58, Lee Jones wrote:
> This driver reads very platform specific information in from Device Tree
> and translates it into frequency tables.  The generic drivers then use the
> tables to conduct frequency and voltage scaling in the normal way.
> 
> There are 'ARM' patches in the set which are not necessarily related to 
> CPUFreq,
> but are required to get it to work.  Anyone who is not interested in general 
> STi
> DT changes can safely ignore these.
> 
> v1 => v2:
>  - CPUFreq is no longer it's own device in DT; instead:
>- It is probed from the platform area
>- Key properties have been moved into the CPU's node
>  - Driver is less generic [ST => STI]
>  - Documentation has been updated
>- Point one (above) has been accounted for
>- Example of bootloader supplied node has been provided
>  - GPL licensing has been updated to reflected the header
>  - Kconfig disparity has been rectified [bool => tristate]

Sorry for being so late to get back to this.. Was tooo busy :(

-- 
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 2/2] arm64: dts: mediatek: add mt6795 support

[Mark Rutland]

On Wed, Jul 08, 2015 at 11:14:40AM +0100, Mars Cheng wrote:
> This adds basic chip support for MT6795 SoC
> 
> Signed-off-by: Mars Cheng 
> ---
>  arch/arm64/boot/dts/mediatek/Makefile   |   1 +
>  arch/arm64/boot/dts/mediatek/mt6795-evb.dts |  34 ++
>  arch/arm64/boot/dts/mediatek/mt6795.dtsi| 164 
> 
>  3 files changed, 199 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt6795-evb.dts
>  create mode 100644 arch/arm64/boot/dts/mediatek/mt6795.dtsi
> 
> diff --git a/arch/arm64/boot/dts/mediatek/Makefile 
> b/arch/arm64/boot/dts/mediatek/Makefile
> index 3ce2462..e0a4bff 100644
> --- a/arch/arm64/boot/dts/mediatek/Makefile
> +++ b/arch/arm64/boot/dts/mediatek/Makefile
> @@ -1,3 +1,4 @@
> +dtb-$(CONFIG_ARCH_MEDIATEK) += mt6795-evb.dtb
>  dtb-$(CONFIG_ARCH_MEDIATEK) += mt8173-evb.dtb
>  
>  always   := $(dtb-y)
> diff --git a/arch/arm64/boot/dts/mediatek/mt6795-evb.dts 
> b/arch/arm64/boot/dts/mediatek/mt6795-evb.dts
> new file mode 100644
> index 000..3a43c860
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt6795-evb.dts
> @@ -0,0 +1,34 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + * Author: Mars.C 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +/dts-v1/;
> +#include "mt6795.dtsi"
> +
> +/ {
> + model = "MediaTek MT6795 Evaluation Board";
> +
> + memory@4000 {
> + device_type = "memory";
> + reg = <0 0x4000 0 0x1e80>;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,921600n8 earlyprintk";

PLease get rid of bootargs here; earlyprintk doesn't do anything on
arm64 (it's earlycon these days), and you can specify the serial
configuration in stdout-path, so please use that instead.

> + stdout-path = &uart0;
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/mediatek/mt6795.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
> new file mode 100644
> index 000..832be20
> --- /dev/null
> +++ b/arch/arm64/boot/dts/mediatek/mt6795.dtsi
> @@ -0,0 +1,164 @@
> +/*
> + * Copyright (c) 2015 MediaTek Inc.
> + * Author: Mars.C 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +
> +/ {
> + compatible = "mediatek,mt6795";
> + interrupt-parent = <&sysirq>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x000>;
> + };
> +
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x001>;
> + };

No enable-method? Does your FW patch that in?

> +
> + cpu2: cpu@2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x002>;
> + };
> +
> + cpu3: cpu@3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x003>;
> + };
> +
> + cpu4: cpu@4 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x100>;
> + };

The unit-address should match the reg (e.g. this should be cpu@100).

> +
> + cpu5: cpu@5 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x101>;
> + };
> +
> + cpu6: cpu@6 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x102>;
> + };
> +
> + cpu7: cpu@7 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x103>;
> + };
> + };
> +
> + clocks {
> + system_clk: dummy13m {
> +   

[PATCH v4 3/5] tee: generic TEE subsystem

[Jens Wiklander]

Initial patch for generic TEE subsystem.
This subsystem provides:
* Registration/un-registration of TEE drivers.
* Shared memory between normal world and secure world.
* Ioctl interface for interaction with user space.

A TEE (Trusted Execution Environment) driver is a driver that interfaces
with a trusted OS running in some secure environment, for example,
TrustZone on ARM cpus, or a separate secure co-processor etc.

The TEE subsystem can serve a TEE driver for a Global Platform compliant
TEE, but it's not limited to only Global Platform TEEs.

This patch builds on other similar implementations trying to solve
the same problem:
* "optee_linuxdriver" by among others
  Jean-michel DELORME and
  Emmanuel MICHEL 
* "Generic TrustZone Driver" by Javier González 

Signed-off-by: Jens Wiklander 
---
 Documentation/ioctl/ioctl-number.txt |   1 +
 MAINTAINERS  |   8 +
 drivers/Kconfig  |   2 +
 drivers/Makefile |   1 +
 drivers/tee/Kconfig  |   8 +
 drivers/tee/Makefile |   3 +
 drivers/tee/tee.c| 839 +++
 drivers/tee/tee_private.h|  80 
 drivers/tee/tee_shm.c| 324 ++
 drivers/tee/tee_shm_pool.c   | 133 ++
 include/linux/tee_drv.h  | 306 +
 include/uapi/linux/tee.h | 376 
 12 files changed, 2081 insertions(+)
 create mode 100644 drivers/tee/Kconfig
 create mode 100644 drivers/tee/Makefile
 create mode 100644 drivers/tee/tee.c
 create mode 100644 drivers/tee/tee_private.h
 create mode 100644 drivers/tee/tee_shm.c
 create mode 100644 drivers/tee/tee_shm_pool.c
 create mode 100644 include/linux/tee_drv.h
 create mode 100644 include/uapi/linux/tee.h

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index 51f4221..f54dfc02 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -301,6 +301,7 @@ Code  Seq#(hex) Include FileComments
 0xA3   80-8F   Port ACLin development:

 0xA3   90-9F   linux/dtlk.h
+0xA4   00-1F   uapi/linux/tee.hGeneric TEE subsystem
 0xAB   00-1F   linux/nbd.h
 0xAC   00-1F   linux/raw.h
 0xAD   00  Netfilter devicein development:
diff --git a/MAINTAINERS b/MAINTAINERS
index d8afd29..869635f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8634,6 +8634,14 @@ S:   Maintained
 F: include/linux/mmc/dw_mmc.h
 F: drivers/mmc/host/dw_mmc*
 
+TEE SUBSYSTEM
+M: Jens Wiklander 
+M: Javier González 
+S: Maintained
+F: include/linux/tee_drv.h
+F: include/uapi/linux/tee.h
+F: drivers/tee/
+
 THUNDERBOLT DRIVER
 M: Andreas Noever 
 S: Maintained
diff --git a/drivers/Kconfig b/drivers/Kconfig
index c0cc96b..7510f69 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -182,4 +182,6 @@ source "drivers/thunderbolt/Kconfig"
 
 source "drivers/android/Kconfig"
 
+source "drivers/tee/Kconfig"
+
 endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index 46d2554..852f0af 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -165,3 +165,4 @@ obj-$(CONFIG_RAS)   += ras/
 obj-$(CONFIG_THUNDERBOLT)  += thunderbolt/
 obj-$(CONFIG_CORESIGHT)+= hwtracing/coresight/
 obj-$(CONFIG_ANDROID)  += android/
+obj-$(CONFIG_TEE)  += tee/
diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
new file mode 100644
index 000..64a8cd7
--- /dev/null
+++ b/drivers/tee/Kconfig
@@ -0,0 +1,8 @@
+# Generic Trusted Execution Environment Configuration
+config TEE
+   bool "Trusted Execution Environment support"
+   default n
+   select DMA_SHARED_BUFFER
+   help
+ This implements a generic interface towards a Trusted Execution
+ Environment (TEE).
diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
new file mode 100644
index 000..60d2dab
--- /dev/null
+++ b/drivers/tee/Makefile
@@ -0,0 +1,3 @@
+obj-y += tee.o
+obj-y += tee_shm.o
+obj-y += tee_shm_pool.o
diff --git a/drivers/tee/tee.c b/drivers/tee/tee.c
new file mode 100644
index 000..9dca143
--- /dev/null
+++ b/drivers/tee/tee.c
@@ -0,0 +1,839 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "tee_private.h"
+
+#define TEE_NUM_DEVICES32
+
+#define TEE_IOCTL_

[PATCH v4 1/5] arm/arm64: add smccc ARCH32

[Jens Wiklander]

Adds helpers to do SMC based on ARM SMC Calling Convention.
CONFIG_HAVE_SMCCC is enabled for architectures that may support
the SMC instruction. It's the responsibility of the caller to
know if the SMC instruction is supported by the platform.

Signed-off-by: Jens Wiklander 
---
 arch/arm/Kconfig   |  4 +++
 arch/arm/kernel/Makefile   |  2 ++
 arch/arm/kernel/smccc-call.S   | 26 ++
 arch/arm/kernel/smccc.c| 17 +
 arch/arm64/Kconfig |  4 +++
 arch/arm64/kernel/Makefile |  1 +
 arch/arm64/kernel/smccc-call.S | 34 ++
 arch/arm64/kernel/smccc.c  | 17 +
 include/linux/arm-smccc.h  | 80 ++
 9 files changed, 185 insertions(+)
 create mode 100644 arch/arm/kernel/smccc-call.S
 create mode 100644 arch/arm/kernel/smccc.c
 create mode 100644 arch/arm64/kernel/smccc-call.S
 create mode 100644 arch/arm64/kernel/smccc.c
 create mode 100644 include/linux/arm-smccc.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 45df48b..75e4da3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -221,6 +221,9 @@ config NEED_RET_TO_USER
 config ARCH_MTD_XIP
bool
 
+config HAVE_SMCCC
+   bool
+
 config VECTORS_BASE
hex
default 0x if MMU || CPU_HIGH_VECTOR
@@ -324,6 +327,7 @@ config ARCH_MULTIPLATFORM
select CLKSRC_OF
select COMMON_CLK
select GENERIC_CLOCKEVENTS
+   select HAVE_SMCCC if CPU_V7
select MIGHT_HAVE_PCI
select MULTI_IRQ_HANDLER
select SPARSE_IRQ
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 752725d..8cdd25b 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -90,4 +90,6 @@ obj-y += psci.o psci-call.o
 obj-$(CONFIG_SMP)  += psci_smp.o
 endif
 
+obj-$(CONFIG_HAVE_SMCCC)   += smccc-call.o smccc.o
+
 extra-y := $(head-y) vmlinux.lds
diff --git a/arch/arm/kernel/smccc-call.S b/arch/arm/kernel/smccc-call.S
new file mode 100644
index 000..05bc554
--- /dev/null
+++ b/arch/arm/kernel/smccc-call.S
@@ -0,0 +1,26 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+
+#include 
+
+/* void smccc_call32(struct smccc_param32 *param) */
+ENTRY(smccc_call32)
+   push{r4-r8, lr}
+   mov r8, r0
+   ldm r8, {r0-r7}
+   __SMC(0)
+   stm r8, {r0-r7}
+   pop {r4-r8, pc}
+ENDPROC(smccc_call32)
diff --git a/arch/arm/kernel/smccc.c b/arch/arm/kernel/smccc.c
new file mode 100644
index 000..ba4039e
--- /dev/null
+++ b/arch/arm/kernel/smccc.c
@@ -0,0 +1,17 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+
+EXPORT_SYMBOL_GPL(smccc_call32);
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7796af4..b3ea778 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -83,6 +83,7 @@ config ARM64
select SPARSE_IRQ
select SYSCTL_EXCEPTION_TRACE
select HAVE_CONTEXT_TRACKING
+   select HAVE_SMCCC
help
  ARM 64-bit (AArch64) Linux support.
 
@@ -146,6 +147,9 @@ config KERNEL_MODE_NEON
 config FIX_EARLYCON_MEM
def_bool y
 
+config HAVE_SMCCC
+   bool
+
 config PGTABLE_LEVELS
int
default 2 if ARM64_64K_PAGES && ARM64_VA_BITS_42
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 426d076..f7804f7 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -36,6 +36,7 @@ arm64-obj-$(CONFIG_EFI)   += efi.o 
efi-stub.o efi-entry.o
 arm64-obj-$(CONFIG_PCI)+= pci.o
 arm64-obj-$(CONFIG_ARMV8_DEPRECATED)   += armv8_deprecated.o
 arm64-obj-$(CONFIG_ACPI)   += acpi.o
+arm64-obj-$(CONFIG_HAVE_SMCCC) += smccc-call.o smccc.o
 
 obj-y  += $(arm64-obj-y) vdso/
 obj-m  += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
new file mode 100644
index 000..3ce7fe8
--- /dev/null
++

[PATCH v4 5/5] Documentation: tee subsystem and op-tee driver

[Jens Wiklander]

Signed-off-by: Jens Wiklander 
---
 Documentation/00-INDEX |   2 +
 Documentation/tee.txt  | 117 +
 MAINTAINERS|   1 +
 3 files changed, 120 insertions(+)
 create mode 100644 Documentation/tee.txt

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index cd077ca..bd3f803 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -435,6 +435,8 @@ sysrq.txt
- info on the magic SysRq key.
 target/
- directory with info on generating TCM v4 fabric .ko modules
+tee.txt
+   - info on the TEE subsystem and drivers
 this_cpu_ops.txt
- List rationale behind and the way to use this_cpu operations.
 thermal/
diff --git a/Documentation/tee.txt b/Documentation/tee.txt
new file mode 100644
index 000..4ac91d2
--- /dev/null
+++ b/Documentation/tee.txt
@@ -0,0 +1,117 @@
+TEE subsystem
+This document describes the TEE subsystem in Linux
+
+A TEE (Trusted Execution Environment) is a trusted OS running in some
+secure environment, for example, TrustZone on ARM CPUs, or a separate
+secure co-processor etc. A TEE driver handles the details needed to
+communicate with the TEE.
+
+This subsystem deals with:
+
+- Registration of TEE drivers
+
+- Managing shared memory between Linux and the TEE
+
+- Providing a generic API to the TEE
+
+The TEE interface
+=
+
+include/uapi/linux/tee.h defines the generic interface to a TEE.
+
+User space (the client) connects to the driver by opening /dev/tee[0-9]* or
+/dev/teepriv[0-9]*.
+
+- TEE_IOC_SHM_ALLOC allocates shared memory and returns a file descriptor which
+  user space can mmap. When user space doesn't need the file descriptor anymore
+  it should be closed. When shared memory isn't needed any longer it should be
+  unmapped with munmap() to allow the reuse of memory.
+
+- TEE_IOC_VERSION lets user space know which TEE this driver handles and
+  the its capabilities.
+
+- TEE_IOC_OPEN_SESSION opens a new session to a Trusted Application
+
+- TEE_IOC_INVOKE invokes a function in a Trusted Application
+
+- TEE_IOC_CANCEL may cancel an ongoing TEE_IOC_OPEN_SESSION or TEE_IOC_INVOKE
+
+- TEE_IOC_CLOSE_SESSION closes a session to a Trusted Application
+
+There are two classes of clients, normal clients and supplicants. The latter is
+a helper process for the TEE to access resources in Linux, for example file
+system access. A normal client opens /dev/tee[0-9]* and a supplicant opens
+/dev/teepriv[0-9].
+
+Much of the communication between clients and the TEE is opaque to the
+driver. The main job for the driver is to receive requests from the
+clients, forward them to the TEE and send back the results. In the case of
+supplicants the communication goes in the other direction, the TEE sends
+requests to the supplicant which then sends back the result.
+
+OP-TEE driver
+=
+
+The OP-TEE driver handles OP-TEE [1] based TEEs. Currently it is only the ARM
+TrustZone based OP-TEE solution that is supported.
+
+Lowest level of communication with OP-TEE builds on ARM SMC Calling
+Convention (SMCCC) [2], which is the foundation for OP-TEE's SMC interface
+[3] used internally by the driver. Stacked on top of that is OP-TEE Message
+Protocol [4].
+
+OP-TEE SMC interface provides the basic functions required by SMCCC and some
+additional functions specific for OP-TEE. The most interesting functions are:
+
+- OPTEE_SMC_FUNCID_CALLS_UID (part of SMCCC) returns the version information
+  which is then returned by TEE_IOC_VERSION
+
+- OPTEE_SMC_CALL_GET_OS_UUID returns the particular OP-TEE implementation, used
+  to tell, for instance, a TrustZone OP-TEE apart from an OP-TEE running on a
+  separate secure co-processor.
+
+- OPTEE_SMC_CALL_WITH_ARG drives the OP-TEE message protocol
+
+- OPTEE_SMC_GET_SHM_CONFIG lets the driver and OP-TEE agree on which memory
+  range to used for shared memory between Linux and OP-TEE.
+
+The GlobalPlatform TEE Client API [5] is implemented on top of the generic
+TEE API.
+
+Picture of the relationship between the different components in the
+OP-TEE architecture.
+
+User space  Kernel   Secure world
+~~  ~~   
+ ++ +-+
+ | Client | | Trusted |
+ ++ | Application |
+/\  +-+
+|| +--+   /\
+|| |tee-  |   ||
+|| |supplicant|   \/
+|| +--+ +-+
+\/  /\  | TEE Internal|
+ +---+  ||  | API |
+ + TEE   |  ||+--

[PATCH v4 2/5] dt/bindings: add bindings for optee

[Jens Wiklander]

Introduces optee prefix and adds bindings for ARM TrustZone based OP-TEE
implementation.

Signed-off-by: Jens Wiklander 
---
 Documentation/devicetree/bindings/optee/optee.txt | 17 +
 Documentation/devicetree/bindings/vendor-prefixes.txt |  1 +
 2 files changed, 18 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/optee/optee.txt

diff --git a/Documentation/devicetree/bindings/optee/optee.txt 
b/Documentation/devicetree/bindings/optee/optee.txt
new file mode 100644
index 000..4a6ff10
--- /dev/null
+++ b/Documentation/devicetree/bindings/optee/optee.txt
@@ -0,0 +1,17 @@
+OP-TEE Device Tree Bindings
+
+OP-TEE is a piece of software using hardware features to provide a Trusted
+Execution Environment. The security can be provided with ARM TrustZone, but
+also by virtualization or a separate chip. As there's no single OP-TEE
+vendor we're using "optee" as the first part of compatible property,
+indicating the OP-TEE protocol is used when communicating with the secure
+world.
+
+* OP-TEE based on ARM TrustZone required properties:
+
+- compatible="optee,optee-tz"
+
+Example:
+   optee {
+   compatible="optee,optee-tz";
+   };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 8033919..17c2a7e 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -141,6 +141,7 @@ nvidia  NVIDIA
 nxpNXP Semiconductors
 onnn   ON Semiconductor Corp.
 opencores  OpenCores.org
+optee  OP-TEE, Open Portable Trusted Execution Environment
 ortustech  Ortus Technology Co., Ltd.
 ovti   OmniVision Technologies
 panasonic  Panasonic Corporation
-- 
1.9.1

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

[PATCH v4 4/5] tee: add OP-TEE driver

[Jens Wiklander]

Adds a OP-TEE driver which also can be compiled as a loadable module.

* Targets ARM and ARM64
* Supports using reserved memory from OP-TEE as shared memory
* Probes OP-TEE version using SMCs
* Accepts requests on privileged and unprivileged device
* Uses OPTEE message protocol version 2 to communicate with secure world

Signed-off-by: Jens Wiklander 
---
 MAINTAINERS   |   5 +
 drivers/tee/Kconfig   |  10 +
 drivers/tee/Makefile  |   1 +
 drivers/tee/optee/Kconfig |   8 +
 drivers/tee/optee/Makefile|   5 +
 drivers/tee/optee/call.c  | 390 +++
 drivers/tee/optee/core.c  | 451 
 drivers/tee/optee/optee_msg.h | 334 +++
 drivers/tee/optee/optee_private.h | 129 +++
 drivers/tee/optee/optee_smc.h | 466 ++
 drivers/tee/optee/rpc.c   | 248 
 drivers/tee/optee/supp.c  | 212 +
 12 files changed, 2259 insertions(+)
 create mode 100644 drivers/tee/optee/Kconfig
 create mode 100644 drivers/tee/optee/Makefile
 create mode 100644 drivers/tee/optee/call.c
 create mode 100644 drivers/tee/optee/core.c
 create mode 100644 drivers/tee/optee/optee_msg.h
 create mode 100644 drivers/tee/optee/optee_private.h
 create mode 100644 drivers/tee/optee/optee_smc.h
 create mode 100644 drivers/tee/optee/rpc.c
 create mode 100644 drivers/tee/optee/supp.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 869635f..2df3f03 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7314,6 +7314,11 @@ F:   arch/*/oprofile/
 F: drivers/oprofile/
 F: include/linux/oprofile.h
 
+OP-TEE DRIVER
+M: Jens Wiklander 
+S: Maintained
+F: drivers/tee/optee/
+
 ORACLE CLUSTER FILESYSTEM 2 (OCFS2)
 M: Mark Fasheh 
 M: Joel Becker 
diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
index 64a8cd7..b269276 100644
--- a/drivers/tee/Kconfig
+++ b/drivers/tee/Kconfig
@@ -6,3 +6,13 @@ config TEE
help
  This implements a generic interface towards a Trusted Execution
  Environment (TEE).
+
+if TEE
+
+menu "TEE drivers"
+
+source "drivers/tee/optee/Kconfig"
+
+endmenu
+
+endif
diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
index 60d2dab..53f3c76 100644
--- a/drivers/tee/Makefile
+++ b/drivers/tee/Makefile
@@ -1,3 +1,4 @@
 obj-y += tee.o
 obj-y += tee_shm.o
 obj-y += tee_shm_pool.o
+obj-$(CONFIG_OPTEE) += optee/
diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
new file mode 100644
index 000..b550b18
--- /dev/null
+++ b/drivers/tee/optee/Kconfig
@@ -0,0 +1,8 @@
+# OP-TEE Trusted Execution Environment Configuration
+config OPTEE
+   tristate "OP-TEE"
+   default n
+   depends on HAVE_SMCCC
+   help
+ This implements the OP-TEE Trusted Execution Environment (TEE)
+ driver.
diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
new file mode 100644
index 000..92fe578
--- /dev/null
+++ b/drivers/tee/optee/Makefile
@@ -0,0 +1,5 @@
+obj-$(CONFIG_OPTEE) += optee.o
+optee-objs += core.o
+optee-objs += call.o
+optee-objs += rpc.o
+optee-objs += supp.o
diff --git a/drivers/tee/optee/call.c b/drivers/tee/optee/call.c
new file mode 100644
index 000..ed07b65
--- /dev/null
+++ b/drivers/tee/optee/call.c
@@ -0,0 +1,390 @@
+/*
+ * Copyright (c) 2015, Linaro Limited
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "optee_private.h"
+#include "optee_smc.h"
+
+struct optee_call_waiter {
+   struct list_head list_node;
+   struct completion c;
+   bool completed;
+};
+
+static void optee_cq_wait_init(struct optee_call_queue *cq,
+   struct optee_call_waiter *w)
+{
+   mutex_lock(&cq->mutex);
+   /*
+* We add ourselves to the queue, but we don't wait. This
+* guarentees that we don't lose a completion if secure world
+* returns busy and another thread just exited and try to complete
+* someone.
+*/
+   w->completed = false;
+   init_completion(&w->c);
+   list_add_tail(&w->list_node, &cq->waiters);
+   mutex_unlock(&cq->mutex);
+}
+
+static void optee_cq_wait_for_completion(struct optee_call_queue *cq,
+   struct optee_call_waiter *w)
+{
+   wait_for_completion(&w->c);
+
+   mutex_lock(&cq->mutex);
+
+   /* Move to end of list to get out of the way for othe

[PATCH v4 0/5] generic TEE subsystem

[Jens Wiklander]

Hi,

This patch set introduces a generic TEE subsystem. The TEE subsystem will be
able contain drivers for various TEE implementations. A TEE (Trusted
Execution Environment) is a trusted OS running in some secure environment,
for example, TrustZone on ARM cpus, or a separate secure co-processor etc.

Regarding use cases, TrustZone has traditionally been used for
offloading secure tasks to the secure world. Examples include banking
applications, Digital Rights Management (DRM), or specific secure
solutions.

This TEE subsystem can serve a TEE driver for a Global Platform compliant
TEE, but it's not limited to only Global Platform TEEs.  One reason why I'm
doing this to be able to get an OP-TEE (https://github.com/OP-TEE/optee_os)
driver upstream.

"tee: generic TEE subsystem" brings in the generic TEE subsystem which
helps when writing a driver for a specific TEE, for example, OP-TEE.

"tee: add OP-TEE driver" is an OP-TEE driver which uses the subsystem to do
its work.

This patch set has been prepared in cooperation with Javier González who
proposed "Generic TrustZone Driver in Linux Kernel" patches 28 Nov 2014,
https://lwn.net/Articles/623380/ . We've since then changed the scope to
TEE instead of TrustZone.

We have discussed the design on tee-...@lists.linaro.org (archive at
https://lists.linaro.org/pipermail/tee-dev/) with people from other
companies, including Valentin Manea ,
Emmanuel MICHEL ,
Jean-michel DELORME ,
and Joakim Bech . Our main concern has been to
agree on something that is generic enough to support many different
TEEs while still keeping the interface together.

v4:
* Rebased on 4.1
* Redesigned the synchronization around entry exit of normal SMC
* Replaced rwsem on the driver instance with kref and completion since
  rwsem wasn't intended to be used in this way
* Expanded the TEE_IOCTL_PARAM_ATTR_TYPE_MASK to make room for
  future additional parameter types
* Documents TEE subsystem and OP-TEE driver
* Replaced TEE_IOC_CMD with TEE_IOC_OPEN_SESSION, TEE_IOC_INVOKE,
  TEE_IOC_CANCEL and TEE_IOC_CLOSE_SESSION
* DT bindings in a separate patch
* Assembly parts moved to arch/arm and arch/arm64 respectively, in a
  separate patch
* Redefined/clarified the meaning of OPTEE_SMC_SHM_CACHED
* Removed CMA usage to limit the scope of the patch set

v3:
* Rebased on 4.1-rc3 (dma_buf_export() API change)
* A couple of small sparse fixes
* Documents bindings for OP-TEE driver
* Updated MAINTAINERS

v2:
* Replaced the stubbed OP-TEE driver with a real OP-TEE driver
* Removed most APIs not needed by OP-TEE in current state
* Update Documentation/ioctl/ioctl-number.txt with correct path to tee.h
* Rename tee_shm_pool_alloc_cma() to tee_shm_pool_alloc()
* Moved tee.h into include/uapi/linux/
* Redefined tee.h IOCTL macros to be directly based on _IOR and friends
* Removed version info on the API to user space, a data blob which
  can contain an UUID is left for user space to be able to tell which
  protocol to use in TEE_IOC_CMD
* Changed user space exposed structures to only have types with __ prefix
* Dropped THIS_MODULE from tee_fops
* Reworked how the driver is registered and ref counted:
  - moved from using an embedded struct miscdevice to an embedded struct
device.
  - uses an struct rw_semaphore as synchronization for driver detachment
  - uses alloc/register pattern from TPM

Thanks,
Jens

Jens Wiklander (5):
  arm/arm64: add smccc ARCH32
  dt/bindings: add bindings for optee
  tee: generic TEE subsystem
  tee: add OP-TEE driver
  Documentation: tee subsystem and op-tee driver

 Documentation/00-INDEX |   2 +
 Documentation/devicetree/bindings/optee/optee.txt  |  17 +
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 Documentation/ioctl/ioctl-number.txt   |   1 +
 Documentation/tee.txt  | 117 +++
 MAINTAINERS|  14 +
 arch/arm/Kconfig   |   4 +
 arch/arm/kernel/Makefile   |   2 +
 arch/arm/kernel/smccc-call.S   |  26 +
 arch/arm/kernel/smccc.c|  17 +
 arch/arm64/Kconfig |   4 +
 arch/arm64/kernel/Makefile |   1 +
 arch/arm64/kernel/smccc-call.S |  34 +
 arch/arm64/kernel/smccc.c  |  17 +
 drivers/Kconfig|   2 +
 drivers/Makefile   |   1 +
 drivers/tee/Kconfig|  18 +
 drivers/tee/Makefile   |   4 +
 drivers/tee/optee/Kconfig  |   8 +
 drivers/tee/optee/Makefile |   5 +
 drivers/tee/optee/call.c   | 390 ++
 drivers/tee/optee/core.c   | 451 +++
 drivers/tee/optee/optee_msg.h  | 334 
 drivers/tee/optee/optee_priv