Re: [PATCH v4 0/2] ARM: Add Rockchip rk3288w support

[Mylene Josserand]

Hello Heiko,

On 6/17/20 10:58 AM, Heiko Stuebner wrote:

On Tue, 2 Jun 2020 10:06:42 +0200, Mylène Josserand wrote:

Context
---

Here is my V4 of my patches that add the support for the Rockchip
RK3288w which is a revision of the RK3288. It is mostly the same SOC
except for, at least, one clock tree which is different.
This difference is only known by looking at the BSP kernel [1].

[...]


Applied, thanks!


Thank you!

Best regards,
Mylène



[1/2] clk: rockchip: Handle clock tree for rk3288w variant
   commit: 1627f683636df70fb25358b0a7b39a24e8fce5bf
[2/2] dt-bindings: clocks: add rk3288w variant compatible
   commit: 00bd404144241155653bb0d0c15be51e4e6983aa

Best regards,

Re: [PATCH v3 1/1] clk: rockchip: rk3288: Handle clock tree for rk3288w

[Mylene Josserand]

Hi Heiko,

Thank you very much for your quick review!

On 6/1/20 10:09 PM, Heiko Stübner wrote:

Hi Mylène,

Am Montag, 1. Juni 2020, 17:14:42 CEST schrieb Mylène Josserand:

The revision rk3288w has a different clock tree about "hclk_vio"
clock, according to the BSP kernel code.

This patch handles this difference by detecting which device-tree
we are using. If it is a "rockchip,rk3288-cru", let's register
the clock tree as it was before. If the compatible is
"rockchip,rk3288w-cru", we will apply the difference according to this
version of this SoC.

Noticed that this new device-tree compatible must be handled by
bootloader.

Signed-off-by: Mylène Josserand 


approach looks good, but you should also update the clock-controller
dt-binding for the new compatible.


Okay, I will. As it was not implemented in the Kernel, I didn't know if 
I should add it.




Style nits below.



---
  drivers/clk/rockchip/clk-rk3288.c | 20 ++--
  1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3288.c 
