RE: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

[Yoshihiro Shimoda]

Hi,

> From: Peter Chen
> Sent: Friday, April 22, 2016 12:34 PM
> 
> On Fri, Apr 22, 2016 at 09:26:46AM +0800, Peter Chen wrote:
> > On Fri, Apr 15, 2016 at 10:03:16AM +, Yoshihiro Shimoda wrote:
> > > Hi,
> > >
> > > > From: Yoshihiro Shimoda
> > > > Sent: Friday, April 15, 2016 6:59 PM
> > > >
> > > > Hi,
> > > >
> > > > > From: Roger Quadros
> > > > > Sent: Thursday, April 14, 2016 8:32 PM
> > > > >
> > > > > On 14/04/16 14:15, Yoshihiro Shimoda wrote:
> > > > > > Hi,
> > > > > >
> > > > < snip >
> > > > > >>> @@ -865,7 +867,8 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, 
> > > > > >>> unsigned int irqnum,
> > > > > >>>* we're ready only if we have shared HCD
> > > > > >>>* or we don't need shared HCD.
> > > > > >>>*/
> > > > > >>> - if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
> > > > > >>> + if (otg->shared_hcd.hcd || (!otg->caps->needs_companion &&
> > > > > >>> + !otg->primary_hcd.hcd->shared_hcd)) 
> > > > > >>> {
> > > > > >>>   otg->host = hcd_to_bus(hcd);
> > > > > >>>   /* FIXME: set bus->otg_port if this is true OTG port 
> > > > > >>> with HNP */
> > > > > >>>
> > > > > >>
> > > > > >> These changes look good to me. Thanks.
> > > > > >
> > > > > > Thank you for the comment.
> > > > > > If we change the "needs_companion" place to the otg_config,
> > > > > > do we need to add a flag into the otg, instead of otg->caps?
> > > > >
> > > > > Yes we can add a flag in struct usb_otg.
> > > >
> > > > Thank you for the comment.
> > > >
> > > > I made a fixed patch.
> > > > So, should I send this patch to ML after you sent v7 patches?
> > > > Or, would you apply this patch before you send v7 patches?
> > >
> > > Oops, I sent this email without my patch...
> > >
> > > ---
> > > Subject: [PATCH] usb: otg: add hcd companion support
> > >
> > > Since some host controller (e.g. EHCI) needs a companion host controller
> > > (e.g. OHCI), this patch adds such a configuration to use it in the OTG
> > > core.
> > >
> > > Signed-off-by: Yoshihiro Shimoda 
> > > ---
> > >  Documentation/devicetree/bindings/usb/generic.txt |  3 +++
> > >  drivers/usb/common/usb-otg.c  | 17 +
> > >  include/linux/usb/otg.h   |  7 ++-
> > >  3 files changed, 22 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/usb/generic.txt 
> > > b/Documentation/devicetree/bindings/usb/generic.txt
> > > index f6866c1..1db1c33 100644
> > > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > > @@ -27,6 +27,9 @@ Optional properties:
> > >   - otg-controller: phandle to otg controller. Host or gadget controllers 
> > > can
> > >   contain this property to link it to a particular OTG
> > >   controller.
> > > + - hcd-needs-companion: must be present if otg controller is dealing with
> > > + EHCI host controller that needs a companion OHCI host
> > > + controller.
> > >
> > >  This is an attribute to a USB controller such as:
> > >
> > > diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> > > index 41e762a..83c8c96 100644
> > > --- a/drivers/usb/common/usb-otg.c
> > > +++ b/drivers/usb/common/usb-otg.c
> > > @@ -20,6 +20,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -600,6 +601,10 @@ struct usb_otg *usb_otg_register(struct device *dev,
> > >   else
> > >   INIT_WORK(>work, usb_otg_work);
> > >
> > > + if (of_find_property(dev->of_node, "hcd-needs-companion", NULL) ||
> > > + config->hcd_needs_companion)/* needs comanion ? */
> > > + otg->flags |= OTG_FLAG_HCD_NEEDS_COMPANION;
> > > +
> > >   otg->wq = create_singlethread_workqueue("usb_otg");
> > >   if (!otg->wq) {
> > >   dev_err(dev, "otg: %s: can't create workqueue\n",
> > > @@ -823,13 +828,15 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, 
> > > unsigned int irqnum,
> > >   /* HCD will be started by OTG fsm when needed */
> > >   mutex_lock(>fsm.lock);
> > >   if (otg->primary_hcd.hcd) {
> > > - /* probably a shared HCD ? */
> > > - if (usb_otg_hcd_is_primary_hcd(hcd)) {
> > > + /* probably a shared HCD or a companion OHCI HCD ? */
> > > + if (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
> > > + usb_otg_hcd_is_primary_hcd(hcd)) {
> > >   dev_err(otg_dev, "otg: primary host already 
> > > registered\n");
> > >   goto err;
> > >   }
> > >
> > > - if (hcd->shared_hcd == otg->primary_hcd.hcd) {
> > > + if (otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION ||
> > > + (hcd->shared_hcd == otg->primary_hcd.hcd)) {
> > >   if (otg->shared_hcd.hcd) {
> > >   

RE: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

[Yoshihiro Shimoda]

Hi,

> From: Peter Chen
> Sent: Friday, April 22, 2016 12:34 PM
> 
> On Fri, Apr 22, 2016 at 09:26:46AM +0800, Peter Chen wrote:
> > On Fri, Apr 15, 2016 at 10:03:16AM +, Yoshihiro Shimoda wrote:
> > > Hi,
> > >
> > > > From: Yoshihiro Shimoda
> > > > Sent: Friday, April 15, 2016 6:59 PM
> > > >
> > > > Hi,
> > > >
> > > > > From: Roger Quadros
> > > > > Sent: Thursday, April 14, 2016 8:32 PM
> > > > >
> > > > > On 14/04/16 14:15, Yoshihiro Shimoda wrote:
> > > > > > Hi,
> > > > > >
> > > > < snip >
> > > > > >>> @@ -865,7 +867,8 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, 
> > > > > >>> unsigned int irqnum,
> > > > > >>>* we're ready only if we have shared HCD
> > > > > >>>* or we don't need shared HCD.
> > > > > >>>*/
> > > > > >>> - if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
> > > > > >>> + if (otg->shared_hcd.hcd || (!otg->caps->needs_companion &&
> > > > > >>> + !otg->primary_hcd.hcd->shared_hcd)) 
> > > > > >>> {
> > > > > >>>   otg->host = hcd_to_bus(hcd);
> > > > > >>>   /* FIXME: set bus->otg_port if this is true OTG port 
> > > > > >>> with HNP */
> > > > > >>>
> > > > > >>
> > > > > >> These changes look good to me. Thanks.
> > > > > >
> > > > > > Thank you for the comment.
> > > > > > If we change the "needs_companion" place to the otg_config,
> > > > > > do we need to add a flag into the otg, instead of otg->caps?
> > > > >
> > > > > Yes we can add a flag in struct usb_otg.
> > > >
> > > > Thank you for the comment.
> > > >
> > > > I made a fixed patch.
> > > > So, should I send this patch to ML after you sent v7 patches?
> > > > Or, would you apply this patch before you send v7 patches?
> > >
> > > Oops, I sent this email without my patch...
> > >
> > > ---
> > > Subject: [PATCH] usb: otg: add hcd companion support
> > >
> > > Since some host controller (e.g. EHCI) needs a companion host controller
> > > (e.g. OHCI), this patch adds such a configuration to use it in the OTG
> > > core.
> > >
> > > Signed-off-by: Yoshihiro Shimoda 
> > > ---
> > >  Documentation/devicetree/bindings/usb/generic.txt |  3 +++
> > >  drivers/usb/common/usb-otg.c  | 17 +
> > >  include/linux/usb/otg.h   |  7 ++-
> > >  3 files changed, 22 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/usb/generic.txt 
> > > b/Documentation/devicetree/bindings/usb/generic.txt
> > > index f6866c1..1db1c33 100644
> > > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > > @@ -27,6 +27,9 @@ Optional properties:
> > >   - otg-controller: phandle to otg controller. Host or gadget controllers 
> > > can
> > >   contain this property to link it to a particular OTG
> > >   controller.
> > > + - hcd-needs-companion: must be present if otg controller is dealing with
> > > + EHCI host controller that needs a companion OHCI host
> > > + controller.
> > >
> > >  This is an attribute to a USB controller such as:
> > >
> > > diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> > > index 41e762a..83c8c96 100644
> > > --- a/drivers/usb/common/usb-otg.c
> > > +++ b/drivers/usb/common/usb-otg.c
> > > @@ -20,6 +20,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -600,6 +601,10 @@ struct usb_otg *usb_otg_register(struct device *dev,
> > >   else
> > >   INIT_WORK(>work, usb_otg_work);
> > >
> > > + if (of_find_property(dev->of_node, "hcd-needs-companion", NULL) ||
> > > + config->hcd_needs_companion)/* needs comanion ? */
> > > + otg->flags |= OTG_FLAG_HCD_NEEDS_COMPANION;
> > > +
> > >   otg->wq = create_singlethread_workqueue("usb_otg");
> > >   if (!otg->wq) {
> > >   dev_err(dev, "otg: %s: can't create workqueue\n",
> > > @@ -823,13 +828,15 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, 
> > > unsigned int irqnum,
> > >   /* HCD will be started by OTG fsm when needed */
> > >   mutex_lock(>fsm.lock);
> > >   if (otg->primary_hcd.hcd) {
> > > - /* probably a shared HCD ? */
> > > - if (usb_otg_hcd_is_primary_hcd(hcd)) {
> > > + /* probably a shared HCD or a companion OHCI HCD ? */
> > > + if (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
> > > + usb_otg_hcd_is_primary_hcd(hcd)) {
> > >   dev_err(otg_dev, "otg: primary host already 
> > > registered\n");
> > >   goto err;
> > >   }
> > >
> > > - if (hcd->shared_hcd == otg->primary_hcd.hcd) {
> > > + if (otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION ||
> > > + (hcd->shared_hcd == otg->primary_hcd.hcd)) {
> > >   if (otg->shared_hcd.hcd) {
> > >   dev_err(otg_dev, "otg: shared host already 
> > 

[PATCH RESEND v2 3/4] ARM64: dts: rockchip: add RK3399 evaluation board

[Jianqun Xu]

The RK3399 evaluation board is designed with pmic
rk808 on top board.

Signed-off-by: Jianqun Xu 
---
changes in v2:
- new add patch

 Documentation/devicetree/bindings/arm/rockchip.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt 
b/Documentation/devicetree/bindings/arm/rockchip.txt
index 2549519..6491b56 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -101,4 +101,8 @@ Rockchip platforms device tree bindings
 
 - Rockchip RK3228 Evaluation board:
 Required root node properties:
-  - compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
+ - compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
+
+- Rockchip RK3399 evb:
+Required root node properties:
+  - compatible = "rockchip,rk3399-evb", "rockchip,rk3399";
-- 
1.9.1

[PATCH RESEND v2 3/4] ARM64: dts: rockchip: add RK3399 evaluation board

[Jianqun Xu]

The RK3399 evaluation board is designed with pmic
rk808 on top board.

Signed-off-by: Jianqun Xu 
---
changes in v2:
- new add patch

 Documentation/devicetree/bindings/arm/rockchip.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt 
b/Documentation/devicetree/bindings/arm/rockchip.txt
index 2549519..6491b56 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -101,4 +101,8 @@ Rockchip platforms device tree bindings
 
 - Rockchip RK3228 Evaluation board:
 Required root node properties:
-  - compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
+ - compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
+
+- Rockchip RK3399 evb:
+Required root node properties:
+  - compatible = "rockchip,rk3399-evb", "rockchip,rk3399";
-- 
1.9.1

[PATCH RESEND v2 4/4] ARM64: dts: rockchip: add dts file for RK3399 evaluation board

[Jianqun Xu]

This patch add rk3399-evb.dts for RK3399 evaluation board.
Tested on RK3399 evb.

Signed-off-by: Jianqun Xu 
---
changes in v2:
- remove rk808 since without i2c, which will upstream independently
- remove es8316 since without i2c, which will upstream independently
- fix codingstyle issues

 arch/arm64/boot/dts/rockchip/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 122 
 2 files changed, 123 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index df37865..7037a16 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -1,6 +1,7 @@
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
new file mode 100644
index 000..309f870
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -0,0 +1,122 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   compatible = "rockchip,rk3399-evb", "rockchip,rk3399";
+
+   vdd_center: vdd-center {
+   compatible = "pwm-regulator";
+   pwms = < 0 25000 0>;
+   regulator-name = "vdd_center";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-always-on;
+   regulator-boot-on;
+   status = "okay";
+   };
+
+   vcc3v3_sys: vcc3v3-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   vcc_phy: vcc-phy-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_phy";
+   regulator-always-on;
+   regulator-boot-on;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_host0_ehci {
+   status = "okay";
+};
+
+_host0_ohci {
+   status = "okay";
+};
+
+_host1_ehci {
+   status = "okay";
+};
+
+_host1_ohci {
+   status = "okay";
+};
+
+ {
+   pmic {
+   pmic_int_l: pmic-int-l {
+   rockchip,pins =
+   <1 21 RK_FUNC_GPIO _pull_up>;
+   };
+
+   pmic_dvs2: pmic-dvs2 {
+   rockchip,pins =
+   <1 18 RK_FUNC_GPIO _pull_down>;
+

[PATCH RESEND v2 4/4] ARM64: dts: rockchip: add dts file for RK3399 evaluation board

[Jianqun Xu]

This patch add rk3399-evb.dts for RK3399 evaluation board.
Tested on RK3399 evb.

Signed-off-by: Jianqun Xu 
---
changes in v2:
- remove rk808 since without i2c, which will upstream independently
- remove es8316 since without i2c, which will upstream independently
- fix codingstyle issues

 arch/arm64/boot/dts/rockchip/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 122 
 2 files changed, 123 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index df37865..7037a16 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -1,6 +1,7 @@
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
new file mode 100644
index 000..309f870
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -0,0 +1,122 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   compatible = "rockchip,rk3399-evb", "rockchip,rk3399";
+
+   vdd_center: vdd-center {
+   compatible = "pwm-regulator";
+   pwms = < 0 25000 0>;
+   regulator-name = "vdd_center";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-always-on;
+   regulator-boot-on;
+   status = "okay";
+   };
+
+   vcc3v3_sys: vcc3v3-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   vcc_phy: vcc-phy-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_phy";
+   regulator-always-on;
+   regulator-boot-on;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_host0_ehci {
+   status = "okay";
+};
+
+_host0_ohci {
+   status = "okay";
+};
+
+_host1_ehci {
+   status = "okay";
+};
+
+_host1_ohci {
+   status = "okay";
+};
+
+ {
+   pmic {
+   pmic_int_l: pmic-int-l {
+   rockchip,pins =
+   <1 21 RK_FUNC_GPIO _pull_up>;
+   };
+
+   pmic_dvs2: pmic-dvs2 {
+   rockchip,pins =
+   <1 18 RK_FUNC_GPIO _pull_down>;
+   };
+   

[PATCH RESEND v2 2/4] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs

[Jianqun Xu]

This patch adds core dtsi file for Rockchip RK3399 SoCs.

The RK3399 has big/little architecture, which needs a separate
node for the PMU of each microarchitecture, for now it missing
the pmu node since the old one could not work well.

Marc is working on it with:
https://lkml.org/lkml/2016/4/11/182

and on the following branch:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
irq/percpu-partition

That will to be tested on RK3399 evb.

Signed-off-by: Jianqun Xu 
---
changes in v2:
- remove arm-pmu at first. (Marc, Heiko, Mark)
- remove rga, emmc, usb3, mipi, edp, pd, i2c, gpu, thermal, tsadc, saradc, 
which will upstream independently

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1022 ++
 1 file changed, 1022 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 000..5a8a915
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,1022 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "rockchip,rk3399";
+
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   serial4 = 
+   };
+
+   psci {
+   compatible = "arm,psci-1.0";
+   method = "smc";
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <_l0>;
+   };
+   core1 {
+   cpu = <_l1>;
+   };
+   core2 {
+   cpu = <_l2>;
+   };
+   core3 {
+   cpu = <_l3>;
+   };
+   };
+
+   cluster1 {
+   core0 {
+   cpu = <_b0>;
+   };
+   core1 {
+   cpu = <_b1>;
+   };
+   };
+   };
+
+   cpu_l0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   #cooling-cells = <2>; /* min followed by max */
+   clocks = < ARMCLKL>;
+   };
+

[PATCH RESEND v2 2/4] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs

[Jianqun Xu]

This patch adds core dtsi file for Rockchip RK3399 SoCs.

The RK3399 has big/little architecture, which needs a separate
node for the PMU of each microarchitecture, for now it missing
the pmu node since the old one could not work well.

Marc is working on it with:
https://lkml.org/lkml/2016/4/11/182

and on the following branch:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
irq/percpu-partition

That will to be tested on RK3399 evb.

Signed-off-by: Jianqun Xu 
---
changes in v2:
- remove arm-pmu at first. (Marc, Heiko, Mark)
- remove rga, emmc, usb3, mipi, edp, pd, i2c, gpu, thermal, tsadc, saradc, 
which will upstream independently

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1022 ++
 1 file changed, 1022 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 000..5a8a915
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,1022 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "rockchip,rk3399";
+
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   serial4 = 
+   };
+
+   psci {
+   compatible = "arm,psci-1.0";
+   method = "smc";
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <_l0>;
+   };
+   core1 {
+   cpu = <_l1>;
+   };
+   core2 {
+   cpu = <_l2>;
+   };
+   core3 {
+   cpu = <_l3>;
+   };
+   };
+
+   cluster1 {
+   core0 {
+   cpu = <_b0>;
+   };
+   core1 {
+   cpu = <_b1>;
+   };
+   };
+   };
+
+   cpu_l0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   #cooling-cells = <2>; /* min followed by max */
+   clocks = < ARMCLKL>;
+   };
+
+   

[PATCH RESEND v2 0/4] ARM64: dts: rockchip: add support for RK3399

[Jianqun Xu]

Add dtsi file for RK3399 SoCs, and evb dts file for RK3399 evb.

To make patch more easily to be reviewed, some nodes have been removed
temporarily, after this base file been applied, more patches will be
upstreamed independently.

Jianqun Xu (3):
  ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs
  ARM64: dts: rockchip: add RK3399 evaluation board
  ARM64: dts: rockchip: add dts file for RK3399 evaluation board

Shawn Lin (1):
  Documentation: rockchip-dw-mshc: add description for rk3399

 Documentation/devicetree/bindings/arm/rockchip.txt |6 +-
 .../devicetree/bindings/mmc/rockchip-dw-mshc.txt   |1 +
 arch/arm64/boot/dts/rockchip/Makefile  |1 +
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts|  122 +++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   | 1022 
 5 files changed, 1151 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

--
changes in v2:
- split into more patches. (Heiko)
- remove arm-pmu at first. (Marc, Heiko, Mark)
- remove rga, emmc, usb3, mipi, edp, pd, i2c, gpu, thermal, tsadc, saradc, 
which will upstream independently
- remove rk808 since without i2c, which will upstream independently
- remove es8316 since without i2c, which will upstream independently
- add rockchip-dw-mshc binding patch
- add rockchip,rk3399-evb binding patch
- fix codingstyle issues

1.9.1

[PATCH RESEND v2 1/4] Documentation: rockchip-dw-mshc: add description for rk3399

[Jianqun Xu]

From: Shawn Lin 

Add "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc" for
dwmmc on rk3399 platform.

Change-Id: Ieefafab5f0e9650271e823659e2bec1556c4a9bc
Signed-off-by: Shawn Lin 
---
changes in v2:
- new add patch

 Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
index ea5614b..07184e8 100644
--- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
@@ -15,6 +15,7 @@ Required Properties:
- "rockchip,rk3288-dw-mshc": for Rockchip RK3288
- "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3036
- "rockchip,rk3368-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3368
+   - "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3399
 
 Optional Properties:
 * clocks: from common clock binding: if ciu_drive and ciu_sample are
-- 
1.9.1

[PATCH RESEND v2 1/4] Documentation: rockchip-dw-mshc: add description for rk3399

[Jianqun Xu]

From: Shawn Lin 

Add "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc" for
dwmmc on rk3399 platform.

Change-Id: Ieefafab5f0e9650271e823659e2bec1556c4a9bc
Signed-off-by: Shawn Lin 
---
changes in v2:
- new add patch

 Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
index ea5614b..07184e8 100644
--- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
@@ -15,6 +15,7 @@ Required Properties:
- "rockchip,rk3288-dw-mshc": for Rockchip RK3288
- "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3036
- "rockchip,rk3368-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3368
+   - "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3399
 
 Optional Properties:
 * clocks: from common clock binding: if ciu_drive and ciu_sample are
-- 
1.9.1

[PATCH RESEND v2 0/4] ARM64: dts: rockchip: add support for RK3399

[Jianqun Xu]

Add dtsi file for RK3399 SoCs, and evb dts file for RK3399 evb.

To make patch more easily to be reviewed, some nodes have been removed
temporarily, after this base file been applied, more patches will be
upstreamed independently.

Jianqun Xu (3):
  ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs
  ARM64: dts: rockchip: add RK3399 evaluation board
  ARM64: dts: rockchip: add dts file for RK3399 evaluation board

Shawn Lin (1):
  Documentation: rockchip-dw-mshc: add description for rk3399

 Documentation/devicetree/bindings/arm/rockchip.txt |6 +-
 .../devicetree/bindings/mmc/rockchip-dw-mshc.txt   |1 +
 arch/arm64/boot/dts/rockchip/Makefile  |1 +
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts|  122 +++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   | 1022 
 5 files changed, 1151 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

--
changes in v2:
- split into more patches. (Heiko)
- remove arm-pmu at first. (Marc, Heiko, Mark)
- remove rga, emmc, usb3, mipi, edp, pd, i2c, gpu, thermal, tsadc, saradc, 
which will upstream independently
- remove rk808 since without i2c, which will upstream independently
- remove es8316 since without i2c, which will upstream independently
- add rockchip-dw-mshc binding patch
- add rockchip,rk3399-evb binding patch
- fix codingstyle issues

1.9.1

[PATCH] usb: core: Do not use sizeof on pointer type

[Vaishali Thakkar]

When sizeof is applied to a pointer typed expression, it gives
the size of the pointer. So, do not use sizeof on pointer type.

Problem found using Coccinelle.

Signed-off-by: Vaishali Thakkar 
---
 drivers/usb/core/hcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 2ca2cef..2aa352d 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1386,7 +1386,7 @@ static int hcd_alloc_coherent(struct usb_bus *bus,
return -EFAULT;
}
 
-   vaddr = hcd_buffer_alloc(bus, size + sizeof(vaddr),
+   vaddr = hcd_buffer_alloc(bus, size + sizeof(*vaddr),
 mem_flags, dma_handle);
if (!vaddr)
return -ENOMEM;
-- 
2.1.4

[PATCH] usb: core: Do not use sizeof on pointer type

[Vaishali Thakkar]

When sizeof is applied to a pointer typed expression, it gives
the size of the pointer. So, do not use sizeof on pointer type.

Problem found using Coccinelle.

Signed-off-by: Vaishali Thakkar 
---
 drivers/usb/core/hcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 2ca2cef..2aa352d 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1386,7 +1386,7 @@ static int hcd_alloc_coherent(struct usb_bus *bus,
return -EFAULT;
}
 
-   vaddr = hcd_buffer_alloc(bus, size + sizeof(vaddr),
+   vaddr = hcd_buffer_alloc(bus, size + sizeof(*vaddr),
 mem_flags, dma_handle);
if (!vaddr)
return -ENOMEM;
-- 
2.1.4

Re: [RESEND PATCH v4] clk/axs10x: Add I2S PLL clock driver

[Vineet Gupta]

On Thursday 21 April 2016 05:48 PM, Alexey Brodkin wrote:
> Hi Jose,
> 
> On Thu, 2016-04-21 at 10:51 +0100, Jose Abreu wrote:
>> Hi Alexey,
> 
> 
> Otherwise, I still prefer two DTS files for the two different FPGA
> versions. At the least, please use ioremap for any pointers that
> you readl/writel here.
>
> Beyond that, we should have a fixed rate source clk somewhere in
> the software view of the clk tree, because that reflects reality.
> Hardcoding the parent rate in the structure works, but doesn't
> properly express the clk tree.
>
 Can I use a property in the DT to pass this reference clock? something 
 like this:
 snps,parent-freq = <0xFBED9 2700>, <0x0 28224000>; /* Tuple
 , fpga-version = 0 is default */

 Or use a parent clock? like:
 clk {
 compatible = "fixed-clock";
 clock-frequency = <2700>;
 #clock-cells = <0>;
 snps,fpga-version = <0xFBED9>;
 }

 It is important to distinguish between the different versions 
 automatically, is
 any of these solutions ok?
>>> I do like that solution with a master clock but with some fine-tuning
>>> for simplification.
>>>
>>> We'll add master clock node for I2S as a fixed clock like that:
>>> --->8--
>>> i2s_master_clock: clk {
>>> #clock-cells = <0>;
>>> compatible = "fixed-clock";
>>> clock-frequency = <2700>;
>>> };
>>> --->8--
>>>
>>> Note there's no mention of MB version, just a value of the frequency.
>>> And in the driver itself value of that master clock will be used for
>>> population of "pll_clk->ref_clk" directly.
>>>
>>> These are benefits we'll get with that approach:
>>>  [1] We escape any IOs not related to our clock device (I mean
>>>  "snps,i2s-pll-clock") itself.
>>>  [2] We'll use whatever reference clock value is given.
>>>  I.e. we'll be able to do a fix-up of that reference clock
>>>  value early in platform code depending on HW we're running on.
>>>  That's what people do here and there.
>>>  [3] Remember another clock driver for AXS10x board is right around
>>>  the corner. I mean the one for ARC PGU which uses exactly the same
>>>  master clock. So one fixup as mentioned above will work
>>>  at once for 2 clock drivers.
>>>
>>> Let me know if above makes sense.
>> That approach can't be used because the reference clock value will change in 
>> the
>> next firmware release.  The new release will have a reference clock of 
>> 28224000
>> Hz instead of the usual 2700 Hz, so we need to have a way to distinguish
>> between them. Because of that we can't have only one master clock unless you
>> state to users that they have to change the reference clock value when using 
>> the
>> new firmware release. Stephen suggested to use two DT files (one for each
>> firmware release), but as Vineet said this would be annoying to the user so 
>> I am
>> trying to use another solution so that only one DT file is required.
> 
> Ok reference clock will change.
> But I may guess we'll still be able to determine at least that new
> firmware version in run-time, right? If so we'll update a fix-up in
> early axs10x platform code so that reference clock will be set as 28224000 Hz.


Please no - lets not bolt-in more hacks and instead try do this cleanly if
possible. And from other discusions it seems there might be a way. The readl
approach seems fine to me (with ioremap) if that is what it takes.


> And indeed 2 DT files is a no go - we want to run the same one binary
> (with built-in .dtb) on all flavors of AXS boards.

Right - 2 DT is not acceptable unless we are feeling bored and want more emails
for AXS board support :-)

 And fix-up I'm talking about
> will actually do transformation of .dtb early on kernel boot process so that 
> will
> be a complete equivalent of different DT files.
> 
> -Alexey--
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RESEND PATCH v4] clk/axs10x: Add I2S PLL clock driver

[Vineet Gupta]

On Thursday 21 April 2016 05:48 PM, Alexey Brodkin wrote:
> Hi Jose,
> 
> On Thu, 2016-04-21 at 10:51 +0100, Jose Abreu wrote:
>> Hi Alexey,
> 
> 
> Otherwise, I still prefer two DTS files for the two different FPGA
> versions. At the least, please use ioremap for any pointers that
> you readl/writel here.
>
> Beyond that, we should have a fixed rate source clk somewhere in
> the software view of the clk tree, because that reflects reality.
> Hardcoding the parent rate in the structure works, but doesn't
> properly express the clk tree.
>
 Can I use a property in the DT to pass this reference clock? something 
 like this:
 snps,parent-freq = <0xFBED9 2700>, <0x0 28224000>; /* Tuple
 , fpga-version = 0 is default */

 Or use a parent clock? like:
 clk {
 compatible = "fixed-clock";
 clock-frequency = <2700>;
 #clock-cells = <0>;
 snps,fpga-version = <0xFBED9>;
 }

 It is important to distinguish between the different versions 
 automatically, is
 any of these solutions ok?
>>> I do like that solution with a master clock but with some fine-tuning
>>> for simplification.
>>>
>>> We'll add master clock node for I2S as a fixed clock like that:
>>> --->8--
>>> i2s_master_clock: clk {
>>> #clock-cells = <0>;
>>> compatible = "fixed-clock";
>>> clock-frequency = <2700>;
>>> };
>>> --->8--
>>>
>>> Note there's no mention of MB version, just a value of the frequency.
>>> And in the driver itself value of that master clock will be used for
>>> population of "pll_clk->ref_clk" directly.
>>>
>>> These are benefits we'll get with that approach:
>>>  [1] We escape any IOs not related to our clock device (I mean
>>>  "snps,i2s-pll-clock") itself.
>>>  [2] We'll use whatever reference clock value is given.
>>>  I.e. we'll be able to do a fix-up of that reference clock
>>>  value early in platform code depending on HW we're running on.
>>>  That's what people do here and there.
>>>  [3] Remember another clock driver for AXS10x board is right around
>>>  the corner. I mean the one for ARC PGU which uses exactly the same
>>>  master clock. So one fixup as mentioned above will work
>>>  at once for 2 clock drivers.
>>>
>>> Let me know if above makes sense.
>> That approach can't be used because the reference clock value will change in 
>> the
>> next firmware release.  The new release will have a reference clock of 
>> 28224000
>> Hz instead of the usual 2700 Hz, so we need to have a way to distinguish
>> between them. Because of that we can't have only one master clock unless you
>> state to users that they have to change the reference clock value when using 
>> the
>> new firmware release. Stephen suggested to use two DT files (one for each
>> firmware release), but as Vineet said this would be annoying to the user so 
>> I am
>> trying to use another solution so that only one DT file is required.
> 
> Ok reference clock will change.
> But I may guess we'll still be able to determine at least that new
> firmware version in run-time, right? If so we'll update a fix-up in
> early axs10x platform code so that reference clock will be set as 28224000 Hz.


Please no - lets not bolt-in more hacks and instead try do this cleanly if
possible. And from other discusions it seems there might be a way. The readl
approach seems fine to me (with ioremap) if that is what it takes.


> And indeed 2 DT files is a no go - we want to run the same one binary
> (with built-in .dtb) on all flavors of AXS boards.

Right - 2 DT is not acceptable unless we are feeling bored and want more emails
for AXS board support :-)

 And fix-up I'm talking about
> will actually do transformation of .dtb early on kernel boot process so that 
> will
> be a complete equivalent of different DT files.
> 
> -Alexey--
> To unsubscribe from this list: send the line "unsubscribe linux-clk" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 7/9] thermal: of: Add support for hardware-tracked trip points

[Sascha Hauer]

On Fri, Apr 22, 2016 at 09:54:19AM +0800, Caesar Wang wrote:
> Hi Brian, Eduardo, Sascha
> 
> 在 2016年04月21日 09:12, Brian Norris 写道:
> >+ Sascha
> >
> >On Wed, Apr 20, 2016 at 04:48:18PM -0700, Eduardo Valentin wrote:
> >>On Mon, Apr 18, 2016 at 11:35:59AM +0800, Caesar Wang wrote:
> >>>From: Mikko Perttunen 
> >>>
> >>>This adds support for hardware-tracked trip points to the device tree
> >>
> >>
> >>>diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> >>>index 97b86c5..6ef932a 100644
> >>>--- a/include/linux/thermal.h
> >>>+++ b/include/linux/thermal.h
> >>>@@ -335,12 +335,14 @@ struct thermal_genl_event {
> >>>   * @get_trend: a pointer to a function that reads the sensor temperature 
> >>> trend.
> >>>   * @set_emul_temp: a pointer to a function that sets sensor emulated
> >>>   *  temperature.
> >>>+ * @set_trips: a pointer to a function that set low/high trip temperature.
> >>>   */
> >>>  struct thermal_zone_of_device_ops {
> >>>   int (*get_temp)(void *, int *);
> >>>   int (*get_trend)(void *, long *);
> >>>   int (*set_emul_temp)(void *, int);
> >>>   int (*set_trip_temp)(void *, int, int);
> >>>+  int (*set_trips)(void *, int, int);
> >>This is unfortunately a diverges from API available on thermal core. Can
> >>you please add first on thermal core then, use it in of thermal?
> >>
> >>I don't want to have callbacks available only via of thermal. If we
> >>allow it, OF thermal becomes a separate API.
> >What ever happened to this effort?
> >
> >http://thread.gmane.org/gmane.linux.power-management.general/59451
> >
> >Patch 12 and 13 look to accomplish something similar, yet they do what
> >Eduardo suggested. I was testing that series at my previous job, but
> >unfortunately (for the fate of this series) I left that employer before
> >I could finish reviewing and testing it. Perhaps Caesar can resurrect
> >and test it?
> 
> @Brian
> Yes, I can
> 
> Sure, I can.
> 
> I see the Sascha's newest thermal patches in patchwork.
> The following patches are still needed, right?
> 
> 6446191 New  [06/16] thermal: inline only once used function
> 6446111 New  [07/16] thermal: streamline get_trend callbacks
> 6445871 New  [08/16] thermal: Allow sensor ops to fail with -ENOSYS
> 6445861 New  [09/16] thermal: of: always set sensor related
> callbacks
> 6446221 New  [10/16] thermal: Make struct thermal_zone_device_ops
> const
> 6446201 New  [11/16] thermal: bang-bang governor: act on lower trip
> boundary
> 6445891 New  [12/16] thermal: thermal: Add support for
> hardware-tracked trip points
> 6445911 New  [13/16] thermal: of: implement .set_trips for device
> tree thermal zones
> 
> @Sascha, Eduardo
> Can you share your discussion content for the above patches as remembered?

These are still the newest patches. I won't have any resources in the
near future for continuing the work on them, so feel free to pick them
up. There hasn't been much discussion around these patches which was the
reason I abandoned them.

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH 7/9] thermal: of: Add support for hardware-tracked trip points

[Sascha Hauer]

On Fri, Apr 22, 2016 at 09:54:19AM +0800, Caesar Wang wrote:
> Hi Brian, Eduardo, Sascha
> 
> 在 2016年04月21日 09:12, Brian Norris 写道:
> >+ Sascha
> >
> >On Wed, Apr 20, 2016 at 04:48:18PM -0700, Eduardo Valentin wrote:
> >>On Mon, Apr 18, 2016 at 11:35:59AM +0800, Caesar Wang wrote:
> >>>From: Mikko Perttunen 
> >>>
> >>>This adds support for hardware-tracked trip points to the device tree
> >>
> >>
> >>>diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> >>>index 97b86c5..6ef932a 100644
> >>>--- a/include/linux/thermal.h
> >>>+++ b/include/linux/thermal.h
> >>>@@ -335,12 +335,14 @@ struct thermal_genl_event {
> >>>   * @get_trend: a pointer to a function that reads the sensor temperature 
> >>> trend.
> >>>   * @set_emul_temp: a pointer to a function that sets sensor emulated
> >>>   *  temperature.
> >>>+ * @set_trips: a pointer to a function that set low/high trip temperature.
> >>>   */
> >>>  struct thermal_zone_of_device_ops {
> >>>   int (*get_temp)(void *, int *);
> >>>   int (*get_trend)(void *, long *);
> >>>   int (*set_emul_temp)(void *, int);
> >>>   int (*set_trip_temp)(void *, int, int);
> >>>+  int (*set_trips)(void *, int, int);
> >>This is unfortunately a diverges from API available on thermal core. Can
> >>you please add first on thermal core then, use it in of thermal?
> >>
> >>I don't want to have callbacks available only via of thermal. If we
> >>allow it, OF thermal becomes a separate API.
> >What ever happened to this effort?
> >
> >http://thread.gmane.org/gmane.linux.power-management.general/59451
> >
> >Patch 12 and 13 look to accomplish something similar, yet they do what
> >Eduardo suggested. I was testing that series at my previous job, but
> >unfortunately (for the fate of this series) I left that employer before
> >I could finish reviewing and testing it. Perhaps Caesar can resurrect
> >and test it?
> 
> @Brian
> Yes, I can
> 
> Sure, I can.
> 
> I see the Sascha's newest thermal patches in patchwork.
> The following patches are still needed, right?
> 
> 6446191 New  [06/16] thermal: inline only once used function
> 6446111 New  [07/16] thermal: streamline get_trend callbacks
> 6445871 New  [08/16] thermal: Allow sensor ops to fail with -ENOSYS
> 6445861 New  [09/16] thermal: of: always set sensor related
> callbacks
> 6446221 New  [10/16] thermal: Make struct thermal_zone_device_ops
> const
> 6446201 New  [11/16] thermal: bang-bang governor: act on lower trip
> boundary
> 6445891 New  [12/16] thermal: thermal: Add support for
> hardware-tracked trip points
> 6445911 New  [13/16] thermal: of: implement .set_trips for device
> tree thermal zones
> 
> @Sascha, Eduardo
> Can you share your discussion content for the above patches as remembered?

These are still the newest patches. I won't have any resources in the
near future for continuing the work on them, so feel free to pick them
up. There hasn't been much discussion around these patches which was the
reason I abandoned them.

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[PATCH v2 4/4] ARM64: dts: rockchip: add dts file for RK3399 evaluation board

[Jianqun Xu]

This patch add rk3399-evb.dts for RK3399 evaluation board.
Tested on RK3399 evb.

Signed-off-by: Jianqun Xu 
---
changes in v2:
- remove rk808 since without i2c, which will upstream independently
- remove es8316 since without i2c, which will upstream independently
- fix codingstyle issues

 arch/arm64/boot/dts/rockchip/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 122 
 2 files changed, 123 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index df37865..7037a16 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -1,6 +1,7 @@
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
new file mode 100644
index 000..309f870
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -0,0 +1,122 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   compatible = "rockchip,rk3399-evb", "rockchip,rk3399";
+
+   vdd_center: vdd-center {
+   compatible = "pwm-regulator";
+   pwms = < 0 25000 0>;
+   regulator-name = "vdd_center";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-always-on;
+   regulator-boot-on;
+   status = "okay";
+   };
+
+   vcc3v3_sys: vcc3v3-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   vcc_phy: vcc-phy-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_phy";
+   regulator-always-on;
+   regulator-boot-on;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_host0_ehci {
+   status = "okay";
+};
+
+_host0_ohci {
+   status = "okay";
+};
+
+_host1_ehci {
+   status = "okay";
+};
+
+_host1_ohci {
+   status = "okay";
+};
+
+ {
+   pmic {
+   pmic_int_l: pmic-int-l {
+   rockchip,pins =
+   <1 21 RK_FUNC_GPIO _pull_up>;
+   };
+
+   pmic_dvs2: pmic-dvs2 {
+   rockchip,pins =
+   <1 18 RK_FUNC_GPIO _pull_down>;
+

[PATCH v2 4/4] ARM64: dts: rockchip: add dts file for RK3399 evaluation board

[Jianqun Xu]

This patch add rk3399-evb.dts for RK3399 evaluation board.
Tested on RK3399 evb.

Signed-off-by: Jianqun Xu 
---
changes in v2:
- remove rk808 since without i2c, which will upstream independently
- remove es8316 since without i2c, which will upstream independently
- fix codingstyle issues

 arch/arm64/boot/dts/rockchip/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts | 122 
 2 files changed, 123 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index df37865..7037a16 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -1,6 +1,7 @@
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-evb-act8846.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-geekbox.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3368-r88.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-evb.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-evb.dts 
b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
new file mode 100644
index 000..309f870
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399-evb.dts
@@ -0,0 +1,122 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include 
+#include "rk3399.dtsi"
+
+/ {
+   compatible = "rockchip,rk3399-evb", "rockchip,rk3399";
+
+   vdd_center: vdd-center {
+   compatible = "pwm-regulator";
+   pwms = < 0 25000 0>;
+   regulator-name = "vdd_center";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-always-on;
+   regulator-boot-on;
+   status = "okay";
+   };
+
+   vcc3v3_sys: vcc3v3-sys {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   vcc_phy: vcc-phy-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_phy";
+   regulator-always-on;
+   regulator-boot-on;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_host0_ehci {
+   status = "okay";
+};
+
+_host0_ohci {
+   status = "okay";
+};
+
+_host1_ehci {
+   status = "okay";
+};
+
+_host1_ohci {
+   status = "okay";
+};
+
+ {
+   pmic {
+   pmic_int_l: pmic-int-l {
+   rockchip,pins =
+   <1 21 RK_FUNC_GPIO _pull_up>;
+   };
+
+   pmic_dvs2: pmic-dvs2 {
+   rockchip,pins =
+   <1 18 RK_FUNC_GPIO _pull_down>;
+   };
+   

RE: [PATCH v6 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding documentation

[Appana Durga Kedareswara Rao]

Hi Rob,

Thanks for the review...

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Thursday, April 21, 2016 7:12 PM
> To: Appana Durga Kedareswara Rao 
> Cc: pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal Simek
> ; Soren Brinkmann ;
> vinod.k...@intel.com; dan.j.willi...@intel.com; Appana Durga Kedareswara
> Rao ; moritz.fisc...@ettus.com;
> laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Anirudha
> Sarangi ; Punnaiah Choudary Kalluri
> ; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> dmaeng...@vger.kernel.org
> Subject: Re: [PATCH v6 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma
> device tree binding documentation
> 
> On Fri, Apr 15, 2016 at 02:22:53PM +0530, Kedareswara rao Appana wrote:
> > Device-tree binding documentation for Xilinx zynqmp dma engine used in
> > Zynq UltraScale+ MPSoC.
> >
> > Signed-off-by: Punnaiah Choudary Kalluri 
> > Signed-off-by: Kedareswara rao Appana 
> > ---
> > Changes in v6:
> > - Removed desc-axi-cache/dst-axi-cache/src-axi-cache properties
> >   from the binding doc as it allow broken combinations when dma-coherent
> >   is set as suggested by Rob.
> > - Fixed minor comments given by Rob related coding(lower case DT node
> name).
> > Changes in v5:
> > - Use dma-coherent flag for coherent transfers as suggested by rob.
> > - Removed unnecessary properties from binding doc as suggested by Rob.
> > Changes in v4:
> > - None
> > Changes in v3:
> > - None
> > Changes in v2:
> > - None.
> >
> >  .../devicetree/bindings/dma/xilinx/zynqmp_dma.txt  | 44
> ++
> >  1 file changed, 44 insertions(+)
> >  create mode 100644
> Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
> >
> > diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
> b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
> > new file mode 100644
> > index 000..f0f0b54
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
> > @@ -0,0 +1,44 @@
> > +Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
> > +memory to device and device to memory transfers. It also has flow
> > +control and rate control support for slave/peripheral dma access.
> > +
> > +Required properties:
> > +- compatible   : Should be "xlnx,zynqmp-dma-1.0"
> > +- reg  : Memory map for gdma/adma module access.
> > +- interrupt-parent : Interrupt controller the interrupt is routed through
> > +- interrupts   : Should contain DMA channel interrupt.
> > +- xlnx,bus-width   : Axi buswidth in bits. Should contain 128 or 64
> 
> I think how this is getting used by the driver is wrong.
> {src,dst}_addr_widths are supposed to be a bitmask of supported slave
> device register widths. You aren't doing a bitmask and you are also
> saying you only support slaves with 8 or 16 byte data registers which is
> somewhat rare. It may happen to work because 128/8 == BIT(4). However,
> the documentation for the field is contradictory in that it says 1,2,4
> or 8 byte widths are supported, but the enum has more sizes.


The DMA supports an AXI bus width of 128/64 bits only.
Please refer IP data sheet. 
http://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
 Page No: 359(DMA Over fetch section).

That's why during probe we are making the dma_device supported source and 
destination address widths accordingly based on the DT property.

Snap shot of driver code from the probe:
   struct dma_device *p; 
   p->dst_addr_widths = zdev->chan->bus_width / 8;
   p->src_addr_widths = zdev->chan->bus_width / 8;

Where bus_width property is read from the probe.
err = of_property_read_u32(node, "xlnx,bus-width", >bus_width)

Cheers!,
Kedar...

> 
> Rob

RE: [PATCH v6 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma device tree binding documentation

[Appana Durga Kedareswara Rao]

Hi Rob,

Thanks for the review...

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Thursday, April 21, 2016 7:12 PM
> To: Appana Durga Kedareswara Rao 
> Cc: pawel.m...@arm.com; mark.rutl...@arm.com;
> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org; Michal Simek
> ; Soren Brinkmann ;
> vinod.k...@intel.com; dan.j.willi...@intel.com; Appana Durga Kedareswara
> Rao ; moritz.fisc...@ettus.com;
> laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Anirudha
> Sarangi ; Punnaiah Choudary Kalluri
> ; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> dmaeng...@vger.kernel.org
> Subject: Re: [PATCH v6 1/2] Documentation: DT: dma: Add Xilinx zynqmp dma
> device tree binding documentation
> 
> On Fri, Apr 15, 2016 at 02:22:53PM +0530, Kedareswara rao Appana wrote:
> > Device-tree binding documentation for Xilinx zynqmp dma engine used in
> > Zynq UltraScale+ MPSoC.
> >
> > Signed-off-by: Punnaiah Choudary Kalluri 
> > Signed-off-by: Kedareswara rao Appana 
> > ---
> > Changes in v6:
> > - Removed desc-axi-cache/dst-axi-cache/src-axi-cache properties
> >   from the binding doc as it allow broken combinations when dma-coherent
> >   is set as suggested by Rob.
> > - Fixed minor comments given by Rob related coding(lower case DT node
> name).
> > Changes in v5:
> > - Use dma-coherent flag for coherent transfers as suggested by rob.
> > - Removed unnecessary properties from binding doc as suggested by Rob.
> > Changes in v4:
> > - None
> > Changes in v3:
> > - None
> > Changes in v2:
> > - None.
> >
> >  .../devicetree/bindings/dma/xilinx/zynqmp_dma.txt  | 44
> ++
> >  1 file changed, 44 insertions(+)
> >  create mode 100644
> Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
> >
> > diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
> b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
> > new file mode 100644
> > index 000..f0f0b54
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
> > @@ -0,0 +1,44 @@
> > +Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
> > +memory to device and device to memory transfers. It also has flow
> > +control and rate control support for slave/peripheral dma access.
> > +
> > +Required properties:
> > +- compatible   : Should be "xlnx,zynqmp-dma-1.0"
> > +- reg  : Memory map for gdma/adma module access.
> > +- interrupt-parent : Interrupt controller the interrupt is routed through
> > +- interrupts   : Should contain DMA channel interrupt.
> > +- xlnx,bus-width   : Axi buswidth in bits. Should contain 128 or 64
> 
> I think how this is getting used by the driver is wrong.
> {src,dst}_addr_widths are supposed to be a bitmask of supported slave
> device register widths. You aren't doing a bitmask and you are also
> saying you only support slaves with 8 or 16 byte data registers which is
> somewhat rare. It may happen to work because 128/8 == BIT(4). However,
> the documentation for the field is contradictory in that it says 1,2,4
> or 8 byte widths are supported, but the enum has more sizes.


The DMA supports an AXI bus width of 128/64 bits only.
Please refer IP data sheet. 
http://www.xilinx.com/support/documentation/user_guides/ug1085-zynq-ultrascale-trm.pdf
 Page No: 359(DMA Over fetch section).

That's why during probe we are making the dma_device supported source and 
destination address widths accordingly based on the DT property.

Snap shot of driver code from the probe:
   struct dma_device *p; 
   p->dst_addr_widths = zdev->chan->bus_width / 8;
   p->src_addr_widths = zdev->chan->bus_width / 8;

Where bus_width property is read from the probe.
err = of_property_read_u32(node, "xlnx,bus-width", >bus_width)

Cheers!,
Kedar...

> 
> Rob

linux-next: Tree for Apr 22

[Stephen Rothwell]

Hi all,

There will be no linux-next release on Monday (ANZAC Day).

Changes since 20160421:

New trees:  rdma-leon, rdma-leon-test

The pci tree gained a build failure so I used the version from
next-20160421.

The sound-asoc tree gained a build failure so I used the version from
next-20160421.

The akpm-current tree still had its build failure and gained another
(due to interactions with other trees) for which I applied a patch.

Non-merge commits (relative to Linus' tree): 4966
 4535 files changed, 196470 insertions(+), 99293 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 234 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (5f44abd041c5 Merge tag 'rtc-4.6-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging fixes/master (9735a22799b9 Linux 4.6-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (421e31e58c2a ARCv2: Enable LOCKDEP)
Merging arm-current/fixes (ac36a881b72a ARM: 8564/1: fix cpu feature extracting 
helper)
Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs 
for v4.6-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (4705e02498d6 powerpc: Update TM user feature bits 
in scan_features())
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.)
Merging net/master (b4f70527f052 openvswitch: use flow protocol when 
recalculating ipv6 checksums)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (bcf493428840 netfilter: ebtables: Fix extension lookup 
with identical name)
Merging wireless-drivers/master (e2841ea91611 Merge tag 
'iwlwifi-for-kalle-2016-04-12_2' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (8f815cdde3e5 nl80211: check netlink protocol in socket 
release notification)
Merging sound-current/for-linus (3194ed497939 ALSA: hda - Fix possible race on 
regmap bypass flip)
Merging pci-current/for-linus (67e658794ca1 cxgb4: Set VPD size so we can read 
both VPD structures)
Merging driver-core.current/driver-core-linus (c3b46c73264b Linux 4.6-rc4)
Merging tty.current/tty-linus (f077b7368291 Revert "serial: 8250: Add hardware 
dependency to RT288X option")
Merging usb.current/usb-linus (c3b46c73264b Linux 4.6-rc4)
Merging usb-gadget-fixes/fixes (38740a5b87d5 usb: gadget: f_fs: Fix 
use-after-free)
Merging usb-serial-fixes/usb-linus (bf1620068911 Linux 4.6-rc3)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (bf1620068911 Linux 4.6-rc3)
Merging char-misc.current/char-misc-linus (c3b46c73264b Linux 4.6-rc4)
Merging input-current/for-linus (dcc7597116c6 Input: twl4030-vibra - do not 
reparent to grandparent)
Merging crypto-current/master (340ff60ae93a crypto: talitos - fix AEAD tcrypt 
tests)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: f

linux-next: Tree for Apr 22

[Stephen Rothwell]

Hi all,

There will be no linux-next release on Monday (ANZAC Day).

Changes since 20160421:

New trees:  rdma-leon, rdma-leon-test

The pci tree gained a build failure so I used the version from
next-20160421.

The sound-asoc tree gained a build failure so I used the version from
next-20160421.

The akpm-current tree still had its build failure and gained another
(due to interactions with other trees) for which I applied a patch.

Non-merge commits (relative to Linus' tree): 4966
 4535 files changed, 196470 insertions(+), 99293 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 234 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (5f44abd041c5 Merge tag 'rtc-4.6-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux)
Merging fixes/master (9735a22799b9 Linux 4.6-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (421e31e58c2a ARCv2: Enable LOCKDEP)
Merging arm-current/fixes (ac36a881b72a ARM: 8564/1: fix cpu feature extracting 
helper)
Merging m68k-current/for-linus (7b8ba82ad4ad m68k/defconfig: Update defconfigs 
for v4.6-rc2)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (4705e02498d6 powerpc: Update TM user feature bits 
in scan_features())
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.)
Merging net/master (b4f70527f052 openvswitch: use flow protocol when 
recalculating ipv6 checksums)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (bcf493428840 netfilter: ebtables: Fix extension lookup 
with identical name)
Merging wireless-drivers/master (e2841ea91611 Merge tag 
'iwlwifi-for-kalle-2016-04-12_2' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (8f815cdde3e5 nl80211: check netlink protocol in socket 
release notification)
Merging sound-current/for-linus (3194ed497939 ALSA: hda - Fix possible race on 
regmap bypass flip)
Merging pci-current/for-linus (67e658794ca1 cxgb4: Set VPD size so we can read 
both VPD structures)
Merging driver-core.current/driver-core-linus (c3b46c73264b Linux 4.6-rc4)
Merging tty.current/tty-linus (f077b7368291 Revert "serial: 8250: Add hardware 
dependency to RT288X option")
Merging usb.current/usb-linus (c3b46c73264b Linux 4.6-rc4)
Merging usb-gadget-fixes/fixes (38740a5b87d5 usb: gadget: f_fs: Fix 
use-after-free)
Merging usb-serial-fixes/usb-linus (bf1620068911 Linux 4.6-rc3)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (bf1620068911 Linux 4.6-rc3)
Merging char-misc.current/char-misc-linus (c3b46c73264b Linux 4.6-rc4)
Merging input-current/for-linus (dcc7597116c6 Input: twl4030-vibra - do not 
reparent to grandparent)
Merging crypto-current/master (340ff60ae93a crypto: talitos - fix AEAD tcrypt 
tests)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: f

Re: [PATCH 2/2 v5] irqchip/Layerscape: Add SCFG MSI controller support

[Leo Li]

On Mon, Mar 7, 2016 at 3:50 AM, Marc Zyngier  wrote:
> On Mon, 7 Mar 2016 11:36:22 +0800
> Minghuan Lian  wrote:
>
>> Some kind of NXP Layerscape SoC provides a MSI
>> implementation which uses two SCFG registers MSIIR and
>> MSIR to support 32 MSI interrupts for each PCIe controller.
>> The patch is to support it.
>>
>> Signed-off-by: Minghuan Lian 
>
> Acked-by: Marc Zyngier 
>
> The DT binding still needs an Ack from the DT maintainers though (cc'd).

Marc,

Who will be responsible to pick this driver?  I see you are also one
of the maintainers for irqchip.  Can you pick up the driver?  The
binding has already gotten ACKed by the device tree maintainer.

Regards,
Leo

[PATCH 3/4] ARM64: dts: rockchip: add RK3399 evaluation board

[Jianqun Xu]

The RK3399 evaluation board is designed with pmic
rk808 on top board.

Signed-off-by: Jianqun Xu 
---
changes in v2:
- remove rk808 since without i2c, which will upstream independently
- remove es8316 since without i2c, which will upstream independently

 Documentation/devicetree/bindings/arm/rockchip.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt 
b/Documentation/devicetree/bindings/arm/rockchip.txt
index 2549519..6491b56 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -101,4 +101,8 @@ Rockchip platforms device tree bindings
 
 - Rockchip RK3228 Evaluation board:
 Required root node properties:
-  - compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
+ - compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
+
+- Rockchip RK3399 evb:
+Required root node properties:
+  - compatible = "rockchip,rk3399-evb", "rockchip,rk3399";
-- 
1.9.1

Re: [PATCH 2/2 v5] irqchip/Layerscape: Add SCFG MSI controller support

[Leo Li]

On Mon, Mar 7, 2016 at 3:50 AM, Marc Zyngier  wrote:
> On Mon, 7 Mar 2016 11:36:22 +0800
> Minghuan Lian  wrote:
>
>> Some kind of NXP Layerscape SoC provides a MSI
>> implementation which uses two SCFG registers MSIIR and
>> MSIR to support 32 MSI interrupts for each PCIe controller.
>> The patch is to support it.
>>
>> Signed-off-by: Minghuan Lian 
>
> Acked-by: Marc Zyngier 
>
> The DT binding still needs an Ack from the DT maintainers though (cc'd).

Marc,

Who will be responsible to pick this driver?  I see you are also one
of the maintainers for irqchip.  Can you pick up the driver?  The
binding has already gotten ACKed by the device tree maintainer.

Regards,
Leo

[PATCH 3/4] ARM64: dts: rockchip: add RK3399 evaluation board

[Jianqun Xu]

The RK3399 evaluation board is designed with pmic
rk808 on top board.

Signed-off-by: Jianqun Xu 
---
changes in v2:
- remove rk808 since without i2c, which will upstream independently
- remove es8316 since without i2c, which will upstream independently

 Documentation/devicetree/bindings/arm/rockchip.txt | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt 
b/Documentation/devicetree/bindings/arm/rockchip.txt
index 2549519..6491b56 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -101,4 +101,8 @@ Rockchip platforms device tree bindings
 
 - Rockchip RK3228 Evaluation board:
 Required root node properties:
-  - compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
+ - compatible = "rockchip,rk3228-evb", "rockchip,rk3228";
+
+- Rockchip RK3399 evb:
+Required root node properties:
+  - compatible = "rockchip,rk3399-evb", "rockchip,rk3399";
-- 
1.9.1

[PATCH v2 2/4] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs

[Jianqun Xu]

This patch adds core dtsi file for Rockchip RK3399 SoCs.

The RK3399 has big/little architecture, which needs a separate
node for the PMU of each microarchitecture, for now it missing
the pmu node since the old one could not work well.

Marc is working on it with:
https://lkml.org/lkml/2016/4/11/182

and on the following branch:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
irq/percpu-partition

That will to be tested on RK3399 evb.

Signed-off-by: Jianqun Xu 
---
changes in v2:
- remove arm-pmu at first. (Marc, Heiko, Mark)
- remove rga, emmc, usb3, mipi, edp, pd, i2c, gpu, thermal, tsadc, saradc, 
which will upstream independently

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1022 ++
 1 file changed, 1022 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 000..5a8a915
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,1022 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "rockchip,rk3399";
+
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   serial4 = 
+   };
+
+   psci {
+   compatible = "arm,psci-1.0";
+   method = "smc";
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <_l0>;
+   };
+   core1 {
+   cpu = <_l1>;
+   };
+   core2 {
+   cpu = <_l2>;
+   };
+   core3 {
+   cpu = <_l3>;
+   };
+   };
+
+   cluster1 {
+   core0 {
+   cpu = <_b0>;
+   };
+   core1 {
+   cpu = <_b1>;
+   };
+   };
+   };
+
+   cpu_l0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   #cooling-cells = <2>; /* min followed by max */
+   clocks = < ARMCLKL>;
+   };
+

[PATCH v2 2/4] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs

[Jianqun Xu]

This patch adds core dtsi file for Rockchip RK3399 SoCs.

The RK3399 has big/little architecture, which needs a separate
node for the PMU of each microarchitecture, for now it missing
the pmu node since the old one could not work well.

Marc is working on it with:
https://lkml.org/lkml/2016/4/11/182

and on the following branch:
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git
irq/percpu-partition

That will to be tested on RK3399 evb.

Signed-off-by: Jianqun Xu 
---
changes in v2:
- remove arm-pmu at first. (Marc, Heiko, Mark)
- remove rga, emmc, usb3, mipi, edp, pd, i2c, gpu, thermal, tsadc, saradc, 
which will upstream independently

 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1022 ++
 1 file changed, 1022 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
new file mode 100644
index 000..5a8a915
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -0,0 +1,1022 @@
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library 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.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "rockchip,rk3399";
+
+   interrupt-parent = <>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   aliases {
+   serial0 = 
+   serial1 = 
+   serial2 = 
+   serial3 = 
+   serial4 = 
+   };
+
+   psci {
+   compatible = "arm,psci-1.0";
+   method = "smc";
+   };
+
+   cpus {
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   cpu-map {
+   cluster0 {
+   core0 {
+   cpu = <_l0>;
+   };
+   core1 {
+   cpu = <_l1>;
+   };
+   core2 {
+   cpu = <_l2>;
+   };
+   core3 {
+   cpu = <_l3>;
+   };
+   };
+
+   cluster1 {
+   core0 {
+   cpu = <_b0>;
+   };
+   core1 {
+   cpu = <_b1>;
+   };
+   };
+   };
+
+   cpu_l0: cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a53", "arm,armv8";
+   reg = <0x0 0x0>;
+   enable-method = "psci";
+   #cooling-cells = <2>; /* min followed by max */
+   clocks = < ARMCLKL>;
+   };
+
+   

Re: [PATCH v2] Force cppc_cpufreq to report values in KHz to fix user space reporting

[Viresh Kumar]

On 19-04-16, 16:12, Ashwin Chaugule wrote:
> + Ryan
> 
> Hi Al,
> 
> On 18 April 2016 at 20:11, Al Stone  wrote:
> > When CPPC is being used by ACPI on arm64, user space tools such as
> > cpupower report CPU frequency values from sysfs that are incorrect.
> >
> > What the driver was doing was reporting the values given by ACPI tables
> > in whatever scale was used to provide them.  However, the ACPI spec
> > defines the CPPC values as unitless abstract numbers.  Internal kernel
> > structures such as struct perf_cap, in contrast, expect these values
> > to be in KHz.  When these struct values get reported via sysfs, the
> > user space tools also assume they are in KHz, causing them to report
> > incorrect values (for example, reporting a CPU frequency of 1MHz when
> > it should be 1.8GHz).
> >
> > While the investigation for a long term fix proceeds (several options
> > are being explored, some of which may require spec changes or other
> > much more invasive fixes), this patch forces the values read by CPPC
> > to be read in KHz, regardless of what they actually represent.
> >
> > The downside is that this approach has some assumptions:
> >
> >(1) It relies on SMBIOS3 being used, *and* that the Max Frequency
> >value for a processor is set to a non-zero value.
> >
> >(2) It assumes that all processors run at the same speed.  This
> >patch retrieves the first CPU Max Frequency from a type 4 DMI
> >record that it can find.  This may not be an issue, however, as a
> >sampling of DMI data on x86 and arm64 indicates there is often only
> >one such record regardless.

Don't we have any big LITTLE ARM servers yet ? Or we will not have them at all ?

> > For arm64 servers, this may be sufficient, but it does rely on
> > firmware values being set correctly.  Hence, other approaches are
> > also being considered.
> >
> > This has been tested on three arm64 servers, with and without DMI, with
> > and without CPPC support.
> >
> > Changes for v2:
> > -- Corrected thinko: needed to have DEPENDS on DMI in Kconfig.arm,
> >not SELECT DMI (found by build daemon)
> >
> > Signed-off-by: Al Stone 
> 
> This looks like a good short term solution. Does it make more sense to
> move this to the cppc_cpufreq driver though? Since that ties more
> closely into the cpufreq framework which requires the kHz values in
> sysfs. That way we can keep the cppc_acpi.c shim compliant with the
> ACPI spec. (i.e. values read in cppc structures remain abstract and
> unitless).
> 
> Rafael, Viresh, others,
> 
> Any other ideas how to handle this better in the long term?
> 
>  - Decouple the cpufreq sysfs from the cppc driver and introduce its
> own entries. Is it possibly to do this cleanly while still allowing
> usage of cpufreq registration with existing governors?
> 
>  - Come up with a scaling factor using the PMU cycle counter at boot
> before the CPPC drivers are initialized. This would use the current
> freq set by some UEFI var. This would possibly require some messy
> perfevents plumbing and added bootup time though.

I may be missing the obvious, but can't we just create the cpufreq-table from
this table in khz? We wouldn't require any further change then.

-- 
viresh

Re: [PATCH v2] Force cppc_cpufreq to report values in KHz to fix user space reporting

[Viresh Kumar]

On 19-04-16, 16:12, Ashwin Chaugule wrote:
> + Ryan
> 
> Hi Al,
> 
> On 18 April 2016 at 20:11, Al Stone  wrote:
> > When CPPC is being used by ACPI on arm64, user space tools such as
> > cpupower report CPU frequency values from sysfs that are incorrect.
> >
> > What the driver was doing was reporting the values given by ACPI tables
> > in whatever scale was used to provide them.  However, the ACPI spec
> > defines the CPPC values as unitless abstract numbers.  Internal kernel
> > structures such as struct perf_cap, in contrast, expect these values
> > to be in KHz.  When these struct values get reported via sysfs, the
> > user space tools also assume they are in KHz, causing them to report
> > incorrect values (for example, reporting a CPU frequency of 1MHz when
> > it should be 1.8GHz).
> >
> > While the investigation for a long term fix proceeds (several options
> > are being explored, some of which may require spec changes or other
> > much more invasive fixes), this patch forces the values read by CPPC
> > to be read in KHz, regardless of what they actually represent.
> >
> > The downside is that this approach has some assumptions:
> >
> >(1) It relies on SMBIOS3 being used, *and* that the Max Frequency
> >value for a processor is set to a non-zero value.
> >
> >(2) It assumes that all processors run at the same speed.  This
> >patch retrieves the first CPU Max Frequency from a type 4 DMI
> >record that it can find.  This may not be an issue, however, as a
> >sampling of DMI data on x86 and arm64 indicates there is often only
> >one such record regardless.

Don't we have any big LITTLE ARM servers yet ? Or we will not have them at all ?

> > For arm64 servers, this may be sufficient, but it does rely on
> > firmware values being set correctly.  Hence, other approaches are
> > also being considered.
> >
> > This has been tested on three arm64 servers, with and without DMI, with
> > and without CPPC support.
> >
> > Changes for v2:
> > -- Corrected thinko: needed to have DEPENDS on DMI in Kconfig.arm,
> >not SELECT DMI (found by build daemon)
> >
> > Signed-off-by: Al Stone 
> 
> This looks like a good short term solution. Does it make more sense to
> move this to the cppc_cpufreq driver though? Since that ties more
> closely into the cpufreq framework which requires the kHz values in
> sysfs. That way we can keep the cppc_acpi.c shim compliant with the
> ACPI spec. (i.e. values read in cppc structures remain abstract and
> unitless).
> 
> Rafael, Viresh, others,
> 
> Any other ideas how to handle this better in the long term?
> 
>  - Decouple the cpufreq sysfs from the cppc driver and introduce its
> own entries. Is it possibly to do this cleanly while still allowing
> usage of cpufreq registration with existing governors?
> 
>  - Come up with a scaling factor using the PMU cycle counter at boot
> before the CPPC drivers are initialized. This would use the current
> freq set by some UEFI var. This would possibly require some messy
> perfevents plumbing and added bootup time though.

I may be missing the obvious, but can't we just create the cpufreq-table from
this table in khz? We wouldn't require any further change then.

-- 
viresh

Re: [PATCH] drm/exynos/hdmi: Don't print error on deferral due to regulators

[Krzysztof Kozlowski]

On 04/21/2016 08:51 PM, Javier Martinez Canillas wrote:
> The regulators may not be available just because their driver's probe
> function was just not executed and so the regulators not registered.
> 
> So, in this case the Exynos HDMI driver should not print logs since
> a -EPROBE_DEFER is not really an error and that will just pollute
> the kernel log and confuse users.
> 
> This patch prevents the following misleading messages to be printed:
> 
> [1.443638] [drm:hdmi_probe] *ERROR* failed to get regulators
> [1.449326] [drm:hdmi_probe] *ERROR* hdmi_resources_init failed
> 
> Reported-by: Krzysztof Kozlowski 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
> The real fix for these kind of issues is to change the device model
> core to support device dependencies so the number of probe deferral
> should be minimal or non-existent, instead of fixing on each driver.
> 
> But there have been different attempts [0,1] to implement this and
> there doesn't seem that this will be solved in the short term.
> 
> [0]: https://lkml.org/lkml/2014/5/12/452
> [1]: https://lkml.org/lkml/2015/5/25/251
> 
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Since I like to look at 'dmesg -l err' then I find this useful:

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH] drm/exynos/hdmi: Don't print error on deferral due to regulators

[Krzysztof Kozlowski]

On 04/21/2016 08:51 PM, Javier Martinez Canillas wrote:
> The regulators may not be available just because their driver's probe
> function was just not executed and so the regulators not registered.
> 
> So, in this case the Exynos HDMI driver should not print logs since
> a -EPROBE_DEFER is not really an error and that will just pollute
> the kernel log and confuse users.
> 
> This patch prevents the following misleading messages to be printed:
> 
> [1.443638] [drm:hdmi_probe] *ERROR* failed to get regulators
> [1.449326] [drm:hdmi_probe] *ERROR* hdmi_resources_init failed
> 
> Reported-by: Krzysztof Kozlowski 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
> The real fix for these kind of issues is to change the device model
> core to support device dependencies so the number of probe deferral
> should be minimal or non-existent, instead of fixing on each driver.
> 
> But there have been different attempts [0,1] to implement this and
> there doesn't seem that this will be solved in the short term.
> 
> [0]: https://lkml.org/lkml/2014/5/12/452
> [1]: https://lkml.org/lkml/2015/5/25/251
> 
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)

Since I like to look at 'dmesg -l err' then I find this useful:

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

[PATCH v2 1/4] Documentation: rockchip-dw-mshc: add description for rk3399

[Jianqun Xu]

From: Shawn Lin 

Add "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc" for
dwmmc on rk3399 platform.

Change-Id: Ieefafab5f0e9650271e823659e2bec1556c4a9bc
Signed-off-by: Shawn Lin 
---
 Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
index ea5614b..07184e8 100644
--- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
@@ -15,6 +15,7 @@ Required Properties:
- "rockchip,rk3288-dw-mshc": for Rockchip RK3288
- "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3036
- "rockchip,rk3368-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3368
+   - "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3399
 
 Optional Properties:
 * clocks: from common clock binding: if ciu_drive and ciu_sample are
-- 
1.9.1

[PATCH v2 1/4] Documentation: rockchip-dw-mshc: add description for rk3399

[Jianqun Xu]

From: Shawn Lin 

Add "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc" for
dwmmc on rk3399 platform.

Change-Id: Ieefafab5f0e9650271e823659e2bec1556c4a9bc
Signed-off-by: Shawn Lin 
---
 Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
index ea5614b..07184e8 100644
--- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
@@ -15,6 +15,7 @@ Required Properties:
- "rockchip,rk3288-dw-mshc": for Rockchip RK3288
- "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3036
- "rockchip,rk3368-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3368
+   - "rockchip,rk3399-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip 
RK3399
 
 Optional Properties:
 * clocks: from common clock binding: if ciu_drive and ciu_sample are
-- 
1.9.1

[PATCH v2 0/4] ARM64: dts: rockchip: add support for RK3399

[Jianqun Xu]

Add dtsi file for RK3399 SoCs, and evb dts file for RK3399 evb.

To make patch more easily to be reviewed, some nodes have been removed
temporarily, after this base file been applied, more patches will be
upstreamed independently.

Jianqun Xu (3):
  ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs
  ARM64: dts: rockchip: add RK3399 evaluation board
  ARM64: dts: rockchip: add dts file for RK3399 evaluation board

Shawn Lin (1):
  Documentation: rockchip-dw-mshc: add description for rk3399

 Documentation/devicetree/bindings/arm/rockchip.txt |6 +-
 .../devicetree/bindings/mmc/rockchip-dw-mshc.txt   |1 +
 arch/arm64/boot/dts/rockchip/Makefile  |1 +
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts|  122 +++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   | 1022 
 5 files changed, 1151 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

--
changes in v2:
- split into more patches. (Heiko)
- remove arm-pmu at first. (Marc, Heiko, Mark)
- remove rga, emmc, usb3, mipi, edp, pd, i2c, gpu, thermal, tsadc, saradc, 
which will upstream independently
- remove rk808 since without i2c, which will upstream independently
- remove es8316 since without i2c, which will upstream independently
- add rockchip-dw-mshc binding patch
- add rockchip,rk3399-evb binding patch
- fix codingstyle issues

1.9.1

[PATCH v2 0/4] ARM64: dts: rockchip: add support for RK3399

[Jianqun Xu]

Add dtsi file for RK3399 SoCs, and evb dts file for RK3399 evb.

To make patch more easily to be reviewed, some nodes have been removed
temporarily, after this base file been applied, more patches will be
upstreamed independently.

Jianqun Xu (3):
  ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs
  ARM64: dts: rockchip: add RK3399 evaluation board
  ARM64: dts: rockchip: add dts file for RK3399 evaluation board

Shawn Lin (1):
  Documentation: rockchip-dw-mshc: add description for rk3399

 Documentation/devicetree/bindings/arm/rockchip.txt |6 +-
 .../devicetree/bindings/mmc/rockchip-dw-mshc.txt   |1 +
 arch/arm64/boot/dts/rockchip/Makefile  |1 +
 arch/arm64/boot/dts/rockchip/rk3399-evb.dts|  122 +++
 arch/arm64/boot/dts/rockchip/rk3399.dtsi   | 1022 
 5 files changed, 1151 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399-evb.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3399.dtsi

--
changes in v2:
- split into more patches. (Heiko)
- remove arm-pmu at first. (Marc, Heiko, Mark)
- remove rga, emmc, usb3, mipi, edp, pd, i2c, gpu, thermal, tsadc, saradc, 
which will upstream independently
- remove rk808 since without i2c, which will upstream independently
- remove es8316 since without i2c, which will upstream independently
- add rockchip-dw-mshc binding patch
- add rockchip,rk3399-evb binding patch
- fix codingstyle issues

1.9.1

linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/net/ethernet/qlogic/qede/qede_main.c: In function 'qede_fill_frag_skb':
drivers/net/ethernet/qlogic/qede/qede_main.c:961:31: error: 'struct page' has 
no member named '_count'
   atomic_inc(_bd->data->_count);
   ^
drivers/net/ethernet/qlogic/qede/qede_main.c: In function 'qede_rx_int':
drivers/net/ethernet/qlogic/qede/qede_main.c:1412:33: error: 'struct page' has 
no member named '_count'
 atomic_inc(_rx_data->data->_count);
 ^  
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function 
'mlx5e_alloc_rx_fragmented_mpwqe': 
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:297:32: error: 'struct page' 
has no member named '_count'
   >umr.dma_info[i].page->_count);
^   
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:316:32: error: 'struct page' 
has no member named '_count'
   >umr.dma_info[i].page->_count);
^   
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function 
'mlx5e_free_rx_fragmented_mpwqe':  
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:341:32: error: 'struct page' 
has no member named '_count'
   >umr.dma_info[i].page->_count);
^   
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function 
'mlx5e_alloc_rx_linear_mpwqe':
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:391:28: error: 'struct page' 
has no member named '_count'
   >dma_info.page[i]._count);
^
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function 
'mlx5e_free_rx_linear_mpwqe':
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:415:28: error: 'struct page' 
has no member named '_count'
   >dma_info.page[i]._count);
^

Caused by commit

  2dde4bc2820e ("mm: rename _count, field of the struct page, to _refcount")

interacting with commits

  f86af2dfded6 ("qede: Fix various memory allocation error flows for fastpath")

from Linus' tree and

  bc77b240b3c5 ("net/mlx5e: Add fragmented memory support for RX multi packet 
WQE")

from the net-next tree.

I applied the following patch:

From: Stephen Rothwell 
Date: Fri, 22 Apr 2016 15:13:21 +1000
Subject: [PATCH] mm-rename-_count-field-of-the-struct-page-to-_refcount-fix6

Signed-off-by: Stephen Rothwell 
---
 drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 20 ++--
 drivers/net/ethernet/qlogic/qede/qede_main.c|  4 ++--
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index 918b7c7fd74f..0543fbc130b6 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@ -293,8 +293,8 @@ static int mlx5e_alloc_rx_fragmented_mpwqe(struct mlx5e_rq 
*rq,
for (i = 0; i < MLX5_MPWRQ_PAGES_PER_WQE; i++) {
if (unlikely(mlx5e_alloc_and_map_page(rq, wi, i)))
goto err_unmap;
-   atomic_add(MLX5_MPWRQ_STRIDES_PER_PAGE,
-  >umr.dma_info[i].page->_count);
+   page_ref_add(wi->umr.dma_info[i].page,
+MLX5_MPWRQ_STRIDES_PER_PAGE);
wi->skbs_frags[i] = 0;
}
 
@@ -312,8 +312,8 @@ err_unmap:
while (--i >= 0) {
dma_unmap_page(rq->pdev, wi->umr.dma_info[i].addr, PAGE_SIZE,
   PCI_DMA_FROMDEVICE);
-   atomic_sub(MLX5_MPWRQ_STRIDES_PER_PAGE,
-  >umr.dma_info[i].page->_count);
+   page_ref_sub(wi->umr.dma_info[i].page,
+MLX5_MPWRQ_STRIDES_PER_PAGE);
put_page(wi->umr.dma_info[i].page);
}
dma_unmap_single(rq->pdev, wi->umr.mtt_addr, mtt_sz, PCI_DMA_TODEVICE);
@@ -337,8 +337,8 @@ void mlx5e_free_rx_fragmented_mpwqe(struct mlx5e_rq *rq,
for (i = 0; i < MLX5_MPWRQ_PAGES_PER_WQE; i++) {
dma_unmap_page(rq->pdev, wi->umr.dma_info[i].addr, PAGE_SIZE,
   PCI_DMA_FROMDEVICE);
-   atomic_sub(MLX5_MPWRQ_STRIDES_PER_PAGE - wi->skbs_frags[i],
-  >umr.dma_info[i].page->_count);
+   page_ref_sub(wi->umr.dma_info[i].page,
+MLX5_MPWRQ_STRIDES_PER_PAGE - wi->skbs_frags[i]);
put_page(wi->umr.dma_info[i].page);
}
dma_unmap_single(rq->pdev, wi->umr.mtt_addr, mtt_sz, PCI_DMA_TODEVICE);
@@ -387,8 +387,8 @@ static int mlx5e_alloc_rx_linear_mpwqe(struct mlx5e_rq *rq,
 */
split_page(wi->dma_info.page, MLX5_MPWRQ_WQE_PAGE_ORDER);
for (i = 0; i < MLX5_MPWRQ_PAGES_PER_WQE; i++) {
-   atomic_add(MLX5_MPWRQ_STRIDES_PER_PAGE,
-  

linux-next: build failure after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/net/ethernet/qlogic/qede/qede_main.c: In function 'qede_fill_frag_skb':
drivers/net/ethernet/qlogic/qede/qede_main.c:961:31: error: 'struct page' has 
no member named '_count'
   atomic_inc(_bd->data->_count);
   ^
drivers/net/ethernet/qlogic/qede/qede_main.c: In function 'qede_rx_int':
drivers/net/ethernet/qlogic/qede/qede_main.c:1412:33: error: 'struct page' has 
no member named '_count'
 atomic_inc(_rx_data->data->_count);
 ^  
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function 
'mlx5e_alloc_rx_fragmented_mpwqe': 
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:297:32: error: 'struct page' 
has no member named '_count'
   >umr.dma_info[i].page->_count);
^   
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:316:32: error: 'struct page' 
has no member named '_count'
   >umr.dma_info[i].page->_count);
^   
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function 
'mlx5e_free_rx_fragmented_mpwqe':  
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:341:32: error: 'struct page' 
has no member named '_count'
   >umr.dma_info[i].page->_count);
^   
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function 
'mlx5e_alloc_rx_linear_mpwqe':
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:391:28: error: 'struct page' 
has no member named '_count'
   >dma_info.page[i]._count);
^
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c: In function 
'mlx5e_free_rx_linear_mpwqe':
drivers/net/ethernet/mellanox/mlx5/core/en_rx.c:415:28: error: 'struct page' 
has no member named '_count'
   >dma_info.page[i]._count);
^

Caused by commit

  2dde4bc2820e ("mm: rename _count, field of the struct page, to _refcount")

interacting with commits

  f86af2dfded6 ("qede: Fix various memory allocation error flows for fastpath")

from Linus' tree and

  bc77b240b3c5 ("net/mlx5e: Add fragmented memory support for RX multi packet 
WQE")

from the net-next tree.

I applied the following patch:

From: Stephen Rothwell 
Date: Fri, 22 Apr 2016 15:13:21 +1000
Subject: [PATCH] mm-rename-_count-field-of-the-struct-page-to-_refcount-fix6

Signed-off-by: Stephen Rothwell 
---
 drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 20 ++--
 drivers/net/ethernet/qlogic/qede/qede_main.c|  4 ++--
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index 918b7c7fd74f..0543fbc130b6 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@ -293,8 +293,8 @@ static int mlx5e_alloc_rx_fragmented_mpwqe(struct mlx5e_rq 
*rq,
for (i = 0; i < MLX5_MPWRQ_PAGES_PER_WQE; i++) {
if (unlikely(mlx5e_alloc_and_map_page(rq, wi, i)))
goto err_unmap;
-   atomic_add(MLX5_MPWRQ_STRIDES_PER_PAGE,
-  >umr.dma_info[i].page->_count);
+   page_ref_add(wi->umr.dma_info[i].page,
+MLX5_MPWRQ_STRIDES_PER_PAGE);
wi->skbs_frags[i] = 0;
}
 
@@ -312,8 +312,8 @@ err_unmap:
while (--i >= 0) {
dma_unmap_page(rq->pdev, wi->umr.dma_info[i].addr, PAGE_SIZE,
   PCI_DMA_FROMDEVICE);
-   atomic_sub(MLX5_MPWRQ_STRIDES_PER_PAGE,
-  >umr.dma_info[i].page->_count);
+   page_ref_sub(wi->umr.dma_info[i].page,
+MLX5_MPWRQ_STRIDES_PER_PAGE);
put_page(wi->umr.dma_info[i].page);
}
dma_unmap_single(rq->pdev, wi->umr.mtt_addr, mtt_sz, PCI_DMA_TODEVICE);
@@ -337,8 +337,8 @@ void mlx5e_free_rx_fragmented_mpwqe(struct mlx5e_rq *rq,
for (i = 0; i < MLX5_MPWRQ_PAGES_PER_WQE; i++) {
dma_unmap_page(rq->pdev, wi->umr.dma_info[i].addr, PAGE_SIZE,
   PCI_DMA_FROMDEVICE);
-   atomic_sub(MLX5_MPWRQ_STRIDES_PER_PAGE - wi->skbs_frags[i],
-  >umr.dma_info[i].page->_count);
+   page_ref_sub(wi->umr.dma_info[i].page,
+MLX5_MPWRQ_STRIDES_PER_PAGE - wi->skbs_frags[i]);
put_page(wi->umr.dma_info[i].page);
}
dma_unmap_single(rq->pdev, wi->umr.mtt_addr, mtt_sz, PCI_DMA_TODEVICE);
@@ -387,8 +387,8 @@ static int mlx5e_alloc_rx_linear_mpwqe(struct mlx5e_rq *rq,
 */
split_page(wi->dma_info.page, MLX5_MPWRQ_WQE_PAGE_ORDER);
for (i = 0; i < MLX5_MPWRQ_PAGES_PER_WQE; i++) {
-   atomic_add(MLX5_MPWRQ_STRIDES_PER_PAGE,
-  >dma_info.page[i]._count);
+   

Re: [RFC][PATCH 0/6] /dev/random - a new approach

[Stephan Mueller]

Am Donnerstag, 21. April 2016, 22:51:55 schrieb Theodore Ts'o:

Hi Theodore,

> I still have a massive problem with the claims that the "Jitter" RNG
> provides any amount of entropy.  Just because you and I might not be
> able to analyze it doesn't mean that somebody else couldn't.  After
> all, DUAL-EC DRNG was very complicated and hard to analyze.  So would
> be something like
> 
>AES(NSA_KEY, COUNTER++)
> 
> Very hard to analyze indeed.  Shall we run statistical tests?  They'll
> pass with flying colors.
> 
> Secure?  Not so much.

If you are concerned with that RNG, we can easily drop it from the LRNG. The 
testing documented in the writeup disable the Jitter RNG to ensure that only 
the LRNG IRQ collection is tested.

The conclusions regarding timeliness of the seeding, the prevention of 
draining the entropy pool are performed without the Jitter RNG which implies 
that the Jitter RNG can be dropped without harm.

Ciao
Stephan

Re: [RFC][PATCH 0/6] /dev/random - a new approach

[Stephan Mueller]

Am Donnerstag, 21. April 2016, 22:51:55 schrieb Theodore Ts'o:

Hi Theodore,

> I still have a massive problem with the claims that the "Jitter" RNG
> provides any amount of entropy.  Just because you and I might not be
> able to analyze it doesn't mean that somebody else couldn't.  After
> all, DUAL-EC DRNG was very complicated and hard to analyze.  So would
> be something like
> 
>AES(NSA_KEY, COUNTER++)
> 
> Very hard to analyze indeed.  Shall we run statistical tests?  They'll
> pass with flying colors.
> 
> Secure?  Not so much.

If you are concerned with that RNG, we can easily drop it from the LRNG. The 
testing documented in the writeup disable the Jitter RNG to ensure that only 
the LRNG IRQ collection is tested.

The conclusions regarding timeliness of the seeding, the prevention of 
draining the entropy pool are performed without the Jitter RNG which implies 
that the Jitter RNG can be dropped without harm.

Ciao
Stephan

Re: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch

[Han Xu]

From: Yunhui Cui
Sent: Thursday, April 21, 2016 9:52 PM
To: Han Xu; Yunhui Cui; dw...@infradead.org; computersforpe...@gmail.com; 
han...@freescale.com
Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; 
linux-arm-ker...@lists.infradead.org; Yao Yuan
Subject: RE: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch

> -Original Message-
> From: Han Xu
> Sent: Thursday, April 21, 2016 11:48 PM
> To: Yunhui Cui; Yunhui Cui; dw...@infradead.org;
> computersforpe...@gmail.com; han...@freescale.com
> Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; linux-
> arm-ker...@lists.infradead.org; Yao Yuan
> Subject: Re: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
>
>
>
> 
> From: Yunhui Cui
> Sent: Thursday, April 21, 2016 3:41 AM
> To: Han Xu; Yunhui Cui; dw...@infradead.org; computersforpe...@gmail.com;
> han...@freescale.com
> Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; linux-
> arm-ker...@lists.infradead.org; Yao Yuan
> Subject: RE: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
>
> On Thu, Apr 24, 2016 at 06:37:01 AM +0800, Han Xu wrote:
> > 
> > From: Yunhui Cui 
> > Sent: Wednesday, April 13, 2016 9:50 PM
> > To: dw...@infradead.org; computersforpe...@gmail.com;
> > han...@freescale.com
> > Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org;
> > linux- arm-ker...@lists.infradead.org; Yao Yuan; Yunhui Cui
> > Subject: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
> >
> > From: Yunhui Cui 
> >
> > A-009282: QuadSPI: QuadSPI data pre-fetch can result in incorrect data
> > Affects: QuadSPI
> > Description: With AHB buffer prefetch enabled, the QuadSPI may return
> > incorrect data on the AHB interface. The buffer pre-fetch is enabled
> > if the fetch size as configured either in the LUT or in the BUFxCR
> > register is greater than 8 bytes.
> > Impact: Only 64 bit read allowed.
> > Workaround: Keep the read data size to 64 bits (8 Bytes), which
> > disables the prefetch on the AHB buffer, and prevents this issue from
> occurring.
> >
> > Signed-off-by: Yunhui Cui 
> > ---
> >  drivers/mtd/spi-nor/fsl-quadspi.c | 29 +++--
> >  1 file changed, 23 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
> > b/drivers/mtd/spi-nor/fsl- quadspi.c index fea18b6..d9f3e50 100644
> > --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> > +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> > @@ -752,19 +752,36 @@ static void fsl_qspi_init_abh_read(struct
> > fsl_qspi
> > *q)  {
> > void __iomem *base = q->iobase;
> > int seqid;
> > +   const struct fsl_qspi_devtype_data *devtype_data =
> > + q->devtype_data;
> >
> > /* AHB configuration for access buffer 0/1/2 .*/
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF0CR);
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF1CR);
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF2CR);
> > +
> > /*
> > -* Set ADATSZ with the maximum AHB buffer size to improve the
> > -* read performance.
> > +* Errata: A-009282: QuadSPI data prefetch may result in
> > incorrect data
> > +* Workaround: Keep the read data size to 64 bits (8 bytes).
> > +* This disables the prefetch on the AHB buffer and
> > +* prevents this issue from occurring.
> >  */
> > -   qspi_writel(q, QUADSPI_BUF3CR_ALLMST_MASK |
> > -   ((q->devtype_data->ahb_buf_size / 8)
> > -   << QUADSPI_BUF3CR_ADATSZ_SHIFT),
> > -   base + QUADSPI_BUF3CR);
> > +   if (devtype_data->devtype == FSL_QUADSPI_LS2080A ||
> > +   devtype_data->devtype == FSL_QUADSPI_LS1021A) {
> >
> > Use QUIRK, not SoC name.
> [Yunhui] This is a SoC errata, we need distinguish according to the
> devtype_data->devtype
>
> It's the same thing and we have already done that before.

> [Yunhui] your mean that I should add such as the following code:
#define QUADSPI_QUIRK_ERRATA_9282 (1 << 4)
static inline int has_errata_num_a009282(struct fsl_qspi *q)
{
 return q->devtype_data->driver_data & 
QUADSPI_QUIRK_ERRATA_9282;
}

I mean QUIRK can be used even for HW limitation, but it's not necessary to
use ERRATA number as QUIRK name, you can name it with natural language,
such as QUADSPI_QUIRK_ADASZ_8BYTE_LIMIT, and describe the reason in
comments.

> /*
>  * TKT253890, Controller needs driver to fill txfifo till 16 byte to
>  * trigger data transfer even though extra data will not transferred.
>  */
> #define QUADSPI_QUIRK_TKT253890 (1 << 2)
> /* Controller cannot wake up from wait mode, TKT245618 */
> #define 

Re: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch

[Han Xu]

From: Yunhui Cui
Sent: Thursday, April 21, 2016 9:52 PM
To: Han Xu; Yunhui Cui; dw...@infradead.org; computersforpe...@gmail.com; 
han...@freescale.com
Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; 
linux-arm-ker...@lists.infradead.org; Yao Yuan
Subject: RE: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch

> -Original Message-
> From: Han Xu
> Sent: Thursday, April 21, 2016 11:48 PM
> To: Yunhui Cui; Yunhui Cui; dw...@infradead.org;
> computersforpe...@gmail.com; han...@freescale.com
> Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; linux-
> arm-ker...@lists.infradead.org; Yao Yuan
> Subject: Re: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
>
>
>
> 
> From: Yunhui Cui
> Sent: Thursday, April 21, 2016 3:41 AM
> To: Han Xu; Yunhui Cui; dw...@infradead.org; computersforpe...@gmail.com;
> han...@freescale.com
> Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; linux-
> arm-ker...@lists.infradead.org; Yao Yuan
> Subject: RE: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
>
> On Thu, Apr 24, 2016 at 06:37:01 AM +0800, Han Xu wrote:
> > 
> > From: Yunhui Cui 
> > Sent: Wednesday, April 13, 2016 9:50 PM
> > To: dw...@infradead.org; computersforpe...@gmail.com;
> > han...@freescale.com
> > Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org;
> > linux- arm-ker...@lists.infradead.org; Yao Yuan; Yunhui Cui
> > Subject: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
> >
> > From: Yunhui Cui 
> >
> > A-009282: QuadSPI: QuadSPI data pre-fetch can result in incorrect data
> > Affects: QuadSPI
> > Description: With AHB buffer prefetch enabled, the QuadSPI may return
> > incorrect data on the AHB interface. The buffer pre-fetch is enabled
> > if the fetch size as configured either in the LUT or in the BUFxCR
> > register is greater than 8 bytes.
> > Impact: Only 64 bit read allowed.
> > Workaround: Keep the read data size to 64 bits (8 Bytes), which
> > disables the prefetch on the AHB buffer, and prevents this issue from
> occurring.
> >
> > Signed-off-by: Yunhui Cui 
> > ---
> >  drivers/mtd/spi-nor/fsl-quadspi.c | 29 +++--
> >  1 file changed, 23 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
> > b/drivers/mtd/spi-nor/fsl- quadspi.c index fea18b6..d9f3e50 100644
> > --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> > +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> > @@ -752,19 +752,36 @@ static void fsl_qspi_init_abh_read(struct
> > fsl_qspi
> > *q)  {
> > void __iomem *base = q->iobase;
> > int seqid;
> > +   const struct fsl_qspi_devtype_data *devtype_data =
> > + q->devtype_data;
> >
> > /* AHB configuration for access buffer 0/1/2 .*/
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF0CR);
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF1CR);
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF2CR);
> > +
> > /*
> > -* Set ADATSZ with the maximum AHB buffer size to improve the
> > -* read performance.
> > +* Errata: A-009282: QuadSPI data prefetch may result in
> > incorrect data
> > +* Workaround: Keep the read data size to 64 bits (8 bytes).
> > +* This disables the prefetch on the AHB buffer and
> > +* prevents this issue from occurring.
> >  */
> > -   qspi_writel(q, QUADSPI_BUF3CR_ALLMST_MASK |
> > -   ((q->devtype_data->ahb_buf_size / 8)
> > -   << QUADSPI_BUF3CR_ADATSZ_SHIFT),
> > -   base + QUADSPI_BUF3CR);
> > +   if (devtype_data->devtype == FSL_QUADSPI_LS2080A ||
> > +   devtype_data->devtype == FSL_QUADSPI_LS1021A) {
> >
> > Use QUIRK, not SoC name.
> [Yunhui] This is a SoC errata, we need distinguish according to the
> devtype_data->devtype
>
> It's the same thing and we have already done that before.

> [Yunhui] your mean that I should add such as the following code:
#define QUADSPI_QUIRK_ERRATA_9282 (1 << 4)
static inline int has_errata_num_a009282(struct fsl_qspi *q)
{
 return q->devtype_data->driver_data & 
QUADSPI_QUIRK_ERRATA_9282;
}

I mean QUIRK can be used even for HW limitation, but it's not necessary to
use ERRATA number as QUIRK name, you can name it with natural language,
such as QUADSPI_QUIRK_ADASZ_8BYTE_LIMIT, and describe the reason in
comments.

> /*
>  * TKT253890, Controller needs driver to fill txfifo till 16 byte to
>  * trigger data transfer even though extra data will not transferred.
>  */
> #define QUADSPI_QUIRK_TKT253890 (1 << 2)
> /* Controller cannot wake up from wait mode, TKT245618 */
> #define QUADSPI_QUIRK_TKT245618 (1 << 3)
>
>
> > +
> > +   

Re: [PATCH V3 29/29] ethernet: use parity8 in broadcom/tg3.c

[Siva Reddy Kallam]

On Thu, Apr 14, 2016 at 8:42 AM,  wrote:
>
> From: Zhaoxiu Zeng 
>
> Signed-off-by: Zhaoxiu Zeng 
Looks good to me.
Acked-by: Siva Reddy Kallam 
> ---
>  drivers/net/ethernet/broadcom/tg3.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c 
> b/drivers/net/ethernet/broadcom/tg3.c
> index 3010080..802a429 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -12939,11 +12939,7 @@ static int tg3_test_nvram(struct tg3 *tp)
>
> err = -EIO;
> for (i = 0; i < NVRAM_SELFBOOT_DATA_SIZE; i++) {
> -   u8 hw8 = hweight8(data[i]);
> -
> -   if ((hw8 & 0x1) && parity[i])
> -   goto out;
> -   else if (!(hw8 & 0x1) && !parity[i])
> +   if (parity8(data[i]) == !!parity[i])
> goto out;
> }
> err = 0;
> --
> 2.5.0
>
>

Re: [PATCH V3 29/29] ethernet: use parity8 in broadcom/tg3.c

[Siva Reddy Kallam]

On Thu, Apr 14, 2016 at 8:42 AM,  wrote:
>
> From: Zhaoxiu Zeng 
>
> Signed-off-by: Zhaoxiu Zeng 
Looks good to me.
Acked-by: Siva Reddy Kallam 
> ---
>  drivers/net/ethernet/broadcom/tg3.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/tg3.c 
> b/drivers/net/ethernet/broadcom/tg3.c
> index 3010080..802a429 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -12939,11 +12939,7 @@ static int tg3_test_nvram(struct tg3 *tp)
>
> err = -EIO;
> for (i = 0; i < NVRAM_SELFBOOT_DATA_SIZE; i++) {
> -   u8 hw8 = hweight8(data[i]);
> -
> -   if ((hw8 & 0x1) && parity[i])
> -   goto out;
> -   else if (!(hw8 & 0x1) && !parity[i])
> +   if (parity8(data[i]) == !!parity[i])
> goto out;
> }
> err = 0;
> --
> 2.5.0
>
>

Re: [PATCH] ARM: dts: omap3: Fix ISP syscon register offset

[Ivaylo Dimitrov]

On 16.04.2016 09:20, Ivaylo Dimitrov wrote:

According to the TRM, SCM CONTROL_CSIRXFE register is on offset 0x6c

Signed-off-by: Ivaylo Dimitrov 
---
  arch/arm/boot/dts/omap34xx.dtsi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 5cdba1f..e446562 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -46,7 +46,7 @@
   0x480bd800 0x017c>;
interrupts = <24>;
iommus = <_isp>;
-   syscon = <_conf 0xdc>;
+   syscon = <_conf 0x6c>;
ti,phy-type = ;
#clock-cells = <1>;
ports {



Anyone going to review that?

Re: [PATCH] ARM: dts: omap3: Fix ISP syscon register offset

[Ivaylo Dimitrov]

On 16.04.2016 09:20, Ivaylo Dimitrov wrote:

According to the TRM, SCM CONTROL_CSIRXFE register is on offset 0x6c

Signed-off-by: Ivaylo Dimitrov 
---
  arch/arm/boot/dts/omap34xx.dtsi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 5cdba1f..e446562 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -46,7 +46,7 @@
   0x480bd800 0x017c>;
interrupts = <24>;
iommus = <_isp>;
-   syscon = <_conf 0xdc>;
+   syscon = <_conf 0x6c>;
ti,phy-type = ;
#clock-cells = <1>;
ports {



Anyone going to review that?

[PATCH v7 8/8] arm64: dts: mediatek: Add Video Encoder for MT8173

[Tiffany Lin]

Add video encoder node for MT8173

Signed-off-by: Tiffany Lin 

---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   39 ++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index ae147bb..348ce0e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -717,6 +717,45 @@
clock-names = "apb", "smi";
};
 
+   vcodec_enc: vcodec@18002000 {
+   compatible = "mediatek,mt8173-vcodec-enc";
+   reg = <0 0x18002000 0 0x1000>,  /* VENC_SYS */
+ <0 0x19002000 0 0x1000>;  /* VENC_LT_SYS */
+   interrupts = ,
+;
+   mediatek,larb = <>,
+   <>;
+   iommus = < M4U_PORT_VENC_RCPU>,
+< M4U_PORT_VENC_REC>,
+< M4U_PORT_VENC_BSDMA>,
+< M4U_PORT_VENC_SV_COMV>,
+< M4U_PORT_VENC_RD_COMV>,
+< M4U_PORT_VENC_CUR_LUMA>,
+< M4U_PORT_VENC_CUR_CHROMA>,
+< M4U_PORT_VENC_REF_LUMA>,
+< M4U_PORT_VENC_REF_CHROMA>,
+< M4U_PORT_VENC_NBM_RDMA>,
+< M4U_PORT_VENC_NBM_WDMA>,
+< M4U_PORT_VENC_RCPU_SET2>,
+< M4U_PORT_VENC_REC_FRM_SET2>,
+< M4U_PORT_VENC_BSDMA_SET2>,
+< M4U_PORT_VENC_SV_COMA_SET2>,
+< M4U_PORT_VENC_RD_COMA_SET2>,
+< M4U_PORT_VENC_CUR_LUMA_SET2>,
+< M4U_PORT_VENC_CUR_CHROMA_SET2>,
+< M4U_PORT_VENC_REF_LUMA_SET2>,
+< M4U_PORT_VENC_REC_CHROMA_SET2>;
+   mediatek,vpu = <>;
+   clocks = < CLK_TOP_VENCPLL_D2>,
+< CLK_TOP_VENC_SEL>,
+< CLK_TOP_UNIVPLL1_D2>,
+< CLK_TOP_VENC_LT_SEL>;
+   clock-names = "venc_sel_src",
+ "venc_sel",
+ "venc_lt_sel_src",
+ "venc_lt_sel";
+   };
+
vencltsys: clock-controller@1900 {
compatible = "mediatek,mt8173-vencltsys", "syscon";
reg = <0 0x1900 0 0x1000>;
-- 
1.7.9.5

[PATCH v7 8/8] arm64: dts: mediatek: Add Video Encoder for MT8173

[Tiffany Lin]

Add video encoder node for MT8173

Signed-off-by: Tiffany Lin 

---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   39 ++
 1 file changed, 39 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index ae147bb..348ce0e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -717,6 +717,45 @@
clock-names = "apb", "smi";
};
 
+   vcodec_enc: vcodec@18002000 {
+   compatible = "mediatek,mt8173-vcodec-enc";
+   reg = <0 0x18002000 0 0x1000>,  /* VENC_SYS */
+ <0 0x19002000 0 0x1000>;  /* VENC_LT_SYS */
+   interrupts = ,
+;
+   mediatek,larb = <>,
+   <>;
+   iommus = < M4U_PORT_VENC_RCPU>,
+< M4U_PORT_VENC_REC>,
+< M4U_PORT_VENC_BSDMA>,
+< M4U_PORT_VENC_SV_COMV>,
+< M4U_PORT_VENC_RD_COMV>,
+< M4U_PORT_VENC_CUR_LUMA>,
+< M4U_PORT_VENC_CUR_CHROMA>,
+< M4U_PORT_VENC_REF_LUMA>,
+< M4U_PORT_VENC_REF_CHROMA>,
+< M4U_PORT_VENC_NBM_RDMA>,
+< M4U_PORT_VENC_NBM_WDMA>,
+< M4U_PORT_VENC_RCPU_SET2>,
+< M4U_PORT_VENC_REC_FRM_SET2>,
+< M4U_PORT_VENC_BSDMA_SET2>,
+< M4U_PORT_VENC_SV_COMA_SET2>,
+< M4U_PORT_VENC_RD_COMA_SET2>,
+< M4U_PORT_VENC_CUR_LUMA_SET2>,
+< M4U_PORT_VENC_CUR_CHROMA_SET2>,
+< M4U_PORT_VENC_REF_LUMA_SET2>,
+< M4U_PORT_VENC_REC_CHROMA_SET2>;
+   mediatek,vpu = <>;
+   clocks = < CLK_TOP_VENCPLL_D2>,
+< CLK_TOP_VENC_SEL>,
+< CLK_TOP_UNIVPLL1_D2>,
+< CLK_TOP_VENC_LT_SEL>;
+   clock-names = "venc_sel_src",
+ "venc_sel",
+ "venc_lt_sel_src",
+ "venc_lt_sel";
+   };
+
vencltsys: clock-controller@1900 {
compatible = "mediatek,mt8173-vencltsys", "syscon";
reg = <0 0x1900 0 0x1000>;
-- 
1.7.9.5

[PATCH v7 1/8] dt-bindings: Add a binding for Mediatek Video Processor

[Tiffany Lin]

From: Andrew-CT Chen 

Add a DT binding documentation of Video Processor Unit for the
MT8173 SoC from Mediatek.

Signed-off-by: Andrew-CT Chen 
Signed-off-by: Tiffany Lin 
Acked-by: Rob Herring 

---
 .../devicetree/bindings/media/mediatek-vpu.txt |   31 
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek-vpu.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-vpu.txt 
b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
new file mode 100644
index 000..2a5bac3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
@@ -0,0 +1,31 @@
+* Mediatek Video Processor Unit
+
+Video Processor Unit is a HW video controller. It controls HW Codec including
+H.264/VP8/VP9 Decode, H.264/VP8 Encode and Image Processor (scale/rotate/color 
convert).
+
+Required properties:
+  - compatible: "mediatek,mt8173-vpu"
+  - reg: Must contain an entry for each entry in reg-names.
+  - reg-names: Must include the following entries:
+"tcm": tcm base
+"cfg_reg": Main configuration registers base
+  - interrupts: interrupt number to the cpu.
+  - clocks : clock name from clock manager
+  - clock-names: must be main. It is the main clock of VPU
+
+Optional properties:
+  - memory-region: phandle to a node describing memory (see
+Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
+to be used for VPU extended memory; if not present, VPU may be located
+anywhere in the memory
+
+Example:
+   vpu: vpu@1002 {
+   compatible = "mediatek,mt8173-vpu";
+   reg = <0 0x1002 0 0x3>,
+ <0 0x1005 0 0x100>;
+   reg-names = "tcm", "cfg_reg";
+   interrupts = ;
+   clocks = < TOP_SCP_SEL>;
+   clock-names = "main";
+   };
-- 
1.7.9.5

[PATCH v7 4/8] dt-bindings: Add a binding for Mediatek Video Encoder

[Tiffany Lin]

Add a DT binding documentation of Video Encoder for the
MT8173 SoC from Mediatek.

Signed-off-by: Tiffany Lin 
Acked-by: Rob Herring 

---
 .../devicetree/bindings/media/mediatek-vcodec.txt  |   59 
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt 
b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
new file mode 100644
index 000..59a47a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -0,0 +1,59 @@
+Mediatek Video Codec
+
+Mediatek Video Codec is the video codec hw present in Mediatek SoCs which
+supports high resolution encoding functionalities.
+
+Required properties:
+- compatible : "mediatek,mt8173-vcodec-enc" for encoder
+- reg : Physical base address of the video codec registers and length of
+  memory mapped region.
+- interrupts : interrupt number to the cpu.
+- mediatek,larb : must contain the local arbiters in the current Socs.
+- clocks : list of clock specifiers, corresponding to entries in
+  the clock-names property.
+- clock-names: encoder must contain "venc_sel_src", "venc_sel",
+- "venc_lt_sel_src", "venc_lt_sel".
+- iommus : should point to the respective IOMMU block with master port as
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  for details.
+- mediatek,vpu : the node of video processor unit
+
+Example:
+vcodec_enc: vcodec@0x18002000 {
+compatible = "mediatek,mt8173-vcodec-enc";
+reg = <0 0x18002000 0 0x1000>,/*VENC_SYS*/
+  <0 0x19002000 0 0x1000>;/*VENC_LT_SYS*/
+interrupts = ,
+;
+mediatek,larb = <>,
+   <>;
+iommus = < M4U_PORT_VENC_RCPU>,
+ < M4U_PORT_VENC_REC>,
+ < M4U_PORT_VENC_BSDMA>,
+ < M4U_PORT_VENC_SV_COMV>,
+ < M4U_PORT_VENC_RD_COMV>,
+ < M4U_PORT_VENC_CUR_LUMA>,
+ < M4U_PORT_VENC_CUR_CHROMA>,
+ < M4U_PORT_VENC_REF_LUMA>,
+ < M4U_PORT_VENC_REF_CHROMA>,
+ < M4U_PORT_VENC_NBM_RDMA>,
+ < M4U_PORT_VENC_NBM_WDMA>,
+ < M4U_PORT_VENC_RCPU_SET2>,
+ < M4U_PORT_VENC_REC_FRM_SET2>,
+ < M4U_PORT_VENC_BSDMA_SET2>,
+ < M4U_PORT_VENC_SV_COMA_SET2>,
+ < M4U_PORT_VENC_RD_COMA_SET2>,
+ < M4U_PORT_VENC_CUR_LUMA_SET2>,
+ < M4U_PORT_VENC_CUR_CHROMA_SET2>,
+ < M4U_PORT_VENC_REF_LUMA_SET2>,
+ < M4U_PORT_VENC_REC_CHROMA_SET2>;
+mediatek,vpu = <>;
+clocks = < CLK_TOP_VENCPLL_D2>,
+ < CLK_TOP_VENC_SEL>,
+ < CLK_TOP_UNIVPLL1_D2>,
+ < CLK_TOP_VENC_LT_SEL>;
+clock-names = "venc_sel_src",
+  "venc_sel",
+  "venc_lt_sel_src",
+  "venc_lt_sel";
+  };
-- 
1.7.9.5

[PATCH v7 1/8] dt-bindings: Add a binding for Mediatek Video Processor

[Tiffany Lin]

From: Andrew-CT Chen 

Add a DT binding documentation of Video Processor Unit for the
MT8173 SoC from Mediatek.

Signed-off-by: Andrew-CT Chen 
Signed-off-by: Tiffany Lin 
Acked-by: Rob Herring 

---
 .../devicetree/bindings/media/mediatek-vpu.txt |   31 
 1 file changed, 31 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek-vpu.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-vpu.txt 
b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
new file mode 100644
index 000..2a5bac3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
@@ -0,0 +1,31 @@
+* Mediatek Video Processor Unit
+
+Video Processor Unit is a HW video controller. It controls HW Codec including
+H.264/VP8/VP9 Decode, H.264/VP8 Encode and Image Processor (scale/rotate/color 
convert).
+
+Required properties:
+  - compatible: "mediatek,mt8173-vpu"
+  - reg: Must contain an entry for each entry in reg-names.
+  - reg-names: Must include the following entries:
+"tcm": tcm base
+"cfg_reg": Main configuration registers base
+  - interrupts: interrupt number to the cpu.
+  - clocks : clock name from clock manager
+  - clock-names: must be main. It is the main clock of VPU
+
+Optional properties:
+  - memory-region: phandle to a node describing memory (see
+Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
+to be used for VPU extended memory; if not present, VPU may be located
+anywhere in the memory
+
+Example:
+   vpu: vpu@1002 {
+   compatible = "mediatek,mt8173-vpu";
+   reg = <0 0x1002 0 0x3>,
+ <0 0x1005 0 0x100>;
+   reg-names = "tcm", "cfg_reg";
+   interrupts = ;
+   clocks = < TOP_SCP_SEL>;
+   clock-names = "main";
+   };
-- 
1.7.9.5

[PATCH v7 4/8] dt-bindings: Add a binding for Mediatek Video Encoder

[Tiffany Lin]

Add a DT binding documentation of Video Encoder for the
MT8173 SoC from Mediatek.

Signed-off-by: Tiffany Lin 
Acked-by: Rob Herring 

---
 .../devicetree/bindings/media/mediatek-vcodec.txt  |   59 
 1 file changed, 59 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt

diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt 
b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
new file mode 100644
index 000..59a47a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -0,0 +1,59 @@
+Mediatek Video Codec
+
+Mediatek Video Codec is the video codec hw present in Mediatek SoCs which
+supports high resolution encoding functionalities.
+
+Required properties:
+- compatible : "mediatek,mt8173-vcodec-enc" for encoder
+- reg : Physical base address of the video codec registers and length of
+  memory mapped region.
+- interrupts : interrupt number to the cpu.
+- mediatek,larb : must contain the local arbiters in the current Socs.
+- clocks : list of clock specifiers, corresponding to entries in
+  the clock-names property.
+- clock-names: encoder must contain "venc_sel_src", "venc_sel",
+- "venc_lt_sel_src", "venc_lt_sel".
+- iommus : should point to the respective IOMMU block with master port as
+  argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
+  for details.
+- mediatek,vpu : the node of video processor unit
+
+Example:
+vcodec_enc: vcodec@0x18002000 {
+compatible = "mediatek,mt8173-vcodec-enc";
+reg = <0 0x18002000 0 0x1000>,/*VENC_SYS*/
+  <0 0x19002000 0 0x1000>;/*VENC_LT_SYS*/
+interrupts = ,
+;
+mediatek,larb = <>,
+   <>;
+iommus = < M4U_PORT_VENC_RCPU>,
+ < M4U_PORT_VENC_REC>,
+ < M4U_PORT_VENC_BSDMA>,
+ < M4U_PORT_VENC_SV_COMV>,
+ < M4U_PORT_VENC_RD_COMV>,
+ < M4U_PORT_VENC_CUR_LUMA>,
+ < M4U_PORT_VENC_CUR_CHROMA>,
+ < M4U_PORT_VENC_REF_LUMA>,
+ < M4U_PORT_VENC_REF_CHROMA>,
+ < M4U_PORT_VENC_NBM_RDMA>,
+ < M4U_PORT_VENC_NBM_WDMA>,
+ < M4U_PORT_VENC_RCPU_SET2>,
+ < M4U_PORT_VENC_REC_FRM_SET2>,
+ < M4U_PORT_VENC_BSDMA_SET2>,
+ < M4U_PORT_VENC_SV_COMA_SET2>,
+ < M4U_PORT_VENC_RD_COMA_SET2>,
+ < M4U_PORT_VENC_CUR_LUMA_SET2>,
+ < M4U_PORT_VENC_CUR_CHROMA_SET2>,
+ < M4U_PORT_VENC_REF_LUMA_SET2>,
+ < M4U_PORT_VENC_REC_CHROMA_SET2>;
+mediatek,vpu = <>;
+clocks = < CLK_TOP_VENCPLL_D2>,
+ < CLK_TOP_VENC_SEL>,
+ < CLK_TOP_UNIVPLL1_D2>,
+ < CLK_TOP_VENC_LT_SEL>;
+clock-names = "venc_sel_src",
+  "venc_sel",
+  "venc_lt_sel_src",
+  "venc_lt_sel";
+  };
-- 
1.7.9.5

[PATCH v7 5/8] [media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver

[Tiffany Lin]

Add v4l2 layer encoder driver for MT8173

Signed-off-by: Tiffany Lin 

---
 drivers/media/platform/Kconfig |   16 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/mtk-vcodec/Makefile |   14 +
 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |  339 +
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1301 
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h |   59 +
 .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c |  467 +++
 .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c  |  137 +++
 .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.h  |   26 +
 .../media/platform/mtk-vcodec/mtk_vcodec_intr.c|   56 +
 .../media/platform/mtk-vcodec/mtk_vcodec_intr.h|   27 +
 .../media/platform/mtk-vcodec/mtk_vcodec_util.c|   96 ++
 .../media/platform/mtk-vcodec/mtk_vcodec_util.h|   87 ++
 drivers/media/platform/mtk-vcodec/venc_drv_base.h  |   62 +
 drivers/media/platform/mtk-vcodec/venc_drv_if.c|  107 ++
 drivers/media/platform/mtk-vcodec/venc_drv_if.h|  165 +++
 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h   |  210 
 17 files changed, 3171 insertions(+)
 create mode 100644 drivers/media/platform/mtk-vcodec/Makefile
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_base.h
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.h
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 74c3575..13b765a 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -165,6 +165,22 @@ config VIDEO_MEDIATEK_VPU
To compile this driver as a module, choose M here: the
module will be called mtk-vpu.
 
+config VIDEO_MEDIATEK_VCODEC
+   tristate "Mediatek Video Codec driver"
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+   select VIDEO_MEDIATEK_VPU
+   default n
+   ---help---
+   Mediatek video codec driver provides HW capability to
+   encode and decode in a range of video formats
+   This driver rely on VPU driver to communicate with VPU.
+
+   To compile this driver as a module, choose M here: the
+   module will be called mtk-vcodec
+
 config VIDEO_MEM2MEM_DEINTERLACE
tristate "Deinterlace support"
depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 2efb7b1..6e735fe 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -58,3 +58,5 @@ obj-$(CONFIG_VIDEO_XILINX)+= xilinx/
 ccflags-y += -I$(srctree)/drivers/media/i2c
 
 obj-$(CONFIG_VIDEO_MEDIATEK_VPU)   += mtk-vpu/
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/
diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
new file mode 100644
index 000..d04433be
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -0,0 +1,14 @@
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-enc.o mtk-vcodec-common.o
+
+
+
+mtk-vcodec-enc-y := mtk_vcodec_enc.o \
+   mtk_vcodec_enc_drv.o \
+   mtk_vcodec_enc_pm.o \
+   venc_drv_if.o \
+
+mtk-vcodec-common-y := mtk_vcodec_intr.o \
+   mtk_vcodec_util.o\
+
+ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
new file mode 100644
index 000..bf41ff3
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -0,0 +1,339 @@
+/*
+* Copyright (c) 2016 MediaTek Inc.
+* Author: PC Chen 
+* Tiffany Lin 
+*
+* 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 

[PATCH v7 0/8] Add MT8173 Video Encoder Driver and VPU Driver

[Tiffany Lin]

==
 Introduction
==

The purpose of this series is to add the driver for video codec hw embedded in 
the Mediatek's MT8173 SoCs.
Mediatek Video Codec is able to handle video encoding of in a range of formats.

This patch series also include VPU driver. Mediatek Video Codec driver rely on 
VPU driver to load,
communicate with VPU.

Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI both 
have been merged in v4.6-rc1.

==
 Device interface
==

In principle the driver bases on v4l2 memory-to-memory framework:
it provides a single video node and each opened file handle gets its own 
private context with separate
buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source 
buffers, i.e. raw video
frames) and CAPTURE (for destination buffers, i.e. encoded video frames).

==
 VPU (Video Processor Unit)
==
The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
It is able to handle video decoding/encoding in a range of formats.
The driver provides with VPU firmware download, memory management and the 
communication interface between CPU and VPU.
For VPU initialization, it will create virtual memory for CPU access and 
physical address for VPU hw device access. 
When a decode/encode instance opens a device node, vpu driver will download vpu 
firmware to the device.
A decode/encode instant will decode/encode a frame using VPU interface to 
interrupt vpu to handle decoding/encoding jobs.

Please have a look at the code and comments will be very much appreciated.

Change in v7:
1. Rebase against the master branch of git://linuxtv.org/media_tree.git
2. Add ycbcr_enc, quantization and xfer_func in try_fmt, g_fmt, s_fmt
3. Merge h264_enc and vp8_enc to one venc directory

Change in v6:
1. Add synchronization access protect between irq handler and work thread
2. Add DMA_ATTR_ALLOC_SINGLE_PAGES support
3. S_FMT will return coded_width, coded_height, so user space could allocate 
correct size memory that HW required
4. merge h264/vp8 enc ap and md32 ipi msg
5. separate h264/vp8 enc gop_size and intra_period handle
6. remove sizeimage relative code in work buffer function
7. Refine makefile to build as an module
8. Code clean up

VPU Part
1. export symbols for building VPU as an module
2. change function from "wait_event_interruptible_timeout" to 
"wait_event_timeout" since
   CPU needs to wait for ACK from VPU even if it was interrupted by a signal

v4l2-compliance test output:
localhost Encode # ./v4l2-compliance -d /dev/video1
Driver Info:
Driver name   : mtk-vcodec-enc
Card type : platform:mt8173
Bus info  : platform:mt8173
Driver version: 4.4.0
Capabilities  : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format

Compliance test for device /dev/video1 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERYCTRL/MENU: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 12 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK
test VIDIOC_G_FBUF: OK (Not Supported)
   

[PATCH v7 7/8] [media] vcodec: mediatek: Add Mediatek H264 Video Encoder Driver

[Tiffany Lin]

Add h264 encoder driver for MT8173

Signed-off-by: PoChun Lin 
Signed-off-by: Tiffany Lin 

---
 drivers/media/platform/mtk-vcodec/Makefile |1 +
 .../media/platform/mtk-vcodec/venc/venc_h264_if.c  |  687 
 drivers/media/platform/mtk-vcodec/venc_drv_if.c|4 +-
 3 files changed, 691 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c

diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
index bf73a45..dc5cb00 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -12,6 +12,7 @@ mtk-vcodec-enc-y := venc/venc_vp8_if.o \
venc_drv_if.o \
venc_vpu_if.o \
 
+
 mtk-vcodec-common-y := mtk_vcodec_intr.o \
mtk_vcodec_util.o\
 
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c 
b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
new file mode 100644
index 000..6e90b3f
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
@@ -0,0 +1,687 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Jungchang Tsao 
+ * Daniel Hsiao 
+ * PoChun Lin 
+ *
+ * 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 "../mtk_vcodec_drv.h"
+#include "../mtk_vcodec_util.h"
+#include "../mtk_vcodec_intr.h"
+#include "../mtk_vcodec_enc.h"
+#include "../mtk_vcodec_enc_pm.h"
+#include "../venc_drv_base.h"
+#include "../venc_ipi_msg.h"
+#include "../venc_vpu_if.h"
+#include "mtk_vpu.h"
+
+static const char h264_filler_marker[] = {0x0, 0x0, 0x0, 0x1, 0xc};
+
+#define H264_FILLER_MARKER_SIZE ARRAY_SIZE(h264_filler_marker)
+#define VENC_PIC_BITSTREAM_BYTE_CNT 0x0098
+
+/**
+ * enum venc_h264_vpu_work_buf - h264 encoder buffer index
+ */
+enum venc_h264_vpu_work_buf {
+   VENC_H264_VPU_WORK_BUF_RC_INFO,
+   VENC_H264_VPU_WORK_BUF_RC_CODE,
+   VENC_H264_VPU_WORK_BUF_REC_LUMA,
+   VENC_H264_VPU_WORK_BUF_REC_CHROMA,
+   VENC_H264_VPU_WORK_BUF_REF_LUMA,
+   VENC_H264_VPU_WORK_BUF_REF_CHROMA,
+   VENC_H264_VPU_WORK_BUF_MV_INFO_1,
+   VENC_H264_VPU_WORK_BUF_MV_INFO_2,
+   VENC_H264_VPU_WORK_BUF_SKIP_FRAME,
+   VENC_H264_VPU_WORK_BUF_MAX,
+};
+
+/**
+ * enum venc_h264_bs_mode - for bs_mode argument in h264_enc_vpu_encode
+ */
+enum venc_h264_bs_mode {
+   H264_BS_MODE_SPS,
+   H264_BS_MODE_PPS,
+   H264_BS_MODE_FRAME,
+};
+
+/*
+ * struct venc_h264_vpu_config - Structure for h264 encoder configuration
+ * @input_fourcc: input fourcc
+ * @bitrate: target bitrate (in bps)
+ * @pic_w: picture width. Picture size is visible stream resolution, in pixels,
+ * to be used for display purposes; must be smaller or equal to buffer
+ * size.
+ * @pic_h: picture height
+ * @buf_w: buffer width. Buffer size is stream resolution in pixels aligned to
+ * hardware requirements.
+ * @buf_h: buffer height
+ * @gop_size: group of picture size (idr frame)
+ * @intra_period: intra frame period
+ * @framerate: frame rate in fps
+ * @profile: as specified in standard
+ * @level: as specified in standard
+ * @wfd: WFD mode 1:on, 0:off
+ */
+struct venc_h264_vpu_config {
+   u32 input_fourcc;
+   u32 bitrate;
+   u32 pic_w;
+   u32 pic_h;
+   u32 buf_w;
+   u32 buf_h;
+   u32 gop_size;
+   u32 intra_period;
+   u32 framerate;
+   u32 profile;
+   u32 level;
+   u32 wfd;
+};
+
+/*
+ * struct venc_h264_vpu_buf - Structure for buffer information
+ * @align: buffer alignment (in bytes)
+ * @iova: IO virtual address
+ * @vpua: VPU side memory addr which is used by RC_CODE
+ * @size: buffer size (in bytes)
+ */
+struct venc_h264_vpu_buf {
+   u32 align;
+   u32 iova;
+   u32 vpua;
+   u32 size;
+};
+
+/*
+ * struct venc_h264_vsi - Structure for VPU driver control and info share
+ * This structure is allocated in VPU side and shared to AP side.
+ * @config: h264 encoder configuration
+ * @work_bufs: working buffer information in VPU side
+ * The work_bufs here is for storing the 'size' info shared to AP side.
+ * The similar item in struct venc_h264_inst is for memory allocation
+ * in AP side. The AP driver will copy the 'size' from here to the one in
+ * struct mtk_vcodec_mem, then invoke mtk_vcodec_mem_alloc to allocate
+ * the buffer. After that, bypass the 'dma_addr' to the 'iova' 

[PATCH v7 2/8] [media] VPU: mediatek: support Mediatek VPU

[Tiffany Lin]

From: Andrew-CT Chen 

The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
It is able to handle video decoding/encoding of in a range of formats.
The driver provides with VPU firmware download, memory management and
the communication interface between CPU and VPU.
For VPU initialization, it will create virtual memory for CPU access and
IOMMU address for vcodec hw device access. When a decode/encode instance
opens a device node, vpu driver will download vpu firmware to the device.
A decode/encode instant will decode/encode a frame using VPU
interface to interrupt vpu to handle decoding/encoding jobs.

Signed-off-by: Andrew-CT Chen 
Signed-off-by: Tiffany Lin 

---
 drivers/media/platform/Kconfig   |   13 +
 drivers/media/platform/Makefile  |2 +
 drivers/media/platform/mtk-vpu/Makefile  |3 +
 drivers/media/platform/mtk-vpu/mtk_vpu.c |  950 ++
 drivers/media/platform/mtk-vpu/mtk_vpu.h |  162 +
 5 files changed, 1130 insertions(+)
 create mode 100644 drivers/media/platform/mtk-vpu/Makefile
 create mode 100755 drivers/media/platform/mtk-vpu/mtk_vpu.c
 create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 84e041c..74c3575 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -152,6 +152,19 @@ config VIDEO_CODA
   Coda is a range of video codec IPs that supports
   H.264, MPEG-4, and other video formats.
 
+config VIDEO_MEDIATEK_VPU
+   tristate "Mediatek Video Processor Unit"
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   ---help---
+   This driver provides downloading VPU firmware and
+   communicating with VPU. This driver for hw video
+   codec embedded in Mediatek's MT8173 SOCs. It is able
+   to handle video decoding/encoding in a range of formats.
+
+   To compile this driver as a module, choose M here: the
+   module will be called mtk-vpu.
+
 config VIDEO_MEM2MEM_DEINTERLACE
tristate "Deinterlace support"
depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index bbb7bd1..2efb7b1 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -56,3 +56,5 @@ obj-$(CONFIG_VIDEO_AM437X_VPFE)   += am437x/
 obj-$(CONFIG_VIDEO_XILINX) += xilinx/
 
 ccflags-y += -I$(srctree)/drivers/media/i2c
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VPU)   += mtk-vpu/
diff --git a/drivers/media/platform/mtk-vpu/Makefile 
b/drivers/media/platform/mtk-vpu/Makefile
new file mode 100644
index 000..58cc1b4
--- /dev/null
+++ b/drivers/media/platform/mtk-vpu/Makefile
@@ -0,0 +1,3 @@
+mtk-vpu-y += mtk_vpu.o
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu.o
diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c 
b/drivers/media/platform/mtk-vpu/mtk_vpu.c
new file mode 100755
index 000..55c081e
--- /dev/null
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
@@ -0,0 +1,950 @@
+/*
+* Copyright (c) 2016 MediaTek Inc.
+* Author: Andrew-CT Chen 
+*
+* 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 "mtk_vpu.h"
+
+/**
+ * VPU (video processor unit) is a tiny processor controlling video hardware
+ * related to video codec, scaling and color format converting.
+ * VPU interfaces with other blocks by share memory and interrupt.
+ **/
+
+#define INIT_TIMEOUT_MS2000U
+#define IPI_TIMEOUT_MS 2000U
+#define VPU_FW_VER_LEN 16
+
+/* maximum program/data TCM (Tightly-Coupled Memory) size */
+#define VPU_PTCM_SIZE  (96 * SZ_1K)
+#define VPU_DTCM_SIZE  (32 * SZ_1K)
+/* the offset to get data tcm address */
+#define VPU_DTCM_OFFSET0x18000UL
+/* daynamic allocated maximum extended memory size */
+#define VPU_EXT_P_SIZE SZ_1M
+#define VPU_EXT_D_SIZE SZ_4M
+/* maximum binary firmware size */
+#define VPU_P_FW_SIZE  (VPU_PTCM_SIZE + VPU_EXT_P_SIZE)
+#define VPU_D_FW_SIZE  (VPU_DTCM_SIZE + VPU_EXT_D_SIZE)
+/* the size of share buffer between Host and  VPU */
+#define SHARE_BUF_SIZE 48
+
+/* binary firmware name */
+#define VPU_P_FW   "vpu_p.bin"
+#define 

[PATCH v7 5/8] [media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver

[Tiffany Lin]

Add v4l2 layer encoder driver for MT8173

Signed-off-by: Tiffany Lin 

---
 drivers/media/platform/Kconfig |   16 +
 drivers/media/platform/Makefile|2 +
 drivers/media/platform/mtk-vcodec/Makefile |   14 +
 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |  339 +
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1301 
 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h |   59 +
 .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c |  467 +++
 .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c  |  137 +++
 .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.h  |   26 +
 .../media/platform/mtk-vcodec/mtk_vcodec_intr.c|   56 +
 .../media/platform/mtk-vcodec/mtk_vcodec_intr.h|   27 +
 .../media/platform/mtk-vcodec/mtk_vcodec_util.c|   96 ++
 .../media/platform/mtk-vcodec/mtk_vcodec_util.h|   87 ++
 drivers/media/platform/mtk-vcodec/venc_drv_base.h  |   62 +
 drivers/media/platform/mtk-vcodec/venc_drv_if.c|  107 ++
 drivers/media/platform/mtk-vcodec/venc_drv_if.h|  165 +++
 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h   |  210 
 17 files changed, 3171 insertions(+)
 create mode 100644 drivers/media/platform/mtk-vcodec/Makefile
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c
 create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_base.h
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.h
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 74c3575..13b765a 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -165,6 +165,22 @@ config VIDEO_MEDIATEK_VPU
To compile this driver as a module, choose M here: the
module will be called mtk-vpu.
 
+config VIDEO_MEDIATEK_VCODEC
+   tristate "Mediatek Video Codec driver"
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   select V4L2_MEM2MEM_DEV
+   select VIDEO_MEDIATEK_VPU
+   default n
+   ---help---
+   Mediatek video codec driver provides HW capability to
+   encode and decode in a range of video formats
+   This driver rely on VPU driver to communicate with VPU.
+
+   To compile this driver as a module, choose M here: the
+   module will be called mtk-vcodec
+
 config VIDEO_MEM2MEM_DEINTERLACE
tristate "Deinterlace support"
depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 2efb7b1..6e735fe 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -58,3 +58,5 @@ obj-$(CONFIG_VIDEO_XILINX)+= xilinx/
 ccflags-y += -I$(srctree)/drivers/media/i2c
 
 obj-$(CONFIG_VIDEO_MEDIATEK_VPU)   += mtk-vpu/
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/
diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
new file mode 100644
index 000..d04433be
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -0,0 +1,14 @@
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-enc.o mtk-vcodec-common.o
+
+
+
+mtk-vcodec-enc-y := mtk_vcodec_enc.o \
+   mtk_vcodec_enc_drv.o \
+   mtk_vcodec_enc_pm.o \
+   venc_drv_if.o \
+
+mtk-vcodec-common-y := mtk_vcodec_intr.o \
+   mtk_vcodec_util.o\
+
+ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h 
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
new file mode 100644
index 000..bf41ff3
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -0,0 +1,339 @@
+/*
+* Copyright (c) 2016 MediaTek Inc.
+* Author: PC Chen 
+* Tiffany Lin 
+*
+* 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 

[PATCH v7 0/8] Add MT8173 Video Encoder Driver and VPU Driver

[Tiffany Lin]

==
 Introduction
==

The purpose of this series is to add the driver for video codec hw embedded in 
the Mediatek's MT8173 SoCs.
Mediatek Video Codec is able to handle video encoding of in a range of formats.

This patch series also include VPU driver. Mediatek Video Codec driver rely on 
VPU driver to load,
communicate with VPU.

Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI both 
have been merged in v4.6-rc1.

==
 Device interface
==

In principle the driver bases on v4l2 memory-to-memory framework:
it provides a single video node and each opened file handle gets its own 
private context with separate
buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source 
buffers, i.e. raw video
frames) and CAPTURE (for destination buffers, i.e. encoded video frames).

==
 VPU (Video Processor Unit)
==
The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
It is able to handle video decoding/encoding in a range of formats.
The driver provides with VPU firmware download, memory management and the 
communication interface between CPU and VPU.
For VPU initialization, it will create virtual memory for CPU access and 
physical address for VPU hw device access. 
When a decode/encode instance opens a device node, vpu driver will download vpu 
firmware to the device.
A decode/encode instant will decode/encode a frame using VPU interface to 
interrupt vpu to handle decoding/encoding jobs.

Please have a look at the code and comments will be very much appreciated.

Change in v7:
1. Rebase against the master branch of git://linuxtv.org/media_tree.git
2. Add ycbcr_enc, quantization and xfer_func in try_fmt, g_fmt, s_fmt
3. Merge h264_enc and vp8_enc to one venc directory

Change in v6:
1. Add synchronization access protect between irq handler and work thread
2. Add DMA_ATTR_ALLOC_SINGLE_PAGES support
3. S_FMT will return coded_width, coded_height, so user space could allocate 
correct size memory that HW required
4. merge h264/vp8 enc ap and md32 ipi msg
5. separate h264/vp8 enc gop_size and intra_period handle
6. remove sizeimage relative code in work buffer function
7. Refine makefile to build as an module
8. Code clean up

VPU Part
1. export symbols for building VPU as an module
2. change function from "wait_event_interruptible_timeout" to 
"wait_event_timeout" since
   CPU needs to wait for ACK from VPU even if it was interrupted by a signal

v4l2-compliance test output:
localhost Encode # ./v4l2-compliance -d /dev/video1
Driver Info:
Driver name   : mtk-vcodec-enc
Card type : platform:mt8173
Bus info  : platform:mt8173
Driver version: 4.4.0
Capabilities  : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format

Compliance test for device /dev/video1 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Control ioctls:
test VIDIOC_QUERYCTRL/MENU: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 12 Private Controls: 0

Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK
test VIDIOC_G_FBUF: OK (Not Supported)
   

[PATCH v7 7/8] [media] vcodec: mediatek: Add Mediatek H264 Video Encoder Driver

[Tiffany Lin]

Add h264 encoder driver for MT8173

Signed-off-by: PoChun Lin 
Signed-off-by: Tiffany Lin 

---
 drivers/media/platform/mtk-vcodec/Makefile |1 +
 .../media/platform/mtk-vcodec/venc/venc_h264_if.c  |  687 
 drivers/media/platform/mtk-vcodec/venc_drv_if.c|4 +-
 3 files changed, 691 insertions(+), 1 deletion(-)
 create mode 100644 drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c

diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
index bf73a45..dc5cb00 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -12,6 +12,7 @@ mtk-vcodec-enc-y := venc/venc_vp8_if.o \
venc_drv_if.o \
venc_vpu_if.o \
 
+
 mtk-vcodec-common-y := mtk_vcodec_intr.o \
mtk_vcodec_util.o\
 
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c 
b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
new file mode 100644
index 000..6e90b3f
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
@@ -0,0 +1,687 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Jungchang Tsao 
+ * Daniel Hsiao 
+ * PoChun Lin 
+ *
+ * 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 "../mtk_vcodec_drv.h"
+#include "../mtk_vcodec_util.h"
+#include "../mtk_vcodec_intr.h"
+#include "../mtk_vcodec_enc.h"
+#include "../mtk_vcodec_enc_pm.h"
+#include "../venc_drv_base.h"
+#include "../venc_ipi_msg.h"
+#include "../venc_vpu_if.h"
+#include "mtk_vpu.h"
+
+static const char h264_filler_marker[] = {0x0, 0x0, 0x0, 0x1, 0xc};
+
+#define H264_FILLER_MARKER_SIZE ARRAY_SIZE(h264_filler_marker)
+#define VENC_PIC_BITSTREAM_BYTE_CNT 0x0098
+
+/**
+ * enum venc_h264_vpu_work_buf - h264 encoder buffer index
+ */
+enum venc_h264_vpu_work_buf {
+   VENC_H264_VPU_WORK_BUF_RC_INFO,
+   VENC_H264_VPU_WORK_BUF_RC_CODE,
+   VENC_H264_VPU_WORK_BUF_REC_LUMA,
+   VENC_H264_VPU_WORK_BUF_REC_CHROMA,
+   VENC_H264_VPU_WORK_BUF_REF_LUMA,
+   VENC_H264_VPU_WORK_BUF_REF_CHROMA,
+   VENC_H264_VPU_WORK_BUF_MV_INFO_1,
+   VENC_H264_VPU_WORK_BUF_MV_INFO_2,
+   VENC_H264_VPU_WORK_BUF_SKIP_FRAME,
+   VENC_H264_VPU_WORK_BUF_MAX,
+};
+
+/**
+ * enum venc_h264_bs_mode - for bs_mode argument in h264_enc_vpu_encode
+ */
+enum venc_h264_bs_mode {
+   H264_BS_MODE_SPS,
+   H264_BS_MODE_PPS,
+   H264_BS_MODE_FRAME,
+};
+
+/*
+ * struct venc_h264_vpu_config - Structure for h264 encoder configuration
+ * @input_fourcc: input fourcc
+ * @bitrate: target bitrate (in bps)
+ * @pic_w: picture width. Picture size is visible stream resolution, in pixels,
+ * to be used for display purposes; must be smaller or equal to buffer
+ * size.
+ * @pic_h: picture height
+ * @buf_w: buffer width. Buffer size is stream resolution in pixels aligned to
+ * hardware requirements.
+ * @buf_h: buffer height
+ * @gop_size: group of picture size (idr frame)
+ * @intra_period: intra frame period
+ * @framerate: frame rate in fps
+ * @profile: as specified in standard
+ * @level: as specified in standard
+ * @wfd: WFD mode 1:on, 0:off
+ */
+struct venc_h264_vpu_config {
+   u32 input_fourcc;
+   u32 bitrate;
+   u32 pic_w;
+   u32 pic_h;
+   u32 buf_w;
+   u32 buf_h;
+   u32 gop_size;
+   u32 intra_period;
+   u32 framerate;
+   u32 profile;
+   u32 level;
+   u32 wfd;
+};
+
+/*
+ * struct venc_h264_vpu_buf - Structure for buffer information
+ * @align: buffer alignment (in bytes)
+ * @iova: IO virtual address
+ * @vpua: VPU side memory addr which is used by RC_CODE
+ * @size: buffer size (in bytes)
+ */
+struct venc_h264_vpu_buf {
+   u32 align;
+   u32 iova;
+   u32 vpua;
+   u32 size;
+};
+
+/*
+ * struct venc_h264_vsi - Structure for VPU driver control and info share
+ * This structure is allocated in VPU side and shared to AP side.
+ * @config: h264 encoder configuration
+ * @work_bufs: working buffer information in VPU side
+ * The work_bufs here is for storing the 'size' info shared to AP side.
+ * The similar item in struct venc_h264_inst is for memory allocation
+ * in AP side. The AP driver will copy the 'size' from here to the one in
+ * struct mtk_vcodec_mem, then invoke mtk_vcodec_mem_alloc to allocate
+ * the buffer. After that, bypass the 'dma_addr' to the 'iova' field here for
+ * register setting in VPU side.
+ * @sizeimage: image size for each plane
+ */
+struct venc_h264_vsi {
+   struct 

[PATCH v7 2/8] [media] VPU: mediatek: support Mediatek VPU

[Tiffany Lin]

From: Andrew-CT Chen 

The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
It is able to handle video decoding/encoding of in a range of formats.
The driver provides with VPU firmware download, memory management and
the communication interface between CPU and VPU.
For VPU initialization, it will create virtual memory for CPU access and
IOMMU address for vcodec hw device access. When a decode/encode instance
opens a device node, vpu driver will download vpu firmware to the device.
A decode/encode instant will decode/encode a frame using VPU
interface to interrupt vpu to handle decoding/encoding jobs.

Signed-off-by: Andrew-CT Chen 
Signed-off-by: Tiffany Lin 

---
 drivers/media/platform/Kconfig   |   13 +
 drivers/media/platform/Makefile  |2 +
 drivers/media/platform/mtk-vpu/Makefile  |3 +
 drivers/media/platform/mtk-vpu/mtk_vpu.c |  950 ++
 drivers/media/platform/mtk-vpu/mtk_vpu.h |  162 +
 5 files changed, 1130 insertions(+)
 create mode 100644 drivers/media/platform/mtk-vpu/Makefile
 create mode 100755 drivers/media/platform/mtk-vpu/mtk_vpu.c
 create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 84e041c..74c3575 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -152,6 +152,19 @@ config VIDEO_CODA
   Coda is a range of video codec IPs that supports
   H.264, MPEG-4, and other video formats.
 
+config VIDEO_MEDIATEK_VPU
+   tristate "Mediatek Video Processor Unit"
+   depends on VIDEO_DEV && VIDEO_V4L2
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   ---help---
+   This driver provides downloading VPU firmware and
+   communicating with VPU. This driver for hw video
+   codec embedded in Mediatek's MT8173 SOCs. It is able
+   to handle video decoding/encoding in a range of formats.
+
+   To compile this driver as a module, choose M here: the
+   module will be called mtk-vpu.
+
 config VIDEO_MEM2MEM_DEINTERLACE
tristate "Deinterlace support"
depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index bbb7bd1..2efb7b1 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -56,3 +56,5 @@ obj-$(CONFIG_VIDEO_AM437X_VPFE)   += am437x/
 obj-$(CONFIG_VIDEO_XILINX) += xilinx/
 
 ccflags-y += -I$(srctree)/drivers/media/i2c
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VPU)   += mtk-vpu/
diff --git a/drivers/media/platform/mtk-vpu/Makefile 
b/drivers/media/platform/mtk-vpu/Makefile
new file mode 100644
index 000..58cc1b4
--- /dev/null
+++ b/drivers/media/platform/mtk-vpu/Makefile
@@ -0,0 +1,3 @@
+mtk-vpu-y += mtk_vpu.o
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu.o
diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c 
b/drivers/media/platform/mtk-vpu/mtk_vpu.c
new file mode 100755
index 000..55c081e
--- /dev/null
+++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c
@@ -0,0 +1,950 @@
+/*
+* Copyright (c) 2016 MediaTek Inc.
+* Author: Andrew-CT Chen 
+*
+* 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 "mtk_vpu.h"
+
+/**
+ * VPU (video processor unit) is a tiny processor controlling video hardware
+ * related to video codec, scaling and color format converting.
+ * VPU interfaces with other blocks by share memory and interrupt.
+ **/
+
+#define INIT_TIMEOUT_MS2000U
+#define IPI_TIMEOUT_MS 2000U
+#define VPU_FW_VER_LEN 16
+
+/* maximum program/data TCM (Tightly-Coupled Memory) size */
+#define VPU_PTCM_SIZE  (96 * SZ_1K)
+#define VPU_DTCM_SIZE  (32 * SZ_1K)
+/* the offset to get data tcm address */
+#define VPU_DTCM_OFFSET0x18000UL
+/* daynamic allocated maximum extended memory size */
+#define VPU_EXT_P_SIZE SZ_1M
+#define VPU_EXT_D_SIZE SZ_4M
+/* maximum binary firmware size */
+#define VPU_P_FW_SIZE  (VPU_PTCM_SIZE + VPU_EXT_P_SIZE)
+#define VPU_D_FW_SIZE  (VPU_DTCM_SIZE + VPU_EXT_D_SIZE)
+/* the size of share buffer between Host and  VPU */
+#define SHARE_BUF_SIZE 48
+
+/* binary firmware name */
+#define VPU_P_FW   "vpu_p.bin"
+#define VPU_D_FW   "vpu_d.bin"
+
+#define VPU_RESET  0x0
+#define VPU_TCM_CFG0x0008
+#define 

[PATCH v7 6/8] [media] vcodec: mediatek: Add Mediatek VP8 Video Encoder Driver

[Tiffany Lin]

Add vp8 encoder driver for MT8173

Signed-off-by: PoChun Lin 
Signed-off-by: Tiffany Lin 

---
 drivers/media/platform/mtk-vcodec/Makefile |6 +-
 .../media/platform/mtk-vcodec/venc/venc_vp8_if.c   |  488 
 drivers/media/platform/mtk-vcodec/venc_drv_if.c|7 +-
 drivers/media/platform/mtk-vcodec/venc_vpu_if.c|  240 ++
 drivers/media/platform/mtk-vcodec/venc_vpu_if.h|   61 +++
 5 files changed, 800 insertions(+), 2 deletions(-)
 create mode 100644 drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_vpu_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_vpu_if.h

diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
index d04433be..bf73a45 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -1,12 +1,16 @@
 
+
 obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-enc.o mtk-vcodec-common.o
 
 
 
-mtk-vcodec-enc-y := mtk_vcodec_enc.o \
+mtk-vcodec-enc-y := venc/venc_vp8_if.o \
+   venc/venc_h264_if.o \
+   mtk_vcodec_enc.o \
mtk_vcodec_enc_drv.o \
mtk_vcodec_enc_pm.o \
venc_drv_if.o \
+   venc_vpu_if.o \
 
 mtk-vcodec-common-y := mtk_vcodec_intr.o \
mtk_vcodec_util.o\
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c 
b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
new file mode 100644
index 000..5389841
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
@@ -0,0 +1,488 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Daniel Hsiao 
+ * PoChun Lin 
+ *
+ * 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 "../mtk_vcodec_drv.h"
+#include "../mtk_vcodec_util.h"
+#include "../mtk_vcodec_intr.h"
+#include "../mtk_vcodec_enc.h"
+#include "../mtk_vcodec_enc_pm.h"
+#include "../venc_drv_base.h"
+#include "../venc_ipi_msg.h"
+#include "../venc_vpu_if.h"
+#include "mtk_vpu.h"
+
+#define VENC_BITSTREAM_FRAME_SIZE 0x0098
+#define VENC_BITSTREAM_HEADER_LEN 0x00e8
+
+/* This ac_tag is vp8 frame tag. */
+#define MAX_AC_TAG_SIZE 10
+
+/**
+ * enum venc_vp8_vpu_work_buf - vp8 encoder buffer index
+ */
+enum venc_vp8_vpu_work_buf {
+   VENC_VP8_VPU_WORK_BUF_LUMA,
+   VENC_VP8_VPU_WORK_BUF_LUMA2,
+   VENC_VP8_VPU_WORK_BUF_LUMA3,
+   VENC_VP8_VPU_WORK_BUF_CHROMA,
+   VENC_VP8_VPU_WORK_BUF_CHROMA2,
+   VENC_VP8_VPU_WORK_BUF_CHROMA3,
+   VENC_VP8_VPU_WORK_BUF_MV_INFO,
+   VENC_VP8_VPU_WORK_BUF_BS_HEADER,
+   VENC_VP8_VPU_WORK_BUF_PROB_BUF,
+   VENC_VP8_VPU_WORK_BUF_RC_INFO,
+   VENC_VP8_VPU_WORK_BUF_RC_CODE,
+   VENC_VP8_VPU_WORK_BUF_RC_CODE2,
+   VENC_VP8_VPU_WORK_BUF_RC_CODE3,
+   VENC_VP8_VPU_WORK_BUF_MAX,
+};
+
+/*
+ * struct venc_vp8_vpu_config - Structure for vp8 encoder configuration
+ * @input_fourcc: input fourcc
+ * @bitrate: target bitrate (in bps)
+ * @pic_w: picture width. Picture size is visible stream resolution, in pixels,
+ * to be used for display purposes; must be smaller or equal to buffer
+ * size.
+ * @pic_h: picture height
+ * @buf_w: buffer width (with 16 alignment). Buffer size is stream resolution
+ * in pixels aligned to hardware requirements.
+ * @buf_h: buffer height (with 16 alignment)
+ * @gop_size: group of picture size (key frame)
+ * @framerate: frame rate in fps
+ * @ts_mode: temporal scalability mode (0: disable, 1: enable)
+ *  support three temporal layers - 0: 7.5fps 1: 7.5fps 2: 15fps.
+ */
+struct venc_vp8_vpu_config {
+   u32 input_fourcc;
+   u32 bitrate;
+   u32 pic_w;
+   u32 pic_h;
+   u32 buf_w;
+   u32 buf_h;
+   u32 gop_size;
+   u32 framerate;
+   u32 ts_mode;
+};
+
+/*
+ * struct venc_vp8_vpu_buf -Structure for buffer information
+ * @align: buffer alignment (in bytes)
+ * @iova: IO virtual address
+ * @vpua: VPU side memory addr which is used by RC_CODE
+ * @size: buffer size (in bytes)
+ */
+struct venc_vp8_vpu_buf {
+   u32 align;
+   u32 iova;
+   u32 vpua;
+   u32 size;
+};
+
+/*
+ * struct venc_vp8_vsi - Structure for VPU driver control and info share
+ * This structure is allocated in VPU side and shared to AP side.
+ * @config: vp8 encoder configuration
+ * @work_bufs: working buffer information in VPU side
+ * The 

[PATCH v7 6/8] [media] vcodec: mediatek: Add Mediatek VP8 Video Encoder Driver

[Tiffany Lin]

Add vp8 encoder driver for MT8173

Signed-off-by: PoChun Lin 
Signed-off-by: Tiffany Lin 

---
 drivers/media/platform/mtk-vcodec/Makefile |6 +-
 .../media/platform/mtk-vcodec/venc/venc_vp8_if.c   |  488 
 drivers/media/platform/mtk-vcodec/venc_drv_if.c|7 +-
 drivers/media/platform/mtk-vcodec/venc_vpu_if.c|  240 ++
 drivers/media/platform/mtk-vcodec/venc_vpu_if.h|   61 +++
 5 files changed, 800 insertions(+), 2 deletions(-)
 create mode 100644 drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_vpu_if.c
 create mode 100644 drivers/media/platform/mtk-vcodec/venc_vpu_if.h

diff --git a/drivers/media/platform/mtk-vcodec/Makefile 
b/drivers/media/platform/mtk-vcodec/Makefile
index d04433be..bf73a45 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -1,12 +1,16 @@
 
+
 obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-enc.o mtk-vcodec-common.o
 
 
 
-mtk-vcodec-enc-y := mtk_vcodec_enc.o \
+mtk-vcodec-enc-y := venc/venc_vp8_if.o \
+   venc/venc_h264_if.o \
+   mtk_vcodec_enc.o \
mtk_vcodec_enc_drv.o \
mtk_vcodec_enc_pm.o \
venc_drv_if.o \
+   venc_vpu_if.o \
 
 mtk-vcodec-common-y := mtk_vcodec_intr.o \
mtk_vcodec_util.o\
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c 
b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
new file mode 100644
index 000..5389841
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
@@ -0,0 +1,488 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ * Author: Daniel Hsiao 
+ * PoChun Lin 
+ *
+ * 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 "../mtk_vcodec_drv.h"
+#include "../mtk_vcodec_util.h"
+#include "../mtk_vcodec_intr.h"
+#include "../mtk_vcodec_enc.h"
+#include "../mtk_vcodec_enc_pm.h"
+#include "../venc_drv_base.h"
+#include "../venc_ipi_msg.h"
+#include "../venc_vpu_if.h"
+#include "mtk_vpu.h"
+
+#define VENC_BITSTREAM_FRAME_SIZE 0x0098
+#define VENC_BITSTREAM_HEADER_LEN 0x00e8
+
+/* This ac_tag is vp8 frame tag. */
+#define MAX_AC_TAG_SIZE 10
+
+/**
+ * enum venc_vp8_vpu_work_buf - vp8 encoder buffer index
+ */
+enum venc_vp8_vpu_work_buf {
+   VENC_VP8_VPU_WORK_BUF_LUMA,
+   VENC_VP8_VPU_WORK_BUF_LUMA2,
+   VENC_VP8_VPU_WORK_BUF_LUMA3,
+   VENC_VP8_VPU_WORK_BUF_CHROMA,
+   VENC_VP8_VPU_WORK_BUF_CHROMA2,
+   VENC_VP8_VPU_WORK_BUF_CHROMA3,
+   VENC_VP8_VPU_WORK_BUF_MV_INFO,
+   VENC_VP8_VPU_WORK_BUF_BS_HEADER,
+   VENC_VP8_VPU_WORK_BUF_PROB_BUF,
+   VENC_VP8_VPU_WORK_BUF_RC_INFO,
+   VENC_VP8_VPU_WORK_BUF_RC_CODE,
+   VENC_VP8_VPU_WORK_BUF_RC_CODE2,
+   VENC_VP8_VPU_WORK_BUF_RC_CODE3,
+   VENC_VP8_VPU_WORK_BUF_MAX,
+};
+
+/*
+ * struct venc_vp8_vpu_config - Structure for vp8 encoder configuration
+ * @input_fourcc: input fourcc
+ * @bitrate: target bitrate (in bps)
+ * @pic_w: picture width. Picture size is visible stream resolution, in pixels,
+ * to be used for display purposes; must be smaller or equal to buffer
+ * size.
+ * @pic_h: picture height
+ * @buf_w: buffer width (with 16 alignment). Buffer size is stream resolution
+ * in pixels aligned to hardware requirements.
+ * @buf_h: buffer height (with 16 alignment)
+ * @gop_size: group of picture size (key frame)
+ * @framerate: frame rate in fps
+ * @ts_mode: temporal scalability mode (0: disable, 1: enable)
+ *  support three temporal layers - 0: 7.5fps 1: 7.5fps 2: 15fps.
+ */
+struct venc_vp8_vpu_config {
+   u32 input_fourcc;
+   u32 bitrate;
+   u32 pic_w;
+   u32 pic_h;
+   u32 buf_w;
+   u32 buf_h;
+   u32 gop_size;
+   u32 framerate;
+   u32 ts_mode;
+};
+
+/*
+ * struct venc_vp8_vpu_buf -Structure for buffer information
+ * @align: buffer alignment (in bytes)
+ * @iova: IO virtual address
+ * @vpua: VPU side memory addr which is used by RC_CODE
+ * @size: buffer size (in bytes)
+ */
+struct venc_vp8_vpu_buf {
+   u32 align;
+   u32 iova;
+   u32 vpua;
+   u32 size;
+};
+
+/*
+ * struct venc_vp8_vsi - Structure for VPU driver control and info share
+ * This structure is allocated in VPU side and shared to AP side.
+ * @config: vp8 encoder configuration
+ * @work_bufs: working buffer information in VPU side
+ * The work_bufs here is for storing the 'size' info shared to AP side.
+ * The similar item in struct 

[PATCH v7 3/8] arm64: dts: mediatek: Add node for Mediatek Video Processor Unit

[Tiffany Lin]

From: Andrew-CT Chen 

Add VPU drivers for MT8173

Signed-off-by: Andrew-CT Chen 
Signed-off-by: Tiffany Lin 

---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index eab7efc..ae147bb 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -125,6 +125,18 @@
clock-output-names = "cpum_ck";
};
 
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   vpu_dma_reserved: vpu_dma_mem_region {
+   compatible = "shared-dma-pool";
+   reg = <0 0xb700 0 0x50>;
+   alignment = <0x1000>;
+   no-map;
+   };
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupt-parent = <>;
@@ -269,6 +281,17 @@
clock-names = "spi", "wrap";
};
 
+   vpu: vpu@1002 {
+   compatible = "mediatek,mt8173-vpu";
+   reg = <0 0x1002 0 0x3>,
+ <0 0x1005 0 0x100>;
+   reg-names = "tcm", "cfg_reg";
+   interrupts = ;
+   clocks = < CLK_TOP_SCP_SEL>;
+   clock-names = "main";
+   memory-region = <_dma_reserved>;
+   };
+
sysirq: intpol-controller@10200620 {
compatible = "mediatek,mt8173-sysirq",
 "mediatek,mt6577-sysirq";
-- 
1.7.9.5

[PATCH v7 3/8] arm64: dts: mediatek: Add node for Mediatek Video Processor Unit

[Tiffany Lin]

From: Andrew-CT Chen 

Add VPU drivers for MT8173

Signed-off-by: Andrew-CT Chen 
Signed-off-by: Tiffany Lin 

---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |   23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index eab7efc..ae147bb 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -125,6 +125,18 @@
clock-output-names = "cpum_ck";
};
 
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   vpu_dma_reserved: vpu_dma_mem_region {
+   compatible = "shared-dma-pool";
+   reg = <0 0xb700 0 0x50>;
+   alignment = <0x1000>;
+   no-map;
+   };
+   };
+
timer {
compatible = "arm,armv8-timer";
interrupt-parent = <>;
@@ -269,6 +281,17 @@
clock-names = "spi", "wrap";
};
 
+   vpu: vpu@1002 {
+   compatible = "mediatek,mt8173-vpu";
+   reg = <0 0x1002 0 0x3>,
+ <0 0x1005 0 0x100>;
+   reg-names = "tcm", "cfg_reg";
+   interrupts = ;
+   clocks = < CLK_TOP_SCP_SEL>;
+   clock-names = "main";
+   memory-region = <_dma_reserved>;
+   };
+
sysirq: intpol-controller@10200620 {
compatible = "mediatek,mt8173-sysirq",
 "mediatek,mt6577-sysirq";
-- 
1.7.9.5

Re: [PATCH] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs

[Huang, Tao]

Hi, Doug:
On 2016年04月22日 06:38, Doug Anderson wrote:
>
>>> + i2c1: i2c@ff11 {
>>> + compatible = "rockchip,rk3399-i2c";
>> David respun the rk3399 i2c-support on tuesday, so this and the others below
>> are waiting on Wolfram to take a look.
> I think it can work with the rk3288-i2c as a fallback, at least for
> low speed stuff, right?  Should this be:
>
> compatible = "rockchip,rk3399-i2c", "rockchip,rk3288-i2c"
>
> Looks like that was done for rk3368.
No. For RK3399 I2C controller:
The I2C controller uses the APB clock/clk_i2c as the working clock. The
APB clock will determine the I2C bus clock, clk_i2c is the function clk,
up to 200MHz.
Chips such as RK3288/3368 only uses APB clock. So old driver do not work
on RK3399.

Thanks,
Huang, Tao

Re: [PATCH] ARM64: dts: rockchip: add core dtsi file for RK3399 SoCs

[Huang, Tao]

Hi, Doug:
On 2016年04月22日 06:38, Doug Anderson wrote:
>
>>> + i2c1: i2c@ff11 {
>>> + compatible = "rockchip,rk3399-i2c";
>> David respun the rk3399 i2c-support on tuesday, so this and the others below
>> are waiting on Wolfram to take a look.
> I think it can work with the rk3288-i2c as a fallback, at least for
> low speed stuff, right?  Should this be:
>
> compatible = "rockchip,rk3399-i2c", "rockchip,rk3288-i2c"
>
> Looks like that was done for rk3368.
No. For RK3399 I2C controller:
The I2C controller uses the APB clock/clk_i2c as the working clock. The
APB clock will determine the I2C bus clock, clk_i2c is the function clk,
up to 200MHz.
Chips such as RK3288/3368 only uses APB clock. So old driver do not work
on RK3399.

Thanks,
Huang, Tao

RE: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch

[Yunhui Cui]

> -Original Message-
> From: Han Xu
> Sent: Thursday, April 21, 2016 11:48 PM
> To: Yunhui Cui; Yunhui Cui; dw...@infradead.org;
> computersforpe...@gmail.com; han...@freescale.com
> Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; linux-
> arm-ker...@lists.infradead.org; Yao Yuan
> Subject: Re: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
> 
> 
> 
> 
> From: Yunhui Cui
> Sent: Thursday, April 21, 2016 3:41 AM
> To: Han Xu; Yunhui Cui; dw...@infradead.org; computersforpe...@gmail.com;
> han...@freescale.com
> Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; linux-
> arm-ker...@lists.infradead.org; Yao Yuan
> Subject: RE: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
> 
> On Thu, Apr 24, 2016 at 06:37:01 AM +0800, Han Xu wrote:
> > 
> > From: Yunhui Cui 
> > Sent: Wednesday, April 13, 2016 9:50 PM
> > To: dw...@infradead.org; computersforpe...@gmail.com;
> > han...@freescale.com
> > Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org;
> > linux- arm-ker...@lists.infradead.org; Yao Yuan; Yunhui Cui
> > Subject: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
> >
> > From: Yunhui Cui 
> >
> > A-009282: QuadSPI: QuadSPI data pre-fetch can result in incorrect data
> > Affects: QuadSPI
> > Description: With AHB buffer prefetch enabled, the QuadSPI may return
> > incorrect data on the AHB interface. The buffer pre-fetch is enabled
> > if the fetch size as configured either in the LUT or in the BUFxCR
> > register is greater than 8 bytes.
> > Impact: Only 64 bit read allowed.
> > Workaround: Keep the read data size to 64 bits (8 Bytes), which
> > disables the prefetch on the AHB buffer, and prevents this issue from
> occurring.
> >
> > Signed-off-by: Yunhui Cui 
> > ---
> >  drivers/mtd/spi-nor/fsl-quadspi.c | 29 +++--
> >  1 file changed, 23 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
> > b/drivers/mtd/spi-nor/fsl- quadspi.c index fea18b6..d9f3e50 100644
> > --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> > +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> > @@ -752,19 +752,36 @@ static void fsl_qspi_init_abh_read(struct
> > fsl_qspi
> > *q)  {
> > void __iomem *base = q->iobase;
> > int seqid;
> > +   const struct fsl_qspi_devtype_data *devtype_data =
> > + q->devtype_data;
> >
> > /* AHB configuration for access buffer 0/1/2 .*/
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF0CR);
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF1CR);
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF2CR);
> > +
> > /*
> > -* Set ADATSZ with the maximum AHB buffer size to improve the
> > -* read performance.
> > +* Errata: A-009282: QuadSPI data prefetch may result in
> > incorrect data
> > +* Workaround: Keep the read data size to 64 bits (8 bytes).
> > +* This disables the prefetch on the AHB buffer and
> > +* prevents this issue from occurring.
> >  */
> > -   qspi_writel(q, QUADSPI_BUF3CR_ALLMST_MASK |
> > -   ((q->devtype_data->ahb_buf_size / 8)
> > -   << QUADSPI_BUF3CR_ADATSZ_SHIFT),
> > -   base + QUADSPI_BUF3CR);
> > +   if (devtype_data->devtype == FSL_QUADSPI_LS2080A ||
> > +   devtype_data->devtype == FSL_QUADSPI_LS1021A) {
> >
> > Use QUIRK, not SoC name.
> [Yunhui] This is a SoC errata, we need distinguish according to the
> devtype_data->devtype
> 
> It's the same thing and we have already done that before.

> [Yunhui] your mean that I should add such as the following code:
#define QUADSPI_QUIRK_ERRATA_9282 (1 << 4)
static inline int has_errata_num_a009282(struct fsl_qspi *q)
{
 return q->devtype_data->driver_data & 
QUADSPI_QUIRK_ERRATA_9282;
}

> /*
>  * TKT253890, Controller needs driver to fill txfifo till 16 byte to
>  * trigger data transfer even though extra data will not transferred.
>  */
> #define QUADSPI_QUIRK_TKT253890 (1 << 2)
> /* Controller cannot wake up from wait mode, TKT245618 */
> #define QUADSPI_QUIRK_TKT245618 (1 << 3)
> 
> 
> > +
> > +   qspi_writel(q, QUADSPI_BUF3CR_ALLMST_MASK |
> > +   (1 << QUADSPI_BUF3CR_ADATSZ_SHIFT),
> > +   base + QUADSPI_BUF3CR);
> > +
> > +   } else {
> > +   /*
> > +* Set ADATSZ with the maximum AHB buffer size to
> > + improve
> > the
> > +* read performance.
> > +   */
> > +   qspi_writel(q, QUADSPI_BUF3CR_ALLMST_MASK |
> > +   ((q->devtype_data->ahb_buf_size / 8)
> > +   

RE: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch

[Yunhui Cui]

> -Original Message-
> From: Han Xu
> Sent: Thursday, April 21, 2016 11:48 PM
> To: Yunhui Cui; Yunhui Cui; dw...@infradead.org;
> computersforpe...@gmail.com; han...@freescale.com
> Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; linux-
> arm-ker...@lists.infradead.org; Yao Yuan
> Subject: Re: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
> 
> 
> 
> 
> From: Yunhui Cui
> Sent: Thursday, April 21, 2016 3:41 AM
> To: Han Xu; Yunhui Cui; dw...@infradead.org; computersforpe...@gmail.com;
> han...@freescale.com
> Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; linux-
> arm-ker...@lists.infradead.org; Yao Yuan
> Subject: RE: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
> 
> On Thu, Apr 24, 2016 at 06:37:01 AM +0800, Han Xu wrote:
> > 
> > From: Yunhui Cui 
> > Sent: Wednesday, April 13, 2016 9:50 PM
> > To: dw...@infradead.org; computersforpe...@gmail.com;
> > han...@freescale.com
> > Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org;
> > linux- arm-ker...@lists.infradead.org; Yao Yuan; Yunhui Cui
> > Subject: [PATCH 8/9] mtd: fsl-quadspi: disable AHB buffer prefetch
> >
> > From: Yunhui Cui 
> >
> > A-009282: QuadSPI: QuadSPI data pre-fetch can result in incorrect data
> > Affects: QuadSPI
> > Description: With AHB buffer prefetch enabled, the QuadSPI may return
> > incorrect data on the AHB interface. The buffer pre-fetch is enabled
> > if the fetch size as configured either in the LUT or in the BUFxCR
> > register is greater than 8 bytes.
> > Impact: Only 64 bit read allowed.
> > Workaround: Keep the read data size to 64 bits (8 Bytes), which
> > disables the prefetch on the AHB buffer, and prevents this issue from
> occurring.
> >
> > Signed-off-by: Yunhui Cui 
> > ---
> >  drivers/mtd/spi-nor/fsl-quadspi.c | 29 +++--
> >  1 file changed, 23 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c
> > b/drivers/mtd/spi-nor/fsl- quadspi.c index fea18b6..d9f3e50 100644
> > --- a/drivers/mtd/spi-nor/fsl-quadspi.c
> > +++ b/drivers/mtd/spi-nor/fsl-quadspi.c
> > @@ -752,19 +752,36 @@ static void fsl_qspi_init_abh_read(struct
> > fsl_qspi
> > *q)  {
> > void __iomem *base = q->iobase;
> > int seqid;
> > +   const struct fsl_qspi_devtype_data *devtype_data =
> > + q->devtype_data;
> >
> > /* AHB configuration for access buffer 0/1/2 .*/
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF0CR);
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF1CR);
> > qspi_writel(q, QUADSPI_BUFXCR_INVALID_MSTRID, base +
> > QUADSPI_BUF2CR);
> > +
> > /*
> > -* Set ADATSZ with the maximum AHB buffer size to improve the
> > -* read performance.
> > +* Errata: A-009282: QuadSPI data prefetch may result in
> > incorrect data
> > +* Workaround: Keep the read data size to 64 bits (8 bytes).
> > +* This disables the prefetch on the AHB buffer and
> > +* prevents this issue from occurring.
> >  */
> > -   qspi_writel(q, QUADSPI_BUF3CR_ALLMST_MASK |
> > -   ((q->devtype_data->ahb_buf_size / 8)
> > -   << QUADSPI_BUF3CR_ADATSZ_SHIFT),
> > -   base + QUADSPI_BUF3CR);
> > +   if (devtype_data->devtype == FSL_QUADSPI_LS2080A ||
> > +   devtype_data->devtype == FSL_QUADSPI_LS1021A) {
> >
> > Use QUIRK, not SoC name.
> [Yunhui] This is a SoC errata, we need distinguish according to the
> devtype_data->devtype
> 
> It's the same thing and we have already done that before.

> [Yunhui] your mean that I should add such as the following code:
#define QUADSPI_QUIRK_ERRATA_9282 (1 << 4)
static inline int has_errata_num_a009282(struct fsl_qspi *q)
{
 return q->devtype_data->driver_data & 
QUADSPI_QUIRK_ERRATA_9282;
}

> /*
>  * TKT253890, Controller needs driver to fill txfifo till 16 byte to
>  * trigger data transfer even though extra data will not transferred.
>  */
> #define QUADSPI_QUIRK_TKT253890 (1 << 2)
> /* Controller cannot wake up from wait mode, TKT245618 */
> #define QUADSPI_QUIRK_TKT245618 (1 << 3)
> 
> 
> > +
> > +   qspi_writel(q, QUADSPI_BUF3CR_ALLMST_MASK |
> > +   (1 << QUADSPI_BUF3CR_ADATSZ_SHIFT),
> > +   base + QUADSPI_BUF3CR);
> > +
> > +   } else {
> > +   /*
> > +* Set ADATSZ with the maximum AHB buffer size to
> > + improve
> > the
> > +* read performance.
> > +   */
> > +   qspi_writel(q, QUADSPI_BUF3CR_ALLMST_MASK |
> > +   ((q->devtype_data->ahb_buf_size / 8)
> > +   << QUADSPI_BUF3CR_ADATSZ_SHIFT),
> > +

Re: [PATCH V4] audit: add tty field to LOGIN event

[Richard Guy Briggs]

On 16/04/21, Paul Moore wrote:
> On Thu, Apr 21, 2016 at 2:14 PM, Richard Guy Briggs  wrote:
> > The tty field was missing from AUDIT_LOGIN events.
> >
> > Refactor code to create a new function audit_get_tty(), using it to
> > replace the call in audit_log_task_info() and to add it to
> > audit_log_set_loginuid().  Lock and bump the kref to protect it, adding
> > audit_put_tty() alias to decrement it.
> >
> > Signed-off-by: Richard Guy Briggs 
> > ---
> >
> > V4: Add missing prototype for audit_put_tty() when audit syscall is not
> > enabled (MIPS).
> >
> > V3: Introduce audit_put_tty() alias to decrement kref.
> >
> > V2: Use kref to protect tty signal struct while in use.
> >
> > ---
> >
> >  include/linux/audit.h |   24 
> >  kernel/audit.c|   18 +-
> >  kernel/auditsc.c  |8 ++--
> >  3 files changed, 35 insertions(+), 15 deletions(-)
> >
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index b40ed5d..32cdafb 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -26,6 +26,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #define AUDIT_INO_UNSET ((unsigned long)-1)
> >  #define AUDIT_DEV_UNSET ((dev_t)-1)
> > @@ -343,6 +344,23 @@ static inline unsigned int audit_get_sessionid(struct 
> > task_struct *tsk)
> > return tsk->sessionid;
> >  }
> >
> > +static inline struct tty_struct *audit_get_tty(struct task_struct *tsk)
> > +{
> > +   struct tty_struct *tty = NULL;
> > +   unsigned long flags;
> > +
> > +   spin_lock_irqsave(>sighand->siglock, flags);
> > +   if (tsk->signal)
> > +   tty = tty_kref_get(tsk->signal->tty);
> > +   spin_unlock_irqrestore(>sighand->siglock, flags);
> > +   return tty;
> > +}
> > +
> > +static inline void audit_put_tty(struct tty_struct *tty)
> > +{
> > +   tty_kref_put(tty);
> > +}
> 
> I'm generally not a big fan of defining functions as inlines in header
> files, with the general exception of dummy functions that will get
> compiled out.  Although I guess there might be some performance
> argument to be made wrt audit_log_task_info().

I did reflect on that initially and decided this was the least
disruptive way to implement it.  There are others similar around it and
when I started it wasn't as involved, but now it is starting to push the
limits with the kref bits...

> I guess I'm fine with this, but what was the idea behind the static
> inlines in audit.h?  Performance, or something else?

Can't say I remember...  I was tempted to put it in as a define, but
decided to stick with the existing style, right?  :-)

> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index 195ffae..71e14d8 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -1980,6 +1980,7 @@ static void audit_log_set_loginuid(kuid_t 
> > koldloginuid, kuid_t kloginuid,
> >  {
> > struct audit_buffer *ab;
> > uid_t uid, oldloginuid, loginuid;
> > +   struct tty_struct *tty;
> >
> > if (!audit_enabled)
> > return;
> > @@ -1987,14 +1988,17 @@ static void audit_log_set_loginuid(kuid_t 
> > koldloginuid, kuid_t kloginuid,
> > uid = from_kuid(_user_ns, task_uid(current));
> > oldloginuid = from_kuid(_user_ns, koldloginuid);
> > loginuid = from_kuid(_user_ns, kloginuid),
> > +   tty = audit_get_tty(current);
> >
> > ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_LOGIN);
> > if (!ab)
> > return;
> > audit_log_format(ab, "pid=%d uid=%u", task_pid_nr(current), uid);
> > audit_log_task_context(ab);
> > -   audit_log_format(ab, " old-auid=%u auid=%u old-ses=%u ses=%u 
> > res=%d",
> > -oldloginuid, loginuid, oldsessionid, sessionid, 
> > !rc);
> > +   audit_log_format(ab, " old-auid=%u auid=%u tty=%s old-ses=%u ses=%u 
> > res=%d",
> > +oldloginuid, loginuid, tty ? tty_name(tty) : 
> > "(none)",
> > +oldsessionid, sessionid, !rc);
> > +   audit_put_tty(tty);
> > audit_log_end(ab);
> >  }
> 
> Because we are still using the crappy fixed string format for
> kernel<->userspace communication, this patch will likely "break the
> world" ... let's check with Steve but I believe the way to handle this
> is to add the tty information to the end of the record.

Well, I did try to put that keyword consistently with where it was
inserted in other messages.  My understanding was that adding an extra
in the middle wouldn't cause a problem because the keyword scanner
looked ahead until it found the keyword it sought.  This way, older
scanners will just hop over this keyword it wasn't seeking.

> paul moore

- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: [PATCH V4] audit: add tty field to LOGIN event

[Richard Guy Briggs]

On 16/04/21, Paul Moore wrote:
> On Thu, Apr 21, 2016 at 2:14 PM, Richard Guy Briggs  wrote:
> > The tty field was missing from AUDIT_LOGIN events.
> >
> > Refactor code to create a new function audit_get_tty(), using it to
> > replace the call in audit_log_task_info() and to add it to
> > audit_log_set_loginuid().  Lock and bump the kref to protect it, adding
> > audit_put_tty() alias to decrement it.
> >
> > Signed-off-by: Richard Guy Briggs 
> > ---
> >
> > V4: Add missing prototype for audit_put_tty() when audit syscall is not
> > enabled (MIPS).
> >
> > V3: Introduce audit_put_tty() alias to decrement kref.
> >
> > V2: Use kref to protect tty signal struct while in use.
> >
> > ---
> >
> >  include/linux/audit.h |   24 
> >  kernel/audit.c|   18 +-
> >  kernel/auditsc.c  |8 ++--
> >  3 files changed, 35 insertions(+), 15 deletions(-)
> >
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index b40ed5d..32cdafb 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -26,6 +26,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #define AUDIT_INO_UNSET ((unsigned long)-1)
> >  #define AUDIT_DEV_UNSET ((dev_t)-1)
> > @@ -343,6 +344,23 @@ static inline unsigned int audit_get_sessionid(struct 
> > task_struct *tsk)
> > return tsk->sessionid;
> >  }
> >
> > +static inline struct tty_struct *audit_get_tty(struct task_struct *tsk)
> > +{
> > +   struct tty_struct *tty = NULL;
> > +   unsigned long flags;
> > +
> > +   spin_lock_irqsave(>sighand->siglock, flags);
> > +   if (tsk->signal)
> > +   tty = tty_kref_get(tsk->signal->tty);
> > +   spin_unlock_irqrestore(>sighand->siglock, flags);
> > +   return tty;
> > +}
> > +
> > +static inline void audit_put_tty(struct tty_struct *tty)
> > +{
> > +   tty_kref_put(tty);
> > +}
> 
> I'm generally not a big fan of defining functions as inlines in header
> files, with the general exception of dummy functions that will get
> compiled out.  Although I guess there might be some performance
> argument to be made wrt audit_log_task_info().

I did reflect on that initially and decided this was the least
disruptive way to implement it.  There are others similar around it and
when I started it wasn't as involved, but now it is starting to push the
limits with the kref bits...

> I guess I'm fine with this, but what was the idea behind the static
> inlines in audit.h?  Performance, or something else?

Can't say I remember...  I was tempted to put it in as a define, but
decided to stick with the existing style, right?  :-)

> > diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> > index 195ffae..71e14d8 100644
> > --- a/kernel/auditsc.c
> > +++ b/kernel/auditsc.c
> > @@ -1980,6 +1980,7 @@ static void audit_log_set_loginuid(kuid_t 
> > koldloginuid, kuid_t kloginuid,
> >  {
> > struct audit_buffer *ab;
> > uid_t uid, oldloginuid, loginuid;
> > +   struct tty_struct *tty;
> >
> > if (!audit_enabled)
> > return;
> > @@ -1987,14 +1988,17 @@ static void audit_log_set_loginuid(kuid_t 
> > koldloginuid, kuid_t kloginuid,
> > uid = from_kuid(_user_ns, task_uid(current));
> > oldloginuid = from_kuid(_user_ns, koldloginuid);
> > loginuid = from_kuid(_user_ns, kloginuid),
> > +   tty = audit_get_tty(current);
> >
> > ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_LOGIN);
> > if (!ab)
> > return;
> > audit_log_format(ab, "pid=%d uid=%u", task_pid_nr(current), uid);
> > audit_log_task_context(ab);
> > -   audit_log_format(ab, " old-auid=%u auid=%u old-ses=%u ses=%u 
> > res=%d",
> > -oldloginuid, loginuid, oldsessionid, sessionid, 
> > !rc);
> > +   audit_log_format(ab, " old-auid=%u auid=%u tty=%s old-ses=%u ses=%u 
> > res=%d",
> > +oldloginuid, loginuid, tty ? tty_name(tty) : 
> > "(none)",
> > +oldsessionid, sessionid, !rc);
> > +   audit_put_tty(tty);
> > audit_log_end(ab);
> >  }
> 
> Because we are still using the crappy fixed string format for
> kernel<->userspace communication, this patch will likely "break the
> world" ... let's check with Steve but I believe the way to handle this
> is to add the tty information to the end of the record.

Well, I did try to put that keyword consistently with where it was
inserted in other messages.  My understanding was that adding an extra
in the middle wouldn't cause a problem because the keyword scanner
looked ahead until it found the keyword it sought.  This way, older
scanners will just hop over this keyword it wasn't seeking.

> paul moore

- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

[PATCH] iio: tmp006: Set correct iio name

[Yong Li]

When load the driver using the below command:
echo tmp006 0x40 > /sys/bus/i2c/devices/i2c-0/new_device

In sysfs, the i2c name is tmp006, however the iio name is 0-0040,
they are inconsistent. With this patch,
the iio name will be the same as the i2c device name

Signed-off-by: Yong Li 
---
 drivers/iio/temperature/tmp006.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/temperature/tmp006.c b/drivers/iio/temperature/tmp006.c
index 18c9b43..17c8413 100644
--- a/drivers/iio/temperature/tmp006.c
+++ b/drivers/iio/temperature/tmp006.c
@@ -221,7 +221,7 @@ static int tmp006_probe(struct i2c_client *client,
data->client = client;
 
indio_dev->dev.parent = >dev;
-   indio_dev->name = dev_name(>dev);
+   indio_dev->name = id->name;
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->info = _info;
 
-- 
2.5.0

[PATCH] iio: tmp006: Set correct iio name

[Yong Li]

When load the driver using the below command:
echo tmp006 0x40 > /sys/bus/i2c/devices/i2c-0/new_device

In sysfs, the i2c name is tmp006, however the iio name is 0-0040,
they are inconsistent. With this patch,
the iio name will be the same as the i2c device name

Signed-off-by: Yong Li 
---
 drivers/iio/temperature/tmp006.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/temperature/tmp006.c b/drivers/iio/temperature/tmp006.c
index 18c9b43..17c8413 100644
--- a/drivers/iio/temperature/tmp006.c
+++ b/drivers/iio/temperature/tmp006.c
@@ -221,7 +221,7 @@ static int tmp006_probe(struct i2c_client *client,
data->client = client;
 
indio_dev->dev.parent = >dev;
-   indio_dev->name = dev_name(>dev);
+   indio_dev->name = id->name;
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->info = _info;
 
-- 
2.5.0

Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

[Peter Chen]

On Fri, Apr 22, 2016 at 09:26:46AM +0800, Peter Chen wrote:
> On Fri, Apr 15, 2016 at 10:03:16AM +, Yoshihiro Shimoda wrote:
> > Hi,
> > 
> > > From: Yoshihiro Shimoda
> > > Sent: Friday, April 15, 2016 6:59 PM
> > > 
> > > Hi,
> > > 
> > > > From: Roger Quadros
> > > > Sent: Thursday, April 14, 2016 8:32 PM
> > > >
> > > > On 14/04/16 14:15, Yoshihiro Shimoda wrote:
> > > > > Hi,
> > > > >
> > > < snip >
> > > > >>> @@ -865,7 +867,8 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, 
> > > > >>> unsigned int irqnum,
> > > > >>>  * we're ready only if we have shared HCD
> > > > >>>  * or we don't need shared HCD.
> > > > >>>  */
> > > > >>> -   if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
> > > > >>> +   if (otg->shared_hcd.hcd || (!otg->caps->needs_companion &&
> > > > >>> +   !otg->primary_hcd.hcd->shared_hcd)) 
> > > > >>> {
> > > > >>> otg->host = hcd_to_bus(hcd);
> > > > >>> /* FIXME: set bus->otg_port if this is true OTG port 
> > > > >>> with HNP */
> > > > >>>
> > > > >>
> > > > >> These changes look good to me. Thanks.
> > > > >
> > > > > Thank you for the comment.
> > > > > If we change the "needs_companion" place to the otg_config,
> > > > > do we need to add a flag into the otg, instead of otg->caps?
> > > >
> > > > Yes we can add a flag in struct usb_otg.
> > > 
> > > Thank you for the comment.
> > > 
> > > I made a fixed patch.
> > > So, should I send this patch to ML after you sent v7 patches?
> > > Or, would you apply this patch before you send v7 patches?
> > 
> > Oops, I sent this email without my patch...
> > 
> > ---
> > Subject: [PATCH] usb: otg: add hcd companion support
> > 
> > Since some host controller (e.g. EHCI) needs a companion host controller
> > (e.g. OHCI), this patch adds such a configuration to use it in the OTG
> > core.
> > 
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >  Documentation/devicetree/bindings/usb/generic.txt |  3 +++
> >  drivers/usb/common/usb-otg.c  | 17 +
> >  include/linux/usb/otg.h   |  7 ++-
> >  3 files changed, 22 insertions(+), 5 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt 
> > b/Documentation/devicetree/bindings/usb/generic.txt
> > index f6866c1..1db1c33 100644
> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > @@ -27,6 +27,9 @@ Optional properties:
> >   - otg-controller: phandle to otg controller. Host or gadget controllers 
> > can
> > contain this property to link it to a particular OTG
> > controller.
> > + - hcd-needs-companion: must be present if otg controller is dealing with
> > +   EHCI host controller that needs a companion OHCI host
> > +   controller.
> >  
> >  This is an attribute to a USB controller such as:
> >  
> > diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> > index 41e762a..83c8c96 100644
> > --- a/drivers/usb/common/usb-otg.c
> > +++ b/drivers/usb/common/usb-otg.c
> > @@ -20,6 +20,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -600,6 +601,10 @@ struct usb_otg *usb_otg_register(struct device *dev,
> > else
> > INIT_WORK(>work, usb_otg_work);
> >  
> > +   if (of_find_property(dev->of_node, "hcd-needs-companion", NULL) ||
> > +   config->hcd_needs_companion)/* needs comanion ? */
> > +   otg->flags |= OTG_FLAG_HCD_NEEDS_COMPANION;
> > +
> > otg->wq = create_singlethread_workqueue("usb_otg");
> > if (!otg->wq) {
> > dev_err(dev, "otg: %s: can't create workqueue\n",
> > @@ -823,13 +828,15 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, 
> > unsigned int irqnum,
> > /* HCD will be started by OTG fsm when needed */
> > mutex_lock(>fsm.lock);
> > if (otg->primary_hcd.hcd) {
> > -   /* probably a shared HCD ? */
> > -   if (usb_otg_hcd_is_primary_hcd(hcd)) {
> > +   /* probably a shared HCD or a companion OHCI HCD ? */
> > +   if (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
> > +   usb_otg_hcd_is_primary_hcd(hcd)) {
> > dev_err(otg_dev, "otg: primary host already 
> > registered\n");
> > goto err;
> > }
> >  
> > -   if (hcd->shared_hcd == otg->primary_hcd.hcd) {
> > +   if (otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION ||
> > +   (hcd->shared_hcd == otg->primary_hcd.hcd)) {
> > if (otg->shared_hcd.hcd) {
> > dev_err(otg_dev, "otg: shared host already 
> > registered\n");
> > goto err;
> > @@ -865,7 +872,9 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned 
> > int irqnum,
> >  * we're ready 

Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

[Peter Chen]

On Fri, Apr 22, 2016 at 09:26:46AM +0800, Peter Chen wrote:
> On Fri, Apr 15, 2016 at 10:03:16AM +, Yoshihiro Shimoda wrote:
> > Hi,
> > 
> > > From: Yoshihiro Shimoda
> > > Sent: Friday, April 15, 2016 6:59 PM
> > > 
> > > Hi,
> > > 
> > > > From: Roger Quadros
> > > > Sent: Thursday, April 14, 2016 8:32 PM
> > > >
> > > > On 14/04/16 14:15, Yoshihiro Shimoda wrote:
> > > > > Hi,
> > > > >
> > > < snip >
> > > > >>> @@ -865,7 +867,8 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, 
> > > > >>> unsigned int irqnum,
> > > > >>>  * we're ready only if we have shared HCD
> > > > >>>  * or we don't need shared HCD.
> > > > >>>  */
> > > > >>> -   if (otg->shared_hcd.hcd || !otg->primary_hcd.hcd->shared_hcd) {
> > > > >>> +   if (otg->shared_hcd.hcd || (!otg->caps->needs_companion &&
> > > > >>> +   !otg->primary_hcd.hcd->shared_hcd)) 
> > > > >>> {
> > > > >>> otg->host = hcd_to_bus(hcd);
> > > > >>> /* FIXME: set bus->otg_port if this is true OTG port 
> > > > >>> with HNP */
> > > > >>>
> > > > >>
> > > > >> These changes look good to me. Thanks.
> > > > >
> > > > > Thank you for the comment.
> > > > > If we change the "needs_companion" place to the otg_config,
> > > > > do we need to add a flag into the otg, instead of otg->caps?
> > > >
> > > > Yes we can add a flag in struct usb_otg.
> > > 
> > > Thank you for the comment.
> > > 
> > > I made a fixed patch.
> > > So, should I send this patch to ML after you sent v7 patches?
> > > Or, would you apply this patch before you send v7 patches?
> > 
> > Oops, I sent this email without my patch...
> > 
> > ---
> > Subject: [PATCH] usb: otg: add hcd companion support
> > 
> > Since some host controller (e.g. EHCI) needs a companion host controller
> > (e.g. OHCI), this patch adds such a configuration to use it in the OTG
> > core.
> > 
> > Signed-off-by: Yoshihiro Shimoda 
> > ---
> >  Documentation/devicetree/bindings/usb/generic.txt |  3 +++
> >  drivers/usb/common/usb-otg.c  | 17 +
> >  include/linux/usb/otg.h   |  7 ++-
> >  3 files changed, 22 insertions(+), 5 deletions(-)
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt 
> > b/Documentation/devicetree/bindings/usb/generic.txt
> > index f6866c1..1db1c33 100644
> > --- a/Documentation/devicetree/bindings/usb/generic.txt
> > +++ b/Documentation/devicetree/bindings/usb/generic.txt
> > @@ -27,6 +27,9 @@ Optional properties:
> >   - otg-controller: phandle to otg controller. Host or gadget controllers 
> > can
> > contain this property to link it to a particular OTG
> > controller.
> > + - hcd-needs-companion: must be present if otg controller is dealing with
> > +   EHCI host controller that needs a companion OHCI host
> > +   controller.
> >  
> >  This is an attribute to a USB controller such as:
> >  
> > diff --git a/drivers/usb/common/usb-otg.c b/drivers/usb/common/usb-otg.c
> > index 41e762a..83c8c96 100644
> > --- a/drivers/usb/common/usb-otg.c
> > +++ b/drivers/usb/common/usb-otg.c
> > @@ -20,6 +20,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -600,6 +601,10 @@ struct usb_otg *usb_otg_register(struct device *dev,
> > else
> > INIT_WORK(>work, usb_otg_work);
> >  
> > +   if (of_find_property(dev->of_node, "hcd-needs-companion", NULL) ||
> > +   config->hcd_needs_companion)/* needs comanion ? */
> > +   otg->flags |= OTG_FLAG_HCD_NEEDS_COMPANION;
> > +
> > otg->wq = create_singlethread_workqueue("usb_otg");
> > if (!otg->wq) {
> > dev_err(dev, "otg: %s: can't create workqueue\n",
> > @@ -823,13 +828,15 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, 
> > unsigned int irqnum,
> > /* HCD will be started by OTG fsm when needed */
> > mutex_lock(>fsm.lock);
> > if (otg->primary_hcd.hcd) {
> > -   /* probably a shared HCD ? */
> > -   if (usb_otg_hcd_is_primary_hcd(hcd)) {
> > +   /* probably a shared HCD or a companion OHCI HCD ? */
> > +   if (!(otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION) &&
> > +   usb_otg_hcd_is_primary_hcd(hcd)) {
> > dev_err(otg_dev, "otg: primary host already 
> > registered\n");
> > goto err;
> > }
> >  
> > -   if (hcd->shared_hcd == otg->primary_hcd.hcd) {
> > +   if (otg->flags & OTG_FLAG_HCD_NEEDS_COMPANION ||
> > +   (hcd->shared_hcd == otg->primary_hcd.hcd)) {
> > if (otg->shared_hcd.hcd) {
> > dev_err(otg_dev, "otg: shared host already 
> > registered\n");
> > goto err;
> > @@ -865,7 +872,9 @@ int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned 
> > int irqnum,
> >  * we're ready only if we have shared HCD
> >  * 

Re: [PATCH] Revert "cpufreq: governor: Fix negative idle_time when configured with CONFIG_HZ_PERIODIC"

[Viresh Kumar]

On 21-04-16, 20:57, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Revert commit 0df35026c6a5 (cpufreq: governor: Fix negative idle_time
> when configured with CONFIG_HZ_PERIODIC) that introduced a regression
> by causing the ondemand cpufreq governor to misbehave for
> CONFIG_TICK_CPU_ACCOUNTING unset (the frequency goes up to the max at
> one point and stays there indefinitely).
> 
> The revert takes subsequent modifications of the code in question into
> account.
> 
> Fixes: 0df35026c6a5 (cpufreq: governor: Fix negative idle_time when 
> configured with CONFIG_HZ_PERIODIC)
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=115261
> Reported-and-tested-by: Timo Valtoaho 
> Cc: 4.5+  # 4.5+
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq_governor.c |8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
> +++ linux-pm/drivers/cpufreq/cpufreq_governor.c
> @@ -146,12 +146,8 @@ unsigned int dbs_update(struct cpufreq_p
>   wall_time = cur_wall_time - j_cdbs->prev_cpu_wall;
>   j_cdbs->prev_cpu_wall = cur_wall_time;
>  
> - if (cur_idle_time <= j_cdbs->prev_cpu_idle) {
> - idle_time = 0;
> - } else {
> - idle_time = cur_idle_time - j_cdbs->prev_cpu_idle;
> - j_cdbs->prev_cpu_idle = cur_idle_time;
> - }
> + idle_time = cur_idle_time - j_cdbs->prev_cpu_idle;
> + j_cdbs->prev_cpu_idle = cur_idle_time;
>  
>   if (ignore_nice) {
>   u64 cur_nice = kcpustat_cpu(j).cpustat[CPUTIME_NICE];

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH] Revert "cpufreq: governor: Fix negative idle_time when configured with CONFIG_HZ_PERIODIC"

[Viresh Kumar]

On 21-04-16, 20:57, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> Revert commit 0df35026c6a5 (cpufreq: governor: Fix negative idle_time
> when configured with CONFIG_HZ_PERIODIC) that introduced a regression
> by causing the ondemand cpufreq governor to misbehave for
> CONFIG_TICK_CPU_ACCOUNTING unset (the frequency goes up to the max at
> one point and stays there indefinitely).
> 
> The revert takes subsequent modifications of the code in question into
> account.
> 
> Fixes: 0df35026c6a5 (cpufreq: governor: Fix negative idle_time when 
> configured with CONFIG_HZ_PERIODIC)
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=115261
> Reported-and-tested-by: Timo Valtoaho 
> Cc: 4.5+  # 4.5+
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq_governor.c |8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
> +++ linux-pm/drivers/cpufreq/cpufreq_governor.c
> @@ -146,12 +146,8 @@ unsigned int dbs_update(struct cpufreq_p
>   wall_time = cur_wall_time - j_cdbs->prev_cpu_wall;
>   j_cdbs->prev_cpu_wall = cur_wall_time;
>  
> - if (cur_idle_time <= j_cdbs->prev_cpu_idle) {
> - idle_time = 0;
> - } else {
> - idle_time = cur_idle_time - j_cdbs->prev_cpu_idle;
> - j_cdbs->prev_cpu_idle = cur_idle_time;
> - }
> + idle_time = cur_idle_time - j_cdbs->prev_cpu_idle;
> + j_cdbs->prev_cpu_idle = cur_idle_time;
>  
>   if (ignore_nice) {
>   u64 cur_nice = kcpustat_cpu(j).cpustat[CPUTIME_NICE];

Acked-by: Viresh Kumar 

-- 
viresh

Re: [PATCH v3 2/6] sched/rtmutex/deadline: Fix a PI crash for deadline tasks

[Xunlei Pang]

Hi Peter,

On 2016/04/20 at 21:49, Xunlei Pang wrote:
> On 2016/04/20 at 21:19, Peter Zijlstra wrote:
>> On Thu, Apr 14, 2016 at 07:37:03PM +0800, Xunlei Pang wrote:
>>> +   /* Updated under pi_lock and rtmutex lock */
>>> struct rb_node *pi_waiters_leftmost;
>>> +   struct rb_node *pi_waiters_leftmost_copy;
>>>  struct task_struct *rt_mutex_get_top_task(struct task_struct *task)
>>>  {
>>> +   if (!task->pi_waiters_leftmost_copy)
>>> return NULL;
>>>  
>>> +   return rb_entry(task->pi_waiters_leftmost_copy,
>>> +   struct rt_mutex_waiter, pi_tree_entry)->task;
>>>  }
>> why ?! Why not keep a regular task_struct pointer and avoid this stuff?
> I meant to make it semantically consistent, but I can change it since you 
> think task_struct is better.

What do you think this version of PATCH1 and PATCH2?
If you are fine with it, I can sent it out as v4 separately, then we can focus 
on the issue in PATCH5.

Thanks!

>
> Regards,
> Xunlei

Re: [PATCH v3 2/6] sched/rtmutex/deadline: Fix a PI crash for deadline tasks

[Xunlei Pang]

Hi Peter,

On 2016/04/20 at 21:49, Xunlei Pang wrote:
> On 2016/04/20 at 21:19, Peter Zijlstra wrote:
>> On Thu, Apr 14, 2016 at 07:37:03PM +0800, Xunlei Pang wrote:
>>> +   /* Updated under pi_lock and rtmutex lock */
>>> struct rb_node *pi_waiters_leftmost;
>>> +   struct rb_node *pi_waiters_leftmost_copy;
>>>  struct task_struct *rt_mutex_get_top_task(struct task_struct *task)
>>>  {
>>> +   if (!task->pi_waiters_leftmost_copy)
>>> return NULL;
>>>  
>>> +   return rb_entry(task->pi_waiters_leftmost_copy,
>>> +   struct rt_mutex_waiter, pi_tree_entry)->task;
>>>  }
>> why ?! Why not keep a regular task_struct pointer and avoid this stuff?
> I meant to make it semantically consistent, but I can change it since you 
> think task_struct is better.

What do you think this version of PATCH1 and PATCH2?
If you are fine with it, I can sent it out as v4 separately, then we can focus 
on the issue in PATCH5.

Thanks!

>
> Regards,
> Xunlei

Re: [PATCH 5/8] cpufreq: shmobile: Use generic platdev driver

[Viresh Kumar]

On 21-04-16, 15:04, Geert Uytterhoeven wrote:
> Hi Viresh,
> 
> On Thu, Apr 21, 2016 at 10:43 AM, Viresh Kumar  
> wrote:
> > --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> > @@ -29,6 +29,18 @@ static const struct of_device_id machines[] = {
> > { .compatible = "samsung,exynos5800", },
> >  #endif
> >
> 
> I think an #ifdef CONFIG_ARCH_RENESAS block wouldn't hurt, likewise
> for the other SoCs.
> Soon you'll have this file filled with lots of compatible values for random\
> SoCs...

This is going to be done once per boot and this shouldn't hurt. And for new
platforms we may do things differently as they are going to use opp-v2 bindings.

And, so I am not really in favor of ifdef hackery :)

-- 
viresh

Re: [PATCH 5/8] cpufreq: shmobile: Use generic platdev driver

[Viresh Kumar]

On 21-04-16, 15:04, Geert Uytterhoeven wrote:
> Hi Viresh,
> 
> On Thu, Apr 21, 2016 at 10:43 AM, Viresh Kumar  
> wrote:
> > --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> > @@ -29,6 +29,18 @@ static const struct of_device_id machines[] = {
> > { .compatible = "samsung,exynos5800", },
> >  #endif
> >
> 
> I think an #ifdef CONFIG_ARCH_RENESAS block wouldn't hurt, likewise
> for the other SoCs.
> Soon you'll have this file filled with lots of compatible values for random\
> SoCs...

This is going to be done once per boot and this shouldn't hurt. And for new
platforms we may do things differently as they are going to use opp-v2 bindings.

And, so I am not really in favor of ifdef hackery :)

-- 
viresh

[PATCH] PM / OPP: -ENOSYS is applicable only to syscalls

[Viresh Kumar]

Some of the routines have use -ENOSYS, which is supposed to be used only
for syscalls. Replace that with -EINVAL.

Signed-off-by: Viresh Kumar 
---
I am including this patch into the series and this one will be the first
patch of the series. Also, later patches will be updated to *not* use
-ENOSYS.

I will send out the series again once some sort of reviews are done.

 include/linux/pm_opp.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index cccaf4a29e9f..2605ed66f1bd 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -199,7 +199,7 @@ static inline void dev_pm_opp_of_remove_table(struct device 
*dev)
 
 static inline int dev_pm_opp_of_cpumask_add_table(cpumask_var_t cpumask)
 {
-   return -ENOSYS;
+   return -EINVAL;
 }
 
 static inline void dev_pm_opp_of_cpumask_remove_table(cpumask_var_t cpumask)
@@ -208,12 +208,12 @@ static inline void 
dev_pm_opp_of_cpumask_remove_table(cpumask_var_t cpumask)
 
 static inline int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, 
cpumask_var_t cpumask)
 {
-   return -ENOSYS;
+   return -EINVAL;
 }
 
 static inline int dev_pm_opp_set_sharing_cpus(struct device *cpu_dev, 
cpumask_var_t cpumask)
 {
-   return -ENOSYS;
+   return -EINVAL;
 }
 #endif
 
-- 
2.7.1.410.g6faf27b

[PATCH] PM / OPP: -ENOSYS is applicable only to syscalls

[Viresh Kumar]

Some of the routines have use -ENOSYS, which is supposed to be used only
for syscalls. Replace that with -EINVAL.

Signed-off-by: Viresh Kumar 
---
I am including this patch into the series and this one will be the first
patch of the series. Also, later patches will be updated to *not* use
-ENOSYS.

I will send out the series again once some sort of reviews are done.

 include/linux/pm_opp.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index cccaf4a29e9f..2605ed66f1bd 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -199,7 +199,7 @@ static inline void dev_pm_opp_of_remove_table(struct device 
*dev)
 
 static inline int dev_pm_opp_of_cpumask_add_table(cpumask_var_t cpumask)
 {
-   return -ENOSYS;
+   return -EINVAL;
 }
 
 static inline void dev_pm_opp_of_cpumask_remove_table(cpumask_var_t cpumask)
@@ -208,12 +208,12 @@ static inline void 
dev_pm_opp_of_cpumask_remove_table(cpumask_var_t cpumask)
 
 static inline int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, 
cpumask_var_t cpumask)
 {
-   return -ENOSYS;
+   return -EINVAL;
 }
 
 static inline int dev_pm_opp_set_sharing_cpus(struct device *cpu_dev, 
cpumask_var_t cpumask)
 {
-   return -ENOSYS;
+   return -EINVAL;
 }
 #endif
 
-- 
2.7.1.410.g6faf27b

Re: [PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16

[Boqun Feng]

On Fri, Apr 22, 2016 at 09:59:22AM +0800, Pan Xinhui wrote:
> On 2016年04月21日 23:52, Boqun Feng wrote:
> > On Thu, Apr 21, 2016 at 11:35:07PM +0800, Pan Xinhui wrote:
> >> On 2016年04月20日 22:24, Peter Zijlstra wrote:
> >>> On Wed, Apr 20, 2016 at 09:24:00PM +0800, Pan Xinhui wrote:
> >>>
>  +#define __XCHG_GEN(cmp, type, sfx, skip, v) 
>  \
>  +static __always_inline unsigned long
>  \
>  +__cmpxchg_u32##sfx(v unsigned int *p, unsigned long old,
>  \
>  + unsigned long new);
>  \
>  +static __always_inline u32  
>  \
>  +__##cmp##xchg_##type##sfx(v void *ptr, u32 old, u32 new)
>  \
>  +{   
>  \
>  +int size = sizeof (type);   
>  \
>  +int off = (unsigned long)ptr % sizeof(u32); 
>  \
>  +volatile u32 *p = ptr - off;
>  \
>  +int bitoff = BITOFF_CAL(size, off); 
>  \
>  +u32 bitmask = ((0x1 << size * BITS_PER_BYTE) - 1) << bitoff;
>  \
>  +u32 oldv, newv, tmp;
>  \
>  +u32 ret;
>  \
>  +oldv = READ_ONCE(*p);   
>  \
>  +do {
>  \
>  +ret = (oldv & bitmask) >> bitoff;   
>  \
>  +if (skip && ret != old) 
>  \
>  +break;  
>  \
>  +newv = (oldv & ~bitmask) | (new << bitoff); 
>  \
>  +tmp = oldv; 
>  \
>  +oldv = __cmpxchg_u32##sfx((v u32*)p, oldv, newv);   
>  \
>  +} while (tmp != oldv);  
>  \
>  +return ret; 
>  \
>  +}
> >>>
> >>> So for an LL/SC based arch using cmpxchg() like that is sub-optimal.
> >>>
> >>> Why did you choose to write it entirely in C?
> >>>
> >> yes, you are right. more load/store will be done in C code.
> >> However such xchg_u8/u16 is just used by qspinlock now. and I did not see 
> >> any performance regression.
> >> So just wrote in C, for simple. :)
> >>
> >> Of course I have done xchg tests.
> >> we run code just like xchg((u8*), j++); in several threads.
> >> and the result is,
> >> [  768.374264] use time[1550072]ns in xchg_u8_asm
> > 
> > How was xchg_u8_asm() implemented, using lbarx or using a 32bit ll/sc
> > loop with shifting and masking in it?
> > 
> yes, using 32bit ll/sc loops.
> 
> looks like:
> __asm__ __volatile__(
> "1: lwarx   %0,0,%3\n"
> "   and %1,%0,%5\n"
> "   or %1,%1,%4\n"
>PPC405_ERR77(0,%2)
> "   stwcx.  %1,0,%3\n"
> "   bne-1b"
> : "=" (_oldv), "=" (tmp), "+m" (*(volatile unsigned int *)_p)
> : "r" (_p), "r" (_newv), "r" (_oldv_mask)
> : "cc", "memory");
> 

Good, so this works for all ppc ISAs too.

Given the performance benefit(maybe caused by the reason Peter
mentioned), I think we should use this as the implementation of u8/u16
{cmp}xchg for now. For Power7 and later, we can always switch to the
lbarx/lharx version if observable performance benefit can be achieved.

But the choice is left to you. After all, as you said, qspinlock is the
only user ;-)

Regards,
Boqun

> 
> > Regards,
> > Boqun
> > 
> >> [  768.377102] use time[2826802]ns in xchg_u8_c
> >>
> >> I think this is because there is one more load in C.
> >> If possible, we can move such code in asm-generic/.
> >>
> >> thanks
> >> xinhui
> >>
> 


signature.asc
Description: PGP signature

Re: [PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16

[Boqun Feng]

On Fri, Apr 22, 2016 at 09:59:22AM +0800, Pan Xinhui wrote:
> On 2016年04月21日 23:52, Boqun Feng wrote:
> > On Thu, Apr 21, 2016 at 11:35:07PM +0800, Pan Xinhui wrote:
> >> On 2016年04月20日 22:24, Peter Zijlstra wrote:
> >>> On Wed, Apr 20, 2016 at 09:24:00PM +0800, Pan Xinhui wrote:
> >>>
>  +#define __XCHG_GEN(cmp, type, sfx, skip, v) 
>  \
>  +static __always_inline unsigned long
>  \
>  +__cmpxchg_u32##sfx(v unsigned int *p, unsigned long old,
>  \
>  + unsigned long new);
>  \
>  +static __always_inline u32  
>  \
>  +__##cmp##xchg_##type##sfx(v void *ptr, u32 old, u32 new)
>  \
>  +{   
>  \
>  +int size = sizeof (type);   
>  \
>  +int off = (unsigned long)ptr % sizeof(u32); 
>  \
>  +volatile u32 *p = ptr - off;
>  \
>  +int bitoff = BITOFF_CAL(size, off); 
>  \
>  +u32 bitmask = ((0x1 << size * BITS_PER_BYTE) - 1) << bitoff;
>  \
>  +u32 oldv, newv, tmp;
>  \
>  +u32 ret;
>  \
>  +oldv = READ_ONCE(*p);   
>  \
>  +do {
>  \
>  +ret = (oldv & bitmask) >> bitoff;   
>  \
>  +if (skip && ret != old) 
>  \
>  +break;  
>  \
>  +newv = (oldv & ~bitmask) | (new << bitoff); 
>  \
>  +tmp = oldv; 
>  \
>  +oldv = __cmpxchg_u32##sfx((v u32*)p, oldv, newv);   
>  \
>  +} while (tmp != oldv);  
>  \
>  +return ret; 
>  \
>  +}
> >>>
> >>> So for an LL/SC based arch using cmpxchg() like that is sub-optimal.
> >>>
> >>> Why did you choose to write it entirely in C?
> >>>
> >> yes, you are right. more load/store will be done in C code.
> >> However such xchg_u8/u16 is just used by qspinlock now. and I did not see 
> >> any performance regression.
> >> So just wrote in C, for simple. :)
> >>
> >> Of course I have done xchg tests.
> >> we run code just like xchg((u8*), j++); in several threads.
> >> and the result is,
> >> [  768.374264] use time[1550072]ns in xchg_u8_asm
> > 
> > How was xchg_u8_asm() implemented, using lbarx or using a 32bit ll/sc
> > loop with shifting and masking in it?
> > 
> yes, using 32bit ll/sc loops.
> 
> looks like:
> __asm__ __volatile__(
> "1: lwarx   %0,0,%3\n"
> "   and %1,%0,%5\n"
> "   or %1,%1,%4\n"
>PPC405_ERR77(0,%2)
> "   stwcx.  %1,0,%3\n"
> "   bne-1b"
> : "=" (_oldv), "=" (tmp), "+m" (*(volatile unsigned int *)_p)
> : "r" (_p), "r" (_newv), "r" (_oldv_mask)
> : "cc", "memory");
> 

Good, so this works for all ppc ISAs too.

Given the performance benefit(maybe caused by the reason Peter
mentioned), I think we should use this as the implementation of u8/u16
{cmp}xchg for now. For Power7 and later, we can always switch to the
lbarx/lharx version if observable performance benefit can be achieved.

But the choice is left to you. After all, as you said, qspinlock is the
only user ;-)

Regards,
Boqun

> 
> > Regards,
> > Boqun
> > 
> >> [  768.377102] use time[2826802]ns in xchg_u8_c
> >>
> >> I think this is because there is one more load in C.
> >> If possible, we can move such code in asm-generic/.
> >>
> >> thanks
> >> xinhui
> >>
> 


signature.asc
Description: PGP signature

Re: [PATCH 1/5] x86, KASLR: Update description for decompressor worst case size

[Baoquan He]

On 04/21/16 at 01:04pm, Kees Cook wrote:
> On Thu, Apr 21, 2016 at 7:47 AM, Borislav Petkov  wrote:
> > On Wed, Apr 20, 2016 at 01:55:42PM -0700, Kees Cook wrote:
> > ...
> > What's "non compressed data overhead"?
> >
> > Does that want to say:
> >
> > "... resulting in 18 bytes overhead of uncompressed data."
> >
> > perhaps?
> 
> Yeah, that reads much more clearly. I'll change it.
> 
> >> +#
> >> +# Files divided into blocks
> >> +# 1 bit (last block flag)
> >> +# 2 bits (block type)
> >> +#
> >> +# 1 block occurs every 32K -1 bytes or when there 50% compression
> >> +# has been achieved. The smallest block type encoding is always used.
> >> +#
> >> +# stored:
> >> +#32 bits length in bytes.
> >> +#
> >> +# fixed:
> >> +#magic fixed tree.
> >> +#symbols.
> >> +#
> >> +# dynamic:
> >> +#dynamic tree encoding.
> >> +#symbols.
> >> +#
> >> +#
> >> +# The buffer for decompression in place is the length of the uncompressed
> >> +# data, plus a small amount extra to keep the algorithm safe. The
> >> +# compressed data is placed at the end of the buffer.  The output pointer
> >> +# is placed at the start of the buffer and the input pointer is placed
> >> +# where the compressed data starts. Problems will occur when the output
> >> +# pointer overruns the input pointer.
> >> +#
> >> +# The output pointer can only overrun the input pointer if the input
> >> +# pointer is moving faster than the output pointer.  A condition only
> >> +# triggered by data whose compressed form is larger than the uncompressed
> >> +# form.
> >> +#
> >> +# The worst case at the block level is a growth of the compressed data
> >> +# of 5 bytes per 32767 bytes.
> >> +#
> >> +# The worst case internal to a compressed block is very hard to figure.
> >> +# The worst case can at least be bounded by having one bit that represents
> >> +# 32764 bytes and then all of the rest of the bytes representing the very
> >> +# very last byte.
> >> +#
> >> +# All of which is enough to compute an amount of extra data that is 
> >> required
> >> +# to be safe.  To avoid problems at the block level allocating 5 extra 
> >> bytes
> >> +# per 32767 bytes of data is sufficient.  To avoid problems internal to a
> >> +# block adding an extra 32767 bytes (the worst case uncompressed block 
> >> size)
> >> +# is sufficient, to ensure that in the worst case the decompressed data 
> >> for
> >> +# block will stop the byte before the compressed data for a block begins.
> >> +# To avoid problems with the compressed data's meta information an extra 
> >> 18
> >> +# bytes are needed.  Leading to the formula:
> >> +#
> >> +# extra_bytes = (uncompressed_size >> 12) + 32768 + 18 + decompressor_size
> >> +#
> >> +# Adding 8 bytes per 32K is a bit excessive but much easier to calculate.
> >> +# Adding 32768 instead of 32767 just makes for round numbers.
> >> +# Adding the decompressor_size is necessary as it musht live after all
> >> +# of the data as well.  Last I measured the decompressor is about 14K.
> >> +# 10K of actual data and 4K of bss.
> >
> > I guess reflow the paragraphs while at it, as well?
> >
> > "Adding 8 bytes per 32K is a bit excessive but much easier to calculate.
> > Adding 32768 instead of 32767 just makes for round numbers. Adding the
> > decompressor_size is necessary as it musht live after all of the data as
   ~~must
There's a typo here, it should be 'must'. I didn't notice before. It
might be fixed when take Boris's paragraph reflowing. :)

> > well. Last I measured the decompressor is about 14K. 10K of actual data
> > and 4K of bss."
> >
> > and so on...
> 
> Yeah, I'd been reflowing as I went and I went back and forth on that
> one. It looked like it was a list ("Adding... Adding... Adding...") so
> I'd left it, but my initial instinct matches your: it should just get
> reflowed like all the rest.
> 
> I'll fix that too.
> 
> Thanks for the review!
> 
> -Kees
> 
> -- 
> Kees Cook
> Chrome OS & Brillo Security

Re: [PATCH 1/5] x86, KASLR: Update description for decompressor worst case size

[Baoquan He]

On 04/21/16 at 01:04pm, Kees Cook wrote:
> On Thu, Apr 21, 2016 at 7:47 AM, Borislav Petkov  wrote:
> > On Wed, Apr 20, 2016 at 01:55:42PM -0700, Kees Cook wrote:
> > ...
> > What's "non compressed data overhead"?
> >
> > Does that want to say:
> >
> > "... resulting in 18 bytes overhead of uncompressed data."
> >
> > perhaps?
> 
> Yeah, that reads much more clearly. I'll change it.
> 
> >> +#
> >> +# Files divided into blocks
> >> +# 1 bit (last block flag)
> >> +# 2 bits (block type)
> >> +#
> >> +# 1 block occurs every 32K -1 bytes or when there 50% compression
> >> +# has been achieved. The smallest block type encoding is always used.
> >> +#
> >> +# stored:
> >> +#32 bits length in bytes.
> >> +#
> >> +# fixed:
> >> +#magic fixed tree.
> >> +#symbols.
> >> +#
> >> +# dynamic:
> >> +#dynamic tree encoding.
> >> +#symbols.
> >> +#
> >> +#
> >> +# The buffer for decompression in place is the length of the uncompressed
> >> +# data, plus a small amount extra to keep the algorithm safe. The
> >> +# compressed data is placed at the end of the buffer.  The output pointer
> >> +# is placed at the start of the buffer and the input pointer is placed
> >> +# where the compressed data starts. Problems will occur when the output
> >> +# pointer overruns the input pointer.
> >> +#
> >> +# The output pointer can only overrun the input pointer if the input
> >> +# pointer is moving faster than the output pointer.  A condition only
> >> +# triggered by data whose compressed form is larger than the uncompressed
> >> +# form.
> >> +#
> >> +# The worst case at the block level is a growth of the compressed data
> >> +# of 5 bytes per 32767 bytes.
> >> +#
> >> +# The worst case internal to a compressed block is very hard to figure.
> >> +# The worst case can at least be bounded by having one bit that represents
> >> +# 32764 bytes and then all of the rest of the bytes representing the very
> >> +# very last byte.
> >> +#
> >> +# All of which is enough to compute an amount of extra data that is 
> >> required
> >> +# to be safe.  To avoid problems at the block level allocating 5 extra 
> >> bytes
> >> +# per 32767 bytes of data is sufficient.  To avoid problems internal to a
> >> +# block adding an extra 32767 bytes (the worst case uncompressed block 
> >> size)
> >> +# is sufficient, to ensure that in the worst case the decompressed data 
> >> for
> >> +# block will stop the byte before the compressed data for a block begins.
> >> +# To avoid problems with the compressed data's meta information an extra 
> >> 18
> >> +# bytes are needed.  Leading to the formula:
> >> +#
> >> +# extra_bytes = (uncompressed_size >> 12) + 32768 + 18 + decompressor_size
> >> +#
> >> +# Adding 8 bytes per 32K is a bit excessive but much easier to calculate.
> >> +# Adding 32768 instead of 32767 just makes for round numbers.
> >> +# Adding the decompressor_size is necessary as it musht live after all
> >> +# of the data as well.  Last I measured the decompressor is about 14K.
> >> +# 10K of actual data and 4K of bss.
> >
> > I guess reflow the paragraphs while at it, as well?
> >
> > "Adding 8 bytes per 32K is a bit excessive but much easier to calculate.
> > Adding 32768 instead of 32767 just makes for round numbers. Adding the
> > decompressor_size is necessary as it musht live after all of the data as
   ~~must
There's a typo here, it should be 'must'. I didn't notice before. It
might be fixed when take Boris's paragraph reflowing. :)

> > well. Last I measured the decompressor is about 14K. 10K of actual data
> > and 4K of bss."
> >
> > and so on...
> 
> Yeah, I'd been reflowing as I went and I went back and forth on that
> one. It looked like it was a list ("Adding... Adding... Adding...") so
> I'd left it, but my initial instinct matches your: it should just get
> reflowed like all the rest.
> 
> I'll fix that too.
> 
> Thanks for the review!
> 
> -Kees
> 
> -- 
> Kees Cook
> Chrome OS & Brillo Security

Re: [RFC][PATCH 0/6] /dev/random - a new approach

[Theodore Ts'o]

I still have a massive problem with the claims that the "Jitter" RNG
provides any amount of entropy.  Just because you and I might not be
able to analyze it doesn't mean that somebody else couldn't.  After
all, DUAL-EC DRNG was very complicated and hard to analyze.  So would
be something like

   AES(NSA_KEY, COUNTER++)

Very hard to analyze indeed.  Shall we run statistical tests?  They'll
pass with flying colors.

Secure?  Not so much.

- Ted

Re: [RFC][PATCH 0/6] /dev/random - a new approach

[Theodore Ts'o]

I still have a massive problem with the claims that the "Jitter" RNG
provides any amount of entropy.  Just because you and I might not be
able to analyze it doesn't mean that somebody else couldn't.  After
all, DUAL-EC DRNG was very complicated and hard to analyze.  So would
be something like

   AES(NSA_KEY, COUNTER++)

Very hard to analyze indeed.  Shall we run statistical tests?  They'll
pass with flying colors.

Secure?  Not so much.

- Ted

Re: [PATCH v2 all 00/14] use of_platform_default_populate() to populate default bus

[Kefeng Wang]

On 2016/4/21 21:10, Rob Herring wrote:
> On Thu, Apr 21, 2016 at 2:55 AM, Kefeng Wang  
> wrote:
>> Hi Rob,
>>
>> On 2016/4/20 5:10, Rob Herring wrote:
>>> On Wed, Mar 16, 2016 at 2:35 AM, Kefeng Wang  
>>> wrote:
 Use helper of_platform_default_populate() in linux/of_platform
 when possible, instead of calling of_platform_populate() with
 the default match table.

 Then it is possible for driver code build as a module, and no
 need to export of_default_bus_match_table anymore.

 This patchset is based on Linux 4.5.

 Changes since v1:
 - Add ack, test and review
 - Remove v1 patch 14/15, the similar patch has posted and applied,
   see https://patchwork.kernel.org/patch/8096991/

 v1:
 - https://lkml.org/lkml/2016/1/26/1123
>>>
>>> I was going to apply this, but I've thought about this some more and
>>> it is a lot of tree wide churn for little gain. Most of the call sites
>>> here I want to get rid of by making of_platform_populate callable
>>> multiple times. The infrastructure is almost there, but I think we
>>> just need something like this:
>>>
>>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>>> index 8d103e4..b25e710 100644
>>> --- a/drivers/of/platform.c
>>> +++ b/drivers/of/platform.c
>>> @@ -345,6 +345,9 @@ static int of_platform_bus_create(struct device_node 
>>> *bus,
>>> return 0;
>>> }
>>>
>>> +   if (of_node_check_flag(bus, OF_POPULATED_BUS))
>>> +   return 0;
>>> +
>>> auxdata = of_dev_lookup(lookup, bus);
>>> if (auxdata) {
>>> bus_id = auxdata->name;
>>>
>>> Then we can call of_platform_populate from the DT core and remove all
>>> the default calls.
>>
>> OK, it seems that we can drop all the of_of_platform_default_populate in 
>> arch code
>> by this changes, will do it.
>>
>> But replace of_platform_populate() with the default match table by 
>> of_platform_default_populate
>> is a cleanup, and especially for the driver, we can not need export 
>> of_default_bus_match_table
>> after that.
>>
>> There is a v3 patchset[1], it is based 4.6-rc2 with some updated, should 
>> this be merge firstly,
>> then drop all the default of_platform_populate in arch code, and I think the 
>> of_iommu_init() in
>> arch code could do the same thing.
>>
>> If not, I will repost the patches with new ways, but still exists the part 
>> of unexport
>> of_default_bus_match_table by helper of_platform_default_populate().
>>
>> Hope the v3 patchset could be merge in advance, after all, it has been 
>> reviewed fully. Thanks a lot.
> 
> We'd be touching the same line twice in a bunch of places if we apply
> this series first, so it makes more sense to remove all these calls
> first and then use of_platform_default_populate where it is still
> needed.

Agree, will repost them.

BRs,
Kefeng

> 
> Rob
> 
> .
> 

Re: [PATCH v2 all 00/14] use of_platform_default_populate() to populate default bus

[Kefeng Wang]

On 2016/4/21 21:10, Rob Herring wrote:
> On Thu, Apr 21, 2016 at 2:55 AM, Kefeng Wang  
> wrote:
>> Hi Rob,
>>
>> On 2016/4/20 5:10, Rob Herring wrote:
>>> On Wed, Mar 16, 2016 at 2:35 AM, Kefeng Wang  
>>> wrote:
 Use helper of_platform_default_populate() in linux/of_platform
 when possible, instead of calling of_platform_populate() with
 the default match table.

 Then it is possible for driver code build as a module, and no
 need to export of_default_bus_match_table anymore.

 This patchset is based on Linux 4.5.

 Changes since v1:
 - Add ack, test and review
 - Remove v1 patch 14/15, the similar patch has posted and applied,
   see https://patchwork.kernel.org/patch/8096991/

 v1:
 - https://lkml.org/lkml/2016/1/26/1123
>>>
>>> I was going to apply this, but I've thought about this some more and
>>> it is a lot of tree wide churn for little gain. Most of the call sites
>>> here I want to get rid of by making of_platform_populate callable
>>> multiple times. The infrastructure is almost there, but I think we
>>> just need something like this:
>>>
>>> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
>>> index 8d103e4..b25e710 100644
>>> --- a/drivers/of/platform.c
>>> +++ b/drivers/of/platform.c
>>> @@ -345,6 +345,9 @@ static int of_platform_bus_create(struct device_node 
>>> *bus,
>>> return 0;
>>> }
>>>
>>> +   if (of_node_check_flag(bus, OF_POPULATED_BUS))
>>> +   return 0;
>>> +
>>> auxdata = of_dev_lookup(lookup, bus);
>>> if (auxdata) {
>>> bus_id = auxdata->name;
>>>
>>> Then we can call of_platform_populate from the DT core and remove all
>>> the default calls.
>>
>> OK, it seems that we can drop all the of_of_platform_default_populate in 
>> arch code
>> by this changes, will do it.
>>
>> But replace of_platform_populate() with the default match table by 
>> of_platform_default_populate
>> is a cleanup, and especially for the driver, we can not need export 
>> of_default_bus_match_table
>> after that.
>>
>> There is a v3 patchset[1], it is based 4.6-rc2 with some updated, should 
>> this be merge firstly,
>> then drop all the default of_platform_populate in arch code, and I think the 
>> of_iommu_init() in
>> arch code could do the same thing.
>>
>> If not, I will repost the patches with new ways, but still exists the part 
>> of unexport
>> of_default_bus_match_table by helper of_platform_default_populate().
>>
>> Hope the v3 patchset could be merge in advance, after all, it has been 
>> reviewed fully. Thanks a lot.
> 
> We'd be touching the same line twice in a bunch of places if we apply
> this series first, so it makes more sense to remove all these calls
> first and then use of_platform_default_populate where it is still
> needed.

Agree, will repost them.

BRs,
Kefeng

> 
> Rob
> 
> .
> 

Re: [RFC][PATCH 2/4] tracing: Use pid bitmap instead of a pid array for set_event_pid

[Namhyung Kim]

Hi Steve,

On Tue, Apr 19, 2016 at 10:34:23AM -0400, Steven Rostedt wrote:
> From: Steven Rostedt 
> 
> In order to add the ability to let tasks that are filtered by the events
> have their children also be traced on fork (and then not traced on exit),
> convert the array into a pid bitmask. Most of the time the number of pids is
> only 32768 pids or a 4k bitmask, which is the same size as the default list
> currently is, and that list could grow if more pids are listed.
> 
> This also greatly simplifies the code.
> 
> Suggested-by: "H. Peter Anvin" 
> Signed-off-by: Steven Rostedt 
> ---

[SNIP]
> @@ -1571,7 +1572,7 @@ ftrace_event_pid_write(struct file *filp, const char 
> __user *ubuf,
>   struct seq_file *m = filp->private_data;
>   struct trace_array *tr = m->private;
>   struct trace_pid_list *filtered_pids = NULL;
> - struct trace_pid_list *pid_list = NULL;
> + struct trace_pid_list *pid_list;
>   struct trace_event_file *file;
>   struct trace_parser parser;
>   unsigned long val;
> @@ -1579,7 +1580,7 @@ ftrace_event_pid_write(struct file *filp, const char 
> __user *ubuf,
>   ssize_t read = 0;
>   ssize_t ret = 0;
>   pid_t pid;
> - int i;
> + int nr_pids = 0;
>  
>   if (!cnt)
>   return 0;
> @@ -1592,10 +1593,43 @@ ftrace_event_pid_write(struct file *filp, const char 
> __user *ubuf,
>   return -ENOMEM;
>  
>   mutex_lock(_mutex);
> + filtered_pids = rcu_dereference_protected(tr->filtered_pids,
> +  lockdep_is_held(_mutex));
> +
>   /*
> -  * Load as many pids into the array before doing a
> -  * swap from the tr->filtered_pids to the new list.
> +  * Always recreate a new array. The write is an all or nothing
> +  * operation. Always create a new array when adding new pids by
> +  * the user. If the operation fails, then the current list is
> +  * not modified.
>*/
> + pid_list = kmalloc(sizeof(*pid_list), GFP_KERNEL);
> + if (!pid_list) {
> + read = -ENOMEM;
> + goto out;
> + }
> + pid_list->pid_max = READ_ONCE(pid_max);
> + /* Only truncating will shrink pid_max */
> + if (filtered_pids && filtered_pids->pid_max > pid_list->pid_max)
> + pid_list->pid_max = filtered_pids->pid_max;
> + pid_list->pids = vzalloc((pid_list->pid_max + 7) >> 3);
> + if (!pid_list->pids) {
> + kfree(pid_list);
> + read = -ENOMEM;
> + goto out;
> + }
> + if (filtered_pids) {
> + /* copy the current bits to the new max */
> + pid = find_first_bit(filtered_pids->pids,
> +  filtered_pids->pid_max);
> + while (pid < filtered_pids->pid_max) {
> + set_bit(pid, pid_list->pids);
> + pid = find_next_bit(filtered_pids->pids,
> + filtered_pids->pid_max,
> + pid + 1);
> + nr_pids++;
> + }

Why not just use memcpy and keep nr_pids in the pid_list?

Thanks,
Namhyung



> + }
> +
>   while (cnt > 0) {
>  
>   this_pos = 0;
> @@ -1613,92 +1647,35 @@ ftrace_event_pid_write(struct file *filp, const char 
> __user *ubuf,
>   ret = -EINVAL;
>   if (kstrtoul(parser.buffer, 0, ))
>   break;
> - if (val > INT_MAX)
> + if (val >= pid_list->pid_max)
>   break;
>  
>   pid = (pid_t)val;
>  
> - ret = -ENOMEM;
> - if (!pid_list) {
> - pid_list = kmalloc(sizeof(*pid_list), GFP_KERNEL);
> - if (!pid_list)
> - break;
> -
> - filtered_pids = 
> rcu_dereference_protected(tr->filtered_pids,
> - 
> lockdep_is_held(_mutex));
> - if (filtered_pids)
> - pid_list->order = filtered_pids->order;
> - else
> - pid_list->order = 0;
> -
> - pid_list->pids = (void *)__get_free_pages(GFP_KERNEL,
> -   
> pid_list->order);
> - if (!pid_list->pids)
> - break;
> -
> - if (filtered_pids) {
> - pid_list->nr_pids = filtered_pids->nr_pids;
> - memcpy(pid_list->pids, filtered_pids->pids,
> -pid_list->nr_pids * sizeof(pid_t));
> - } else
> - pid_list->nr_pids = 0;
> - }
> -
> - if (pid_list->nr_pids >= max_pids(pid_list)) {
> - 

Re: [RFC][PATCH 2/4] tracing: Use pid bitmap instead of a pid array for set_event_pid

[Namhyung Kim]

Hi Steve,

On Tue, Apr 19, 2016 at 10:34:23AM -0400, Steven Rostedt wrote:
> From: Steven Rostedt 
> 
> In order to add the ability to let tasks that are filtered by the events
> have their children also be traced on fork (and then not traced on exit),
> convert the array into a pid bitmask. Most of the time the number of pids is
> only 32768 pids or a 4k bitmask, which is the same size as the default list
> currently is, and that list could grow if more pids are listed.
> 
> This also greatly simplifies the code.
> 
> Suggested-by: "H. Peter Anvin" 
> Signed-off-by: Steven Rostedt 
> ---

[SNIP]
> @@ -1571,7 +1572,7 @@ ftrace_event_pid_write(struct file *filp, const char 
> __user *ubuf,
>   struct seq_file *m = filp->private_data;
>   struct trace_array *tr = m->private;
>   struct trace_pid_list *filtered_pids = NULL;
> - struct trace_pid_list *pid_list = NULL;
> + struct trace_pid_list *pid_list;
>   struct trace_event_file *file;
>   struct trace_parser parser;
>   unsigned long val;
> @@ -1579,7 +1580,7 @@ ftrace_event_pid_write(struct file *filp, const char 
> __user *ubuf,
>   ssize_t read = 0;
>   ssize_t ret = 0;
>   pid_t pid;
> - int i;
> + int nr_pids = 0;
>  
>   if (!cnt)
>   return 0;
> @@ -1592,10 +1593,43 @@ ftrace_event_pid_write(struct file *filp, const char 
> __user *ubuf,
>   return -ENOMEM;
>  
>   mutex_lock(_mutex);
> + filtered_pids = rcu_dereference_protected(tr->filtered_pids,
> +  lockdep_is_held(_mutex));
> +
>   /*
> -  * Load as many pids into the array before doing a
> -  * swap from the tr->filtered_pids to the new list.
> +  * Always recreate a new array. The write is an all or nothing
> +  * operation. Always create a new array when adding new pids by
> +  * the user. If the operation fails, then the current list is
> +  * not modified.
>*/
> + pid_list = kmalloc(sizeof(*pid_list), GFP_KERNEL);
> + if (!pid_list) {
> + read = -ENOMEM;
> + goto out;
> + }
> + pid_list->pid_max = READ_ONCE(pid_max);
> + /* Only truncating will shrink pid_max */
> + if (filtered_pids && filtered_pids->pid_max > pid_list->pid_max)
> + pid_list->pid_max = filtered_pids->pid_max;
> + pid_list->pids = vzalloc((pid_list->pid_max + 7) >> 3);
> + if (!pid_list->pids) {
> + kfree(pid_list);
> + read = -ENOMEM;
> + goto out;
> + }
> + if (filtered_pids) {
> + /* copy the current bits to the new max */
> + pid = find_first_bit(filtered_pids->pids,
> +  filtered_pids->pid_max);
> + while (pid < filtered_pids->pid_max) {
> + set_bit(pid, pid_list->pids);
> + pid = find_next_bit(filtered_pids->pids,
> + filtered_pids->pid_max,
> + pid + 1);
> + nr_pids++;
> + }

Why not just use memcpy and keep nr_pids in the pid_list?

Thanks,
Namhyung



> + }
> +
>   while (cnt > 0) {
>  
>   this_pos = 0;
> @@ -1613,92 +1647,35 @@ ftrace_event_pid_write(struct file *filp, const char 
> __user *ubuf,
>   ret = -EINVAL;
>   if (kstrtoul(parser.buffer, 0, ))
>   break;
> - if (val > INT_MAX)
> + if (val >= pid_list->pid_max)
>   break;
>  
>   pid = (pid_t)val;
>  
> - ret = -ENOMEM;
> - if (!pid_list) {
> - pid_list = kmalloc(sizeof(*pid_list), GFP_KERNEL);
> - if (!pid_list)
> - break;
> -
> - filtered_pids = 
> rcu_dereference_protected(tr->filtered_pids,
> - 
> lockdep_is_held(_mutex));
> - if (filtered_pids)
> - pid_list->order = filtered_pids->order;
> - else
> - pid_list->order = 0;
> -
> - pid_list->pids = (void *)__get_free_pages(GFP_KERNEL,
> -   
> pid_list->order);
> - if (!pid_list->pids)
> - break;
> -
> - if (filtered_pids) {
> - pid_list->nr_pids = filtered_pids->nr_pids;
> - memcpy(pid_list->pids, filtered_pids->pids,
> -pid_list->nr_pids * sizeof(pid_t));
> - } else
> - pid_list->nr_pids = 0;
> - }
> -
> - if (pid_list->nr_pids >= max_pids(pid_list)) {
> - pid_t *pid_page;
> -
> - pid_page = 

Re: [PATCH V3 05/11] staging: mt29f_spinand: set ECC algorithm explicitly

[Greg Kroah-Hartman]

On Thu, Apr 21, 2016 at 10:20:56PM +0200, Boris Brezillon wrote:
> Hi Greg,
> 
> On Sun, 17 Apr 2016 22:53:01 +0200
> Rafał Miłecki  wrote:
> 
> > This is part of process deprecating NAND_ECC_SOFT_BCH (and switching to
> > enum nand_ecc_algo).
> 
> Do you mind if I take this patch through the NAND tree in order to avoid
> dependency problems?

Not at all:
Acked-by: Greg Kroah-Hartman 

Re: [PATCH V3 05/11] staging: mt29f_spinand: set ECC algorithm explicitly

[Greg Kroah-Hartman]

On Thu, Apr 21, 2016 at 10:20:56PM +0200, Boris Brezillon wrote:
> Hi Greg,
> 
> On Sun, 17 Apr 2016 22:53:01 +0200
> Rafał Miłecki  wrote:
> 
> > This is part of process deprecating NAND_ECC_SOFT_BCH (and switching to
> > enum nand_ecc_algo).
> 
> Do you mind if I take this patch through the NAND tree in order to avoid
> dependency problems?

Not at all:
Acked-by: Greg Kroah-Hartman 

linux-next: build failure after merge of the sound-asoc tree

[Stephen Rothwell]

Hi all,

After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/notifier.h:13:0,
 from include/linux/memory_hotplug.h:6,
 from include/linux/mmzone.h:744,
 from include/linux/gfp.h:5,
 from include/linux/kmod.h:22,
 from include/linux/module.h:13,
 from sound/soc/codecs/hdmi-codec.c:15:
sound/soc/codecs/hdmi-codec.c: In function 'hdmi_eld_ctl_get':
sound/soc/codecs/hdmi-codec.c:68:17: error: 'struct hdmi_codec_priv' has no 
member named 'eld_lock'
  mutex_lock(>eld_lock);
 ^
include/linux/mutex.h:146:44: note: in definition of macro 'mutex_lock'
 #define mutex_lock(lock) mutex_lock_nested(lock, 0)
^
sound/soc/codecs/hdmi-codec.c:70:19: error: 'struct hdmi_codec_priv' has no 
member named 'eld_lock'
  mutex_unlock(>eld_lock);
   ^

Caused by commit

  81151cfb6bfe ("ASoC: hdmi-codec: Add ELD control")

I have used the sound-asoc tree from next-20160421 for today.

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the sound-asoc tree

[Stephen Rothwell]

Hi all,

After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from include/linux/notifier.h:13:0,
 from include/linux/memory_hotplug.h:6,
 from include/linux/mmzone.h:744,
 from include/linux/gfp.h:5,
 from include/linux/kmod.h:22,
 from include/linux/module.h:13,
 from sound/soc/codecs/hdmi-codec.c:15:
sound/soc/codecs/hdmi-codec.c: In function 'hdmi_eld_ctl_get':
sound/soc/codecs/hdmi-codec.c:68:17: error: 'struct hdmi_codec_priv' has no 
member named 'eld_lock'
  mutex_lock(>eld_lock);
 ^
include/linux/mutex.h:146:44: note: in definition of macro 'mutex_lock'
 #define mutex_lock(lock) mutex_lock_nested(lock, 0)
^
sound/soc/codecs/hdmi-codec.c:70:19: error: 'struct hdmi_codec_priv' has no 
member named 'eld_lock'
  mutex_unlock(>eld_lock);
   ^

Caused by commit

  81151cfb6bfe ("ASoC: hdmi-codec: Add ELD control")

I have used the sound-asoc tree from next-20160421 for today.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16

[Pan Xinhui]

On 2016年04月21日 23:52, Boqun Feng wrote:
> On Thu, Apr 21, 2016 at 11:35:07PM +0800, Pan Xinhui wrote:
>> On 2016年04月20日 22:24, Peter Zijlstra wrote:
>>> On Wed, Apr 20, 2016 at 09:24:00PM +0800, Pan Xinhui wrote:
>>>
 +#define __XCHG_GEN(cmp, type, sfx, skip, v)   
 \
 +static __always_inline unsigned long  
 \
 +__cmpxchg_u32##sfx(v unsigned int *p, unsigned long old,  \
 +   unsigned long new);\
 +static __always_inline u32
 \
 +__##cmp##xchg_##type##sfx(v void *ptr, u32 old, u32 new)  \
 +{ \
 +  int size = sizeof (type);   \
 +  int off = (unsigned long)ptr % sizeof(u32); \
 +  volatile u32 *p = ptr - off;\
 +  int bitoff = BITOFF_CAL(size, off); \
 +  u32 bitmask = ((0x1 << size * BITS_PER_BYTE) - 1) << bitoff;\
 +  u32 oldv, newv, tmp;\
 +  u32 ret;\
 +  oldv = READ_ONCE(*p);   \
 +  do {\
 +  ret = (oldv & bitmask) >> bitoff;   \
 +  if (skip && ret != old) \
 +  break;  \
 +  newv = (oldv & ~bitmask) | (new << bitoff); \
 +  tmp = oldv; \
 +  oldv = __cmpxchg_u32##sfx((v u32*)p, oldv, newv);   \
 +  } while (tmp != oldv);  \
 +  return ret; \
 +}
>>>
>>> So for an LL/SC based arch using cmpxchg() like that is sub-optimal.
>>>
>>> Why did you choose to write it entirely in C?
>>>
>> yes, you are right. more load/store will be done in C code.
>> However such xchg_u8/u16 is just used by qspinlock now. and I did not see 
>> any performance regression.
>> So just wrote in C, for simple. :)
>>
>> Of course I have done xchg tests.
>> we run code just like xchg((u8*), j++); in several threads.
>> and the result is,
>> [  768.374264] use time[1550072]ns in xchg_u8_asm
> 
> How was xchg_u8_asm() implemented, using lbarx or using a 32bit ll/sc
> loop with shifting and masking in it?
> 
yes, using 32bit ll/sc loops.

looks like:
__asm__ __volatile__(
"1: lwarx   %0,0,%3\n"
"   and %1,%0,%5\n"
"   or %1,%1,%4\n"
   PPC405_ERR77(0,%2)
"   stwcx.  %1,0,%3\n"
"   bne-1b"
: "=" (_oldv), "=" (tmp), "+m" (*(volatile unsigned int *)_p)
: "r" (_p), "r" (_newv), "r" (_oldv_mask)
: "cc", "memory");


> Regards,
> Boqun
> 
>> [  768.377102] use time[2826802]ns in xchg_u8_c
>>
>> I think this is because there is one more load in C.
>> If possible, we can move such code in asm-generic/.
>>
>> thanks
>> xinhui
>>

Re: [PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16

[Pan Xinhui]

On 2016年04月21日 23:52, Boqun Feng wrote:
> On Thu, Apr 21, 2016 at 11:35:07PM +0800, Pan Xinhui wrote:
>> On 2016年04月20日 22:24, Peter Zijlstra wrote:
>>> On Wed, Apr 20, 2016 at 09:24:00PM +0800, Pan Xinhui wrote:
>>>
 +#define __XCHG_GEN(cmp, type, sfx, skip, v)   
 \
 +static __always_inline unsigned long  
 \
 +__cmpxchg_u32##sfx(v unsigned int *p, unsigned long old,  \
 +   unsigned long new);\
 +static __always_inline u32
 \
 +__##cmp##xchg_##type##sfx(v void *ptr, u32 old, u32 new)  \
 +{ \
 +  int size = sizeof (type);   \
 +  int off = (unsigned long)ptr % sizeof(u32); \
 +  volatile u32 *p = ptr - off;\
 +  int bitoff = BITOFF_CAL(size, off); \
 +  u32 bitmask = ((0x1 << size * BITS_PER_BYTE) - 1) << bitoff;\
 +  u32 oldv, newv, tmp;\
 +  u32 ret;\
 +  oldv = READ_ONCE(*p);   \
 +  do {\
 +  ret = (oldv & bitmask) >> bitoff;   \
 +  if (skip && ret != old) \
 +  break;  \
 +  newv = (oldv & ~bitmask) | (new << bitoff); \
 +  tmp = oldv; \
 +  oldv = __cmpxchg_u32##sfx((v u32*)p, oldv, newv);   \
 +  } while (tmp != oldv);  \
 +  return ret; \
 +}
>>>
>>> So for an LL/SC based arch using cmpxchg() like that is sub-optimal.
>>>
>>> Why did you choose to write it entirely in C?
>>>
>> yes, you are right. more load/store will be done in C code.
>> However such xchg_u8/u16 is just used by qspinlock now. and I did not see 
>> any performance regression.
>> So just wrote in C, for simple. :)
>>
>> Of course I have done xchg tests.
>> we run code just like xchg((u8*), j++); in several threads.
>> and the result is,
>> [  768.374264] use time[1550072]ns in xchg_u8_asm
> 
> How was xchg_u8_asm() implemented, using lbarx or using a 32bit ll/sc
> loop with shifting and masking in it?
> 
yes, using 32bit ll/sc loops.

looks like:
__asm__ __volatile__(
"1: lwarx   %0,0,%3\n"
"   and %1,%0,%5\n"
"   or %1,%1,%4\n"
   PPC405_ERR77(0,%2)
"   stwcx.  %1,0,%3\n"
"   bne-1b"
: "=" (_oldv), "=" (tmp), "+m" (*(volatile unsigned int *)_p)
: "r" (_p), "r" (_newv), "r" (_oldv_mask)
: "cc", "memory");


> Regards,
> Boqun
> 
>> [  768.377102] use time[2826802]ns in xchg_u8_c
>>
>> I think this is because there is one more load in C.
>> If possible, we can move such code in asm-generic/.
>>
>> thanks
>> xinhui
>>