b/drivers/clk/rockchip/clk-rk3288.c
index cc2a177bbdbf..5018d2f1e54c 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -425,8 +425,6 @@ static struct rockchip_clk_branch rk3288_clk_branches[] 
__initdata = {
COMPOSITE(0, "aclk_vio0", mux_pll_src_cpll_gpll_usb480m_p, 
CLK_IGNORE_UNUSED,
RK3288_CLKSEL_CON(31), 6, 2, MFLAGS, 0, 5, DFLAGS,
RK3288_CLKGATE_CON(3), 0, GFLAGS),
-   DIV(0, "hclk_vio", "aclk_vio0", 0,
-   RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
COMPOSITE(0, "aclk_vio1", mux_pll_src_cpll_gpll_usb480m_p, 
CLK_IGNORE_UNUSED,
RK3288_CLKSEL_CON(31), 14, 2, MFLAGS, 8, 5, DFLAGS,
RK3288_CLKGATE_CON(3), 2, GFLAGS),
@@ -819,6 +817,16 @@ static struct rockchip_clk_branch rk3288_clk_branches[] 
__initdata = {
INVERTER(0, "pclk_isp", "pclk_isp_in", RK3288_CLKSEL_CON(29), 3, 
IFLAGS),
  };
  
+static struct rockchip_clk_branch rk3288w_hclkvio_branch[] __initdata = {

+   DIV(0, "hclk_vio", "aclk_vio1", 0,
+   RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),


please keep indentations as they were, the sub-lines starting where they
are is actually intentional :-)


Oups, I didn't know, I will update this in my V4.





+};
+
+static struct rockchip_clk_branch rk3288_hclkvio_branch[] __initdata = {
+   DIV(0, "hclk_vio", "aclk_vio0", 0,
+   RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),


same here


same here




+};
+
  static const char *const rk3288_critical_clocks[] __initconst = {
"aclk_cpu",
"aclk_peri",
@@ -936,6 +944,14 @@ static void __init rk3288_clk_init(struct device_node *np)
   RK3288_GRF_SOC_STATUS1);
rockchip_clk_register_branches(ctx, rk3288_clk_branches,
  ARRAY_SIZE(rk3288_clk_branches));
+
+   if (of_device_is_compatible(np, "rockchip,rk3288w-cru"))
+   rockchip_clk_register_branches(ctx, rk3288w_hclkvio_branch,
+  
ARRAY_SIZE(rk3288w_hclkvio_branch));
+   else
+   rockchip_clk_register_branches(ctx, rk3288_hclkvio_branch,
+  
ARRAY_SIZE(rk3288_hclkvio_branch));
+
rockchip_clk_protect_critical(rk3288_critical_clocks,
  ARRAY_SIZE(rk3288_critical_clocks));
  



Best regards,
Mylène

Re: [PATCH v2 1/2] Input: edt-ft5x06 - Add support for regulator

[Mylene Josserand]

Hello Dmitry,

Le Tue, 23 Jan 2018 09:58:29 -0800,
Dmitry Torokhov <dmitry.torok...@gmail.com> a écrit :

> On Tue, Jan 23, 2018 at 10:10:55AM +0100, Mylene Josserand wrote:
> > Hello Dimitry,
> > 
> > Thank you for the review!
> > 
> > Le Mon, 22 Jan 2018 09:42:08 -0800,
> > Dmitry Torokhov <dmitry.torok...@gmail.com> a écrit :
> >   
> > > Hi Mylène,
> > > 
> > > On Thu, Dec 28, 2017 at 8:33 AM, Mylène Josserand
> > > <mylene.josser...@free-electrons.com> wrote:  
> > > > Add the support of regulator to use it as VCC source.
> > > >
> > > > Signed-off-by: Mylène Josserand <mylene.josser...@free-electrons.com>
> > > > ---
> > > >  .../bindings/input/touchscreen/edt-ft5x06.txt  |  1 +
> > > >  drivers/input/touchscreen/edt-ft5x06.c | 33 
> > > > ++
> > > >  2 files changed, 34 insertions(+)
> > > >
> > > > diff --git 
> > > > a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt 
> > > > b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > > > index 025cf8c9324a..48e975b9c1aa 100644
> > > > --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > > > +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > > > @@ -30,6 +30,7 @@ Required properties:
> > > >  Optional properties:
> > > >   - reset-gpios: GPIO specification for the RESET input
> > > >   - wake-gpios:  GPIO specification for the WAKE input
> > > > + - vcc-supply:  Regulator that supplies the touchscreen
> > > >
> > > >   - pinctrl-names: should be "default"
> > > >   - pinctrl-0:   a phandle pointing to the pin settings for the
> > > > diff --git a/drivers/input/touchscreen/edt-ft5x06.c 
> > > > b/drivers/input/touchscreen/edt-ft5x06.c
> > > > index c53a3d7239e7..5ee14a25a382 100644
> > > > --- a/drivers/input/touchscreen/edt-ft5x06.c
> > > > +++ b/drivers/input/touchscreen/edt-ft5x06.c
> > > > @@ -39,6 +39,7 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > >
> > > >  #define WORK_REGISTER_THRESHOLD0x00
> > > >  #define WORK_REGISTER_REPORT_RATE  0x08
> > > > @@ -91,6 +92,7 @@ struct edt_ft5x06_ts_data {
> > > > struct touchscreen_properties prop;
> > > > u16 num_x;
> > > > u16 num_y;
> > > > +   struct regulator *vcc;
> > > >
> > > > struct gpio_desc *reset_gpio;
> > > > struct gpio_desc *wake_gpio;
> > > > @@ -993,6 +995,23 @@ static int edt_ft5x06_ts_probe(struct i2c_client 
> > > > *client,
> > > >
> > > > tsdata->max_support_points = chip_data->max_support_points;
> > > >
> > > > +   tsdata->vcc = devm_regulator_get(>dev, "vcc");
> > > > +   if (IS_ERR(tsdata->vcc)) {
> > > > +   error = PTR_ERR(tsdata->vcc);
> > > > +   dev_err(>dev, "failed to request regulator: 
> > > > %d\n",
> > > > +   error);
> > > > +   return error;
> > > > +   };
> > > 
> > > As 0-day pounted out, this semicolon is not needed.  
> > 
> > Yes, thanks, I will fix that in next version.
> >   
> > >   
> > > > +
> > > > +   if (tsdata->vcc) {
> > > 
> > > You do not need to check for non-NULL here, devm_regulator_get() wil
> > > lnever give you a NULL. If regulator is not defined in DT/board
> > > mappings, then dummy regulator will be provided. You can call
> > > regulator_enable() and regulator_disable() and other regulator APIs
> > > with dummy regulator.  
> > 
> > Okay, thanks for the explanation, I will remove that.
> >   
> > >   
> > > > +   error = regulator_enable(tsdata->vcc);
> > > > +   if (error < 0) {
> > > > +   dev_err(>dev, "failed to enable vcc: 
> > > > %d\n",
> > > > +   error);
> > > > +   return error;
> > > > +   }
> > > > +   }
> > > >

Re: [PATCH v2 1/2] Input: edt-ft5x06 - Add support for regulator

[Mylene Josserand]

Hello Dmitry,

Le Tue, 23 Jan 2018 09:58:29 -0800,
Dmitry Torokhov  a écrit :

> On Tue, Jan 23, 2018 at 10:10:55AM +0100, Mylene Josserand wrote:
> > Hello Dimitry,
> > 
> > Thank you for the review!
> > 
> > Le Mon, 22 Jan 2018 09:42:08 -0800,
> > Dmitry Torokhov  a écrit :
> >   
> > > Hi Mylène,
> > > 
> > > On Thu, Dec 28, 2017 at 8:33 AM, Mylène Josserand
> > >  wrote:  
> > > > Add the support of regulator to use it as VCC source.
> > > >
> > > > Signed-off-by: Mylène Josserand 
> > > > ---
> > > >  .../bindings/input/touchscreen/edt-ft5x06.txt  |  1 +
> > > >  drivers/input/touchscreen/edt-ft5x06.c | 33 
> > > > ++
> > > >  2 files changed, 34 insertions(+)
> > > >
> > > > diff --git 
> > > > a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt 
> > > > b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > > > index 025cf8c9324a..48e975b9c1aa 100644
> > > > --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > > > +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > > > @@ -30,6 +30,7 @@ Required properties:
> > > >  Optional properties:
> > > >   - reset-gpios: GPIO specification for the RESET input
> > > >   - wake-gpios:  GPIO specification for the WAKE input
> > > > + - vcc-supply:  Regulator that supplies the touchscreen
> > > >
> > > >   - pinctrl-names: should be "default"
> > > >   - pinctrl-0:   a phandle pointing to the pin settings for the
> > > > diff --git a/drivers/input/touchscreen/edt-ft5x06.c 
> > > > b/drivers/input/touchscreen/edt-ft5x06.c
> > > > index c53a3d7239e7..5ee14a25a382 100644
> > > > --- a/drivers/input/touchscreen/edt-ft5x06.c
> > > > +++ b/drivers/input/touchscreen/edt-ft5x06.c
> > > > @@ -39,6 +39,7 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > >
> > > >  #define WORK_REGISTER_THRESHOLD0x00
> > > >  #define WORK_REGISTER_REPORT_RATE  0x08
> > > > @@ -91,6 +92,7 @@ struct edt_ft5x06_ts_data {
> > > > struct touchscreen_properties prop;
> > > > u16 num_x;
> > > > u16 num_y;
> > > > +   struct regulator *vcc;
> > > >
> > > > struct gpio_desc *reset_gpio;
> > > > struct gpio_desc *wake_gpio;
> > > > @@ -993,6 +995,23 @@ static int edt_ft5x06_ts_probe(struct i2c_client 
> > > > *client,
> > > >
> > > > tsdata->max_support_points = chip_data->max_support_points;
> > > >
> > > > +   tsdata->vcc = devm_regulator_get(>dev, "vcc");
> > > > +   if (IS_ERR(tsdata->vcc)) {
> > > > +   error = PTR_ERR(tsdata->vcc);
> > > > +   dev_err(>dev, "failed to request regulator: 
> > > > %d\n",
> > > > +   error);
> > > > +   return error;
> > > > +   };
> > > 
> > > As 0-day pounted out, this semicolon is not needed.  
> > 
> > Yes, thanks, I will fix that in next version.
> >   
> > >   
> > > > +
> > > > +   if (tsdata->vcc) {
> > > 
> > > You do not need to check for non-NULL here, devm_regulator_get() wil
> > > lnever give you a NULL. If regulator is not defined in DT/board
> > > mappings, then dummy regulator will be provided. You can call
> > > regulator_enable() and regulator_disable() and other regulator APIs
> > > with dummy regulator.  
> > 
> > Okay, thanks for the explanation, I will remove that.
> >   
> > >   
> > > > +   error = regulator_enable(tsdata->vcc);
> > > > +   if (error < 0) {
> > > > +   dev_err(>dev, "failed to enable vcc: 
> > > > %d\n",
> > > > +   error);
> > > > +   return error;
> > > > +   }
> > > > +   }
> > > > +
> > > > tsdata->reset_gpio = devm_gpiod_get_optional(>dev,
> > > >  

Re: [PATCH v4 1/2] Input: Add driver for Cypress Generation 5 touchscreen

[Mylene Josserand]

Hi Dmitry,

Thank you for the review.

Le Mon, 22 Jan 2018 20:15:03 -0800,
Dmitry Torokhov  a écrit :

> Hi Mylène,
> 
> On Fri, Dec 01, 2017 at 04:39:56PM +0100, Mylène Josserand wrote:
> > This is the basic driver for the Cypress TrueTouch Gen5 touchscreen
> > controllers. This driver supports only the I2C bus but it uses regmap
> > so SPI support could be added later.
> > The touchscreen can retrieve some defined zone that are handled as
> > buttons (according to the hardware). That is why it handles
> > button and multitouch events.
> > 
> > Reviewed-by: Maxime Ripard 
> > Signed-off-by: Mylène Josserand 
> > ---
> >  drivers/input/touchscreen/Kconfig   |   16 +
> >  drivers/input/touchscreen/Makefile  |1 +
> >  drivers/input/touchscreen/cyttsp5.c | 1110 
> > +++
> >  3 files changed, 1127 insertions(+)
> >  create mode 100644 drivers/input/touchscreen/cyttsp5.c
> > 
> > diff --git a/drivers/input/touchscreen/Kconfig 
> > b/drivers/input/touchscreen/Kconfig
> > index 0cfdb7cb610e..28eea6d5f1bb 100644
> > --- a/drivers/input/touchscreen/Kconfig
> > +++ b/drivers/input/touchscreen/Kconfig
> > @@ -238,6 +238,22 @@ config TOUCHSCREEN_CYTTSP4_SPI
> >   To compile this driver as a module, choose M here: the
> >   module will be called cyttsp4_spi.
> >  
> > +config TOUCHSCREEN_CYTTSP5
> > +   tristate "Cypress TrueTouch Gen5 Touchscreen Driver"
> > +   depends on OF  
> 
> Does it have to be? Please use generic device properties
> (device_property_* API) and it can be used with ACPI and static board
> files, of needed.

Okay, I will try with that.

> 
> > +   select REGMAP_I2C
> > +   select CRC_ITU_T
> > +   help
> > + Driver for Parade TrueTouch Standard Product
> > + Generation 5 touchscreen controllers.
> > + I2C bus interface support only.
> > +
> > + Say Y here if you have a Cypress Gen5 touchscreen.
> > + If unsure, say N.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called cyttsp5.
> > +
> >  config TOUCHSCREEN_DA9034
> > tristate "Touchscreen support for Dialog Semiconductor DA9034"
> > depends on PMIC_DA903X
> > diff --git a/drivers/input/touchscreen/Makefile 
> > b/drivers/input/touchscreen/Makefile
> > index d2a2b3b7af27..e7d124901dd9 100644
> > --- a/drivers/input/touchscreen/Makefile
> > +++ b/drivers/input/touchscreen/Makefile
> > @@ -26,6 +26,7 @@ obj-$(CONFIG_TOUCHSCREEN_CYTTSP_SPI)  += cyttsp_spi.o
> >  obj-$(CONFIG_TOUCHSCREEN_CYTTSP4_CORE) += cyttsp4_core.o
> >  obj-$(CONFIG_TOUCHSCREEN_CYTTSP4_I2C)  += cyttsp4_i2c.o 
> > cyttsp_i2c_common.o
> >  obj-$(CONFIG_TOUCHSCREEN_CYTTSP4_SPI)  += cyttsp4_spi.o
> > +obj-$(CONFIG_TOUCHSCREEN_CYTTSP5)  += cyttsp5.o
> >  obj-$(CONFIG_TOUCHSCREEN_DA9034)   += da9034-ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_DA9052)   += da9052_tsi.o
> >  obj-$(CONFIG_TOUCHSCREEN_DYNAPRO)  += dynapro.o
> > diff --git a/drivers/input/touchscreen/cyttsp5.c 
> > b/drivers/input/touchscreen/cyttsp5.c
> > new file mode 100644
> > index ..a41feea2cd5a
> > --- /dev/null
> > +++ b/drivers/input/touchscreen/cyttsp5.c
> > @@ -0,0 +1,1110 @@
> > +/*
> > + * Parade TrueTouch(TM) Standard Product V5 Module.
> > + * For use with Parade touchscreen controllers.
> > + *
> > + * Copyright (C) 2015 Parade Technologies
> > + * Copyright (C) 2012-2015 Cypress Semiconductor
> > + * Copyright (C) 2017 Free Electrons
> > + *
> > + * Author: Mylène Josserand 
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * version 2, and only 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 
> > +
> > +#define CYTTSP5_NAME   "cyttsp5"
> > +#define CY_I2C_DATA_SIZE   (2 * 256)
> > +#define HID_VERSION0x0100
> > +#define CY_MAX_INPUT   512
> > +#define CYTTSP5_PREALLOCATED_CMD_BUFFER32
> > +#define CY_BITS_PER_BTN1
> > +#define CY_NUM_BTN_EVENT_ID((1 << CY_BITS_PER_BTN) 
> > - 1)
> > +
> > +#define MAX_AREA   255
> > +#define HID_OUTPUT_BL_SOP  0x1
> > +#define HID_OUTPUT_BL_EOP  0x17
> > +#define HID_OUTPUT_BL_LAUNCH_APP   0x3B
> > 

Re: [PATCH v4 1/2] Input: Add driver for Cypress Generation 5 touchscreen

[Mylene Josserand]

Hi Dmitry,

Thank you for the review.

Le Mon, 22 Jan 2018 20:15:03 -0800,
Dmitry Torokhov  a écrit :

> Hi Mylène,
> 
> On Fri, Dec 01, 2017 at 04:39:56PM +0100, Mylène Josserand wrote:
> > This is the basic driver for the Cypress TrueTouch Gen5 touchscreen
> > controllers. This driver supports only the I2C bus but it uses regmap
> > so SPI support could be added later.
> > The touchscreen can retrieve some defined zone that are handled as
> > buttons (according to the hardware). That is why it handles
> > button and multitouch events.
> > 
> > Reviewed-by: Maxime Ripard 
> > Signed-off-by: Mylène Josserand 
> > ---
> >  drivers/input/touchscreen/Kconfig   |   16 +
> >  drivers/input/touchscreen/Makefile  |1 +
> >  drivers/input/touchscreen/cyttsp5.c | 1110 
> > +++
> >  3 files changed, 1127 insertions(+)
> >  create mode 100644 drivers/input/touchscreen/cyttsp5.c
> > 
> > diff --git a/drivers/input/touchscreen/Kconfig 
> > b/drivers/input/touchscreen/Kconfig
> > index 0cfdb7cb610e..28eea6d5f1bb 100644
> > --- a/drivers/input/touchscreen/Kconfig
> > +++ b/drivers/input/touchscreen/Kconfig
> > @@ -238,6 +238,22 @@ config TOUCHSCREEN_CYTTSP4_SPI
> >   To compile this driver as a module, choose M here: the
> >   module will be called cyttsp4_spi.
> >  
> > +config TOUCHSCREEN_CYTTSP5
> > +   tristate "Cypress TrueTouch Gen5 Touchscreen Driver"
> > +   depends on OF  
> 
> Does it have to be? Please use generic device properties
> (device_property_* API) and it can be used with ACPI and static board
> files, of needed.

Okay, I will try with that.

> 
> > +   select REGMAP_I2C
> > +   select CRC_ITU_T
> > +   help
> > + Driver for Parade TrueTouch Standard Product
> > + Generation 5 touchscreen controllers.
> > + I2C bus interface support only.
> > +
> > + Say Y here if you have a Cypress Gen5 touchscreen.
> > + If unsure, say N.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called cyttsp5.
> > +
> >  config TOUCHSCREEN_DA9034
> > tristate "Touchscreen support for Dialog Semiconductor DA9034"
> > depends on PMIC_DA903X
> > diff --git a/drivers/input/touchscreen/Makefile 
> > b/drivers/input/touchscreen/Makefile
> > index d2a2b3b7af27..e7d124901dd9 100644
> > --- a/drivers/input/touchscreen/Makefile
> > +++ b/drivers/input/touchscreen/Makefile
> > @@ -26,6 +26,7 @@ obj-$(CONFIG_TOUCHSCREEN_CYTTSP_SPI)  += cyttsp_spi.o
> >  obj-$(CONFIG_TOUCHSCREEN_CYTTSP4_CORE) += cyttsp4_core.o
> >  obj-$(CONFIG_TOUCHSCREEN_CYTTSP4_I2C)  += cyttsp4_i2c.o 
> > cyttsp_i2c_common.o
> >  obj-$(CONFIG_TOUCHSCREEN_CYTTSP4_SPI)  += cyttsp4_spi.o
> > +obj-$(CONFIG_TOUCHSCREEN_CYTTSP5)  += cyttsp5.o
> >  obj-$(CONFIG_TOUCHSCREEN_DA9034)   += da9034-ts.o
> >  obj-$(CONFIG_TOUCHSCREEN_DA9052)   += da9052_tsi.o
> >  obj-$(CONFIG_TOUCHSCREEN_DYNAPRO)  += dynapro.o
> > diff --git a/drivers/input/touchscreen/cyttsp5.c 
> > b/drivers/input/touchscreen/cyttsp5.c
> > new file mode 100644
> > index ..a41feea2cd5a
> > --- /dev/null
> > +++ b/drivers/input/touchscreen/cyttsp5.c
> > @@ -0,0 +1,1110 @@
> > +/*
> > + * Parade TrueTouch(TM) Standard Product V5 Module.
> > + * For use with Parade touchscreen controllers.
> > + *
> > + * Copyright (C) 2015 Parade Technologies
> > + * Copyright (C) 2012-2015 Cypress Semiconductor
> > + * Copyright (C) 2017 Free Electrons
> > + *
> > + * Author: Mylène Josserand 
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * version 2, and only 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 
> > +
> > +#define CYTTSP5_NAME   "cyttsp5"
> > +#define CY_I2C_DATA_SIZE   (2 * 256)
> > +#define HID_VERSION0x0100
> > +#define CY_MAX_INPUT   512
> > +#define CYTTSP5_PREALLOCATED_CMD_BUFFER32
> > +#define CY_BITS_PER_BTN1
> > +#define CY_NUM_BTN_EVENT_ID((1 << CY_BITS_PER_BTN) 
> > - 1)
> > +
> > +#define MAX_AREA   255
> > +#define HID_OUTPUT_BL_SOP  0x1
> > +#define HID_OUTPUT_BL_EOP  0x17
> > +#define HID_OUTPUT_BL_LAUNCH_APP   0x3B
> > +#define HID_OUTPUT_BL_LAUNCH_APP_SIZE  11
> > +#define HID_OUTPUT_GET_SYSINFO 0x2
> > +#define 

Re: [PATCH v4 1/2] Input: Add driver for Cypress Generation 5 touchscreen

[Mylene Josserand]

Hello Marcus,

Thank you for the review.

Le Mon, 22 Jan 2018 21:11:09 +0100,
Marcus Folkesson  a écrit :

> Mylene,
> 
> On Fri, Dec 01, 2017 at 04:39:56PM +0100, Mylène Josserand wrote:
> > +++ b/drivers/input/touchscreen/cyttsp5.c
> > @@ -0,0 +1,1110 @@
> > +/*
> > + * Parade TrueTouch(TM) Standard Product V5 Module.
> > + * For use with Parade touchscreen controllers.
> > + *
> > + * Copyright (C) 2015 Parade Technologies
> > + * Copyright (C) 2012-2015 Cypress Semiconductor
> > + * Copyright (C) 2017 Free Electrons
> > + *
> > + * Author: Mylène Josserand 
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * version 2, and only version 2, as published by the
> > + * Free Software Foundation.  
> 
> Please use SPDX license Identifier to describe the license.
> 
> E.g.
> SPDX-License-Identifier: GPL-2.0
> 
> Also, the MODULE_LICENSE means GPL 2.0 or later per module.h and this does
> not match the license description.
> 
> Could you make sure they are in sync?

You are right, I will check that, thanks.

> 
> 
> > + *
> > + * 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 
> 
> since you are using BIT()

okay

> 
> 
> [snip]
> 
> 
> > +static int cyttsp5_setup_input_device(struct device *dev)
> > +{
> > +   struct cyttsp5 *ts = dev_get_drvdata(dev);
> > +   struct cyttsp5_sysinfo *si = >sysinfo;
> > +   int max_x, max_y, max_p;
> > +   int max_x_tmp, max_y_tmp;
> > +   int rc;
> > +
> > +   __set_bit(EV_ABS, ts->input->evbit);
> > +   __set_bit(EV_REL, ts->input->evbit);
> > +   __set_bit(EV_KEY, ts->input->evbit);
> > +
> > +   max_x_tmp = si->sensing_conf_data.res_x;
> > +   max_y_tmp = si->sensing_conf_data.res_y;
> > +   max_x = max_y_tmp - 1;
> > +   max_y = max_x_tmp - 1;
> > +   max_p = si->sensing_conf_data.max_z;
> > +
> > +   input_mt_init_slots(ts->input, si->tch_abs[CY_TCH_T].max, 0);
> > +
> > +   __set_bit(ABS_MT_POSITION_X, ts->input->absbit);
> > +   __set_bit(ABS_MT_POSITION_Y, ts->input->absbit);
> > +   __set_bit(ABS_MT_PRESSURE, ts->input->absbit);  
> 
> Not needed, input_set_abs_params() will set the bits for you below.

Yes, I will remove it.

> 
> 
> > +
> > +   input_set_abs_params(ts->input, ABS_MT_POSITION_X, 0, max_x, 0, 0);
> > +   input_set_abs_params(ts->input, ABS_MT_POSITION_Y, 0, max_y, 0, 0);
> > +   input_set_abs_params(ts->input, ABS_MT_PRESSURE, 0, max_p, 0, 0);
> > +
> > +   input_set_abs_params(ts->input, ABS_MT_TOUCH_MAJOR, 0, MAX_AREA, 0, 0);
> > +   input_set_abs_params(ts->input, ABS_MT_TOUCH_MINOR, 0, MAX_AREA, 0, 0);
> > +
> > +   rc = input_register_device(ts->input);
> > +   if (rc < 0)
> > +   dev_err(dev, "Error, failed register input device r=%d\n", rc);
> > +
> > +   return rc;
> > +}
> > +
> > +  
> 
> [snip]
> 
> > +static int cyttsp5_get_hid_descriptor(struct cyttsp5 *ts,
> > + struct cyttsp5_hid_desc *desc)
> > +{
> > +   struct device *dev = ts->dev;
> > +   __le16 hid_desc_register = HID_DESC_REG;
> > +   int rc;
> > +   u8 cmd[2];
> > +
> > +   /* Read HID descriptor length and version */
> > +   mutex_lock(>system_lock);
> > +   ts->hid_cmd_state = HID_CMD_BUSY;
> > +   mutex_unlock(>system_lock);
> > +
> > +   /* Set HID descriptor register */
> > +   memcpy(cmd, _desc_register, sizeof(hid_desc_register));
> > +
> > +   rc = cyttsp5_write(ts, HID_DESC_REG, NULL, 0);
> > +   if (rc < 0) {
> > +   dev_err(dev, "Failed to get HID descriptor, rc=%d\n", rc);
> > +   goto error;
> > +   }
> > +
> > +   rc = wait_event_timeout(ts->wait_q, (ts->hid_cmd_state == HID_CMD_DONE),
> > +   
> > msecs_to_jiffies(CY_HID_GET_HID_DESCRIPTOR_TIMEOUT));
> > +   if (!rc) {
> > +   dev_err(ts->dev, "HID get descriptor timed out\n");
> > +   rc = -ETIME;
> > +   goto error;
> > +   }
> > +
> > +   memcpy(desc, ts->response_buf, sizeof(struct cyttsp5_hid_desc));
> > +
> > +   /* Check HID descriptor length and version */
> > +   if (le16_to_cpu(desc->hid_desc_len) != sizeof(*desc) ||
> > +   le16_to_cpu(desc->bcd_version) != HID_VERSION) {
> > +   dev_err(dev, "Unsupported HID version\n");
> > +   return -ENODEV;  
> 
> Maybe it is supposed to return here, but all other faults use "goto
> error".

Yep, I will use 'goto' instead of 'return' here.

> 
> > +   }
> > +
> > +   goto exit;
> > +
> > +error:
> > +   mutex_lock(>system_lock);
> > +   ts->hid_cmd_state 

Re: [PATCH v4 1/2] Input: Add driver for Cypress Generation 5 touchscreen

[Mylene Josserand]

Hello Marcus,

Thank you for the review.

Le Mon, 22 Jan 2018 21:11:09 +0100,
Marcus Folkesson  a écrit :

> Mylene,
> 
> On Fri, Dec 01, 2017 at 04:39:56PM +0100, Mylène Josserand wrote:
> > +++ b/drivers/input/touchscreen/cyttsp5.c
> > @@ -0,0 +1,1110 @@
> > +/*
> > + * Parade TrueTouch(TM) Standard Product V5 Module.
> > + * For use with Parade touchscreen controllers.
> > + *
> > + * Copyright (C) 2015 Parade Technologies
> > + * Copyright (C) 2012-2015 Cypress Semiconductor
> > + * Copyright (C) 2017 Free Electrons
> > + *
> > + * Author: Mylène Josserand 
> > + *
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License
> > + * version 2, and only version 2, as published by the
> > + * Free Software Foundation.  
> 
> Please use SPDX license Identifier to describe the license.
> 
> E.g.
> SPDX-License-Identifier: GPL-2.0
> 
> Also, the MODULE_LICENSE means GPL 2.0 or later per module.h and this does
> not match the license description.
> 
> Could you make sure they are in sync?

You are right, I will check that, thanks.

> 
> 
> > + *
> > + * 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 
> 
> since you are using BIT()

okay

> 
> 
> [snip]
> 
> 
> > +static int cyttsp5_setup_input_device(struct device *dev)
> > +{
> > +   struct cyttsp5 *ts = dev_get_drvdata(dev);
> > +   struct cyttsp5_sysinfo *si = >sysinfo;
> > +   int max_x, max_y, max_p;
> > +   int max_x_tmp, max_y_tmp;
> > +   int rc;
> > +
> > +   __set_bit(EV_ABS, ts->input->evbit);
> > +   __set_bit(EV_REL, ts->input->evbit);
> > +   __set_bit(EV_KEY, ts->input->evbit);
> > +
> > +   max_x_tmp = si->sensing_conf_data.res_x;
> > +   max_y_tmp = si->sensing_conf_data.res_y;
> > +   max_x = max_y_tmp - 1;
> > +   max_y = max_x_tmp - 1;
> > +   max_p = si->sensing_conf_data.max_z;
> > +
> > +   input_mt_init_slots(ts->input, si->tch_abs[CY_TCH_T].max, 0);
> > +
> > +   __set_bit(ABS_MT_POSITION_X, ts->input->absbit);
> > +   __set_bit(ABS_MT_POSITION_Y, ts->input->absbit);
> > +   __set_bit(ABS_MT_PRESSURE, ts->input->absbit);  
> 
> Not needed, input_set_abs_params() will set the bits for you below.

Yes, I will remove it.

> 
> 
> > +
> > +   input_set_abs_params(ts->input, ABS_MT_POSITION_X, 0, max_x, 0, 0);
> > +   input_set_abs_params(ts->input, ABS_MT_POSITION_Y, 0, max_y, 0, 0);
> > +   input_set_abs_params(ts->input, ABS_MT_PRESSURE, 0, max_p, 0, 0);
> > +
> > +   input_set_abs_params(ts->input, ABS_MT_TOUCH_MAJOR, 0, MAX_AREA, 0, 0);
> > +   input_set_abs_params(ts->input, ABS_MT_TOUCH_MINOR, 0, MAX_AREA, 0, 0);
> > +
> > +   rc = input_register_device(ts->input);
> > +   if (rc < 0)
> > +   dev_err(dev, "Error, failed register input device r=%d\n", rc);
> > +
> > +   return rc;
> > +}
> > +
> > +  
> 
> [snip]
> 
> > +static int cyttsp5_get_hid_descriptor(struct cyttsp5 *ts,
> > + struct cyttsp5_hid_desc *desc)
> > +{
> > +   struct device *dev = ts->dev;
> > +   __le16 hid_desc_register = HID_DESC_REG;
> > +   int rc;
> > +   u8 cmd[2];
> > +
> > +   /* Read HID descriptor length and version */
> > +   mutex_lock(>system_lock);
> > +   ts->hid_cmd_state = HID_CMD_BUSY;
> > +   mutex_unlock(>system_lock);
> > +
> > +   /* Set HID descriptor register */
> > +   memcpy(cmd, _desc_register, sizeof(hid_desc_register));
> > +
> > +   rc = cyttsp5_write(ts, HID_DESC_REG, NULL, 0);
> > +   if (rc < 0) {
> > +   dev_err(dev, "Failed to get HID descriptor, rc=%d\n", rc);
> > +   goto error;
> > +   }
> > +
> > +   rc = wait_event_timeout(ts->wait_q, (ts->hid_cmd_state == HID_CMD_DONE),
> > +   
> > msecs_to_jiffies(CY_HID_GET_HID_DESCRIPTOR_TIMEOUT));
> > +   if (!rc) {
> > +   dev_err(ts->dev, "HID get descriptor timed out\n");
> > +   rc = -ETIME;
> > +   goto error;
> > +   }
> > +
> > +   memcpy(desc, ts->response_buf, sizeof(struct cyttsp5_hid_desc));
> > +
> > +   /* Check HID descriptor length and version */
> > +   if (le16_to_cpu(desc->hid_desc_len) != sizeof(*desc) ||
> > +   le16_to_cpu(desc->bcd_version) != HID_VERSION) {
> > +   dev_err(dev, "Unsupported HID version\n");
> > +   return -ENODEV;  
> 
> Maybe it is supposed to return here, but all other faults use "goto
> error".

Yep, I will use 'goto' instead of 'return' here.

> 
> > +   }
> > +
> > +   goto exit;
> > +
> > +error:
> > +   mutex_lock(>system_lock);
> > +   ts->hid_cmd_state = HID_CMD_DONE;
> > +   mutex_unlock(>system_lock);
> > +exit:
> 

Re: [PATCH v2 1/2] Input: edt-ft5x06 - Add support for regulator

[Mylene Josserand]

Hello Lothar,

Le Tue, 23 Jan 2018 09:04:14 +0100,
Lothar Waßmann  a écrit :

> Hi,
> 
> On Mon, 22 Jan 2018 09:42:08 -0800 Dmitry Torokhov wrote:
> > Hi Mylène,
> > 
> > On Thu, Dec 28, 2017 at 8:33 AM, Mylène Josserand
> >  wrote:  
> > > Add the support of regulator to use it as VCC source.
> > >
> > > Signed-off-by: Mylène Josserand 
> > > ---
> > >  .../bindings/input/touchscreen/edt-ft5x06.txt  |  1 +
> > >  drivers/input/touchscreen/edt-ft5x06.c | 33 
> > > ++
> > >  2 files changed, 34 insertions(+)
> > >
> > > diff --git 
> > > a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt 
> > > b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > > index 025cf8c9324a..48e975b9c1aa 100644
> > > --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > > +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > > @@ -30,6 +30,7 @@ Required properties:
> > >  Optional properties:
> > >   - reset-gpios: GPIO specification for the RESET input
> > >   - wake-gpios:  GPIO specification for the WAKE input
> > > + - vcc-supply:  Regulator that supplies the touchscreen
> > >
> > >   - pinctrl-names: should be "default"
> > >   - pinctrl-0:   a phandle pointing to the pin settings for the
> > > diff --git a/drivers/input/touchscreen/edt-ft5x06.c 
> > > b/drivers/input/touchscreen/edt-ft5x06.c
> > > index c53a3d7239e7..5ee14a25a382 100644
> > > --- a/drivers/input/touchscreen/edt-ft5x06.c
> > > +++ b/drivers/input/touchscreen/edt-ft5x06.c
> > > @@ -39,6 +39,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  #define WORK_REGISTER_THRESHOLD0x00
> > >  #define WORK_REGISTER_REPORT_RATE  0x08
> > > @@ -91,6 +92,7 @@ struct edt_ft5x06_ts_data {
> > > struct touchscreen_properties prop;
> > > u16 num_x;
> > > u16 num_y;
> > > +   struct regulator *vcc;
> > >
> > > struct gpio_desc *reset_gpio;
> > > struct gpio_desc *wake_gpio;
> > > @@ -993,6 +995,23 @@ static int edt_ft5x06_ts_probe(struct i2c_client 
> > > *client,
> > >
> > > tsdata->max_support_points = chip_data->max_support_points;
> > >
> > > +   tsdata->vcc = devm_regulator_get(>dev, "vcc");
> > > +   if (IS_ERR(tsdata->vcc)) {
> > > +   error = PTR_ERR(tsdata->vcc);
> > > +   dev_err(>dev, "failed to request regulator: %d\n",
> > > +   error);  
> >  
> I would check for -EPROBE_DEFER here and omit the error message in this
> case.
> 
> 
> Lothar Waßmann

Sure, I will add this case, thank you for the review.

Best regards,

-- 
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2 1/2] Input: edt-ft5x06 - Add support for regulator

[Mylene Josserand]

Hello Lothar,

Le Tue, 23 Jan 2018 09:04:14 +0100,
Lothar Waßmann  a écrit :

> Hi,
> 
> On Mon, 22 Jan 2018 09:42:08 -0800 Dmitry Torokhov wrote:
> > Hi Mylène,
> > 
> > On Thu, Dec 28, 2017 at 8:33 AM, Mylène Josserand
> >  wrote:  
> > > Add the support of regulator to use it as VCC source.
> > >
> > > Signed-off-by: Mylène Josserand 
> > > ---
> > >  .../bindings/input/touchscreen/edt-ft5x06.txt  |  1 +
> > >  drivers/input/touchscreen/edt-ft5x06.c | 33 
> > > ++
> > >  2 files changed, 34 insertions(+)
> > >
> > > diff --git 
> > > a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt 
> > > b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > > index 025cf8c9324a..48e975b9c1aa 100644
> > > --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > > +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > > @@ -30,6 +30,7 @@ Required properties:
> > >  Optional properties:
> > >   - reset-gpios: GPIO specification for the RESET input
> > >   - wake-gpios:  GPIO specification for the WAKE input
> > > + - vcc-supply:  Regulator that supplies the touchscreen
> > >
> > >   - pinctrl-names: should be "default"
> > >   - pinctrl-0:   a phandle pointing to the pin settings for the
> > > diff --git a/drivers/input/touchscreen/edt-ft5x06.c 
> > > b/drivers/input/touchscreen/edt-ft5x06.c
> > > index c53a3d7239e7..5ee14a25a382 100644
> > > --- a/drivers/input/touchscreen/edt-ft5x06.c
> > > +++ b/drivers/input/touchscreen/edt-ft5x06.c
> > > @@ -39,6 +39,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  #define WORK_REGISTER_THRESHOLD0x00
> > >  #define WORK_REGISTER_REPORT_RATE  0x08
> > > @@ -91,6 +92,7 @@ struct edt_ft5x06_ts_data {
> > > struct touchscreen_properties prop;
> > > u16 num_x;
> > > u16 num_y;
> > > +   struct regulator *vcc;
> > >
> > > struct gpio_desc *reset_gpio;
> > > struct gpio_desc *wake_gpio;
> > > @@ -993,6 +995,23 @@ static int edt_ft5x06_ts_probe(struct i2c_client 
> > > *client,
> > >
> > > tsdata->max_support_points = chip_data->max_support_points;
> > >
> > > +   tsdata->vcc = devm_regulator_get(>dev, "vcc");
> > > +   if (IS_ERR(tsdata->vcc)) {
> > > +   error = PTR_ERR(tsdata->vcc);
> > > +   dev_err(>dev, "failed to request regulator: %d\n",
> > > +   error);  
> >  
> I would check for -EPROBE_DEFER here and omit the error message in this
> case.
> 
> 
> Lothar Waßmann

Sure, I will add this case, thank you for the review.

Best regards,

-- 
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2 1/2] Input: edt-ft5x06 - Add support for regulator

[Mylene Josserand]

Hello Dimitry,

Thank you for the review!

Le Mon, 22 Jan 2018 09:42:08 -0800,
Dmitry Torokhov  a écrit :

> Hi Mylène,
> 
> On Thu, Dec 28, 2017 at 8:33 AM, Mylène Josserand
>  wrote:
> > Add the support of regulator to use it as VCC source.
> >
> > Signed-off-by: Mylène Josserand 
> > ---
> >  .../bindings/input/touchscreen/edt-ft5x06.txt  |  1 +
> >  drivers/input/touchscreen/edt-ft5x06.c | 33 
> > ++
> >  2 files changed, 34 insertions(+)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt 
> > b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > index 025cf8c9324a..48e975b9c1aa 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > @@ -30,6 +30,7 @@ Required properties:
> >  Optional properties:
> >   - reset-gpios: GPIO specification for the RESET input
> >   - wake-gpios:  GPIO specification for the WAKE input
> > + - vcc-supply:  Regulator that supplies the touchscreen
> >
> >   - pinctrl-names: should be "default"
> >   - pinctrl-0:   a phandle pointing to the pin settings for the
> > diff --git a/drivers/input/touchscreen/edt-ft5x06.c 
> > b/drivers/input/touchscreen/edt-ft5x06.c
> > index c53a3d7239e7..5ee14a25a382 100644
> > --- a/drivers/input/touchscreen/edt-ft5x06.c
> > +++ b/drivers/input/touchscreen/edt-ft5x06.c
> > @@ -39,6 +39,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #define WORK_REGISTER_THRESHOLD0x00
> >  #define WORK_REGISTER_REPORT_RATE  0x08
> > @@ -91,6 +92,7 @@ struct edt_ft5x06_ts_data {
> > struct touchscreen_properties prop;
> > u16 num_x;
> > u16 num_y;
> > +   struct regulator *vcc;
> >
> > struct gpio_desc *reset_gpio;
> > struct gpio_desc *wake_gpio;
> > @@ -993,6 +995,23 @@ static int edt_ft5x06_ts_probe(struct i2c_client 
> > *client,
> >
> > tsdata->max_support_points = chip_data->max_support_points;
> >
> > +   tsdata->vcc = devm_regulator_get(>dev, "vcc");
> > +   if (IS_ERR(tsdata->vcc)) {
> > +   error = PTR_ERR(tsdata->vcc);
> > +   dev_err(>dev, "failed to request regulator: %d\n",
> > +   error);
> > +   return error;
> > +   };  
> 
> As 0-day pounted out, this semicolon is not needed.

Yes, thanks, I will fix that in next version.

> 
> > +
> > +   if (tsdata->vcc) {  
> 
> You do not need to check for non-NULL here, devm_regulator_get() wil
> lnever give you a NULL. If regulator is not defined in DT/board
> mappings, then dummy regulator will be provided. You can call
> regulator_enable() and regulator_disable() and other regulator APIs
> with dummy regulator.

Okay, thanks for the explanation, I will remove that.

> 
> > +   error = regulator_enable(tsdata->vcc);
> > +   if (error < 0) {
> > +   dev_err(>dev, "failed to enable vcc: %d\n",
> > +   error);
> > +   return error;
> > +   }
> > +   }
> > +
> > tsdata->reset_gpio = devm_gpiod_get_optional(>dev,
> >  "reset", 
> > GPIOD_OUT_HIGH);
> > if (IS_ERR(tsdata->reset_gpio)) {
> > @@ -1122,20 +1141,34 @@ static int edt_ft5x06_ts_remove(struct i2c_client 
> > *client)
> >  static int __maybe_unused edt_ft5x06_ts_suspend(struct device *dev)
> >  {
> > struct i2c_client *client = to_i2c_client(dev);
> > +   struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
> >
> > if (device_may_wakeup(dev))
> > enable_irq_wake(client->irq);
> >
> > +   if (tsdata->vcc)  
> 
> Same here.

yep

> 
> > +   regulator_disable(tsdata->vcc);
> > +
> > return 0;
> >  }
> >
> >  static int __maybe_unused edt_ft5x06_ts_resume(struct device *dev)
> >  {
> > struct i2c_client *client = to_i2c_client(dev);
> > +   struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
> > +   int ret;
> >
> > if (device_may_wakeup(dev))
> > disable_irq_wake(client->irq);
> >
> > +   if (tsdata->vcc) {  
> 
> And here.

yep

> 
> > +   ret = regulator_enable(tsdata->vcc);
> > +   if (ret < 0) {
> > +   dev_err(dev, "failed to enable vcc: %d\n", ret);
> > +   return ret;
> > +   }  
> 
> Since power to the device may have been cut, I think you need to
> restore the register settings to whatever it was (factory vs work
> mode, threshold, gain and offset registers, etc, etc).

Okay. Could you tell me how can I do that?

> 
> > +   }
> > +
> > return 0;
> >  }
> >
> > --
> > 2.11.0
> >  
> 
> Thanks.
> 

Re: [PATCH v2 1/2] Input: edt-ft5x06 - Add support for regulator

[Mylene Josserand]

Hello Dimitry,

Thank you for the review!

Le Mon, 22 Jan 2018 09:42:08 -0800,
Dmitry Torokhov  a écrit :

> Hi Mylène,
> 
> On Thu, Dec 28, 2017 at 8:33 AM, Mylène Josserand
>  wrote:
> > Add the support of regulator to use it as VCC source.
> >
> > Signed-off-by: Mylène Josserand 
> > ---
> >  .../bindings/input/touchscreen/edt-ft5x06.txt  |  1 +
> >  drivers/input/touchscreen/edt-ft5x06.c | 33 
> > ++
> >  2 files changed, 34 insertions(+)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt 
> > b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > index 025cf8c9324a..48e975b9c1aa 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
> > @@ -30,6 +30,7 @@ Required properties:
> >  Optional properties:
> >   - reset-gpios: GPIO specification for the RESET input
> >   - wake-gpios:  GPIO specification for the WAKE input
> > + - vcc-supply:  Regulator that supplies the touchscreen
> >
> >   - pinctrl-names: should be "default"
> >   - pinctrl-0:   a phandle pointing to the pin settings for the
> > diff --git a/drivers/input/touchscreen/edt-ft5x06.c 
> > b/drivers/input/touchscreen/edt-ft5x06.c
> > index c53a3d7239e7..5ee14a25a382 100644
> > --- a/drivers/input/touchscreen/edt-ft5x06.c
> > +++ b/drivers/input/touchscreen/edt-ft5x06.c
> > @@ -39,6 +39,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #define WORK_REGISTER_THRESHOLD0x00
> >  #define WORK_REGISTER_REPORT_RATE  0x08
> > @@ -91,6 +92,7 @@ struct edt_ft5x06_ts_data {
> > struct touchscreen_properties prop;
> > u16 num_x;
> > u16 num_y;
> > +   struct regulator *vcc;
> >
> > struct gpio_desc *reset_gpio;
> > struct gpio_desc *wake_gpio;
> > @@ -993,6 +995,23 @@ static int edt_ft5x06_ts_probe(struct i2c_client 
> > *client,
> >
> > tsdata->max_support_points = chip_data->max_support_points;
> >
> > +   tsdata->vcc = devm_regulator_get(>dev, "vcc");
> > +   if (IS_ERR(tsdata->vcc)) {
> > +   error = PTR_ERR(tsdata->vcc);
> > +   dev_err(>dev, "failed to request regulator: %d\n",
> > +   error);
> > +   return error;
> > +   };  
> 
> As 0-day pounted out, this semicolon is not needed.

Yes, thanks, I will fix that in next version.

> 
> > +
> > +   if (tsdata->vcc) {  
> 
> You do not need to check for non-NULL here, devm_regulator_get() wil
> lnever give you a NULL. If regulator is not defined in DT/board
> mappings, then dummy regulator will be provided. You can call
> regulator_enable() and regulator_disable() and other regulator APIs
> with dummy regulator.

Okay, thanks for the explanation, I will remove that.

> 
> > +   error = regulator_enable(tsdata->vcc);
> > +   if (error < 0) {
> > +   dev_err(>dev, "failed to enable vcc: %d\n",
> > +   error);
> > +   return error;
> > +   }
> > +   }
> > +
> > tsdata->reset_gpio = devm_gpiod_get_optional(>dev,
> >  "reset", 
> > GPIOD_OUT_HIGH);
> > if (IS_ERR(tsdata->reset_gpio)) {
> > @@ -1122,20 +1141,34 @@ static int edt_ft5x06_ts_remove(struct i2c_client 
> > *client)
> >  static int __maybe_unused edt_ft5x06_ts_suspend(struct device *dev)
> >  {
> > struct i2c_client *client = to_i2c_client(dev);
> > +   struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
> >
> > if (device_may_wakeup(dev))
> > enable_irq_wake(client->irq);
> >
> > +   if (tsdata->vcc)  
> 
> Same here.

yep

> 
> > +   regulator_disable(tsdata->vcc);
> > +
> > return 0;
> >  }
> >
> >  static int __maybe_unused edt_ft5x06_ts_resume(struct device *dev)
> >  {
> > struct i2c_client *client = to_i2c_client(dev);
> > +   struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
> > +   int ret;
> >
> > if (device_may_wakeup(dev))
> > disable_irq_wake(client->irq);
> >
> > +   if (tsdata->vcc) {  
> 
> And here.

yep

> 
> > +   ret = regulator_enable(tsdata->vcc);
> > +   if (ret < 0) {
> > +   dev_err(dev, "failed to enable vcc: %d\n", ret);
> > +   return ret;
> > +   }  
> 
> Since power to the device may have been cut, I think you need to
> restore the register settings to whatever it was (factory vs work
> mode, threshold, gain and offset registers, etc, etc).

Okay. Could you tell me how can I do that?

> 
> > +   }
> > +
> > return 0;
> >  }
> >
> > --
> > 2.11.0
> >  
> 
> Thanks.
> 

About your V2's review, you suggested to add support for wake/reset in
suspend/resume (that I 

Re: [PATCH v2 0/5] Sunxi: Add SMP support on A83T

[Mylene JOSSERAND]

Hello,

Le Fri, 29 Dec 2017 11:55:01 +0100,
Mylène Josserand  a écrit :

> Hello everyone,
> 
> This is a V2 of my series that adds SMP support for Allwinner sun8i-a83t
> with MCPM (Multi-Cluster Power Management).
> Based on last linux-next (next-20171222).
> 
> Changes since v1:
> - Add Chen Yu's patch in my series (see path 01)
> - Add new compatibles for prcm and cpucfg registers for sun8i-a83t.
> Create two functions to separate the DT parsing of sun9i-a80 and
> sun8i-a83t.
> - Thanks to Maxime's review: order device tree's nodes according
> to physical addresses, remove unused label and fix registers' sizes.
> Update the commit log and commit title of my last patch (see
> patch 05).
> 
> Patch 01: Patch from Chen Yu Tsai that adds SMP support on A80
> with MCPM
> Patch 02: Convert the MCPM driver to use it for A83T. This SoC has a
> bit flip that needs to be handled.
> Patch 03: Add registers nodes (prcm, cpucfg and r_cpucfg) needed
> for MCPM.
> Patch 04: Add CCI-400 node for a83t.
> Patch 05: Fix the use of virtual timers that hangs the kernel in
> case of SMP support.
> 
> If you have any remarks/questions, let me know.
> Thank you in advance,
> Mylène
> 
> Chen-Yu Tsai (1):
>   ARM: sun9i: Support SMP on A80 with Multi-Cluster Power Management
> (MCPM)

Oops, I noticed that Chen Yu sent a new version of his patches on
July 2017:

https://patchwork.kernel.org/patch/9861179/
https://patchwork.kernel.org/patch/9861175/
https://patchwork.kernel.org/patch/9861173/
https://patchwork.kernel.org/patch/9861177/

I will send a V3 using this series instead of the old RFC one:
https://patchwork.kernel.org/patch/6402801/

Sorry about the noise.

Mylène

> 
> Mylène Josserand (4):
>   ARM: sunxi: mcpm: Add support for A83T
>   arm: dts: sun8i: a83t: Add registers needed for MCPM
>   arm: dts: sun8i: a83t: Add CCI-400 node
>   arm: dts: sun8i: a83t: Fix undefined offset with virtual timer
> 
>  arch/arm/boot/dts/sun8i-a83t.dtsi |  57 +
>  arch/arm/mach-sunxi/Kconfig   |  11 +
>  arch/arm/mach-sunxi/Makefile  |   1 +
>  arch/arm/mach-sunxi/mcpm.c| 513 
> ++
>  4 files changed, 582 insertions(+)
>  create mode 100644 arch/arm/mach-sunxi/mcpm.c
> 

Re: [PATCH v2 0/5] Sunxi: Add SMP support on A83T

[Mylene JOSSERAND]

Hello,

Le Fri, 29 Dec 2017 11:55:01 +0100,
Mylène Josserand  a écrit :

> Hello everyone,
> 
> This is a V2 of my series that adds SMP support for Allwinner sun8i-a83t
> with MCPM (Multi-Cluster Power Management).
> Based on last linux-next (next-20171222).
> 
> Changes since v1:
> - Add Chen Yu's patch in my series (see path 01)
> - Add new compatibles for prcm and cpucfg registers for sun8i-a83t.
> Create two functions to separate the DT parsing of sun9i-a80 and
> sun8i-a83t.
> - Thanks to Maxime's review: order device tree's nodes according
> to physical addresses, remove unused label and fix registers' sizes.
> Update the commit log and commit title of my last patch (see
> patch 05).
> 
> Patch 01: Patch from Chen Yu Tsai that adds SMP support on A80
> with MCPM
> Patch 02: Convert the MCPM driver to use it for A83T. This SoC has a
> bit flip that needs to be handled.
> Patch 03: Add registers nodes (prcm, cpucfg and r_cpucfg) needed
> for MCPM.
> Patch 04: Add CCI-400 node for a83t.
> Patch 05: Fix the use of virtual timers that hangs the kernel in
> case of SMP support.
> 
> If you have any remarks/questions, let me know.
> Thank you in advance,
> Mylène
> 
> Chen-Yu Tsai (1):
>   ARM: sun9i: Support SMP on A80 with Multi-Cluster Power Management
> (MCPM)

Oops, I noticed that Chen Yu sent a new version of his patches on
July 2017:

https://patchwork.kernel.org/patch/9861179/
https://patchwork.kernel.org/patch/9861175/
https://patchwork.kernel.org/patch/9861173/
https://patchwork.kernel.org/patch/9861177/

I will send a V3 using this series instead of the old RFC one:
https://patchwork.kernel.org/patch/6402801/

Sorry about the noise.

Mylène

> 
> Mylène Josserand (4):
>   ARM: sunxi: mcpm: Add support for A83T
>   arm: dts: sun8i: a83t: Add registers needed for MCPM
>   arm: dts: sun8i: a83t: Add CCI-400 node
>   arm: dts: sun8i: a83t: Fix undefined offset with virtual timer
> 
>  arch/arm/boot/dts/sun8i-a83t.dtsi |  57 +
>  arch/arm/mach-sunxi/Kconfig   |  11 +
>  arch/arm/mach-sunxi/Makefile  |   1 +
>  arch/arm/mach-sunxi/mcpm.c| 513 
> ++
>  4 files changed, 582 insertions(+)
>  create mode 100644 arch/arm/mach-sunxi/mcpm.c
> 

Re: [PATCH 0/4] Sunxi: Add SMP support on A83T

[Mylene JOSSERAND]

Hello Corentin,

Le Thu, 28 Dec 2017 21:31:25 +0100,
Corentin Labbe  a écrit :

[...]

> Hello
> 
> With the .config that you give me in private, everything seems to work.
> But with mine, the stacktrace still happen.
> After some research, this is due to the following code:
> cpumask_set_cpu(get_cpu(), _pmu->cpus);
> which disable preemption (via get_cpu())
> 
> So it is unrelated with your patch, I will send a bug report tomorow.

Okay, great to know that it is not related to my patches.

> 
> Furthermore, you can add:
> Tested-by: Corentin Labbe 

Thanks, I have just sent a V2. I did not add your tested-by because
I have done some modifications. Could you test this new series and give
me your tested-by again? It would be great!

Thank you in advance,

Best regards,

Mylène

-- 
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 0/4] Sunxi: Add SMP support on A83T

[Mylene JOSSERAND]

Hello Corentin,

Le Thu, 28 Dec 2017 21:31:25 +0100,
Corentin Labbe  a écrit :

[...]

> Hello
> 
> With the .config that you give me in private, everything seems to work.
> But with mine, the stacktrace still happen.
> After some research, this is due to the following code:
> cpumask_set_cpu(get_cpu(), _pmu->cpus);
> which disable preemption (via get_cpu())
> 
> So it is unrelated with your patch, I will send a bug report tomorow.

Okay, great to know that it is not related to my patches.

> 
> Furthermore, you can add:
> Tested-by: Corentin Labbe 

Thanks, I have just sent a V2. I did not add your tested-by because
I have done some modifications. Could you test this new series and give
me your tested-by again? It would be great!

Thank you in advance,

Best regards,

Mylène

-- 
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2 0/2] sun8i-a83t: Add touchscreen support on TBS A711

[Mylene JOSSERAND]

Hello,

Le Thu, 28 Dec 2017 17:33:34 +0100,
Mylène Josserand  a écrit :

> Hello everyone,
> 
> This is a V2 of the patch series that adds touchscreen support
> (FocalTech EDT-FT5x06 Polytouch) for TBS A711 (Allwinner sun8i-a83t SoC).
> Based on last linux-next (next-20171222).
> 
> Changes since v1:
>- Remove patches 01 and 02 as Chen-Yu Tsai sent a similar patch:
>https://patchwork.kernel.org/patch/10111431/
>and it is merged on last next-20171222.
>(See commit f066f46ce5a5 "ARM: dts: sun8i: a83t: Add I2C device nodes and 
> pinmux settings")
>- Update regulator according to Dmitry Torokhov's review: remove "optional"
>suffix while retrieving the regulator, rename it into "vcc" instead of
>"power" and add bindings documentation.

I notice that I forgot the second review of Dmitry about reset/wake
gpios so I will send a V3 with the modifications.

Thanks,

Mylène

>- Update device tree according to Maxime Ripard's review: remove the
>label and rename the node.
>- Squash patch 03 with patch 05 to add I2C0 and touchscreen's node
>in one patch (see patch 02).
> 
> Patch 01: Add support for regulator in the FocalTech touchscreen driver
> because A711 tablet is using a regulator to power-up the touchscreen.
> Patch 02: Add i2c0 and touchscreen's node for A711 TBS tablet.
> 
> Thank you in advance for any review.
> Best regards,
> Mylène
> 
> Mylène Josserand (2):
>   Input: edt-ft5x06 - Add support for regulator
>   arm: dts: sun8i: a83t: a711: Add touchscreen node
> 
>  .../bindings/input/touchscreen/edt-ft5x06.txt  |  1 +
>  arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts  | 16 +++
>  drivers/input/touchscreen/edt-ft5x06.c | 33 
> ++
>  3 files changed, 50 insertions(+)
> 

Re: [PATCH v2 0/2] sun8i-a83t: Add touchscreen support on TBS A711

[Mylene JOSSERAND]

Hello,

Le Thu, 28 Dec 2017 17:33:34 +0100,
Mylène Josserand  a écrit :

> Hello everyone,
> 
> This is a V2 of the patch series that adds touchscreen support
> (FocalTech EDT-FT5x06 Polytouch) for TBS A711 (Allwinner sun8i-a83t SoC).
> Based on last linux-next (next-20171222).
> 
> Changes since v1:
>- Remove patches 01 and 02 as Chen-Yu Tsai sent a similar patch:
>https://patchwork.kernel.org/patch/10111431/
>and it is merged on last next-20171222.
>(See commit f066f46ce5a5 "ARM: dts: sun8i: a83t: Add I2C device nodes and 
> pinmux settings")
>- Update regulator according to Dmitry Torokhov's review: remove "optional"
>suffix while retrieving the regulator, rename it into "vcc" instead of
>"power" and add bindings documentation.

I notice that I forgot the second review of Dmitry about reset/wake
gpios so I will send a V3 with the modifications.

Thanks,

Mylène

>- Update device tree according to Maxime Ripard's review: remove the
>label and rename the node.
>- Squash patch 03 with patch 05 to add I2C0 and touchscreen's node
>in one patch (see patch 02).
> 
> Patch 01: Add support for regulator in the FocalTech touchscreen driver
> because A711 tablet is using a regulator to power-up the touchscreen.
> Patch 02: Add i2c0 and touchscreen's node for A711 TBS tablet.
> 
> Thank you in advance for any review.
> Best regards,
> Mylène
> 
> Mylène Josserand (2):
>   Input: edt-ft5x06 - Add support for regulator
>   arm: dts: sun8i: a83t: a711: Add touchscreen node
> 
>  .../bindings/input/touchscreen/edt-ft5x06.txt  |  1 +
>  arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts  | 16 +++
>  drivers/input/touchscreen/edt-ft5x06.c | 33 
> ++
>  3 files changed, 50 insertions(+)
> 

Re: [PATCH 0/4] Sunxi: Add SMP support on A83T

[Mylene JOSSERAND]

Hello Corentin,

Le Fri, 15 Dec 2017 07:10:46 +0100,
Corentin Labbe  a écrit :
> On Tue, Dec 12, 2017 at 09:24:25AM +0100, Maxime Ripard wrote:
> > Hi,
> > 
> > On Mon, Dec 11, 2017 at 08:35:34PM +0100, Corentin Labbe wrote:  
> > > On Mon, Dec 11, 2017 at 08:49:57AM +0100, Mylène Josserand wrote:  
> > > > This series adds SMP support for Allwinner Sun8i-a83t
> > > > with MCPM (Multi-Cluster Power Management).
> > > > Series information:
> > > > - Based on last linux-next (next-20171211)
> > > > - Had dependencies on Chen Yu's patch that add MCPM
> > > > support:
> > > > https://patchwork.kernel.org/patch/6402801/
> > > > 
> > > > Patch 01: Convert the mcpm driver (initially for A80) to be able
> > > > to use it for A83T. This SoC has a bit flip that needs to be handled.
> > > > Patch 02: Add registers nodes (prcm, cpucfg and r_cpucfg) needed
> > > > for MCPM.
> > > > Patch 03: Add CCI-400 node for a83t.
> > > > Patch 04: Fix the use of virtual timers that hangs the kernel in
> > > > case of SMP support.  
> > > 
> > > As we discussed in private, Chen Yu's patch should be added in your 
> > > series.  
> > 
> > Not really, she mentionned the dependency in the cover letter, and
> > it's a good way to do things too. Sure, you can do it your way, but
> > there's no preference.
> >   
> 
> If the goal of this series is to be applied, the dependency must be applied 
> also.
> And since the dependency is 2 years old (and part of a serie which does not 
> apply now), I think cherry picking the patch and send it for review is better.
> 
> > > Furthermore, MCPM is not automaticaly selected via imply.  
> > 
> > Well, yes, is that an issue?
> >   
> 
> After reading the imply documentation, no.
> 
> > > With all patchs I hit a bug:
> > > [0.898668] BUG: sleeping function called from invalid context at 
> > > kernel/locking/mutex.c:238  
> > 
> > I guess this is with CONFIG_PROVE_LOCKING enabled?
> >   
> 
> No, the BUG() printed is enabled by default
> 
> > > [0.911162] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
> > > [0.917776] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> > > 4.15.0-rc2-next-20171211+ #73  
> > 
> > What are the changes you've made?
> >   
> 
> Just adding wens's patch and this series.

I tried to reproduce your issue without success (even with
CONFIG_PROVE_LOCKING enabled, just in case).
Can you give me more details about your tests? which defconfig and
additional configurations?

> 
> > > [0.925418] Hardware name: Allwinner sun8i Family
> > > [0.930118] Backtrace: 
> > > [0.932596] [] (dump_backtrace) from [] 
> > > (show_stack+0x18/0x1c)
> > > [0.940158]  r7:c0b261e4 r6:6013 r5: r4:c0b51958
> > > [0.945820] [] (show_stack) from [] 
> > > (dump_stack+0x8c/0xa0)
> > > [0.953045] [] (dump_stack) from [] 
> > > (___might_sleep+0x150/0x170)
> > > [0.960779]  r7:c0b261e4 r6: r5:00ee r4:ee844000
> > > [0.966437] [] (___might_sleep) from [] 
> > > (__might_sleep+0x68/0xa0)
> > > [0.974253]  r4:c0861690
> > > [0.976796] [] (__might_sleep) from [] 
> > > (mutex_lock+0x24/0x68)
> > > [0.984269]  r6:c0892f6c r5: r4:c0b1bb24
> > > [0.988891] [] (mutex_lock) from [] 
> > > (perf_pmu_register+0x24/0x3e4)
> > > [0.996795]  r5: r4:ee98b014
> > > [1.000375] [] (perf_pmu_register) from [] 
> > > (cci_pmu_probe+0x340/0x484)
> > > [1.008631]  r10:c0892f6c r9:c0bfd5f0 r8:eea19010 r7:c0b261e4 
> > > r6:c0b26240 r5:eea19000
> > > [1.016447]  r4:ee98b010
> > > [1.018989] [] (cci_pmu_probe) from [] 
> > > (platform_drv_probe+0x58/0xb8)
> > > [1.027158]  r10: r9:c0b2610c r8: r7:fdfb 
> > > r6:c0b2610c r5:ffed
> > > [1.034974]  r4:eea19010
> > > [1.037511] [] (platform_drv_probe) from [] 
> > > (driver_probe_device+0x254/0x330)
> > > [1.046371]  r7: r6:c0bff498 r5:c0bff494 r4:eea19010
> > > [1.052026] [] (driver_probe_device) from [] 
> > > (__device_attach_driver+0xa0/0xd4)
> > > [1.061062]  r10: r9:c0bff470 r8: r7:0001 
> > > r6:eea19010 r5:ee845ac0
> > > [1.068879]  r4:c0b2610c r3:
> > > [1.072454] [] (__device_attach_driver) from [] 
> > > (bus_for_each_drv+0x68/0x9c)
> > > [1.081228]  r7:0001 r6:c045cb24 r5:ee845ac0 r4:
> > > [1.086883] [] (bus_for_each_drv) from [] 
> > > (__device_attach+0xb8/0x11c)
> > > [1.095135]  r6:c0b3e848 r5:eea19044 r4:eea19010
> > > [1.099750] [] (__device_attach) from [] 
> > > (device_initial_probe+0x14/0x18)
> > > [1.108263]  r7:c0b0a4c8 r6:c0b3e848 r5:eea19010 r4:eea19018
> > > [1.113919] [] (device_initial_probe) from [] 
> > > (bus_probe_device+0x8c/0x94)
> > > [1.122523] [] (bus_probe_device) from [] 
> > > (device_add+0x40c/0x5a0)
> > > [1.130429]  r7:c0b0a4c8 r6:eea19010 r5:eea18a10 r4:eea19018
> > > [1.136089] [] (device_add) from [] 
> > > 

Re: [PATCH 0/4] Sunxi: Add SMP support on A83T

[Mylene JOSSERAND]

Hello Corentin,

Le Fri, 15 Dec 2017 07:10:46 +0100,
Corentin Labbe  a écrit :
> On Tue, Dec 12, 2017 at 09:24:25AM +0100, Maxime Ripard wrote:
> > Hi,
> > 
> > On Mon, Dec 11, 2017 at 08:35:34PM +0100, Corentin Labbe wrote:  
> > > On Mon, Dec 11, 2017 at 08:49:57AM +0100, Mylène Josserand wrote:  
> > > > This series adds SMP support for Allwinner Sun8i-a83t
> > > > with MCPM (Multi-Cluster Power Management).
> > > > Series information:
> > > > - Based on last linux-next (next-20171211)
> > > > - Had dependencies on Chen Yu's patch that add MCPM
> > > > support:
> > > > https://patchwork.kernel.org/patch/6402801/
> > > > 
> > > > Patch 01: Convert the mcpm driver (initially for A80) to be able
> > > > to use it for A83T. This SoC has a bit flip that needs to be handled.
> > > > Patch 02: Add registers nodes (prcm, cpucfg and r_cpucfg) needed
> > > > for MCPM.
> > > > Patch 03: Add CCI-400 node for a83t.
> > > > Patch 04: Fix the use of virtual timers that hangs the kernel in
> > > > case of SMP support.  
> > > 
> > > As we discussed in private, Chen Yu's patch should be added in your 
> > > series.  
> > 
> > Not really, she mentionned the dependency in the cover letter, and
> > it's a good way to do things too. Sure, you can do it your way, but
> > there's no preference.
> >   
> 
> If the goal of this series is to be applied, the dependency must be applied 
> also.
> And since the dependency is 2 years old (and part of a serie which does not 
> apply now), I think cherry picking the patch and send it for review is better.
> 
> > > Furthermore, MCPM is not automaticaly selected via imply.  
> > 
> > Well, yes, is that an issue?
> >   
> 
> After reading the imply documentation, no.
> 
> > > With all patchs I hit a bug:
> > > [0.898668] BUG: sleeping function called from invalid context at 
> > > kernel/locking/mutex.c:238  
> > 
> > I guess this is with CONFIG_PROVE_LOCKING enabled?
> >   
> 
> No, the BUG() printed is enabled by default
> 
> > > [0.911162] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
> > > [0.917776] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
> > > 4.15.0-rc2-next-20171211+ #73  
> > 
> > What are the changes you've made?
> >   
> 
> Just adding wens's patch and this series.

I tried to reproduce your issue without success (even with
CONFIG_PROVE_LOCKING enabled, just in case).
Can you give me more details about your tests? which defconfig and
additional configurations?

> 
> > > [0.925418] Hardware name: Allwinner sun8i Family
> > > [0.930118] Backtrace: 
> > > [0.932596] [] (dump_backtrace) from [] 
> > > (show_stack+0x18/0x1c)
> > > [0.940158]  r7:c0b261e4 r6:6013 r5: r4:c0b51958
> > > [0.945820] [] (show_stack) from [] 
> > > (dump_stack+0x8c/0xa0)
> > > [0.953045] [] (dump_stack) from [] 
> > > (___might_sleep+0x150/0x170)
> > > [0.960779]  r7:c0b261e4 r6: r5:00ee r4:ee844000
> > > [0.966437] [] (___might_sleep) from [] 
> > > (__might_sleep+0x68/0xa0)
> > > [0.974253]  r4:c0861690
> > > [0.976796] [] (__might_sleep) from [] 
> > > (mutex_lock+0x24/0x68)
> > > [0.984269]  r6:c0892f6c r5: r4:c0b1bb24
> > > [0.988891] [] (mutex_lock) from [] 
> > > (perf_pmu_register+0x24/0x3e4)
> > > [0.996795]  r5: r4:ee98b014
> > > [1.000375] [] (perf_pmu_register) from [] 
> > > (cci_pmu_probe+0x340/0x484)
> > > [1.008631]  r10:c0892f6c r9:c0bfd5f0 r8:eea19010 r7:c0b261e4 
> > > r6:c0b26240 r5:eea19000
> > > [1.016447]  r4:ee98b010
> > > [1.018989] [] (cci_pmu_probe) from [] 
> > > (platform_drv_probe+0x58/0xb8)
> > > [1.027158]  r10: r9:c0b2610c r8: r7:fdfb 
> > > r6:c0b2610c r5:ffed
> > > [1.034974]  r4:eea19010
> > > [1.037511] [] (platform_drv_probe) from [] 
> > > (driver_probe_device+0x254/0x330)
> > > [1.046371]  r7: r6:c0bff498 r5:c0bff494 r4:eea19010
> > > [1.052026] [] (driver_probe_device) from [] 
> > > (__device_attach_driver+0xa0/0xd4)
> > > [1.061062]  r10: r9:c0bff470 r8: r7:0001 
> > > r6:eea19010 r5:ee845ac0
> > > [1.068879]  r4:c0b2610c r3:
> > > [1.072454] [] (__device_attach_driver) from [] 
> > > (bus_for_each_drv+0x68/0x9c)
> > > [1.081228]  r7:0001 r6:c045cb24 r5:ee845ac0 r4:
> > > [1.086883] [] (bus_for_each_drv) from [] 
> > > (__device_attach+0xb8/0x11c)
> > > [1.095135]  r6:c0b3e848 r5:eea19044 r4:eea19010
> > > [1.099750] [] (__device_attach) from [] 
> > > (device_initial_probe+0x14/0x18)
> > > [1.108263]  r7:c0b0a4c8 r6:c0b3e848 r5:eea19010 r4:eea19018
> > > [1.113919] [] (device_initial_probe) from [] 
> > > (bus_probe_device+0x8c/0x94)
> > > [1.122523] [] (bus_probe_device) from [] 
> > > (device_add+0x40c/0x5a0)
> > > [1.130429]  r7:c0b0a4c8 r6:eea19010 r5:eea18a10 r4:eea19018
> > > [1.136089] [] (device_add) from [] 
> > > (of_device_add+0x3c/0x44)
> > > [   

Re: [PATCH] pinctrl: axp209: dereference pointer after it's been set

[Mylene JOSSERAND]

Hello Quentin,

Le Wed, 13 Dec 2017 09:55:03 +0100,
Quentin Schulz  a écrit :

> The number of GPIOs is gotten from a field within the structure
> referenced in the of_device.data but it was actually read before it was
> retrieved, thus it was dereferencing a null pointer.
> 
> Set the number of GPIOs after retrieving of_device.data.
> 
> Fixes: e1190083b89b ("pinctrl: axp209: add support for AXP813 GPIOs")
> 
> Signed-off-by: Quentin Schulz 
> Reported-by: Mylène Josserand 

Tested-by: Mylène Josserand 

Thanks,

Mylène

> ---
>  drivers/pinctrl/pinctrl-axp209.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-axp209.c 
> b/drivers/pinctrl/pinctrl-axp209.c
> index 22d3bb0bf927..510a2821e910 100644
> --- a/drivers/pinctrl/pinctrl-axp209.c
> +++ b/drivers/pinctrl/pinctrl-axp209.c
> @@ -413,9 +413,11 @@ static int axp20x_pctl_probe(struct platform_device 
> *pdev)
>   pctl->chip.set  = axp20x_gpio_set;
>   pctl->chip.direction_input  = axp20x_gpio_input;
>   pctl->chip.direction_output = axp20x_gpio_output;
> - pctl->chip.ngpio= pctl->desc->npins;
>  
>   pctl->desc = (struct axp20x_pctrl_desc *)of_device_get_match_data(dev);
> +
> + pctl->chip.ngpio= pctl->desc->npins;
> +
>   pctl->regmap = axp20x->regmap;
>   pctl->dev = >dev;
>  

-- 
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH] pinctrl: axp209: dereference pointer after it's been set

[Mylene JOSSERAND]

Hello Quentin,

Le Wed, 13 Dec 2017 09:55:03 +0100,
Quentin Schulz  a écrit :

> The number of GPIOs is gotten from a field within the structure
> referenced in the of_device.data but it was actually read before it was
> retrieved, thus it was dereferencing a null pointer.
> 
> Set the number of GPIOs after retrieving of_device.data.
> 
> Fixes: e1190083b89b ("pinctrl: axp209: add support for AXP813 GPIOs")
> 
> Signed-off-by: Quentin Schulz 
> Reported-by: Mylène Josserand 

Tested-by: Mylène Josserand 

Thanks,

Mylène

> ---
>  drivers/pinctrl/pinctrl-axp209.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/pinctrl-axp209.c 
> b/drivers/pinctrl/pinctrl-axp209.c
> index 22d3bb0bf927..510a2821e910 100644
> --- a/drivers/pinctrl/pinctrl-axp209.c
> +++ b/drivers/pinctrl/pinctrl-axp209.c
> @@ -413,9 +413,11 @@ static int axp20x_pctl_probe(struct platform_device 
> *pdev)
>   pctl->chip.set  = axp20x_gpio_set;
>   pctl->chip.direction_input  = axp20x_gpio_input;
>   pctl->chip.direction_output = axp20x_gpio_output;
> - pctl->chip.ngpio= pctl->desc->npins;
>  
>   pctl->desc = (struct axp20x_pctrl_desc *)of_device_get_match_data(dev);
> +
> + pctl->chip.ngpio= pctl->desc->npins;
> +
>   pctl->regmap = axp20x->regmap;
>   pctl->dev = >dev;
>  

-- 
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 0/4] Sunxi: Add SMP support on A83T

[Mylene JOSSERAND]

Le Tue, 12 Dec 2017 10:40:25 +0100,
Mylene JOSSERAND <mylene.josser...@free-electrons.com> a écrit :

[...]

> I have done further tests.
> 
> I booted a previous kernel that I know it was working fine (kernel
> v4.13) then, I booted the kernel with this series and it worked just
> fine.
> 
> Only after a power cycle, I am able to reproduce the error, otherwise,
> it is working well. See the boot log of this two tests:
> http://code.bulix.org/7kr0e0-239697?raw

I wrote this mail too fast, I am wrong, the error I had/copied is not
the same error than Corentin is having (and I have 8 CPUS up).

-- 
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 0/4] Sunxi: Add SMP support on A83T

[Mylene JOSSERAND]

Le Tue, 12 Dec 2017 10:40:25 +0100,
Mylene JOSSERAND  a écrit :

[...]

> I have done further tests.
> 
> I booted a previous kernel that I know it was working fine (kernel
> v4.13) then, I booted the kernel with this series and it worked just
> fine.
> 
> Only after a power cycle, I am able to reproduce the error, otherwise,
> it is working well. See the boot log of this two tests:
> http://code.bulix.org/7kr0e0-239697?raw

I wrote this mail too fast, I am wrong, the error I had/copied is not
the same error than Corentin is having (and I have 8 CPUS up).

-- 
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 0/4] Sunxi: Add SMP support on A83T

[Mylene JOSSERAND]

Hi,

Le Mon, 11 Dec 2017 20:35:34 +0100,
Corentin Labbe  a écrit :
> On Mon, Dec 11, 2017 at 08:49:57AM +0100, Mylène Josserand wrote:
> > Hello everyone,
> > 
> > This series adds SMP support for Allwinner Sun8i-a83t
> > with MCPM (Multi-Cluster Power Management).
> > Series information:
> > - Based on last linux-next (next-20171211)
> > - Had dependencies on Chen Yu's patch that add MCPM
> > support:
> > https://patchwork.kernel.org/patch/6402801/
> > 
> > Patch 01: Convert the mcpm driver (initially for A80) to be able
> > to use it for A83T. This SoC has a bit flip that needs to be
> > handled. Patch 02: Add registers nodes (prcm, cpucfg and r_cpucfg)
> > needed for MCPM.
> > Patch 03: Add CCI-400 node for a83t.
> > Patch 04: Fix the use of virtual timers that hangs the kernel in
> > case of SMP support.
> > 
> > If you have any remarks/questions, let me know.
> > Thank you in advance,
> > Mylène
> >   
> 
> Hello
> 
> As we discussed in private, Chen Yu's patch should be added in your
> series.
> 
> Furthermore, MCPM is not automaticaly selected via imply.
> 
> With all patchs I hit a bug:
> [0.898668] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:238 [0.911162] in_atomic(): 1,
> irqs_disabled(): 0, pid: 1, name: swapper/0 [0.917776] CPU: 0
> PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-next-20171211+ #73
> [0.925418] Hardware name: Allwinner sun8i Family [0.930118]
> Backtrace: [0.932596] [] (dump_backtrace) from
> [] (show_stack+0x18/0x1c) [0.940158]  r7:c0b261e4
> r6:6013 r5: r4:c0b51958 [0.945820] []
> (show_stack) from [] (dump_stack+0x8c/0xa0) [0.953045]
> [] (dump_stack) from []
> (___might_sleep+0x150/0x170) [0.960779]  r7:c0b261e4 r6:
> r5:00ee r4:ee844000 [0.966437] [] (___might_sleep)
> from [] (__might_sleep+0x68/0xa0) [0.974253]
> r4:c0861690 [0.976796] [] (__might_sleep) from
> [] (mutex_lock+0x24/0x68) [0.984269]  r6:c0892f6c
> r5: r4:c0b1bb24 [0.988891] [] (mutex_lock) from
> [] (perf_pmu_register+0x24/0x3e4) [0.996795]
> r5: r4:ee98b014 [1.000375] []
> (perf_pmu_register) from [] (cci_pmu_probe+0x340/0x484)
> [1.008631]  r10:c0892f6c r9:c0bfd5f0 r8:eea19010 r7:c0b261e4
> r6:c0b26240 r5:eea19000 [1.016447]  r4:ee98b010 [1.018989]
> [] (cci_pmu_probe) from []
> (platform_drv_probe+0x58/0xb8) [1.027158]  r10:
> r9:c0b2610c r8: r7:fdfb r6:c0b2610c r5:ffed
> [1.034974]  r4:eea19010 [1.037511] []
> (platform_drv_probe) from []
> (driver_probe_device+0x254/0x330) [1.046371]  r7:
> r6:c0bff498 r5:c0bff494 r4:eea19010 [1.052026] []
> (driver_probe_device) from []
> (__device_attach_driver+0xa0/0xd4) [1.061062]  r10:
> r9:c0bff470 r8: r7:0001 r6:eea19010 r5:ee845ac0
> [1.068879]  r4:c0b2610c r3: [1.072454] []
> (__device_attach_driver) from []
> (bus_for_each_drv+0x68/0x9c) [1.081228]  r7:0001 r6:c045cb24
> r5:ee845ac0 r4: [1.086883] []
> (bus_for_each_drv) from [] (__device_attach+0xb8/0x11c)
> [1.095135]  r6:c0b3e848 r5:eea19044 r4:eea19010 [1.099750]
> [] (__device_attach) from []
> (device_initial_probe+0x14/0x18) [1.108263]  r7:c0b0a4c8
> r6:c0b3e848 r5:eea19010 r4:eea19018 [1.113919] []
> (device_initial_probe) from [] (bus_probe_device+0x8c/0x94)
> [1.122523] [] (bus_probe_device) from []
> (device_add+0x40c/0x5a0) [1.130429]  r7:c0b0a4c8 r6:eea19010
> r5:eea18a10 r4:eea19018 [1.136089] [] (device_add) from
> [] (of_device_add+0x3c/0x44) [1.143564]  r10:
> r9: r8: r7:eedf21a4 r6:eea18a10 r5:
> [1.151380]  r4:eea19000 [1.153915] []
> (of_device_add) from []
> (of_platform_device_create_pdata+0x7c/0xac) [1.163210]
> [] (of_platform_device_create_pdata) from []
> (of_platform_bus_create+0xf4/0x1f0) [1.173372]  r9:
> r8: r7:0001 r6: r5:eedf2154 r4:
> [1.181107] [] (of_platform_bus_create) from
> [] (of_platform_populate+0x74/0xd4) [1.190229]
> r10:0001 r9:eea18a10 r8: r7: r6:
> r5:eedf1d04 [1.198045]  r4:eedf2154 [1.200580] []
> (of_platform_populate) from []
> (cci_platform_probe+0x3c/0x54) [1.209356]  r10:
> r9:c0b26168 r8: r7:fdfb r6:c0b26168 r5:ffed
> [1.217172]  r4:eea18a00 [1.219708] []
> (cci_platform_probe) from [] (platform_drv_probe+0x58/0xb8)
> [1.228306]  r5:ffed r4:eea18a10 [1.231881] []
> (platform_drv_probe) from []
> (driver_probe_device+0x254/0x330) [1.240742]  r7:
> r6:c0bff498 r5:c0bff494 r4:eea18a10 [1.246397] []
> (driver_probe_device) from []
> (__device_attach_driver+0xa0/0xd4) [1.255433]  r10:
> r9:c0bff470 r8: r7:0001 r6:eea18a10 r5:ee845ce8
> [1.263250]  r4:c0b26168 r3: [1.266825] []
> 

Re: [PATCH 0/4] Sunxi: Add SMP support on A83T

[Mylene JOSSERAND]

Hi,

Le Mon, 11 Dec 2017 20:35:34 +0100,
Corentin Labbe  a écrit :
> On Mon, Dec 11, 2017 at 08:49:57AM +0100, Mylène Josserand wrote:
> > Hello everyone,
> > 
> > This series adds SMP support for Allwinner Sun8i-a83t
> > with MCPM (Multi-Cluster Power Management).
> > Series information:
> > - Based on last linux-next (next-20171211)
> > - Had dependencies on Chen Yu's patch that add MCPM
> > support:
> > https://patchwork.kernel.org/patch/6402801/
> > 
> > Patch 01: Convert the mcpm driver (initially for A80) to be able
> > to use it for A83T. This SoC has a bit flip that needs to be
> > handled. Patch 02: Add registers nodes (prcm, cpucfg and r_cpucfg)
> > needed for MCPM.
> > Patch 03: Add CCI-400 node for a83t.
> > Patch 04: Fix the use of virtual timers that hangs the kernel in
> > case of SMP support.
> > 
> > If you have any remarks/questions, let me know.
> > Thank you in advance,
> > Mylène
> >   
> 
> Hello
> 
> As we discussed in private, Chen Yu's patch should be added in your
> series.
> 
> Furthermore, MCPM is not automaticaly selected via imply.
> 
> With all patchs I hit a bug:
> [0.898668] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:238 [0.911162] in_atomic(): 1,
> irqs_disabled(): 0, pid: 1, name: swapper/0 [0.917776] CPU: 0
> PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-next-20171211+ #73
> [0.925418] Hardware name: Allwinner sun8i Family [0.930118]
> Backtrace: [0.932596] [] (dump_backtrace) from
> [] (show_stack+0x18/0x1c) [0.940158]  r7:c0b261e4
> r6:6013 r5: r4:c0b51958 [0.945820] []
> (show_stack) from [] (dump_stack+0x8c/0xa0) [0.953045]
> [] (dump_stack) from []
> (___might_sleep+0x150/0x170) [0.960779]  r7:c0b261e4 r6:
> r5:00ee r4:ee844000 [0.966437] [] (___might_sleep)
> from [] (__might_sleep+0x68/0xa0) [0.974253]
> r4:c0861690 [0.976796] [] (__might_sleep) from
> [] (mutex_lock+0x24/0x68) [0.984269]  r6:c0892f6c
> r5: r4:c0b1bb24 [0.988891] [] (mutex_lock) from
> [] (perf_pmu_register+0x24/0x3e4) [0.996795]
> r5: r4:ee98b014 [1.000375] []
> (perf_pmu_register) from [] (cci_pmu_probe+0x340/0x484)
> [1.008631]  r10:c0892f6c r9:c0bfd5f0 r8:eea19010 r7:c0b261e4
> r6:c0b26240 r5:eea19000 [1.016447]  r4:ee98b010 [1.018989]
> [] (cci_pmu_probe) from []
> (platform_drv_probe+0x58/0xb8) [1.027158]  r10:
> r9:c0b2610c r8: r7:fdfb r6:c0b2610c r5:ffed
> [1.034974]  r4:eea19010 [1.037511] []
> (platform_drv_probe) from []
> (driver_probe_device+0x254/0x330) [1.046371]  r7:
> r6:c0bff498 r5:c0bff494 r4:eea19010 [1.052026] []
> (driver_probe_device) from []
> (__device_attach_driver+0xa0/0xd4) [1.061062]  r10:
> r9:c0bff470 r8: r7:0001 r6:eea19010 r5:ee845ac0
> [1.068879]  r4:c0b2610c r3: [1.072454] []
> (__device_attach_driver) from []
> (bus_for_each_drv+0x68/0x9c) [1.081228]  r7:0001 r6:c045cb24
> r5:ee845ac0 r4: [1.086883] []
> (bus_for_each_drv) from [] (__device_attach+0xb8/0x11c)
> [1.095135]  r6:c0b3e848 r5:eea19044 r4:eea19010 [1.099750]
> [] (__device_attach) from []
> (device_initial_probe+0x14/0x18) [1.108263]  r7:c0b0a4c8
> r6:c0b3e848 r5:eea19010 r4:eea19018 [1.113919] []
> (device_initial_probe) from [] (bus_probe_device+0x8c/0x94)
> [1.122523] [] (bus_probe_device) from []
> (device_add+0x40c/0x5a0) [1.130429]  r7:c0b0a4c8 r6:eea19010
> r5:eea18a10 r4:eea19018 [1.136089] [] (device_add) from
> [] (of_device_add+0x3c/0x44) [1.143564]  r10:
> r9: r8: r7:eedf21a4 r6:eea18a10 r5:
> [1.151380]  r4:eea19000 [1.153915] []
> (of_device_add) from []
> (of_platform_device_create_pdata+0x7c/0xac) [1.163210]
> [] (of_platform_device_create_pdata) from []
> (of_platform_bus_create+0xf4/0x1f0) [1.173372]  r9:
> r8: r7:0001 r6: r5:eedf2154 r4:
> [1.181107] [] (of_platform_bus_create) from
> [] (of_platform_populate+0x74/0xd4) [1.190229]
> r10:0001 r9:eea18a10 r8: r7: r6:
> r5:eedf1d04 [1.198045]  r4:eedf2154 [1.200580] []
> (of_platform_populate) from []
> (cci_platform_probe+0x3c/0x54) [1.209356]  r10:
> r9:c0b26168 r8: r7:fdfb r6:c0b26168 r5:ffed
> [1.217172]  r4:eea18a00 [1.219708] []
> (cci_platform_probe) from [] (platform_drv_probe+0x58/0xb8)
> [1.228306]  r5:ffed r4:eea18a10 [1.231881] []
> (platform_drv_probe) from []
> (driver_probe_device+0x254/0x330) [1.240742]  r7:
> r6:c0bff498 r5:c0bff494 r4:eea18a10 [1.246397] []
> (driver_probe_device) from []
> (__device_attach_driver+0xa0/0xd4) [1.255433]  r10:
> r9:c0bff470 r8: r7:0001 r6:eea18a10 r5:ee845ce8
> [1.263250]  r4:c0b26168 r3: [1.266825] []
> (__device_attach_driver) from []
> 

Re: [PATCH 0/4] Sunxi: Add SMP support on A83T

[Mylene JOSSERAND]

Hello Corentin,

Le Mon, 11 Dec 2017 20:35:34 +0100,
Corentin Labbe  a écrit :

> On Mon, Dec 11, 2017 at 08:49:57AM +0100, Mylène Josserand wrote:
> > Hello everyone,
> > 
> > This series adds SMP support for Allwinner Sun8i-a83t
> > with MCPM (Multi-Cluster Power Management).
> > Series information:
> > - Based on last linux-next (next-20171211)
> > - Had dependencies on Chen Yu's patch that add MCPM
> > support:
> > https://patchwork.kernel.org/patch/6402801/
> > 
> > Patch 01: Convert the mcpm driver (initially for A80) to be able
> > to use it for A83T. This SoC has a bit flip that needs to be
> > handled. Patch 02: Add registers nodes (prcm, cpucfg and r_cpucfg)
> > needed for MCPM.
> > Patch 03: Add CCI-400 node for a83t.
> > Patch 04: Fix the use of virtual timers that hangs the kernel in
> > case of SMP support.
> > 
> > If you have any remarks/questions, let me know.
> > Thank you in advance,
> > Mylène
> >   
> 
> Hello
> 
> As we discussed in private, Chen Yu's patch should be added in your
> series.

Yep, I will do that.

> 
> Furthermore, MCPM is not automaticaly selected via imply.

It is selected if you run again a sunxi_defconfig. I guess I can change
to "select".

> 
> With all patchs I hit a bug:
> [0.898668] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:238 [0.911162] in_atomic(): 1,
> irqs_disabled(): 0, pid: 1, name: swapper/0 [0.917776] CPU: 0
> PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-next-20171211+ #73
> [0.925418] Hardware name: Allwinner sun8i Family [0.930118]
> Backtrace: [0.932596] [] (dump_backtrace) from
> [] (show_stack+0x18/0x1c) [0.940158]  r7:c0b261e4
> r6:6013 r5: r4:c0b51958 [0.945820] []
> (show_stack) from [] (dump_stack+0x8c/0xa0) [0.953045]
> [] (dump_stack) from []
> (___might_sleep+0x150/0x170) [0.960779]  r7:c0b261e4 r6:
> r5:00ee r4:ee844000 [0.966437] [] (___might_sleep)
> from [] (__might_sleep+0x68/0xa0) [0.974253]
> r4:c0861690 [0.976796] [] (__might_sleep) from
> [] (mutex_lock+0x24/0x68) [0.984269]  r6:c0892f6c
> r5: r4:c0b1bb24 [0.988891] [] (mutex_lock) from
> [] (perf_pmu_register+0x24/0x3e4) [0.996795]
> r5: r4:ee98b014 [1.000375] []
> (perf_pmu_register) from [] (cci_pmu_probe+0x340/0x484)
> [1.008631]  r10:c0892f6c r9:c0bfd5f0 r8:eea19010 r7:c0b261e4
> r6:c0b26240 r5:eea19000 [1.016447]  r4:ee98b010 [1.018989]
> [] (cci_pmu_probe) from []
> (platform_drv_probe+0x58/0xb8) [1.027158]  r10:
> r9:c0b2610c r8: r7:fdfb r6:c0b2610c r5:ffed
> [1.034974]  r4:eea19010 [1.037511] []
> (platform_drv_probe) from []
> (driver_probe_device+0x254/0x330) [1.046371]  r7:
> r6:c0bff498 r5:c0bff494 r4:eea19010 [1.052026] []
> (driver_probe_device) from []
> (__device_attach_driver+0xa0/0xd4) [1.061062]  r10:
> r9:c0bff470 r8: r7:0001 r6:eea19010 r5:ee845ac0
> [1.068879]  r4:c0b2610c r3: [1.072454] []
> (__device_attach_driver) from []
> (bus_for_each_drv+0x68/0x9c) [1.081228]  r7:0001 r6:c045cb24
> r5:ee845ac0 r4: [1.086883] []
> (bus_for_each_drv) from [] (__device_attach+0xb8/0x11c)
> [1.095135]  r6:c0b3e848 r5:eea19044 r4:eea19010 [1.099750]
> [] (__device_attach) from []
> (device_initial_probe+0x14/0x18) [1.108263]  r7:c0b0a4c8
> r6:c0b3e848 r5:eea19010 r4:eea19018 [1.113919] []
> (device_initial_probe) from [] (bus_probe_device+0x8c/0x94)
> [1.122523] [] (bus_probe_device) from []
> (device_add+0x40c/0x5a0) [1.130429]  r7:c0b0a4c8 r6:eea19010
> r5:eea18a10 r4:eea19018 [1.136089] [] (device_add) from
> [] (of_device_add+0x3c/0x44) [1.143564]  r10:
> r9: r8: r7:eedf21a4 r6:eea18a10 r5:
> [1.151380]  r4:eea19000 [1.153915] []
> (of_device_add) from []
> (of_platform_device_create_pdata+0x7c/0xac) [1.163210]
> [] (of_platform_device_create_pdata) from []
> (of_platform_bus_create+0xf4/0x1f0) [1.173372]  r9:
> r8: r7:0001 r6: r5:eedf2154 r4:
> [1.181107] [] (of_platform_bus_create) from
> [] (of_platform_populate+0x74/0xd4) [1.190229]
> r10:0001 r9:eea18a10 r8: r7: r6:
> r5:eedf1d04 [1.198045]  r4:eedf2154 [1.200580] []
> (of_platform_populate) from []
> (cci_platform_probe+0x3c/0x54) [1.209356]  r10:
> r9:c0b26168 r8: r7:fdfb r6:c0b26168 r5:ffed
> [1.217172]  r4:eea18a00 [1.219708] []
> (cci_platform_probe) from [] (platform_drv_probe+0x58/0xb8)
> [1.228306]  r5:ffed r4:eea18a10 [1.231881] []
> (platform_drv_probe) from []
> (driver_probe_device+0x254/0x330) [1.240742]  r7:
> r6:c0bff498 r5:c0bff494 r4:eea18a10 [1.246397] []
> (driver_probe_device) from []
> (__device_attach_driver+0xa0/0xd4) [1.255433]  r10:
> r9:c0bff470 

Re: [PATCH 0/4] Sunxi: Add SMP support on A83T

[Mylene JOSSERAND]

Hello Corentin,

Le Mon, 11 Dec 2017 20:35:34 +0100,
Corentin Labbe  a écrit :

> On Mon, Dec 11, 2017 at 08:49:57AM +0100, Mylène Josserand wrote:
> > Hello everyone,
> > 
> > This series adds SMP support for Allwinner Sun8i-a83t
> > with MCPM (Multi-Cluster Power Management).
> > Series information:
> > - Based on last linux-next (next-20171211)
> > - Had dependencies on Chen Yu's patch that add MCPM
> > support:
> > https://patchwork.kernel.org/patch/6402801/
> > 
> > Patch 01: Convert the mcpm driver (initially for A80) to be able
> > to use it for A83T. This SoC has a bit flip that needs to be
> > handled. Patch 02: Add registers nodes (prcm, cpucfg and r_cpucfg)
> > needed for MCPM.
> > Patch 03: Add CCI-400 node for a83t.
> > Patch 04: Fix the use of virtual timers that hangs the kernel in
> > case of SMP support.
> > 
> > If you have any remarks/questions, let me know.
> > Thank you in advance,
> > Mylène
> >   
> 
> Hello
> 
> As we discussed in private, Chen Yu's patch should be added in your
> series.

Yep, I will do that.

> 
> Furthermore, MCPM is not automaticaly selected via imply.

It is selected if you run again a sunxi_defconfig. I guess I can change
to "select".

> 
> With all patchs I hit a bug:
> [0.898668] BUG: sleeping function called from invalid context at
> kernel/locking/mutex.c:238 [0.911162] in_atomic(): 1,
> irqs_disabled(): 0, pid: 1, name: swapper/0 [0.917776] CPU: 0
> PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2-next-20171211+ #73
> [0.925418] Hardware name: Allwinner sun8i Family [0.930118]
> Backtrace: [0.932596] [] (dump_backtrace) from
> [] (show_stack+0x18/0x1c) [0.940158]  r7:c0b261e4
> r6:6013 r5: r4:c0b51958 [0.945820] []
> (show_stack) from [] (dump_stack+0x8c/0xa0) [0.953045]
> [] (dump_stack) from []
> (___might_sleep+0x150/0x170) [0.960779]  r7:c0b261e4 r6:
> r5:00ee r4:ee844000 [0.966437] [] (___might_sleep)
> from [] (__might_sleep+0x68/0xa0) [0.974253]
> r4:c0861690 [0.976796] [] (__might_sleep) from
> [] (mutex_lock+0x24/0x68) [0.984269]  r6:c0892f6c
> r5: r4:c0b1bb24 [0.988891] [] (mutex_lock) from
> [] (perf_pmu_register+0x24/0x3e4) [0.996795]
> r5: r4:ee98b014 [1.000375] []
> (perf_pmu_register) from [] (cci_pmu_probe+0x340/0x484)
> [1.008631]  r10:c0892f6c r9:c0bfd5f0 r8:eea19010 r7:c0b261e4
> r6:c0b26240 r5:eea19000 [1.016447]  r4:ee98b010 [1.018989]
> [] (cci_pmu_probe) from []
> (platform_drv_probe+0x58/0xb8) [1.027158]  r10:
> r9:c0b2610c r8: r7:fdfb r6:c0b2610c r5:ffed
> [1.034974]  r4:eea19010 [1.037511] []
> (platform_drv_probe) from []
> (driver_probe_device+0x254/0x330) [1.046371]  r7:
> r6:c0bff498 r5:c0bff494 r4:eea19010 [1.052026] []
> (driver_probe_device) from []
> (__device_attach_driver+0xa0/0xd4) [1.061062]  r10:
> r9:c0bff470 r8: r7:0001 r6:eea19010 r5:ee845ac0
> [1.068879]  r4:c0b2610c r3: [1.072454] []
> (__device_attach_driver) from []
> (bus_for_each_drv+0x68/0x9c) [1.081228]  r7:0001 r6:c045cb24
> r5:ee845ac0 r4: [1.086883] []
> (bus_for_each_drv) from [] (__device_attach+0xb8/0x11c)
> [1.095135]  r6:c0b3e848 r5:eea19044 r4:eea19010 [1.099750]
> [] (__device_attach) from []
> (device_initial_probe+0x14/0x18) [1.108263]  r7:c0b0a4c8
> r6:c0b3e848 r5:eea19010 r4:eea19018 [1.113919] []
> (device_initial_probe) from [] (bus_probe_device+0x8c/0x94)
> [1.122523] [] (bus_probe_device) from []
> (device_add+0x40c/0x5a0) [1.130429]  r7:c0b0a4c8 r6:eea19010
> r5:eea18a10 r4:eea19018 [1.136089] [] (device_add) from
> [] (of_device_add+0x3c/0x44) [1.143564]  r10:
> r9: r8: r7:eedf21a4 r6:eea18a10 r5:
> [1.151380]  r4:eea19000 [1.153915] []
> (of_device_add) from []
> (of_platform_device_create_pdata+0x7c/0xac) [1.163210]
> [] (of_platform_device_create_pdata) from []
> (of_platform_bus_create+0xf4/0x1f0) [1.173372]  r9:
> r8: r7:0001 r6: r5:eedf2154 r4:
> [1.181107] [] (of_platform_bus_create) from
> [] (of_platform_populate+0x74/0xd4) [1.190229]
> r10:0001 r9:eea18a10 r8: r7: r6:
> r5:eedf1d04 [1.198045]  r4:eedf2154 [1.200580] []
> (of_platform_populate) from []
> (cci_platform_probe+0x3c/0x54) [1.209356]  r10:
> r9:c0b26168 r8: r7:fdfb r6:c0b26168 r5:ffed
> [1.217172]  r4:eea18a00 [1.219708] []
> (cci_platform_probe) from [] (platform_drv_probe+0x58/0xb8)
> [1.228306]  r5:ffed r4:eea18a10 [1.231881] []
> (platform_drv_probe) from []
> (driver_probe_device+0x254/0x330) [1.240742]  r7:
> r6:c0bff498 r5:c0bff494 r4:eea18a10 [1.246397] []
> (driver_probe_device) from []
> (__device_attach_driver+0xa0/0xd4) [1.255433]  r10:
> r9:c0bff470 r8: r7:0001 

Re: [PATCH 0/5] sun8i-a83t: Add touchscreen support on TBS A711

[Mylene JOSSERAND]

Hi,

Le Fri,  8 Dec 2017 22:54:14 +0100,
Mylène Josserand  a écrit :

> Hello everyone,
> 
> This patch series adds touchscreen support (FocalTech EDT-FT5x06
> Polytouch) for TBS A711 (Allwinner sun8i-a83t SoC).
> This touchscreen is using i2c so this series adds support of this bus
> on A83T.
> 
> Series information:
>- Based on last linux-next (next-20171208)
>- Had dependencies on AXP209 Quentin Schultz's series:
>https://www.spinics.net/lists/linux-gpio/msg26913.htmlx

I forgot to mention a dependency on Maxime Ripard's patch that
reinstate AXP813 PMIC:
https://patchwork.kernel.org/patch/10077037/

Thanks,

Mylène

> 
> Patch 01: Add i2c0 node on a83t device tree.
> Patch 02: Add i2c0 pin group.
> Patch 03: Enable i2c0 on TBS A711.
> Patch 04: Add support for regulator in the FocalTech touchscreen
> driver because A711 tablet is using a regulator to power-up the
> touchscreen. Patch 05: Add the touchscreen node in A711 TBS tablet.
> 
> Thank you in advance for any review.
> Best regards,
> Mylène
> 
> Mylène Josserand (5):
>   arm: dts: sun8i: a83t: Add I2C0 node
>   arm: dts: sun8i: a83t: Add I2C0 pins group
>   arm: dts: sun8i: a83t: a711: Enable I2C0
>   Input: edt-ft5x06 - Add support for regulator
>   arm: dts: sun8i: a83t: a711: Add touchscreen node
> 
>  arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 18 +
>  arch/arm/boot/dts/sun8i-a83t.dtsi | 16 +++
>  drivers/input/touchscreen/edt-ft5x06.c| 33
> +++ 3 files changed, 67 insertions(+)
> 

Re: [PATCH 0/5] sun8i-a83t: Add touchscreen support on TBS A711

[Mylene JOSSERAND]

Hi,

Le Fri,  8 Dec 2017 22:54:14 +0100,
Mylène Josserand  a écrit :

> Hello everyone,
> 
> This patch series adds touchscreen support (FocalTech EDT-FT5x06
> Polytouch) for TBS A711 (Allwinner sun8i-a83t SoC).
> This touchscreen is using i2c so this series adds support of this bus
> on A83T.
> 
> Series information:
>- Based on last linux-next (next-20171208)
>- Had dependencies on AXP209 Quentin Schultz's series:
>https://www.spinics.net/lists/linux-gpio/msg26913.htmlx

I forgot to mention a dependency on Maxime Ripard's patch that
reinstate AXP813 PMIC:
https://patchwork.kernel.org/patch/10077037/

Thanks,

Mylène

> 
> Patch 01: Add i2c0 node on a83t device tree.
> Patch 02: Add i2c0 pin group.
> Patch 03: Enable i2c0 on TBS A711.
> Patch 04: Add support for regulator in the FocalTech touchscreen
> driver because A711 tablet is using a regulator to power-up the
> touchscreen. Patch 05: Add the touchscreen node in A711 TBS tablet.
> 
> Thank you in advance for any review.
> Best regards,
> Mylène
> 
> Mylène Josserand (5):
>   arm: dts: sun8i: a83t: Add I2C0 node
>   arm: dts: sun8i: a83t: Add I2C0 pins group
>   arm: dts: sun8i: a83t: a711: Enable I2C0
>   Input: edt-ft5x06 - Add support for regulator
>   arm: dts: sun8i: a83t: a711: Add touchscreen node
> 
>  arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 18 +
>  arch/arm/boot/dts/sun8i-a83t.dtsi | 16 +++
>  drivers/input/touchscreen/edt-ft5x06.c| 33
> +++ 3 files changed, 67 insertions(+)
> 

Re: [PATCH] clk: sunxi-ng: a83t: Fix i2c buses bits

[Mylene JOSSERAND]

Hello,

Le Fri, 3 Nov 2017 08:11:00 -0700,
Stephen Boyd  a écrit :

> On 11/03, Mylène Josserand wrote:
> > i2c1 and i2c2 bits for CCU are not bit 0 but bit 1 and bit 2.
> > Because of that, the i2c0 (bit 0) was not correctly configured.
> > Fixed the correct bits for i2c1 and i2c2.
> > 
> > Signed-off-by: Mylène Josserand
> >  ---  
> 
> Please add a Fixes tag.
> 

Sure, I will resend the patch with a Fixes tag.

Thank you,

-- 
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH] clk: sunxi-ng: a83t: Fix i2c buses bits

[Mylene JOSSERAND]

Hello,

Le Fri, 3 Nov 2017 08:11:00 -0700,
Stephen Boyd  a écrit :

> On 11/03, Mylène Josserand wrote:
> > i2c1 and i2c2 bits for CCU are not bit 0 but bit 1 and bit 2.
> > Because of that, the i2c0 (bit 0) was not correctly configured.
> > Fixed the correct bits for i2c1 and i2c2.
> > 
> > Signed-off-by: Mylène Josserand
> >  ---  
> 
> Please add a Fixes tag.
> 

Sure, I will resend the patch with a Fixes tag.

Thank you,

-- 
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

[Mylene JOSSERAND]

Hello Yong,

Thank you for these drivers!

I tested it with an OV5640 camera on an Nanopi M1 plus (Allwinner H3)
and I noticed that I got a frame correctly displayed only on a half of
the frame's size.

It is related to your "sun6i_csi_set_window" function (see
below).

> Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> and CSI1 is used for parallel interface. This is not documented in
> datasheet but by testing and guess.
> 
> This patch implement a v4l2 framework driver for it.
> 
> Currently, the driver only support the parallel interface. MIPI-CSI2,
> ISP's support are not included in this patch.
> 
> Signed-off-by: Yong Deng 
> ---
>  drivers/media/platform/Kconfig   |   1 +
>  drivers/media/platform/Makefile  |   2 +
>  drivers/media/platform/sun6i-csi/Kconfig |   9 +
>  drivers/media/platform/sun6i-csi/Makefile|   3 +
>  drivers/media/platform/sun6i-csi/sun6i_csi.c | 545
> +++ drivers/media/platform/sun6i-csi/sun6i_csi.h |
> 203 ++ drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c | 827
> +++
> drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h | 206 ++
> drivers/media/platform/sun6i-csi/sun6i_video.c   | 663
> ++ drivers/media/platform/sun6i-csi/sun6i_video.h
> |  61 ++ 10 files changed, 2520 insertions(+) create mode 100644
> drivers/media/platform/sun6i-csi/Kconfig create mode 100644
> drivers/media/platform/sun6i-csi/Makefile create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_csi.c create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_csi.h create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_video.c create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_video.h
> 
> diff --git a/drivers/media/platform/Kconfig
> b/drivers/media/platform/Kconfig index 0c741d1..8371a87 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -143,6 +143,7 @@ source "drivers/media/platform/am437x/Kconfig"
>  source "drivers/media/platform/xilinx/Kconfig"
>  source "drivers/media/platform/rcar-vin/Kconfig"
>  source "drivers/media/platform/atmel/Kconfig"
> +source "drivers/media/platform/sun6i-csi/Kconfig"
>  



> +static void sun6i_csi_set_format(struct sun6i_csi_dev *sdev)
> +{
> + struct sun6i_csi *csi = >csi;
> + u32 cfg;
> + u32 val;
> +
> + regmap_read(sdev->regmap, CSI_CH_CFG_REG, );
> +
> + cfg &= ~(CSI_CH_CFG_INPUT_FMT_MASK |
> +  CSI_CH_CFG_OUTPUT_FMT_MASK | CSI_CH_CFG_VFLIP_EN |
> +  CSI_CH_CFG_HFLIP_EN | CSI_CH_CFG_FIELD_SEL_MASK |
> +  CSI_CH_CFG_INPUT_SEQ_MASK);
> +
> + val = get_csi_input_format(csi->config.code,
> csi->config.pixelformat);
> + cfg |= CSI_CH_CFG_INPUT_FMT(val);
> +
> + val = get_csi_output_format(csi->config.code,
> csi->config.field);
> + cfg |= CSI_CH_CFG_OUTPUT_FMT(val);
> +
> + val = get_csi_input_seq(csi->config.code,
> csi->config.pixelformat);
> + cfg |= CSI_CH_CFG_INPUT_SEQ(val);
> +
> + if (csi->config.field == V4L2_FIELD_TOP)
> + cfg |= CSI_CH_CFG_FIELD_SEL_FIELD0;
> + else if (csi->config.field == V4L2_FIELD_BOTTOM)
> + cfg |= CSI_CH_CFG_FIELD_SEL_FIELD1;
> + else
> + cfg |= CSI_CH_CFG_FIELD_SEL_BOTH;
> +
> + regmap_write(sdev->regmap, CSI_CH_CFG_REG, cfg);
> +}
> +
> +static void sun6i_csi_set_window(struct sun6i_csi_dev *sdev)
> +{
> + struct sun6i_csi_config *config = >csi.config;
> + u32 bytesperline_y;
> + u32 bytesperline_c;
> + int *planar_offset = sdev->planar_offset;
> +
> + regmap_write(sdev->regmap, CSI_CH_HSIZE_REG,
> +  CSI_CH_HSIZE_HOR_LEN(config->width) |
> +  CSI_CH_HSIZE_HOR_START(0));
> + regmap_write(sdev->regmap, CSI_CH_VSIZE_REG,
> +  CSI_CH_VSIZE_VER_LEN(config->height) |
> +  CSI_CH_VSIZE_VER_START(0));

In my case, the HOR_LEN and VER_LEN were not correctly configured.

They were configured to width and height (640 * 480) but as I was
using a YUYV format, the pixel's size is 2 bytes so the
horizontal/vertical lines' lengths were divided by 2.

Currently, I fixed that by getting the number of bytes per pixel with
"v4l2_pixformat_get_bpp()":

+   int bytes_pixel;
+
+   bytes_pixel = v4l2_pixformat_get_bpp(config->pixelformat) / 8;
 
regmap_write(sdev->regmap, CSI_CH_HSIZE_REG,
-CSI_CH_HSIZE_HOR_LEN(config->width) |
+CSI_CH_HSIZE_HOR_LEN(config->width * bytes_pixel) |
 CSI_CH_HSIZE_HOR_START(0));
regmap_write(sdev->regmap, CSI_CH_VSIZE_REG,
-CSI_CH_VSIZE_VER_LEN(config->height) |
+CSI_CH_VSIZE_VER_LEN(config->height * bytes_pixel)
  | CSI_CH_VSIZE_VER_START(0));

Re: [PATCH v2 1/3] media: V3s: Add support for Allwinner CSI.

[Mylene JOSSERAND]

Hello Yong,

Thank you for these drivers!

I tested it with an OV5640 camera on an Nanopi M1 plus (Allwinner H3)
and I noticed that I got a frame correctly displayed only on a half of
the frame's size.

It is related to your "sun6i_csi_set_window" function (see
below).

> Allwinner V3s SoC have two CSI module. CSI0 is used for MIPI interface
> and CSI1 is used for parallel interface. This is not documented in
> datasheet but by testing and guess.
> 
> This patch implement a v4l2 framework driver for it.
> 
> Currently, the driver only support the parallel interface. MIPI-CSI2,
> ISP's support are not included in this patch.
> 
> Signed-off-by: Yong Deng 
> ---
>  drivers/media/platform/Kconfig   |   1 +
>  drivers/media/platform/Makefile  |   2 +
>  drivers/media/platform/sun6i-csi/Kconfig |   9 +
>  drivers/media/platform/sun6i-csi/Makefile|   3 +
>  drivers/media/platform/sun6i-csi/sun6i_csi.c | 545
> +++ drivers/media/platform/sun6i-csi/sun6i_csi.h |
> 203 ++ drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c | 827
> +++
> drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h | 206 ++
> drivers/media/platform/sun6i-csi/sun6i_video.c   | 663
> ++ drivers/media/platform/sun6i-csi/sun6i_video.h
> |  61 ++ 10 files changed, 2520 insertions(+) create mode 100644
> drivers/media/platform/sun6i-csi/Kconfig create mode 100644
> drivers/media/platform/sun6i-csi/Makefile create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_csi.c create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_csi.h create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_csi_v3s.c create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_csi_v3s.h create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_video.c create mode 100644
> drivers/media/platform/sun6i-csi/sun6i_video.h
> 
> diff --git a/drivers/media/platform/Kconfig
> b/drivers/media/platform/Kconfig index 0c741d1..8371a87 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -143,6 +143,7 @@ source "drivers/media/platform/am437x/Kconfig"
>  source "drivers/media/platform/xilinx/Kconfig"
>  source "drivers/media/platform/rcar-vin/Kconfig"
>  source "drivers/media/platform/atmel/Kconfig"
> +source "drivers/media/platform/sun6i-csi/Kconfig"
>  



> +static void sun6i_csi_set_format(struct sun6i_csi_dev *sdev)
> +{
> + struct sun6i_csi *csi = >csi;
> + u32 cfg;
> + u32 val;
> +
> + regmap_read(sdev->regmap, CSI_CH_CFG_REG, );
> +
> + cfg &= ~(CSI_CH_CFG_INPUT_FMT_MASK |
> +  CSI_CH_CFG_OUTPUT_FMT_MASK | CSI_CH_CFG_VFLIP_EN |
> +  CSI_CH_CFG_HFLIP_EN | CSI_CH_CFG_FIELD_SEL_MASK |
> +  CSI_CH_CFG_INPUT_SEQ_MASK);
> +
> + val = get_csi_input_format(csi->config.code,
> csi->config.pixelformat);
> + cfg |= CSI_CH_CFG_INPUT_FMT(val);
> +
> + val = get_csi_output_format(csi->config.code,
> csi->config.field);
> + cfg |= CSI_CH_CFG_OUTPUT_FMT(val);
> +
> + val = get_csi_input_seq(csi->config.code,
> csi->config.pixelformat);
> + cfg |= CSI_CH_CFG_INPUT_SEQ(val);
> +
> + if (csi->config.field == V4L2_FIELD_TOP)
> + cfg |= CSI_CH_CFG_FIELD_SEL_FIELD0;
> + else if (csi->config.field == V4L2_FIELD_BOTTOM)
> + cfg |= CSI_CH_CFG_FIELD_SEL_FIELD1;
> + else
> + cfg |= CSI_CH_CFG_FIELD_SEL_BOTH;
> +
> + regmap_write(sdev->regmap, CSI_CH_CFG_REG, cfg);
> +}
> +
> +static void sun6i_csi_set_window(struct sun6i_csi_dev *sdev)
> +{
> + struct sun6i_csi_config *config = >csi.config;
> + u32 bytesperline_y;
> + u32 bytesperline_c;
> + int *planar_offset = sdev->planar_offset;
> +
> + regmap_write(sdev->regmap, CSI_CH_HSIZE_REG,
> +  CSI_CH_HSIZE_HOR_LEN(config->width) |
> +  CSI_CH_HSIZE_HOR_START(0));
> + regmap_write(sdev->regmap, CSI_CH_VSIZE_REG,
> +  CSI_CH_VSIZE_VER_LEN(config->height) |
> +  CSI_CH_VSIZE_VER_START(0));

In my case, the HOR_LEN and VER_LEN were not correctly configured.

They were configured to width and height (640 * 480) but as I was
using a YUYV format, the pixel's size is 2 bytes so the
horizontal/vertical lines' lengths were divided by 2.

Currently, I fixed that by getting the number of bytes per pixel with
"v4l2_pixformat_get_bpp()":

+   int bytes_pixel;
+
+   bytes_pixel = v4l2_pixformat_get_bpp(config->pixelformat) / 8;
 
regmap_write(sdev->regmap, CSI_CH_HSIZE_REG,
-CSI_CH_HSIZE_HOR_LEN(config->width) |
+CSI_CH_HSIZE_HOR_LEN(config->width * bytes_pixel) |
 CSI_CH_HSIZE_HOR_START(0));
regmap_write(sdev->regmap, CSI_CH_VSIZE_REG,
-CSI_CH_VSIZE_VER_LEN(config->height) |
+CSI_CH_VSIZE_VER_LEN(config->height * bytes_pixel)
  | CSI_CH_VSIZE_VER_START(0));

There is certainly a 

Re: [PATCH v3] phy: allwinner: phy-sun4i-usb: Add log when probing

[Mylene Josserand]

Hi,

On 04/07/2017 14:37, Quentin Schulz wrote:

When phy-sun4i-usb's probing fails, it does not print the reason in
kernel log, forcing the developer to edit this driver to add info logs.
This commit makes the kernel print the reason of phy-sun4i-usb's probing
failure or a success message.

Signed-off-by: Quentin Schulz 


Tested-by: Mylène Josserand 

Thanks!

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v3] phy: allwinner: phy-sun4i-usb: Add log when probing

[Mylene Josserand]

Hi,

On 04/07/2017 14:37, Quentin Schulz wrote:

When phy-sun4i-usb's probing fails, it does not print the reason in
kernel log, forcing the developer to edit this driver to add info logs.
This commit makes the kernel print the reason of phy-sun4i-usb's probing
failure or a success message.

Signed-off-by: Quentin Schulz 


Tested-by: Mylène Josserand 

Thanks!

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 2/2] Documentation: DT: bindings: input: Add documentation for cyttsp5

[Mylene Josserand]

Hi Dmitry,

Thank you for the review!

On 07/06/2017 22:40, Dmitry Torokhov wrote:

On Wed, Jun 07, 2017 at 03:26:03PM -0500, Rob Herring wrote:

On Mon, May 29, 2017 at 04:45:38PM +0200, Mylène Josserand wrote:

Add the Cypress TrueTouch Generation 5 touchscreen device tree bindings
documentation. It can use I2C or SPI bus.
This touchscreen can handle some defined zone that are designed and
sent as button. To be able to customize the keycode sent, the
"linux,code" property in a "button" sub-node can be used.


"documentation" twice in the subject makes for a long subject.
The preferred subject prefix is "dt-bindings: input: ..."



Signed-off-by: Mylène Josserand 
---
 .../bindings/input/touchscreen/cyttsp5.txt | 55 ++


cypress,cyttsp5.txt matching the compatible is preferred.


 1 file changed, 55 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/cyttsp5.txt

diff --git a/Documentation/devicetree/bindings/input/touchscreen/cyttsp5.txt 
b/Documentation/devicetree/bindings/input/touchscreen/cyttsp5.txt
new file mode 100644
index ..713a377b5039
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/cyttsp5.txt
@@ -0,0 +1,55 @@
+* Cypress cyttsp touchscreen controller, generation 5
+
+Required properties:
+ - compatible  : must be "cypress,cyttsp5"
+ - reg : Device I2C address or SPI chip select number
+ - interrupt-parent: the phandle for the gpio controller
+ (see interrupt binding[0]).
+ - interrupts  : (gpio) interrupt to which the chip is connected
+ (see interrupt binding[0]).
+
+Optional properties (many of them coming from touchscreen binding[1]):
+ - reset-gpios : the reset gpio the chip is connected to
+ (see GPIO binding[2] for more details).
+ - touchscreen-size-x  : horizontal resolution of touchscreen (in pixels)


Just "see ./touchscreen.txt" is enough description.


+ - touchscreen-size-y  : vertical resolution of touchscreen (in pixels)
+ - touchscreen-fuzz-x  : horizontal noise value of the absolute input device
+ (in pixels)
+ - touchscreen-fuzz-y  : vertical noise value of the absolute input device
+ (in pixels)
+
+This touchscreen can handle some buttons that are touchscreen's defined zones.
+Each button's event can be customized using a sub-node properties:
+   - linux,code: Keycode to emit.
+
+[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+[2]: Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+ {
+   [...]
+
+   tsc@24 {


touchscreen@24


+   compatible = "cypress,cyttsp5";
+   reg = <0x24>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_reset_ds203>;
+   interrupt-parent = <>;
+   interrupts = <1 5 IRQ_TYPE_LEVEL_LOW>;
+   reset-gpios = < 7 1 GPIO_ACTIVE_HIGH>;
+
+   button@0 {


unit addresses need a reg property. If 0,1,2 are meaningful numbers for
the hardware, then it makes sense to add here.


Another option would be just say:

linux,keycodes = , , ;


Sure. I noticed the "linux,code" property so I used that one but I did 
not see the "linux,keycodes". I guess it is possible to group all the 
keycodes using that property.




I am wondering though: you read number of button supported by the device
from HID_SYSINFO_BTN_OFFSET, can you also get button assignment form
the device as well?


For what I know, it is not possible. We can only retrieve the number of 
buttons configured for one device but not keycodes.




And the biggest question of all: since you refer to HID descriptors in
your driver, is it a HID device and should it be driven by HID susbystem
instead of relying on a custom driver?


I am not familiar with HID subsytem but I looked to other HID drivers 
and read the kernel documentation.
In the datasheet, there is no reference to the HID specification and, 
for example, there is no GET/SET_REPORT requests. There is one "HID 
descriptor register" but that is all.


I guess that it is not a HID device but do not hesitate to give me hints 
to look at it, if you want me to confirm it.







+   linux,code = ;
+   };
+
+   button@1 {
+   linux,code = ;
+   };
+
+   button@2 {
+   linux,code = ;
+   };
+   };
+};
--
2.11.0



Thanks.



Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 2/2] Documentation: DT: bindings: input: Add documentation for cyttsp5

[Mylene Josserand]

Hi Dmitry,

Thank you for the review!

On 07/06/2017 22:40, Dmitry Torokhov wrote:

On Wed, Jun 07, 2017 at 03:26:03PM -0500, Rob Herring wrote:

On Mon, May 29, 2017 at 04:45:38PM +0200, Mylène Josserand wrote:

Add the Cypress TrueTouch Generation 5 touchscreen device tree bindings
documentation. It can use I2C or SPI bus.
This touchscreen can handle some defined zone that are designed and
sent as button. To be able to customize the keycode sent, the
"linux,code" property in a "button" sub-node can be used.


"documentation" twice in the subject makes for a long subject.
The preferred subject prefix is "dt-bindings: input: ..."



Signed-off-by: Mylène Josserand 
---
 .../bindings/input/touchscreen/cyttsp5.txt | 55 ++


cypress,cyttsp5.txt matching the compatible is preferred.


 1 file changed, 55 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/cyttsp5.txt

diff --git a/Documentation/devicetree/bindings/input/touchscreen/cyttsp5.txt 
b/Documentation/devicetree/bindings/input/touchscreen/cyttsp5.txt
new file mode 100644
index ..713a377b5039
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/cyttsp5.txt
@@ -0,0 +1,55 @@
+* Cypress cyttsp touchscreen controller, generation 5
+
+Required properties:
+ - compatible  : must be "cypress,cyttsp5"
+ - reg : Device I2C address or SPI chip select number
+ - interrupt-parent: the phandle for the gpio controller
+ (see interrupt binding[0]).
+ - interrupts  : (gpio) interrupt to which the chip is connected
+ (see interrupt binding[0]).
+
+Optional properties (many of them coming from touchscreen binding[1]):
+ - reset-gpios : the reset gpio the chip is connected to
+ (see GPIO binding[2] for more details).
+ - touchscreen-size-x  : horizontal resolution of touchscreen (in pixels)


Just "see ./touchscreen.txt" is enough description.


+ - touchscreen-size-y  : vertical resolution of touchscreen (in pixels)
+ - touchscreen-fuzz-x  : horizontal noise value of the absolute input device
+ (in pixels)
+ - touchscreen-fuzz-y  : vertical noise value of the absolute input device
+ (in pixels)
+
+This touchscreen can handle some buttons that are touchscreen's defined zones.
+Each button's event can be customized using a sub-node properties:
+   - linux,code: Keycode to emit.
+
+[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+[2]: Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+ {
+   [...]
+
+   tsc@24 {


touchscreen@24


+   compatible = "cypress,cyttsp5";
+   reg = <0x24>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_reset_ds203>;
+   interrupt-parent = <>;
+   interrupts = <1 5 IRQ_TYPE_LEVEL_LOW>;
+   reset-gpios = < 7 1 GPIO_ACTIVE_HIGH>;
+
+   button@0 {


unit addresses need a reg property. If 0,1,2 are meaningful numbers for
the hardware, then it makes sense to add here.


Another option would be just say:

linux,keycodes = , , ;


Sure. I noticed the "linux,code" property so I used that one but I did 
not see the "linux,keycodes". I guess it is possible to group all the 
keycodes using that property.




I am wondering though: you read number of button supported by the device
from HID_SYSINFO_BTN_OFFSET, can you also get button assignment form
the device as well?


For what I know, it is not possible. We can only retrieve the number of 
buttons configured for one device but not keycodes.




And the biggest question of all: since you refer to HID descriptors in
your driver, is it a HID device and should it be driven by HID susbystem
instead of relying on a custom driver?


I am not familiar with HID subsytem but I looked to other HID drivers 
and read the kernel documentation.
In the datasheet, there is no reference to the HID specification and, 
for example, there is no GET/SET_REPORT requests. There is one "HID 
descriptor register" but that is all.


I guess that it is not a HID device but do not hesitate to give me hints 
to look at it, if you want me to confirm it.







+   linux,code = ;
+   };
+
+   button@1 {
+   linux,code = ;
+   };
+
+   button@2 {
+   linux,code = ;
+   };
+   };
+};
--
2.11.0



Thanks.



Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 2/2] Documentation: DT: bindings: input: Add documentation for cyttsp5

[Mylene Josserand]

Hi Rob,

Thank you for the review.

On 07/06/2017 22:26, Rob Herring wrote:

On Mon, May 29, 2017 at 04:45:38PM +0200, Mylène Josserand wrote:

Add the Cypress TrueTouch Generation 5 touchscreen device tree bindings
documentation. It can use I2C or SPI bus.
This touchscreen can handle some defined zone that are designed and
sent as button. To be able to customize the keycode sent, the
"linux,code" property in a "button" sub-node can be used.


"documentation" twice in the subject makes for a long subject.
The preferred subject prefix is "dt-bindings: input: ..."



Noted, thanks.



Signed-off-by: Mylène Josserand 
---
 .../bindings/input/touchscreen/cyttsp5.txt | 55 ++


cypress,cyttsp5.txt matching the compatible is preferred.


ACK




 1 file changed, 55 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/cyttsp5.txt

diff --git a/Documentation/devicetree/bindings/input/touchscreen/cyttsp5.txt 
b/Documentation/devicetree/bindings/input/touchscreen/cyttsp5.txt
new file mode 100644
index ..713a377b5039
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/cyttsp5.txt
@@ -0,0 +1,55 @@
+* Cypress cyttsp touchscreen controller, generation 5
+
+Required properties:
+ - compatible  : must be "cypress,cyttsp5"
+ - reg : Device I2C address or SPI chip select number
+ - interrupt-parent: the phandle for the gpio controller
+ (see interrupt binding[0]).
+ - interrupts  : (gpio) interrupt to which the chip is connected
+ (see interrupt binding[0]).
+
+Optional properties (many of them coming from touchscreen binding[1]):
+ - reset-gpios : the reset gpio the chip is connected to
+ (see GPIO binding[2] for more details).
+ - touchscreen-size-x  : horizontal resolution of touchscreen (in pixels)


Just "see ./touchscreen.txt" is enough description.


Okay




+ - touchscreen-size-y  : vertical resolution of touchscreen (in pixels)
+ - touchscreen-fuzz-x  : horizontal noise value of the absolute input device
+ (in pixels)
+ - touchscreen-fuzz-y  : vertical noise value of the absolute input device
+ (in pixels)
+
+This touchscreen can handle some buttons that are touchscreen's defined zones.
+Each button's event can be customized using a sub-node properties:
+   - linux,code: Keycode to emit.
+
+[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+[2]: Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+ {
+   [...]
+
+   tsc@24 {


touchscreen@24


ACK




+   compatible = "cypress,cyttsp5";
+   reg = <0x24>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_reset_ds203>;
+   interrupt-parent = <>;
+   interrupts = <1 5 IRQ_TYPE_LEVEL_LOW>;
+   reset-gpios = < 7 1 GPIO_ACTIVE_HIGH>;
+
+   button@0 {


unit addresses need a reg property. If 0,1,2 are meaningful numbers for
the hardware, then it makes sense to add here.


No, 0,1,2 do not mean anything to the driver.




+   linux,code = ;
+   };
+
+   button@1 {
+   linux,code = ;
+   };
+
+   button@2 {
+   linux,code = ;
+   };
+   };
+};
--
2.11.0



Thanks!

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 2/2] Documentation: DT: bindings: input: Add documentation for cyttsp5

[Mylene Josserand]

Hi Rob,

Thank you for the review.

On 07/06/2017 22:26, Rob Herring wrote:

On Mon, May 29, 2017 at 04:45:38PM +0200, Mylène Josserand wrote:

Add the Cypress TrueTouch Generation 5 touchscreen device tree bindings
documentation. It can use I2C or SPI bus.
This touchscreen can handle some defined zone that are designed and
sent as button. To be able to customize the keycode sent, the
"linux,code" property in a "button" sub-node can be used.


"documentation" twice in the subject makes for a long subject.
The preferred subject prefix is "dt-bindings: input: ..."



Noted, thanks.



Signed-off-by: Mylène Josserand 
---
 .../bindings/input/touchscreen/cyttsp5.txt | 55 ++


cypress,cyttsp5.txt matching the compatible is preferred.


ACK




 1 file changed, 55 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/input/touchscreen/cyttsp5.txt

diff --git a/Documentation/devicetree/bindings/input/touchscreen/cyttsp5.txt 
b/Documentation/devicetree/bindings/input/touchscreen/cyttsp5.txt
new file mode 100644
index ..713a377b5039
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/cyttsp5.txt
@@ -0,0 +1,55 @@
+* Cypress cyttsp touchscreen controller, generation 5
+
+Required properties:
+ - compatible  : must be "cypress,cyttsp5"
+ - reg : Device I2C address or SPI chip select number
+ - interrupt-parent: the phandle for the gpio controller
+ (see interrupt binding[0]).
+ - interrupts  : (gpio) interrupt to which the chip is connected
+ (see interrupt binding[0]).
+
+Optional properties (many of them coming from touchscreen binding[1]):
+ - reset-gpios : the reset gpio the chip is connected to
+ (see GPIO binding[2] for more details).
+ - touchscreen-size-x  : horizontal resolution of touchscreen (in pixels)


Just "see ./touchscreen.txt" is enough description.


Okay




+ - touchscreen-size-y  : vertical resolution of touchscreen (in pixels)
+ - touchscreen-fuzz-x  : horizontal noise value of the absolute input device
+ (in pixels)
+ - touchscreen-fuzz-y  : vertical noise value of the absolute input device
+ (in pixels)
+
+This touchscreen can handle some buttons that are touchscreen's defined zones.
+Each button's event can be customized using a sub-node properties:
+   - linux,code: Keycode to emit.
+
+[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+[1]: Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
+[2]: Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+ {
+   [...]
+
+   tsc@24 {


touchscreen@24


ACK




+   compatible = "cypress,cyttsp5";
+   reg = <0x24>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_reset_ds203>;
+   interrupt-parent = <>;
+   interrupts = <1 5 IRQ_TYPE_LEVEL_LOW>;
+   reset-gpios = < 7 1 GPIO_ACTIVE_HIGH>;
+
+   button@0 {


unit addresses need a reg property. If 0,1,2 are meaningful numbers for
the hardware, then it makes sense to add here.


No, 0,1,2 do not mean anything to the driver.




+   linux,code = ;
+   };
+
+   button@1 {
+   linux,code = ;
+   };
+
+   button@2 {
+   linux,code = ;
+   };
+   };
+};
--
2.11.0



Thanks!

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 1/2] Input: Add driver for Cypress Generation 5 touchscreen

[Mylene Josserand]

Maxime,

On 06/06/2017 14:04, Maxime Ripard wrote:

On Tue, Jun 06, 2017 at 10:03:48AM +0200, Mylene Josserand wrote:

+static int cyttsp5_hid_output_bl_launch_app(struct cyttsp5 *ts)
+{
+   int rc, t;
+   u8 cmd[HID_OUTPUT_BL_LAUNCH_APP];
+   u16 crc;
+
+   mutex_lock(>system_lock);
+   ts->hid_cmd_state = HID_OUTPUT_BL_LAUNCH_APP + 1;
+   mutex_unlock(>system_lock);
+
+   cmd[0] = LOW_BYTE(HID_OUTPUT_BL_LAUNCH_APP_SIZE);
+   cmd[1] = HI_BYTE(HID_OUTPUT_BL_LAUNCH_APP_SIZE);
+   cmd[2] = HID_BL_OUTPUT_REPORT_ID;
+   cmd[3] = 0x0; /* Reserved */
+   cmd[4] = HID_OUTPUT_BL_SOP;
+   cmd[5] = HID_OUTPUT_BL_LAUNCH_APP;
+   cmd[6] = 0x0; /* Low bytes of data */
+   cmd[7] = 0x0; /* Hi bytes of data */
+   crc = cyttsp5_compute_crc([4], 4);
+   cmd[8] = LOW_BYTE(crc);
+   cmd[9] = HI_BYTE(crc);
+   cmd[10] = HID_OUTPUT_BL_EOP;
+
+   rc = cyttsp5_write(ts, HID_OUTPUT_REG, cmd,
+  HID_OUTPUT_BL_LAUNCH_APP_SIZE);


It seems like you'll send HID_OUTPUT_BL_LAUNCH_APP_SIZE twice here,
once as setup in cyttsp5_write, and once in the buffer you want to
send. Is that on purpose?


I am not sure to see the second time it is sent. What do you mean by "as
setup in cyttsp5_write"? Anyway, the size is needed in the buffer of the
frame.


Nevermind, I confused the HID_OUTPUT_BL_LAUNCH_APP_SIZE with the
register, my bad.



No problem.


+   /* Call platform init function */
+   ts->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+   if (IS_ERR(ts->reset_gpio)) {
+   rc = PTR_ERR(ts->reset_gpio);
+   dev_err(dev, "Failed to request reset gpio, error %d\n", rc);
+   return rc;
+   }
+
+   /* Need a delay to have device up */
+   msleep(20);


In the case where the device has already been out of reset, this means
that this alone is not sufficient to reset it and bring it out of
reset, which also means that you do not have any guarantee on the
current state of the device. I'm not sure how it would impact the
proper operations though.


Okay. A reset frame can be sent to perform a "software
reset". Should I add it on startup to be in a "known behavior"?


I guess you'd be safer just getting the GPIO with the low level by
default, and then changing to high. That way you know that you went
through a reset state, before bringing up the device.


Okay, I will update the driver, thanks!


+   ts->input = input_allocate_device();
+   if (!ts->input) {
+   dev_err(dev, "%s: Error, failed to allocate input device\n",
+   __func__);
+   rc = -ENODEV;
+   goto error_startup;
+   }


In error_startup, you never uninitialize the device. Given your
comment in cyttsp5_startup, this means that you might end up in a
situation where your driver probes again with the device initialized
and no longer in a bootloader mode, which is likely to cause some
error.

Putting the call to cyttsp5_startup later will make you less likely to
fail (especially because of the DT parsing), and putting the device
back into reset will probably address the issue once and for all.


Hm, I am not sure to understand what you want to say, here.
Could you explain me more what you have in mind?


I meant to say that there was still an issue with the reset here, and
moving the DT parsing code further would ease the reset operation.


Okay




Notice that the DT parsing uses a sysinfo's variable (si->num_btns)
which is retrieved in the startup function (thanks to
get_sysinfo). So, currently, it is not possible to move the startup
function after the DT parsing.


Can't that be made the other way around? You parse the number of
buttons in the DT, and check the consistency with the hardware?


It could be possible but currently, it was designed to enable every 
button from hardware's configuration and DT binding was just a way to 
customize button's keycode (default is KEY_RESERVED).
If I base it on the DT, it means that some buttons could never be 
reported (such as deactivated) because they will not be present in the 
DT. I am not sure if it is the behavior we want. What do you think?



Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 1/2] Input: Add driver for Cypress Generation 5 touchscreen

[Mylene Josserand]

Maxime,

On 06/06/2017 14:04, Maxime Ripard wrote:

On Tue, Jun 06, 2017 at 10:03:48AM +0200, Mylene Josserand wrote:

+static int cyttsp5_hid_output_bl_launch_app(struct cyttsp5 *ts)
+{
+   int rc, t;
+   u8 cmd[HID_OUTPUT_BL_LAUNCH_APP];
+   u16 crc;
+
+   mutex_lock(>system_lock);
+   ts->hid_cmd_state = HID_OUTPUT_BL_LAUNCH_APP + 1;
+   mutex_unlock(>system_lock);
+
+   cmd[0] = LOW_BYTE(HID_OUTPUT_BL_LAUNCH_APP_SIZE);
+   cmd[1] = HI_BYTE(HID_OUTPUT_BL_LAUNCH_APP_SIZE);
+   cmd[2] = HID_BL_OUTPUT_REPORT_ID;
+   cmd[3] = 0x0; /* Reserved */
+   cmd[4] = HID_OUTPUT_BL_SOP;
+   cmd[5] = HID_OUTPUT_BL_LAUNCH_APP;
+   cmd[6] = 0x0; /* Low bytes of data */
+   cmd[7] = 0x0; /* Hi bytes of data */
+   crc = cyttsp5_compute_crc([4], 4);
+   cmd[8] = LOW_BYTE(crc);
+   cmd[9] = HI_BYTE(crc);
+   cmd[10] = HID_OUTPUT_BL_EOP;
+
+   rc = cyttsp5_write(ts, HID_OUTPUT_REG, cmd,
+  HID_OUTPUT_BL_LAUNCH_APP_SIZE);


It seems like you'll send HID_OUTPUT_BL_LAUNCH_APP_SIZE twice here,
once as setup in cyttsp5_write, and once in the buffer you want to
send. Is that on purpose?


I am not sure to see the second time it is sent. What do you mean by "as
setup in cyttsp5_write"? Anyway, the size is needed in the buffer of the
frame.


Nevermind, I confused the HID_OUTPUT_BL_LAUNCH_APP_SIZE with the
register, my bad.



No problem.


+   /* Call platform init function */
+   ts->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+   if (IS_ERR(ts->reset_gpio)) {
+   rc = PTR_ERR(ts->reset_gpio);
+   dev_err(dev, "Failed to request reset gpio, error %d\n", rc);
+   return rc;
+   }
+
+   /* Need a delay to have device up */
+   msleep(20);


In the case where the device has already been out of reset, this means
that this alone is not sufficient to reset it and bring it out of
reset, which also means that you do not have any guarantee on the
current state of the device. I'm not sure how it would impact the
proper operations though.


Okay. A reset frame can be sent to perform a "software
reset". Should I add it on startup to be in a "known behavior"?


I guess you'd be safer just getting the GPIO with the low level by
default, and then changing to high. That way you know that you went
through a reset state, before bringing up the device.


Okay, I will update the driver, thanks!


+   ts->input = input_allocate_device();
+   if (!ts->input) {
+   dev_err(dev, "%s: Error, failed to allocate input device\n",
+   __func__);
+   rc = -ENODEV;
+   goto error_startup;
+   }


In error_startup, you never uninitialize the device. Given your
comment in cyttsp5_startup, this means that you might end up in a
situation where your driver probes again with the device initialized
and no longer in a bootloader mode, which is likely to cause some
error.

Putting the call to cyttsp5_startup later will make you less likely to
fail (especially because of the DT parsing), and putting the device
back into reset will probably address the issue once and for all.


Hm, I am not sure to understand what you want to say, here.
Could you explain me more what you have in mind?


I meant to say that there was still an issue with the reset here, and
moving the DT parsing code further would ease the reset operation.


Okay




Notice that the DT parsing uses a sysinfo's variable (si->num_btns)
which is retrieved in the startup function (thanks to
get_sysinfo). So, currently, it is not possible to move the startup
function after the DT parsing.


Can't that be made the other way around? You parse the number of
buttons in the DT, and check the consistency with the hardware?


It could be possible but currently, it was designed to enable every 
button from hardware's configuration and DT binding was just a way to 
customize button's keycode (default is KEY_RESERVED).
If I base it on the DT, it means that some buttons could never be 
reported (such as deactivated) because they will not be present in the 
DT. I am not sure if it is the behavior we want. What do you think?



Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 1/2] Input: Add driver for Cypress Generation 5 touchscreen

[Mylene Josserand]

Hello Thomas,

On 30/05/2017 10:43, Thomas Petazzoni wrote:

Hello,

A few more comments :)


Thank you for the review!



On Mon, 29 May 2017 16:45:37 +0200, Mylène Josserand wrote:

+struct cyttsp5 {
+   struct device *dev;
+   struct mutex system_lock;
+   struct mutex btn_lock;
+   struct mutex mt_lock;


Three mutexes for such a driver is probably excessive, especially when
they are in fact used "sequentially".


Yes, I will have a look at these tree mutexes to see if there are 
necessary or not.





+static int cyttsp5_parse_dt_key_code(struct device *dev)
+{
+   struct cyttsp5 *ts = dev_get_drvdata(dev);
+   struct cyttsp5_sysinfo *si = >sysinfo;
+   struct device_node *np, *pp;
+   int rc, i;
+
+   np = dev->of_node;
+   if (!np)
+   return -EINVAL;
+
+   if (si->num_btns) {


Invert the test, and remove one indentation level:


Thanks!



if (!si->num_btns)
return 0;


+   si->btn = devm_kzalloc(dev,
+  si->num_btns * sizeof(struct 
cyttsp5_btn),
+  GFP_KERNEL);
+   if (!si->btn)
+   return -ENOMEM;
+
+   /* Initialized the button to RESERVED */


Initialized -> Initialize


+   for (i = 0; i < si->num_btns; i++) {
+   struct cyttsp5_btn *btns = >btn[i];
+   btns->key_code = KEY_RESERVED;
+   btns->enabled = true;


Does it make sense to have the button as "enabled" when it in fact
isn't really? Also setting btns->enabled = true is done again below.


No, it was used in the initial driver. I can remove it now.




+   }
+   }
+
+   i = 0;
+   for_each_child_of_node(np, pp) {
+   struct cyttsp5_btn *btns = >btn[i];
+
+   rc = of_property_read_u32(pp, "linux,code", >key_code);
+   if (rc) {
+   dev_err(dev, "%s: Inval linux,code prop\n", pp->name);
+   return -EINVAL;


Propagate "rc".


+   }


Add blank line here.


+   btns->enabled = true;
+
+   i++;
+   }


si->num_btns comes from the HW (calculated in function
cyttsp5_si_get_btn_data), but then you are trusting the DT to have the
exact same number of buttons.

If the DT has more button that si->num_btns, then you have a buffer
overflow here because you for_each_child_of_node() loop will loop after
the end of si->btn[].


Oh, thanks for the catch!




+static int cyttsp5_btn_attention(struct device *dev)
+{
+   struct cyttsp5 *ts = dev_get_drvdata(dev);
+   struct cyttsp5_sysinfo *si = >sysinfo;
+   int cur_btn;
+   int cur_btn_state;
+
+   if (si->xy_mode[2] != HID_BTN_REPORT_ID)
+   return 0;
+
+   /* core handles handshake */
+   mutex_lock(>btn_lock);
+
+   /* extract button press/release touch information */
+   if (si->num_btns > 0) {


Invert this test:

if (!si->num_btns)
return 0;

and then you save one indentation level.

Of course, move the test outside the mutex lock/unlock section.


ACK





+static void cyttsp5_si_get_btn_data(struct cyttsp5 *ts)
+{
+   struct cyttsp5_sysinfo *si = >sysinfo;
+   int i;
+   int num_btns = 0;
+   unsigned int btns = ts->response_buf[HID_SYSINFO_BTN_OFFSET]
+   & HID_SYSINFO_BTN_MASK;
+
+   for (i = 0; i < HID_SYSINFO_MAX_BTN; i++) {
+   if (btns & (1 << i))


Replace (1 << i) by BIT(i)


ACK




+   num_btns++;
+   }
+   si->num_btns = num_btns;


Does it really make sense to have a temporary variable, rather than
using si->num_btns directly?


Not at all :)




+static int cyttsp5_get_sysinfo_regs(struct cyttsp5 *ts)
+{
+   struct cyttsp5_sensing_conf_data *scd = >sysinfo.sensing_conf_data;
+   struct cyttsp5_sensing_conf_data_dev *scd_dev =
+   (struct cyttsp5_sensing_conf_data_dev *)
+   >response_buf[HID_SYSINFO_SENSING_OFFSET];
+   struct cyttsp5_sysinfo *si = >sysinfo;
+
+   cyttsp5_si_get_btn_data(ts);
+
+   scd->max_tch = scd_dev->max_num_of_tch_per_refresh_cycle;
+   scd->res_x = get_unaligned_le16(_dev->res_x);
+   scd->res_y = get_unaligned_le16(_dev->res_y);
+   scd->max_z = get_unaligned_le16(_dev->max_z);
+   scd->len_x = get_unaligned_le16(_dev->len_x);
+   scd->len_y = get_unaligned_le16(_dev->len_y);
+
+   si->xy_data = devm_kzalloc(ts->dev, scd->max_tch * TOUCH_REPORT_SIZE,
+  GFP_KERNEL);
+   if (!si->xy_data)
+   return -ENOMEM;
+
+   si->xy_mode = devm_kzalloc(ts->dev, TOUCH_INPUT_HEADER_SIZE, 
GFP_KERNEL);
+   if (!si->xy_mode) {
+   devm_kfree(ts->dev, si->xy_data);


The point of devm_kzalloc() is to not need to do a devm_kfree(). Of
course, check you're doing this only in the 

Re: [PATCH 1/2] Input: Add driver for Cypress Generation 5 touchscreen

[Mylene Josserand]

Hello Thomas,

On 30/05/2017 10:43, Thomas Petazzoni wrote:

Hello,

A few more comments :)


Thank you for the review!



On Mon, 29 May 2017 16:45:37 +0200, Mylène Josserand wrote:

+struct cyttsp5 {
+   struct device *dev;
+   struct mutex system_lock;
+   struct mutex btn_lock;
+   struct mutex mt_lock;


Three mutexes for such a driver is probably excessive, especially when
they are in fact used "sequentially".


Yes, I will have a look at these tree mutexes to see if there are 
necessary or not.





+static int cyttsp5_parse_dt_key_code(struct device *dev)
+{
+   struct cyttsp5 *ts = dev_get_drvdata(dev);
+   struct cyttsp5_sysinfo *si = >sysinfo;
+   struct device_node *np, *pp;
+   int rc, i;
+
+   np = dev->of_node;
+   if (!np)
+   return -EINVAL;
+
+   if (si->num_btns) {


Invert the test, and remove one indentation level:


Thanks!



if (!si->num_btns)
return 0;


+   si->btn = devm_kzalloc(dev,
+  si->num_btns * sizeof(struct 
cyttsp5_btn),
+  GFP_KERNEL);
+   if (!si->btn)
+   return -ENOMEM;
+
+   /* Initialized the button to RESERVED */


Initialized -> Initialize


+   for (i = 0; i < si->num_btns; i++) {
+   struct cyttsp5_btn *btns = >btn[i];
+   btns->key_code = KEY_RESERVED;
+   btns->enabled = true;


Does it make sense to have the button as "enabled" when it in fact
isn't really? Also setting btns->enabled = true is done again below.


No, it was used in the initial driver. I can remove it now.




+   }
+   }
+
+   i = 0;
+   for_each_child_of_node(np, pp) {
+   struct cyttsp5_btn *btns = >btn[i];
+
+   rc = of_property_read_u32(pp, "linux,code", >key_code);
+   if (rc) {
+   dev_err(dev, "%s: Inval linux,code prop\n", pp->name);
+   return -EINVAL;


Propagate "rc".


+   }


Add blank line here.


+   btns->enabled = true;
+
+   i++;
+   }


si->num_btns comes from the HW (calculated in function
cyttsp5_si_get_btn_data), but then you are trusting the DT to have the
exact same number of buttons.

If the DT has more button that si->num_btns, then you have a buffer
overflow here because you for_each_child_of_node() loop will loop after
the end of si->btn[].


Oh, thanks for the catch!




+static int cyttsp5_btn_attention(struct device *dev)
+{
+   struct cyttsp5 *ts = dev_get_drvdata(dev);
+   struct cyttsp5_sysinfo *si = >sysinfo;
+   int cur_btn;
+   int cur_btn_state;
+
+   if (si->xy_mode[2] != HID_BTN_REPORT_ID)
+   return 0;
+
+   /* core handles handshake */
+   mutex_lock(>btn_lock);
+
+   /* extract button press/release touch information */
+   if (si->num_btns > 0) {


Invert this test:

if (!si->num_btns)
return 0;

and then you save one indentation level.

Of course, move the test outside the mutex lock/unlock section.


ACK





+static void cyttsp5_si_get_btn_data(struct cyttsp5 *ts)
+{
+   struct cyttsp5_sysinfo *si = >sysinfo;
+   int i;
+   int num_btns = 0;
+   unsigned int btns = ts->response_buf[HID_SYSINFO_BTN_OFFSET]
+   & HID_SYSINFO_BTN_MASK;
+
+   for (i = 0; i < HID_SYSINFO_MAX_BTN; i++) {
+   if (btns & (1 << i))


Replace (1 << i) by BIT(i)


ACK




+   num_btns++;
+   }
+   si->num_btns = num_btns;


Does it really make sense to have a temporary variable, rather than
using si->num_btns directly?


Not at all :)




+static int cyttsp5_get_sysinfo_regs(struct cyttsp5 *ts)
+{
+   struct cyttsp5_sensing_conf_data *scd = >sysinfo.sensing_conf_data;
+   struct cyttsp5_sensing_conf_data_dev *scd_dev =
+   (struct cyttsp5_sensing_conf_data_dev *)
+   >response_buf[HID_SYSINFO_SENSING_OFFSET];
+   struct cyttsp5_sysinfo *si = >sysinfo;
+
+   cyttsp5_si_get_btn_data(ts);
+
+   scd->max_tch = scd_dev->max_num_of_tch_per_refresh_cycle;
+   scd->res_x = get_unaligned_le16(_dev->res_x);
+   scd->res_y = get_unaligned_le16(_dev->res_y);
+   scd->max_z = get_unaligned_le16(_dev->max_z);
+   scd->len_x = get_unaligned_le16(_dev->len_x);
+   scd->len_y = get_unaligned_le16(_dev->len_y);
+
+   si->xy_data = devm_kzalloc(ts->dev, scd->max_tch * TOUCH_REPORT_SIZE,
+  GFP_KERNEL);
+   if (!si->xy_data)
+   return -ENOMEM;
+
+   si->xy_mode = devm_kzalloc(ts->dev, TOUCH_INPUT_HEADER_SIZE, 
GFP_KERNEL);
+   if (!si->xy_mode) {
+   devm_kfree(ts->dev, si->xy_data);


The point of devm_kzalloc() is to not need to do a devm_kfree(). Of
course, check you're doing this only in the 

Re: [PATCH 1/2] Input: Add driver for Cypress Generation 5 touchscreen

[Mylene Josserand]

Hello Maxime,

Thank you for the review!

On 30/05/2017 10:02, Maxime Ripard wrote:

Hi Mylene,

On Mon, May 29, 2017 at 04:45:37PM +0200, Mylène Josserand wrote:

+static int cyttsp5_read(struct cyttsp5 *ts, u8 *buf, u32 max)
+{
+   int rc;
+   u32 size;
+
+   if (!buf)
+   return -EINVAL;
+
+   /* Read the frame to retrieve the size */
+   rc = regmap_bulk_read(ts->regmap, 0, buf, 2);
+   if (rc < 0)
+   return rc;


You should probably use a temporary buffer here, instead of the caller
one. Otherwise, you might return an error (a bit below, in the (size >
max) test), while you modified the caller buffer, which seems a bit
odd.


Okay.




+   size = get_unaligned_le16([0]);


isn't [0] the same thing than buf here ?


Yep




+   if (!size || size == 2)
+   return 0;
+
+   if (size > max)
+   return -EINVAL;
+
+   /* Get the real value */
+   return regmap_bulk_read(ts->regmap, 0, buf, size);
+}
+
+static int cyttsp5_write(struct cyttsp5 *ts, unsigned int reg, u8 *data,
+size_t size)
+{
+   u8 cmd[size + 1];
+
+   /* High bytes of register address needed as first byte of cmd */
+   cmd[0] = HI_BYTE(reg);
+   /* Copy the rest of the data */
+   memcpy([1], data, size);
+
+   return regmap_bulk_write(ts->regmap, LOW_BYTE(reg), cmd, size + 1);


The way we need to access the buffers here is definitely not trivial,
I guess some comment about how the hardware expects the commands to be
sent would be welcome.


Yes, it is not trivial, I will add a comment.




+}
+
+static void cyttsp5_final_sync(struct input_dev *input, int max_slots,
+  unsigned long *ids)
+{
+   int t;
+
+   for (t = 0; t < max_slots; t++) {
+   if (test_bit(t, ids))
+   continue;
+   input_mt_slot(input, t);
+   input_mt_report_slot_state(input, MT_TOOL_FINGER, false);
+   }
+
+   input_sync(input);
+}
+
+static void cyttsp5_report_slot_liftoff(struct cyttsp5 *ts, int max_slots)
+{
+   int t;
+
+   if (ts->num_prv_rec == 0)
+   return;
+
+   for (t = 0; t < max_slots; t++) {
+   input_mt_slot(ts->input, t);
+   input_mt_report_slot_state(ts->input, MT_TOOL_FINGER, false);
+   }
+}
+
+static void cyttsp5_mt_lift_all(struct cyttsp5 *ts)
+{
+   struct cyttsp5_sysinfo *si = >sysinfo;
+   int max = si->tch_abs[CY_TCH_T].max;
+
+   if (ts->num_prv_rec != 0) {
+   cyttsp5_report_slot_liftoff(ts, max);
+   input_sync(ts->input);
+   ts->num_prv_rec = 0;
+   }
+}
+
+static void cyttsp5_get_touch_axis(int *axis, int size, int max, u8 *xy_data,
+  int bofs)
+{
+   int nbyte;
+   int next;
+
+   for (nbyte = 0, *axis = 0, next = 0; nbyte < size; nbyte++) {
+   *axis = *axis + ((xy_data[next] >> bofs) << (nbyte * 8));
+   next++;


Isn't nbyte and next the same thing here ?


Yes, thanks!




+   }
+
+   *axis &= max - 1;
+}
+
+static void cyttsp5_get_touch_record(struct cyttsp5 *ts,
+struct cyttsp5_touch *touch, u8 *xy_data)
+{
+   struct cyttsp5_sysinfo *si = >sysinfo;
+   enum cyttsp5_tch_abs abs;
+
+   for (abs = CY_TCH_X; abs < CY_TCH_NUM_ABS; abs++) {
+   cyttsp5_get_touch_axis(>abs[abs],
+  si->tch_abs[abs].size,
+  si->tch_abs[abs].max,
+  xy_data + si->tch_abs[abs].ofs,
+  si->tch_abs[abs].bofs);
+   }
+}
+
+static void cyttsp5_mt_process_touch(struct cyttsp5 *ts,
+struct cyttsp5_touch *touch)
+{
+   struct cyttsp5_sysinfo *si = >sysinfo;
+   int tmp;
+
+   tmp = touch->abs[CY_TCH_X];
+   touch->abs[CY_TCH_X] = touch->abs[CY_TCH_Y];
+   touch->abs[CY_TCH_Y] = tmp;


Why do you need to swap the values here?


The X/Y axis must be swapped otherwise, touchscreen's events are not 
correct (inversion between X and Y axis).
I noticed that there is a "touchscreen-swapped-x-y" property that exists 
in the touchscreen's device tree documentation.


http://elixir.free-electrons.com/linux/v4.12-rc4/source/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt#L22

I will update the driver to use this property instead of hard-coding the 
swap.




Instead of rolling your own implementation, you can use swap()


+   /* Convert MAJOR/MINOR from mm to resolution */
+   tmp = touch->abs[CY_TCH_MAJ] * 100 * si->sensing_conf_data.res_x;
+   touch->abs[CY_TCH_MAJ] = tmp / si->sensing_conf_data.len_x;
+   tmp = touch->abs[CY_TCH_MIN] * 100 * si->sensing_conf_data.res_x;
+   touch->abs[CY_TCH_MIN] = tmp / si->sensing_conf_data.len_x;
+}
+
+static void 

Re: [PATCH 1/2] Input: Add driver for Cypress Generation 5 touchscreen

[Mylene Josserand]

Hello Maxime,

Thank you for the review!

On 30/05/2017 10:02, Maxime Ripard wrote:

Hi Mylene,

On Mon, May 29, 2017 at 04:45:37PM +0200, Mylène Josserand wrote:

+static int cyttsp5_read(struct cyttsp5 *ts, u8 *buf, u32 max)
+{
+   int rc;
+   u32 size;
+
+   if (!buf)
+   return -EINVAL;
+
+   /* Read the frame to retrieve the size */
+   rc = regmap_bulk_read(ts->regmap, 0, buf, 2);
+   if (rc < 0)
+   return rc;


You should probably use a temporary buffer here, instead of the caller
one. Otherwise, you might return an error (a bit below, in the (size >
max) test), while you modified the caller buffer, which seems a bit
odd.


Okay.




+   size = get_unaligned_le16([0]);


isn't [0] the same thing than buf here ?


Yep




+   if (!size || size == 2)
+   return 0;
+
+   if (size > max)
+   return -EINVAL;
+
+   /* Get the real value */
+   return regmap_bulk_read(ts->regmap, 0, buf, size);
+}
+
+static int cyttsp5_write(struct cyttsp5 *ts, unsigned int reg, u8 *data,
+size_t size)
+{
+   u8 cmd[size + 1];
+
+   /* High bytes of register address needed as first byte of cmd */
+   cmd[0] = HI_BYTE(reg);
+   /* Copy the rest of the data */
+   memcpy([1], data, size);
+
+   return regmap_bulk_write(ts->regmap, LOW_BYTE(reg), cmd, size + 1);


The way we need to access the buffers here is definitely not trivial,
I guess some comment about how the hardware expects the commands to be
sent would be welcome.


Yes, it is not trivial, I will add a comment.




+}
+
+static void cyttsp5_final_sync(struct input_dev *input, int max_slots,
+  unsigned long *ids)
+{
+   int t;
+
+   for (t = 0; t < max_slots; t++) {
+   if (test_bit(t, ids))
+   continue;
+   input_mt_slot(input, t);
+   input_mt_report_slot_state(input, MT_TOOL_FINGER, false);
+   }
+
+   input_sync(input);
+}
+
+static void cyttsp5_report_slot_liftoff(struct cyttsp5 *ts, int max_slots)
+{
+   int t;
+
+   if (ts->num_prv_rec == 0)
+   return;
+
+   for (t = 0; t < max_slots; t++) {
+   input_mt_slot(ts->input, t);
+   input_mt_report_slot_state(ts->input, MT_TOOL_FINGER, false);
+   }
+}
+
+static void cyttsp5_mt_lift_all(struct cyttsp5 *ts)
+{
+   struct cyttsp5_sysinfo *si = >sysinfo;
+   int max = si->tch_abs[CY_TCH_T].max;
+
+   if (ts->num_prv_rec != 0) {
+   cyttsp5_report_slot_liftoff(ts, max);
+   input_sync(ts->input);
+   ts->num_prv_rec = 0;
+   }
+}
+
+static void cyttsp5_get_touch_axis(int *axis, int size, int max, u8 *xy_data,
+  int bofs)
+{
+   int nbyte;
+   int next;
+
+   for (nbyte = 0, *axis = 0, next = 0; nbyte < size; nbyte++) {
+   *axis = *axis + ((xy_data[next] >> bofs) << (nbyte * 8));
+   next++;


Isn't nbyte and next the same thing here ?


Yes, thanks!




+   }
+
+   *axis &= max - 1;
+}
+
+static void cyttsp5_get_touch_record(struct cyttsp5 *ts,
+struct cyttsp5_touch *touch, u8 *xy_data)
+{
+   struct cyttsp5_sysinfo *si = >sysinfo;
+   enum cyttsp5_tch_abs abs;
+
+   for (abs = CY_TCH_X; abs < CY_TCH_NUM_ABS; abs++) {
+   cyttsp5_get_touch_axis(>abs[abs],
+  si->tch_abs[abs].size,
+  si->tch_abs[abs].max,
+  xy_data + si->tch_abs[abs].ofs,
+  si->tch_abs[abs].bofs);
+   }
+}
+
+static void cyttsp5_mt_process_touch(struct cyttsp5 *ts,
+struct cyttsp5_touch *touch)
+{
+   struct cyttsp5_sysinfo *si = >sysinfo;
+   int tmp;
+
+   tmp = touch->abs[CY_TCH_X];
+   touch->abs[CY_TCH_X] = touch->abs[CY_TCH_Y];
+   touch->abs[CY_TCH_Y] = tmp;


Why do you need to swap the values here?


The X/Y axis must be swapped otherwise, touchscreen's events are not 
correct (inversion between X and Y axis).
I noticed that there is a "touchscreen-swapped-x-y" property that exists 
in the touchscreen's device tree documentation.


http://elixir.free-electrons.com/linux/v4.12-rc4/source/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt#L22

I will update the driver to use this property instead of hard-coding the 
swap.




Instead of rolling your own implementation, you can use swap()


+   /* Convert MAJOR/MINOR from mm to resolution */
+   tmp = touch->abs[CY_TCH_MAJ] * 100 * si->sensing_conf_data.res_x;
+   touch->abs[CY_TCH_MAJ] = tmp / si->sensing_conf_data.len_x;
+   tmp = touch->abs[CY_TCH_MIN] * 100 * si->sensing_conf_data.res_x;
+   touch->abs[CY_TCH_MIN] = tmp / si->sensing_conf_data.len_x;
+}
+
+static void 

Re: [PATCH 1/2] ASoC: sun8i-codec: Add ADC support for a33

[Mylene Josserand]

Hi Chen-Yu,

Thank you for the review!

On 03/05/2017 19:13, Chen-Yu Tsai wrote:

Hi,

On Wed, May 3, 2017 at 9:56 PM, Mylène Josserand
 wrote:

Add ADC support for the sun8i-codec driver.

This driver uses all the microphones widgets and routes provided by the
analog part (sun8i-codec-analog).
Some digital configurations are needed by creating new ADC widgets
and routes.

Signed-off-by: Mylène Josserand 
---
 sound/soc/sunxi/sun8i-codec.c | 80 +--
 1 file changed, 78 insertions(+), 2 deletions(-)

diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
index 5723c3404f6b..b4938b06acec 100644
--- a/sound/soc/sunxi/sun8i-codec.c
+++ b/sound/soc/sunxi/sun8i-codec.c
@@ -37,9 +37,11 @@
 #define SUN8I_SYSCLK_CTL_SYSCLK_SRC0
 #define SUN8I_MOD_CLK_ENA  0x010
 #define SUN8I_MOD_CLK_ENA_AIF1 15
+#define SUN8I_MOD_CLK_ENA_ADC  3
 #define SUN8I_MOD_CLK_ENA_DAC  2
 #define SUN8I_MOD_RST_CTL  0x014
 #define SUN8I_MOD_RST_CTL_AIF1 15
+#define SUN8I_MOD_RST_CTL_ADC  3
 #define SUN8I_MOD_RST_CTL_DAC  2
 #define SUN8I_SYS_SR_CTRL  0x018
 #define SUN8I_SYS_SR_CTRL_AIF1_FS  12
@@ -54,9 +56,25 @@
 #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ   4
 #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_16(1 << 4)
 #define SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT   2
+#define SUN8I_AIF1_ADCDAT_CTRL 0x044
+#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0L_ENA   15
+#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0R_ENA   14
 #define SUN8I_AIF1_DACDAT_CTRL 0x048
 #define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA   15
 #define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA   14
+#define SUN8I_AIF1_MXR_SRC 0x04c
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L   15
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL   14
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL   13
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR   12
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R   11
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR   10
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR   9
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL   8
+#define SUN8I_ADC_DIG_CTRL 0x100
+#define SUN8I_ADC_DIG_CTRL_ENDA15


The register bit name in the manual is ENAD, as in ENable ADc.


Okay, I did not know that, thanks.




+#define SUN8I_ADC_DIG_CTRL_ADOUT_DTS   2
+#define SUN8I_ADC_DIG_CTRL_ADOUT_DLY   1
 #define SUN8I_DAC_DIG_CTRL 0x120
 #define SUN8I_DAC_DIG_CTRL_ENDA15
 #define SUN8I_DAC_MXR_SRC  0x130
@@ -276,10 +294,28 @@ static const struct snd_kcontrol_new 
sun8i_dac_mixer_controls[] = {
SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_ADCR, 1, 0),
 };

+static const struct snd_kcontrol_new sun8i_input_mixer_controls[] = {
+   SOC_DAPM_DOUBLE("AIF1 Slot 0 Digital ADC Capture Switch",
+   SUN8I_AIF1_MXR_SRC,
+   SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L,
+   SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R, 1, 0),
+   SOC_DAPM_DOUBLE("AIF2 Digital ADC Capture Switch", SUN8I_AIF1_MXR_SRC,
+   SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL,
+   SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR, 1, 0),
+   SOC_DAPM_DOUBLE("AIF1 Data Digital ADC Capture Switch", 
SUN8I_AIF1_MXR_SRC,
+   SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL,
+   SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR, 1, 0),
+   SOC_DAPM_DOUBLE("AIF2 Inv Digital ADC Capture Switch", 
SUN8I_AIF1_MXR_SRC,
+   SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR,
+   SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL, 1, 0),
+};


This group of mixer controls is only for AIF1 slot 0 capture.
So in fact they should all read "AIF1 Slot 0 Mixer X Capture Switch",
with X replaced by "AIF1 Slot 0", "AIF2", "ADC", and "AIF2 Inv".

This hopefully informs the user that these controls are for the AIF1
slot 0 mixer, and are capture switch from the various sources listed
above.


Sounds good.




+
 static const struct snd_soc_dapm_widget sun8i_codec_dapm_widgets[] = {
-   /* Digital parts of the DACs */
+   /* Digital parts of the DACs and ADC */
SND_SOC_DAPM_SUPPLY("DAC", SUN8I_DAC_DIG_CTRL, SUN8I_DAC_DIG_CTRL_ENDA,
0, NULL, 0),
+   SND_SOC_DAPM_SUPPLY("ADC", SUN8I_ADC_DIG_CTRL, SUN8I_ADC_DIG_CTRL_ENDA,
+   0, 

Re: [PATCH 1/2] ASoC: sun8i-codec: Add ADC support for a33

[Mylene Josserand]

Hi Chen-Yu,

Thank you for the review!

On 03/05/2017 19:13, Chen-Yu Tsai wrote:

Hi,

On Wed, May 3, 2017 at 9:56 PM, Mylène Josserand
 wrote:

Add ADC support for the sun8i-codec driver.

This driver uses all the microphones widgets and routes provided by the
analog part (sun8i-codec-analog).
Some digital configurations are needed by creating new ADC widgets
and routes.

Signed-off-by: Mylène Josserand 
---
 sound/soc/sunxi/sun8i-codec.c | 80 +--
 1 file changed, 78 insertions(+), 2 deletions(-)

diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
index 5723c3404f6b..b4938b06acec 100644
--- a/sound/soc/sunxi/sun8i-codec.c
+++ b/sound/soc/sunxi/sun8i-codec.c
@@ -37,9 +37,11 @@
 #define SUN8I_SYSCLK_CTL_SYSCLK_SRC0
 #define SUN8I_MOD_CLK_ENA  0x010
 #define SUN8I_MOD_CLK_ENA_AIF1 15
+#define SUN8I_MOD_CLK_ENA_ADC  3
 #define SUN8I_MOD_CLK_ENA_DAC  2
 #define SUN8I_MOD_RST_CTL  0x014
 #define SUN8I_MOD_RST_CTL_AIF1 15
+#define SUN8I_MOD_RST_CTL_ADC  3
 #define SUN8I_MOD_RST_CTL_DAC  2
 #define SUN8I_SYS_SR_CTRL  0x018
 #define SUN8I_SYS_SR_CTRL_AIF1_FS  12
@@ -54,9 +56,25 @@
 #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ   4
 #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_16(1 << 4)
 #define SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT   2
+#define SUN8I_AIF1_ADCDAT_CTRL 0x044
+#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0L_ENA   15
+#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0R_ENA   14
 #define SUN8I_AIF1_DACDAT_CTRL 0x048
 #define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA   15
 #define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA   14
+#define SUN8I_AIF1_MXR_SRC 0x04c
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L   15
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL   14
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL   13
+#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR   12
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R   11
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR   10
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR   9
+#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL   8
+#define SUN8I_ADC_DIG_CTRL 0x100
+#define SUN8I_ADC_DIG_CTRL_ENDA15


The register bit name in the manual is ENAD, as in ENable ADc.


Okay, I did not know that, thanks.




+#define SUN8I_ADC_DIG_CTRL_ADOUT_DTS   2
+#define SUN8I_ADC_DIG_CTRL_ADOUT_DLY   1
 #define SUN8I_DAC_DIG_CTRL 0x120
 #define SUN8I_DAC_DIG_CTRL_ENDA15
 #define SUN8I_DAC_MXR_SRC  0x130
@@ -276,10 +294,28 @@ static const struct snd_kcontrol_new 
sun8i_dac_mixer_controls[] = {
SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_ADCR, 1, 0),
 };

+static const struct snd_kcontrol_new sun8i_input_mixer_controls[] = {
+   SOC_DAPM_DOUBLE("AIF1 Slot 0 Digital ADC Capture Switch",
+   SUN8I_AIF1_MXR_SRC,
+   SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L,
+   SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R, 1, 0),
+   SOC_DAPM_DOUBLE("AIF2 Digital ADC Capture Switch", SUN8I_AIF1_MXR_SRC,
+   SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL,
+   SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR, 1, 0),
+   SOC_DAPM_DOUBLE("AIF1 Data Digital ADC Capture Switch", 
SUN8I_AIF1_MXR_SRC,
+   SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL,
+   SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR, 1, 0),
+   SOC_DAPM_DOUBLE("AIF2 Inv Digital ADC Capture Switch", 
SUN8I_AIF1_MXR_SRC,
+   SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR,
+   SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL, 1, 0),
+};


This group of mixer controls is only for AIF1 slot 0 capture.
So in fact they should all read "AIF1 Slot 0 Mixer X Capture Switch",
with X replaced by "AIF1 Slot 0", "AIF2", "ADC", and "AIF2 Inv".

This hopefully informs the user that these controls are for the AIF1
slot 0 mixer, and are capture switch from the various sources listed
above.


Sounds good.




+
 static const struct snd_soc_dapm_widget sun8i_codec_dapm_widgets[] = {
-   /* Digital parts of the DACs */
+   /* Digital parts of the DACs and ADC */
SND_SOC_DAPM_SUPPLY("DAC", SUN8I_DAC_DIG_CTRL, SUN8I_DAC_DIG_CTRL_ENDA,
0, NULL, 0),
+   SND_SOC_DAPM_SUPPLY("ADC", SUN8I_ADC_DIG_CTRL, SUN8I_ADC_DIG_CTRL_ENDA,
+   0, NULL, 0),

/* Analog DAC AIF */
SND_SOC_DAPM_AIF_IN("AIF1 

Re: [PATCH 0/2] ASoC: sunxi: Add ADC support for A33

[Mylene Josserand]

Hello,

On 03/05/2017 15:56, Mylène Josserand wrote:

Hello everyone,

This is a first version of a serie to add ADC support
for Sun8i-A33.
Based on asoc/for-next branch, last commit:
20d5c84bef067b7e804a163e2abca16c47125bad.

The first patch adds the support of ADC and microphones in the digital
part (driver sun8i-codec).
The second one adds the route between analog (sun8i-codec-analog) and
digital (sun8i-codec) parts to have a functional ADC route on Sun8i-A33
device tree.

Tested on Allwinner R16 Parrot board with microphone 1 (external) and
microphone 2 (headset).


I forgot to add in my cover-letter amixer commands used to test it:

amixer set 'AIF1 Data Digital ADC' cap
amixer set 'Mic1' cap
or
amixer set 'Mic2' cap

and, just in case, the commands to enable output/DAC:

amixer set 'Headphone' 50%
amixer set 'Headphone' on
amixer set 'DAC' on
amixer set 'AIF1 Slot 0 Digital DAC' on



I am not sure about the bias handling so if you have any comments on it,
do not hesitate.

Thank you in advance!

Best regards,

Mylène Josserand (2):
  ASoC: sun8i-codec: Add ADC support for a33
  ARM: dts: sun8i: Add ADC routing

 arch/arm/boot/dts/sun8i-a33.dtsi | 10 -
 sound/soc/sunxi/sun8i-codec.c| 80 +++-
 2 files changed, 87 insertions(+), 3 deletions(-)



Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 0/2] ASoC: sunxi: Add ADC support for A33

[Mylene Josserand]

Hello,

On 03/05/2017 15:56, Mylène Josserand wrote:

Hello everyone,

This is a first version of a serie to add ADC support
for Sun8i-A33.
Based on asoc/for-next branch, last commit:
20d5c84bef067b7e804a163e2abca16c47125bad.

The first patch adds the support of ADC and microphones in the digital
part (driver sun8i-codec).
The second one adds the route between analog (sun8i-codec-analog) and
digital (sun8i-codec) parts to have a functional ADC route on Sun8i-A33
device tree.

Tested on Allwinner R16 Parrot board with microphone 1 (external) and
microphone 2 (headset).


I forgot to add in my cover-letter amixer commands used to test it:

amixer set 'AIF1 Data Digital ADC' cap
amixer set 'Mic1' cap
or
amixer set 'Mic2' cap

and, just in case, the commands to enable output/DAC:

amixer set 'Headphone' 50%
amixer set 'Headphone' on
amixer set 'DAC' on
amixer set 'AIF1 Slot 0 Digital DAC' on



I am not sure about the bias handling so if you have any comments on it,
do not hesitate.

Thank you in advance!

Best regards,

Mylène Josserand (2):
  ASoC: sun8i-codec: Add ADC support for a33
  ARM: dts: sun8i: Add ADC routing

 arch/arm/boot/dts/sun8i-a33.dtsi | 10 -
 sound/soc/sunxi/sun8i-codec.c| 80 +++-
 2 files changed, 87 insertions(+), 3 deletions(-)



Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v3 1/5] ASoC: sun8i-codec: Remove analog "HP" widget

[Mylene Josserand]

Mark,

On 20/03/2017 18:39, Mark Brown wrote:

On Sat, Mar 18, 2017 at 08:55:05AM +0100, Mylène Josserand wrote:

The "HP" widget is already present and take part to
the analog part (sun8i-codec-analog).

Remove it from the digital part as it is unnecessary.


I know I said to send against Linus' tree but it turns out this actually
conflicts with some of the existing fixes, please see my fixes/sunxi
branch and resend against that.  Sorry for the hassle here.



It does not apply because my driver ("sun8i-codec") is, currently, not 
available in your fix/sunxi branch:


https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/tree/sound/soc/sunxi?h=fix/sunxi

Should I apply the patches (which add my driver) as "dependencies" and 
indicate it in my cover letter? Let me know what I should do.


Thank you for the help!

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v3 1/5] ASoC: sun8i-codec: Remove analog "HP" widget

[Mylene Josserand]

Mark,

On 20/03/2017 18:39, Mark Brown wrote:

On Sat, Mar 18, 2017 at 08:55:05AM +0100, Mylène Josserand wrote:

The "HP" widget is already present and take part to
the analog part (sun8i-codec-analog).

Remove it from the digital part as it is unnecessary.


I know I said to send against Linus' tree but it turns out this actually
conflicts with some of the existing fixes, please see my fixes/sunxi
branch and resend against that.  Sorry for the hassle here.



It does not apply because my driver ("sun8i-codec") is, currently, not 
available in your fix/sunxi branch:


https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/tree/sound/soc/sunxi?h=fix/sunxi

Should I apply the patches (which add my driver) as "dependencies" and 
indicate it in my cover letter? Let me know what I should do.


Thank you for the help!

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v3 1/5] ASoC: sun8i-codec: Remove analog "HP" widget

[Mylene Josserand]

Hi Mark,

On 20/03/2017 18:39, Mark Brown wrote:

On Sat, Mar 18, 2017 at 08:55:05AM +0100, Mylène Josserand wrote:

The "HP" widget is already present and take part to
the analog part (sun8i-codec-analog).

Remove it from the digital part as it is unnecessary.


I know I said to send against Linus' tree but it turns out this actually
conflicts with some of the existing fixes, please see my fixes/sunxi
branch and resend against that.  Sorry for the hassle here.



Sure, no problem! I will rebase my V4 on your fixes/sunxi branch.

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v3 1/5] ASoC: sun8i-codec: Remove analog "HP" widget

[Mylene Josserand]

Hi Mark,

On 20/03/2017 18:39, Mark Brown wrote:

On Sat, Mar 18, 2017 at 08:55:05AM +0100, Mylène Josserand wrote:

The "HP" widget is already present and take part to
the analog part (sun8i-codec-analog).

Remove it from the digital part as it is unnecessary.


I know I said to send against Linus' tree but it turns out this actually
conflicts with some of the existing fixes, please see my fixes/sunxi
branch and resend against that.  Sorry for the hassle here.



Sure, no problem! I will rebase my V4 on your fixes/sunxi branch.

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v3 2/5] ASoC: sun8i-codec: Update mixer to use SOC_DAPM_DOUBLE

[Mylene Josserand]

Hi Chen-Yu,

On 20/03/2017 12:46, Chen-Yu Tsai wrote:

On Sat, Mar 18, 2017 at 3:55 PM, Mylène Josserand
 wrote:

Update the driver to use the new SOC_DAPM_DOUBLE definition
on the digital DAC mixer.
Update the names accordingly as, when they are shared, the
controls are not prefixed with the widget's name anymore.

Signed-off-by: Mylène Josserand 
---
 sound/soc/sunxi/sun8i-codec.c | 45 ---
 1 file changed, 21 insertions(+), 24 deletions(-)

diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
index d60f6fbd36a2..107fa8213600 100644
--- a/sound/soc/sunxi/sun8i-codec.c
+++ b/sound/soc/sunxi/sun8i-codec.c
@@ -259,25 +259,20 @@ static int sun8i_codec_hw_params(struct snd_pcm_substream 
*substream,
return 0;
 }

-static const struct snd_kcontrol_new sun8i_output_left_mixer_controls[] = {
-   SOC_DAPM_SINGLE("LSlot 0", SUN8I_DAC_MXR_SRC,
-   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA0L, 1, 0),
-   SOC_DAPM_SINGLE("LSlot 1", SUN8I_DAC_MXR_SRC,
-   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA1L, 1, 0),
-   SOC_DAPM_SINGLE("DACL", SUN8I_DAC_MXR_SRC,
-   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF2DACL, 1, 0),
-   SOC_DAPM_SINGLE("ADCL", SUN8I_DAC_MXR_SRC,
-   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_ADCL, 1, 0),
-};
-
-static const struct snd_kcontrol_new sun8i_output_right_mixer_controls[] = {
-   SOC_DAPM_SINGLE("RSlot 0", SUN8I_DAC_MXR_SRC,
+static const struct snd_kcontrol_new sun8i_dac_mixer_controls[] = {
+   SOC_DAPM_DOUBLE("AIF1 Slot 0 Digital DAC Playback Switch",
+   SUN8I_DAC_MXR_SRC,
+   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA0L,
SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF1DA0R, 1, 0),
-   SOC_DAPM_SINGLE("RSlot 1", SUN8I_DAC_MXR_SRC,
+   SOC_DAPM_DOUBLE("AIF1 Slot 1 Digital DAC Playback Switch",
+   SUN8I_DAC_MXR_SRC,
+   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA1L,
SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF1DA1R, 1, 0),
-   SOC_DAPM_SINGLE("DACR", SUN8I_DAC_MXR_SRC,
+   SOC_DAPM_DOUBLE("AIF2 Digital DAC Playback Switch", SUN8I_DAC_MXR_SRC,
+   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF2DACL,
SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF2DACR, 1, 0),
-   SOC_DAPM_SINGLE("ADCR", SUN8I_DAC_MXR_SRC,
+   SOC_DAPM_DOUBLE("ADC Digital DAC Playback Switch", SUN8I_DAC_MXR_SRC,
+   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_ADCL,
SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_ADCR, 1, 0),
 };

@@ -293,12 +288,12 @@ static const struct snd_soc_dapm_widget 
sun8i_codec_dapm_widgets[] = {
 SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA, 0),

/* DAC Mixers */
-   SND_SOC_DAPM_MIXER("Left DAC Mixer", SND_SOC_NOPM, 0, 0,
-  sun8i_output_left_mixer_controls,
-  ARRAY_SIZE(sun8i_output_left_mixer_controls)),
-   SND_SOC_DAPM_MIXER("Right DAC Mixer", SND_SOC_NOPM, 0, 0,
-  sun8i_output_right_mixer_controls,
-  ARRAY_SIZE(sun8i_output_right_mixer_controls)),
+   SND_SOC_DAPM_MIXER("Left Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
+  sun8i_dac_mixer_controls,
+  ARRAY_SIZE(sun8i_dac_mixer_controls)),
+   SND_SOC_DAPM_MIXER("Right Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
+  sun8i_dac_mixer_controls,
+  ARRAY_SIZE(sun8i_dac_mixer_controls)),

/* Clocks */
SND_SOC_DAPM_SUPPLY("MODCLK AFI1", SUN8I_MOD_CLK_ENA,
@@ -340,8 +335,10 @@ static const struct snd_soc_dapm_route 
sun8i_codec_dapm_routes[] = {
{ "Digital Right DAC", NULL, "DAC" },

/* DAC Mixer Routes */
-   { "Left DAC Mixer", "LSlot 0", "Digital Left DAC"},
-   { "Right DAC Mixer", "RSlot 0", "Digital Right DAC"},
+   { "Left Digital DAC Mixer", "AIF1 Slot 0 Digital DAC Playback Switch",
+ "Digital Left DAC"},
+   { "Right Digital DAC Mixer", "AIF1 Slot 0 Digital DAC Playback Switch ",


The extra space fixed in the next patch could be squashed into this
patch. Otherwise,


Oh, yes, sorry about that.

I will send a V4 with the fixes you pointed me on this series.

Thanks!

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v3 2/5] ASoC: sun8i-codec: Update mixer to use SOC_DAPM_DOUBLE

[Mylene Josserand]

Hi Chen-Yu,

On 20/03/2017 12:46, Chen-Yu Tsai wrote:

On Sat, Mar 18, 2017 at 3:55 PM, Mylène Josserand
 wrote:

Update the driver to use the new SOC_DAPM_DOUBLE definition
on the digital DAC mixer.
Update the names accordingly as, when they are shared, the
controls are not prefixed with the widget's name anymore.

Signed-off-by: Mylène Josserand 
---
 sound/soc/sunxi/sun8i-codec.c | 45 ---
 1 file changed, 21 insertions(+), 24 deletions(-)

diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
index d60f6fbd36a2..107fa8213600 100644
--- a/sound/soc/sunxi/sun8i-codec.c
+++ b/sound/soc/sunxi/sun8i-codec.c
@@ -259,25 +259,20 @@ static int sun8i_codec_hw_params(struct snd_pcm_substream 
*substream,
return 0;
 }

-static const struct snd_kcontrol_new sun8i_output_left_mixer_controls[] = {
-   SOC_DAPM_SINGLE("LSlot 0", SUN8I_DAC_MXR_SRC,
-   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA0L, 1, 0),
-   SOC_DAPM_SINGLE("LSlot 1", SUN8I_DAC_MXR_SRC,
-   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA1L, 1, 0),
-   SOC_DAPM_SINGLE("DACL", SUN8I_DAC_MXR_SRC,
-   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF2DACL, 1, 0),
-   SOC_DAPM_SINGLE("ADCL", SUN8I_DAC_MXR_SRC,
-   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_ADCL, 1, 0),
-};
-
-static const struct snd_kcontrol_new sun8i_output_right_mixer_controls[] = {
-   SOC_DAPM_SINGLE("RSlot 0", SUN8I_DAC_MXR_SRC,
+static const struct snd_kcontrol_new sun8i_dac_mixer_controls[] = {
+   SOC_DAPM_DOUBLE("AIF1 Slot 0 Digital DAC Playback Switch",
+   SUN8I_DAC_MXR_SRC,
+   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA0L,
SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF1DA0R, 1, 0),
-   SOC_DAPM_SINGLE("RSlot 1", SUN8I_DAC_MXR_SRC,
+   SOC_DAPM_DOUBLE("AIF1 Slot 1 Digital DAC Playback Switch",
+   SUN8I_DAC_MXR_SRC,
+   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA1L,
SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF1DA1R, 1, 0),
-   SOC_DAPM_SINGLE("DACR", SUN8I_DAC_MXR_SRC,
+   SOC_DAPM_DOUBLE("AIF2 Digital DAC Playback Switch", SUN8I_DAC_MXR_SRC,
+   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF2DACL,
SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF2DACR, 1, 0),
-   SOC_DAPM_SINGLE("ADCR", SUN8I_DAC_MXR_SRC,
+   SOC_DAPM_DOUBLE("ADC Digital DAC Playback Switch", SUN8I_DAC_MXR_SRC,
+   SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_ADCL,
SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_ADCR, 1, 0),
 };

@@ -293,12 +288,12 @@ static const struct snd_soc_dapm_widget 
sun8i_codec_dapm_widgets[] = {
 SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA, 0),

/* DAC Mixers */
-   SND_SOC_DAPM_MIXER("Left DAC Mixer", SND_SOC_NOPM, 0, 0,
-  sun8i_output_left_mixer_controls,
-  ARRAY_SIZE(sun8i_output_left_mixer_controls)),
-   SND_SOC_DAPM_MIXER("Right DAC Mixer", SND_SOC_NOPM, 0, 0,
-  sun8i_output_right_mixer_controls,
-  ARRAY_SIZE(sun8i_output_right_mixer_controls)),
+   SND_SOC_DAPM_MIXER("Left Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
+  sun8i_dac_mixer_controls,
+  ARRAY_SIZE(sun8i_dac_mixer_controls)),
+   SND_SOC_DAPM_MIXER("Right Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
+  sun8i_dac_mixer_controls,
+  ARRAY_SIZE(sun8i_dac_mixer_controls)),

/* Clocks */
SND_SOC_DAPM_SUPPLY("MODCLK AFI1", SUN8I_MOD_CLK_ENA,
@@ -340,8 +335,10 @@ static const struct snd_soc_dapm_route 
sun8i_codec_dapm_routes[] = {
{ "Digital Right DAC", NULL, "DAC" },

/* DAC Mixer Routes */
-   { "Left DAC Mixer", "LSlot 0", "Digital Left DAC"},
-   { "Right DAC Mixer", "RSlot 0", "Digital Right DAC"},
+   { "Left Digital DAC Mixer", "AIF1 Slot 0 Digital DAC Playback Switch",
+ "Digital Left DAC"},
+   { "Right Digital DAC Mixer", "AIF1 Slot 0 Digital DAC Playback Switch ",


The extra space fixed in the next patch could be squashed into this
patch. Otherwise,


Oh, yes, sorry about that.

I will send a V4 with the fixes you pointed me on this series.

Thanks!

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: Applied "ASoC: sun8i-codec: Update mixer to use SOC_DAPM_DOUBLE" to the asoc tree

[Mylene Josserand]

Hello,

On 16/03/2017 15:06, Mark Brown wrote:

On Wed, Mar 15, 2017 at 10:15:22PM +0800, Chen-Yu Tsai wrote:


It depends on the second half of commit 4aa8146c89f3 ("ASoC: sun8i-codec:
Remove analog "HP" widget"), which is also a cleanup. Would it be OK
to pick these two over to fixes then? Or should we send a clean version
instead?


That also doesn't pick over cleanly, can you send a new version against
Linus' tree, that'll be easiest and safest I think.



No problem, I will do that.

Thank you!

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: Applied "ASoC: sun8i-codec: Update mixer to use SOC_DAPM_DOUBLE" to the asoc tree

[Mylene Josserand]

Hello,

On 16/03/2017 15:06, Mark Brown wrote:

On Wed, Mar 15, 2017 at 10:15:22PM +0800, Chen-Yu Tsai wrote:


It depends on the second half of commit 4aa8146c89f3 ("ASoC: sun8i-codec:
Remove analog "HP" widget"), which is also a cleanup. Would it be OK
to pick these two over to fixes then? Or should we send a clean version
instead?


That also doesn't pick over cleanly, can you send a new version against
Linus' tree, that'll be easiest and safest I think.



No problem, I will do that.

Thank you!

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 4/4] ASoC: sun8i-codec: Convert to use SND_SOC_DAPM_AIF_IN

[Mylene Josserand]

Hi Chen-Yu,

Thank you for the review.

On 06/03/2017 10:56, Chen-Yu Tsai wrote:

On Fri, Feb 10, 2017 at 5:41 PM, Mylène Josserand
 wrote:

Update the driver to use SND_SOC_DAPM_AIF_IN instead of
SND_SOC_DAPM_DAC.

Set the route names so it must be updated on the device tree too.

Signed-off-by: Mylène Josserand 
---
 arch/arm/boot/dts/sun8i-a33.dtsi |  4 ++--


This patch looks OK, but having the DTS changes in the same patch
probably isn't a good idea. I would really like to see this series
merged for 4.11, so we can expose a good mixer interface to userspace
during the first kernel release supporting the A33 codec. That likely
means some breakage between when the asoc bits and the dts bits land
though.


Yes, as it means some breakage, I did not know if 2 patches will be fine 
or not.




Maxime, any ideas?



I asked him directly and he agrees.

It is fine for me so I will send a v2 with this patch split.

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com



Regards
ChenYu


 sound/soc/sunxi/sun8i-codec.c| 20 +++-
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 4e34ec6613a0..e9e2e7312460 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -78,8 +78,8 @@
simple-audio-card,mclk-fs = <512>;
simple-audio-card,aux-devs = <_analog>;
simple-audio-card,routing =
-   "Left DAC", "Digital Left DAC",
-   "Right DAC", "Digital Right DAC";
+   "Left DAC", "AIF1 Slot 0 Left",
+   "Right DAC", "AIF1 Slot 0 Right";
status = "disabled";

simple-audio-card,cpu {
diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
index a75a983974d9..9b15a5ee235f 100644
--- a/sound/soc/sunxi/sun8i-codec.c
+++ b/sound/soc/sunxi/sun8i-codec.c
@@ -281,11 +281,13 @@ static const struct snd_soc_dapm_widget 
sun8i_codec_dapm_widgets[] = {
SND_SOC_DAPM_SUPPLY("DAC", SUN8I_DAC_DIG_CTRL, SUN8I_DAC_DIG_CTRL_ENDA,
0, NULL, 0),

-   /* Analog DAC */
-   SND_SOC_DAPM_DAC("Digital Left DAC", "Playback", SUN8I_AIF1_DACDAT_CTRL,
-SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA, 0),
-   SND_SOC_DAPM_DAC("Digital Right DAC", "Playback", 
SUN8I_AIF1_DACDAT_CTRL,
-SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA, 0),
+   /* Analog DAC AIF */
+   SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Left", "Playback", 0,
+   SUN8I_AIF1_DACDAT_CTRL,
+   SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA, 0),
+   SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Right", "Playback", 0,
+   SUN8I_AIF1_DACDAT_CTRL,
+   SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA, 0),

/* DAC Mixers */
SOC_MIXER_ARRAY("Left Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
@@ -329,14 +331,14 @@ static const struct snd_soc_dapm_route 
sun8i_codec_dapm_routes[] = {
{ "DAC", NULL, "MODCLK DAC" },

/* DAC Routes */
-   { "Digital Left DAC", NULL, "DAC" },
-   { "Digital Right DAC", NULL, "DAC" },
+   { "AIF1 Slot 0 Right", NULL, "DAC" },
+   { "AIF1 Slot 0 Left", NULL, "DAC" },

/* DAC Mixer Routes */
{ "Left Digital DAC Mixer", "AIF1 Slot 0 Digital DAC Playback Switch",
- "Digital Left DAC"},
+ "AIF1 Slot 0 Left"},
{ "Right Digital DAC Mixer", "AIF1 Slot 0 Digital DAC Playback Switch ",
- "Digital Right DAC"},
+ "AIF1 Slot 0 Right"},
 };

 static struct snd_soc_dai_ops sun8i_codec_dai_ops = {
--
2.11.0

Re: [PATCH 4/4] ASoC: sun8i-codec: Convert to use SND_SOC_DAPM_AIF_IN

[Mylene Josserand]

Hi Chen-Yu,

Thank you for the review.

On 06/03/2017 10:56, Chen-Yu Tsai wrote:

On Fri, Feb 10, 2017 at 5:41 PM, Mylène Josserand
 wrote:

Update the driver to use SND_SOC_DAPM_AIF_IN instead of
SND_SOC_DAPM_DAC.

Set the route names so it must be updated on the device tree too.

Signed-off-by: Mylène Josserand 
---
 arch/arm/boot/dts/sun8i-a33.dtsi |  4 ++--


This patch looks OK, but having the DTS changes in the same patch
probably isn't a good idea. I would really like to see this series
merged for 4.11, so we can expose a good mixer interface to userspace
during the first kernel release supporting the A33 codec. That likely
means some breakage between when the asoc bits and the dts bits land
though.


Yes, as it means some breakage, I did not know if 2 patches will be fine 
or not.




Maxime, any ideas?



I asked him directly and he agrees.

It is fine for me so I will send a v2 with this patch split.

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com



Regards
ChenYu


 sound/soc/sunxi/sun8i-codec.c| 20 +++-
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index 4e34ec6613a0..e9e2e7312460 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -78,8 +78,8 @@
simple-audio-card,mclk-fs = <512>;
simple-audio-card,aux-devs = <_analog>;
simple-audio-card,routing =
-   "Left DAC", "Digital Left DAC",
-   "Right DAC", "Digital Right DAC";
+   "Left DAC", "AIF1 Slot 0 Left",
+   "Right DAC", "AIF1 Slot 0 Right";
status = "disabled";

simple-audio-card,cpu {
diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
index a75a983974d9..9b15a5ee235f 100644
--- a/sound/soc/sunxi/sun8i-codec.c
+++ b/sound/soc/sunxi/sun8i-codec.c
@@ -281,11 +281,13 @@ static const struct snd_soc_dapm_widget 
sun8i_codec_dapm_widgets[] = {
SND_SOC_DAPM_SUPPLY("DAC", SUN8I_DAC_DIG_CTRL, SUN8I_DAC_DIG_CTRL_ENDA,
0, NULL, 0),

-   /* Analog DAC */
-   SND_SOC_DAPM_DAC("Digital Left DAC", "Playback", SUN8I_AIF1_DACDAT_CTRL,
-SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA, 0),
-   SND_SOC_DAPM_DAC("Digital Right DAC", "Playback", 
SUN8I_AIF1_DACDAT_CTRL,
-SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA, 0),
+   /* Analog DAC AIF */
+   SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Left", "Playback", 0,
+   SUN8I_AIF1_DACDAT_CTRL,
+   SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA, 0),
+   SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Right", "Playback", 0,
+   SUN8I_AIF1_DACDAT_CTRL,
+   SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA, 0),

/* DAC Mixers */
SOC_MIXER_ARRAY("Left Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
@@ -329,14 +331,14 @@ static const struct snd_soc_dapm_route 
sun8i_codec_dapm_routes[] = {
{ "DAC", NULL, "MODCLK DAC" },

/* DAC Routes */
-   { "Digital Left DAC", NULL, "DAC" },
-   { "Digital Right DAC", NULL, "DAC" },
+   { "AIF1 Slot 0 Right", NULL, "DAC" },
+   { "AIF1 Slot 0 Left", NULL, "DAC" },

/* DAC Mixer Routes */
{ "Left Digital DAC Mixer", "AIF1 Slot 0 Digital DAC Playback Switch",
- "Digital Left DAC"},
+ "AIF1 Slot 0 Left"},
{ "Right Digital DAC Mixer", "AIF1 Slot 0 Digital DAC Playback Switch ",
- "Digital Right DAC"},
+ "AIF1 Slot 0 Right"},
 };

 static struct snd_soc_dai_ops sun8i_codec_dai_ops = {
--
2.11.0

Re: [PATCH v4 1/8] ASoC: sun4i-i2s: Update binding documentation to include A31

[Mylene Josserand]

Hello Mark Brown,

Thank you to have applied my patches!

On 02/02/2017 10:24, Mylène Josserand wrote:

Add a new compatible for sun4i-i2s driver to handle some
SoCs that have a reset line that must be asserted/deasserted.

This new compatible, "allwinner,sun6i-a31-i2s", requires the
property "resets" which should be a phandle to the reset line.
Except these differences, the compatible is identical to previous one
which will not handle a reset line.

Signed-off-by: Mylène Josserand 
Acked-by: Maxime Ripard 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/sound/sun4i-i2s.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt 
b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
index 7b526ec64991..f4adc58f82ba 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
@@ -7,6 +7,7 @@ Required properties:

 - compatible: should be one of the followings
- "allwinner,sun4i-a10-i2s"
+   - "allwinner,sun6i-a31-i2s"
 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: should contain the I2S interrupt.
@@ -19,6 +20,10 @@ Required properties:
- "mod" : module clock for the I2S controller
 - #sound-dai-cells : Must be equal to 0

+Required properties for the following compatibles:
+   - "allwinner,sun6i-a31-i2s"
+- resets: phandle to the reset line for this codec
+
 Example:

 i2s0: i2s@01c22400 {



For all my series, you did not pick-up this patch. I was wondering if 
you have any comment on it? Is there something wrong?


Thank you in advance,

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v4 1/8] ASoC: sun4i-i2s: Update binding documentation to include A31

[Mylene Josserand]

Hello Mark Brown,

Thank you to have applied my patches!

On 02/02/2017 10:24, Mylène Josserand wrote:

Add a new compatible for sun4i-i2s driver to handle some
SoCs that have a reset line that must be asserted/deasserted.

This new compatible, "allwinner,sun6i-a31-i2s", requires the
property "resets" which should be a phandle to the reset line.
Except these differences, the compatible is identical to previous one
which will not handle a reset line.

Signed-off-by: Mylène Josserand 
Acked-by: Maxime Ripard 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/sound/sun4i-i2s.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt 
b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
index 7b526ec64991..f4adc58f82ba 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
@@ -7,6 +7,7 @@ Required properties:

 - compatible: should be one of the followings
- "allwinner,sun4i-a10-i2s"
+   - "allwinner,sun6i-a31-i2s"
 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: should contain the I2S interrupt.
@@ -19,6 +20,10 @@ Required properties:
- "mod" : module clock for the I2S controller
 - #sound-dai-cells : Must be equal to 0

+Required properties for the following compatibles:
+   - "allwinner,sun6i-a31-i2s"
+- resets: phandle to the reset line for this codec
+
 Example:

 i2s0: i2s@01c22400 {



For all my series, you did not pick-up this patch. I was wondering if 
you have any comment on it? Is there something wrong?


Thank you in advance,

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v4 3/8] ASoC: Add sun8i digital audio codec

[Mylene Josserand]

Hi Chen-Yu,

On 07/02/2017 09:39, Chen-Yu Tsai wrote:

Hi,

On Thu, Feb 2, 2017 at 5:24 PM, Mylène Josserand
 wrote:

Add the sun8i audio codec which handles the digital register of
A33 codec.
The driver handles only the basic playback from the DAC to headphones.
All other features (microphone, capture, etc) will be added later.

Signed-off-by: Mylène Josserand 
Acked-by: Maxime Ripard 
---
 sound/soc/sunxi/Kconfig   |  11 +
 sound/soc/sunxi/Makefile  |   1 +
 sound/soc/sunxi/sun8i-codec.c | 498 ++
 3 files changed, 510 insertions(+)
 create mode 100644 sound/soc/sunxi/sun8i-codec.c

diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
index 6c344e16aca4..13a8267f17c7 100644
--- a/sound/soc/sunxi/Kconfig
+++ b/sound/soc/sunxi/Kconfig
@@ -9,6 +9,17 @@ config SND_SUN4I_CODEC
  Select Y or M to add support for the Codec embedded in the Allwinner
  A10 and affiliated SoCs.

+config SND_SUN8I_CODEC
+   tristate "Allwinner SUN8I audio codec"
+   depends on OF
+   depends on MACH_SUN8I || COMPILE_TEST
+   select REGMAP_MMIO
+   help
+ This option enables the digital part of the internal audio codec for
+ Allwinner sun8i SoC (and particularly A33).
+
+ Say Y or M if you want to add sun8i digital audio codec support.
+
 config SND_SUN8I_CODEC_ANALOG
tristate "Allwinner sun8i Codec Analog Controls Support"
depends on MACH_SUN8I || COMPILE_TEST
diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
index 241c0df9ca0c..1f1af6271731 100644
--- a/sound/soc/sunxi/Makefile
+++ b/sound/soc/sunxi/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o
 obj-$(CONFIG_SND_SUN4I_I2S) += sun4i-i2s.o
 obj-$(CONFIG_SND_SUN4I_SPDIF) += sun4i-spdif.o
 obj-$(CONFIG_SND_SUN8I_CODEC_ANALOG) += sun8i-codec-analog.o
+obj-$(CONFIG_SND_SUN8I_CODEC) += sun8i-codec.o
diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
new file mode 100644
index ..b92bdc8361af
--- /dev/null
+++ b/sound/soc/sunxi/sun8i-codec.c
@@ -0,0 +1,498 @@
+/*
+ * This driver supports the digital controls for the internal codec
+ * found in Allwinner's A33 SoCs.
+ *
+ * (C) Copyright 2010-2016
+ * Reuuimlla Technology Co., Ltd. 
+ * huangxin 
+ * Mylène Josserand 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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 
+
+#define SUN8I_SYSCLK_CTL   0x00c
+#define SUN8I_SYSCLK_CTL_AIF1CLK_ENA   11
+#define SUN8I_SYSCLK_CTL_AIF1CLK_SRC_PLL   9
+#define SUN8I_SYSCLK_CTL_AIF1CLK_SRC   8
+#define SUN8I_SYSCLK_CTL_SYSCLK_ENA3
+#define SUN8I_SYSCLK_CTL_SYSCLK_SRC0
+#define SUN8I_MOD_CLK_ENA  0x010
+#define SUN8I_MOD_CLK_ENA_AIF1 15
+#define SUN8I_MOD_CLK_ENA_DAC  2
+#define SUN8I_MOD_RST_CTL  0x014
+#define SUN8I_MOD_RST_CTL_AIF1 15
+#define SUN8I_MOD_RST_CTL_DAC  2
+#define SUN8I_SYS_SR_CTRL  0x018
+#define SUN8I_SYS_SR_CTRL_AIF1_FS  12
+#define SUN8I_SYS_SR_CTRL_AIF2_FS  8
+#define SUN8I_AIF1CLK_CTRL 0x040
+#define SUN8I_AIF1CLK_CTRL_AIF1_MSTR_MOD   15
+#define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV   14
+#define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV   13
+#define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV   9
+#define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV   6
+#define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV_16(1 << 6)
+#define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ   4
+#define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_16(1 << 4)
+#define SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT   2
+#define SUN8I_AIF1_DACDAT_CTRL 0x048
+#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA   15
+#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA   14
+#define SUN8I_DAC_DIG_CTRL 0x120
+#define SUN8I_DAC_DIG_CTRL_ENDA15
+#define SUN8I_DAC_MXR_SRC  0x130
+#define 

Re: [PATCH v4 3/8] ASoC: Add sun8i digital audio codec

[Mylene Josserand]

Hi Chen-Yu,

On 07/02/2017 09:39, Chen-Yu Tsai wrote:

Hi,

On Thu, Feb 2, 2017 at 5:24 PM, Mylène Josserand
 wrote:

Add the sun8i audio codec which handles the digital register of
A33 codec.
The driver handles only the basic playback from the DAC to headphones.
All other features (microphone, capture, etc) will be added later.

Signed-off-by: Mylène Josserand 
Acked-by: Maxime Ripard 
---
 sound/soc/sunxi/Kconfig   |  11 +
 sound/soc/sunxi/Makefile  |   1 +
 sound/soc/sunxi/sun8i-codec.c | 498 ++
 3 files changed, 510 insertions(+)
 create mode 100644 sound/soc/sunxi/sun8i-codec.c

diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
index 6c344e16aca4..13a8267f17c7 100644
--- a/sound/soc/sunxi/Kconfig
+++ b/sound/soc/sunxi/Kconfig
@@ -9,6 +9,17 @@ config SND_SUN4I_CODEC
  Select Y or M to add support for the Codec embedded in the Allwinner
  A10 and affiliated SoCs.

+config SND_SUN8I_CODEC
+   tristate "Allwinner SUN8I audio codec"
+   depends on OF
+   depends on MACH_SUN8I || COMPILE_TEST
+   select REGMAP_MMIO
+   help
+ This option enables the digital part of the internal audio codec for
+ Allwinner sun8i SoC (and particularly A33).
+
+ Say Y or M if you want to add sun8i digital audio codec support.
+
 config SND_SUN8I_CODEC_ANALOG
tristate "Allwinner sun8i Codec Analog Controls Support"
depends on MACH_SUN8I || COMPILE_TEST
diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
index 241c0df9ca0c..1f1af6271731 100644
--- a/sound/soc/sunxi/Makefile
+++ b/sound/soc/sunxi/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o
 obj-$(CONFIG_SND_SUN4I_I2S) += sun4i-i2s.o
 obj-$(CONFIG_SND_SUN4I_SPDIF) += sun4i-spdif.o
 obj-$(CONFIG_SND_SUN8I_CODEC_ANALOG) += sun8i-codec-analog.o
+obj-$(CONFIG_SND_SUN8I_CODEC) += sun8i-codec.o
diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
new file mode 100644
index ..b92bdc8361af
--- /dev/null
+++ b/sound/soc/sunxi/sun8i-codec.c
@@ -0,0 +1,498 @@
+/*
+ * This driver supports the digital controls for the internal codec
+ * found in Allwinner's A33 SoCs.
+ *
+ * (C) Copyright 2010-2016
+ * Reuuimlla Technology Co., Ltd. 
+ * huangxin 
+ * Mylène Josserand 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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 
+
+#define SUN8I_SYSCLK_CTL   0x00c
+#define SUN8I_SYSCLK_CTL_AIF1CLK_ENA   11
+#define SUN8I_SYSCLK_CTL_AIF1CLK_SRC_PLL   9
+#define SUN8I_SYSCLK_CTL_AIF1CLK_SRC   8
+#define SUN8I_SYSCLK_CTL_SYSCLK_ENA3
+#define SUN8I_SYSCLK_CTL_SYSCLK_SRC0
+#define SUN8I_MOD_CLK_ENA  0x010
+#define SUN8I_MOD_CLK_ENA_AIF1 15
+#define SUN8I_MOD_CLK_ENA_DAC  2
+#define SUN8I_MOD_RST_CTL  0x014
+#define SUN8I_MOD_RST_CTL_AIF1 15
+#define SUN8I_MOD_RST_CTL_DAC  2
+#define SUN8I_SYS_SR_CTRL  0x018
+#define SUN8I_SYS_SR_CTRL_AIF1_FS  12
+#define SUN8I_SYS_SR_CTRL_AIF2_FS  8
+#define SUN8I_AIF1CLK_CTRL 0x040
+#define SUN8I_AIF1CLK_CTRL_AIF1_MSTR_MOD   15
+#define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV   14
+#define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV   13
+#define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV   9
+#define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV   6
+#define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV_16(1 << 6)
+#define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ   4
+#define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_16(1 << 4)
+#define SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT   2
+#define SUN8I_AIF1_DACDAT_CTRL 0x048
+#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA   15
+#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA   14
+#define SUN8I_DAC_DIG_CTRL 0x120
+#define SUN8I_DAC_DIG_CTRL_ENDA15
+#define SUN8I_DAC_MXR_SRC  0x130
+#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA0L15
+#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA1L14
+#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF2DACL13
+#define 

Re: [PATCH v3 1/8] ASoC: sun4i-i2s: Update binding documentation to include A31

[Mylene Josserand]

Hi,

On 01/02/2017 12:59, Mark Brown wrote:

On Wed, Feb 01, 2017 at 08:44:56AM +0100, Mylene Josserand wrote:

On 31/01/2017 22:17, Mark Brown wrote:

On Tue, Jan 31, 2017 at 11:05:45AM +0100, Mylène Josserand wrote:

Add a new compatible for sun4i-i2s driver to handle some
SoCs that have a reset line that must be asserted/deasserted.



This doesn't apply against current code, please check and resend.



I based my series on linux-next 20170131. Which one I should use?


You should be submitting against my git tree (which should be what's in
-next...).

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next



Okay, thank you! I will update my series according to your branch.

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v3 1/8] ASoC: sun4i-i2s: Update binding documentation to include A31

[Mylene Josserand]

Hi,

On 01/02/2017 12:59, Mark Brown wrote:

On Wed, Feb 01, 2017 at 08:44:56AM +0100, Mylene Josserand wrote:

On 31/01/2017 22:17, Mark Brown wrote:

On Tue, Jan 31, 2017 at 11:05:45AM +0100, Mylène Josserand wrote:

Add a new compatible for sun4i-i2s driver to handle some
SoCs that have a reset line that must be asserted/deasserted.



This doesn't apply against current code, please check and resend.



I based my series on linux-next 20170131. Which one I should use?


You should be submitting against my git tree (which should be what's in
-next...).

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next



Okay, thank you! I will update my series according to your branch.

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v3 1/8] ASoC: sun4i-i2s: Update binding documentation to include A31

[Mylene Josserand]

Hello,

On 31/01/2017 22:17, Mark Brown wrote:

On Tue, Jan 31, 2017 at 11:05:45AM +0100, Mylène Josserand wrote:

Add a new compatible for sun4i-i2s driver to handle some
SoCs that have a reset line that must be asserted/deasserted.


This doesn't apply against current code, please check and resend.



I based my series on linux-next 20170131. Which one I should use?

Thank you in advance,

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v3 1/8] ASoC: sun4i-i2s: Update binding documentation to include A31

[Mylene Josserand]

Hello,

On 31/01/2017 22:17, Mark Brown wrote:

On Tue, Jan 31, 2017 at 11:05:45AM +0100, Mylène Josserand wrote:

Add a new compatible for sun4i-i2s driver to handle some
SoCs that have a reset line that must be asserted/deasserted.


This doesn't apply against current code, please check and resend.



I based my series on linux-next 20170131. Which one I should use?

Thank you in advance,

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2 07/10] dt-bindings: sound: Add sun8i audio documentation

[Mylene Josserand]

Hi,

On 17/01/2017 17:50, Mark Brown wrote:

On Tue, Jan 17, 2017 at 03:02:27PM +0100, Mylène Josserand wrote:

Add the documentation for dt-binding of the digital audio codec driver
and the audio card driver for Sun8i SoCs.



Please submit patches using subject lines reflecting the style for the
subsystem.  This makes it easier for people to identify relevant
patches.  Look at what existing commits in the area you're changing are
doing and make sure your subject lines visually resemble what they're
doing.



Yeah, sorry about that. Maxime indicated it in another patch. I will 
keep it in mind for next times.


Anyway, thank you for the review!

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2 07/10] dt-bindings: sound: Add sun8i audio documentation

[Mylene Josserand]

Hi,

On 17/01/2017 17:50, Mark Brown wrote:

On Tue, Jan 17, 2017 at 03:02:27PM +0100, Mylène Josserand wrote:

Add the documentation for dt-binding of the digital audio codec driver
and the audio card driver for Sun8i SoCs.



Please submit patches using subject lines reflecting the style for the
subsystem.  This makes it easier for people to identify relevant
patches.  Look at what existing commits in the area you're changing are
doing and make sure your subject lines visually resemble what they're
doing.



Yeah, sorry about that. Maxime indicated it in another patch. I will 
keep it in mind for next times.


Anyway, thank you for the review!

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2 03/10] dt-bindings: sound: Add new reset compatible for sun4i-i2s

[Mylene Josserand]

Hi,

On 17/01/2017 17:46, Maxime Ripard wrote:

On Tue, Jan 17, 2017 at 03:02:23PM +0100, Mylène Josserand wrote:

Add a new compatible for sun4i-i2s driver to handle some
SoCs that have a reset line that must be asserted/deasserted.

This new compatible, "allwinner,sun6i-a31-i2s", requires two
properties:
- resets: phandle to the reset line
- reset-names: the name of the reset line ("rst").
Except these differences, the compatible is identical to previous one
which will not handle a reset line.

Signed-off-by: Mylène Josserand 
---
 .../devicetree/bindings/sound/sun4i-i2s.txt| 23 ++
 1 file changed, 23 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt 
b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
index 7a2c0945fd22..f673206e309b 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
@@ -7,6 +7,7 @@ Required properties:

 - compatible: should be one of the following:
- "allwinner,sun4i-a10-i2s"
+   - "allwinner,sun6i-a31-i2s" for controller with reset lines


That's not only for controllers with reset lines, but for the
controllers found in the A31 (and later). I'd simply drop the last
part of that line.


ACK




 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: should contain the I2S interrupt.
@@ -19,7 +20,13 @@ Required properties:
- "mod" : module clock for the I2S controller
 - #sound-dai-cells : Must be equal to 0

+Required properties for the following compatibles:
+   - "allwinner,sun6i-a31-i2s"
+- resets: phandle to the reset line for this codec
+- reset-names: Contains the reset signal name "rst"


You don't need reset-names if there's a single reset line.



ACK


+
 Example:
+For "allwinner,sun4i-a10-i2s":

 i2s0: i2s@01c22400 {
#sound-dai-cells = <0>;
@@ -32,3 +39,19 @@ i2s0: i2s@01c22400 {
   < SUN4I_DMA_NORMAL 3>;
dma-names = "rx", "tx";
 };
+
+For "allwinner,sun6i-a31-i2s":
+
+dai: dai@01c22c00 {
+   #sound-dai-cells = <0>;
+   compatible = "allwinner,sun6i-a31-i2s";
+   reg = <0x01c22c00 0x200>;
+   interrupts = ;
+   clocks = < CLK_BUS_CODEC>, < CLK_AC_DIG>;
+   clock-names = "apb", "mod";
+   resets = < RST_BUS_CODEC>;
+   reset-names = "rst";
+   dmas = < 15>, /* AUDIO_CODEC port */
+   < 15>; /* AUDIO_CODEC port */
+   dma-names = "rx", "tx";
+};


And we already have an example, so there's no need to add a new one
either.


I will remove it on a V3.

Thank you the review!

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2 03/10] dt-bindings: sound: Add new reset compatible for sun4i-i2s

[Mylene Josserand]

Hi,

On 17/01/2017 17:46, Maxime Ripard wrote:

On Tue, Jan 17, 2017 at 03:02:23PM +0100, Mylène Josserand wrote:

Add a new compatible for sun4i-i2s driver to handle some
SoCs that have a reset line that must be asserted/deasserted.

This new compatible, "allwinner,sun6i-a31-i2s", requires two
properties:
- resets: phandle to the reset line
- reset-names: the name of the reset line ("rst").
Except these differences, the compatible is identical to previous one
which will not handle a reset line.

Signed-off-by: Mylène Josserand 
---
 .../devicetree/bindings/sound/sun4i-i2s.txt| 23 ++
 1 file changed, 23 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt 
b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
index 7a2c0945fd22..f673206e309b 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
@@ -7,6 +7,7 @@ Required properties:

 - compatible: should be one of the following:
- "allwinner,sun4i-a10-i2s"
+   - "allwinner,sun6i-a31-i2s" for controller with reset lines


That's not only for controllers with reset lines, but for the
controllers found in the A31 (and later). I'd simply drop the last
part of that line.


ACK




 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: should contain the I2S interrupt.
@@ -19,7 +20,13 @@ Required properties:
- "mod" : module clock for the I2S controller
 - #sound-dai-cells : Must be equal to 0

+Required properties for the following compatibles:
+   - "allwinner,sun6i-a31-i2s"
+- resets: phandle to the reset line for this codec
+- reset-names: Contains the reset signal name "rst"


You don't need reset-names if there's a single reset line.



ACK


+
 Example:
+For "allwinner,sun4i-a10-i2s":

 i2s0: i2s@01c22400 {
#sound-dai-cells = <0>;
@@ -32,3 +39,19 @@ i2s0: i2s@01c22400 {
   < SUN4I_DMA_NORMAL 3>;
dma-names = "rx", "tx";
 };
+
+For "allwinner,sun6i-a31-i2s":
+
+dai: dai@01c22c00 {
+   #sound-dai-cells = <0>;
+   compatible = "allwinner,sun6i-a31-i2s";
+   reg = <0x01c22c00 0x200>;
+   interrupts = ;
+   clocks = < CLK_BUS_CODEC>, < CLK_AC_DIG>;
+   clock-names = "apb", "mod";
+   resets = < RST_BUS_CODEC>;
+   reset-names = "rst";
+   dmas = < 15>, /* AUDIO_CODEC port */
+   < 15>; /* AUDIO_CODEC port */
+   dma-names = "rx", "tx";
+};


And we already have an example, so there's no need to add a new one
either.


I will remove it on a V3.

Thank you the review!

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2 02/10] clk: ccu-sun8i-a33: Add CLK_SET_RATE_PARENT to ac-dig

[Mylene Josserand]

Hi,

On 17/01/2017 17:44, Maxime Ripard wrote:

Hi,

On Tue, Jan 17, 2017 at 03:02:22PM +0100, Mylène Josserand wrote:

The audio DAI needs to set the clock rates of the ac-dig clock.
To make it possible, the parent PLL audio clock rates should
also be changed. This is possible via "CLK_SET_RATE_PARENT" flag.

Signed-off-by: Mylène Josserand 


Please make sure to look at the prefixes usually used in the commit
titles of the area you're working on. In this case that would have
been "clk: sunxi-ng:". I fixed it, and applied.


Okay, I will pay more attention to prefixes for commit titles for next 
times.


Thank you !

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2 02/10] clk: ccu-sun8i-a33: Add CLK_SET_RATE_PARENT to ac-dig

[Mylene Josserand]

Hi,

On 17/01/2017 17:44, Maxime Ripard wrote:

Hi,

On Tue, Jan 17, 2017 at 03:02:22PM +0100, Mylène Josserand wrote:

The audio DAI needs to set the clock rates of the ac-dig clock.
To make it possible, the parent PLL audio clock rates should
also be changed. This is possible via "CLK_SET_RATE_PARENT" flag.

Signed-off-by: Mylène Josserand 


Please make sure to look at the prefixes usually used in the commit
titles of the area you're working on. In this case that would have
been "clk: sunxi-ng:". I fixed it, and applied.


Okay, I will pay more attention to prefixes for commit titles for next 
times.


Thank you !

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2 05/10] ASoC: Add sun8i digital audio codec

[Mylene Josserand]

Hello everyone,

On 17/01/2017 15:02, Mylène Josserand wrote:

Add the sun8i audio codec which handles the digital register of
A33 codec.
The driver handles only the basic playback from the DAC to headphones.
All other features (microphone, capture, etc) will be added later.

Signed-off-by: Mylène Josserand 


[...]


+static int sun8i_codec_get_hw_rate(struct snd_pcm_hw_params *params)
+{
+   unsigned int rate = params_rate(params);
+
+   switch (rate) {
+   case 8000:
+   case 7350:
+   return 0x0;
+   case 11025:
+   return 0x1;
+   case 12000:
+   return 0x2;
+   case 16000:
+   return 0x3;
+   case 22050:
+   return 0x4;
+   case 24000:
+   return 0x5;
+   case 32000:
+   return 0x6;
+   case 44100:
+   return 0x7;
+   case 48000:
+   return 0x8;
+   case 96000:
+   return 0x9;
+   case 192000:
+   return 0xa;
+   default:
+   return -EINVAL;
+   }
+}
+
+static u32 sun8i_codec_get_mod_freq(struct snd_pcm_hw_params *params)
+{
+   unsigned int rate = params_rate(params);
+
+   switch (rate) {
+   case 176400:
+   case 88200:
+   case 44100:
+   case 22050:
+   case 11025:
+   return 22579200;
+
+   case 192000:
+   case 128000:
+   case 96000:
+   case 64000:
+   case 48000:
+   case 32000:
+   case 24000:
+   case 16000:
+   case 12000:
+   case 8000:
+   return 24576000;
+
+   default:
+   return 0;
+   }
+}


This function is not used anymore, I will remove it in v3 (once I will 
get some reviews).



+
+static int sun8i_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
+{
+   struct sun8i_codec *scodec = snd_soc_codec_get_drvdata(dai->codec);
+   u32 value;
+
+   /* clock masters */
+   switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
+   case SND_SOC_DAIFMT_CBS_CFS: /* DAI Slave */
+   value = 0x0; /* Codec Master */
+   break;
+   case SND_SOC_DAIFMT_CBM_CFM: /* DAI Master */
+   value = 0x1; /* Codec Slave */
+   break;
+   default:
+   return -EINVAL;
+   }
+   regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
+  BIT(SUN8I_AIF1CLK_CTRL_AIF1_MSTR_MOD),
+  value << SUN8I_AIF1CLK_CTRL_AIF1_MSTR_MOD);
+
+   /* clock inversion */
+   switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
+   case SND_SOC_DAIFMT_NB_NF: /* Normal */
+   value = 0x0;
+   break;
+   case SND_SOC_DAIFMT_IB_IF: /* Inversion */
+   value = 0x1;
+   break;
+   default:
+   return -EINVAL;
+   }
+   regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
+  BIT(SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV),
+  value << SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV);
+   regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
+  BIT(SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV),
+  value << SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV);
+
+   /* DAI format */
+   switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
+   case SND_SOC_DAIFMT_I2S:
+   value = 0x0;
+   break;
+   case SND_SOC_DAIFMT_LEFT_J:
+   value = 0x1;
+   break;
+   case SND_SOC_DAIFMT_RIGHT_J:
+   value = 0x2;
+   break;
+   case SND_SOC_DAIFMT_DSP_A:
+   case SND_SOC_DAIFMT_DSP_B:
+   value = 0x3;
+   break;
+   default:
+   return -EINVAL;
+   }
+   regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
+  BIT(SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT),
+  value << SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT);
+
+   return 0;
+}
+
+static int sun8i_codec_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params,
+struct snd_soc_dai *dai)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_dai *cpu_dai = rtd->cpu_dai;


Same things for these variables.


+   struct sun8i_codec *scodec = snd_soc_codec_get_drvdata(dai->codec);
+   u32 clk_freq;
+   int sample_rate, err;


ditto for "clk_freq" and "err" ones.

Sorry about that.

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2 05/10] ASoC: Add sun8i digital audio codec

[Mylene Josserand]

Hello everyone,

On 17/01/2017 15:02, Mylène Josserand wrote:

Add the sun8i audio codec which handles the digital register of
A33 codec.
The driver handles only the basic playback from the DAC to headphones.
All other features (microphone, capture, etc) will be added later.

Signed-off-by: Mylène Josserand 


[...]


+static int sun8i_codec_get_hw_rate(struct snd_pcm_hw_params *params)
+{
+   unsigned int rate = params_rate(params);
+
+   switch (rate) {
+   case 8000:
+   case 7350:
+   return 0x0;
+   case 11025:
+   return 0x1;
+   case 12000:
+   return 0x2;
+   case 16000:
+   return 0x3;
+   case 22050:
+   return 0x4;
+   case 24000:
+   return 0x5;
+   case 32000:
+   return 0x6;
+   case 44100:
+   return 0x7;
+   case 48000:
+   return 0x8;
+   case 96000:
+   return 0x9;
+   case 192000:
+   return 0xa;
+   default:
+   return -EINVAL;
+   }
+}
+
+static u32 sun8i_codec_get_mod_freq(struct snd_pcm_hw_params *params)
+{
+   unsigned int rate = params_rate(params);
+
+   switch (rate) {
+   case 176400:
+   case 88200:
+   case 44100:
+   case 22050:
+   case 11025:
+   return 22579200;
+
+   case 192000:
+   case 128000:
+   case 96000:
+   case 64000:
+   case 48000:
+   case 32000:
+   case 24000:
+   case 16000:
+   case 12000:
+   case 8000:
+   return 24576000;
+
+   default:
+   return 0;
+   }
+}


This function is not used anymore, I will remove it in v3 (once I will 
get some reviews).



+
+static int sun8i_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
+{
+   struct sun8i_codec *scodec = snd_soc_codec_get_drvdata(dai->codec);
+   u32 value;
+
+   /* clock masters */
+   switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
+   case SND_SOC_DAIFMT_CBS_CFS: /* DAI Slave */
+   value = 0x0; /* Codec Master */
+   break;
+   case SND_SOC_DAIFMT_CBM_CFM: /* DAI Master */
+   value = 0x1; /* Codec Slave */
+   break;
+   default:
+   return -EINVAL;
+   }
+   regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
+  BIT(SUN8I_AIF1CLK_CTRL_AIF1_MSTR_MOD),
+  value << SUN8I_AIF1CLK_CTRL_AIF1_MSTR_MOD);
+
+   /* clock inversion */
+   switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
+   case SND_SOC_DAIFMT_NB_NF: /* Normal */
+   value = 0x0;
+   break;
+   case SND_SOC_DAIFMT_IB_IF: /* Inversion */
+   value = 0x1;
+   break;
+   default:
+   return -EINVAL;
+   }
+   regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
+  BIT(SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV),
+  value << SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV);
+   regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
+  BIT(SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV),
+  value << SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV);
+
+   /* DAI format */
+   switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
+   case SND_SOC_DAIFMT_I2S:
+   value = 0x0;
+   break;
+   case SND_SOC_DAIFMT_LEFT_J:
+   value = 0x1;
+   break;
+   case SND_SOC_DAIFMT_RIGHT_J:
+   value = 0x2;
+   break;
+   case SND_SOC_DAIFMT_DSP_A:
+   case SND_SOC_DAIFMT_DSP_B:
+   value = 0x3;
+   break;
+   default:
+   return -EINVAL;
+   }
+   regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
+  BIT(SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT),
+  value << SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT);
+
+   return 0;
+}
+
+static int sun8i_codec_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params,
+struct snd_soc_dai *dai)
+{
+   struct snd_soc_pcm_runtime *rtd = substream->private_data;
+   struct snd_soc_dai *cpu_dai = rtd->cpu_dai;


Same things for these variables.


+   struct sun8i_codec *scodec = snd_soc_codec_get_drvdata(dai->codec);
+   u32 clk_freq;
+   int sample_rate, err;


ditto for "clk_freq" and "err" ones.

Sorry about that.

Best regards,

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 08/14] dt-bindings: sound: Add sun8i analog codec documentation

[Mylene Josserand]

Hello,


On 05/10/2016 04:59, Chen-Yu Tsai wrote:

On Wed, Oct 5, 2016 at 12:24 AM, Maxime Ripard
 wrote:

Hi,

On Tue, Oct 04, 2016 at 11:46:21AM +0200, Mylène Josserand wrote:

Add the documentation for dt-binding of the analog audiocodec
driver for SUN8I SoC.

Signed-off-by: Mylène Josserand 
---
 .../devicetree/bindings/sound/sun8i-codec-analog.txt | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt

diff --git a/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt 
b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
new file mode 100644
index 000..a03ec20
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
@@ -0,0 +1,20 @@
+* Allwinner A23/A33 Analog Codec
+
+This codec must be handled as a PRCM subnode.


Like Mark was saying, you should probably reference the sun6i-prcm.txt
binding here



Okay, I will explain more how it works.





+Required properties:
+- compatible: must be either "allwinner,sun8i-codec-analog"


Our compatible prefix is -, and using the older SoC that
introduced that block.

In this case, that would be sun6i-a31, I think?


sun6i-a31s actually, but a31s has extra line out controls,
so the right one would be sun8i-a23. Both are listed in my
original driver.



It is noted.

Thanks!


--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 08/14] dt-bindings: sound: Add sun8i analog codec documentation

[Mylene Josserand]

Hello,


On 05/10/2016 04:59, Chen-Yu Tsai wrote:

On Wed, Oct 5, 2016 at 12:24 AM, Maxime Ripard
 wrote:

Hi,

On Tue, Oct 04, 2016 at 11:46:21AM +0200, Mylène Josserand wrote:

Add the documentation for dt-binding of the analog audiocodec
driver for SUN8I SoC.

Signed-off-by: Mylène Josserand 
---
 .../devicetree/bindings/sound/sun8i-codec-analog.txt | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt

diff --git a/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt 
b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
new file mode 100644
index 000..a03ec20
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
@@ -0,0 +1,20 @@
+* Allwinner A23/A33 Analog Codec
+
+This codec must be handled as a PRCM subnode.


Like Mark was saying, you should probably reference the sun6i-prcm.txt
binding here



Okay, I will explain more how it works.





+Required properties:
+- compatible: must be either "allwinner,sun8i-codec-analog"


Our compatible prefix is -, and using the older SoC that
introduced that block.

In this case, that would be sun6i-a31, I think?


sun6i-a31s actually, but a31s has extra line out controls,
so the right one would be sun8i-a23. Both are listed in my
original driver.



It is noted.

Thanks!


--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 06/14] ASoC: Add sun8i digital audio codec

[Mylene Josserand]

Hello,


On 04/10/2016 14:40, Thomas Petazzoni wrote:

Hello,

On Tue,  4 Oct 2016 11:46:19 +0200, Mylène Josserand wrote:

Add the digital sun8i audio codec which handles the base register
(without DAI).


I'm not sure what you mean by "which handles the base register".


I wanted to explain that it is registers for audio codec and not PRCM 
ones. This is, maybe, unclear (and useless ?).





diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
index 7aee95a..9e287b0 100644
--- a/sound/soc/sunxi/Kconfig
+++ b/sound/soc/sunxi/Kconfig
@@ -27,6 +27,15 @@ config SND_SUN4I_SPDIF
  Say Y or M to add support for the S/PDIF audio block in the Allwinner
  A10 and affiliated SoCs.

+config SND_SUN8I_CODEC
+   tristate "Allwinner SUN8I audio codec"
+   select REGMAP_MMIO
+help


Indentation issue here, it should be intended with one tab, not spaces.

You probably also want a "depends on OF" here.


Yes, thanks !




+/* CODEC_OFFSET represents the offset of the codec registers
+ * and not all the DAI registers
+ */


This is not the proper comment style I believe for audio code, it
should be:

/*
 * ...
 */


+#define CODEC_OFFSET   0x200


Do you really need this CODEC_OFFSET macro? Why not simply use directly
the right offsets? I.e instead of:

  #define SUN8I_SYSCLK_CTL  (0x20c - CODEC_OFFSET)

use:

  #define SUN8I_SYSCLK_CTL  0xc


I thought it could be easier to find registers using offset but I guess 
that register's names are enough.





+#define CODEC_BASSADDRESS  0x01c22c00


This define is not used anywhere.


Yes, sorry, I forgot to remove it.




+#define SUN8I_SYSCLK_CTL   (0x20c - CODEC_OFFSET)
+#define SUN8I_SYSCLK_CTL_AIF1CLK_ENA   (11)
+#define SUN8I_SYSCLK_CTL_SYSCLK_ENA(3)
+#define SUN8I_SYSCLK_CTL_SYSCLK_SRC(0)


Parenthesis around single values are not really useful.


+#define SUN8I_MOD_CLK_ENA  (0x210 - CODEC_OFFSET)
+#define SUN8I_MOD_CLK_ENA_AIF1 (15)
+#define SUN8I_MOD_CLK_ENA_DAC  (2)
+#define SUN8I_MOD_RST_CTL  (0x214 - CODEC_OFFSET)
+#define SUN8I_MOD_RST_CTL_AIF1 (15)
+#define SUN8I_MOD_RST_CTL_DAC  (2)
+#define SUN8I_SYS_SR_CTRL  (0x218 - CODEC_OFFSET)
+#define SUN8I_SYS_SR_CTRL_AIF1_FS  (12)
+#define SUN8I_SYS_SR_CTRL_AIF2_FS  (8)
+#define SUN8I_AIF1CLK_CTRL (0x240 - CODEC_OFFSET)
+#define SUN8I_AIF1CLK_CTRL_AIF1_MSTR_MOD   (15)
+#define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV   (14)
+#define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV   (13)
+#define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV   (9)
+#define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV   (6)
+#define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ   (4)
+#define SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT   (2)
+#define SUN8I_AIF1_DACDAT_CTRL (0x248 - CODEC_OFFSET)
+#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA   (15)
+#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA   (14)
+#define SUN8I_DAC_DIG_CTRL (0x320 - CODEC_OFFSET)
+#define SUN8I_DAC_DIG_CTRL_ENDA(15)
+#define SUN8I_DAC_MXR_SRC  (0x330 - CODEC_OFFSET)
+#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA0L (15)
+#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA1L (14)
+#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF2DACL (13)
+#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_ADCL(12)
+#define SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF1DA0R (11)
+#define SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF1DA1R (10)
+#define SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF2DACR (9)
+#define SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_ADCR(8)


Indentation of the value is not very clean for those last defines.


+static int sun8i_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
+{
+   struct sun8i_codec *scodec = snd_soc_codec_get_drvdata(dai->codec);
+   unsigned long value;


I'm not sure "unsigned long" is a very good choice here, it's going to
be a 64 bits integer on 64 bits platform. I'd suggest to use "u32",
which also seems to be what's used in _set_fmt() function of the
sun4i-i2s.c driver.


Agreed, thanks !





+static int sun8i_codec_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params,
+struct snd_soc_dai *dai)
+{
+   int rs_value  = 0;


Two spaces before the = sign, not needed. Is the initialization to 0
really needed? Also, this should be a u32.


ditto




+   regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
+  0x3 << SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ,


Maybe a #define value to replace the hardcoded 0x3 ?


+  rs_value << SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ);
+
+   /* calculate bclk_lrck_div Ratio */
+   bclk_lrck_div = sample_resolution * 2;
+   switch (bclk_lrck_div) {
+  

Re: [PATCH 06/14] ASoC: Add sun8i digital audio codec

[Mylene Josserand]

Hello,


On 04/10/2016 14:40, Thomas Petazzoni wrote:

Hello,

On Tue,  4 Oct 2016 11:46:19 +0200, Mylène Josserand wrote:

Add the digital sun8i audio codec which handles the base register
(without DAI).


I'm not sure what you mean by "which handles the base register".


I wanted to explain that it is registers for audio codec and not PRCM 
ones. This is, maybe, unclear (and useless ?).





diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
index 7aee95a..9e287b0 100644
--- a/sound/soc/sunxi/Kconfig
+++ b/sound/soc/sunxi/Kconfig
@@ -27,6 +27,15 @@ config SND_SUN4I_SPDIF
  Say Y or M to add support for the S/PDIF audio block in the Allwinner
  A10 and affiliated SoCs.

+config SND_SUN8I_CODEC
+   tristate "Allwinner SUN8I audio codec"
+   select REGMAP_MMIO
+help


Indentation issue here, it should be intended with one tab, not spaces.

You probably also want a "depends on OF" here.


Yes, thanks !




+/* CODEC_OFFSET represents the offset of the codec registers
+ * and not all the DAI registers
+ */


This is not the proper comment style I believe for audio code, it
should be:

/*
 * ...
 */


+#define CODEC_OFFSET   0x200


Do you really need this CODEC_OFFSET macro? Why not simply use directly
the right offsets? I.e instead of:

  #define SUN8I_SYSCLK_CTL  (0x20c - CODEC_OFFSET)

use:

  #define SUN8I_SYSCLK_CTL  0xc


I thought it could be easier to find registers using offset but I guess 
that register's names are enough.





+#define CODEC_BASSADDRESS  0x01c22c00


This define is not used anywhere.


Yes, sorry, I forgot to remove it.




+#define SUN8I_SYSCLK_CTL   (0x20c - CODEC_OFFSET)
+#define SUN8I_SYSCLK_CTL_AIF1CLK_ENA   (11)
+#define SUN8I_SYSCLK_CTL_SYSCLK_ENA(3)
+#define SUN8I_SYSCLK_CTL_SYSCLK_SRC(0)


Parenthesis around single values are not really useful.


+#define SUN8I_MOD_CLK_ENA  (0x210 - CODEC_OFFSET)
+#define SUN8I_MOD_CLK_ENA_AIF1 (15)
+#define SUN8I_MOD_CLK_ENA_DAC  (2)
+#define SUN8I_MOD_RST_CTL  (0x214 - CODEC_OFFSET)
+#define SUN8I_MOD_RST_CTL_AIF1 (15)
+#define SUN8I_MOD_RST_CTL_DAC  (2)
+#define SUN8I_SYS_SR_CTRL  (0x218 - CODEC_OFFSET)
+#define SUN8I_SYS_SR_CTRL_AIF1_FS  (12)
+#define SUN8I_SYS_SR_CTRL_AIF2_FS  (8)
+#define SUN8I_AIF1CLK_CTRL (0x240 - CODEC_OFFSET)
+#define SUN8I_AIF1CLK_CTRL_AIF1_MSTR_MOD   (15)
+#define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV   (14)
+#define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV   (13)
+#define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV   (9)
+#define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV   (6)
+#define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ   (4)
+#define SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT   (2)
+#define SUN8I_AIF1_DACDAT_CTRL (0x248 - CODEC_OFFSET)
+#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA   (15)
+#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA   (14)
+#define SUN8I_DAC_DIG_CTRL (0x320 - CODEC_OFFSET)
+#define SUN8I_DAC_DIG_CTRL_ENDA(15)
+#define SUN8I_DAC_MXR_SRC  (0x330 - CODEC_OFFSET)
+#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA0L (15)
+#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA1L (14)
+#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF2DACL (13)
+#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_ADCL(12)
+#define SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF1DA0R (11)
+#define SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF1DA1R (10)
+#define SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF2DACR (9)
+#define SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_ADCR(8)


Indentation of the value is not very clean for those last defines.


+static int sun8i_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
+{
+   struct sun8i_codec *scodec = snd_soc_codec_get_drvdata(dai->codec);
+   unsigned long value;


I'm not sure "unsigned long" is a very good choice here, it's going to
be a 64 bits integer on 64 bits platform. I'd suggest to use "u32",
which also seems to be what's used in _set_fmt() function of the
sun4i-i2s.c driver.


Agreed, thanks !





+static int sun8i_codec_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *params,
+struct snd_soc_dai *dai)
+{
+   int rs_value  = 0;


Two spaces before the = sign, not needed. Is the initialization to 0
really needed? Also, this should be a u32.


ditto




+   regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL,
+  0x3 << SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ,


Maybe a #define value to replace the hardcoded 0x3 ?


+  rs_value << SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ);
+
+   /* calculate bclk_lrck_div Ratio */
+   bclk_lrck_div = sample_resolution * 2;
+   switch (bclk_lrck_div) {
+  

Re: [PATCH 03/14] ASoC: sun4i-i2s: Add apb reset

[Mylene Josserand]

Hello,


On 04/10/2016 17:42, Maxime Ripard wrote:

Hi,

On Tue, Oct 04, 2016 at 02:15:16PM +0200, Thomas Petazzoni wrote:

Hello,

On Tue,  4 Oct 2016 11:46:16 +0200, Mylène Josserand wrote:


 #include 
 #include 
@@ -589,6 +590,7 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
 {
struct sun4i_i2s *i2s;
struct resource *res;
+   struct reset_control *reset_apb;
void __iomem *regs;
int irq, ret;

@@ -626,7 +628,19 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
dev_err(>dev, "Can't get our mod clock\n");
return PTR_ERR(i2s->mod_clk);
}
-   
+
+   reset_apb = devm_reset_control_get(>dev, "apb_reset");


I believe this is a change in the Device Tree binding, since you're
adding support for a new resource. Perhaps the Device Tree binding
documentation should be updated accordingly?


Indeed.

You have two solutions to do that:
  - Either mark it as optional and use reset_control_get_optional
(because here, you broke the other SoCs that have that controller
but no reset line)
  - Or introduce a new compatible, and make the reset property
mandatory for that new compatible.

I prefer the latter, since you get a stricter error check, and you
cannot end up in a situation where your driver probes but is
useless. But you'll find both in our drivers.




Okay, thank you for the hints!



+   }
+
+   ret = reset_control_deassert(reset_apb);
+   if (ret < 0) {
+   dev_err(>dev, "Can't deassert apb reset (%d)\n", ret);
+   return ret;
+   }


Do you need to re-assert the reset line in the ->remove() hook?


Even better, you can add it to the runtime_pm hooks! :)



I will have a look to runtime_pm and update it for a V2.


--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 03/14] ASoC: sun4i-i2s: Add apb reset

[Mylene Josserand]

Hello,


On 04/10/2016 17:42, Maxime Ripard wrote:

Hi,

On Tue, Oct 04, 2016 at 02:15:16PM +0200, Thomas Petazzoni wrote:

Hello,

On Tue,  4 Oct 2016 11:46:16 +0200, Mylène Josserand wrote:


 #include 
 #include 
@@ -589,6 +590,7 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
 {
struct sun4i_i2s *i2s;
struct resource *res;
+   struct reset_control *reset_apb;
void __iomem *regs;
int irq, ret;

@@ -626,7 +628,19 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
dev_err(>dev, "Can't get our mod clock\n");
return PTR_ERR(i2s->mod_clk);
}
-   
+
+   reset_apb = devm_reset_control_get(>dev, "apb_reset");


I believe this is a change in the Device Tree binding, since you're
adding support for a new resource. Perhaps the Device Tree binding
documentation should be updated accordingly?


Indeed.

You have two solutions to do that:
  - Either mark it as optional and use reset_control_get_optional
(because here, you broke the other SoCs that have that controller
but no reset line)
  - Or introduce a new compatible, and make the reset property
mandatory for that new compatible.

I prefer the latter, since you get a stricter error check, and you
cannot end up in a situation where your driver probes but is
useless. But you'll find both in our drivers.




Okay, thank you for the hints!



+   }
+
+   ret = reset_control_deassert(reset_apb);
+   if (ret < 0) {
+   dev_err(>dev, "Can't deassert apb reset (%d)\n", ret);
+   return ret;
+   }


Do you need to re-assert the reset line in the ->remove() hook?


Even better, you can add it to the runtime_pm hooks! :)



I will have a look to runtime_pm and update it for a V2.


--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 02/14] clk: ccu-sun8i-a33: Add CLK_SET_RATE_PARENT to ac-dig

[Mylene Josserand]

Hello Thomas,


On 04/10/2016 14:12, Thomas Petazzoni wrote:

Hello,

On Tue,  4 Oct 2016 11:46:15 +0200, Mylène Josserand wrote:

Add the flag CLK_SET_RATE_PARENT to 'ac-dig' clock.


There is no need to repeat the commit title inside the commit log
itself. What would be more useful is to explain *why* this is needed.



Agreed, I will update it for a V2.

Thanks !

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 02/14] clk: ccu-sun8i-a33: Add CLK_SET_RATE_PARENT to ac-dig

[Mylene Josserand]

Hello Thomas,


On 04/10/2016 14:12, Thomas Petazzoni wrote:

Hello,

On Tue,  4 Oct 2016 11:46:15 +0200, Mylène Josserand wrote:

Add the flag CLK_SET_RATE_PARENT to 'ac-dig' clock.


There is no need to repeat the commit title inside the commit log
itself. What would be more useful is to explain *why* this is needed.



Agreed, I will update it for a V2.

Thanks !

--
Mylène Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH 1/2] rtc: abx80x: handle autocalibration

[Mylene JOSSERAND]

The autocalibration is separated in two bits to set in Oscillator
Control register (0x1c) :
 - OSEL bit to select the oscillator type (XT or RC).
 - ACAL bit to select the autocalibration type.

These functionnalities are exported in sysfs entries : "oscillator"
and "autocalibration". Respectively, the values are "xtal" for XT
oscillator and "rc" for RC oscillator and 0 to disable the
autocalibration cycle, 512 for a 512 seconds autocalibration cycle
and 1024 for a cycle of 1024 seconds.

Examples :
Set to XT Oscillator
echo xtal > /sys/class/rtc/rtc0/device/oscillator
Activate an autocalibration every 512 seconds
echo 512 > /sys/class/rtc/rtc0/device/autocalibration

Signed-off-by: Mylene JOSSERAND <mylene.josser...@free-electrons.com>
---
 drivers/rtc/rtc-abx80x.c | 219 +++
 1 file changed, 219 insertions(+)

diff --git a/drivers/rtc/rtc-abx80x.c b/drivers/rtc/rtc-abx80x.c
index d41bbcd..0e4c9a0 100644
--- a/drivers/rtc/rtc-abx80x.c
+++ b/drivers/rtc/rtc-abx80x.c
@@ -49,7 +49,19 @@
 
 #define ABX8XX_REG_CD_TIMER_CTL0x18
 
+#define ABX8XX_REG_OSC 0x1c
+#define ABX8XX_OSC_FOS BIT(3)
+#define ABX8XX_OSC_BOS BIT(4)
+#define ABX8XX_OSC_ACAL_512BIT(5)
+#define ABX8XX_OSC_ACAL_1024   BIT(6)
+
+#define ABX8XX_OSC_OSELBIT(7)
+
+#define ABX8XX_REG_OSS 0x1d
+#define ABX8XX_OSS_OMODE   BIT(4)
+
 #define ABX8XX_REG_CFG_KEY 0x1f
+#define ABX8XX_CFG_KEY_OSC 0xa1
 #define ABX8XX_CFG_KEY_MISC0x9d
 
 #define ABX8XX_REG_ID0 0x28
@@ -81,6 +93,20 @@ static struct abx80x_cap abx80x_caps[] = {
[ABX80X] = {.pn = 0}
 };
 
+static int abx80x_is_rc_mode(struct i2c_client *client)
+{
+   int flags = 0;
+
+   flags =  i2c_smbus_read_byte_data(client, ABX8XX_REG_OSS);
+   if (flags < 0) {
+   dev_err(>dev,
+   "Failed to read autocalibration attribute\n");
+   return flags;
+   }
+
+   return (flags & ABX8XX_OSS_OMODE) ? 1 : 0;
+}
+
 static int abx80x_enable_trickle_charger(struct i2c_client *client,
 u8 trickle_cfg)
 {
@@ -248,6 +274,174 @@ static int abx80x_set_alarm(struct device *dev, struct 
rtc_wkalrm *t)
return 0;
 }
 
+static int abx80x_rtc_set_autocalibration(struct device *dev,
+ int autocalibration)
+{
+   struct i2c_client *client = to_i2c_client(dev);
+   int retval, flags = 0;
+
+   if ((autocalibration != 0) && (autocalibration != 1024) &&
+   (autocalibration != 512)) {
+   dev_err(dev, "autocalibration value outside permitted range\n");
+   return -EINVAL;
+   }
+
+   flags = i2c_smbus_read_byte_data(client, ABX8XX_REG_OSC);
+   if (flags < 0)
+   return flags;
+
+   if (autocalibration == 0) {
+   flags &= ~(ABX8XX_OSC_ACAL_512 | ABX8XX_OSC_ACAL_1024);
+   } else if (autocalibration == 1024) {
+   /* 1024 autocalibration is 0x10 */
+   flags |= ABX8XX_OSC_ACAL_1024;
+   flags &= ~(ABX8XX_OSC_ACAL_512);
+   } else {
+   /* 512 autocalibration is 0x11 */
+   flags |= (ABX8XX_OSC_ACAL_1024 | ABX8XX_OSC_ACAL_512);
+   }
+
+   /* Unlock write access to Oscillator Control Register */
+   retval = i2c_smbus_write_byte_data(client, ABX8XX_REG_CFG_KEY,
+  ABX8XX_CFG_KEY_OSC);
+   if (retval < 0) {
+   dev_err(dev, "Failed to write CONFIG_KEY register\n");
+   return retval;
+   }
+
+   retval = i2c_smbus_write_byte_data(client, ABX8XX_REG_OSC, flags);
+
+   return retval;
+}
+
+static int abx80x_rtc_get_autocalibration(struct device *dev)
+{
+   struct i2c_client *client = to_i2c_client(dev);
+   int flags = 0, autocalibration;
+
+   flags =  i2c_smbus_read_byte_data(client, ABX8XX_REG_OSC);
+   if (flags < 0)
+   return flags;
+
+   if (flags & ABX8XX_OSC_ACAL_512)
+   autocalibration = 512;
+   else if (flags & ABX8XX_OSC_ACAL_1024)
+   autocalibration = 1024;
+   else
+   autocalibration = 0;
+
+   return autocalibration;
+}
+
+static ssize_t autocalibration_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   int retval;
+   unsigned long autocalibration = 0;
+
+   retval = kstrtoul(buf, 10, );
+   if (retval < 0) {
+   dev_err(dev, "Failed to store RTC autocalibration attribute\n");
+   return -EINVAL;
+   }
+
+   retval = abx80x_rtc_set_autocalibration(dev, autocalibration);
+
+   return retval ? retval :

[PATCH 1/2] rtc: abx80x: handle autocalibration

[Mylene JOSSERAND]

The autocalibration is separated in two bits to set in Oscillator
Control register (0x1c) :
 - OSEL bit to select the oscillator type (XT or RC).
 - ACAL bit to select the autocalibration type.

These functionnalities are exported in sysfs entries : "oscillator"
and "autocalibration". Respectively, the values are "xtal" for XT
oscillator and "rc" for RC oscillator and 0 to disable the
autocalibration cycle, 512 for a 512 seconds autocalibration cycle
and 1024 for a cycle of 1024 seconds.

Examples :
Set to XT Oscillator
echo xtal > /sys/class/rtc/rtc0/device/oscillator
Activate an autocalibration every 512 seconds
echo 512 > /sys/class/rtc/rtc0/device/autocalibration

Signed-off-by: Mylene JOSSERAND 
---
 drivers/rtc/rtc-abx80x.c | 219 +++
 1 file changed, 219 insertions(+)

diff --git a/drivers/rtc/rtc-abx80x.c b/drivers/rtc/rtc-abx80x.c
index d41bbcd..0e4c9a0 100644
--- a/drivers/rtc/rtc-abx80x.c
+++ b/drivers/rtc/rtc-abx80x.c
@@ -49,7 +49,19 @@
 
 #define ABX8XX_REG_CD_TIMER_CTL0x18
 
+#define ABX8XX_REG_OSC 0x1c
+#define ABX8XX_OSC_FOS BIT(3)
+#define ABX8XX_OSC_BOS BIT(4)
+#define ABX8XX_OSC_ACAL_512BIT(5)
+#define ABX8XX_OSC_ACAL_1024   BIT(6)
+
+#define ABX8XX_OSC_OSELBIT(7)
+
+#define ABX8XX_REG_OSS 0x1d
+#define ABX8XX_OSS_OMODE   BIT(4)
+
 #define ABX8XX_REG_CFG_KEY 0x1f
+#define ABX8XX_CFG_KEY_OSC 0xa1
 #define ABX8XX_CFG_KEY_MISC0x9d
 
 #define ABX8XX_REG_ID0 0x28
@@ -81,6 +93,20 @@ static struct abx80x_cap abx80x_caps[] = {
[ABX80X] = {.pn = 0}
 };
 
+static int abx80x_is_rc_mode(struct i2c_client *client)
+{
+   int flags = 0;
+
+   flags =  i2c_smbus_read_byte_data(client, ABX8XX_REG_OSS);
+   if (flags < 0) {
+   dev_err(>dev,
+   "Failed to read autocalibration attribute\n");
+   return flags;
+   }
+
+   return (flags & ABX8XX_OSS_OMODE) ? 1 : 0;
+}
+
 static int abx80x_enable_trickle_charger(struct i2c_client *client,
 u8 trickle_cfg)
 {
@@ -248,6 +274,174 @@ static int abx80x_set_alarm(struct device *dev, struct 
rtc_wkalrm *t)
return 0;
 }
 
+static int abx80x_rtc_set_autocalibration(struct device *dev,
+ int autocalibration)
+{
+   struct i2c_client *client = to_i2c_client(dev);
+   int retval, flags = 0;
+
+   if ((autocalibration != 0) && (autocalibration != 1024) &&
+   (autocalibration != 512)) {
+   dev_err(dev, "autocalibration value outside permitted range\n");
+   return -EINVAL;
+   }
+
+   flags = i2c_smbus_read_byte_data(client, ABX8XX_REG_OSC);
+   if (flags < 0)
+   return flags;
+
+   if (autocalibration == 0) {
+   flags &= ~(ABX8XX_OSC_ACAL_512 | ABX8XX_OSC_ACAL_1024);
+   } else if (autocalibration == 1024) {
+   /* 1024 autocalibration is 0x10 */
+   flags |= ABX8XX_OSC_ACAL_1024;
+   flags &= ~(ABX8XX_OSC_ACAL_512);
+   } else {
+   /* 512 autocalibration is 0x11 */
+   flags |= (ABX8XX_OSC_ACAL_1024 | ABX8XX_OSC_ACAL_512);
+   }
+
+   /* Unlock write access to Oscillator Control Register */
+   retval = i2c_smbus_write_byte_data(client, ABX8XX_REG_CFG_KEY,
+  ABX8XX_CFG_KEY_OSC);
+   if (retval < 0) {
+   dev_err(dev, "Failed to write CONFIG_KEY register\n");
+   return retval;
+   }
+
+   retval = i2c_smbus_write_byte_data(client, ABX8XX_REG_OSC, flags);
+
+   return retval;
+}
+
+static int abx80x_rtc_get_autocalibration(struct device *dev)
+{
+   struct i2c_client *client = to_i2c_client(dev);
+   int flags = 0, autocalibration;
+
+   flags =  i2c_smbus_read_byte_data(client, ABX8XX_REG_OSC);
+   if (flags < 0)
+   return flags;
+
+   if (flags & ABX8XX_OSC_ACAL_512)
+   autocalibration = 512;
+   else if (flags & ABX8XX_OSC_ACAL_1024)
+   autocalibration = 1024;
+   else
+   autocalibration = 0;
+
+   return autocalibration;
+}
+
+static ssize_t autocalibration_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+   int retval;
+   unsigned long autocalibration = 0;
+
+   retval = kstrtoul(buf, 10, );
+   if (retval < 0) {
+   dev_err(dev, "Failed to store RTC autocalibration attribute\n");
+   return -EINVAL;
+   }
+
+   retval = abx80x_rtc_set_autocalibration(dev, autocalibration);
+
+   return retval ? retval : count;
+}
+
+static ssize_t autocalibrati

[PATCH 2/2] rtc: abx80x: handle the oscillator failure bit

[Mylene JOSSERAND]

Handle the Oscillator Failure ('OF') bit from Oscillator Status register
(0x1D). This bit is cleared on set_time function and is read each time the
date/time is read, but only in case of XT Oscillator selection.
In RC mode, this bit is always set.

Signed-off-by: Mylene JOSSERAND <mylene.josser...@free-electrons.com>
---
 drivers/rtc/rtc-abx80x.c | 33 +++--
 1 file changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-abx80x.c b/drivers/rtc/rtc-abx80x.c
index 0e4c9a0..ba0d619 100644
--- a/drivers/rtc/rtc-abx80x.c
+++ b/drivers/rtc/rtc-abx80x.c
@@ -58,6 +58,7 @@
 #define ABX8XX_OSC_OSELBIT(7)
 
 #define ABX8XX_REG_OSS 0x1d
+#define ABX8XX_OSS_OF  BIT(1)
 #define ABX8XX_OSS_OMODE   BIT(4)
 
 #define ABX8XX_REG_CFG_KEY 0x1f
@@ -138,7 +139,23 @@ static int abx80x_rtc_read_time(struct device *dev, struct 
rtc_time *tm)
 {
struct i2c_client *client = to_i2c_client(dev);
unsigned char buf[8];
-   int err;
+   int err, flags, rc_mode = 0;
+
+   /* Read the Oscillator Failure only in XT mode */
+   rc_mode = abx80x_is_rc_mode(client);
+   if (rc_mode < 0)
+   return rc_mode;
+
+   if (!rc_mode) {
+   flags = i2c_smbus_read_byte_data(client, ABX8XX_REG_OSS);
+   if (flags < 0)
+   return flags;
+
+   if (flags & ABX8XX_OSS_OF) {
+   dev_err(dev, "Oscillator failure, data is invalid.\n");
+   return -EINVAL;
+   }
+   }
 
err = i2c_smbus_read_i2c_block_data(client, ABX8XX_REG_HTH,
sizeof(buf), buf);
@@ -166,7 +183,7 @@ static int abx80x_rtc_set_time(struct device *dev, struct 
rtc_time *tm)
 {
struct i2c_client *client = to_i2c_client(dev);
unsigned char buf[8];
-   int err;
+   int err, flags;
 
if (tm->tm_year < 100)
return -EINVAL;
@@ -187,6 +204,18 @@ static int abx80x_rtc_set_time(struct device *dev, struct 
rtc_time *tm)
return -EIO;
}
 
+   /* Clear the OF bit of Oscillator Status Register */
+   flags = i2c_smbus_read_byte_data(client, ABX8XX_REG_OSS);
+   if (flags < 0)
+   return flags;
+
+   err = i2c_smbus_write_byte_data(client, ABX8XX_REG_OSS,
+   flags & ~ABX8XX_OSS_OF);
+   if (err < 0) {
+   dev_err(>dev, "Unable to write oscillator status 
register\n");
+   return err;
+   }
+
return 0;
 }
 
-- 
2.7.0

[PATCH 2/2] rtc: abx80x: handle the oscillator failure bit

[Mylene JOSSERAND]

Handle the Oscillator Failure ('OF') bit from Oscillator Status register
(0x1D). This bit is cleared on set_time function and is read each time the
date/time is read, but only in case of XT Oscillator selection.
In RC mode, this bit is always set.

Signed-off-by: Mylene JOSSERAND 
---
 drivers/rtc/rtc-abx80x.c | 33 +++--
 1 file changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-abx80x.c b/drivers/rtc/rtc-abx80x.c
index 0e4c9a0..ba0d619 100644
--- a/drivers/rtc/rtc-abx80x.c
+++ b/drivers/rtc/rtc-abx80x.c
@@ -58,6 +58,7 @@
 #define ABX8XX_OSC_OSELBIT(7)
 
 #define ABX8XX_REG_OSS 0x1d
+#define ABX8XX_OSS_OF  BIT(1)
 #define ABX8XX_OSS_OMODE   BIT(4)
 
 #define ABX8XX_REG_CFG_KEY 0x1f
@@ -138,7 +139,23 @@ static int abx80x_rtc_read_time(struct device *dev, struct 
rtc_time *tm)
 {
struct i2c_client *client = to_i2c_client(dev);
unsigned char buf[8];
-   int err;
+   int err, flags, rc_mode = 0;
+
+   /* Read the Oscillator Failure only in XT mode */
+   rc_mode = abx80x_is_rc_mode(client);
+   if (rc_mode < 0)
+   return rc_mode;
+
+   if (!rc_mode) {
+   flags = i2c_smbus_read_byte_data(client, ABX8XX_REG_OSS);
+   if (flags < 0)
+   return flags;
+
+   if (flags & ABX8XX_OSS_OF) {
+   dev_err(dev, "Oscillator failure, data is invalid.\n");
+   return -EINVAL;
+   }
+   }
 
err = i2c_smbus_read_i2c_block_data(client, ABX8XX_REG_HTH,
sizeof(buf), buf);
@@ -166,7 +183,7 @@ static int abx80x_rtc_set_time(struct device *dev, struct 
rtc_time *tm)
 {
struct i2c_client *client = to_i2c_client(dev);
unsigned char buf[8];
-   int err;
+   int err, flags;
 
if (tm->tm_year < 100)
return -EINVAL;
@@ -187,6 +204,18 @@ static int abx80x_rtc_set_time(struct device *dev, struct 
rtc_time *tm)
return -EIO;
}
 
+   /* Clear the OF bit of Oscillator Status Register */
+   flags = i2c_smbus_read_byte_data(client, ABX8XX_REG_OSS);
+   if (flags < 0)
+   return flags;
+
+   err = i2c_smbus_write_byte_data(client, ABX8XX_REG_OSS,
+   flags & ~ABX8XX_OSS_OF);
+   if (err < 0) {
+   dev_err(>dev, "Unable to write oscillator status 
register\n");
+   return err;
+   }
+
return 0;
 }
 
-- 
2.7.0

[PATCH 0/2] rtc: abx80x: Handle autocalibration and oscillator failure

[Mylene JOSSERAND]

The current patches handle the autocalibration and the oscillator failure
for ABX80X RTC.
The autocalibration is handled using sysfs entries and the oscillator
failure bit is handled only for the XT Oscillator.

Mylene JOSSERAND (2):
  rtc: abx80x: handle autocalibration
  rtc: abx80x: handle the oscillator failure bit

 drivers/rtc/rtc-abx80x.c | 252 ++-
 1 file changed, 250 insertions(+), 2 deletions(-)

-- 
2.7.0

[PATCH 0/2] rtc: abx80x: Handle autocalibration and oscillator failure

[Mylene JOSSERAND]

The current patches handle the autocalibration and the oscillator failure
for ABX80X RTC.
The autocalibration is handled using sysfs entries and the oscillator
failure bit is handled only for the XT Oscillator.

Mylene JOSSERAND (2):
  rtc: abx80x: handle autocalibration
  rtc: abx80x: handle the oscillator failure bit

 drivers/rtc/rtc-abx80x.c | 252 ++-
 1 file changed, 250 insertions(+), 2 deletions(-)

-- 
2.7.0

[PATCH] mmc: sdhci-tegra: convert to use GPIO descriptors

[Mylene JOSSERAND]

Modify the driver to handle GPIOs using the descriptor API.

Signed-off-by: Mylene JOSSERAND 
---
 drivers/mmc/host/sdhci-tegra.c |   32 
 1 file changed, 8 insertions(+), 24 deletions(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 93834ab..ad28b49 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -20,11 +20,10 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
+#include 
 
 #include "sdhci-pltfm.h"
 
@@ -49,7 +48,7 @@ struct sdhci_tegra_soc_data {
 
 struct sdhci_tegra {
const struct sdhci_tegra_soc_data *soc_data;
-   int power_gpio;
+   struct gpio_desc *power_gpio;
 };
 
 static u16 tegra_sdhci_readw(struct sdhci_host *host, int reg)
@@ -246,17 +245,6 @@ static const struct of_device_id sdhci_tegra_dt_match[] = {
 };
 MODULE_DEVICE_TABLE(of, sdhci_tegra_dt_match);
 
-static int sdhci_tegra_parse_dt(struct device *dev)
-{
-   struct device_node *np = dev->of_node;
-   struct sdhci_host *host = dev_get_drvdata(dev);
-   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-   struct sdhci_tegra *tegra_host = pltfm_host->priv;
-
-   tegra_host->power_gpio = of_get_named_gpio(np, "power-gpios", 0);
-   return mmc_of_parse(host->mmc);
-}
-
 static int sdhci_tegra_probe(struct platform_device *pdev)
 {
const struct of_device_id *match;
@@ -286,19 +274,15 @@ static int sdhci_tegra_probe(struct platform_device *pdev)
tegra_host->soc_data = soc_data;
pltfm_host->priv = tegra_host;
 
-   rc = sdhci_tegra_parse_dt(>dev);
+   rc = mmc_of_parse(host->mmc);
if (rc)
goto err_parse_dt;
 
-   if (gpio_is_valid(tegra_host->power_gpio)) {
-   rc = devm_gpio_request(>dev, tegra_host->power_gpio,
-  "sdhci_power");
-   if (rc) {
-   dev_err(mmc_dev(host->mmc),
-   "failed to allocate power gpio\n");
-   goto err_power_req;
-   }
-   gpio_direction_output(tegra_host->power_gpio, 1);
+   tegra_host->power_gpio = devm_gpiod_get_optional(>dev, "power",
+GPIOD_OUT_HIGH);
+   if (IS_ERR(tegra_host->power_gpio)) {
+   rc = PTR_ERR(tegra_host->power_gpio);
+   goto err_power_req;
}
 
clk = devm_clk_get(mmc_dev(host->mmc), NULL);
-- 
1.7.10.4

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

[PATCH] mmc: sdhci-tegra: convert to use GPIO descriptors

[Mylene JOSSERAND]

Modify the driver to handle GPIOs using the descriptor API.

Signed-off-by: Mylene JOSSERAND josserand.myl...@gmail.com
---
 drivers/mmc/host/sdhci-tegra.c |   32 
 1 file changed, 8 insertions(+), 24 deletions(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index 93834ab..ad28b49 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -20,11 +20,10 @@
 #include linux/io.h
 #include linux/of.h
 #include linux/of_device.h
-#include linux/of_gpio.h
-#include linux/gpio.h
 #include linux/mmc/card.h
 #include linux/mmc/host.h
 #include linux/mmc/slot-gpio.h
+#include linux/gpio/consumer.h
 
 #include sdhci-pltfm.h
 
@@ -49,7 +48,7 @@ struct sdhci_tegra_soc_data {
 
 struct sdhci_tegra {
const struct sdhci_tegra_soc_data *soc_data;
-   int power_gpio;
+   struct gpio_desc *power_gpio;
 };
 
 static u16 tegra_sdhci_readw(struct sdhci_host *host, int reg)
@@ -246,17 +245,6 @@ static const struct of_device_id sdhci_tegra_dt_match[] = {
 };
 MODULE_DEVICE_TABLE(of, sdhci_tegra_dt_match);
 
-static int sdhci_tegra_parse_dt(struct device *dev)
-{
-   struct device_node *np = dev-of_node;
-   struct sdhci_host *host = dev_get_drvdata(dev);
-   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-   struct sdhci_tegra *tegra_host = pltfm_host-priv;
-
-   tegra_host-power_gpio = of_get_named_gpio(np, power-gpios, 0);
-   return mmc_of_parse(host-mmc);
-}
-
 static int sdhci_tegra_probe(struct platform_device *pdev)
 {
const struct of_device_id *match;
@@ -286,19 +274,15 @@ static int sdhci_tegra_probe(struct platform_device *pdev)
tegra_host-soc_data = soc_data;
pltfm_host-priv = tegra_host;
 
-   rc = sdhci_tegra_parse_dt(pdev-dev);
+   rc = mmc_of_parse(host-mmc);
if (rc)
goto err_parse_dt;
 
-   if (gpio_is_valid(tegra_host-power_gpio)) {
-   rc = devm_gpio_request(pdev-dev, tegra_host-power_gpio,
-  sdhci_power);
-   if (rc) {
-   dev_err(mmc_dev(host-mmc),
-   failed to allocate power gpio\n);
-   goto err_power_req;
-   }
-   gpio_direction_output(tegra_host-power_gpio, 1);
+   tegra_host-power_gpio = devm_gpiod_get_optional(pdev-dev, power,
+GPIOD_OUT_HIGH);
+   if (IS_ERR(tegra_host-power_gpio)) {
+   rc = PTR_ERR(tegra_host-power_gpio);
+   goto err_power_req;
}
 
clk = devm_clk_get(mmc_dev(host-mmc), NULL);
-- 
1.7.10.4

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

Re: [I2C] informations + advice about messages handling

[Mylene Josserand]

Hi Jean,

Le 24/05/2013 14:20, Jean Delvare a écrit :
> On Fri, 24 May 2013 11:52:54 +0200, Mylene Josserand wrote:
>> - an audio codec tlv320aic3204 : There is a driver for this device but
>> for some reasons, we did not use it. Did not find a "SMBus compliant" in
>> its datasheet.
>
> The tlv320aic32x4 driver uses i2c_master_send, which is a shortcut to
> i2c_transfer. However it seems to only send 2 bytes on the bus at once,
> the same could be achieved with i2c_smbus_write_byte_data if needed.

Okay, thanks to have looked at it !

>
> For completeness: a device might use transactions which are compliant
> with SMBus without being formally "SMBus-compliant", because SMBus has
> more constraints than just transaction types (I kept things simple
> originally to not confuse you.) This may explain why it isn't mentioned
> in the datasheet. Or just because the manufacturer did not care because
> they target fully I2C-capable systems anyway.
>
> What you have to look at is the transaction types. They are usually
> described in the datasheet. Then compare with either the SMBus
> specification or
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/i2c/smbus-protocol
> and if they match then you can use the i2c_smbus_*() calls.


I have checked the PIC18F24201 according to your advice and, of what I 
have seen, it can handle the SMBus protocol.

Thank you for the explanation and trying to keep it simple for me :)


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

Re: [I2C] informations + advice about messages handling

[Mylene Josserand]

Hi Jean,

Le 24/05/2013 14:20, Jean Delvare a écrit :
 On Fri, 24 May 2013 11:52:54 +0200, Mylene Josserand wrote:
 - an audio codec tlv320aic3204 : There is a driver for this device but
 for some reasons, we did not use it. Did not find a SMBus compliant in
 its datasheet.

 The tlv320aic32x4 driver uses i2c_master_send, which is a shortcut to
 i2c_transfer. However it seems to only send 2 bytes on the bus at once,
 the same could be achieved with i2c_smbus_write_byte_data if needed.

Okay, thanks to have looked at it !


 For completeness: a device might use transactions which are compliant
 with SMBus without being formally SMBus-compliant, because SMBus has
 more constraints than just transaction types (I kept things simple
 originally to not confuse you.) This may explain why it isn't mentioned
 in the datasheet. Or just because the manufacturer did not care because
 they target fully I2C-capable systems anyway.

 What you have to look at is the transaction types. They are usually
 described in the datasheet. Then compare with either the SMBus
 specification or
 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/i2c/smbus-protocol
 and if they match then you can use the i2c_smbus_*() calls.


I have checked the PIC18F24201 according to your advice and, of what I 
have seen, it can handle the SMBus protocol.

Thank you for the explanation and trying to keep it simple for me :)


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

Re: [I2C] informations + advice about messages handling

[Mylene Josserand]

Le 24/05/2013 11:07, Jean Delvare a écrit :
 > On Fri, 24 May 2013 10:54:11 +0200, Mylene Josserand wrote:
 >> Ah okay ! And if there are not SMBus compliant, what function I will
 >> have to use ?
 >
 > i2c_transfer()


Okay, logic name ;)


 >> What is it doing if I use this function and that my device is not SMbus
 >> compliant ?
 >
 > This would make no sense. Your device understands only specific message
 > formats, which should be documented in its datasheet. You have to use
 > exactly that in your driver. If the message format matches SMBus, you
 > can use the SMBus API, otherwise you must use i2c_transfer() instead.

Very interesting !
Right now, my company uses the "i2c_smbus_read/write_byte_data" 
functions to talk to devices through an application. On the datasheet of 
these devices, I search but did not seem to be SMBus compliant.
As it was a software which was using these functions, we thought that a 
driver (that I would write) should be better. And here I am ! I prefer 
to understand well the mechanism before coding anything and it is 
interesting !


 >> I have some difficulties to understand the differences
 >> between SMbus and I2C :(
 >
 > SMBus is a subset of I2C. With I2C you can have messages of any length
 > and any format, with no attached semantics. SMBus restricts the
 > possibilities to a few standardized messages formats with semantics. If
 > you'd just tell us what your device is, we would be able to tell you if
 > SMBus will work or if I2C will be needed.

Thanks for the explanation.
No problem, we have 2 devices used without drivers :
- an odometer PIC18F24201 : In the datasheet, there is a SMBus select 
bit but I don't know if it is SMBus compliant.
- an audio codec tlv320aic3204 : There is a driver for this device but 
for some reasons, we did not use it. Did not find a "SMBus compliant" in 
its datasheet.


 >> (...)
 >> In my case, I have 2 segments but if I understand, the bus will not be
 >> used at the same time.
 >
 > I can't comment on that without knowing the exact topology. In
 > particular, do you have two independent segments each with its own
 > controller, or are they interconnected in some way? I2C/SMBus is very
 > simple with basic topologies but can become difficult with complex ones.

Yes of course, I understand.
For that, I will ask to our "hardware guy".


 >> (...)
 >> Okay. So the mutex blocks the I2C bus. And is it locking the bus at the
 >> beginning of a message (so when a START is send) and unlocking it after
 >> the STOP ?
 >
 > Yes.
 >
 >> So a complete message will be sent to a same device (the one which
 >> address is in the data frame) ? A device can not receive a beginning of
 >> one message (so with his address) and the end of another message
 >> destined to another device [because of "collision"], for example ?
 >
 > No, this cannot happen.


Thanks a lot for your help !


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

Re: [I2C] informations + advice about messages handling

[Mylene Josserand]

Thanks, both of you, for your answers ! It helps me a lot to understand it !

Le 24/05/2013 09:22, anish singh a écrit :
 > On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand
 >   wrote:
 >> Hi all,
 >>
 >>
 >> I am learning how i2c is working and I read that, to write in an i2c
 >> register, I need to use the function "i2c_smbus_write_byte_data".
 > Only in case your device is smbus compliant.

Ah okay ! And if there are not SMBus compliant, what function I will 
have to use ?
What is it doing if I use this function and that my device is not SMbus 
compliant ? I have some difficulties to understand the differences 
between SMbus and I2C :(


Le 24/05/2013 09:44, Jean Delvare a écrit :
 > Hi Anish, Mylène,
 >
 > On Fri, 24 May 2013 12:52:40 +0530, anish singh wrote:
 >> On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand
 >>   wrote:
 >>> I have read that this function "i2c_smbus_write_byte_data" uses
 >>> "i2c_smbus_xfer" which uses "i2c_lock_adapter".
 >>> In this function, there is a mutex so I thought that it will handle it
 >>> but it says "Get exclusive access to an I2C bus segment". What is
 >>> exactly an I2C segment ? Is it the device we are talking about ? Or is
 >>> it the use of the i2c bus ?
 >> Don't know what you are referring here.
 >
 > In the most simple case, your I2C bus has a single segment so "segment"
 > or "bus" mean the same thing.
 >
 > It only starts mattering when I2C bus multiplexing comes into play.
 > Then your bus is split into segments, with one segment (trunk) between
 > the master (controller) and the multiplexer, and one or more segments
 > (branches) hanging off the multiplexer.
 >
 > Take look at
 > https://i2c.wiki.kernel.org/index.php/I2C_bus_multiplexing
 > for a sample topology.
 >
 > But anyway the comment in front of i2c_lock_adapter() is somewhat
 > misleading. If you read the code you'll see that it always locks the
 > whole bus tree, because it uses the root segment's mutex.


Thanks ! I understand now.
In my case, I have 2 segments but if I understand, the bus will not be 
used at the same time.


 >>> I will certainly have to create an i2c driver and I would like to know
 >>> if this "collision" handling (if it is handled) is done in old kernel
 >>> (2.6.32) or is it handled only in new kernel versions ?
 >> AFAIK collision handling and detection was not supported till now
 >> in linux kernel until recently but I think this patch is doing that.
 >> I may be wrong but I didn't see collision handling in earlier linux
 >> kernels.
 >> http://thread.gmane.org/gmane.linux.kernel/1410276
 >
 > This is for a specific case. The general case is handled by the
 > per-adapter mutex for years now. 2.6.32 should be just fine in this
 > respect.

Okay. So the mutex blocks the I2C bus. And is it locking the bus at the 
beginning of a message (so when a START is send) and unlocking it after 
the STOP ?
So a complete message will be sent to a same device (the one which 
address is in the data frame) ? A device can not receive a beginning of 
one message (so with his address) and the end of another message 
destined to another device [because of "collision"], for example ?


 >>> If you have any documentation on how the i2c messages are handled in
 >>> case of different devices uses, it will help me a lot ! I will 
search in
 >>> the kernel documentation but there is many files about i2c.
 >>> And if you know a good i2c driver that I can use as an example to 
design
 >>> mine, it will be great !
 >
 > Best is to look at a driver for a device which is similar in
 > functionality to yours.

I will search that, thanks for the advice.


-- 
Mylène JOSSERAND
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [I2C] informations + advice about messages handling

[Mylene Josserand]

Thanks, both of you, for your answers ! It helps me a lot to understand it !

Le 24/05/2013 09:22, anish singh a écrit :
  On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand
  mylene.josser...@navocap.com  wrote:
  Hi all,
 
 
  I am learning how i2c is working and I read that, to write in an i2c
  register, I need to use the function i2c_smbus_write_byte_data.
  Only in case your device is smbus compliant.

Ah okay ! And if there are not SMBus compliant, what function I will 
have to use ?
What is it doing if I use this function and that my device is not SMbus 
compliant ? I have some difficulties to understand the differences 
between SMbus and I2C :(


Le 24/05/2013 09:44, Jean Delvare a écrit :
  Hi Anish, Mylène,
 
  On Fri, 24 May 2013 12:52:40 +0530, anish singh wrote:
  On Fri, May 24, 2013 at 12:41 PM, Mylene Josserand
  mylene.josser...@navocap.com  wrote:
  I have read that this function i2c_smbus_write_byte_data uses
  i2c_smbus_xfer which uses i2c_lock_adapter.
  In this function, there is a mutex so I thought that it will handle it
  but it says Get exclusive access to an I2C bus segment. What is
  exactly an I2C segment ? Is it the device we are talking about ? Or is
  it the use of the i2c bus ?
  Don't know what you are referring here.
 
  In the most simple case, your I2C bus has a single segment so segment
  or bus mean the same thing.
 
  It only starts mattering when I2C bus multiplexing comes into play.
  Then your bus is split into segments, with one segment (trunk) between
  the master (controller) and the multiplexer, and one or more segments
  (branches) hanging off the multiplexer.
 
  Take look at
  https://i2c.wiki.kernel.org/index.php/I2C_bus_multiplexing
  for a sample topology.
 
  But anyway the comment in front of i2c_lock_adapter() is somewhat
  misleading. If you read the code you'll see that it always locks the
  whole bus tree, because it uses the root segment's mutex.


Thanks ! I understand now.
In my case, I have 2 segments but if I understand, the bus will not be 
used at the same time.


  I will certainly have to create an i2c driver and I would like to know
  if this collision handling (if it is handled) is done in old kernel
  (2.6.32) or is it handled only in new kernel versions ?
  AFAIK collision handling and detection was not supported till now
  in linux kernel until recently but I think this patch is doing that.
  I may be wrong but I didn't see collision handling in earlier linux
  kernels.
  http://thread.gmane.org/gmane.linux.kernel/1410276
 
  This is for a specific case. The general case is handled by the
  per-adapter mutex for years now. 2.6.32 should be just fine in this
  respect.

Okay. So the mutex blocks the I2C bus. And is it locking the bus at the 
beginning of a message (so when a START is send) and unlocking it after 
the STOP ?
So a complete message will be sent to a same device (the one which 
address is in the data frame) ? A device can not receive a beginning of 
one message (so with his address) and the end of another message 
destined to another device [because of collision], for example ?


  If you have any documentation on how the i2c messages are handled in
  case of different devices uses, it will help me a lot ! I will 
search in
  the kernel documentation but there is many files about i2c.
  And if you know a good i2c driver that I can use as an example to 
design
  mine, it will be great !
 
  Best is to look at a driver for a device which is similar in
  functionality to yours.

I will search that, thanks for the advice.


-- 
Mylène JOSSERAND
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [I2C] informations + advice about messages handling

[Mylene Josserand]

Le 24/05/2013 11:07, Jean Delvare a écrit :
  On Fri, 24 May 2013 10:54:11 +0200, Mylene Josserand wrote:
  Ah okay ! And if there are not SMBus compliant, what function I will
  have to use ?
 
  i2c_transfer()


Okay, logic name ;)


  What is it doing if I use this function and that my device is not SMbus
  compliant ?
 
  This would make no sense. Your device understands only specific message
  formats, which should be documented in its datasheet. You have to use
  exactly that in your driver. If the message format matches SMBus, you
  can use the SMBus API, otherwise you must use i2c_transfer() instead.

Very interesting !
Right now, my company uses the i2c_smbus_read/write_byte_data 
functions to talk to devices through an application. On the datasheet of 
these devices, I search but did not seem to be SMBus compliant.
As it was a software which was using these functions, we thought that a 
driver (that I would write) should be better. And here I am ! I prefer 
to understand well the mechanism before coding anything and it is 
interesting !


  I have some difficulties to understand the differences
  between SMbus and I2C :(
 
  SMBus is a subset of I2C. With I2C you can have messages of any length
  and any format, with no attached semantics. SMBus restricts the
  possibilities to a few standardized messages formats with semantics. If
  you'd just tell us what your device is, we would be able to tell you if
  SMBus will work or if I2C will be needed.

Thanks for the explanation.
No problem, we have 2 devices used without drivers :
- an odometer PIC18F24201 : In the datasheet, there is a SMBus select 
bit but I don't know if it is SMBus compliant.
- an audio codec tlv320aic3204 : There is a driver for this device but 
for some reasons, we did not use it. Did not find a SMBus compliant in 
its datasheet.


  (...)
  In my case, I have 2 segments but if I understand, the bus will not be
  used at the same time.
 
  I can't comment on that without knowing the exact topology. In
  particular, do you have two independent segments each with its own
  controller, or are they interconnected in some way? I2C/SMBus is very
  simple with basic topologies but can become difficult with complex ones.

Yes of course, I understand.
For that, I will ask to our hardware guy.


  (...)
  Okay. So the mutex blocks the I2C bus. And is it locking the bus at the
  beginning of a message (so when a START is send) and unlocking it after
  the STOP ?
 
  Yes.
 
  So a complete message will be sent to a same device (the one which
  address is in the data frame) ? A device can not receive a beginning of
  one message (so with his address) and the end of another message
  destined to another device [because of collision], for example ?
 
  No, this cannot happen.


Thanks a lot for your help !


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