Re: [PATCH 2/2] MAINTAINERS: mtd/nand: update Microchip nand entry

[Yang, Wenyou]

On 2018/1/9 21:46, Nicolas Ferre wrote:

Update Wenyou Yang email address.
Take advantage of this update to move this entry to the MICROCHIP / ATMEL
location and add the DT binding documentation link.

Signed-off-by: Nicolas Ferre 

Acked-by: Wenyou Yang 

---
Hi,

Patch against next-20180109.
This patch is somehow dependent on the previous one in the series
("MAINTAINERS: linux-media: update Microchip ISI and ISC entries") but can be
rebased easily.

I don't know if it's better to have them added at the end of the development
cycle or just after rc1: let me know if you plan to take them or if I need to
rebase them for next cycle.

Best regards,
   Nicolas


  MAINTAINERS | 15 ---
  1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 65c4b59b582f..b48e217d41fb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2373,13 +2373,6 @@ F:   
Documentation/devicetree/bindings/input/atmel,maxtouch.txt
  F:drivers/input/touchscreen/atmel_mxt_ts.c
  F:include/linux/platform_data/atmel_mxt_ts.h
  
-ATMEL NAND DRIVER

-M: Wenyou Yang 
-M: Josh Wu 
-L: linux-...@lists.infradead.org
-S: Supported
-F: drivers/mtd/nand/atmel/*
-
  ATMEL SAMA5D2 ADC DRIVER
  M:Ludovic Desroches 
  L:linux-...@vger.kernel.org
@@ -9110,6 +9103,14 @@ F:   drivers/media/platform/atmel/atmel-isi.c
  F:include/media/atmel-isi.h
  F:Documentation/devicetree/bindings/media/atmel-isi.txt
  
+MICROCHIP / ATMEL NAND DRIVER

+M: Wenyou Yang 
+M: Josh Wu 
+L: linux-...@lists.infradead.org
+S: Supported
+F: drivers/mtd/nand/atmel/*
+F: Documentation/devicetree/bindings/mtd/atmel-nand.txt
+
  MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
  M:Woojung Huh 
  M:Microchip Linux Driver Support 


Best Regards,
Wenyou Yang

Re: [PATCH 1/2] MAINTAINERS: linux-media: update Microchip ISI and ISC entries

[Yang, Wenyou]

On 2018/1/9 21:46, Nicolas Ferre wrote:

These two image capture interface drivers are now handled
by Wenyou Yang.
I benefit from this change to update the two entries by correcting the
binding documentation link for ISC and moving the ISI to the new
MICROCHIP / ATMEL location.

Signed-off-by: Nicolas Ferre 

Acked-by: Wenyou Yang 

---
Hi,

Patch against next-20180109.
Note that I didn't find it useful to have several patches for these changes.
Tell me if you feel differently.

I would like to have the Ack from Ludovic and Wenyou obviously. I don't know if
Songjun can answer as he's not with Microchip anymore.

Best regards,
   Nicolas

  MAINTAINERS | 19 ++-
  1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a7d10a2bb980..65c4b59b582f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2353,13 +2353,6 @@ L:   linux-...@vger.kernel.org
  S:Supported
  F:drivers/i2c/busses/i2c-at91.c
  
-ATMEL ISI DRIVER

-M: Ludovic Desroches 
-L: linux-me...@vger.kernel.org
-S: Supported
-F: drivers/media/platform/atmel/atmel-isi.c
-F: include/media/atmel-isi.h
-
  ATMEL LCDFB DRIVER
  M:Nicolas Ferre 
  L:linux-fb...@vger.kernel.org
@@ -9102,12 +9095,20 @@ S:  Maintained
  F:drivers/crypto/atmel-ecc.*
  
  MICROCHIP / ATMEL ISC DRIVER

-M: Songjun Wu 
+M: Wenyou Yang 
  L:linux-me...@vger.kernel.org
  S:Supported
  F:drivers/media/platform/atmel/atmel-isc.c
  F:drivers/media/platform/atmel/atmel-isc-regs.h
-F: devicetree/bindings/media/atmel-isc.txt
+F: Documentation/devicetree/bindings/media/atmel-isc.txt
+
+MICROCHIP / ATMEL ISI DRIVER
+M: Wenyou Yang 
+L: linux-me...@vger.kernel.org
+S: Supported
+F: drivers/media/platform/atmel/atmel-isi.c
+F: include/media/atmel-isi.h
+F: Documentation/devicetree/bindings/media/atmel-isi.txt
  
  MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER

  M:Woojung Huh 

Best Regards,
Wenyou Yang

Re: [PATCH] media: i2c: ov7740: add media-controller dependency

[Yang, Wenyou]

Hello Arnd,


On 2018/1/8 20:52, Arnd Bergmann wrote:

Without CONFIG_MEDIA_CONTROLLER, the new driver fails to build:

drivers/perf/arm_dsu_pmu.c: In function 'dsu_pmu_probe_pmu':
drivers/perf/arm_dsu_pmu.c:661:2: error: implicit declaration of function 
'bitmap_from_u32array'; did you mean 'bitmap_from_arr32'? 
[-Werror=implicit-function-declaration]

This adds a dependency similar to what we have for other drivers
like this.

Fixes: 39c5c4471b8d ("media: i2c: Add the ov7740 image sensor driver")
Signed-off-by: Arnd Bergmann 
---

Indeed.
Thank you for your fix.

Acked-by: Wenyou Yang 


  drivers/media/i2c/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 9f18cd296841..03cf3a1a1e06 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -667,7 +667,7 @@ config VIDEO_OV7670
  
  config VIDEO_OV7740

tristate "OmniVision OV7740 sensor support"
-   depends on I2C && VIDEO_V4L2
+   depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
depends on MEDIA_CAMERA_SUPPORT
---help---
  This is a Video4Linux2 sensor-level driver for the OmniVision


Best Regards,
Wenyou Yang

Re: [PATCH] mtd/nand/atmel: Delete an error message for a failed memory allocation in two functions

[Yang, Wenyou]

On 2018/1/6 4:55, SF Markus Elfring wrote:

From: Markus Elfring 
Date: Fri, 5 Jan 2018 21:45:04 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---


Acked-by: Wenyou Yang 

  drivers/mtd/nand/atmel/nand-controller.c | 8 ++--
  1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/nand/atmel/nand-controller.c 
b/drivers/mtd/nand/atmel/nand-controller.c
index 90a71a56bc23..a41b999229c9 100644
--- a/drivers/mtd/nand/atmel/nand-controller.c
+++ b/drivers/mtd/nand/atmel/nand-controller.c
@@ -1612,10 +1612,8 @@ static int atmel_nand_register(struct atmel_nand *nand)
mtd->name = devm_kasprintf(nc->dev, GFP_KERNEL,
   "%s:nand.%d", dev_name(nc->dev),
   nand->cs[0].id);
-   if (!mtd->name) {
-   dev_err(nc->dev, "Failed to allocate mtd->name\n");
+   if (!mtd->name)
return -ENOMEM;
-   }
}
  
  	ret = nand_scan_tail(mtd);

@@ -1654,10 +1652,8 @@ static struct atmel_nand *atmel_nand_create(struct 
atmel_nand_controller *nc,
nand = devm_kzalloc(nc->dev,
sizeof(*nand) + (numcs * sizeof(*nand->cs)),
GFP_KERNEL);
-   if (!nand) {
-   dev_err(nc->dev, "Failed to allocate NAND object\n");
+   if (!nand)
return ERR_PTR(-ENOMEM);
-   }
  
  	nand->numcs = numcs;
  


Best Regards,
Wenyou Yang

Re: [PATCH v6 3/6] can: m_can: Add PM Runtime

[Yang, Wenyou]

On 2018/1/4 23:17, Faiz Abbas wrote:

Hi,

On Wednesday 03 January 2018 08:47 PM, Marc Kleine-Budde wrote:

On 01/03/2018 04:06 PM, Faiz Abbas wrote:

Hi,

On Wednesday 03 January 2018 07:55 PM, Marc Kleine-Budde wrote:

On 01/03/2018 01:39 PM, Faiz Abbas wrote:

On Tuesday 02 January 2018 09:37 PM, Marc Kleine-Budde wrote:

On 12/22/2017 02:31 PM, Faiz Abbas wrote:

From: Franklin S Cooper Jr 

Add support for PM Runtime which is the new way to handle managing clocks.
However, to avoid breaking SoCs not using PM_RUNTIME leave the old clk
management approach in place.

There is no PM_RUNTIME anymore since 464ed18ebdb6 ("PM: Eliminate
CONFIG_PM_RUNTIME")

Ok. Will change the commit message.


Have a look at the discussion: https://patchwork.kernel.org/patch/9436507/ :


Well, I admit it would be nicer if drivers didn't have to worry about
whether or not CONFIG_PM was enabled.  A slightly cleaner approach
from the one outlined above would have the probe routine do this:

my_power_up(dev);
pm_runtime_set_active(dev);
pm_runtime_get_noresume(dev);
pm_runtime_enable(dev);

This discussion seems to be about cases in which CONFIG_PM is not
enabled. CONFIG_PM is always selected in the case of omap devices.

Yes, but in the commit message you state that you need to support
systems that don't have PM_RUNTIME enabled. The only mainline SoCs I see
is "arch/arm/boot/dts/sama5d2.dtsi" so far. Please check if they select
CONFIG_PM, then we can make the driver much simpler.

Actually the old clock management (for hclk which is the interface
clock) is still required as mentioned in the cover letter. Will change
the rather misleading description.

Ok. So you can use the code as discussed on
https://patchwork.kernel.org/patch/9436507/ ?

Looking at the kernel configuration, it seems like SAMA5D2 platform
selects CONFIG_PM (Wenyou, please confirm).

Confirmed.  The CONFIG_PM is selected.


So, it seems like the only
users of this driver always have CONFIG_PM enabled.

So I guess the best way is to maintain the current code for pm_runtime_*
and move the clock enable/disable to pm_runtime callbacks.

Something like this:

m_can_runtime_resume()
{
clk_prepare_enable(cclk);
clk_prepare_enable(hclk);
}

m_can_runtime_suspend()
{
clk_disable_unprepare(cclk);
clk_disable_unprepare(hclk);
}

SET_RUNTIME_PM_OPS(m_can_runtime_suspend, m_can_runtime_resume, NULL)

static void m_can_start(struct net_device *dev)
{
pm_runtime_get_sync(dev)
...
}

static void m_can_stop(struct net_device *dev)
{
...
pm_runtime_put_sync(dev)
}

Does that sound okay? If yes, I will go work on the implementation.

Thanks,
Faiz

Best Regards,
Wenyou Yang

Re: [PATCH v6 0/6] Add M_CAN Support for Dra76 platform

[Yang, Wenyou]

On 2017/12/22 21:31, Faiz Abbas wrote:

This patch series adds support for M_CAN on the TI Dra76
platform. Device tree patches will be sent separately.
A bunch of patches were sent before by
Franklin Cooper . I have clubbed the
series together and rebased to the latest kernel.

Tested this series on SAMA5D2 Xplained board.

Tested-by: Wenyou Yang 



v6 changes:
Dropped the patches to make hclk optional. Drivers
which enable hclk as the interface clock using
pm_runtime calls must still provide a hclk in the
clocks property.

Support higher speed CAN-FD bitrate:
The community decided that data sampling point be used
for the secondary sampling point here
https://patchwork.kernel.org/patch/9909845/

Franklin S Cooper Jr (6):
   can: dev: Add support for limiting configured bitrate
   can: m_can: Add call to of_can_transceiver
   can: m_can: Add PM Runtime
   can: m_can: Support higher speed CAN-FD bitrates
   dt-bindings: can: m_can: Document new can transceiver binding
   dt-bindings: can: can-transceiver: Document new binding

  .../bindings/net/can/can-transceiver.txt   | 24 +++
  .../devicetree/bindings/net/can/m_can.txt  |  9 +++
  drivers/net/can/dev.c  | 39 +++
  drivers/net/can/m_can/m_can.c  | 81 --
  include/linux/can/dev.h|  8 +++
  5 files changed, 156 insertions(+), 5 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/net/can/can-transceiver.txt



Best Regards,
Wenyou Yang

Re: [PATCH v8 2/2] media: i2c: Add the ov7740 image sensor driver

[Yang, Wenyou]

Hi Philippe,


On 2017/12/8 21:14, Philippe Ombredanne wrote:

Wenyou,

On Fri, Dec 8, 2017 at 2:55 AM, Wenyou Yang  wrote:

The ov7740 (color) image sensor is a high performance VGA CMOS
image snesor, which supports for output formats: RAW RGB and YUV
and image sizes: VGA, and QVGA, CIF and any size smaller.

Signed-off-by: Songjun Wu 
Signed-off-by: Wenyou Yang 

[]

--- /dev/null
+++ b/drivers/media/i2c/ov7740.c
@@ -0,0 +1,1226 @@
+/*
+ * Copyright (c) 2017 Microchip Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */

Have you considered using the new SPDX ids instead of this fine legalese?
e.g.:

// SPDX-License-Identifier: GPL-2.0
// Copyright (c) 2017 Microchip Corporation.

Short and neat! Check also Thomas doc patches and Linus comments on
why he prefers the C++ comment style for these.

Thank you for your suggestion and information.


Best Regards,
Wenyou Yang

Re: [PATCH v7 2/2] media: i2c: Add the ov7740 image sensor driver

[Yang, Wenyou]

Hi Sakari,


On 2017/12/7 21:16, Sakari Ailus wrote:

Hi Wenyou,

On Wed, Dec 06, 2017 at 10:23:43AM +0800, Wenyou Yang wrote:

The ov7740 (color) image sensor is a high performance VGA CMOS
image snesor, which supports for output formats: RAW RGB and YUV
and image sizes: VGA, and QVGA, CIF and any size smaller.

Signed-off-by: Songjun Wu 
Signed-off-by: Wenyou Yang 
---

Changes in v7:
  - Fix the wrong handle of default register configuration.
  - Add the missed assignment of ov7740->frmsize.

Changes in v6:
  - Remove unnecessary #include .
  - Remove unnecessary comments and extra newline.
  - Add const for some structures.
  - Add the check of the return value from regmap_write().
  - Simplify the calling of __v4l2_ctrl_handler_setup().
  - Add the default format initialization function.
  - Integrate the set_power() and enable/disable the clock into
one function.

Changes in v5:
  - Squash the driver and MAINTAINERS entry patches to one.
  - Precede the driver patch with the bindings patch.

Changes in v4:
  - Assign 'val' a initial value to avoid warning: 'val' may be
used uninitialized.
  - Rename REG_REG15 to avoid warning: "REG_REG15" redefined.

Changes in v3:
  - Put the MAINTAINERS change to a separate patch.

Changes in v2:
  - Split off the bindings into a separate patch.
  - Add a new entry to the MAINTAINERS file.

  MAINTAINERS|8 +
  drivers/media/i2c/Kconfig  |8 +
  drivers/media/i2c/Makefile |1 +
  drivers/media/i2c/ov7740.c | 1234 
  4 files changed, 1251 insertions(+)
  create mode 100644 drivers/media/i2c/ov7740.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7a52a66aa991..1de965009b13 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10053,6 +10053,14 @@ S: Maintained
  F:drivers/media/i2c/ov7670.c
  F:Documentation/devicetree/bindings/media/i2c/ov7670.txt
  
+OMNIVISION OV7740 SENSOR DRIVER

+M: Wenyou Yang 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/ov7740.c
+F: Documentation/devicetree/bindings/media/i2c/ov7740.txt
+
  ONENAND FLASH DRIVER
  M:Kyungmin Park 
  L:linux-...@lists.infradead.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cb5d7ff82915..00b1c4c031d4 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -665,6 +665,14 @@ config VIDEO_OV7670
  OV7670 VGA camera.  It currently only works with the M88ALP01
  controller.
  
+config VIDEO_OV7740

+   tristate "OmniVision OV7740 sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV7740 VGA camera sensor.
+
  config VIDEO_OV9650
tristate "OmniVision OV9650/OV9652 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9efce966..9b19ec7fcaf4 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
  obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
  obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
  obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
new file mode 100644
index ..26b56a627377
--- /dev/null
+++ b/drivers/media/i2c/ov7740.c
@@ -0,0 +1,1234 @@
+/*
+ * Copyright (c) 2017 Microchip Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_OUTSIZE_LSB 0x34
+
+/* OV7740 register tables */
+#define REG_GAIN   0x00/* Gain lower 8 bits (rest in vref) */
+#define REG_BGAIN  0x01/* blue gain */
+#define REG_RGAIN  0x02/* red gain */
+#define REG_GGAIN  0x03/* green gain */
+#define REG_REG04  0x04/* analog setting, dont change*/
+#define REG_BAVG   0x05/* b channel average */
+#define REG_GAVG   0x06/* g channel average */
+#define REG_RAVG   0x07/* r channel average */
+
+#define REG_REG0C  0x0C/* filp enable */
+#define REG0C_IMG_FLIP 0x80
+#define REG0C_IMG_MIRROR   0x40
+
+#define REG_REG0E  0x0E/* blc line */

Re: [PATCH v6 2/2] media: i2c: Add the ov7740 image sensor driver

[Yang, Wenyou]

Hi Sakari,


On 2017/12/5 18:45, Sakari Ailus wrote:

Hi Wenyou,

On Mon, Dec 04, 2017 at 02:58:58PM +0800, Wenyou Yang wrote:

The ov7740 (color) image sensor is a high performance VGA CMOS
image snesor, which supports for output formats: RAW RGB and YUV
and image sizes: VGA, and QVGA, CIF and any size smaller.

Signed-off-by: Songjun Wu 
Signed-off-by: Wenyou Yang 
---

Changes in v6:
  - Remove unnecessary #include .
  - Remove unnecessary comments and extra newline.
  - Add const for some structures.
  - Add the check of the return value from regmap_write().
  - Simplify the calling of __v4l2_ctrl_handler_setup().
  - Add the default format initialization function.
  - Integrate the set_power() and enable/disable the clock into
one function.

Changes in v5:
  - Squash the driver and MAINTAINERS entry patches to one.
  - Precede the driver patch with the bindings patch.

Changes in v4:
  - Assign 'val' a initial value to avoid warning: 'val' may be
used uninitialized.
  - Rename REG_REG15 to avoid warning: "REG_REG15" redefined.

Changes in v3:
  - Put the MAINTAINERS change to a separate patch.

Changes in v2:
  - Split off the bindings into a separate patch.
  - Add a new entry to the MAINTAINERS file.

  MAINTAINERS|8 +
  drivers/media/i2c/Kconfig  |8 +
  drivers/media/i2c/Makefile |1 +
  drivers/media/i2c/ov7740.c | 1226 
  4 files changed, 1243 insertions(+)
  create mode 100644 drivers/media/i2c/ov7740.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7a52a66aa991..1de965009b13 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10053,6 +10053,14 @@ S: Maintained
  F:drivers/media/i2c/ov7670.c
  F:Documentation/devicetree/bindings/media/i2c/ov7670.txt
  
+OMNIVISION OV7740 SENSOR DRIVER

+M: Wenyou Yang 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/ov7740.c
+F: Documentation/devicetree/bindings/media/i2c/ov7740.txt
+
  ONENAND FLASH DRIVER
  M:Kyungmin Park 
  L:linux-...@lists.infradead.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cb5d7ff82915..00b1c4c031d4 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -665,6 +665,14 @@ config VIDEO_OV7670
  OV7670 VGA camera.  It currently only works with the M88ALP01
  controller.
  
+config VIDEO_OV7740

+   tristate "OmniVision OV7740 sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV7740 VGA camera sensor.
+
  config VIDEO_OV9650
tristate "OmniVision OV9650/OV9652 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9efce966..9b19ec7fcaf4 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
  obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
  obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
  obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
new file mode 100644
index ..42c25277d005
--- /dev/null
+++ b/drivers/media/i2c/ov7740.c
@@ -0,0 +1,1226 @@
+/*
+ * Copyright (c) 2017 Microchip Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_OUTSIZE_LSB 0x34
+
+/* OV7740 register tables */
+#define REG_GAIN   0x00/* Gain lower 8 bits (rest in vref) */
+#define REG_BGAIN  0x01/* blue gain */
+#define REG_RGAIN  0x02/* red gain */
+#define REG_GGAIN  0x03/* green gain */
+#define REG_REG04  0x04/* analog setting, dont change*/
+#define REG_BAVG   0x05/* b channel average */
+#define REG_GAVG   0x06/* g channel average */
+#define REG_RAVG   0x07/* r channel average */
+
+#define REG_REG0C  0x0C/* filp enable */
+#define REG0C_IMG_FLIP 0x80
+#define REG0C_IMG_MIRROR   0x40
+
+#define REG_REG0E  0x0E/* blc line */
+#define REG_HAEC   0x0F/* auto exposure cntrl */
+#define REG_AEC0x10/* auto exposure cntrl */
+

Re: [PATCH v5 2/2] media: i2c: Add the ov7740 image sensor driver

[Yang, Wenyou]

Hi Sakari,

Sorry for late answer.

Thank you for your review.

On 2017/11/28 20:06, Sakari Ailus wrote:

Hi Wenyou,

Thanks for the patch. Some comments below.

On Tue, Nov 28, 2017 at 01:22:59PM +0800, Wenyou Yang wrote:

The ov7740 (color) image sensor is a high performance VGA CMOS
image snesor, which supports for output formats: RAW RGB and YUV
and image sizes: VGA, and QVGA, CIF and any size smaller.

Signed-off-by: Songjun Wu 
Signed-off-by: Wenyou Yang 
---

Changes in v5:
  - Squash the driver and MAINTAINERS entry patches to one.
  - Precede the driver patch with the bindings patch.

Changes in v4:
  - Assign 'val' a initial value to avoid warning: 'val' may be
used uninitialized.
  - Rename REG_REG15 to avoid warning: "REG_REG15" redefined.

Changes in v3:
  - Put the MAINTAINERS change to a separate patch.

Changes in v2:
  - Split off the bindings into a separate patch.
  - Add a new entry to the MAINTAINERS file.

  MAINTAINERS|8 +
  drivers/media/i2c/Kconfig  |8 +
  drivers/media/i2c/Makefile |1 +
  drivers/media/i2c/ov7740.c | 1220 
  4 files changed, 1237 insertions(+)
  create mode 100644 drivers/media/i2c/ov7740.c

diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52fd76..19086a073ae9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10053,6 +10053,14 @@ S: Maintained
  F:drivers/media/i2c/ov7670.c
  F:Documentation/devicetree/bindings/media/i2c/ov7670.txt
  
+OMNIVISION OV7740 SENSOR DRIVER

+M: Wenyou Yang 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/ov7740.c
+F: Documentation/devicetree/bindings/media/i2c/ov7740.txt
+
  ONENAND FLASH DRIVER
  M:Kyungmin Park 
  L:linux-...@lists.infradead.org
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 3c6d6428f525..ac484bb82fae 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -665,6 +665,14 @@ config VIDEO_OV7670
  OV7670 VGA camera.  It currently only works with the M88ALP01
  controller.
  
+config VIDEO_OV7740

+   tristate "OmniVision OV7740 sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV7740 VGA camera sensor.
+
  config VIDEO_OV9650
tristate "OmniVision OV9650/OV9652 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 548a9efce966..9b19ec7fcaf4 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
  obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
  obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
  obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
new file mode 100644
index ..b2ec015bf3f6
--- /dev/null
+++ b/drivers/media/i2c/ov7740.c
@@ -0,0 +1,1220 @@
+/*
+ * Copyright (c) 2017 Microchip Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 

Do you need init.h?

No, will remove it.



+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REG_OUTSIZE_LSB 0x34
+
+/* OV7740 register tables */
+#define REG_GAIN   0x00/* Gain lower 8 bits (rest in vref) */
+#define REG_BGAIN  0x01/* blue gain */
+#define REG_RGAIN  0x02/* red gain */
+#define REG_GGAIN  0x03/* green gain */
+#define REG_REG04  0x04/* analog setting, dont change*/
+#define REG_BAVG   0x05/* b channel average */
+#define REG_GAVG   0x06/* g channel average */
+#define REG_RAVG   0x07/* r channel average */
+
+#define REG_REG0C  0x0C/* filp enable */
+#define REG0C_IMG_FLIP 0x80
+#define REG0C_IMG_MIRROR   0x40
+
+#define REG_REG0E  0x0E/* blc line */
+#define REG_HAEC   0x0F/* auto exposure cntrl */
+#define REG_AEC0x10/* auto exposure cntrl */
+
+#define REG_CLK0x11/* Clock control */
+#define REG_REG55  0x55/* Clock PLL DIV/PreDiv */
+
+#define REG_REG12  0x12
+
+#define REG_REG13  0x13/* auto/manual AGC, AEC, Write Balance*/
+#define

Re: [PATCH v2 2/2] media: ov7740: Document device tree bindings

[Yang, Wenyou]

Hi Sakari,

Thank you very much for your review and advice.

I will send a new version to fix it.

On 2017/10/27 18:59, Sakari Ailus wrote:

Hi Wenyou,

On Fri, Oct 27, 2017 at 03:42:20PM +0800, Wenyou Yang wrote:

Add the device tree binding documentation for ov7740 driver and
add a new entry of ov7740 to the MAINTAINERS file.

Signed-off-by: Wenyou Yang 
---

Changes in v2:
  - Split off the bindings into a separate patch.
  - Add a new entry to the MAINTAINERS file.

  .../devicetree/bindings/media/i2c/ov7740.txt   | 43 ++
  MAINTAINERS|  8 
  2 files changed, 51 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7740.txt

diff --git a/Documentation/devicetree/bindings/media/i2c/ov7740.txt 
b/Documentation/devicetree/bindings/media/i2c/ov7740.txt
new file mode 100644
index ..b306e5aa97bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov7740.txt
@@ -0,0 +1,43 @@
+* Omnivision OV7740 CMOS image sensor
+
+The Omnivision OV7740 image sensor supports multiple output image
+size, such as VGA, and QVGA, CIF and any size smaller. It also
+supports the RAW RGB and YUV output formats.
+
+Required Properties:
+- compatible: should be "ovti,ov7740"
+- clocks: reference to the xvclk input clock.
+- clock-names: should be "xvclk".
+
+Optional Properties:
+- reset-gpios: reference to the GPIO connected to the reset_b pin,
+  if any. Active low with pull-ip resistor.
+- powerdown-gpios: reference to the GPIO connected to the pwdn pin,
+  if any. Active high with pull-down resistor.
+
+The device node must contain one 'port' child node for its digital
+output video port, in accordance with the video interface bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.

Could you add there's a single endpoint node as well, and explicitly
document the relevant properties? E.g. as in
Documentation/devicetree/bindings/media/i2c/nokia,smia.txt .


+
+Example:
+
+   i2c1: i2c@fc028000 {
+   ov7740: camera@21 {
+   compatible = "ovti,ov7740";
+   reg = <0x21>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_sensor_power 
&pinctrl_sensor_reset>;
+   clocks = <&isc>;
+   clock-names = "xvclk";
+   assigned-clocks = <&isc>;
+   assigned-clock-rates = <2400>;
+   reset-gpios = <&pioA 43 GPIO_ACTIVE_LOW>;
+   powerdown-gpios = <&pioA 44 GPIO_ACTIVE_HIGH>;
+
+   port {
+   ov7740_0: endpoint {
+   remote-endpoint = <&isc_0>;
+   };
+   };
+   };
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 90230fe020f3..f0f3f121d1d8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9965,6 +9965,14 @@ S:   Maintained
  F:drivers/media/i2c/ov7670.c
  F:Documentation/devicetree/bindings/media/i2c/ov7670.txt
  
+OMNIVISION OV7740 SENSOR DRIVER

+M: Wenyou Yang 
+L: linux-me...@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: drivers/media/i2c/ov7740.c
+F: Documentation/devicetree/bindings/media/i2c/ov7740.txt
+
  ONENAND FLASH DRIVER
  M:Kyungmin Park 
  L:linux-...@lists.infradead.org

Please put the MAINTAINERS change to the driver patch after the DT binding
patch.


Best Regards,
Wenyou Yang

Re: [PATCH v5 0/5] media: atmel-isc: Rework the format list and clock provider

[Yang, Wenyou]

Hi Hans,


On 2017/10/27 20:41, Hans Verkuil wrote:

Hi Wenyou,

Unfortunately the v4 patch series was just merged instead of v5. Can you make a 
new
patch applying just the v4 -> v5 changes?

Thank you for your merging.

Of course, I will send a patch to fix it.



Thanks!

Hans

On 10/27/2017 05:21 AM, Wenyou Yang wrote:

To improve the readability of code, rework the format list table,
split the format array into two. Meanwhile, fix the issue of the
clock provider operation and the pm runtime support.

Changes in v5:
  - Fix the clock ID which enters the runtime suspend should be
ISC_ISPCK, instead of ISC_MCK for clk_prepare/clk_unprepare().
  - Fix the clock ID to ISC_ISPCK, instead of ISC_MCK for
isc_clk_is_enabled().

Changes in v4:
  - Call pm_runtime_get_sync() and pm_runtime_put_sync() in ->prepare
and ->unprepare callback.
  - Move pm_runtime_enable() call from the complete callback to the
end of probe.
  - Call pm_runtime_get_sync() and pm_runtime_put_sync() in
->is_enabled() callbacks.
  - Call clk_disable_unprepare() in ->remove callback.

Changes in v3:
  - Fix the wrong used spinlock.
  - s/_/- on the subject.
  - Add a new flag for Raw Bayer format to remove MAX_RAW_FMT_INDEX define.
  - Add the comments for define of the format flag.
  - Rebase media_tree/master.

Changes in v2:
  - Add the new patch to remove the unnecessary member from
isc_subdev_entity struct.
  - Rebase on the patch set,
 [PATCH 0/6] [media] Atmel: Adjustments for seven function 
implementations
 https://www.mail-archive.com/linux-media@vger.kernel.org/msg118342.html

Wenyou Yang (5):
   media: atmel-isc: Add spin lock for clock enable ops
   media: atmel-isc: Add prepare and unprepare ops
   media: atmel-isc: Enable the clocks during probe
   media: atmel-isc: Remove unnecessary member
   media: atmel-isc: Rework the format list

  drivers/media/platform/atmel/atmel-isc-regs.h |   1 +
  drivers/media/platform/atmel/atmel-isc.c  | 629 --
  2 files changed, 498 insertions(+), 132 deletions(-)


Best Regards,
Wenyou Yang

Re: [PATCH] media: i2c: Add the ov7740 image sensor driver

[Yang, Wenyou]

On 2017/10/27 15:10, Hans Verkuil wrote:

On 10/27/2017 05:30 AM, Wenyou Yang wrote:

From: Songjun Wu 

The ov7740 (color) image sensor is a high performance VGA CMOS
image snesor, which supports for output formats: RAW RGB and YUV
and image sizes: VGA, and QVGA, CIF and any size smaller.

Two short remarks: please split off the bindings into a separate
patch. And add a new entry to the MAINTAINERS file.

Thanks a lot.
Will be done in the next version.



Regards,

Hans


Signed-off-by: Songjun Wu 
Signed-off-by: Wenyou Yang 
---

  .../devicetree/bindings/media/i2c/ov7740.txt   |   43 +
  drivers/media/i2c/Kconfig  |8 +
  drivers/media/i2c/Makefile |1 +
  drivers/media/i2c/ov7740.c | 1220 
  4 files changed, 1272 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7740.txt
  create mode 100644 drivers/media/i2c/ov7740.c

diff --git a/Documentation/devicetree/bindings/media/i2c/ov7740.txt 
b/Documentation/devicetree/bindings/media/i2c/ov7740.txt
new file mode 100644
index ..b306e5aa97bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov7740.txt
@@ -0,0 +1,43 @@
+* Omnivision OV7740 CMOS image sensor
+
+The Omnivision OV7740 image sensor supports multiple output image
+size, such as VGA, and QVGA, CIF and any size smaller. It also
+supports the RAW RGB and YUV output formats.
+
+Required Properties:
+- compatible: should be "ovti,ov7740"
+- clocks: reference to the xvclk input clock.
+- clock-names: should be "xvclk".
+
+Optional Properties:
+- reset-gpios: reference to the GPIO connected to the reset_b pin,
+  if any. Active low with pull-ip resistor.
+- powerdown-gpios: reference to the GPIO connected to the pwdn pin,
+  if any. Active high with pull-down resistor.
+
+The device node must contain one 'port' child node for its digital
+output video port, in accordance with the video interface bindings
+defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+   i2c1: i2c@fc028000 {
+   ov7740: camera@21 {
+   compatible = "ovti,ov7740";
+   reg = <0x21>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_sensor_power 
&pinctrl_sensor_reset>;
+   clocks = <&isc>;
+   clock-names = "xvclk";
+   assigned-clocks = <&isc>;
+   assigned-clock-rates = <2400>;
+   reset-gpios = <&pioA 43 GPIO_ACTIVE_LOW>;
+   powerdown-gpios = <&pioA 44 GPIO_ACTIVE_HIGH>;
+
+   port {
+   ov7740_0: endpoint {
+   remote-endpoint = <&isc_0>;
+   };
+   };
+   };
+   };
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 47113774a297..402ad0e4024c 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -657,6 +657,14 @@ config VIDEO_OV7670
  OV7670 VGA camera.  It currently only works with the M88ALP01
  controller.
  
+config VIDEO_OV7740

+   tristate "OmniVision OV7740 sensor support"
+   depends on I2C && VIDEO_V4L2
+   depends on MEDIA_CAMERA_SUPPORT
+   ---help---
+ This is a Video4Linux2 sensor-level driver for the OmniVision
+ OV7740 VGA camera sensor.
+
  config VIDEO_OV9650
tristate "OmniVision OV9650/OV9652 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index c843c181dfb9..f94cb2a8ed91 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
  obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
  obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
  obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
+obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
  obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
  obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
  obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
new file mode 100644
index ..d68add05b46e
--- /dev/null
+++ b/drivers/media/i2c/ov7740.c
@@ -0,0 +1,1220 @@
+/*
+ * Copyright (c) 2017 Microchip Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include

Re: [PATCH 09/15] ARM: dts: at91: sama5d2_xplained: Add charger node of pmic.

[Yang, Wenyou]

Hi Claudiu,


On 2017/10/10 0:09, Claudiu Beznea wrote:

Add charger device node as a sub-device node of act8945a mfd, move
the charger's properties to this node, and use the "interrupts"
property to replace "active-semi,irq_gpios" to denote the act8945a
charger's irq.

Signed-off-by: Wenyou Yang 
[claudiu.bez...@microchip.com: replace numbers with pin macros]
Signed-off-by: Claudiu Beznea 

This patch has already applied on at91-dt branch.
https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git/commit/?h=at91-dt&id=4b6ad41f267b8ddabf5dd1b02a318bc74f0b95e9


---
  arch/arm/boot/dts/at91-sama5d2_xplained.dts | 23 +++
  1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts 
b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index c7e9ccf2bc87..848ca1b025be 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -160,14 +160,6 @@
compatible = "active-semi,act8945a";
reg = <0x5b>;
active-semi,vsel-high;
-   active-semi,chglev-gpios = <&pioA PIN_PA12 
GPIO_ACTIVE_HIGH>;
-   active-semi,lbo-gpios = <&pioA PIN_PC8 
GPIO_ACTIVE_LOW>;
-   active-semi,irq_gpios = <&pioA PIN_PB13 
GPIO_ACTIVE_LOW>;
-   active-semi,input-voltage-threshold-microvolt 
= <6600>;
-   active-semi,precondition-timeout = <40>;
-   active-semi,total-timeout = <3>;
-   pinctrl-names = "default";
-   pinctrl-0 = <&pinctrl_charger_chglev 
&pinctrl_charger_lbo &pinctrl_charger_irq>;
status = "okay";
  
  	regulators {

@@ -220,6 +212,21 @@
regulator-always-on;
};
};
+
+   charger {
+   compatible = 
"active-semi,act8945a-charger";
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_charger_chglev 
&pinctrl_charger_lbo &pinctrl_charger_irq>;
+   interrupt-parent = <&pioA>;
+   interrupts = ;
+
+   active-semi,chglev-gpios = <&pioA 
PIN_PA12 GPIO_ACTIVE_HIGH>;
+   active-semi,lbo-gpios = <&pioA 
PIN_PC8 GPIO_ACTIVE_LOW>;
+   
active-semi,input-voltage-threshold-microvolt = <6600>;
+   active-semi,precondition-timeout = 
<40>;
+   active-semi,total-timeout = <3>;
+   status = "okay";
+   };
};
};
  


Best Regards,
Wenyou Yang

Re: [PATCH v3 3/5] media: atmel-isc: Enable the clocks during probe

[Yang, Wenyou]

Hi Sakari,

On 2017/10/9 15:58, Sakari Ailus wrote:

Hi
Wenyou,

On Mon, Oct 09, 2017 at 01:49:44PM +0800, Yang, Wenyou wrote:

Hi Sakari,

Sorry for late answer, because I was in vacation last week.

On 2017/9/29 5:25, Sakari Ailus wrote:

Hi Wenyou,

On Thu, Sep 28, 2017 at 04:18:26PM +0800, Wenyou Yang wrote:

To meet the relationship, enable the HCLOCK and ispck during the
device probe, "isc_pck frequency is less than or equal to isc_ispck,
and isc_ispck is greater than or equal to HCLOCK."
Meanwhile, call the pm_runtime_enable() in the right place.

Signed-off-by: Wenyou Yang 
---

Changes in v3: None
Changes in v2: None

   drivers/media/platform/atmel/atmel-isc.c | 31 +--
   1 file changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index 0b15dc1a3a0b..f092c95587c1 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -1594,6 +1594,7 @@ static int isc_async_complete(struct v4l2_async_notifier 
*notifier)
struct isc_subdev_entity *sd_entity;
struct video_device *vdev = &isc->video_dev;
struct vb2_queue *q = &isc->vb2_vidq;
+   struct device *dev = isc->dev;
int ret;
ret = v4l2_device_register_subdev_nodes(&isc->v4l2_dev);
@@ -1677,6 +1678,10 @@ static int isc_async_complete(struct v4l2_async_notifier 
*notifier)
return ret;
}
+   pm_runtime_set_active(dev);
+   pm_runtime_enable(dev);
+   pm_request_idle(dev);

Remember that the driver's async complete function could never get called.

What would be the reason to move it here?

The ISC provides the clock for the sensor, namely, it is the clock provider
for the external sensor.
So it keeps active to make the sensor probe successfully.
Otherwise, the sensor, such as 0v7670 fails to probe due to the failure to
clk_enable().

You'll still need to balance the get and put calls.

complete callback is not necessarily called at all or could be called
multiple times. Instead, you should probably do pm_runtime_get_sync() when
the clock is enabled and put when it's disabled.

I will send v4 to update it.

Thank you for your advice.

Best Regards,
Wenyou Yang

Re: [PATCH v3 3/5] media: atmel-isc: Enable the clocks during probe

[Yang, Wenyou]

Hi Sakari,

Sorry for late answer, because I was in vacation last week.

On 2017/9/29 5:25, Sakari Ailus wrote:

Hi Wenyou,

On Thu, Sep 28, 2017 at 04:18:26PM +0800, Wenyou Yang wrote:

To meet the relationship, enable the HCLOCK and ispck during the
device probe, "isc_pck frequency is less than or equal to isc_ispck,
and isc_ispck is greater than or equal to HCLOCK."
Meanwhile, call the pm_runtime_enable() in the right place.

Signed-off-by: Wenyou Yang 
---

Changes in v3: None
Changes in v2: None

  drivers/media/platform/atmel/atmel-isc.c | 31 +--
  1 file changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index 0b15dc1a3a0b..f092c95587c1 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -1594,6 +1594,7 @@ static int isc_async_complete(struct v4l2_async_notifier 
*notifier)
struct isc_subdev_entity *sd_entity;
struct video_device *vdev = &isc->video_dev;
struct vb2_queue *q = &isc->vb2_vidq;
+   struct device *dev = isc->dev;
int ret;
  
  	ret = v4l2_device_register_subdev_nodes(&isc->v4l2_dev);

@@ -1677,6 +1678,10 @@ static int isc_async_complete(struct v4l2_async_notifier 
*notifier)
return ret;
}
  
+	pm_runtime_set_active(dev);

+   pm_runtime_enable(dev);
+   pm_request_idle(dev);

Remember that the driver's async complete function could never get called.

What would be the reason to move it here?
The ISC provides the clock for the sensor, namely, it is the clock 
provider for the external sensor.

So it keeps active to make the sensor probe successfully.
Otherwise, the sensor, such as 0v7670 fails to probe due to the failure 
to clk_enable().



+
return 0;
  }
  
@@ -1856,25 +1861,37 @@ static int atmel_isc_probe(struct platform_device *pdev)

return ret;
}
  
+	ret = clk_prepare_enable(isc->hclock);

+   if (ret) {
+   dev_err(dev, "failed to enable hclock: %d\n", ret);
+   return ret;
+   }
+
ret = isc_clk_init(isc);
if (ret) {
dev_err(dev, "failed to init isc clock: %d\n", ret);
-   goto clean_isc_clk;
+   goto unprepare_hclk;
}
  
  	isc->ispck = isc->isc_clks[ISC_ISPCK].clk;
  
+	ret = clk_prepare_enable(isc->ispck);

+   if (ret) {
+   dev_err(dev, "failed to enable ispck: %d\n", ret);
+   goto unprepare_hclk;
+   }
+
/* ispck should be greater or equal to hclock */
ret = clk_set_rate(isc->ispck, clk_get_rate(isc->hclock));
if (ret) {
dev_err(dev, "failed to set ispck rate: %d\n", ret);
-   goto clean_isc_clk;
+   goto unprepare_clk;
}
  
  	ret = v4l2_device_register(dev, &isc->v4l2_dev);

if (ret) {
dev_err(dev, "unable to register v4l2 device.\n");
-   goto clean_isc_clk;
+   goto unprepare_clk;
}
  
  	ret = isc_parse_dt(dev, isc);

@@ -1907,8 +1924,6 @@ static int atmel_isc_probe(struct platform_device *pdev)
break;
}
  
-	pm_runtime_enable(dev);

-
return 0;
  
  cleanup_subdev:

@@ -1917,7 +1932,11 @@ static int atmel_isc_probe(struct platform_device *pdev)
  unregister_v4l2_device:
v4l2_device_unregister(&isc->v4l2_dev);
  
-clean_isc_clk:

+unprepare_clk:
+   clk_disable_unprepare(isc->ispck);
+unprepare_hclk:
+   clk_disable_unprepare(isc->hclock);

I think you're missing clk_disable_unprepare() in the driver's remove
callback.

Will add in next version.



+
isc_clk_cleanup(isc);
  
  	return ret;


Best Regards,
Wenyou Yang

Re: [PATCH v2 1/5] media: atmel_isc: Add spin lock for clock enable ops

[Yang, Wenyou]

Hi Sakari,


On 2017/9/27 15:16, Sakari Ailus wrote:

Hi Wenyou,

On subject:

s/_/-/

On Mon, Sep 18, 2017 at 02:39:21PM +0800, Wenyou Yang wrote:

Add the spin lock for the clock enable and disable operations.

Signed-off-by: Wenyou Yang 
---

Changes in v2: None

  drivers/media/platform/atmel/atmel-isc.c | 14 +-
  1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index 2f8e345d297e..78114193af4c 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -65,6 +65,7 @@ struct isc_clk {
struct clk_hw   hw;
struct clk  *clk;
struct regmap   *regmap;
+   spinlock_t  *lock;

Can this work? I don't see lock being assigned anywhere. Did you mean

spinlock_t  lock;

?

Ooh. I made a mistake.

Thank you very much.



u8  id;
u8  parent_id;
u32 div;
@@ -312,26 +313,37 @@ static int isc_clk_enable(struct clk_hw *hw)
struct isc_clk *isc_clk = to_isc_clk(hw);
u32 id = isc_clk->id;
struct regmap *regmap = isc_clk->regmap;
+   unsigned long flags;
+   unsigned int status;
  
  	dev_dbg(isc_clk->dev, "ISC CLK: %s, div = %d, parent id = %d\n",

__func__, isc_clk->div, isc_clk->parent_id);
  
+	spin_lock_irqsave(isc_clk->lock, flags);

regmap_update_bits(regmap, ISC_CLKCFG,
   ISC_CLKCFG_DIV_MASK(id) | ISC_CLKCFG_SEL_MASK(id),
   (isc_clk->div << ISC_CLKCFG_DIV_SHIFT(id)) |
   (isc_clk->parent_id << ISC_CLKCFG_SEL_SHIFT(id)));
  
  	regmap_write(regmap, ISC_CLKEN, ISC_CLK(id));

+   spin_unlock_irqrestore(isc_clk->lock, flags);
  
-	return 0;

+   regmap_read(regmap, ISC_CLKSR, &status);
+   if (status & ISC_CLK(id))
+   return 0;
+   else
+   return -EINVAL;
  }
  
  static void isc_clk_disable(struct clk_hw *hw)

  {
struct isc_clk *isc_clk = to_isc_clk(hw);
u32 id = isc_clk->id;
+   unsigned long flags;
  
+	spin_lock_irqsave(isc_clk->lock, flags);

regmap_write(isc_clk->regmap, ISC_CLKDIS, ISC_CLK(id));
+   spin_unlock_irqrestore(isc_clk->lock, flags);
  }
  
  static int isc_clk_is_enabled(struct clk_hw *hw)

Best Regards,
Wenyou Yang

Re: [PATCH v2 5/5] media: atmel-isc: Rework the format list

[Yang, Wenyou]

On 2017/9/27 16:03, Hans Verkuil wrote:

On 09/27/2017 07:15 AM, Yang, Wenyou wrote:

Hi Hans,

Thank  you very much for your review.

On 2017/9/25 21:24, Hans Verkuil wrote:

Hi Wenyou,

On 18/09/17 08:39, Wenyou Yang wrote:

To improve the readability of code, split the format array into two,
one for the format description, other for the register configuration.
Meanwhile, add the flag member to indicate the format can be achieved
from the sensor or be produced by the controller, and rename members
related to the register configuration.

Also add more formats support: GREY, ARGB444, ARGB555 and ARGB32.

Signed-off-by: Wenyou Yang 

This looks better. Just a few comments, see below.


---

Changes in v2:
   - Add the new patch to remove the unnecessary member from
 isc_subdev_entity struct.
   - Rebase on the patch set,
  [PATCH 0/6] [media] Atmel: Adjustments for seven function 
implementations
  
https://www.mail-archive.com/linux-media@vger.kernel.org/msg118342.html

   drivers/media/platform/atmel/atmel-isc.c | 524 
---
   1 file changed, 405 insertions(+), 119 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index 2d876903da71..90bd0b28a975 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -89,34 +89,56 @@ struct isc_subdev_entity {
struct list_head list;
   };
   
+#define FMT_FLAG_FROM_SENSOR		BIT(0)

+#define FMT_FLAG_FROM_CONTROLLER   BIT(1)

Document the meaning of these flags.

Will add it in next version.

+
   /*
* struct isc_format - ISC media bus format information
* @fourcc:  Fourcc code for this format
* @mbus_code:   V4L2 media bus format code.
+ * flags:  Indicate format from sensor or converted by controller
* @bpp: Bits per pixel (when stored in memory)
- * @reg_bps:   reg value for bits per sample
*   (when transferred over a bus)
- * @pipeline:  pipeline switch
* @sd_support:  Subdev supports this format
* @isc_support: ISC can convert raw format to this format
*/
+
   struct isc_format {
u32 fourcc;
u32 mbus_code;
+   u32 flags;
u8  bpp;
   
-	u32	reg_bps;

-   u32 reg_bay_cfg;
-   u32 reg_rlp_mode;
-   u32 reg_dcfg_imode;
-   u32 reg_dctrl_dview;
-
-   u32 pipeline;
-
boolsd_support;
boolisc_support;
   };
   
+/* Pipeline bitmap */

+#define WB_ENABLE  BIT(0)
+#define CFA_ENABLE BIT(1)
+#define CC_ENABLE  BIT(2)
+#define GAM_ENABLE BIT(3)
+#define GAM_BENABLEBIT(4)
+#define GAM_GENABLEBIT(5)
+#define GAM_RENABLEBIT(6)
+#define CSC_ENABLE BIT(7)
+#define CBC_ENABLE BIT(8)
+#define SUB422_ENABLE  BIT(9)
+#define SUB420_ENABLE  BIT(10)
+
+#define GAM_ENABLES(GAM_RENABLE | GAM_GENABLE | GAM_BENABLE | GAM_ENABLE)
+
+struct fmt_config {
+   u32 fourcc;
+
+   u32 pfe_cfg0_bps;
+   u32 cfa_baycfg;
+   u32 rlp_cfg_mode;
+   u32 dcfg_imode;
+   u32 dctrl_dview;
+
+   u32 bits_pipeline;
+};
   
   #define HIST_ENTRIES		512

   #define HIST_BAYER   (ISC_HIS_CFG_MODE_B + 1)
@@ -181,80 +203,321 @@ struct isc_device {
struct list_headsubdev_entities;
   };
   
-#define RAW_FMT_IND_START0

-#define RAW_FMT_IND_END  11
-#define ISC_FMT_IND_START12
-#define ISC_FMT_IND_END  14
-
-static struct isc_format isc_formats[] = {
-   { V4L2_PIX_FMT_SBGGR8, MEDIA_BUS_FMT_SBGGR8_1X8, 8,
- ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_DAT8,
- ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0,
- false, false },
-   { V4L2_PIX_FMT_SGBRG8, MEDIA_BUS_FMT_SGBRG8_1X8, 8,
- ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_GBGB, ISC_RLP_CFG_MODE_DAT8,
- ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0,
- false, false },
-   { V4L2_PIX_FMT_SGRBG8, MEDIA_BUS_FMT_SGRBG8_1X8, 8,
- ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_GRGR, ISC_RLP_CFG_MODE_DAT8,
- ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0,
- false, false },
-   { V4L2_PIX_FMT_SRGGB8, MEDIA_BUS_FMT_SRGGB8_1X8, 8,
- ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_RGRG, ISC_RLP_CFG_MODE_DAT8,
- ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0,
- false, false },
-
-   { V4L2_PIX_FMT_SBGGR10, MEDIA_BUS_FMT_SBGGR10_1X10, 16,
- ISC_PFG_CFG0_BPS_TEN, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_DAT10,
- ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x0,
- false, false },
-   { V4L2_PIX_FMT_SGBRG10, MEDIA_BUS_FMT_SGBRG10_1X10, 16,
- ISC_PFG_CFG0_BPS_TEN, ISC_BAY_CFG_GBGB, ISC_RLP_CFG_MODE_DAT10,
- ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x0,
- false, false

Re: [PATCH v2 5/5] media: atmel-isc: Rework the format list

[Yang, Wenyou]

Hi Hans,

Thank  you very much for your review.

On 2017/9/25 21:24, Hans Verkuil wrote:

Hi Wenyou,

On 18/09/17 08:39, Wenyou Yang wrote:

To improve the readability of code, split the format array into two,
one for the format description, other for the register configuration.
Meanwhile, add the flag member to indicate the format can be achieved
from the sensor or be produced by the controller, and rename members
related to the register configuration.

Also add more formats support: GREY, ARGB444, ARGB555 and ARGB32.

Signed-off-by: Wenyou Yang 

This looks better. Just a few comments, see below.


---

Changes in v2:
  - Add the new patch to remove the unnecessary member from
isc_subdev_entity struct.
  - Rebase on the patch set,
 [PATCH 0/6] [media] Atmel: Adjustments for seven function 
implementations
 https://www.mail-archive.com/linux-media@vger.kernel.org/msg118342.html

  drivers/media/platform/atmel/atmel-isc.c | 524 ---
  1 file changed, 405 insertions(+), 119 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index 2d876903da71..90bd0b28a975 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -89,34 +89,56 @@ struct isc_subdev_entity {
struct list_head list;
  };
  
+#define FMT_FLAG_FROM_SENSOR		BIT(0)

+#define FMT_FLAG_FROM_CONTROLLER   BIT(1)

Document the meaning of these flags.

Will add it in next version.



+
  /*
   * struct isc_format - ISC media bus format information
   * @fourcc:   Fourcc code for this format
   * @mbus_code:V4L2 media bus format code.
+ * flags:  Indicate format from sensor or converted by controller
   * @bpp:  Bits per pixel (when stored in memory)
- * @reg_bps:   reg value for bits per sample
   *(when transferred over a bus)
- * @pipeline:  pipeline switch
   * @sd_support:   Subdev supports this format
   * @isc_support:  ISC can convert raw format to this format
   */
+
  struct isc_format {
u32 fourcc;
u32 mbus_code;
+   u32 flags;
u8  bpp;
  
-	u32	reg_bps;

-   u32 reg_bay_cfg;
-   u32 reg_rlp_mode;
-   u32 reg_dcfg_imode;
-   u32 reg_dctrl_dview;
-
-   u32 pipeline;
-
boolsd_support;
boolisc_support;
  };
  
+/* Pipeline bitmap */

+#define WB_ENABLE  BIT(0)
+#define CFA_ENABLE BIT(1)
+#define CC_ENABLE  BIT(2)
+#define GAM_ENABLE BIT(3)
+#define GAM_BENABLEBIT(4)
+#define GAM_GENABLEBIT(5)
+#define GAM_RENABLEBIT(6)
+#define CSC_ENABLE BIT(7)
+#define CBC_ENABLE BIT(8)
+#define SUB422_ENABLE  BIT(9)
+#define SUB420_ENABLE  BIT(10)
+
+#define GAM_ENABLES(GAM_RENABLE | GAM_GENABLE | GAM_BENABLE | GAM_ENABLE)
+
+struct fmt_config {
+   u32 fourcc;
+
+   u32 pfe_cfg0_bps;
+   u32 cfa_baycfg;
+   u32 rlp_cfg_mode;
+   u32 dcfg_imode;
+   u32 dctrl_dview;
+
+   u32 bits_pipeline;
+};
  
  #define HIST_ENTRIES		512

  #define HIST_BAYER(ISC_HIS_CFG_MODE_B + 1)
@@ -181,80 +203,321 @@ struct isc_device {
struct list_headsubdev_entities;
  };
  
-#define RAW_FMT_IND_START0

-#define RAW_FMT_IND_END  11
-#define ISC_FMT_IND_START12
-#define ISC_FMT_IND_END  14
-
-static struct isc_format isc_formats[] = {
-   { V4L2_PIX_FMT_SBGGR8, MEDIA_BUS_FMT_SBGGR8_1X8, 8,
- ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_DAT8,
- ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0,
- false, false },
-   { V4L2_PIX_FMT_SGBRG8, MEDIA_BUS_FMT_SGBRG8_1X8, 8,
- ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_GBGB, ISC_RLP_CFG_MODE_DAT8,
- ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0,
- false, false },
-   { V4L2_PIX_FMT_SGRBG8, MEDIA_BUS_FMT_SGRBG8_1X8, 8,
- ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_GRGR, ISC_RLP_CFG_MODE_DAT8,
- ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0,
- false, false },
-   { V4L2_PIX_FMT_SRGGB8, MEDIA_BUS_FMT_SRGGB8_1X8, 8,
- ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_RGRG, ISC_RLP_CFG_MODE_DAT8,
- ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0,
- false, false },
-
-   { V4L2_PIX_FMT_SBGGR10, MEDIA_BUS_FMT_SBGGR10_1X10, 16,
- ISC_PFG_CFG0_BPS_TEN, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_DAT10,
- ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x0,
- false, false },
-   { V4L2_PIX_FMT_SGBRG10, MEDIA_BUS_FMT_SGBRG10_1X10, 16,
- ISC_PFG_CFG0_BPS_TEN, ISC_BAY_CFG_GBGB, ISC_RLP_CFG_MODE_DAT10,
- ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x0,
- false, false },
-   { V4L2_PIX_FMT_SGRBG10, MEDIA_BUS_FMT_SGRBG10_1X10, 16,
- ISC_PFG_CFG0_BPS_TEN, ISC_BAY_CFG_GRG

Re: [PATCH] ARM: dts: at91: sama5d2_xplained: Add charger node

[Yang, Wenyou]

Hi Alexandre,


On 2017/9/26 4:13, Alexandre Belloni wrote:

On 15/08/2017 at 14:24:20 +0800, Wenyou Yang wrote:

From: Wenyou Yang 

Add the charger device node as a sub-device of act8945a mfd, move
the charger's properties in the node, and replace the
"active-semi,irq_gpios" with the "interrupts" property to denote
the act8945a charger's irq.

Signed-off-by: Wenyou Yang 
---

  arch/arm/boot/dts/at91-sama5d2_xplained.dts | 23 +++
  1 file changed, 15 insertions(+), 8 deletions(-)

Applied, now but I had to rework the patch a bit. Can you check this is
working for you?

https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git/commit/?h=at91-dt&id=4b6ad41f267b8ddabf5dd1b02a318bc74f0b95e9

It is okay for me.

Thanks a lot.

Best Regards,
Wenyou Yang

Re: [v2,3/3] can: m_can: Add PM Runtime

[Yang, Wenyou]

Hi Franklin,


On 2017/9/21 8:36, Franklin S Cooper Jr wrote:

On 08/24/2017 03:30 AM, Sekhar Nori wrote:

+ OMAP mailing list

On Tuesday 25 July 2017 04:21 AM, Franklin Cooper wrote:

Add support for PM Runtime which is the new way to handle managing clocks.
However, to avoid breaking SoCs not using PM_RUNTIME leave the old clk
management approach in place.

Since hclk is the interface clock, I think at a minimum there needs to
be an assumption that pm_runtime_get_sync() will enable that clock and
make the module ready for access.

The only in-kernel user of this driver seems to be an atmel SoC. I am
ccing folks who added support for M_CAN on that SoC to see if hclk
management can be left to pm_runtime*() on their SoC.

If they are okay, I think its a good to atleast drop explicit hclk
enable disable in the driver. That way, we avoid double enable/disable
of interface clock (hclk).

Wenyou,

Do you foresee this being a problem on your board? If not I can send a
v3 removing these clk_enable and clk_disable calls and it would be great
if you can test it out and provide your tested by.

Please send a v3 patch.  I would like test it on my side.




PM_RUNTIME is required by OMAP based devices to handle clock management.
Therefore, this allows future Texas Instruments SoCs that have the MCAN IP
to work with this driver.

Signed-off-by: Franklin S Cooper Jr 

Thanks,
Sekhar


---
  drivers/net/can/m_can/m_can.c | 13 +
  1 file changed, 13 insertions(+)

diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index ea48e59..93e23f5 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -23,6 +23,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  
@@ -633,11 +634,15 @@ static int m_can_clk_start(struct m_can_priv *priv)

if (err)
clk_disable_unprepare(priv->hclk);
  
+	pm_runtime_get_sync(priv->device);

+
return err;
  }
  
  static void m_can_clk_stop(struct m_can_priv *priv)

  {
+   pm_runtime_put_sync(priv->device);
+
clk_disable_unprepare(priv->cclk);
clk_disable_unprepare(priv->hclk);
  }
@@ -1582,6 +1587,8 @@ static int m_can_plat_probe(struct platform_device *pdev)
/* Enable clocks. Necessary to read Core Release in order to determine
 * M_CAN version
 */
+   pm_runtime_enable(&pdev->dev);
+
ret = clk_prepare_enable(hclk);
if (ret)
goto disable_hclk_ret;
@@ -1626,6 +1633,8 @@ static int m_can_plat_probe(struct platform_device *pdev)
 */
tx_fifo_size = mram_config_vals[7];
  
+	pm_runtime_get_sync(&pdev->dev);

+
/* allocate the m_can device */
dev = alloc_m_can_dev(pdev, addr, tx_fifo_size);
if (!dev) {
@@ -1670,6 +1679,7 @@ static int m_can_plat_probe(struct platform_device *pdev)
  disable_hclk_ret:
clk_disable_unprepare(hclk);
  failed_ret:
+   pm_runtime_put_sync(&pdev->dev);
return ret;
  }
  
@@ -1726,6 +1736,9 @@ static int m_can_plat_remove(struct platform_device *pdev)

struct net_device *dev = platform_get_drvdata(pdev);
  
  	unregister_m_can_dev(dev);

+
+   pm_runtime_disable(&pdev->dev);
+
platform_set_drvdata(pdev, NULL);
  
  	free_m_can_dev(dev);



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


Best Regards,
Wenyou Yang

Re: [PATCH v4 3/3] media: ov7670: Add the s_power operation

[Yang, Wenyou]

Hi Sakari,


On 2017/9/18 15:35, Sakari Ailus wrote:

Hi Wenyou,

Thanks for the update.

The driver exposes controls that are accessible through the sub-device node
even if the device hasn't been powered on.

Many ISP and bridge drivers will also power the sensor down once the last
user of the user space device nodes disappears. You could keep the device
powered at all times or change the behaviour so that controls can be
accessed when the power is off.

The best option would be to convert the driver to use runtime PM.

Yes, I agree with you.
I also noticed there are a lot of things needed to improve except for 
it, such as the platform data via device tree.

I would like do it in another patch set. I will continue to work on it.

An example of this can be found in drivers/media/i2c/ov13858.c .

A good example, thank you for your providing.


On Mon, Sep 18, 2017 at 02:45:14PM +0800, Wenyou Yang wrote:

Add the s_power operation which is responsible for manipulating the
power dowm mode through the PWDN pin and the reset operation through
the RESET pin.

Signed-off-by: Wenyou Yang 
---

Changes in v4: None
Changes in v3: None
Changes in v2:
  - Add the patch to support the get_fmt ops.
  - Remove the redundant invoking ov7670_init_gpio().

  drivers/media/i2c/ov7670.c | 32 +++-
  1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index 456f48057605..304abc769a67 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1542,6 +1542,22 @@ static int ov7670_s_register(struct v4l2_subdev *sd, 
const struct v4l2_dbg_regis
  }
  #endif
  
+static int ov7670_s_power(struct v4l2_subdev *sd, int on)

+{
+   struct ov7670_info *info = to_state(sd);
+
+   if (info->pwdn_gpio)
+   gpiod_direction_output(info->pwdn_gpio, !on);
+   if (on && info->resetb_gpio) {
+   gpiod_set_value(info->resetb_gpio, 1);
+   usleep_range(500, 1000);
+   gpiod_set_value(info->resetb_gpio, 0);
+   usleep_range(3000, 5000);
+   }
+
+   return 0;
+}
+
  static void ov7670_get_default_format(struct v4l2_subdev *sd,
  struct v4l2_mbus_framefmt *format)
  {
@@ -1575,6 +1591,7 @@ static const struct v4l2_subdev_core_ops ov7670_core_ops 
= {
.g_register = ov7670_g_register,
.s_register = ov7670_s_register,
  #endif
+   .s_power = ov7670_s_power,
  };
  
  static const struct v4l2_subdev_video_ops ov7670_video_ops = {

@@ -1692,23 +1709,25 @@ static int ov7670_probe(struct i2c_client *client,
if (ret)
return ret;
  
-	ret = ov7670_init_gpio(client, info);

-   if (ret)
-   goto clk_disable;
-
info->clock_speed = clk_get_rate(info->clk) / 100;
if (info->clock_speed < 10 || info->clock_speed > 48) {
ret = -EINVAL;
goto clk_disable;
}
  
+	ret = ov7670_init_gpio(client, info);

+   if (ret)
+   goto clk_disable;
+
+   ov7670_s_power(sd, 1);
+
/* Make sure it's an ov7670 */
ret = ov7670_detect(sd);
if (ret) {
v4l_dbg(1, debug, client,
"chip found @ 0x%x (%s) is not an ov7670 chip.\n",
client->addr << 1, client->adapter->name);
-   goto clk_disable;
+   goto power_off;
}
v4l_info(client, "chip found @ 0x%02x (%s)\n",
client->addr << 1, client->adapter->name);
@@ -1787,6 +1806,8 @@ static int ov7670_probe(struct i2c_client *client,
  #endif
  hdl_free:
v4l2_ctrl_handler_free(&info->hdl);
+power_off:
+   ov7670_s_power(sd, 0);
  clk_disable:
clk_disable_unprepare(info->clk);
return ret;
@@ -1804,6 +1825,7 @@ static int ov7670_remove(struct i2c_client *client)
  #if defined(CONFIG_MEDIA_CONTROLLER)
media_entity_cleanup(&info->sd.entity);
  #endif
+   ov7670_s_power(sd, 0);
return 0;
  }
  
--

2.13.0



Best Regards,
Wenyou Yang

Re: [PATCH v4 2/3] media: ov7670: Add the get_fmt callback

[Yang, Wenyou]

Hi Sakari,


On 2017/9/18 15:36, Sakari Ailus wrote:

Hi Wenyou,

On Mon, Sep 18, 2017 at 02:45:13PM +0800, Wenyou Yang wrote:

@@ -998,8 +1002,15 @@ static int ov7670_set_fmt(struct v4l2_subdev *sd,
ret = ov7670_try_fmt_internal(sd, &format->format, NULL, NULL);
if (ret)
return ret;
-   cfg->try_fmt = format->format;
+#ifdef CONFIG_VIDEO_V4L2_SUBDEV_API
+   struct v4l2_mbus_framefmt *mbus_fmt;

This will emit a compiler warning at least.

Thank you for your review.
Will be fixed in next version.



+
+   mbus_fmt = v4l2_subdev_get_try_format(sd, cfg, format->pad);
+   *mbus_fmt = format->format;
return 0;
+#else
+   return -ENOTTY;
+#endif
}
  
  	ret = ov7670_try_fmt_internal(sd, &format->format, &ovfmt, &wsize);


Best Regards,
Wenyou Yang

Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates

[Yang, Wenyou]

On 2017/9/14 13:06, Sekhar Nori wrote:

On Thursday 14 September 2017 03:28 AM, Franklin S Cooper Jr wrote:


On 08/18/2017 02:39 PM, Franklin S Cooper Jr wrote:

During test transmitting using CAN-FD at high bitrates (4 Mbps) only
resulted in errors. Scoping the signals I noticed that only a single bit
was being transmitted and with a bit more investigation realized the actual
MCAN IP would go back to initialization mode automatically.

It appears this issue is due to the MCAN needing to use the Transmitter
Delay Compensation Mode as defined in the MCAN User's Guide. When this
mode is used the User's Guide indicates that the Transmitter Delay
Compensation Offset register should be set. The document mentions that this
register should be set to (1/dbitrate)/2*(Func Clk Freq).

Additional CAN-CIA's "Bit Time Requirements for CAN FD" document indicates
that this TDC mode is only needed for data bit rates above 2.5 Mbps.
Therefore, only enable this mode and only set TDCO when the data bit rate
is above 2.5 Mbps.

Signed-off-by: Franklin S Cooper Jr 
---
I'm pretty surprised that this hasn't been implemented already since
the primary purpose of CAN-FD is to go beyond 1 Mbps and the MCAN IP
supports up to 10 Mbps.

So it will be nice to get comments from users of this driver to understand
if they have been able to use CAN-FD beyond 2.5 Mbps without this patch.
If they haven't what did they do to get around it if they needed higher
speeds.

Meanwhile I plan on testing this using a more "realistic" CAN bus to insure
everything still works at 5 Mbps which is the max speed of my CAN
transceiver.

ping. Anyone has any thoughts on this?

I added Dong who authored the m_can driver and Wenyou who added the only
in-kernel user of the driver for any help.
I tested it on SAMA5D2 Xplained board both with and without this patch,  
both work with the 4M bps data bit rate.




Thanks,
Sekhar


  drivers/net/can/m_can/m_can.c | 24 +++-
  1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index f4947a7..720e073 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -126,6 +126,12 @@ enum m_can_mram_cfg {
  #define DBTP_DSJW_SHIFT   0
  #define DBTP_DSJW_MASK(0xf << DBTP_DSJW_SHIFT)
  
+/* Transmitter Delay Compensation Register (TDCR) */

+#define TDCR_TDCO_SHIFT8
+#define TDCR_TDCO_MASK (0x7F << TDCR_TDCO_SHIFT)
+#define TDCR_TDCF_SHIFT0
+#define TDCR_TDCF_MASK (0x7F << TDCR_TDCO_SHIFT)
+
  /* Test Register (TEST) */
  #define TEST_LBCK BIT(4)
  
@@ -977,6 +983,8 @@ static int m_can_set_bittiming(struct net_device *dev)

const struct can_bittiming *dbt = &priv->can.data_bittiming;
u16 brp, sjw, tseg1, tseg2;
u32 reg_btp;
+   u32 enable_tdc = 0;
+   u32 tdco;
  
  	brp = bt->brp - 1;

sjw = bt->sjw - 1;
@@ -991,9 +999,23 @@ static int m_can_set_bittiming(struct net_device *dev)
sjw = dbt->sjw - 1;
tseg1 = dbt->prop_seg + dbt->phase_seg1 - 1;
tseg2 = dbt->phase_seg2 - 1;
+
+   /* TDC is only needed for bitrates beyond 2.5 MBit/s
+* Specified in the "Bit Time Requirements for CAN FD" document
+*/
+   if (dbt->bitrate > 250) {
+   enable_tdc = DBTP_TDC;
+   /* Equation based on Bosch's M_CAN User Manual's
+* Transmitter Delay Compensation Section
+*/
+   tdco = priv->can.clock.freq / (dbt->bitrate * 2);
+   m_can_write(priv, M_CAN_TDCR, tdco << TDCR_TDCO_SHIFT);
+   }
+
reg_btp = (brp << DBTP_DBRP_SHIFT) | (sjw << DBTP_DSJW_SHIFT) |
(tseg1 << DBTP_DTSEG1_SHIFT) |
-   (tseg2 << DBTP_DTSEG2_SHIFT);
+   (tseg2 << DBTP_DTSEG2_SHIFT) | enable_tdc;
+
m_can_write(priv, M_CAN_DBTP, reg_btp);
}
  



Regards,
Wenyou Yang

Re: [PATCH v2 1/2] mtd: nand: introduce NAND_ROW_ADDR_3 flag

[Yang, Wenyou]

On 2017/9/13 10:05, Masahiro Yamada wrote:

Several drivers check ->chipsize to see if the third row address cycle
is needed.  Instead of embedding magic sizes such as 32MB, 128MB in
drivers, introduce a new flag NAND_ROW_ADDR_3 for clean-up.  Since
nand_scan_ident() knows well about the device, it can handle this
properly.  The flag is set if the row address bit width is greater
than 16.

Delete comments such as "One more address cycle for ..." because
intention is now clear enough from the code.

Signed-off-by: Masahiro Yamada 


For atmel/nand-controller,
Acked-by: Wenyou Yang 


---

Changes in v2:
  - Fix build error

  drivers/mtd/nand/atmel/nand-controller.c | 3 +--
  drivers/mtd/nand/au1550nd.c  | 3 +--
  drivers/mtd/nand/diskonchip.c| 3 +--
  drivers/mtd/nand/hisi504_nand.c  | 3 +--
  drivers/mtd/nand/mxc_nand.c  | 3 +--
  drivers/mtd/nand/nand_base.c | 9 +
  drivers/mtd/nand/nuc900_nand.c   | 2 +-
  include/linux/mtd/rawnand.h  | 3 +++
  8 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/mtd/nand/atmel/nand-controller.c 
b/drivers/mtd/nand/atmel/nand-controller.c
index f25eca7..7bc8d20 100644
--- a/drivers/mtd/nand/atmel/nand-controller.c
+++ b/drivers/mtd/nand/atmel/nand-controller.c
@@ -718,8 +718,7 @@ static void atmel_nfc_set_op_addr(struct nand_chip *chip, 
int page, int column)
nc->op.addrs[nc->op.naddrs++] = page;
nc->op.addrs[nc->op.naddrs++] = page >> 8;
  
-		if ((mtd->writesize > 512 && chip->chipsize > SZ_128M) ||

-   (mtd->writesize <= 512 && chip->chipsize > SZ_32M))
+   if (chip->options & NAND_ROW_ADDR_3)
nc->op.addrs[nc->op.naddrs++] = page >> 16;
}
  }
diff --git a/drivers/mtd/nand/au1550nd.c b/drivers/mtd/nand/au1550nd.c
index 9d4a28f..8ab827e 100644
--- a/drivers/mtd/nand/au1550nd.c
+++ b/drivers/mtd/nand/au1550nd.c
@@ -331,8 +331,7 @@ static void au1550_command(struct mtd_info *mtd, unsigned 
command, int column, i
  
  			ctx->write_byte(mtd, (u8)(page_addr >> 8));
  
-			/* One more address cycle for devices > 32MiB */

-   if (this->chipsize > (32 << 20))
+   if (this->options & NAND_ROW_ADDR_3)
ctx->write_byte(mtd,
((page_addr >> 16) & 0x0f));
}
diff --git a/drivers/mtd/nand/diskonchip.c b/drivers/mtd/nand/diskonchip.c
index c3aa53c..72671dc 100644
--- a/drivers/mtd/nand/diskonchip.c
+++ b/drivers/mtd/nand/diskonchip.c
@@ -705,8 +705,7 @@ static void doc2001plus_command(struct mtd_info *mtd, 
unsigned command, int colu
if (page_addr != -1) {
WriteDOC((unsigned char)(page_addr & 0xff), docptr, 
Mplus_FlashAddress);
WriteDOC((unsigned char)((page_addr >> 8) & 0xff), 
docptr, Mplus_FlashAddress);
-   /* One more address cycle for higher density devices */
-   if (this->chipsize & 0x0c00) {
+   if (this->options & NAND_ROW_ADDR_3) {
WriteDOC((unsigned char)((page_addr >> 16) & 
0x0f), docptr, Mplus_FlashAddress);
printk("high density\n");
}
diff --git a/drivers/mtd/nand/hisi504_nand.c b/drivers/mtd/nand/hisi504_nand.c
index d9ee1a7..0897261 100644
--- a/drivers/mtd/nand/hisi504_nand.c
+++ b/drivers/mtd/nand/hisi504_nand.c
@@ -432,8 +432,7 @@ static void set_addr(struct mtd_info *mtd, int column, int 
page_addr)
host->addr_value[0] |= (page_addr & 0x)
<< (host->addr_cycle * 8);
host->addr_cycle+= 2;
-   /* One more address cycle for devices > 128MiB */
-   if (chip->chipsize > (128 << 20)) {
+   if (chip->options & NAND_ROW_ADDR_3) {
host->addr_cycle += 1;
if (host->command == NAND_CMD_ERASE1)
host->addr_value[0] |= ((page_addr >> 16) & 0xff) 
<< 16;
diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
index 53e5e03..bacdd04 100644
--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -859,8 +859,7 @@ static void mxc_do_addr_cycle(struct mtd_info *mtd, int 
column, int page_addr)
host->devtype_data->send_addr(host,
(page_addr >> 8) & 0xff, true);
} else {
-   /* One more address cycle for higher density devices */
-   if (mtd->size >= 0x400) {
+   if (nand_chip->options & NAND_ROW_ADDR_3) {
/* paddr_8 - paddr_15 */
host->devtype_data->send_addr(host,
(page

Re: [PATCH 0/6] [media] Atmel: Adjustments for seven function implementations

[Yang, Wenyou]

Hi,


On 2017/9/5 4:04, SF Markus Elfring wrote:

From: Markus Elfring 
Date: Mon, 4 Sep 2017 21:44:55 +0200

A few update suggestions were taken into account
from static source code analysis.

Thank you for your patches.

You can add my Acked-by for the patch series.

Acked-by: Wenyou Yang 



Markus Elfring (6):
   Delete an error message for a failed memory allocation in isc_formats_init()
   Improve a size determination in isc_formats_init()
   Adjust three checks for null pointers
   Delete an error message for a failed memory allocation in two functions
   Improve three size determinations
   Adjust a null pointer check in three functions

  drivers/media/platform/atmel/atmel-isc.c | 12 +---
  drivers/media/platform/atmel/atmel-isi.c | 20 
  2 files changed, 13 insertions(+), 19 deletions(-)



Best Regards,
Wenyou Yang

Re: [PATCH 1/3] media: atmel-isc: Not support RBG format from sensor.

[Yang, Wenyou]

Hi Hans,


On 2017/8/24 14:41, Hans Verkuil wrote:

On 08/24/2017 08:25 AM, Yang, Wenyou wrote:


On 2017/8/23 18:37, Hans Verkuil wrote:

On 08/22/17 09:30, wenyou.y...@microchip.com wrote:

Hi Hans,


-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: 2017年8月22日 15:00
To: Wenyou Yang - A41535 ; Mauro Carvalho
Chehab 
Cc: Nicolas Ferre - M43238 ; linux-
ker...@vger.kernel.org; Sakari Ailus ; Jonathan Corbet
; linux-arm-ker...@lists.infradead.org; Linux Media Mailing List

Subject: Re: [PATCH 1/3] media: atmel-isc: Not support RBG format from sensor.

On 08/22/2017 03:18 AM, Yang, Wenyou wrote:

Hi Hans,

On 2017/8/21 22:07, Hans Verkuil wrote:

On 08/17/2017 09:16 AM, Wenyou Yang wrote:

The 12-bit parallel interface supports the Raw Bayer, YCbCr,
Monochrome and JPEG Compressed pixel formats from the external
sensor, not support RBG pixel format.

Signed-off-by: Wenyou Yang 
---

drivers/media/platform/atmel/atmel-isc.c | 5 +
1 file changed, 5 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc.c
b/drivers/media/platform/atmel/atmel-isc.c
index d4df3d4ccd85..535bb03783fe 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -1478,6 +1478,11 @@ static int isc_formats_init(struct isc_device *isc)
while (!v4l2_subdev_call(subdev, pad, enum_mbus_code,
   NULL, &mbus_code)) {
mbus_code.index++;
+
+   /* Not support the RGB pixel formats from sensor */
+   if ((mbus_code.code & 0xf000) == 0x1000)
+   continue;

Am I missing something? Here you skip any RGB mediabus formats, but
in patch 3/3 you add RGB mediabus formats. But this patch prevents
those new formats from being selected, right?

This patch prevents getting the RGB format from the sensor directly.
The RGB format can be produced by ISC controller by itself.

OK, I think I see what is going on here. The isc_formats array really is two 
arrays
in one: up to RAW_FMT_IND_END it describes what it can receive from the
source, and after that it describes what it can convert it to.

Not exactly.

Yes, up to RAW_FMT_IND_END, these formats must be got from the senor, they are 
RAW formats.
  From ISC_FMT_IND_START to ISC_FMT_IND_END, they can be generated by the ISC 
controller.
It is possible they can be got from the sensor too, the driver will check it.
If it can be got from both the sensor and the ISC controller, the user can use the 
"sensor_preferred" parameter to decide from which one to get.
The RBG formats are the exception.


But if you can't handle RGB formats from the sensor, then why not make sure
none of the mbus codes in isc_formats uses RGB? That makes much more sense.

E.g.:

  { V4L2_PIX_FMT_RGB565, MEDIA_BUS_FMT_RGB565_2X8_LE, 16,
ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG,
ISC_RLP_CFG_MODE_RGB565,
ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x7b,
false, false },

Why use MEDIA_BUS_FMT_RGB565_2X8_LE if this apparently is not supported?

This array is also the lists of all formats supported by the ISC(including got 
from the sensor).
The RGB formats are only generated by the ISC controller, not from the sensor.

You're adding code that skips any entries of the table where mbus_code is an
RGB code. But this can also be done by not having RGB mbus codes in the table
in the first place since they make no sense if the HW cannot handle that!
Set the mbus_code to e.g. 0 for such entries, that makes more sense.

I also strongly suggest changing how the table is organized since those
_FMT_IND_ indices are all to easy to get wrong (and frankly hard to understand).

Yes, you are right, I will change it. Do you have some advice?

Two options spring to mind: split into two tables or add a bool that tells 
whether
the format can be created by the isc or not.
I reworked the format table, 
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-August/529683.html

Please give your comments.



Regards,

Hans


Best Regards,
Wenyou Yang

Re: [PATCH 1/3] media: atmel-isc: Not support RBG format from sensor.

[Yang, Wenyou]

On 2017/8/23 18:37, Hans Verkuil wrote:

On 08/22/17 09:30, wenyou.y...@microchip.com wrote:

Hi Hans,


-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: 2017年8月22日 15:00
To: Wenyou Yang - A41535 ; Mauro Carvalho
Chehab 
Cc: Nicolas Ferre - M43238 ; linux-
ker...@vger.kernel.org; Sakari Ailus ; Jonathan Corbet
; linux-arm-ker...@lists.infradead.org; Linux Media Mailing List

Subject: Re: [PATCH 1/3] media: atmel-isc: Not support RBG format from sensor.

On 08/22/2017 03:18 AM, Yang, Wenyou wrote:

Hi Hans,

On 2017/8/21 22:07, Hans Verkuil wrote:

On 08/17/2017 09:16 AM, Wenyou Yang wrote:

The 12-bit parallel interface supports the Raw Bayer, YCbCr,
Monochrome and JPEG Compressed pixel formats from the external
sensor, not support RBG pixel format.

Signed-off-by: Wenyou Yang 
---

   drivers/media/platform/atmel/atmel-isc.c | 5 +
   1 file changed, 5 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc.c
b/drivers/media/platform/atmel/atmel-isc.c
index d4df3d4ccd85..535bb03783fe 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -1478,6 +1478,11 @@ static int isc_formats_init(struct isc_device *isc)
while (!v4l2_subdev_call(subdev, pad, enum_mbus_code,
   NULL, &mbus_code)) {
mbus_code.index++;
+
+   /* Not support the RGB pixel formats from sensor */
+   if ((mbus_code.code & 0xf000) == 0x1000)
+   continue;

Am I missing something? Here you skip any RGB mediabus formats, but
in patch 3/3 you add RGB mediabus formats. But this patch prevents
those new formats from being selected, right?

This patch prevents getting the RGB format from the sensor directly.
The RGB format can be produced by ISC controller by itself.

OK, I think I see what is going on here. The isc_formats array really is two 
arrays
in one: up to RAW_FMT_IND_END it describes what it can receive from the
source, and after that it describes what it can convert it to.

Not exactly.

Yes, up to RAW_FMT_IND_END, these formats must be got from the senor, they are 
RAW formats.
 From ISC_FMT_IND_START to ISC_FMT_IND_END, they can be generated by the ISC 
controller.
It is possible they can be got from the sensor too, the driver will check it.
If it can be got from both the sensor and the ISC controller, the user can use the 
"sensor_preferred" parameter to decide from which one to get.
The RBG formats are the exception.


But if you can't handle RGB formats from the sensor, then why not make sure
none of the mbus codes in isc_formats uses RGB? That makes much more sense.

E.g.:

 { V4L2_PIX_FMT_RGB565, MEDIA_BUS_FMT_RGB565_2X8_LE, 16,
   ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG,
ISC_RLP_CFG_MODE_RGB565,
   ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x7b,
   false, false },

Why use MEDIA_BUS_FMT_RGB565_2X8_LE if this apparently is not supported?

This array is also the lists of all formats supported by the ISC(including got 
from the sensor).
The RGB formats are only generated by the ISC controller, not from the sensor.

You're adding code that skips any entries of the table where mbus_code is an
RGB code. But this can also be done by not having RGB mbus codes in the table
in the first place since they make no sense if the HW cannot handle that!
Set the mbus_code to e.g. 0 for such entries, that makes more sense.

I also strongly suggest changing how the table is organized since those
_FMT_IND_ indices are all to easy to get wrong (and frankly hard to understand).

Yes, you are right, I will change it. Do you have some advice?

Thank you.



Regards,

Hans


Regards,

Hans


Regards,

Hans


+
fmt = find_format_by_code(mbus_code.code, &i);
if (!fmt)
continue;


Best Regards,
Wenyou Yang


Best Regards,
Wenyou Yang

Best Regards,
Wenyou Yang

Re: [PATCH 3/3] media: atmel-isc: Add more format configurations

[Yang, Wenyou]

Hi Hans,


On 2017/8/22 14:54, Hans Verkuil wrote:

On 08/17/2017 09:16 AM, Wenyou Yang wrote:

Add the configuration of formats: GREY, ARGB444, ARGB555 and ARGB32.

Signed-off-by: Wenyou Yang 
---

  drivers/media/platform/atmel/atmel-isc.c | 22 --
  1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index d91f4e5f8a8d..4e18fe1104c8 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -184,7 +184,7 @@ struct isc_device {
  #define RAW_FMT_IND_START0
  #define RAW_FMT_IND_END  11
  #define ISC_FMT_IND_START12
-#define ISC_FMT_IND_END  14
+#define ISC_FMT_IND_END  18

Shouldn't this be 19?
From ISC_FMT_IND_START to ISC_FMT_IND_END, it describes the formats 
they can be got from both the sensor (possibly) and the ISC controller.


The last format (19) is in not this category. It maybe be got from the 
sensor, can't be generated by the controller.

Regards,

Hans

  
  static struct isc_format isc_formats[] = {

/* 0 */
@@ -246,12 +246,30 @@ static struct isc_format isc_formats[] = {
{ V4L2_PIX_FMT_YUV422P, 0x0, 16,
  ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_YYCC,
  ISC_DCFG_IMODE_YC422P, ISC_DCTRL_DVIEW_PLANAR, 0x3fb },
+
/* 14 */
+   { V4L2_PIX_FMT_GREY, MEDIA_BUS_FMT_Y8_1X8, 8,
+ ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_DATY8,
+ ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x1fb },
+
+   /* 15 */
+   { V4L2_PIX_FMT_ARGB444, MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE, 16,
+ ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_ARGB444,
+ ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x7b },
+   /* 16 */
+   { V4L2_PIX_FMT_ARGB555, MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE, 16,
+ ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_ARGB555,
+ ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x7b },
+   /* 17 */
{ V4L2_PIX_FMT_RGB565, MEDIA_BUS_FMT_RGB565_2X8_LE, 16,
  ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_RGB565,
  ISC_DCFG_IMODE_PACKED16, ISC_DCTRL_DVIEW_PACKED, 0x7b },
+   /* 18 */
+   { V4L2_PIX_FMT_ARGB32, MEDIA_BUS_FMT_ARGB_1X32, 32,
+ ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_ARGB32,
+ ISC_DCFG_IMODE_PACKED32, ISC_DCTRL_DVIEW_PACKED, 0x7b },
  
-	/* 15 */

+   /* 19 */
{ V4L2_PIX_FMT_YUYV, MEDIA_BUS_FMT_YUYV8_2X8, 16,
  ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_DAT8,
  ISC_DCFG_IMODE_PACKED8, ISC_DCTRL_DVIEW_PACKED, 0x0 },


Best Regards,
Wenyou Yang

Re: [PATCH 1/3] media: atmel-isc: Not support RBG format from sensor.

[Yang, Wenyou]

Hi Hans,

On 2017/8/21 22:07, Hans Verkuil wrote:

On 08/17/2017 09:16 AM, Wenyou Yang wrote:

The 12-bit parallel interface supports the Raw Bayer, YCbCr,
Monochrome and JPEG Compressed pixel formats from the external
sensor, not support RBG pixel format.

Signed-off-by: Wenyou Yang 
---

  drivers/media/platform/atmel/atmel-isc.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/media/platform/atmel/atmel-isc.c 
b/drivers/media/platform/atmel/atmel-isc.c
index d4df3d4ccd85..535bb03783fe 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -1478,6 +1478,11 @@ static int isc_formats_init(struct isc_device *isc)
while (!v4l2_subdev_call(subdev, pad, enum_mbus_code,
   NULL, &mbus_code)) {
mbus_code.index++;
+
+   /* Not support the RGB pixel formats from sensor */
+   if ((mbus_code.code & 0xf000) == 0x1000)
+   continue;

Am I missing something? Here you skip any RGB mediabus formats, but in patch 3/3
you add RGB mediabus formats. But this patch prevents those new formats from 
being
selected, right?

This patch prevents getting the RGB format from the sensor directly.
The RGB format can be produced by ISC controller by itself.


Regards,

Hans


+
fmt = find_format_by_code(mbus_code.code, &i);
if (!fmt)
continue;



Best Regards,
Wenyou Yang

Re: [PATCH 1/2] media: ov7670: Add entity pads initialization

[Yang, Wenyou]

Hi Sakari,


On 2017/8/16 0:23, Sakari Ailus wrote:

Hi Wenyou,

On Thu, Aug 10, 2017 at 05:06:44PM +0800, Wenyou Yang wrote:

Add the media entity pads initialization.

Signed-off-by: Wenyou Yang 

The patch itself seems fine. However the driver is lacking support for
get_fmt which I think would be necessary for the user space API to work
properly. Without sub-device nodes it might not have been an issue with
certain master drivers.

Could you add that in v2, in a separate patch before this one, please?

Okay, I will do.
Thank you for your review.




---

  drivers/media/i2c/ov7670.c | 13 -
  1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index e88549f0e704..5c8460ee65c3 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -213,6 +213,7 @@ struct ov7670_devtype {
  struct ov7670_format_struct;  /* coming later */
  struct ov7670_info {
struct v4l2_subdev sd;
+   struct media_pad pad;
struct v4l2_ctrl_handler hdl;
struct {
/* gain cluster */
@@ -1688,14 +1689,23 @@ static int ov7670_probe(struct i2c_client *client,
v4l2_ctrl_auto_cluster(2, &info->auto_exposure,
   V4L2_EXPOSURE_MANUAL, false);
v4l2_ctrl_cluster(2, &info->saturation);
+
+   info->pad.flags = MEDIA_PAD_FL_SOURCE;
+   info->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
+   ret = media_entity_pads_init(&info->sd.entity, 1, &info->pad);
+   if (ret < 0)
+   goto hdl_free;
+
v4l2_ctrl_handler_setup(&info->hdl);
  
  	ret = v4l2_async_register_subdev(&info->sd);

if (ret < 0)
-   goto hdl_free;
+   goto entity_cleanup;
  
  	return 0;
  
+entity_cleanup:

+   media_entity_cleanup(&info->sd.entity);
  hdl_free:
v4l2_ctrl_handler_free(&info->hdl);
  clk_disable:
@@ -1712,6 +1722,7 @@ static int ov7670_remove(struct i2c_client *client)
v4l2_device_unregister_subdev(sd);
v4l2_ctrl_handler_free(&info->hdl);
clk_disable_unprepare(info->clk);
+   media_entity_cleanup(&info->sd.entity);
return 0;
  }
  
--

2.13.0


Best Regards,
Wenyou Yang

Re: [PATCH v3] ARM: dts: at91: sama5d2: add m_can nodes

[Yang, Wenyou]

On 2017/4/24 9:12, Wenyou Yang wrote:

Add nodes to support the Controller Area Network(M_CAN) on SAMA5D2.
The version of M_CAN IP core is 3.1.0 (CREL = 0x31040730).

As said in SAMA5D2 datasheet, the CAN clock is recommended to use
frequencies of 20, 40 or 80 MHz. To achieve these frequencies,
PMC GCLK3 must select the UPLLCK(480 MHz) as source clock and
divide by 24, 12, or 6. So, the "assigned-clock-rates" property
has three options: 2000, 4000, and 8000.
The "assigned-clock-parents" property should be referred to utmi
fixedly.

The MSBs [bits 31:16] of the CAN Message RAM for CAN0 and CAN1 are
default configured in 0x0020. To avoid conflict with SRAM map
for PM, change them to 0x0021 in the AT91Bootstrap via setting
the CAN Memories Address-based Register(SFR_CAN) of SFR.

Signed-off-by: Wenyou Yang 
Tested-by: Quentin Schulz 


Do you have any comments?

---
The patch is tested on SAMA5D2 Xplained and based on the patch set,
  1. [PATCH v4 1/7] can: m_can: Disabled Interrupt Line 1
 http://marc.info/?l=linux-can&m=149165343604033&w=2

Changes in v3:
  - Add Tested-by tag.
  - Change the number of Rx Rx Buffers, Tx Buffers and Tx Event FIFO
to maximum.

Changes in v2:
  - Configures 10 TX Event FIFO elements and 10 TX Buffers/FIFO slots,
because the TXE FIFO is needed to be configured.
  - Configure the offset of Message RAM for CAN1 followed from CAN0's.

  arch/arm/boot/dts/at91-sama5d2_xplained.dts | 24 +
  arch/arm/boot/dts/sama5d2.dtsi  | 56 +
  2 files changed, 80 insertions(+)

diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts 
b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 9f7f8a7d8ff9..2f19b08dc226 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -257,6 +257,12 @@
status = "okay";
};
  
+			can0: can@f8054000 {

+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_can0_default>;
+   status = "okay";
+   };
+
uart3: serial@fc008000 {
atmel,use-dma-rx;
atmel,use-dma-tx;
@@ -321,6 +327,18 @@
bias-disable;
};
  
+pinctrl_can0_default: can0_default {

+   pinmux = ,
+;
+   bias-disable;
+   };
+
+   pinctrl_can1_default: can1_default {
+   pinmux = ,
+;
+   bias-disable;
+   };
+
pinctrl_charger_chglev: charger_chglev {
pinmux = ;
bias-disable;
@@ -468,6 +486,12 @@
};
  
  			};

+
+   can1: can@fc05 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_can1_default>;
+   status = "okay";
+   };
};
};
  
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi

index 22332be72140..7e00fa21373e 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -762,6 +762,18 @@
atmel,clk-output-range = <0 
8300>;
};
  
+	can0_clk: can0_clk {

+   #clock-cells = <0>;
+   reg = <56>;
+   atmel,clk-output-range = <0 
8300>;
+   };
+
+   can1_clk: can1_clk {
+   #clock-cells = <0>;
+   reg = <57>;
+   atmel,clk-output-range = <0 
8300>;
+   };
+
classd_clk: classd_clk {
#clock-cells = <0>;
reg = <59>;
@@ -890,6 +902,18 @@
#clock-cells = <0>;
reg = <55>;
};
+
+   can0_gclk: can0_gclk {
+   #clock-cells = <0>;
+   reg = <5

Re: [PATCH 3/3] ARM: at91: pm: fallback to slowclock when backup mode fails

[Yang, Wenyou]

On 2017/4/27 0:04, Alexandre Belloni wrote:

If the backup sram allocation fails, ensure we can suspend by falling back
to the usual slow clock mode.

Signed-off-by: Alexandre Belloni 

Acked-by: Wenyou Yang 


---
  arch/arm/mach-at91/pm.c | 12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index d08f032f9d94..02823d8f3ada 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -519,24 +519,30 @@ static void __init at91_pm_bu_sram_init(void)
  
  	if (!pdev) {

pr_warn("%s: failed to find securam device!\n", __func__);
-   return;
+   goto fallback;
}
  
  	sram_pool = gen_pool_get(&pdev->dev, NULL);

if (!sram_pool) {
pr_warn("%s: securam pool unavailable!\n", __func__);
-   return;
+   goto fallback;
}
  
  	pm_bu = (void *)gen_pool_alloc(sram_pool, sizeof(struct at91_pm_bu));

if (!pm_bu) {
pr_warn("%s: unable to alloc securam!\n", __func__);
-   return;
+   goto fallback;
}
  
  	pm_bu->suspended = 0;

pm_bu->canary = virt_to_phys(&canary);
pm_bu->resume = virt_to_phys(cpu_resume);
+
+fallback:
+   if (pm_data.standby_mode == AT91_PM_BACKUP)
+   pm_data.standby_mode = AT91_PM_SLOW_CLOCK;
+   if (pm_data.suspend_mode != AT91_PM_BACKUP)
+   pm_data.suspend_mode = AT91_PM_SLOW_CLOCK;
  }
  
  struct pmc_info {

Best Regards,
Wenyou Yang

Re: [PATCH 2/3] ARM: at91: pm: allow selecting standby and suspend modes

[Yang, Wenyou]

On 2017/4/27 0:04, Alexandre Belloni wrote:

While we can only select between "standby" and "mem" states for power
management, the atmel platforms can actually support more modes.

For both standby and mem, allow selecting which mode will be used using the
atmel.pm_modes kernel parameter.
By default, keep the current modes.

Signed-off-by: Alexandre Belloni 


Acked-by: Wenyou Yang 

---
  arch/arm/mach-at91/pm.c | 110 +---
  arch/arm/mach-at91/pm.h |   3 +-
  2 files changed, 78 insertions(+), 35 deletions(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 1e03f1277f14..d08f032f9d94 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -15,6 +15,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  #include 

@@ -38,7 +39,17 @@ extern void at91_pinctrl_gpio_suspend(void);
  extern void at91_pinctrl_gpio_resume(void);
  #endif
  
-static struct at91_pm_data pm_data;

+static const match_table_t pm_modes __initconst = {
+   { 0, "standby" },
+   { AT91_PM_SLOW_CLOCK, "ulp0" },
+   { AT91_PM_BACKUP, "backup" },
+   { -1, NULL },
+};
+
+static struct at91_pm_data pm_data = {
+   .standby_mode = 0,
+   .suspend_mode = AT91_PM_SLOW_CLOCK,
+};
  
  #define at91_ramc_read(id, field) \

__raw_readl(pm_data.ramc[id] + field)
@@ -68,14 +79,24 @@ static struct at91_pm_bu {
phys_addr_t resume;
  } *pm_bu;
  
-static suspend_state_t target_state;

-
  /*
   * Called after processes are frozen, but before we shutdown devices.
   */
  static int at91_pm_begin(suspend_state_t state)
  {
-   target_state = state;
+   switch (state) {
+   case PM_SUSPEND_MEM:
+   pm_data.mode = pm_data.suspend_mode;
+   break;
+
+   case PM_SUSPEND_STANDBY:
+   pm_data.mode = pm_data.standby_mode;
+   break;
+
+   default:
+   pm_data.mode = -1;
+   }
+
return 0;
  }
  
@@ -124,7 +145,7 @@ static int at91_pm_verify_clocks(void)

   */
  int at91_suspend_entering_slow_clock(void)
  {
-   return (target_state == PM_SUSPEND_MEM);
+   return (pm_data.mode >= AT91_PM_SLOW_CLOCK);
  }
  EXPORT_SYMBOL(at91_suspend_entering_slow_clock);
  
@@ -144,14 +165,6 @@ static int at91_suspend_finish(unsigned long val)
  
  static void at91_pm_suspend(suspend_state_t state)

  {
-   if (pm_data.deepest_state == AT91_PM_BACKUP)
-   if (state == PM_SUSPEND_MEM)
-   pm_data.mode = AT91_PM_BACKUP;
-   else
-   pm_data.mode = AT91_PM_SLOW_CLOCK;
-   else
-   pm_data.mode = (state == PM_SUSPEND_MEM) ? AT91_PM_SLOW_CLOCK : 
0;
-
if (pm_data.mode == AT91_PM_BACKUP) {
pm_bu->suspended = 1;
  
@@ -168,38 +181,37 @@ static void at91_pm_suspend(suspend_state_t state)

outer_resume();
  }
  
+/*

+ * STANDBY mode has *all* drivers suspended; ignores irqs not marked as 
'wakeup'
+ * event sources; and reduces DRAM power.  But otherwise it's identical to
+ * PM_SUSPEND_ON: cpu idle, and nothing fancy done with main or cpu clocks.
+ *
+ * AT91_PM_SLOW_CLOCK is like STANDBY plus slow clock mode, so drivers must
+ * suspend more deeply, the master clock switches to the clk32k and turns off
+ * the main oscillator
+ *
+ * AT91_PM_BACKUP turns off the whole SoC after placing the DDR in self refresh
+ */
  static int at91_pm_enter(suspend_state_t state)
  {
  #ifdef CONFIG_PINCTRL_AT91
at91_pinctrl_gpio_suspend();
  #endif
+
switch (state) {
-   /*
-* Suspend-to-RAM is like STANDBY plus slow clock mode, so
-* drivers must suspend more deeply, the master clock switches
-* to the clk32k and turns off the main oscillator
-*/
case PM_SUSPEND_MEM:
+   case PM_SUSPEND_STANDBY:
/*
 * Ensure that clocks are in a valid state.
 */
-   if (!at91_pm_verify_clocks())
+   if ((pm_data.mode >= AT91_PM_SLOW_CLOCK) &&
+   !at91_pm_verify_clocks())
goto error;
  
  		at91_pm_suspend(state);
  
  		break;
  
-	/*

-* STANDBY mode has *all* drivers suspended; ignores irqs not
-* marked as 'wakeup' event sources; and reduces DRAM power.
-* But otherwise it's identical to PM_SUSPEND_ON: cpu idle, and
-* nothing fancy done with main or cpu clocks.
-*/
-   case PM_SUSPEND_STANDBY:
-   at91_pm_suspend(state);
-   break;
-
case PM_SUSPEND_ON:
cpu_do_idle();
break;
@@ -210,8 +222,6 @@ static int at91_pm_enter(suspend_state_t state)
}
  
  error:

-   target_state = PM_SUSPEND_ON;
-
  #ifdef CONFIG_PINCTRL_AT91
at91_pinctrl_gpio_resume();
  #endif
@@ -223,7 +233,6 @@ static int at91_pm_enter(suspend_state_t state)
   */
  static void at91_pm_end(void)
  {
-  

Re: [PATCH 1/3] ARM: at91: pm: Add sama5d2 backup mode

[Yang, Wenyou]

On 2017/4/27 0:04, Alexandre Belloni wrote:

The sama5d2 has a mode were it is possible to cut power to the SoC while
keeping the RAM in self refresh.
Resuming from that mode needs support in the firmware/bootloader.

Signed-off-by: Alexandre Belloni 


Acked-by: Wenyou Yang 

---
  arch/arm/mach-at91/Makefile  |   4 ++
  arch/arm/mach-at91/generic.h |   2 +
  arch/arm/mach-at91/pm.c  | 103 ++-
  arch/arm/mach-at91/pm.h  |   4 ++
  arch/arm/mach-at91/pm_data-offsets.c |   3 +
  arch/arm/mach-at91/pm_suspend.S  |  86 ++---
  arch/arm/mach-at91/sama5.c   |  19 ++-
  7 files changed, 198 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-at91/Makefile b/arch/arm/mach-at91/Makefile
index cfd8f60a9268..87fe17dbdb56 100644
--- a/arch/arm/mach-at91/Makefile
+++ b/arch/arm/mach-at91/Makefile
@@ -14,6 +14,10 @@ obj-$(CONFIG_PM) += pm_suspend.o
  ifeq ($(CONFIG_CPU_V7),y)
  AFLAGS_pm_suspend.o := -march=armv7-a
  endif
+# Backup mode will not compile for ARMv5 because of movt
+ifeq ($(CONFIG_SOC_SAMA5D2),y)
+AFLAGS_pm_suspend.o += -DBACKUP_MODE
+endif
  ifeq ($(CONFIG_PM_DEBUG),y)
  CFLAGS_pm.o += -DDEBUG
  endif
diff --git a/arch/arm/mach-at91/generic.h b/arch/arm/mach-at91/generic.h
index f1ead0f13c19..e2bd17237964 100644
--- a/arch/arm/mach-at91/generic.h
+++ b/arch/arm/mach-at91/generic.h
@@ -15,10 +15,12 @@
  extern void __init at91rm9200_pm_init(void);
  extern void __init at91sam9_pm_init(void);
  extern void __init sama5_pm_init(void);
+extern void __init sama5d2_pm_init(void);
  #else
  static inline void __init at91rm9200_pm_init(void) { }
  static inline void __init at91sam9_pm_init(void) { }
  static inline void __init sama5_pm_init(void) { }
+static inline void __init sama5d2_pm_init(void) { }
  #endif
  
  #endif /* _AT91_GENERIC_H */

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 2cd27c830ab6..1e03f1277f14 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -22,6 +22,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "generic.h"

  #include "pm.h"
@@ -58,6 +59,14 @@ static int at91_pm_valid_state(suspend_state_t state)
}
  }
  
+static int canary = 0xA5A5A5A5;

+
+static struct at91_pm_bu {
+   int suspended;
+   unsigned long reserved;
+   phys_addr_t canary;
+   phys_addr_t resume;
+} *pm_bu;
  
  static suspend_state_t target_state;
  
@@ -123,15 +132,39 @@ static void (*at91_suspend_sram_fn)(struct at91_pm_data *);

  extern void at91_pm_suspend_in_sram(struct at91_pm_data *pm_data);
  extern u32 at91_pm_suspend_in_sram_sz;
  
-static void at91_pm_suspend(suspend_state_t state)

+static int at91_suspend_finish(unsigned long val)
  {
-   pm_data.mode = (state == PM_SUSPEND_MEM) ? AT91_PM_SLOW_CLOCK : 0;
-
flush_cache_all();
outer_disable();
  
  	at91_suspend_sram_fn(&pm_data);
  
+	return 0;

+}
+
+static void at91_pm_suspend(suspend_state_t state)
+{
+   if (pm_data.deepest_state == AT91_PM_BACKUP)
+   if (state == PM_SUSPEND_MEM)
+   pm_data.mode = AT91_PM_BACKUP;
+   else
+   pm_data.mode = AT91_PM_SLOW_CLOCK;
+   else
+   pm_data.mode = (state == PM_SUSPEND_MEM) ? AT91_PM_SLOW_CLOCK : 
0;
+
+   if (pm_data.mode == AT91_PM_BACKUP) {
+   pm_bu->suspended = 1;
+
+   cpu_suspend(0, at91_suspend_finish);
+
+   /* The SRAM is lost between suspend cycles */
+   at91_suspend_sram_fn = fncpy(at91_suspend_sram_fn,
+&at91_pm_suspend_in_sram,
+at91_pm_suspend_in_sram_sz);
+   } else {
+   at91_suspend_finish(0);
+   }
+
outer_resume();
  }
  
@@ -375,6 +408,25 @@ static __init void at91_dt_ramc(void)

at91_cpuidle_device.dev.platform_data = standby;
  }
  
+static __init void at91_dt_shdwc(void)

+{
+   struct device_node *np;
+
+   np = of_find_compatible_node(NULL, NULL, "atmel,sama5d2-shdwc");
+   if (!np)
+   return;
+
+   pm_data.shdwc = of_iomap(np, 0);
+   of_node_put(np);
+
+   np = of_find_compatible_node(NULL, NULL, "atmel,sama5d2-sfrbu");
+   if (!np)
+   return;
+
+   pm_data.sfrbu = of_iomap(np, 0);
+   of_node_put(np);
+}
+
  static void at91rm9200_idle(void)
  {
/*
@@ -436,6 +488,44 @@ static void __init at91_pm_sram_init(void)
&at91_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
  }
  
+static void __init at91_pm_bu_sram_init(void)

+{
+   struct gen_pool *sram_pool;
+   struct device_node *node;
+   struct platform_device *pdev = NULL;
+
+   pm_bu = NULL;
+
+   for_each_compatible_node(node, NULL, "atmel,sama5d2-securam") {
+   pdev = of_find_device_by_node(node);
+  

RE: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

[Yang, Wenyou]

Hi Alan,

From: Alan Stern [st...@rowland.harvard.edu]
Sent: Friday, May 13, 2016 2:11
To: Yang, Wenyou
Cc: Greg Kroah-Hartman; Ferre, Nicolas; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

On Thu, 12 May 2016, Wenyou Yang wrote:

> In order to get lower consumption, as a workaround, suspend
> the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI Interrupt
> Configuration Register while OHCI USB suspending.

What does this mean?  What does suspending a port do?  Is it the same
as a normal USB port suspend?

If it is the same, why doesn't the USB_PORT_FEAT_SUSPEND subcase of the
SetPortFeature case in ohci_hub_control() already take care of this?

Yes, you are right. 

We can use  the USB_PORT_FEAT_SUSPEND subcase of the
SetPortFeature case to take care this.

I will send a new patch, please help review it. Thanks a lot.

> This suspend operation must be done before stopping the USB clock,
> resume after the USB clock enabled.
>
> Signed-off-by: Wenyou Yang 
> ---

> @@ -132,6 +135,17 @@ static void at91_stop_hc(struct platform_device *pdev)
>
>  /*-*/
>
> +struct regmap *at91_dt_syscon_sfr(void)
> +{
> + struct regmap *regmap;
> +
> + regmap = syscon_regmap_lookup_by_compatible("atmel,sama5d2-sfr");
> + if (IS_ERR(regmap))
> + return NULL;

If you get an error, the regmap pointer is set to NULL...

> @@ -197,6 +211,8 @@ static int usb_hcd_at91_probe(const struct hc_driver 
> *driver,
>   goto err;
>   }
>
> + ohci_at91->sfr_regmap = at91_dt_syscon_sfr();

With no other error checking...

> +
>   board = hcd->self.controller->platform_data;
>   ohci = hcd_to_ohci(hcd);
>   ohci->num_ports = board->ports;

> +static int ohci_at91_port_ctrl(struct regmap *regmap, bool enable)
> +{
> + u32 regval;
> + int ret;
> +
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + ret = regmap_read(regmap, SFR_OHCIICR, ®val);

And now what happens if regmap is NULL?  Hint: It won't be pretty...

Alan Stern


Best Regards,
Wenyou Yang

RE: [PATCH] power: act8945a_charger: fix semicolon.cocci warnings

[Yang, Wenyou]

Hi Fengguang,

I would like to merge this patch and add your Signed-off-by, do you agree?

I think it is better.

Best Regards,
Wenyou Yang


From: kbuild test robot [l...@intel.com]
Sent: Friday, June 24, 2016 20:43
To: Yang, Wenyou
Cc: kbuild-...@01.org; Sebastian Reichel; Dmitry Eremin-Solenikov; David 
Woodhouse; Rob Herring; Pawel Moll; Mark Brown; Ian Campbell; Kumar Gala; 
linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; 
linux-arm-ker...@lists.infradead.org; Ferre, Nicolas; linux...@vger.kernel.org; 
Yang, Wenyou
Subject: [PATCH] power: act8945a_charger: fix semicolon.cocci warnings

drivers/power/act8945a_charger.c:115:2-3: Unneeded semicolon


 Remove unneeded semicolon.

Generated by: scripts/coccinelle/misc/semicolon.cocci

CC: Wenyou Yang 
Signed-off-by: Fengguang Wu 
---

 act8945a_charger.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/power/act8945a_charger.c
+++ b/drivers/power/act8945a_charger.c
@@ -112,7 +112,7 @@ static int act8945a_get_charger_state(st
else
*val = POWER_SUPPLY_STATUS_NOT_CHARGING;
break;
-   };
+   }

return 0;
 }

RE: [PATCH v2 0/7] power: act8945a_charger: Improvements

[Yang, Wenyou]

Hello everyone

Do you have any comments for this patch set?

Best Regards,
Wenyou Yang

From: Wenyou Yang [wenyou.y...@atmel.com]
Sent: Tuesday, June 28, 2016 9:22
To: Sebastian Reichel; Dmitry Eremin-Solenikov; David Woodhouse; Rob Herring; 
Pawel Moll; Mark Brown; Ian Campbell; Kumar Gala
Cc: linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; 
linux-arm-ker...@lists.infradead.org; Ferre, Nicolas; linux...@vger.kernel.org; 
Yang, Wenyou
Subject: [PATCH v2 0/7] power: act8945a_charger: Improvements

This patch series is used to improve the act8945a-charger, such as
improve the way to check the status, fix the power supply type
property, add the status change update, and add more properties:
capacity level property and max current property.

Changes in v2:
 - Add missing ret declaration.

Wenyou Yang (7):
  power: act8945a_charger: Remove "battery_temperature"
  power: act8945a_charger: Improve
  power: act8945a_charger: Add status change update support
  power: act8945a_charger: Fix the power supply type
  power: act8945a_charger: Add capacity level property
  power: act8945a_charger: Add max current property
  doc: bindings: act8945a-charger: Update properties

 .../devicetree/bindings/power/act8945a-charger.txt |   6 +-
 drivers/power/act8945a_charger.c   | 371 ++---
 2 files changed, 337 insertions(+), 40 deletions(-)

--
2.7.4

RE: [PATCH] power: act8945a_charger: fix semicolon.cocci warnings

[Yang, Wenyou]

> -Original Message-
> From: kbuild test robot [mailto:l...@intel.com]
> Sent: 2016年6月24日 20:43
> To: Yang, Wenyou 
> Cc: kbuild-...@01.org; Sebastian Reichel ; Dmitry Eremin-
> Solenikov ; David Woodhouse
> ; Rob Herring ; Pawel Moll
> ; Mark Brown ; Ian Campbell
> ; Kumar Gala ; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; Ferre, Nicolas ; linux-
> p...@vger.kernel.org; Yang, Wenyou 
> Subject: [PATCH] power: act8945a_charger: fix semicolon.cocci warnings
> 
> drivers/power/act8945a_charger.c:115:2-3: Unneeded semicolon
> 
> 
>  Remove unneeded semicolon.
> 
> Generated by: scripts/coccinelle/misc/semicolon.cocci
> 
> CC: Wenyou Yang 
> Signed-off-by: Fengguang Wu 
Acked-by Wenyou Yang 

Thank you for your fix.

> ---
> 
>  act8945a_charger.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/drivers/power/act8945a_charger.c
> +++ b/drivers/power/act8945a_charger.c
> @@ -112,7 +112,7 @@ static int act8945a_get_charger_state(st
>   else
>   *val = POWER_SUPPLY_STATUS_NOT_CHARGING;
>   break;
> - };
> + }
> 
>   return 0;
>  }


Best Regards,
Wenyou Yang

RE: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

[Yang, Wenyou]

Hi Alan,

Sorry for late answer.

> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: 2016年5月13日 2:11
> To: Yang, Wenyou 
> Cc: Greg Kroah-Hartman ; Ferre, Nicolas
> ; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending
> 
> On Thu, 12 May 2016, Wenyou Yang wrote:
> 
> > In order to get lower consumption, as a workaround, suspend the USB
> > PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI Interrupt
> > Configuration Register while OHCI USB suspending.
> 
> What does this mean?  What does suspending a port do?  Is it the same as a
> normal USB port suspend?

The usb controller from Synopsis does not managed correctly the suspend mode 
for the EHCI. 
There is no way to have the VDDUTMII (USB device and host UTMI interface) 
suspend without any device connected to it. 

That's why we added this specific control to fix this issue. Namely, by setting 
some bits of one of the special function registers to fix this issue outside 
the usb controller. 

And the suspend mode works in OHCI mode.

It is not same as a normal USB port suspend.

> 
> If it is the same, why doesn't the USB_PORT_FEAT_SUSPEND subcase of the
> SetPortFeature case in ohci_hub_control() already take care of this?
> 
> > This suspend operation must be done before stopping the USB clock,
> > resume after the USB clock enabled.
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> 
> > @@ -132,6 +135,17 @@ static void at91_stop_hc(struct platform_device
> > *pdev)
> >
> >
> > /*
> > -*/
> >
> > +struct regmap *at91_dt_syscon_sfr(void) {
> > +   struct regmap *regmap;
> > +
> > +   regmap = syscon_regmap_lookup_by_compatible("atmel,sama5d2-sfr");
> > +   if (IS_ERR(regmap))
> > +   return NULL;
> 
> If you get an error, the regmap pointer is set to NULL...
> 
> > @@ -197,6 +211,8 @@ static int usb_hcd_at91_probe(const struct hc_driver
> *driver,
> > goto err;
> > }
> >
> > +   ohci_at91->sfr_regmap = at91_dt_syscon_sfr();
> 
> With no other error checking...
> 
> > +
> > board = hcd->self.controller->platform_data;
> > ohci = hcd_to_ohci(hcd);
> > ohci->num_ports = board->ports;
> 
> > +static int ohci_at91_port_ctrl(struct regmap *regmap, bool enable) {
> > +   u32 regval;
> > +   int ret;
> > +
> > +   if (IS_ERR(regmap))
> > +   return PTR_ERR(regmap);
> > +
> > +   ret = regmap_read(regmap, SFR_OHCIICR, ®val);
> 
> And now what happens if regmap is NULL?  Hint: It won't be pretty...
> 
> Alan Stern


Best Regards,
Wenyou Yang

RE: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

[Yang, Wenyou]

Hi Alexandre & Nicolas,

> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: 2016年6月20日 16:04
> To: Yang, Wenyou 
> Cc: Rob Herring ; Alan Stern ;
> Greg Kroah-Hartman ; Ferre, Nicolas
> ; Pawel Moll ; Mark Brown
> ; Ian Campbell ; Kumar
> Gala ; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> u...@vger.kernel.org
> Subject: Re: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB
> suspend
> 
> On 20/06/2016 at 03:16:35 +, Yang, Wenyou wrote :
> > > Sure, what I mean is that you can try to get the regmap for the SFR in 
> > > every
> case.
> > > Depending on whether you were able to get it, you can decide to call
> > > ohci_at91_port_suspend/resume or not (just test for sfr_regmap != NULL).
> >
> > I don't think so. The SFR includes a lot of miscellaneous functions, more 
> > than
> this one.
> >
> 
> I know but this is irrelevant to this discussion. If you need to use the SFR 
> from
> another driver you will simply get it from that other driver.
> 
> I that case, you will try to get "atmel,sama5d2-sfr". It is only present on 
> sama5d2
> so you have enough information to know whether or not you can use it to
> suspend/resume.

I understand what your meaning :).
Use "atmel,sama5d2-sfr" compatible to distinguish whether forcibly suspend USB 
port via SFR or not.

I am not sure if it is a better solution.

Nicolas, could you give your opinion?

> 
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering http://free-electrons.com


Best Regards,
Wenyou Yang

RE: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

[Yang, Wenyou]

> -Original Message-
> From: Ferre, Nicolas
> Sent: 2016年6月8日 18:46
> To: Yang, Wenyou ; Alan Stern
> ; Greg Kroah-Hartman
> ; Rob Herring ; Alexandre
> Belloni 
> Cc: Pawel Moll ; Mark Brown ; Ian
> Campbell ; Kumar Gala ;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB
> suspend
> 
> Le 08/06/2016 12:04, Nicolas Ferre a écrit :
> > Le 08/06/2016 06:15, Wenyou Yang a écrit :
> >> In order to the save power consumption, as a workaround, suspend
> >> forcibly the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI
> >> Interrupt Configuration Register in the SFRs while OHCI USB suspend.
> >>
> >> This suspend operation must be done before the USB clock is disabled,
> >> resume after the USB clock is enabled.
> >>
> >> Signed-off-by: Wenyou Yang 
> >
> > Little nitpicking below...
> >
> >> ---
> >>
> >> Changes in v3:
> >>  - Change the compatible description for more precise.
> >>
> >> Changes in v2:
> >>  - Add compatible to support forcibly suspend the ports.
> >>  - Add soc/at91/at91_sfr.h to accommodate the defines.
> >>  - Add error checking for .sfr_regmap.
> >>  - Remove unnecessary regmap_read() statement.
> >>
> >>  .../devicetree/bindings/usb/atmel-usb.txt  |  6 +-
> >>  drivers/usb/host/ohci-at91.c   | 80 
> >> +-
> >>  include/soc/at91/at91_sfr.h| 29 
> 
> Oops sorry, additional comment which is not nitpicking, this one:
> 
> We already have SFR header file in this patch:
> 
> Author: Cyrille Pitchen 
> Date:   Thu Mar 17 17:04:00 2016 +0100
> 
> ARM: dts: at91: sama5d2: add SFR node
> 
> This SFR node is looked up by the I2S controller driver to tune the
> SFR_I2SCLKSEL register.
> 
> Signed-off-by: Cyrille Pitchen 
> Signed-off-by: Ludovic Desroches 
> Acked-by: Alexandre Belloni 
> Acked-by: Rob Herring 
> Signed-off-by: Nicolas Ferre 
> 
> Which is already accepted by arm-soc guys for 4.7... So my ack transforms 
> into a
> nack, sorry...
> 
> We will have to coordinate the effort and maybe take the whole series with 
> us. But
> for sure, you'll have to use the existing include/soc/at91/atmel-sfr.h file 
> and build
> on top of it...

Sorry, not notice this file.

I will built it on this file.

> 
> Bye,
> 
> >>  3 files changed, 112 insertions(+), 3 deletions(-)  create mode
> >> 100644 include/soc/at91/at91_sfr.h
> 
> [..]
> 
> >
> > But you can take my:
> >
> > Acked-by: Nicolas Ferre 
> >
> > with the little corrections listed.
> >
> > Alan, We plan to take the second patch of this series with AT91 git
> > tree through arm-soc. Do you agree to take this one through yours?
> 
> Alan, forget this request, we'll have to coordinate differently.
> 
> Sorry for the noise. Bye,
> --
> Nicolas Ferre


Best Regards,
Wenyou Yang

RE: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

[Yang, Wenyou]

Hi Rob,

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: 2016年6月9日 4:27
> To: Yang, Wenyou 
> Cc: Alan Stern ; Greg Kroah-Hartman
> ; Ferre, Nicolas ;
> Pawel Moll ; Mark Brown ; Ian
> Campbell ; Kumar Gala ;
> Alexandre Belloni ; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB
> suspend
> 
> On Wed, Jun 08, 2016 at 12:15:10PM +0800, Wenyou Yang wrote:
> > In order to the save power consumption, as a workaround, suspend
> > forcibly the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI
> > Interrupt Configuration Register in the SFRs while OHCI USB suspend.
> >
> > This suspend operation must be done before the USB clock is disabled,
> > resume after the USB clock is enabled.
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> >
> > Changes in v3:
> >  - Change the compatible description for more precise.
> >
> > Changes in v2:
> >  - Add compatible to support forcibly suspend the ports.
> >  - Add soc/at91/at91_sfr.h to accommodate the defines.
> >  - Add error checking for .sfr_regmap.
> >  - Remove unnecessary regmap_read() statement.
> >
> >  .../devicetree/bindings/usb/atmel-usb.txt  |  6 +-
> >  drivers/usb/host/ohci-at91.c   | 80 
> > +-
> >  include/soc/at91/at91_sfr.h| 29 
> >  3 files changed, 112 insertions(+), 3 deletions(-)  create mode
> > 100644 include/soc/at91/at91_sfr.h
> >
> > diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > b/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > index 5883b73..888deaa 100644
> > --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > @@ -3,8 +3,10 @@ Atmel SOC USB controllers  OHCI
> >
> >  Required properties:
> > - - compatible: Should be "atmel,at91rm9200-ohci" for USB controllers
> > -   used in host mode.
> > + - compatible: Should be one of the following
> > +  "atmel,at91rm9200-ohci" for USB controllers used in host mode.
> > +  "atmel,sama5d2-ohci" for USB controllers used in host mode
> > +  on SAMA5D2 which can force to suspend.
> 
> Guess I wasn't clear enough before. Drop "which can force to suspend".

In previous mail, Nicolas gave a suggestion with "...on SAMA5D2 and compatible 
SoCs that must explicitly force suspend through the Special Function Register 
(SFR)."

I think it is more clear, what is your opinion?

> 
> >   - reg: Address and length of the register set for the device
> >   - interrupts: Should contain ehci interrupt
> >   - clocks: Should reference the peripheral, host and system clocks
> > diff --git a/drivers/usb/host/ohci-at91.c
> > b/drivers/usb/host/ohci-at91.c index d177372..54e8feb 100644
> > --- a/drivers/usb/host/ohci-at91.c
> > +++ b/drivers/usb/host/ohci-at91.c
> > @@ -21,8 +21,11 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "ohci.h"
> >
> > @@ -45,12 +48,18 @@ struct at91_usbh_data {
> > u8 overcurrent_changed[AT91_MAX_USBH_PORTS];
> >  };
> >
> > +struct ohci_at91_caps {
> > +   bool suspend_ctrl;
> > +};
> > +
> >  struct ohci_at91_priv {
> > struct clk *iclk;
> > struct clk *fclk;
> > struct clk *hclk;
> > bool clocked;
> > bool wakeup;/* Saved wake-up state for resume */
> > +   const struct ohci_at91_caps *caps;
> > +   struct regmap *sfr_regmap;
> >  };
> >  /* interface and function clocks; sometimes also an AHB clock */
> >
> > @@ -132,6 +141,17 @@ static void at91_stop_hc(struct platform_device
> > *pdev)
> >
> >
> > /*
> > -*/
> >
> > +struct regmap *at91_dt_syscon_sfr(void) {
> > +   struct regmap *regmap;
> > +
> > +   regmap = syscon_regmap_lookup_by_compatible("atmel,sama5d2-sfr");
> > +   if (IS_ERR(regmap))
> > +   regmap = NULL;
> > +
> > +   return regmap;
> > +}
> > +
> >  static void usb_hcd_at91_remove (struct usb_hcd *, struct
> > platform_device *);
> >
> >  /* configure so an HC device and id

RE: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

[Yang, Wenyou]

Hi Aleandre,

> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: 2016年6月17日 21:55
> To: Yang, Wenyou 
> Cc: Rob Herring ; Alan Stern ;
> Greg Kroah-Hartman ; Ferre, Nicolas
> ; Pawel Moll ; Mark Brown
> ; Ian Campbell ; Kumar
> Gala ; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> u...@vger.kernel.org
> Subject: Re: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB
> suspend
> 
> On 17/06/2016 at 13:44:22 +, Yang, Wenyou wrote :
> > Hi Alexandre,
> >
> > > -Original Message-
> > > From: Alexandre Belloni
> > > [mailto:alexandre.bell...@free-electrons.com]
> > > Sent: 2016年6月9日 4:38
> > > To: Rob Herring 
> > > Cc: Yang, Wenyou ; Alan Stern
> > > ; Greg Kroah-Hartman
> > > ; Ferre, Nicolas
> > > ; Pawel Moll ; Mark
> > > Brown ; Ian Campbell
> > > ; Kumar Gala ;
> > > linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> > > ker...@lists.infradead.org; linux-...@vger.kernel.org
> > > Subject: Re: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports
> > > while USB suspend
> > >
> > > On 08/06/2016 at 15:26:51 -0500, Rob Herring wrote :
> > > > On Wed, Jun 08, 2016 at 12:15:10PM +0800, Wenyou Yang wrote:
> > > > > In order to the save power consumption, as a workaround, suspend
> > > > > forcibly the USB PORTA/B/C via set the SUSPEND_A/B/C bits of
> > > > > OHCI Interrupt Configuration Register in the SFRs while OHCI USB
> suspend.
> > > > >
> > > > > This suspend operation must be done before the USB clock is
> > > > > disabled, resume after the USB clock is enabled.
> > > > >
> > > > > Signed-off-by: Wenyou Yang 
> > > > > ---
> > > > >
> > > > > Changes in v3:
> > > > >  - Change the compatible description for more precise.
> > > > >
> > > > > Changes in v2:
> > > > >  - Add compatible to support forcibly suspend the ports.
> > > > >  - Add soc/at91/at91_sfr.h to accommodate the defines.
> > > > >  - Add error checking for .sfr_regmap.
> > > > >  - Remove unnecessary regmap_read() statement.
> > > > >
> > > > >  .../devicetree/bindings/usb/atmel-usb.txt  |  6 +-
> > > > >  drivers/usb/host/ohci-at91.c   | 80
> +-
> > > > >  include/soc/at91/at91_sfr.h| 29 
> > > > >  3 files changed, 112 insertions(+), 3 deletions(-)  create mode
> > > > > 100644 include/soc/at91/at91_sfr.h
> > > > >
> > > > > diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > > > > b/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > > > > index 5883b73..888deaa 100644
> > > > > --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > > > > +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > > > > @@ -3,8 +3,10 @@ Atmel SOC USB controllers  OHCI
> > > > >
> > > > >  Required properties:
> > > > > - - compatible: Should be "atmel,at91rm9200-ohci" for USB controllers
> > > > > -   used in host mode.
> > > > > + - compatible: Should be one of the following
> > > > > +"atmel,at91rm9200-ohci" for USB controllers used in host
> mode.
> > > > > +"atmel,sama5d2-ohci" for USB controllers used in host 
> > > > > mode
> > > > > +on SAMA5D2 which can force to suspend.
> > > >
> > > > Guess I wasn't clear enough before. Drop "which can force to suspend".
> > > >
> > >
> > > Well, my point is that we don't need a new compatible anyway.
> >
> > Could you give some advice?.
> >
> 
> Sure, what I mean is that you can try to get the regmap for the SFR in every 
> case.
> Depending on whether you were able to get it, you can decide to call
> ohci_at91_port_suspend/resume or not (just test for sfr_regmap != NULL).

I don't think so. The SFR includes a lot of miscellaneous functions, more than 
this one.

> 
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering http://free-electrons.com


Best Regards,
Wenyou Yang

RE: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

[Yang, Wenyou]

Hi Alexandre,

> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: 2016年6月9日 4:38
> To: Rob Herring 
> Cc: Yang, Wenyou ; Alan Stern
> ; Greg Kroah-Hartman
> ; Ferre, Nicolas ;
> Pawel Moll ; Mark Brown ; Ian
> Campbell ; Kumar Gala ;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB
> suspend
> 
> On 08/06/2016 at 15:26:51 -0500, Rob Herring wrote :
> > On Wed, Jun 08, 2016 at 12:15:10PM +0800, Wenyou Yang wrote:
> > > In order to the save power consumption, as a workaround, suspend
> > > forcibly the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI
> > > Interrupt Configuration Register in the SFRs while OHCI USB suspend.
> > >
> > > This suspend operation must be done before the USB clock is
> > > disabled, resume after the USB clock is enabled.
> > >
> > > Signed-off-by: Wenyou Yang 
> > > ---
> > >
> > > Changes in v3:
> > >  - Change the compatible description for more precise.
> > >
> > > Changes in v2:
> > >  - Add compatible to support forcibly suspend the ports.
> > >  - Add soc/at91/at91_sfr.h to accommodate the defines.
> > >  - Add error checking for .sfr_regmap.
> > >  - Remove unnecessary regmap_read() statement.
> > >
> > >  .../devicetree/bindings/usb/atmel-usb.txt  |  6 +-
> > >  drivers/usb/host/ohci-at91.c   | 80 
> > > +-
> > >  include/soc/at91/at91_sfr.h| 29 
> > >  3 files changed, 112 insertions(+), 3 deletions(-)  create mode
> > > 100644 include/soc/at91/at91_sfr.h
> > >
> > > diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > > b/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > > index 5883b73..888deaa 100644
> > > --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > > +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > > @@ -3,8 +3,10 @@ Atmel SOC USB controllers  OHCI
> > >
> > >  Required properties:
> > > - - compatible: Should be "atmel,at91rm9200-ohci" for USB controllers
> > > -   used in host mode.
> > > + - compatible: Should be one of the following
> > > +"atmel,at91rm9200-ohci" for USB controllers used in host mode.
> > > +"atmel,sama5d2-ohci" for USB controllers used in host mode
> > > +on SAMA5D2 which can force to suspend.
> >
> > Guess I wasn't clear enough before. Drop "which can force to suspend".
> >
> 
> Well, my point is that we don't need a new compatible anyway.

Could you give some advice?.

> 
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering http://free-electrons.com


Best Regards,
Wenyou Yang

RE: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

[Yang, Wenyou]

Hi Alan, 

> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: 2016年6月9日 3:14
> To: Yang, Wenyou 
> Cc: Greg Kroah-Hartman ; Ferre, Nicolas
> ; Rob Herring ; Pawel Moll
> ; Mark Brown ; Ian Campbell
> ; Kumar Gala ;
> Alexandre Belloni ; Kernel development
> list ; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; USB list 
> Subject: Re: [PATCH v3 1/2] usb: ohci-at91: Forcibly suspend ports while USB
> suspend
> 
> On Wed, 8 Jun 2016, Wenyou Yang wrote:
> 
> > In order to the save power consumption, as a workaround, suspend
> > forcibly the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI
> > Interrupt Configuration Register in the SFRs while OHCI USB suspend.
> >
> > This suspend operation must be done before the USB clock is disabled,
> > resume after the USB clock is enabled.
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> 
> You never answered the questions I posted for the first version of this
> patch:
> 
> What does this mean?  What does suspending a port do?  Is it the same as a
> normal USB port suspend?
> 
> If it is the same, why doesn't the USB_PORT_FEAT_SUSPEND subcase of the
> SetPortFeature case in ohci_hub_control() already take care of this?

I remembered I answered your questions, 
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-May/429245.html

Maybe not very clear.

> 
> Alan Stern


Best Regards,
Wenyou Yang

RE: [PATCH v2 1/2] usb: ohci-at91: Forcibly suspend ports while USB suspend

[Yang, Wenyou]

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: 2016年6月3日 9:54
> To: Yang, Wenyou 
> Cc: Alan Stern ; Greg Kroah-Hartman
> ; Ferre, Nicolas ;
> Pawel Moll ; Mark Brown ; Ian
> Campbell ; Kumar Gala ;
> Alexandre Belloni ; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH v2 1/2] usb: ohci-at91: Forcibly suspend ports while USB
> suspend
> 
> On Wed, Jun 01, 2016 at 12:29:59PM +0800, Wenyou Yang wrote:
> > In order to the save power consumption, as a workaround, suspend
> > forcibly the USB PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI
> > Interrupt Configuration Register in the SFRs while OHCI USB suspend.
> >
> > This suspend operation must be done before the USB clock is disabled,
> > resume after the USB clock is enabled.
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> >
> > Changes in v2:
> >  - Add compatible to support forcibly suspend the ports.
> >  - Add soc/at91/at91_sfr.h to accommodate the defines.
> >  - Add error checking for .sfr_regmap.
> >  - Remove unnecessary regmap_read() statement.
> >
> >  .../devicetree/bindings/usb/atmel-usb.txt  |  5 +-
> >  drivers/usb/host/ohci-at91.c   | 80 
> > +-
> >  include/soc/at91/at91_sfr.h| 29 
> >  3 files changed, 111 insertions(+), 3 deletions(-)  create mode
> > 100644 include/soc/at91/at91_sfr.h
> >
> > diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > b/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > index 5883b73..3e3e58a 100644
> > --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
> > @@ -3,8 +3,9 @@ Atmel SOC USB controllers  OHCI
> >
> >  Required properties:
> > - - compatible: Should be "atmel,at91rm9200-ohci" for USB controllers
> > -   used in host mode.
> > + - compatible: Should be one of the following
> > +  "atmel,at91rm9200-ohci" for USB controllers used in host mode.
> > +  "atmel,sama5d2-ohci" for SAMA5D2 which can force to suspend.
> 
> That may be why you need this now, but that is irrelevant to having a chip 
> specific
> compatible string.

Maybe a property is better.


Best Regards,
Wenyou Yang

RE: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

[Yang, Wenyou]

Hi Alan,

> -Original Message-
> From: Alan Stern [mailto:st...@rowland.harvard.edu]
> Sent: 2016年5月13日 2:11
> To: Yang, Wenyou 
> Cc: Greg Kroah-Hartman ; Ferre, Nicolas
> ; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending
> 
> On Thu, 12 May 2016, Wenyou Yang wrote:
> 
> > In order to get lower consumption, as a workaround, suspend the USB
> > PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI Interrupt
> > Configuration Register while OHCI USB suspending.
> 
> What does this mean?  What does suspending a port do?  

It is a IP workaround for SAMA5D2 USB. By setting corresponding bits of a 
specific register to get lower consumption.  

> Is it the same as a normal USB port suspend?

No, it is not same.

> 
> If it is the same, why doesn't the USB_PORT_FEAT_SUSPEND subcase of the
> SetPortFeature case in ohci_hub_control() already take care of this?
> 
> > This suspend operation must be done before stopping the USB clock,
> > resume after the USB clock enabled.
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> 
> > @@ -132,6 +135,17 @@ static void at91_stop_hc(struct platform_device
> > *pdev)
> >
> >
> > /*
> > -*/
> >
> > +struct regmap *at91_dt_syscon_sfr(void) {
> > +   struct regmap *regmap;
> > +
> > +   regmap = syscon_regmap_lookup_by_compatible("atmel,sama5d2-sfr");
> > +   if (IS_ERR(regmap))
> > +   return NULL;
> 
> If you get an error, the regmap pointer is set to NULL...
> 
> > @@ -197,6 +211,8 @@ static int usb_hcd_at91_probe(const struct hc_driver
> *driver,
> > goto err;
> > }
> >
> > +   ohci_at91->sfr_regmap = at91_dt_syscon_sfr();
> 
> With no other error checking...

Add error checking in next version.

> 
> > +
> > board = hcd->self.controller->platform_data;
> > ohci = hcd_to_ohci(hcd);
> > ohci->num_ports = board->ports;
> 
> > +static int ohci_at91_port_ctrl(struct regmap *regmap, bool enable) {
> > +   u32 regval;
> > +   int ret;
> > +
> > +   if (IS_ERR(regmap))
> > +   return PTR_ERR(regmap);
> > +
> > +   ret = regmap_read(regmap, SFR_OHCIICR, ®val);
> 
> And now what happens if regmap is NULL?  Hint: It won't be pretty...

Yes, it is not pretty. Will rework in next version.

> 
> Alan Stern


Best Regards,
Wenyou Yang

RE: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending

[Yang, Wenyou]

> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: 2016年5月12日 11:53
> To: Yang, Wenyou 
> Cc: Alan Stern ; Greg Kroah-Hartman
> ; Ferre, Nicolas ;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH] usb: ohci-at91: Suspend the ports while USB suspending
> 
> Hi,
> 
> On 12/05/2016 at 09:05:34 +0800, Wenyou Yang wrote :
> > In order to get lower consumption, as a workaround, suspend the USB
> > PORTA/B/C via set the SUSPEND_A/B/C bits of OHCI Interrupt
> > Configuration Register while OHCI USB suspending.
> >
> 
> Why is that a workaround?

Because if these bits is not set as this patch, there is 5mA current left
at VDDOSC rail during suspend. If apply this patch, this current will disappear.

So, I think it is a workaround.

> 
> > This suspend operation must be done before stopping the USB clock,
> > resume after the USB clock enabled.
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> >
> >  drivers/usb/host/ohci-at91.c | 63
> > 
> >  1 file changed, 63 insertions(+)
> >
> > diff --git a/drivers/usb/host/ohci-at91.c
> > b/drivers/usb/host/ohci-at91.c index d177372..ce898e0 100644
> > --- a/drivers/usb/host/ohci-at91.c
> > +++ b/drivers/usb/host/ohci-at91.c
> > @@ -21,6 +21,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> >
> > @@ -51,6 +53,7 @@ struct ohci_at91_priv {
> > struct clk *hclk;
> > bool clocked;
> > bool wakeup;/* Saved wake-up state for resume */
> > +   struct regmap *sfr_regmap;
> >  };
> >  /* interface and function clocks; sometimes also an AHB clock */
> >
> > @@ -132,6 +135,17 @@ static void at91_stop_hc(struct platform_device
> > *pdev)
> >
> >
> > /*
> > -*/
> >
> > +struct regmap *at91_dt_syscon_sfr(void) {
> > +   struct regmap *regmap;
> > +
> > +   regmap = syscon_regmap_lookup_by_compatible("atmel,sama5d2-sfr");
> > +   if (IS_ERR(regmap))
> > +   return NULL;
> > +
> > +   return regmap;
> > +}
> > +
> >  static void usb_hcd_at91_remove (struct usb_hcd *, struct
> > platform_device *);
> >
> >  /* configure so an HC device and id are always provided */ @@ -197,6
> > +211,8 @@ static int usb_hcd_at91_probe(const struct hc_driver *driver,
> > goto err;
> > }
> >
> > +   ohci_at91->sfr_regmap = at91_dt_syscon_sfr();
> > +
> > board = hcd->self.controller->platform_data;
> > ohci = hcd_to_ohci(hcd);
> > ohci->num_ports = board->ports;
> > @@ -581,6 +597,49 @@ static int ohci_hcd_at91_drv_remove(struct
> platform_device *pdev)
> > return 0;
> >  }
> >
> > +#define SFR_OHCIICR0x10
> > +#define SFR_OHCIICR_SUSPEND_A  BIT(8)
> > +#define SFR_OHCIICR_SUSPEND_B  BIT(9)
> > +#define SFR_OHCIICR_SUSPEND_C  BIT(10)
> > +
> > +#define SFR_OHCIICR_USB_SUSPEND(SFR_OHCIICR_SUSPEND_A | \
> > +SFR_OHCIICR_SUSPEND_B | \
> > +SFR_OHCIICR_SUSPEND_C)
> > +
> 
> Those defines should go in a header file either in include/soc/at91 or in
> include/linux/mfd
> 
> > +static int ohci_at91_port_ctrl(struct regmap *regmap, bool enable) {
> > +   u32 regval;
> > +   int ret;
> > +
> > +   if (IS_ERR(regmap))
> > +   return PTR_ERR(regmap);
> > +
> > +   ret = regmap_read(regmap, SFR_OHCIICR, ®val);
> > +   if (ret)
> > +   return ret;
> > +
> > +   if (enable)
> > +   regval &= ~SFR_OHCIICR_USB_SUSPEND;
> > +   else
> > +   regval |= SFR_OHCIICR_USB_SUSPEND;
> > +
> > +   regmap_write(regmap, SFR_OHCIICR, regval);
> > +
> > +   regmap_read(regmap, SFR_OHCIICR, ®val);
> > +
> > +   return 0;
> > +}
> > +
> > +static int ohci_at91_port_suspend(struct regmap *regmap) {
> > +   return ohci_at91_port_ctrl(regmap, false); }
> > +
> > +static int ohci_at91_port_resume(struct regmap *regmap) {
> > +   return ohci_at91_port_ctrl(regmap, true); }
> > +
> >  static int __maybe_unused
> >  ohci_hcd_at91_drv_suspend(struct device *dev)  { @@ -618,6 +677,8 @@
> > ohci_hcd_at91_drv_suspend(struct device *dev)
> > ohci_writel(ohci, ohci->hc_control, &ohci->regs->control);
> > ohci->rh_state = OHCI_RH_HALTED;
> >
> > +   ohci_at91_port_suspend(ohci_at91->sfr_regmap);
> > +
> 
> The main issue I see here is that you will call that function for all SoCs 
> and it will
> always fail unless it is running on a sama5d2. Maybe we could be smarter about
> that.

Can we use another compatible, such as "atmel,sama5d2-ohci" to differentiate 
it? 


Best Regards,
Wenyou Yang

RE: [PATCH 1/2] Revert "mtd: atmel_nand: Support variable RB_EDGE interrupts"

[Yang, Wenyou]

> -Original Message-
> From: Boris Brezillon [mailto:boris.brezil...@free-electrons.com]
> Sent: 2016年5月10日 16:56
> To: Yang, Wenyou ; Romain Izard
> 
> Cc: Brian Norris ; David Woodhouse
> ; Rob Herring ; Pawel Moll
> ; Mark Brown ; Ian Campbell
> ; Kumar Gala ;
> devicet...@vger.kernel.org; Russell King ; Josh Wu
> ; Ferre, Nicolas ;
> linux-kernel@vger.kernel.org; Alexandre Belloni  electrons.com>; linux-...@lists.infradead.org; Jean-Christophe 
> Plagniol-Villard
> ; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 1/2] Revert "mtd: atmel_nand: Support variable RB_EDGE
> interrupts"
> 
> Hi Wenyou,
> 
> Can you add NAND maintainers/reviewers in Cc next time. And since you revert a
> commit, you should also add the commit author in the loop.
> 
> On Mon, 9 May 2016 14:51:18 +0800
> Wenyou Yang  wrote:
> 
> > This reverts commit 5ddc7bd43ccc ("mtd: atmel_nand: Support variable
> > RB_EDGE interrupts")
> >
> > Because for current SoCs, the RB_EDGE3(i.e. bit 27) of HSMC_SR
> > register does not exist, the RB_EDGE0 (i.e. bit 24) is the ready/busy
> > line edge status bit. It is a datasheet bug.
> 
> Romain, I thought you had a real use case on sama5d4 where this patch was
> needed to make the whole thing work. Not sure why you submitted this patch if
> you couldn't test it on a real board.
> 
> Wenyou, can you confirm that none of the existing SoCs support more than one
> "native" R/B pin?

Yes, I confirmed. 

> 
> Thanks,
> 
> Boris
> 
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> >
> >  .../devicetree/bindings/mtd/atmel-nand.txt |  2 +-
> >  drivers/mtd/nand/atmel_nand.c  | 35 
> > +-
> >  drivers/mtd/nand/atmel_nand_nfc.h  |  3 +-
> >  3 files changed, 10 insertions(+), 30 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > index d53aba9..3e7ee99 100644
> > --- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > +++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > @@ -39,7 +39,7 @@ Optional properties:
> >
> >  Nand Flash Controller(NFC) is an optional sub-node  Required
> > properties:
> > -- compatible : "atmel,sama5d3-nfc" or "atmel,sama5d4-nfc".
> > +- compatible : "atmel,sama5d3-nfc".
> >  - reg : should specify the address and size used for NFC command registers,
> >  NFC registers and NFC SRAM. NFC SRAM address and size can be
> absent
> >  if don't want to use it.
> > diff --git a/drivers/mtd/nand/atmel_nand.c
> > b/drivers/mtd/nand/atmel_nand.c index efc8ea2..68b9160 100644
> > --- a/drivers/mtd/nand/atmel_nand.c
> > +++ b/drivers/mtd/nand/atmel_nand.c
> > @@ -67,10 +67,6 @@ struct atmel_nand_caps {
> > uint8_t pmecc_max_correction;
> >  };
> >
> > -struct atmel_nand_nfc_caps {
> > -   uint32_t rb_mask;
> > -};
> > -
> >  /*
> >   * oob layout for large page size
> >   * bad block info is on bytes 0 and 1 @@ -129,7 +125,6 @@ struct
> > atmel_nfc {
> > /* Point to the sram bank which include readed data via NFC */
> > void*data_in_sram;
> > boolwill_write_sram;
> > -   const struct atmel_nand_nfc_caps *caps;
> >  };
> >  static struct atmel_nfcnand_nfc;
> >
> > @@ -1715,9 +1710,9 @@ static irqreturn_t hsmc_interrupt(int irq, void 
> > *dev_id)
> > nfc_writel(host->nfc->hsmc_regs, IDR, NFC_SR_XFR_DONE);
> > ret = IRQ_HANDLED;
> > }
> > -   if (pending & host->nfc->caps->rb_mask) {
> > +   if (pending & NFC_SR_RB_EDGE) {
> > complete(&host->nfc->comp_ready);
> > -   nfc_writel(host->nfc->hsmc_regs, IDR, host->nfc->caps-
> >rb_mask);
> > +   nfc_writel(host->nfc->hsmc_regs, IDR, NFC_SR_RB_EDGE);
> > ret = IRQ_HANDLED;
> > }
> > if (pending & NFC_SR_CMD_DONE) {
> > @@ -1735,7 +1730,7 @@ static void nfc_prepare_interrupt(struct
> atmel_nand_host *host, u32 flag)
> > if (flag & NFC_SR_XFR_DONE)
> > init_completion(&host->nfc->comp_xfer_done);
> >
> > -   if (flag & host->nfc->caps->rb_mask)
> > +   if (flag & NFC_SR_RB_EDGE)
> > init_completion(&host->nfc->comp_ready);
> >
> > if (flag & NFC_S

RE: [PATCH 0/2] mtd: atmel_nand: remove compatible "atmel,sama5d4-nfc"

[Yang, Wenyou]

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: 2016年5月10日 4:13
> To: Yang, Wenyou 
> Cc: Brian Norris ; David Woodhouse
> ; Pawel Moll ; Mark Brown
> ; Ian Campbell ; Kumar
> Gala ; linux-kernel@vger.kernel.org; linux-
> m...@lists.infradead.org; devicet...@vger.kernel.org; Ferre, Nicolas
> ; Alexandre Belloni  electrons.com>; Jean-Christophe Plagniol-Villard ;
> Russell King ; Josh Wu ;
> linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 0/2] mtd: atmel_nand: remove compatible "atmel,sama5d4-
> nfc"
> 
> On Mon, May 09, 2016 at 02:51:17PM +0800, Wenyou Yang wrote:
> > It is a datasheet bug, for current SoCs, the RB_EDGE3(i.e. bit 27) of
> > HSMC_SR register does not exist, the RB_EDGE0 (i.e. bit 24) is the
> > ready/busy line edge status bit. So the compatible "atmel,sama5d4-nfc"
> > is unneeded.
> 
> The compatible is needed if the SOC still exists. You can list both for the 
> sama5d4
> if the block is the same.

The NFC IP of SAMA5D4 is same as SAMA5D2's, SAMA5D4 hase this issue.  This 
compatible can be removed. 


Best Regards,
Wenyou Yang

RE: [PATCH v5 3/5] ARM: at91: pm: configure PMC fast startup signals

[Yang, Wenyou]

Hi Alexandre,

> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: 2016年3月24日 19:25
> To: Yang, Wenyou 
> Cc: Ferre, Nicolas ; Jean-Christophe Plagniol-
> Villard ; Russell King ; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-...@vger.kernel.org; Rob Herring
> ; Pawel Moll ; Mark Brown
> ; Ian Campbell ; Kumar
> Gala 
> Subject: Re: [PATCH v5 3/5] ARM: at91: pm: configure PMC fast startup signals
> 
> On 21/03/2016 at 02:24:32 +, Yang, Wenyou wrote :
> > Hi Alexandre,
> >
> > > -Original Message-
> > > From: Alexandre Belloni
> > > [mailto:alexandre.bell...@free-electrons.com]
> > > Sent: 2016年3月18日 1:15
> > > To: Yang, Wenyou 
> > > Cc: Ferre, Nicolas ; Jean-Christophe
> > > Plagniol- Villard ; Russell King
> > > ; linux- ker...@vger.kernel.org;
> > > devicet...@vger.kernel.org; linux-arm- ker...@lists.infradead.org;
> > > linux-...@vger.kernel.org; Rob Herring ; Pawel
> > > Moll ; Mark Brown ; Ian
> > > Campbell ; Kumar Gala
> > > 
> > > Subject: Re: [PATCH v5 3/5] ARM: at91: pm: configure PMC fast
> > > startup signals
> > >
> > > On 16/03/2016 at 14:58:07 +0800, Wenyou Yang wrote :
> > > > The fast startup signal is used as wake up sources for ULP1 mode.
> > > > As soon as a fast startup signal is asserted, the embedded 12 MHz
> > > > RC oscillator restarts automatically.
> > > >
> > > > This patch is to configure the fast startup signals, which signal
> > > > is enabled to trigger the PMC to wake up the system from ULP1 mode
> > > > should be configured via the DT.
> > > >
> > > > Signed-off-by: Wenyou Yang 
> > >
> > > I would actually avoid doing that from the PMC driver and do that
> > > configuration from the aic5 driver. It has all the information you
> > > need, it knows what kind of level or edge is needed to wake up and
> > > what are the wakeup interrupts to enable. This will allow you to
> > > stop introducing a new binding. Also, this will avoid discrepancies
> > > between what is configured in the DT and what the user really wants
> > > (for exemple differences between the edge direction configured for the 
> > > PIOBu
> in userspace versus what is in the device tree or wakeonlan
> activation/deactivation).
> >
> > Thank you for your feedback.
> >
> > But some wake-ups such as WKUP pin, ACC_CE, RXLP_MCE, don't have the
> > corresponding
> 
> The WKUP pin can be configured from the shdwc driver, ACC_CE from the ACC
> driver, RXLP_MCE, from the RXLP driver because you will need drivers for those
> at some point anyway.
> 
> > interrupt number. Moreover, I think, the ULP1 is very different form
> > the ULP0, it is not woken up by the interrupt. It is fallen sleep and woken 
> > up by
> the some mechanism in the PMC.
> >
> 
> Well, we don't really care about the mechanism. We only care about how the 
> user
> is able to configure the wakeup sources.

Understand your concerns.

> 
> With your patch set, what happens when no ULP1 sources are defined but there
> are ULP0 sources? What happens when there are both ULP1 and ULP0 sources?

I think there is only one mode, either ULP1 or ULP0, in a runtime system.
The ULP1 sources are used to wake up the ULP1, and the ULP0 sources wake up the 
ULP0,
they don't mutually effect each other.

If system is in the ULP1 mode, and there are no ULP1 sources defined, the 
system will fail to
be waken up, even though there are ULP0 sources defined. The ULP0 source can't 
wake up the ULP1.

> 
> What would be good is to use ULP1 when only ULP1 sources are set up and
> ULP0 in the other cases. This will greatly help the user. Also, what I'm 
> suggesting
> actually allows to change the ULP1 sources at runtime from devices that are
> actually used which is quite better than setting them up statically from DT.
> 

In the ULP1 mode, all clocks are disabled. It can get lower consumption and
quicker wake up (the processor restarts in less than 10us) than ULP0 mode.

The number of wake up sources is limited as well. It is very different from 
ULP0's


Hi Nicolas, what is your opinions?


Best Regards,
Wenyou Yang

RE: [PATCH v5 3/5] ARM: at91: pm: configure PMC fast startup signals

[Yang, Wenyou]

Hi Alexandre,

> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: 2016年3月18日 1:15
> To: Yang, Wenyou 
> Cc: Ferre, Nicolas ; Jean-Christophe Plagniol-
> Villard ; Russell King ; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-...@vger.kernel.org; Rob Herring
> ; Pawel Moll ; Mark Brown
> ; Ian Campbell ; Kumar
> Gala 
> Subject: Re: [PATCH v5 3/5] ARM: at91: pm: configure PMC fast startup signals
> 
> On 16/03/2016 at 14:58:07 +0800, Wenyou Yang wrote :
> > The fast startup signal is used as wake up sources for ULP1 mode.
> > As soon as a fast startup signal is asserted, the embedded 12 MHz RC
> > oscillator restarts automatically.
> >
> > This patch is to configure the fast startup signals, which signal is
> > enabled to trigger the PMC to wake up the system from ULP1 mode should
> > be configured via the DT.
> >
> > Signed-off-by: Wenyou Yang 
> 
> I would actually avoid doing that from the PMC driver and do that 
> configuration
> from the aic5 driver. It has all the information you need, it knows what kind 
> of level
> or edge is needed to wake up and what are the wakeup interrupts to enable. 
> This
> will allow you to stop introducing a new binding. Also, this will avoid 
> discrepancies
> between what is configured in the DT and what the user really wants (for 
> exemple
> differences between the edge direction configured for the PIOBu in userspace
> versus what is in the device tree or wakeonlan activation/deactivation).

Thank you for your feedback.

But some wake-ups such as WKUP pin, ACC_CE, RXLP_MCE, don't have the 
corresponding
interrupt number. Moreover, I think, the ULP1 is very different form the ULP0, 
it is not woken
up by the interrupt. It is fallen sleep and woken up by the some mechanism in 
the PMC. 

Maybe I was wrong. I still think the aic5 driver should be devoted on the 
AIC5's behaviors. 

> 
> You can get the PMC syscon from irq-atmel-aic5.c and then use a table to map
> the hwirq to the offset in PMC_FSMR. Use it in aic5_set_type to set the 
> polarity
> and then in aic5_suspend to enable the wakeup.
> 
> Maybe we could even go further and avoid ulp1 if no ulp1 compatbile wakeup
> sources are defined but there are ulp0 wakeup sources.
> 
> 
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering http://free-electrons.com


Best Regards,
Wenyou Yang

RE: [PATCH 2/2] mfd: add documentation for ACT8945A DT bindings

[Yang, Wenyou]

Hi,

> -Original Message-
> From: kbuild test robot [mailto:l...@intel.com]
> Sent: 2016年3月8日 11:04
> To: Yang, Wenyou 
> Cc: kbuild-...@01.org; Lee Jones ; Rob Herring
> ; Pawel Moll ; Mark Rutland
> ; Ian Campbell ; Kumar
> Gala ; Ferre, Nicolas ;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; Yang, Wenyou
> 
> Subject: Re: [PATCH 2/2] mfd: add documentation for ACT8945A DT bindings
> 
> Hi Wenyou,
> 
> [auto build test ERROR on v4.4-rc8]
> [cannot apply to next-20160307]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improving the system]
> 
> url:https://github.com/0day-ci/linux/commits/Wenyou-Yang/mfd-act8945a-add-
> Active-semi-ACT8945A-PMIC-MFD-driver/20160108-100943

This is not the latest version, please use 
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/405258.html

> config: x86_64-allmodconfig (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
> 

It works using the commands as below.

$ make mrproper
$ export ARCH=x86_64
$ export CROSS_COMPILE=
$ make allmodconfig
$ make


> All errors (new ones prefixed by >>):
> 
>drivers/built-in.o: In function `act8945a_i2c_probe':
> >> act8945a.c:(.text+0x22bb26): undefined reference to 
> >> `__devm_regmap_init_i2c'
>drivers/built-in.o: In function `act8945a_i2c_init':
> >> act8945a.c:(.init.text+0x1a57a): undefined reference to 
> >> `i2c_register_driver'
>drivers/built-in.o: In function `act8945a_i2c_exit':
> >> act8945a.c:(.exit.text+0x68f): undefined reference to `i2c_del_driver'
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation


Best Regards,
Wenyou Yang

RE: [PATCH] mfd: act8945a: fix platform_no_drv_owner.cocci warnings

[Yang, Wenyou]

Hi Fengguang Wu,

Thank you for your patch.

> -Original Message-
> From: kbuild test robot [mailto:l...@intel.com]
> Sent: 2016年3月8日 7:54
> To: Yang, Wenyou 
> Cc: kbuild-...@01.org; Lee Jones ; Rob Herring
> ; Pawel Moll ; Mark Rutland
> ; Ian Campbell ; Kumar
> Gala ; Ferre, Nicolas ;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; Yang, Wenyou
> 
> Subject: [PATCH] mfd: act8945a: fix platform_no_drv_owner.cocci warnings
> 
> drivers/mfd/act8945a.c:100:6-11: No need to set .owner here. The core will do 
> it.
> 
>  Remove .owner field if calls are used which set it automatically
> 
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
> 
> CC: Wenyou Yang 
> Signed-off-by: Fengguang Wu 

Reviewed-by: Wenyou Yang 

> ---
> 
>  act8945a.c |1 -
>  1 file changed, 1 deletion(-)
> 
> --- a/drivers/mfd/act8945a.c
> +++ b/drivers/mfd/act8945a.c
> @@ -97,7 +97,6 @@ MODULE_DEVICE_TABLE(of, act8945a_of_matc  static
> struct i2c_driver act8945a_i2c_driver = {
>   .driver = {
>  .name = "act8945a",
> -.owner = THIS_MODULE,
>  .of_match_table = of_match_ptr(act8945a_of_match),
>   },
>   .probe = act8945a_i2c_probe,


Best Regards,
Wenyou Yang

Re: [PATCH v1] watchdog: sama5d4_wdt: Reset delay on start

[Yang, Wenyou]

Hi Romain,

On 2016/3/3 18:29, Romain Izard wrote:

If the internal counter is not refreshed when the watchdog is started
for the first time, the watchdog will trigger very rapidly. For example,
opening /dev/watchdog without writing in it will immediately trigger a
reboot, instead of waiting for the delay to expire.

To avoid this problem, reload the timer on opening the watchdog device.

Command: "while sleep 5; do echo 1; done > /dev/watchdog"
Before: system reset
After: the watchdog runs correctly

I didn't reproduce your issue on my side,

run the your commands as follows, it works fine,  the system reset 
doesn't happen.

---8<
#!/bin/sh

while [ 1 ]
do
sleep 5;
echo 1 > /dev/watchdog
done
--->8

I also check the WDT_MR register before and after enabling watchdog, the 
WDV and WDD fields are correct.


Can you check it again? thank you.



Signed-off-by: Romain Izard 
---
  drivers/watchdog/sama5d4_wdt.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/watchdog/sama5d4_wdt.c b/drivers/watchdog/sama5d4_wdt.c
index a49634cdc1cc..e162fe140ae1 100644
--- a/drivers/watchdog/sama5d4_wdt.c
+++ b/drivers/watchdog/sama5d4_wdt.c
@@ -15,6 +15,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "at91sam9_wdt.h"
  
@@ -58,6 +59,8 @@ static int sama5d4_wdt_start(struct watchdog_device *wdd)

reg = wdt_read(wdt, AT91_WDT_MR);
reg &= ~AT91_WDT_WDDIS;
wdt_write(wdt, AT91_WDT_MR, reg);
+   udelay(125); /* > 4 cycles at 32,768 Hz */
+   wdt_write(wdt, AT91_WDT_CR, AT91_WDT_KEY | AT91_WDT_WDRSTT);
  
  	return 0;

  }


Best Regards,
Wenyou Yang

RE: [PATCH v9 0/2] power: act8945a: add charger driver for the sub-device of ACT8945A MFD

[Yang, Wenyou]

Hello Sebastian,

> -Original Message-
> From: Wenyou Yang [mailto:wenyou.y...@atmel.com]
> Sent: 2016年2月15日 16:22
> To: Sebastian Reichel ; Dmitry Eremin-Solenikov
> ; David Woodhouse ; Rob
> Herring ; Pawel Moll ; Mark Brown
> ; Ian Campbell ; Kumar
> Gala 
> Cc: Krzysztof Kozlowski ; Javier Martinez Canillas
> ; Lee Jones ; Peter Korsgaard
> ; Ferre, Nicolas ; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> p...@vger.kernel.org; Yang, Wenyou 
> Subject: [PATCH v9 0/2] power: act8945a: add charger driver for the sub-device
> of ACT8945A MFD
> 
> The ACT8945A is a Multi Function Device with the following subdevices:
>  - Regulator
>  - Charger

I would like to know if this patch set is okay to apply.  Or any comments?

Thanks.

> 
> This patch set is to add regulator driver for ACT8945A.
> It is based on the patch set:
>   http://lists.infradead.org/pipermail/linux-arm-kernel/2016-
> February/405258.html
> 
> Changes in v9:
>  - add check if charger->regmap is a NULL pointer.
>  - collect Reviewed-by tag.
> 
> Changes in v8:
>  - remove the OF table.
>  - due to the mfd cell .of_compatible removal, use the platform
>device's parent of_node to read the property and assign it
>to the psy_cfg.of_node.
>  - fix the typo.
>  - due the mfd cell .of_compatible removal, update the compatibe
>description and example.
> 
> Changes in v7:
>  - use the helper dev_get_regmap(pdev->dev.parent, NULL) to get regmap.
>  - remove *act8945a_dev member from struct act8945a_charger.
>  - remove *psy member from struct act8945a_charger.
>  - merge _parse_dt() and _charger_config() functions, remove relevent
>members from struct act8945a_charger.
>  - remove unused platform_set_drvdata(pdev, charger) statement.
> 
> Changes in v6:
>  - change the type value to unsigned int.
> 
> Changes in v5:
>  - remove spare spaces after #define.
>  - add OF match table.
>  - collect Reviewed-by from Krzysztof.
> 
> Changes in v4:
>  - use spaces after #define, not tabs.
>  - use BIT(n) macros to substitute (0x01 << x).
>  - change dt properties with more legible name.
>  - change the properties with more legible name, clearer description.
> 
> Changes in v3:
>  - update the file header with short version license and author line.
>  - remove unused member of struct act8945a_charger, dev.
>  - action due to removing the member of stuct act8945a_dev, dev.
>  - remove the unnecessary print out.
>  - remove the unnecessary act8945a_charger_remove().
>  - fix align of the code-style.
> 
> Changes in v2:
>  1./ Substitute of_property_read_bool() for of_get_property().
>  2./ Substitute devm_power_supply_register() for power_supply_register().
>  3./ Use module_platform_driver(), instead of subsys_initcall().
>  4./ Substitute MODULE_LICENSE("GPL") for MODULE_LICENSE("GPL v2").
> 
> Wenyou Yang (2):
>   power: act8945a: add charger driver for ACT8945A
>   power: add documentation for ACT8945A's charger DT bindings
> 
>  .../devicetree/bindings/power/act8945a-charger.txt |   35 ++
>  drivers/power/Kconfig  |7 +
>  drivers/power/Makefile |1 +
>  drivers/power/act8945a_charger.c   |  359 
> 
>  4 files changed, 402 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/act8945a-
> charger.txt
>  create mode 100644 drivers/power/act8945a_charger.c
> 
> --
> 1.7.9.5


Best Regards,
Wenyou Yang

RE: [PATCH] ARM: at91: sama5/dts: move hsmc_clk out of nfc node

[Yang, Wenyou]

> -Original Message-
> From: Ferre, Nicolas
> Sent: 2016年2月22日 20:58
> To: Yang, Wenyou ; Rob Herring
> ; Pawel Moll ; Mark Brown
> ; Ian Campbell ; Kumar
> Gala ; Alexandre Belloni  electrons.com>; Jean-Christophe Plagniol-Villard ;
> Russell King 
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; Wu, Josh ; Josh Wu
> ; Alexandre Belloni  electrons.com>
> Subject: Re: [PATCH] ARM: at91: sama5/dts: move hsmc_clk out of nfc node
> 
> Le 17/02/2016 06:42, Wenyou Yang a écrit :
> > From: Josh Wu 
> >
> > In sama5d3, sama5d4 chips, pmecc will use the hsmc clock. As pmecc is
> > part of HSMC. So move out hsmc_clk from nfc node to nand node.
> >
> > Signed-off-by: Josh Wu 
> > Signed-off-by: Wenyou Yang 
> 
> I'm not against this change, but beware, it must be applied in 
> synchronization with
> the patch just posted "[PATCH] mtd: atmel_nand:
> move the hsmc_clk from nfc node to nand node"

Okay, revert the mail address to the original one, keep it consistent.

And add this address to CC. 

> 
> Bye,
> 
> 
> > ---
> >
> >  arch/arm/boot/dts/sama5d3.dtsi |2 +-
> >  arch/arm/boot/dts/sama5d4.dtsi |2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/sama5d3.dtsi
> > b/arch/arm/boot/dts/sama5d3.dtsi index a532791..a242d27 100644
> > --- a/arch/arm/boot/dts/sama5d3.dtsi
> > +++ b/arch/arm/boot/dts/sama5d3.dtsi
> > @@ -1474,6 +1474,7 @@
> > atmel,nand-has-dma;
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_nand0_ale_cle>;
> > +   clocks = <&hsmc_clk>;
> > atmel,pmecc-lookup-table-offset = <0x0 0x8000>;
> > status = "disabled";
> >
> > @@ -1486,7 +1487,6 @@
> > 0xc000 0x0070   /* NFC HSMC
> regs */
> > 0x0020 0x0010   /* NFC
> SRAM banks */
> > >;
> > -   clocks = <&hsmc_clk>;
> > };
> > };
> > };
> > diff --git a/arch/arm/boot/dts/sama5d4.dtsi
> > b/arch/arm/boot/dts/sama5d4.dtsi index b8032bc..1499b33 100644
> > --- a/arch/arm/boot/dts/sama5d4.dtsi
> > +++ b/arch/arm/boot/dts/sama5d4.dtsi
> > @@ -295,6 +295,7 @@
> > atmel,nand-has-dma;
> > pinctrl-names = "default";
> > pinctrl-0 = <&pinctrl_nand>;
> > +   clocks = <&hsmc_clk>;
> > status = "disabled";
> >
> > nfc@9000 {
> > @@ -306,7 +307,6 @@
> > 0xfc05c000 0x0070   /* NFC
> HSMC regs */
> > 0x0010 0x0010   /* NFC
> SRAM banks */
> >   >;
> > -   clocks = <&hsmc_clk>;
> > atmel,write-by-sram;
> > };
> > };
> >
> 
> 
> --
> Nicolas Ferre


Best Regards,
Wenyou Yang

RE: [PATCH] mtd: atmel_nand: move the hsmc_clk from nfc node to nand node

[Yang, Wenyou]

> -Original Message-
> From: Ferre, Nicolas
> Sent: 2016年2月22日 20:57
> To: Yang, Wenyou ; Brian Norris
> ; David Woodhouse ;
> Josh Wu 
> Cc: linux-...@lists.infradead.org; linux-arm-ker...@lists.infradead.org; 
> linux-
> ker...@vger.kernel.org; Wu, Josh 
> Subject: Re: [PATCH] mtd: atmel_nand: move the hsmc_clk from nfc node to nand
> node
> 
> Le 17/02/2016 06:40, Wenyou Yang a écrit :
> > From: Josh Wu 
> >
> > For sama5d3, sama5d4 chip, the pmecc becomes a part of HSMC, they need
> > the HSMC clock to be enabled to work.
> > The NFC is a sub feature for current nand driver, it can be disabled.
> > But if HSMC clock is controlled by NFC, so disable NFC will also
> > disable the HSMC clock. then, it will make the PMECC fail to work.
> >
> > So the solution is to move the HSMC clock out of NFC to nand node.
> > When nand driver probed, it will check whether the chip has HSMC, if
> > yes then it will require a HSMC clock.
> >
> > Signed-off-by: Josh Wu 
> > Signed-off-by: Wenyou Yang 
> > ---
> >
> >  .../devicetree/bindings/mtd/atmel-nand.txt |4 +-
> >  drivers/mtd/nand/atmel_nand.c  |   43 
> > +---
> >  2 files changed, 22 insertions(+), 25 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > index d53aba9..29bee7c 100644
> > --- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > +++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
> > @@ -15,6 +15,7 @@ Required properties:
> >  - atmel,nand-cmd-offset : offset for the command latch.
> >  - #address-cells, #size-cells : Must be present if the device has sub-nodes
> >representing partitions.
> > +- clocks: phandle to the peripheral clock
> >
> >  - gpios : specifies the gpio pins to control the NAND device. detect is an
> >optional gpio and may be set to 0 if not present.
> > @@ -43,7 +44,6 @@ Required properties:
> >  - reg : should specify the address and size used for NFC command registers,
> >  NFC registers and NFC SRAM. NFC SRAM address and size can be
> absent
> >  if don't want to use it.
> > -- clocks: phandle to the peripheral clock  Optional properties:
> >  - atmel,write-by-sram: boolean to enable NFC write by SRAM.
> >
> > @@ -100,13 +100,13 @@ nand0: nand@4000 {
> > compatible = "atmel,at91rm9200-nand";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > +   clocks = <&hsmc_clk>
> > ranges;
> >  ...
> >  nfc@7000 {
> > compatible = "atmel,sama5d3-nfc";
> > #address-cells = <1>;
> > #size-cells = <1>;
> > -   clocks = <&hsmc_clk>
> > reg = <
> > 0x7000 0x1000   /* NFC Command
> Registers */
> > 0xc000 0x0070   /* NFC HSMC regs */
> > diff --git a/drivers/mtd/nand/atmel_nand.c
> > b/drivers/mtd/nand/atmel_nand.c index 20cbaab..a1f4ad2 100644
> > --- a/drivers/mtd/nand/atmel_nand.c
> > +++ b/drivers/mtd/nand/atmel_nand.c
> > @@ -66,6 +66,7 @@ module_param(on_flash_bbt, int, 0);  struct
> > atmel_nand_caps {
> > bool pmecc_correct_erase_page;
> > uint8_t pmecc_max_correction;
> > +   bool has_hsmc_clk;
> >  };
> >
> >  struct atmel_nand_nfc_caps {
> > @@ -106,8 +107,6 @@ struct atmel_nfc {
> > booluse_nfc_sram;
> > boolwrite_by_sram;
> >
> > -   struct clk  *clk;
> > -
> > boolis_initialized;
> > struct completion   comp_ready;
> > struct completion   comp_cmd_done;
> > @@ -132,6 +131,7 @@ struct atmel_nand_host {
> > struct dma_chan *dma_chan;
> >
> > struct atmel_nfc*nfc;
> > +   struct clk  *clk;
> >
> > const struct atmel_nand_caps*caps;
> > boolhas_pmecc;
> > @@ -2157,6 +2157,19 @@ static int atmel_nand_probe(struct platform_device
> *pdev)
> > nand_chip->IO_ADDR_R = host->io_base;
> > nand_chip->IO_ADDR_W = host->io_base;
> >
> > +   if (host->caps->has_hsmc_clk) {
> > +   host->clk = devm_clk_get(&pdev->dev, NULL);
> > +   if (IS_ERR(host->clk)) {
> > +   dev_err(&p

RE: [PATCH v3 4/4] Documentation: atmel-pmc: add DT bindings for fast startup

[Yang, Wenyou]

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: 2016年2月22日 10:54
> To: Yang, Wenyou 
> Cc: Ferre, Nicolas ; Alexandre Belloni
> ; Jean-Christophe Plagniol-Villard
> ; Russell King ; linux-
> c...@vger.kernel.org; Pawel Moll ; Mark Brown
> ; Ian Campbell ; Kumar
> Gala ; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v3 4/4] Documentation: atmel-pmc: add DT bindings for fast
> startup
> 
> On Mon, Feb 15, 2016 at 11:40:30AM +0800, Wenyou Yang wrote:
> > Add DT bindings to configurate the PMC_FSMR and PMC_FSPR registers to
> > trigger a fast restart signal to PMC.
> >
> > Signed-off-by: Wenyou Yang 
> > Document: binding
> >
> > ---
> >
> > Changes in v3:
> >  - update the property description.
> 
> This is not helpful. Assume I don't remember what I told you and you need to 
> jog
> my memory what exactly changed so I don't have to go look it up.

Thank you for your instruction, I will keep it in mind.

> 
> >
> > Changes in v2:
> >  - change the property name and property description.
> >
> >  .../devicetree/bindings/arm/atmel-pmc.txt  |   63
> 
> >  1 file changed, 63 insertions(+)
> 
> Acked-by: Rob Herring 

Thank you for your Acked.


Best Regards,
Wenyou Yang

RE: [PATCH v4 1/2] regulator: act8945a: add regulator driver for ACT8945A

[Yang, Wenyou]

> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: 2016年2月4日 1:48
> To: Yang, Wenyou 
> Cc: Javier Martinez Canillas ; Liam Girdwood
> ; Rob Herring ; Pawel Moll
> ; Ian Campbell ; Kumar
> Gala ; Krzysztof Kozlowski
> ; Lee Jones ; Peter
> Korsgaard ; Ferre, Nicolas ;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
> ACT8945A
> 
> On Wed, Feb 03, 2016 at 02:33:11AM +, Yang, Wenyou wrote:
> 
> > > I would just remove the "active-semi,act8945a-regulator" node and
> > > make "active- semi,vsel-high" a property of the "active-semi,act8945a" 
> > > node.
> > > That way you can remove the mfd cell .of_compatible and OF table in
> > > the regulator driver and read the "active-semi,vsel-high" using the
> > > platform device's parent of_node.
> 
> > > But it's better if you wait for Mark's opinions before re-spining your 
> > > patches.
> 
> > Hi Mark, what is your opinions?
> 
> Like Javier says you should make your DT binding look like the DT bindings for
> other MFDs and not use of_compatible.

All right.

Thank you, Mark, Javier.


Best Regards,
Wenyou Yang

RE: [PATCH v4 1/2] regulator: act8945a: add regulator driver for ACT8945A

[Yang, Wenyou]

> -Original Message-
> From: Javier Martinez Canillas [mailto:jav...@dowhile0.org]
> Sent: 2016年2月1日 21:15
> To: Yang, Wenyou 
> Cc: Mark Brown ; Liam Girdwood ;
> Rob Herring ; Pawel Moll ; Ian
> Campbell ; Kumar Gala ;
> Krzysztof Kozlowski ; Lee Jones
> ; Peter Korsgaard ; Ferre, Nicolas
> ; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
> ACT8945A
> 
> Hello Wenyou,
> 
> [snip]
> 
> >> >
> >> > If then device is not being loaded from the DT (and it shouldn't
> >> > be, the device looks like it should be instantiated directly by the
> >> > MFD as it can't exist separately to that MFD) an OF table will do 
> >> > nothing.
> >>
> >> Then he should remove the .of_compatible from the MFD cell definition.
> >
> > I tried it,
> >
> > But if removed this .of_compatible, and reserved the OF table.
> 
> What we said is that you should remove both the mfd cell .of_compatible field 
> and
> the OF table. Of course removing one but leaving the other is not correct.
> 
> > the &pdev->dev->of_node is NULL, the driver fails to get the
> > configuration value from DT,
> >
> 
> I see, you mean that you are not able to lookup the "active-semi,vsel-high"
> property.
> 
> > It seems the OF table still doesn't work. Where is wrong?
> >
> 
> I think the problem is with your DT binding. You have a PMIC dev node with
> compatible "active-semi,act8945a" that has a child node with compatible 
> "active-
> semi,act8945a-regulator" which in turn has the "regulators" node.
> 
> I believe what Mark says is that there shouldn't be a compatible and node for 
> the
> regulators IC since is part of the PMIC. IOW, you can't have it as a 
> standalone
> node in the DTS.
> 
> > Could you help give some suggestion?
> >
> 
> I would just remove the "active-semi,act8945a-regulator" node and make 
> "active-
> semi,vsel-high" a property of the "active-semi,act8945a" node.
> That way you can remove the mfd cell .of_compatible and OF table in the
> regulator driver and read the "active-semi,vsel-high" using the platform 
> device's
> parent of_node.
> 
> But it's better if you wait for Mark's opinions before re-spining your 
> patches.

Hi Mark, what is your opinions?

> 
> Best regards,
> Javier


Best Regards,
Wenyou Yang

RE: [PATCH v4 1/2] regulator: act8945a: add regulator driver for ACT8945A

[Yang, Wenyou]

Hi Peter,

> -Original Message-
> From: Peter Korsgaard [mailto:jac...@gmail.com] On Behalf Of Peter Korsgaard
> Sent: 2016年2月3日 1:42
> To: Mark Brown 
> Cc: Yang, Wenyou ; Liam Girdwood
> ; Rob Herring ; Pawel Moll
> ; Ian Campbell ; Kumar
> Gala ; Krzysztof Kozlowski
> ; Javier Martinez Canillas ;
> Lee Jones ; Peter Korsgaard ; Ferre,
> Nicolas ; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
> ACT8945A
> 
> >>>>> "Mark" == Mark Brown  writes:
> 
>  > On Fri, Jan 29, 2016 at 01:20:08AM +, Yang, Wenyou wrote:
>  >> > > +static const struct of_device_id act8945a_pmic_of_match[] = {
>  >> > > + { .compatible = "active-semi,act8945a-regulator" },
>  >> > > + { },
>  >> > > +};
>  >> > > +MODULE_DEVICE_TABLE(of, act8945a_pmic_of_match);
> 
>  >> > This seems mostly OK but why do we have a compatible string here -
> shouldn't  >> > the MFD be able to instantiate the regulator function without
> needing this?
> 
>  >> Because I got feedback from Javier for the act8945a-charger patches of 
> this
> MFD series,  >> He said missing the OF match table will cause the module
> autoloading broken.
> 
>  >> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/398113.html
> 
>  >> What do you think about it?
> 
>  > If then device is not being loaded from the DT (and it shouldn't be, the  
> > device
> looks like it should be instantiated directly by the MFD as it  > can't exist
> separately to that MFD) an OF table will do nothing.
> 
> To add to the confusion, the regulator part of the chip is actually identical 
> to
> act8865, so it could use the existing regulator driver / compatible, except 
> that it
> binds to the platform bus instead of i2c.

Thank you for your opinion.

But I think It is better to make it a separate driver, the driver is simpler. 

> 
> --
> Bye, Peter Korsgaard


Best Regards,
Wenyou Yang

RE: [PATCH v4 1/2] regulator: act8945a: add regulator driver for ACT8945A

[Yang, Wenyou]

Hi Javier,

> -Original Message-
> From: Javier Martinez Canillas [mailto:jav...@dowhile0.org]
> Sent: 2016年2月1日 21:15
> To: Yang, Wenyou 
> Cc: Mark Brown ; Liam Girdwood ;
> Rob Herring ; Pawel Moll ; Ian
> Campbell ; Kumar Gala ;
> Krzysztof Kozlowski ; Lee Jones
> ; Peter Korsgaard ; Ferre, Nicolas
> ; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
> ACT8945A
> 
> Hello Wenyou,
> 
> [snip]
> 
> >> >
> >> > If then device is not being loaded from the DT (and it shouldn't
> >> > be, the device looks like it should be instantiated directly by the
> >> > MFD as it can't exist separately to that MFD) an OF table will do 
> >> > nothing.
> >>
> >> Then he should remove the .of_compatible from the MFD cell definition.
> >
> > I tried it,
> >
> > But if removed this .of_compatible, and reserved the OF table.
> 
> What we said is that you should remove both the mfd cell .of_compatible field 
> and
> the OF table. Of course removing one but leaving the other is not correct.

I am confused :)

> 
> > the &pdev->dev->of_node is NULL, the driver fails to get the
> > configuration value from DT,
> >
> 
> I see, you mean that you are not able to lookup the "active-semi,vsel-high"
> property.

No only this property,

The regulator init_datas are also not gotten from DT due to the 
&pdev->dev->of_node is NULL.

> 
> > It seems the OF table still doesn't work. Where is wrong?
> >
> 
> I think the problem is with your DT binding. You have a PMIC dev node with
> compatible "active-semi,act8945a" that has a child node with compatible 
> "active-
> semi,act8945a-regulator" which in turn has the "regulators" node.
> 
> I believe what Mark says is that there shouldn't be a compatible and node for 
> the
> regulators IC since is part of the PMIC. IOW, you can't have it as a 
> standalone
> node in the DTS.
> 
> > Could you help give some suggestion?
> >
> 
> I would just remove the "active-semi,act8945a-regulator" node and make 
> "active-
> semi,vsel-high" a property of the "active-semi,act8945a" node.
> That way you can remove the mfd cell .of_compatible and OF table in the
> regulator driver and read the "active-semi,vsel-high" using the platform 
> device's
> parent of_node.
> 
> But it's better if you wait for Mark's opinions before re-spining your 
> patches.

All right.

> 
> Best regards,
> Javier

Thanks 


Best Regards,
Wenyou Yang

RE: [PATCH 4/4] Documentation: atmel-at91: add DT bindings for fast startup

[Yang, Wenyou]

Hi Rob,

Thank you for your review.

> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: 2016年1月30日 0:20
> To: Yang, Wenyou 
> Cc: Ferre, Nicolas ; Alexandre Belloni
> ; Jean-Christophe Plagniol-Villard
> ; Russell King ; linux-
> c...@vger.kernel.org; Pawel Moll ; Mark Brown
> ; Ian Campbell ; Kumar
> Gala ; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH 4/4] Documentation: atmel-at91: add DT bindings for fast
> startup
> 
> On Thu, Jan 28, 2016 at 06:19:16PM +0800, Wenyou Yang wrote:
> > Add DT bindings to configurate the PMC_FSMR and PMC_FSPR registers to
> > trigger a fast restart signal to PMC.
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> >
> >  .../devicetree/bindings/arm/atmel-pmc.txt  |   74
> 
> >  1 file changed, 74 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/atmel-pmc.txt
> > b/Documentation/devicetree/bindings/arm/atmel-pmc.txt
> > index 795cc78..8d45ff9f 100644
> > --- a/Documentation/devicetree/bindings/arm/atmel-pmc.txt
> > +++ b/Documentation/devicetree/bindings/arm/atmel-pmc.txt
> > @@ -12,3 +12,77 @@ Examples:
> > compatible = "atmel,at91rm9200-pmc";
> > reg = <0xfc00 0x100>;
> > };
> > +
> > +PMC Fast Startup Signals
> > +
> > +The PMC Fast Start Signals are used as the wake up source to trigger
> > +the PMC to wake up the system from the ULP1 mode.
> > +
> > +required properties:
> > +- compatible: Should be "atmel,sama5d2-pmc-fast-startup".
> 
> Why the compatible? Does this correspond to some h/w block rather than 
> features
> of the PMC? If it is simply because you want to have a separate driver, that 
> is not
> a good reason.

The PMC is regarded as an MFD device.

The Fast Startup function is a sub-device, the driver access the register
through regmap returned from the syscon helper API syscon_node_to_regmap().

> 
> > +
> > +optional properties:
> > +- atmel,fast-startup-wake-up: boolean to enable the WKUP pin to
> > +trigger
> > +  a fast restart signal to the PMC.
> > +- atmel,fast-startup-secumod: boolean to enable the Security Mode to
> > +trigger
> > +  a fast restart signal to the PMC.
> > +- atmel,fast-startup-piobu0: boolean to enable the PIOBU0 Input to
> > +trigger
> > +  a fast restart signal to the PMC.
> > +- atmel,fast-startup-piobu1: boolean to enable the PIOBU1 Input to
> > +trigger
> > +  a fast restart signal to the PMC.
> > +- atmel,fast-startup-piobu2: boolean to enable the PIOBU2 Input to
> > +trigger
> > +  a fast restart signal to the PMC.
> > +- atmel,fast-startup-piobu3: boolean to enable the PIOBU3 Input to
> > +trigger
> > +  a fast restart signal to the PMC.
> > +- atmel,fast-startup-piobu4: boolean to enable the PIOBU4 Input to
> > +trigger
> > +  a fast restart signal to the PMC.
> > +- atmel,fast-startup-piobu5: boolean to enable the PIOBU5 Input to
> > +trigger
> > +  a fast restart signal to the PMC.
> > +- atmel,fast-startup-piobu6: boolean to enable the PIOBU6 Input to
> > +trigger
> > +  a fast restart signal to the PMC.
> > +- atmel,fast-startup-piobu7: boolean to enable the PIOBU7 Input to
> > +trigger
> > +  a fast restart signal to the PMC.
> > +- atmel,fast-startup-gmac-wol: boolean to enable the GMAC Wake-up On
> > +LAN
> > +  to trigger a fast restart signal to the PMC.
> > +- atmel,fast-startup-rtc-alarm: boolean to enable the RTC Alarm to
> > +trigger
> > +  a fast restart signal to the PMC.
> > +- atmel,fast-startup-usb-resume: boolean to enable the USB Resume to
> > +trigger
> > +  a fast restart signal to the PMC.
> > +- atmel,fast-startup-sdmmc-cd: boolean to enable the SDMMC Card
> > +Detect
> > +  to trigger a fast restart signal to the PMC.
> > +- atmel,fast-startup-rxlp-match: boolean to enable the Backuo UART
> > +Receive
> > +  Match Condition to trigger a fast restart signal to the PMC.
> > +- atmel,fast-startup-acc-comparison: boolean to enable the Analog
> > +Comparator
> > +  Controller (ACC) Comparison to to trigger a fast restart signal to the 
> > PMC.
> > +
> > +- atmel,fast-startup-wkup-pin-high: boolean to indicate if the WKUP
> > +Pin is
> > +  in the high level to trigger fast restart signal, otherwise low level.
> 
> Perhaps just make the above bool properties take a value to indicate high or 
> low
> triggered.

Agreed. 

How about the fol

RE: [PATCH v4 1/2] regulator: act8945a: add regulator driver for ACT8945A

[Yang, Wenyou]

Hi Javier & Mark,

I am educated. Thank you all.

> -Original Message-
> From: Javier Martinez Canillas [mailto:jav...@dowhile0.org]
> Sent: 2016年1月29日 19:50
> To: Mark Brown 
> Cc: Yang, Wenyou ; Liam Girdwood
> ; Rob Herring ; Pawel Moll
> ; Ian Campbell ; Kumar
> Gala ; Krzysztof Kozlowski
> ; Lee Jones ; Peter
> Korsgaard ; Ferre, Nicolas ;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
> ACT8945A
> 
> Hello Mark,
> 
> On Fri, Jan 29, 2016 at 8:35 AM, Mark Brown  wrote:
> > On Fri, Jan 29, 2016 at 01:20:08AM +, Yang, Wenyou wrote:
> >
> >> > > +static const struct of_device_id act8945a_pmic_of_match[] = {  {
> >> > > +.compatible = "active-semi,act8945a-regulator" },  { }, };
> >> > > +MODULE_DEVICE_TABLE(of, act8945a_pmic_of_match);
> >
> >> > This seems mostly OK but why do we have a compatible string here -
> >> > shouldn't the MFD be able to instantiate the regulator function without
> needing this?
> >
> >> Because I got feedback from Javier for the act8945a-charger patches
> >> of this MFD series, He said missing the OF match table will cause the 
> >> module
> autoloading broken.
> >
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/39
> >> 8113.html
> >
> >> What do you think about it?
> >
> > If then device is not being loaded from the DT (and it shouldn't be,
> > the device looks like it should be instantiated directly by the MFD as
> > it can't exist separately to that MFD) an OF table will do nothing.
> 
> Then he should remove the .of_compatible from the MFD cell definition.

I tried it,

But if removed this .of_compatible, and reserved the OF table. 
the &pdev->dev->of_node is NULL, the driver fails to get the configuration 
value from DT, 

It seems the OF table still doesn't work. Where is wrong?

Could you help give some suggestion?

> 
> Otherwise the MFD core will assign an of_node to this device in 
> mfd_add_device(),
> making the platform core to believe the device was instantiated by OF. So an 
> OF
> modalias uevent will be reported to load the module and the OF table should be
> used for matching the device with the driver.
> 
> IOW, the MFD and regulator driver have to agree on this. Either everything 
> should
> have OF or platform information, both work but mixing these as it was on a
> previous version doesn't.
> 
> Best regards,
> Javier


Best Regards,
Wenyou Yang

RE: [PATCH v4 1/2] regulator: act8945a: add regulator driver for ACT8945A

[Yang, Wenyou]

Hi Mark,

> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: 2016年1月29日 8:16
> To: Yang, Wenyou 
> Cc: Liam Girdwood ; Rob Herring ;
> Pawel Moll ; Ian Campbell
> ; Kumar Gala ;
> Krzysztof Kozlowski ; Javier Martinez Canillas
> ; Lee Jones ; Peter Korsgaard
> ; Ferre, Nicolas ; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH v4 1/2] regulator: act8945a: add regulator driver for
> ACT8945A
> 
> On Wed, Jan 27, 2016 at 10:57:42AM +0800, Wenyou Yang wrote:
> 
> > +static const struct of_device_id act8945a_pmic_of_match[] = {
> > +   { .compatible = "active-semi,act8945a-regulator" },
> > +   { },
> > +};
> > +MODULE_DEVICE_TABLE(of, act8945a_pmic_of_match);
> 
> This seems mostly OK but why do we have a compatible string here - shouldn't
> the MFD be able to instantiate the regulator function without needing this?

Because I got feedback from Javier for the act8945a-charger patches of this MFD 
series,
He said missing the OF match table will cause the module autoloading broken. 

http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/398113.html

What do you think about it?


Best Regards,
Wenyou Yang

RE: [PATCH v8 1/2] mfd: act8945a: add Active-semi ACT8945A PMIC MFD driver

[Yang, Wenyou]

Hi Peter,

> -Original Message-
> From: Peter Korsgaard [mailto:jac...@gmail.com] On Behalf Of Peter Korsgaard
> Sent: 2016年1月27日 16:05
> To: Yang, Wenyou 
> Cc: Lee Jones ; Rob Herring ;
> Pawel Moll ; Mark Rutland ; Ian
> Campbell ; Kumar Gala ;
> Javier Martinez Canillas ; Krzysztof Kozlowski
> ; Peter Korsgaard ; Ferre,
> Nicolas ; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v8 1/2] mfd: act8945a: add Active-semi ACT8945A PMIC
> MFD driver
> 
> >>>>> "Wenyou" == Wenyou Yang  writes:
> 
>  > This patch adds support for the Active-semi ACT8945A PMIC.
>  > It is a Multi Function Device with the following subdevices:
>  >  - Regulator
>  >  - Charger
> 
>  > It is interfaced to the host controller using I2C interface,  > ACT8945A 
> is a child
> device of the I2C.
> 
>  > Signed-off-by: Wenyou Yang   > Reviewed-by:
> Krzysztof Kozlowski 
> 
> Thanks, looks good - One more thing though:
> 
>  > +
>  > +struct act8945a_dev {
>  > +  struct regmap *regmap;
>  > +};
> 
> You don't need this structure as you used devm. With that removed (and the 
> logic
> to devm_kzalloc it) you can add my:

Yes, it can be removed.

> 
> Acked-by: Peter Korsgaard 
> 

Thank you for you Acked.

> 
>  > +static const struct mfd_cell act8945a_devs[] = {
>  > +  {
>  > +  .name = "act8945a-regulator",
>  > +  .of_compatible = "active-semi,act8945a-regulator",
>  > +  },
>  > +  {
>  > +  .name = "act8945a-charger",
>  > +  .of_compatible = "active-semi,act8945a-charger",
>  > +  },
>  > +};
>  > +
>  > +static const struct regmap_config act8945a_regmap_config = {
>  > +  .reg_bits = 8,
>  > +  .val_bits = 8,
>  > +};
>  > +
>  > +static int act8945a_i2c_probe(struct i2c_client *i2c,
>  > +const struct i2c_device_id *id)
>  > +{
>  > +  struct act8945a_dev *act8945a;
>  > +  int ret;
>  > +
>  > +  act8945a = devm_kzalloc(&i2c->dev, sizeof(*act8945a), GFP_KERNEL);
>  > +  if (!act8945a)
>  > +  return -ENOMEM;
>  > +
>  > +  i2c_set_clientdata(i2c, act8945a);
>  > +
>  > +  act8945a->regmap = devm_regmap_init_i2c(i2c,
> &act8945a_regmap_config);
>  > +  if (IS_ERR(act8945a->regmap)) {
>  > +  ret = PTR_ERR(act8945a->regmap);
>  > +  dev_err(&i2c->dev, "regmap init failed: %d\n", ret);
>  > +  return ret;
>  > +  }
>  > +
>  > +  ret = mfd_add_devices(&i2c->dev, PLATFORM_DEVID_NONE,
> act8945a_devs,
>  > +ARRAY_SIZE(act8945a_devs), NULL, 0, NULL);
>  > +  if (ret) {
>  > +  dev_err(&i2c->dev, "Failed to add sub devices\n");
>  > +  return ret;
>  > +  }
>  > +
>  > +  return 0;
>  > +}
>  > +
>  > +static int act8945a_i2c_remove(struct i2c_client *i2c)  > +{
>  > +  mfd_remove_devices(&i2c->dev);
>  > +
>  > +  return 0;
>  > +}
>  > +
>  > +static const struct i2c_device_id act8945a_i2c_id[] = {
>  > +  { "act8945a", 0 },
>  > +  {}
>  > +};
>  > +MODULE_DEVICE_TABLE(i2c, act8945a_i2c_id);  > +  > +static const struct
> of_device_id act8945a_of_match[] = {
>  > +  { .compatible = "active-semi,act8945a", },
>  > +  {},
>  > +};
>  > +MODULE_DEVICE_TABLE(of, act8945a_of_match);  > +  > +static struct
> i2c_driver act8945a_i2c_driver = {
>  > +  .driver = {
>  > + .name = "act8945a",
>  > + .of_match_table = of_match_ptr(act8945a_of_match),
>  > +  },
>  > +  .probe = act8945a_i2c_probe,
>  > +  .remove = act8945a_i2c_remove,
>  > +  .id_table = act8945a_i2c_id,
>  > +};
>  > +
>  > +static int __init act8945a_i2c_init(void)  > +{
>  > +  return i2c_add_driver(&act8945a_i2c_driver);
>  > +}
>  > +subsys_initcall(act8945a_i2c_init);
>  > +
>  > +static void __exit act8945a_i2c_exit(void)  > +{
>  > +  i2c_del_driver(&act8945a_i2c_driver);
>  > +}
>  > +module_exit(act8945a_i2c_exit);
>  > +
>  > +MODULE_DESCRIPTION("ACT8945A PMIC multi-function driver");  >
> +MODULE_AUTHOR("Wenyou Yang ");  >
> +MODULE_LICENSE("GPL");  > --  > 1.7.9.5
> 
> 
> 
> --
> Bye, Peter Korsgaard


Best regards,
Wenyou Yang

RE: [PATCH v8 1/2] mfd: act8945a: add Active-semi ACT8945A PMIC MFD driver

[Yang, Wenyou]

Hi Lee,

> -Original Message-
> From: Lee Jones [mailto:lee.jo...@linaro.org]
> Sent: 2016年1月27日 15:28
> To: Yang, Wenyou 
> Cc: Rob Herring ; Pawel Moll ;
> Mark Rutland ; Ian Campbell
> ; Kumar Gala ; Javier
> Martinez Canillas ; Krzysztof Kozlowski
> ; Peter Korsgaard ; Ferre,
> Nicolas ; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v8 1/2] mfd: act8945a: add Active-semi ACT8945A PMIC
> MFD driver
> 
> On Wed, 27 Jan 2016, Wenyou Yang wrote:
> 
> > This patch adds support for the Active-semi ACT8945A PMIC.
> > It is a Multi Function Device with the following subdevices:
> >  - Regulator
> >  - Charger
> >
> > It is interfaced to the host controller using I2C interface, ACT8945A
> > is a child device of the I2C.
> >
> > Signed-off-by: Wenyou Yang 
> > Reviewed-by: Krzysztof Kozlowski 
> 
> Can I take the MFD patches in separately?

Yes, you can, I think.

> 
> For my own reference:
>   Acked-by: Lee Jones 

Thank you for your Acked.

> 
> > ---
> >
> > Changes in v8:
> >  - change the subdevice's name "act8945a-pmic" to "act8945a-regulator".
> >
> > Changes in v7:
> >  - remove struct act8945a_dev to .c file.
> >  - remove unused .h file.
> >
> > Changes in v6:
> >  - change MFD_ACT8945A type from bool to tristate.
> >  - revert depends on to 'I2C'.
> >
> > Changes in v5:
> >  - change depends on to 'I2C=y'.
> >
> > Changes in v4:
> >  - add a space before .compatible.
> >  - collect Reviewed-by from Krzysztof Kozlowski.
> >
> > Changes in v3: None
> > Changes in v2:
> >  - add more help information in Kconfig.
> >  - update the file header with short version license and author line.
> >  - remove unused structure members (dev, i2c_client) of stuct act8945a_dev.
> >  - use define "PLATFORM_DEVID_NONE" for mfd_add_devices(), instead of '-1'.
> >  - use more explicit info to indicate the failure to add sub devices.
> >  - remove the unnecessary print out.
> >  - substitute MODULE_LICENSE("GPL") for MODULE_LICENSE("GPL v2").
> >
> >  drivers/mfd/Kconfig|   11 +
> >  drivers/mfd/Makefile   |1 +
> >  drivers/mfd/act8945a.c |  112
> > 
> >  3 files changed, 124 insertions(+)
> >  create mode 100644 drivers/mfd/act8945a.c
> >
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index
> > 6c4ebd9..38994bb 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -18,6 +18,17 @@ config MFD_CS5535
> >   This is the core driver for CS5535/CS5536 MFD functions.  This is
> >necessary for using the board's GPIO and MFGPT functionality.
> >
> > +config MFD_ACT8945A
> > +   tristate "Active-semi ACT8945A"
> > +   select MFD_CORE
> > +   select REGMAP_I2C
> > +   depends on I2C && OF
> > +   help
> > + Support for the ACT8945A PMIC from Active-semi. This device
> > + features three step-down DC/DC converters and four low-dropout
> > + linear regulators, along with a complete ActivePath battery
> > + charger.
> > +
> >  config MFD_AS3711
> > bool "AMS AS3711"
> > select MFD_CORE
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index
> > 0f230a6..2f1ca82 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -6,6 +6,7 @@
> >  obj-$(CONFIG_MFD_88PM860X) += 88pm860x.o
> >  obj-$(CONFIG_MFD_88PM800)  += 88pm800.o 88pm80x.o
> >  obj-$(CONFIG_MFD_88PM805)  += 88pm805.o 88pm80x.o
> > +obj-$(CONFIG_MFD_ACT8945A) += act8945a.o
> >  obj-$(CONFIG_MFD_SM501)+= sm501.o
> >  obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
> >  obj-$(CONFIG_MFD_BCM590XX) += bcm590xx.o
> > diff --git a/drivers/mfd/act8945a.c b/drivers/mfd/act8945a.c new file
> > mode 100644 index 000..3a37611
> > --- /dev/null
> > +++ b/drivers/mfd/act8945a.c
> > @@ -0,0 +1,112 @@
> > +/*
> > + * MFD driver for Active-semi ACT8945a PMIC
> > + *
> > + * Copyright (C) 2015 Atmel Corporation.
> > + *
> > + * Author: Wenyou Yang 
> > + *
> > + * This program is free software; you can redistribute it and/or
> > +modify it
> > + * under  the terms of the GNU General  Public License as published
> > +by the
> > + * Free Software Foundatio

RE: [PATCH v7 1/2] mfd: act8945a: add Active-semi ACT8945A PMIC MFD driver

[Yang, Wenyou]

Hi Lee,

Thank you for your review.


> -Original Message-
> From: Lee Jones [mailto:lee.jo...@linaro.org]
> Sent: 2016年1月25日 20:50
> To: Yang, Wenyou 
> Cc: Rob Herring ; Pawel Moll ;
> Mark Rutland ; Ian Campbell
> ; Kumar Gala ; Javier
> Martinez Canillas ; Krzysztof Kozlowski
> ; Peter Korsgaard ; Ferre,
> Nicolas ; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v7 1/2] mfd: act8945a: add Active-semi ACT8945A PMIC
> MFD driver
> 
> On Fri, 22 Jan 2016, Wenyou Yang wrote:
> 
> > This patch adds support for the Active-semi ACT8945A PMIC.
> > It is a Multi Function Device with the following subdevices:
> >  - Regulator
> >  - Charger
> >
> > It is interfaced to the host controller using I2C interface, ACT8945A
> > is a child device of the I2C.
> >
> > Signed-off-by: Wenyou Yang 
> > Reviewed-by: Krzysztof Kozlowski 
> > ---
> >
> > Changes in v7:
> >  - remove struct act8945a_dev to .c file.
> >  - remove unused .h file.
> >
> > Changes in v6:
> >  - change MFD_ACT8945A type from bool to tristate.
> >  - revert depends on to 'I2C'.
> >
> > Changes in v5:
> >  - change depends on to 'I2C=y'.
> >
> > Changes in v4:
> >  - add a space before .compatible.
> >  - collect Reviewed-by from Krzysztof Kozlowski.
> >
> > Changes in v3: None
> > Changes in v2:
> >  - add more help information in Kconfig.
> >  - update the file header with short version license and author line.
> >  - remove unused structure members (dev, i2c_client) of stuct act8945a_dev.
> >  - use define "PLATFORM_DEVID_NONE" for mfd_add_devices(), instead of '-1'.
> >  - use more explicit info to indicate the failure to add sub devices.
> >  - remove the unnecessary print out.
> >  - substitute MODULE_LICENSE("GPL") for MODULE_LICENSE("GPL v2").
> >
> >  drivers/mfd/Kconfig|   11 +
> >  drivers/mfd/Makefile   |1 +
> >  drivers/mfd/act8945a.c |  112
> > 
> >  3 files changed, 124 insertions(+)
> >  create mode 100644 drivers/mfd/act8945a.c
> >
> > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index
> > 9ca66de..5038e78 100644
> > --- a/drivers/mfd/Kconfig
> > +++ b/drivers/mfd/Kconfig
> > @@ -18,6 +18,17 @@ config MFD_CS5535
> >   This is the core driver for CS5535/CS5536 MFD functions.  This is
> >necessary for using the board's GPIO and MFGPT functionality.
> >
> > +config MFD_ACT8945A
> > +   tristate "Active-semi ACT8945A"
> > +   select MFD_CORE
> > +   select REGMAP_I2C
> > +   depends on I2C && OF
> > +   help
> > + Support for the ACT8945A PMIC from Active-semi. This device
> > + features three step-down DC/DC converters and four low-dropout
> > + linear regulators, along with a complete ActivePath battery
> > + charger.
> > +
> >  config MFD_AS3711
> > bool "AMS AS3711"
> > select MFD_CORE
> > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index
> > 0f230a6..2f1ca82 100644
> > --- a/drivers/mfd/Makefile
> > +++ b/drivers/mfd/Makefile
> > @@ -6,6 +6,7 @@
> >  obj-$(CONFIG_MFD_88PM860X) += 88pm860x.o
> >  obj-$(CONFIG_MFD_88PM800)  += 88pm800.o 88pm80x.o
> >  obj-$(CONFIG_MFD_88PM805)  += 88pm805.o 88pm80x.o
> > +obj-$(CONFIG_MFD_ACT8945A) += act8945a.o
> >  obj-$(CONFIG_MFD_SM501)+= sm501.o
> >  obj-$(CONFIG_MFD_ASIC3)+= asic3.o tmio_core.o
> >  obj-$(CONFIG_MFD_BCM590XX) += bcm590xx.o
> > diff --git a/drivers/mfd/act8945a.c b/drivers/mfd/act8945a.c new file
> > mode 100644 index 000..d2e01941
> > --- /dev/null
> > +++ b/drivers/mfd/act8945a.c
> > @@ -0,0 +1,112 @@
> > +/*
> > + * MFD driver for Active-semi ACT8945a PMIC
> > + *
> > + * Copyright (C) 2015 Atmel Corporation.
> > + *
> > + * Author: Wenyou Yang 
> > + *
> > + * This program is free software; you can redistribute it and/or
> > +modify it
> > + * under  the terms of the GNU General  Public License as published
> > +by the
> > + * Free Software Foundation;  either version 2 of the License, or (at
> > +your
> > + * option) any later version.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +struct act8945a_dev {
> > +   struct regmap *re

RE: [PATCH v6 1/2] power: act8945a: add charger driver for ACT8945A

[Yang, Wenyou]

Hi Peter,

Thank you for so much advice.


> -Original Message-
> From: Peter Korsgaard [mailto:jac...@gmail.com] On Behalf Of Peter Korsgaard
> Sent: 2016年1月21日 4:25
> To: Yang, Wenyou 
> Cc: Sebastian Reichel ; Dmitry Eremin-Solenikov
> ; David Woodhouse ; Rob
> Herring ; Pawel Moll ; Mark
> Rutland ; Ian Campbell ;
> Kumar Gala ; Krzysztof Kozlowski
> ; Javier Martinez Canillas ;
> Lee Jones ; Peter Korsgaard ; Ferre,
> Nicolas ; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: [PATCH v6 1/2] power: act8945a: add charger driver for ACT8945A
> 
> >>>>> "Wenyou" == Wenyou Yang  writes:
> 
>  > This patch adds new driver for Active-semi ACT8945A ActivePath  > charger
> (part of ACT8945A MFD driver) providing power supply class  > information to
> userspace.
> 
>  > The driver can be configured through DT (such as, total timer,  > 
> precondition
> timer and input over-voltage threshold).
> 
>  > Signed-off-by: Wenyou Yang   > ---
> 
>  > Changes in v6:
>  >  - change the type value to unsigned int.
> 
> [snip]
> 
> > +++ b/drivers/power/act8945a_charger.c
>  > @@ -0,0 +1,375 @@
>  > +/*
>  > + * Power supply driver for the Active-semi ACT8945A PMIC  > + *  > + *
> Copyright (C) 2015 Atmel Corporation  > + *  > + * Author: Wenyou Yang
>   > + *  > + * This program is free software; you can
> redistribute it and/or modify  > + * it under the terms of the GNU General 
> Public
> License version 2 as  > + * published by the Free Software Foundation.
>  > + *
>  > + */
>  > +#include 
>  > +#include 
>  > +#include 
>  > +#include 
>  > +#include 
>  > +#include 
>  > +#include 
>  > +
>  > +static const char *act8945a_charger_model = "ACT8945A";  > +static const
> char *act8945a_charger_manufacturer = "Active-semi";  > +  > +/**  > + *
> ACT8945A Charger Register Map  > + */  > +  > +/* 0x70: Reserved */
>  > +#define ACT8945A_APCH_CFG 0x71
>  > +#define ACT8945A_APCH_STATUS  0x78
>  > +#define ACT8945A_APCH_CTRL0x79
>  > +#define ACT8945A_APCH_STATE   0x7A
>  > +
>  > +/* ACT8945A_APCH_CFG */
>  > +#define APCH_CFG_OVPSET   (0x3 << 0)
>  > +#define APCH_CFG_OVPSET_6V6   (0x0 << 0)
>  > +#define APCH_CFG_OVPSET_7V(0x1 << 0)
>  > +#define APCH_CFG_OVPSET_7V5   (0x2 << 0)
>  > +#define APCH_CFG_OVPSET_8V(0x3 << 0)
>  > +#define APCH_CFG_PRETIMO  (0x3 << 2)
>  > +#define APCH_CFG_PRETIMO_40_MIN   (0x0 << 2)
>  > +#define APCH_CFG_PRETIMO_60_MIN   (0x1 << 2)
>  > +#define APCH_CFG_PRETIMO_80_MIN   (0x2 << 2)
>  > +#define APCH_CFG_PRETIMO_DISABLED (0x3 << 2)
>  > +#define APCH_CFG_TOTTIMO  (0x3 << 4)
>  > +#define APCH_CFG_TOTTIMO_3_HOUR   (0x0 << 4)
>  > +#define APCH_CFG_TOTTIMO_4_HOUR   (0x1 << 4)
>  > +#define APCH_CFG_TOTTIMO_5_HOUR   (0x2 << 4)
>  > +#define APCH_CFG_TOTTIMO_DISABLED (0x3 << 4)
>  > +#define APCH_CFG_SUSCHG   (0x1 << 7)
>  > +
>  > +#define APCH_STATUS_CHGDATBIT(0)
>  > +#define APCH_STATUS_INDAT BIT(1)
>  > +#define APCH_STATUS_TEMPDAT   BIT(2)
>  > +#define APCH_STATUS_TIMRDAT   BIT(3)
>  > +#define APCH_STATUS_CHGSTAT   BIT(4)
>  > +#define APCH_STATUS_INSTATBIT(5)
>  > +#define APCH_STATUS_TEMPSTAT  BIT(6)
>  > +#define APCH_STATUS_TIMRSTAT  BIT(7)
>  > +
>  > +#define APCH_CTRL_CHGEOCOUT   BIT(0)
>  > +#define APCH_CTRL_INDIS   BIT(1)
>  > +#define APCH_CTRL_TEMPOUT BIT(2)
>  > +#define APCH_CTRL_TIMRPRE BIT(3)
>  > +#define APCH_CTRL_CHGEOCINBIT(4)
>  > +#define APCH_CTRL_INCON   BIT(5)
>  > +#define APCH_CTRL_TEMPIN  BIT(6)
>  > +#define APCH_CTRL_TIMRTOT BIT(7)
>  > +
>  > +#define APCH_STATE_ACINSTAT   (0x1 << 1)
>  > +#define APCH_STATE_CSTATE (0x3 << 4)
>  > +#define APCH_STATE_CSTATE_SHIFT   4
>  > +#define APCH_STATE_CSTATE_DISABLED0x00
>  > +#define APCH_STATE_CSTATE_EOC 0x01
>  > +#define APCH_STATE_CSTATE_FAST0x02
>  > +#define APCH_STATE_CSTATE_PRE 

RE: [PATCH v6 0/2] power: act8945a: add charger driver for the sub-device of ACT8945A MFD

[Yang, Wenyou]

> -Original Message-
> From: Lee Jones [mailto:lee.jo...@linaro.org]
> Sent: 2016年1月20日 19:32
> To: Yang, Wenyou 
> Cc: Sebastian Reichel ; Dmitry Eremin-Solenikov
> ; David Woodhouse ; Rob
> Herring ; Pawel Moll ; Mark
> Rutland ; Ian Campbell ;
> Kumar Gala ; Krzysztof Kozlowski
> ; Javier Martinez Canillas ;
> Peter Korsgaard ; Ferre, Nicolas
> ; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux...@vger.kernel.org
> Subject: Re: [PATCH v6 0/2] power: act8945a: add charger driver for the sub-
> device of ACT8945A MFD
> 
> It really is unacceptable to be sending out so many versions at such short
> intervals, essentially spamming the list.  This infraction is worsened by the
> amount of people you have on CC, most of them for no reason.  This set 
> shouldn't
> hit my inbox at all, let alone 4 times in one day!

Sorry!

Next time I will be careful.

> 
> > The ACT8945A is a Multi Function Device with the following subdevices:
> >  - Regulator
> >  - Charger
> >
> > This patch set is to add regulator driver for ACT8945A.
> > It is based on the patch set:
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/400
> > 534.html
> >
> > Changes in v6:
> >  - change the type value to unsigned int.
> >
> > Changes in v5:
> >  - remove spare spaces after #define.
> >  - add OF match table.
> >  - collect Reviewed-by from Krzysztof.
> >
> > Changes in v4:
> >  - use spaces after #define, not tabs.
> >  - use BIT(n) macros to substitute (0x01 << x).
> >  - change dt properties with more legible name.
> >  - change the properties with more legible name, clearer description.
> >
> > Changes in v3:
> >  - update the file header with short version license and author line.
> >  - remove unused member of struct act8945a_charger, dev.
> >  - action due to removing the member of stuct act8945a_dev, dev.
> >  - remove the unnecessary print out.
> >  - remove the unnecessary act8945a_charger_remove().
> >  - fix align of the code-style.
> >
> > Changes in v2:
> >  1./ Substitute of_property_read_bool() for of_get_property().
> >  2./ Substitute devm_power_supply_register() for power_supply_register().
> >  3./ Use module_platform_driver(), instead of subsys_initcall().
> >  4./ Substitute MODULE_LICENSE("GPL") for MODULE_LICENSE("GPL v2").
> >
> > Wenyou Yang (2):
> >   power: act8945a: add charger driver for ACT8945A
> >   power: add documentation for ACT8945A's charger DT bindings
> >
> >  .../devicetree/bindings/power/act8945a-charger.txt |   33 ++
> >  drivers/power/Kconfig  |7 +
> >  drivers/power/Makefile |1 +
> >  drivers/power/act8945a_charger.c   |  375 
> > 
> >  4 files changed, 416 insertions(+)
> >  create mode 100644
> > Documentation/devicetree/bindings/power/act8945a-charger.txt
> >  create mode 100644 drivers/power/act8945a_charger.c
> >
> 
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source
> software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog


Best Regards,
Wenyou Yang

RE: [PATCH 2/2] can: m_can: Add CAN clock generated by UPLLCK support

[Yang, Wenyou]

Hi Marc,

> -Original Message-
> From: Marc Kleine-Budde [mailto:m...@pengutronix.de]
> Sent: 2015年11月18日 18:23
> To: Yang, Wenyou; Wolfgang Grandegger
> Cc: linux-...@vger.kernel.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Ferre, Nicolas
> Subject: Re: [PATCH 2/2] can: m_can: Add CAN clock generated by UPLLCK
> support
> 
> On 11/18/2015 11:04 AM, Wenyou Yang wrote:
> > As said SAMA5D2 datasheet, it is recommended to use the CAN clock at
> > frequencies of 20, 40 or 80 MHz. To achieve these frequencies, PMC
> > GCK3 must select the UPLLCK(480 MHz) as source clock and divide by 24,
> > 12 or 6. In this patch the CAN clock at 20 MHz.
> >
> > As it is configured through DT, it doesn't affect the M_CAN without
> > configuring CAN clock and its generated clock.
> >
> > Signed-off-by: Wenyou Yang 
> 
> NACK
> 
> Please do this setup in your SoC code, where you setup the clock 
> infrastructure or
> have a look at Documentation/devicetree/bindings/clock/clock-bindings.txt
> "Assigned clock parents and rates"
Thank you for your advice. I will do this setup via DT.


> 
> > ---
> >
> >  drivers/net/can/m_can/m_can.c |   16 +++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/can/m_can/m_can.c
> > b/drivers/net/can/m_can/m_can.c index fd1caa0..2ca47db 100644
> > --- a/drivers/net/can/m_can/m_can.c
> > +++ b/drivers/net/can/m_can/m_can.c
> > @@ -269,6 +269,8 @@ enum m_can_mram_cfg {
> >  #define TX_BUF_XTD BIT(30)
> >  #define TX_BUF_RTR BIT(29)
> >
> > +#define AT91_CAN_CLK_FREQ  2000
> > +
> >  /* address offset and element number for each FIFO/Buffer in the
> > Message RAM */  struct mram_cfg {
> > u16 off;
> > @@ -1188,7 +1190,7 @@ static int m_can_plat_probe(struct platform_device
> *pdev)
> > struct m_can_priv *priv;
> > struct resource *res;
> > void __iomem *addr;
> > -   struct clk *hclk, *cclk;
> > +   struct clk *hclk, *cclk, *upll_clk;
> > int irq, ret;
> >
> > hclk = devm_clk_get(&pdev->dev, "hclk"); @@ -1198,6 +1200,18 @@
> > static int m_can_plat_probe(struct platform_device *pdev)
> > return -ENODEV;
> > }
> >
> > +   upll_clk = devm_clk_get(&pdev->dev, "upllclk");
> > +   if (!IS_ERR(upll_clk)) {
> > +   ret = clk_set_parent(cclk, upll_clk);
> > +   if (!ret) {
> > +   ret = clk_set_rate(cclk, AT91_CAN_CLK_FREQ);
> > +   if (ret) {
> > +   dev_err(&pdev->dev, "failed to set gck\n");
> > +   return -ENODEV;
> > +   }
> > +   }
> > +   }
> > +
> > res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "m_can");
> > addr = devm_ioremap_resource(&pdev->dev, res);
> > irq = platform_get_irq_byname(pdev, "int0");
> >
> 
> regards,
> Marc
> 
> --
> Pengutronix e.K.  | Marc Kleine-Budde   |
> Industrial Linux Solutions| Phone: +49-231-2826-924 |
> Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
> Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


Best Regards,
Wenyou Yang

RE: [PATCH 1/2] can: m_can: Increase delay to ensure written INIT accepted

[Yang, Wenyou]

Hi Marc,

Thank you for prompt feedback.

> -Original Message-
> From: Marc Kleine-Budde [mailto:m...@pengutronix.de]
> Sent: 2015年11月18日 18:26
> To: Yang, Wenyou; Wolfgang Grandegger
> Cc: linux-...@vger.kernel.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Ferre, Nicolas
> Subject: Re: [PATCH 1/2] can: m_can: Increase delay to ensure written INIT
> accepted
> 
> On 11/18/2015 11:04 AM, Wenyou Yang wrote:
> > Increase the delay time until the value written to INIT can be read
> > back to ensure that the previous value written to INIT has been
> > accepted.

I tested it again with different clock frequencies, it works without this 
patch. Maybe I made a mistake.

Sorry about it. 

Please ignore.

> >
> > Signed-off-by: Wenyou Yang 
> 
> The patch looks ok, can you please add to your commit message which SoCs are
> affected by this problem.
> 
> > ---
> >
> >  drivers/net/can/m_can/m_can.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/can/m_can/m_can.c
> > b/drivers/net/can/m_can/m_can.c index ef65517..fd1caa0 100644
> > --- a/drivers/net/can/m_can/m_can.c
> > +++ b/drivers/net/can/m_can/m_can.c
> > @@ -320,7 +320,7 @@ static inline void m_can_config_endisable(const struct
> m_can_priv *priv,
> >   bool enable)
> >  {
> > u32 cccr = m_can_read(priv, M_CAN_CCCR);
> > -   u32 timeout = 10;
> > +   u32 timeout = 1000;
> > u32 val = 0;
> >
> > if (enable) {
> >
> 
> Marc
> 
> --
> Pengutronix e.K.  | Marc Kleine-Budde   |
> Industrial Linux Solutions| Phone: +49-231-2826-924 |
> Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
> Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


Best Regards,
Wenyou Yang

RE: [PATCH] MAINTAINERS: Atmel drivers: change NAND and ISI entries

[Yang, Wenyou]

> -Original Message-
> From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com]
> Sent: 2015年11月17日 18:22
> To: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org; Ferre, Nicolas; Desroches, Ludovic; Yang,
> Wenyou; Josh Wu
> Subject: [PATCH] MAINTAINERS: Atmel drivers: change NAND and ISI entries
> 
> Update Josh's entries about NAND and ISI drivers.
> Thanks for your work with Atmel Josh!
> 
> Signed-off-by: Nicolas Ferre 
> Cc: Ludovic Desroches 
> Cc: Wenyou Yang 
> Cc: Josh Wu 
Acked-by: Wenyou Yang 

> ---
>  MAINTAINERS | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e9caa4b28828..3c9d0d0ba0e8 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1931,7 +1931,7 @@ S:  Supported
>  F:   drivers/i2c/busses/i2c-at91.c
> 
>  ATMEL ISI DRIVER
> -M:   Josh Wu 
> +M:   Ludovic Desroches 
>  L:   linux-me...@vger.kernel.org
>  S:   Supported
>  F:   drivers/media/platform/soc_camera/atmel-isi.c
> @@ -1950,7 +1950,8 @@ S:  Supported
>  F:   drivers/net/ethernet/cadence/
> 
>  ATMEL NAND DRIVER
> -M:   Josh Wu 
> +M:   Wenyou Yang 
> +M:   Josh Wu 
>  L:   linux-...@lists.infradead.org
>  S:   Supported
>  F:   drivers/mtd/nand/atmel_nand*
> --
> 2.1.3


Best Regards,
Wenyou Yang

Re: [PATCH v2 03/14] clk: at91: make use of syscon/regmap internally

[Yang, Wenyou]

On 2015/10/12 22:28, Alexandre Belloni wrote:

diff --git a/drivers/clk/at91/clk-h32mx.c b/drivers/clk/at91/clk-h32mx.c
index 61566bcefa53..a0fe54a96031 100644
--- a/drivers/clk/at91/clk-h32mx.c
+++ b/drivers/clk/at91/clk-h32mx.c
@@ -24,6 +24,9 @@
  #include 
  #include 
  #include 
+#include 
+#include 
+#include 

Repeated  #include  .


Best Regards,
Wenyou Yang
--
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: [PATCH v2 10/14] ARM: at91: pm: find and remap the pmc

[Yang, Wenyou]

Hi Alexandre,

Trivial comments.

On 2015/10/12 22:28, Alexandre Belloni wrote:

To avoid relying on at91_pmc_read(), find the pmc node and remap it
locally.

Signed-off-by: Alexandre Belloni 
---
  arch/arm/mach-at91/pm.c | 32 ++--
  1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 5c2b60c5a2a1..1dee29b33ff9 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -35,6 +35,8 @@
  #include "generic.h"
  #include "pm.h"
  
+void __iomem *pmc;

+
  /*
   * FIXME: this is needed to communicate between the pinctrl driver and
   * the PM implementation in the machine. Possibly part of the PM
@@ -85,7 +87,7 @@ static int at91_pm_verify_clocks(void)
unsigned long scsr;
int i;
  
-	scsr = at91_pmc_read(AT91_PMC_SCSR);

+   scsr = readl(pmc + AT91_PMC_SCSR);
  
  	/* USB must not be using PLLB */

if ((scsr & at91_pm_data.uhp_udp_mask) != 0) {
@@ -99,8 +101,7 @@ static int at91_pm_verify_clocks(void)
  
  		if ((scsr & (AT91_PMC_PCK0 << i)) == 0)

continue;
-
-   css = at91_pmc_read(AT91_PMC_PCKR(i)) & AT91_PMC_CSS;
+   css = readl(pmc + AT91_PMC_PCKR(i)) & AT91_PMC_CSS;
if (css != AT91_PMC_CSS_SLOW) {
pr_err("AT91: PM - Suspend-to-RAM with PCK%d src %d\n", 
i, css);
return 0;
@@ -143,8 +144,8 @@ static void at91_pm_suspend(suspend_state_t state)
flush_cache_all();
outer_disable();
  
-	at91_suspend_sram_fn(at91_pmc_base, at91_ramc_base[0],

-   at91_ramc_base[1], pm_data);
+   at91_suspend_sram_fn(pmc, at91_ramc_base[0],
+at91_ramc_base[1], pm_data);
  
  	outer_resume();

  }
@@ -394,13 +395,32 @@ static void __init at91_pm_sram_init(void)
&at91_pm_suspend_in_sram, at91_pm_suspend_in_sram_sz);
  }
  
+static const struct of_device_id atmel_pmc_ids[] = {

+   { .compatible = "atmel,at91rm9200-pmc"  },
+   { .compatible = "atmel,at91sam9260-pmc" },
+   { .compatible = "atmel,at91sam9g45-pmc" },
+   { .compatible = "atmel,at91sam9n12-pmc" },
+   { .compatible = "atmel,at91sam9x5-pmc" },
+   { .compatible = "atmel,sama5d3-pmc" },
+   { /* sentinel */ },

Do we need  compatible for sama5d2 pmc used in sama5d2.dtsi?
{ .compatible = "atmel,sama5d2-pmc" },


+};
+
  static void __init at91_pm_init(void)
  {
-   at91_pm_sram_init();
+   struct device_node *pmc_np;
  
  	if (at91_cpuidle_device.dev.platform_data)

platform_device_register(&at91_cpuidle_device);
  
+	pmc_np = of_find_matching_node(NULL, atmel_pmc_ids);

+   pmc = of_iomap(pmc_np, 0);
+   if (!pmc) {
+   pr_info("AT91: PM not supported, PMC not found");

Should need "\n" before end of printout.


+   return;
+   }
+
+   at91_pm_sram_init();
+
if (at91_suspend_sram_fn)
suspend_set_ops(&at91_pm_ops);
else


Best Regards,
Wenyou Yang
--
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: [PATCH 2/2] ARM: at91/pm: add ultra Low-power mode 1(ULP1) support

[Yang, Wenyou]

Hi Alexandre,

Sorry for late answer.

> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: 2015年10月15日 21:22
> To: Yang, Wenyou
> Cc: Ferre, Nicolas; Jean-Christophe Plagniol-Villard; Russell King; Stephen 
> Boyd;
> Michael Turquette; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH 2/2] ARM: at91/pm: add ultra Low-power mode 1(ULP1)
> support
> 
> Hello Wenyou,
> 
> On 15/10/2015 at 11:41:07 +0800, Wenyou Yang wrote :
> > +#define ULP0_MODE  0x00
> > +#define ULP1_MODE  0x11
> 
> Those are not used.
> 
> > +static void at91_config_ulp1_wkup_source(void)
> > +{
> > +   if (at91_pmc_read(AT91_PMC_VERSION) >= SAMA5D2_PMC_VERSION)
> {
> > +   at91_pmc_write(AT91_PMC_FSMR, AT91_PMC_RTCAL |
> > + AT91_PMC_FSTT9 |
> > + AT91_PMC_FSTT8 |
> > + AT91_PMC_FSTT7 |
> > + AT91_PMC_FSTT6 |
> > + AT91_PMC_FSTT5 |
> > + AT91_PMC_FSTT4 |
> > + AT91_PMC_FSTT3 |
> > + AT91_PMC_FSTT2 |
> > + AT91_PMC_FSTT0);
> > +
> > +   at91_pmc_write(AT91_PMC_FSPR, 0);
> 
> Shouldn't those be configured from irq_set_wake() in the aic driver instead of
> activating all the wakeup sources?
> I think you need to get the PMC syscon from the aic5 driver and implement a 
> new
> irq_set_wake function when you can find the sam5d2 pmc.
I understand these code should not be here,  but I don't think those should be 
configured from irq_set_wake().
As said in datasheet, those configuration is to trigger a fast restart signal 
to the PMC. I think they should not be related to irq. 
 
> 
> The PMC syscon is introduced with that series:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/376493.html
> 
> > @@ -140,6 +165,10 @@ static void at91_pm_suspend(suspend_state_t state)
> > pm_data |= (state == PM_SUSPEND_MEM) ?
> > AT91_PM_MODE(AT91_PM_SLOW_CLOCK) : 0;
> >
> > +   pm_data |= ((state == PM_SUSPEND_MEM) &&
> > +   (at91_pmc_read(AT91_PMC_VERSION) >=
> SAMA5D2_PMC_VERSION)) ?
> > +   AT91_PM_ULP(AT91_PM_ULP1_MODE) : 0;
> > +
> 
> I would prefer not relying on the AT91_PMC_VERSION. Also, you probably
> shouldn't read the register each time you go to suspend.
> Finally, this could be better written by testing state only once.
Yes, it is not good.
> 
> 
> > flush_cache_all();
> > outer_disable();
> >
> > diff --git a/arch/arm/mach-at91/pm.h b/arch/arm/mach-at91/pm.h index
> > 3fcf881..2e76745 100644
> > --- a/arch/arm/mach-at91/pm.h
> > +++ b/arch/arm/mach-at91/pm.h
> > @@ -39,4 +39,11 @@ extern void __iomem *at91_ramc_base[];
> >
> >  #defineAT91_PM_SLOW_CLOCK  0x01
> >
> > +#define AT91_PM_ULP_OFFSET 5
> > +#define AT91_PM_ULP_MASK   0x03
> > +#define AT91_PM_ULP(x) (((x) & AT91_PM_ULP_MASK) <<
> AT91_PM_ULP_OFFSET)
> > +
> > +#define AT91_PM_ULP0_MODE  0x00
> > +#define AT91_PM_ULP1_MODE  0x01
> > +
> >  #endif
> > diff --git a/arch/arm/mach-at91/pm_suspend.S
> > b/arch/arm/mach-at91/pm_suspend.S index 825347b..543c430 100644
> > --- a/arch/arm/mach-at91/pm_suspend.S
> > +++ b/arch/arm/mach-at91/pm_suspend.S
> > @@ -41,6 +41,15 @@ tmp2 .reqr5
> > .endm
> >
> >  /*
> > + * Wait for main oscillator selection is done  */
> > +   .macro wait_moscsels
> > +1: ldr tmp1, [pmc, #AT91_PMC_SR]
> > +   tst tmp1, #AT91_PMC_MOSCSELS
> > +   beq 1b
> > +   .endm
> > +
> > +/*
> >   * Wait until PLLA has locked.
> >   */
> > .macro wait_pllalock
> > @@ -99,6 +108,10 @@ ENTRY(at91_pm_suspend_in_sram)
> > and r0, r0, #AT91_PM_MODE_MASK
> > str r0, .pm_mode
> >
> > +   lsr r0, r3, #AT91_PM_ULP_OFFSET
> > +   and r0, r0, #AT91_PM_ULP_MASK
> > +   str r0, .ulp_mode
> > +
> > /* Active the self-refresh mode */
> > mov r0, #SRAMC_SELF_FRESH_ACTIVE
> > bl  at91_sramc_self_refresh
> > @@ -107,6 +120,14 @@ ENTRY(at91_pm_suspend_in_sram)
> > tst r0, #AT91_PM_SLOW_CLOCK
> > beq 

RE: [PATCH 6/6] watchdog: sama5d4: try to set timeout from device tree first

[Yang, Wenyou]

> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: 2015年10月12日 15:50
> To: Sylvain Rochet
> Cc: Guenter Roeck; Boris BREZILLON; linux-kernel@vger.kernel.org; Ferre,
> Nicolas; Desroches, Ludovic; linux-arm-ker...@lists.infradead.org; Yang,
> Wenyou; Wim Van Sebroeck
> Subject: Re: [PATCH 6/6] watchdog: sama5d4: try to set timeout from device 
> tree
> first
> 
> Hi Sylvain,
> 
> The rest of the series looks good to me, one comment below:
> 
> On 08/10/2015 at 23:34:34 +0200, Sylvain Rochet wrote :
> > watchdog_init_timeout function doesn't try to get the "timeout-sec" DT
> > property if timeout_parm is not zero. This change makes this DT
> > property working for the sama5d4 watchdog driver.
> >
> 
> While I'm not sure of the feasibility, I think that the module parameter 
> should
> override the DT property.

The patch should be right, the DT property overrides the module parameter.

If the DT property is not a valid value, it uses the default value,  
initialized with the module parameter at the beginning of probe.

> 
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering http://free-electrons.com

Best Regards,
Wenyou Yang

RE: [PATCH] rtc: at91rm9200: clear RTC alarm status flag prior to suspending

[Yang, Wenyou]

> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: 2015年10月12日 15:51
> To: Yang, Wenyou
> Cc: Alessandro Zummo; Ferre, Nicolas; Desroches, Ludovic; rtc-
> li...@googlegroups.com; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH] rtc: at91rm9200: clear RTC alarm status flag prior to
> suspending
> 
> On 12/10/2015 at 07:48:18 +, Yang, Wenyou wrote :
> > > On 12/10/2015 at 09:17:57 +0800, Wenyou Yang wrote :
> > > > This patch is to clear the RTC alarm status flag prior to
> > > > suspending to avoid the erroneous wake-up activity.
> > > >
> > >
> > > Is this a new issue appearing with the sama5d2 or was it present
> > > from the beginning?
> > With the sama5d2 ULP1 mode, not from the beginning.
> >
> 
> I think this information should appear in the commit log.
I will add it in the next version, thanks.

> 
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering http://free-electrons.com

Best Regards,
Wenyou Yang

RE: [PATCH] rtc: at91rm9200: clear RTC alarm status flag prior to suspending

[Yang, Wenyou]

Hi Alexandre,

> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: 2015年10月12日 14:53
> To: Yang, Wenyou
> Cc: Alessandro Zummo; Ferre, Nicolas; Desroches, Ludovic; rtc-
> li...@googlegroups.com; linux-kernel@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH] rtc: at91rm9200: clear RTC alarm status flag prior to
> suspending
> 
> Hi Wenyou,
> 
> On 12/10/2015 at 09:17:57 +0800, Wenyou Yang wrote :
> > This patch is to clear the RTC alarm status flag prior to suspending
> > to avoid the erroneous wake-up activity.
> >
> 
> Is this a new issue appearing with the sama5d2 or was it present from the
> beginning?
With the sama5d2 ULP1 mode, not from the beginning.

> 
> > Signed-off-by: Wenyou Yang 
> > ---
> >
> >  drivers/rtc/rtc-at91rm9200.c |2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/rtc/rtc-at91rm9200.c
> > b/drivers/rtc/rtc-at91rm9200.c index cb62e21..b60fd47 100644
> > --- a/drivers/rtc/rtc-at91rm9200.c
> > +++ b/drivers/rtc/rtc-at91rm9200.c
> > @@ -495,6 +495,8 @@ static int at91_rtc_suspend(struct device *dev)
> > /* this IRQ is shared with DBGU and other hardware which isn't
> >  * necessarily doing PM like we are...
> >  */
> > +   at91_rtc_write(AT91_RTC_SCCR, AT91_RTC_ALARM);
> > +
> > at91_rtc_imr = at91_rtc_read_imr()
> > & (AT91_RTC_ALARM|AT91_RTC_SECEV);
> > if (at91_rtc_imr) {
> > --
> > 1.7.9.5
> >
> 
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

Best Regards,
Wenyou Yang

RE: [PATCH] ARM: at91/dt: sama5d3 xplained: disable pmic

[Yang, Wenyou]

> -Original Message-
> From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com]
> Sent: 2015年9月10日 22:59
> To: Yang, Wenyou; Alexandre Belloni; Jean-Christophe PLAGNIOL-VILLARD
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; Ferre,
> Nicolas
> Subject: [PATCH] ARM: at91/dt: sama5d3 xplained: disable pmic
> 
> As PMIC act8865 can disturb communication on i2c1, and as it should be setup
> correctly then its i2c interface disabled by bootloader, we simply disregard 
> it in DT.
> 
> Signed-off-by: Nicolas Ferre 

Indeed,

Acked-by: Wenyou Yang 

> ---
>  arch/arm/boot/dts/at91-sama5d3_xplained.dts | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/at91-sama5d3_xplained.dts 
> b/arch/arm/boot/dts/at91-
> sama5d3_xplained.dts
> index d81474e0bcd6..8488ac53d22d 100644
> --- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> +++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
> @@ -76,7 +76,7 @@
>   pmic: act8865@5b {
>   compatible = "active-semi,act8865";
>   reg = <0x5b>;
> - status = "okay";
> + status = "disabled";
> 
>   regulators {
>   vcc_1v8_reg: DCDC_REG1 {
> --
> 2.1.3

Best Regards,
Wenyou Yang

RE: [PATCH v6 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer

[Yang, Wenyou]

> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 2015年8月7日 23:26
> To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
> Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free-
> electrons.com; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> linux-
> watch...@vger.kernel.org
> Subject: Re: [PATCH v6 1/2] drivers: watchdog: add a driver to support SAMA5D4
> watchdog timer
> 
> On 08/06/2015 03:16 AM, Wenyou Yang wrote:
> >>From SAMA5D4, the watchdog timer is upgrated with a new feature,
> > which is describled as in the datasheet, "WDT_MR can be written until
> > a LOCKMR command is issued in WDT_CR".
> > That is to say, as long as the bootstrap and u-boot don't issue a
> > LOCKMR command, WDT_MR can be written more than once in the driver.
> >
> > So the SAMA5D4 watchdog driver's implementation is different from the
> > at91sam9260 watchdog driver implemented in file at91sam9_wdt.c.
> > The user application open the device file to enable the watchdog timer
> > hardware, and close to disable it, and set the watchdog timer timeout
> > by seting WDV and WDD fields of WDT_MR register, and ping the watchdog
> > by issuing WDRSTT command to WDT_CR register with hard-coded key.
> >
> > Signed-off-by: Wenyou Yang 
> 
> Reviewed-by: Guenter Roeck 

Hi Vim,

Can this patch series be merged? Could you please?

Best Regards,
Wenyou Yang

RE: [PATCH v5 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer

[Yang, Wenyou]

Hi Guenter,

> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 2015年8月6日 18:00
> To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
> Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free-
> electrons.com; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> linux-
> watch...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v5 1/2] drivers: watchdog: add a driver to support SAMA5D4
> watchdog timer
> 
> Hi,
> 
> On 08/06/2015 01:34 AM, Wenyou Yang wrote:
> >>From SAMA5D4, the watchdog timer is upgrated with a new feature,
> 
> Where does the additional ">" come from ?
I don't know why, but it isn't inclusive in my received mail.

> 
> > which is describled as in the datasheet, "WDT_MR can be written until
> > a LOCKMR command is issued in WDT_CR".
> > That is to say, as long as the bootstrap and u-boot don't issue a
> > LOCKMR command, WDT_MR can be written more than once in the driver.
> >
> > So the SAMA5D4 watchdog driver's implementation is different from the
> > at91sam9260 watchdog driver implemented in file at91sam9_wdt.c.
> > The user application open the device file to enable the watchdog timer
> > hardware, and close to disable it, and set the watchdog timer timeout
> > by seting WDV and WDD fields of WDT_MR register, and ping the watchdog
> > by issuing WDRSTT command to WDT_CR register with hard-coded key.
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> >   drivers/watchdog/Kconfig|9 ++
> >   drivers/watchdog/Makefile   |1 +
> >   drivers/watchdog/at91sam9_wdt.h |2 +
> >   drivers/watchdog/sama5d4_wdt.c  |  280
> +++
> >   4 files changed, 292 insertions(+)
> >   create mode 100644 drivers/watchdog/sama5d4_wdt.c
> >
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index
> > e5e7c55..47ad39a 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -167,6 +167,15 @@ config AT91SAM9X_WATCHDOG
> >   Watchdog timer embedded into AT91SAM9X and AT91CAP9 chips. This
> will
> >   reboot your system when the timeout is reached.
> >
> > +config SAMA5D4_WATCHDOG
> > +   tristate "Atmel SAMA5D4 Watchdog Timer"
> > +   depends on ARCH_AT91
> > +   select WATCHDOG_CORE
> > +   help
> > + Atmel SAMA5D4 watchdog timer is embedded into SAMA5D4 chips.
> > + Its Watchdog Timer Mode Register can be written more than once.
> > + This will reboot your system when the timeout is reached.
> > +
> >   config CADENCE_WATCHDOG
> > tristate "Cadence Watchdog Timer"
> > select WATCHDOG_CORE
> > diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> > index 5c19294..f24b820 100644
> > --- a/drivers/watchdog/Makefile
> > +++ b/drivers/watchdog/Makefile
> > @@ -41,6 +41,7 @@ obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o
> >   obj-$(CONFIG_KS8695_WATCHDOG) += ks8695_wdt.o
> >   obj-$(CONFIG_S3C2410_WATCHDOG) += s3c2410_wdt.o
> >   obj-$(CONFIG_SA1100_WATCHDOG) += sa1100_wdt.o
> > +obj-$(CONFIG_SAMA5D4_WATCHDOG) += sama5d4_wdt.o
> >   obj-$(CONFIG_DW_WATCHDOG) += dw_wdt.o
> >   obj-$(CONFIG_EP93XX_WATCHDOG) += ep93xx_wdt.o
> >   obj-$(CONFIG_PNX4008_WATCHDOG) += pnx4008_wdt.o diff --git
> > a/drivers/watchdog/at91sam9_wdt.h b/drivers/watchdog/at91sam9_wdt.h
> > index c6fbb2e6..b79a83b 100644
> > --- a/drivers/watchdog/at91sam9_wdt.h
> > +++ b/drivers/watchdog/at91sam9_wdt.h
> > @@ -22,11 +22,13 @@
> >
> >   #define AT91_WDT_MR   0x04/* Watchdog
> Mode Register */
> >   #define   AT91_WDT_WDV(0xfff << 0)/*
> Counter Value */
> > +#defineAT91_WDT_SET_WDV(x) ((x) &
> AT91_WDT_WDV)
> >   #define   AT91_WDT_WDFIEN (1 << 12)   /*
> Fault Interrupt Enable */
> >   #define   AT91_WDT_WDRSTEN(1 << 13)   /*
> Reset Processor */
> >   #define   AT91_WDT_WDRPROC(1 << 14)   /*
> Timer Restart */
> >   #define   AT91_WDT_WDDIS  (1 << 15)   /*
> Watchdog Disable */
> >   #define   AT91_WDT_WDD(0xfff << 16)   /*
> Delta Value */
> > +#defineAT91_WDT_SET_WDD(x) (((x) << 1

RE: [PATCH v4 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer

[Yang, Wenyou]

Hi Guenter,

Thank you for your correct.

> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 2015年8月6日 16:05
> To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
> Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free-
> electrons.com; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> linux-
> watch...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v4 1/2] drivers: watchdog: add a driver to support SAMA5D4
> watchdog timer
> 
> On 08/05/2015 09:59 PM, Wenyou Yang wrote:
> >>From SAMA5D4, the watchdog timer is upgrated with a new feature,
> > which is describled as in the datasheet, "WDT_MR can be written until
> > a LOCKMR command is issued in WDT_CR".
> > That is to say, as long as the bootstrap and u-boot don't issue a
> > LOCKMR command, WDT_MR can be written more than once in the driver.
> >
> > So the SAMA5D4 watchdog driver's implementation is different from the
> > at91sam9260 watchdog driver implemented in file at91sam9_wdt.c.
> > The user application open the device file to enable the watchdog timer
> > hardware, and close to disable it, and set the watchdog timer timeout
> > by seting WDV and WDD fields of WDT_MR register, and ping the watchdog
> > by issuing WDRSTT command to WDT_CR register with hard-coded key.
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> [ ... ]
> > +
> > +/* minimum and maximum watchdog timeout, in seconds */
> > +#defineMIN_WDT_TIMEOUT 1
> > +#defineMAX_WDT_TIMEOUT 16
> > +#defineWDT_DEFAULT_TIMEOUT MAX_WDT_TIMEOUT
> > +
> > +#defineWDT_SEC2TICKS(s)((s) ? (((s) << 8) - 1) : 0)
> > +
> 
> Why did you replace the spaces after #define with tabs ?
> I understand this is done in the at91.h file, but that is bad enough, it 
> doesn't add
> any value, and I don't see a reason to do it here.
Accepted, Using spaces, not tabs.

> 
> > +
> > +   if ((wdt->config & AT91_WDT_WDFIEN) && irq) {
> > +   ret = devm_request_irq(&pdev->dev, irq,
> sama5d4_wdt_irq_handler,
> > +  0, pdev->name, pdev);
> 
> I just realized - this interrupt is registered with flags set to 0, while in 
> the at91sam
> driver the flags are "IRQF_SHARED | IRQF_IRQPOLL | IRQF_NO_SUSPEND". Is
> this different with the new SOC ?
No, it is same. It is my carelessness.

> 
> Thanks,
> Guenter


Best Regards,
Wenyou Yang

RE: [PATCH v3 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer

[Yang, Wenyou]

Hi Guenter,

Thank you for your review.

> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 2015年8月5日 23:05
> To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
> Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free-
> electrons.com; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> linux-
> watch...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v3 1/2] drivers: watchdog: add a driver to support SAMA5D4
> watchdog timer
> 
> On 08/05/2015 01:57 AM, Wenyou Yang wrote:
> >>From SAMA5D4, the watchdog timer is upgrated with a new feature,
> > which is describled as in the datasheet, "WDT_MR can be written until
> > a LOCKMR command is issued in WDT_CR".
> > That is to say, as long as the bootstrap and u-boot don't issue a
> > LOCKMR command, WDT_MR can be written more than once in the driver.
> >
> > So the SAMA5D4 watchdog driver's implementation is different from the
> > at91sam9260 watchdog driver implemented in file at91sam9_wdt.c.
> > The user application open the device file to enable the watchdog timer
> > hardware, and close to disable it, and set the watchdog timer timeout
> > by seting WDV and WDD fields of WDT_MR register, and ping the watchdog
> > by issuing WDRSTT command to WDT_CR register with hard-coded key.
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> >   drivers/watchdog/Kconfig|9 ++
> >   drivers/watchdog/Makefile   |1 +
> >   drivers/watchdog/at91_sama5d4_wdt.c |  279
> +++
> >   drivers/watchdog/at91sam9_wdt.h |2 +
> >   4 files changed, 291 insertions(+)
> >   create mode 100644 drivers/watchdog/at91_sama5d4_wdt.c
> >
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index
> > e5e7c55..4ce8346 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -152,6 +152,15 @@ config ARM_SP805_WATCHDOG
> >   ARM Primecell SP805 Watchdog timer. This will reboot your system
> when
> >   the timeout is reached.
> >
> > +config AT91_SAMA5D4_WATCHDOG
> 
> Looking into the chip ordering documentation. The chip goes by ATSAMA5D4,
> while the other chips go by AT91SAM9xxx.
> 
> So I think ATSAMA5D4 would be better (same for the driver name).
Use SAMA5D4 directly, the chip name.

> 
> Couple of additional nitpicks below.
I will change it in the next version, thanks.

> 
> Thanks,
> Guenter
> 
> > +   tristate "Atmel SAMA5D4 Watchdog Timer"
> > +   depends on ARCH_AT91
> > +   select WATCHDOG_CORE
> > +   help
> > + Atmel SAMA5D4 watchdog timer is embedded into SAMA5D4 chips.
> > + Its Watchdog Timer Mode Register can be written more than once.
> > + This will reboot your system when the timeout is reached.
> > +
> >   config AT91RM9200_WATCHDOG
> > tristate "AT91RM9200 watchdog"
> > depends on SOC_AT91RM9200 && MFD_SYSCON diff --git
> > a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index
> > 5c19294..c57569c 100644
> > --- a/drivers/watchdog/Makefile
> > +++ b/drivers/watchdog/Makefile
> > @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
> >
> >   # ARM Architecture
> >   obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
> > +obj-$(CONFIG_AT91_SAMA5D4_WATCHDOG) += at91_sama5d4_wdt.o
> >   obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
> >   obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
> >   obj-$(CONFIG_CADENCE_WATCHDOG) += cadence_wdt.o diff --git
> > a/drivers/watchdog/at91_sama5d4_wdt.c
> > b/drivers/watchdog/at91_sama5d4_wdt.c
> > new file mode 100644
> > index 000..f2e1995
> > --- /dev/null
> > +++ b/drivers/watchdog/at91_sama5d4_wdt.c
> > @@ -0,0 +1,279 @@
> > +/*
> > + * Driver for Atmel SAMA5D4 Watchdog Timer
> > + *
> > + * Copyright (C) 2015 Atmel Corporation
> > + *
> > + * Licensed under GPLv2.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "at91sam9_wdt.h"
> > +
> > +/* minimum and maximum watchdog timeout, in seconds */
> > +#define MIN_WDT_TIMEOUT1
> > +#define MAX_WDT_TIMEOUT16
> > +#define WDT_DEFAULT_TIMEOUTMAX_WDT_TIMEOUT
> > +

RE: [PATCH v3 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer

[Yang, Wenyou]

Hi Lothar,

Thank you for your review.

> -Original Message-
> From: Lothar Waßmann [mailto:l...@karo-electronics.de]
> Sent: 2015年8月5日 18:41
> To: Yang, Wenyou
> Cc: w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org;
> boris.brezil...@free-electrons.com; linux-watch...@vger.kernel.org;
> devicet...@vger.kernel.org; sylvain.roc...@finsecur.com; Ferre, Nicolas; 
> linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v3 1/2] drivers: watchdog: add a driver to support SAMA5D4
> watchdog timer
> 
> Hi,
> 
> > From SAMA5D4, the watchdog timer is upgrated with a new feature, which
> > is describled as in the datasheet, "WDT_MR can be written until a
> > LOCKMR command is issued in WDT_CR".
> > That is to say, as long as the bootstrap and u-boot don't issue a
> > LOCKMR command, WDT_MR can be written more than once in the driver.
> >
> > So the SAMA5D4 watchdog driver's implementation is different from the
> > at91sam9260 watchdog driver implemented in file at91sam9_wdt.c.
> > The user application open the device file to enable the watchdog timer
> > hardware, and close to disable it, and set the watchdog timer timeout
> > by seting WDV and WDD fields of WDT_MR register, and ping the watchdog
> > by issuing WDRSTT command to WDT_CR register with hard-coded key.
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> >  drivers/watchdog/Kconfig|9 ++
> >  drivers/watchdog/Makefile   |1 +
> >  drivers/watchdog/at91_sama5d4_wdt.c |  279
> +++
> >  drivers/watchdog/at91sam9_wdt.h |2 +
> >  4 files changed, 291 insertions(+)
> >  create mode 100644 drivers/watchdog/at91_sama5d4_wdt.c
> >
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index
> > e5e7c55..4ce8346 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -152,6 +152,15 @@ config ARM_SP805_WATCHDOG
> >   ARM Primecell SP805 Watchdog timer. This will reboot your system
> when
> >   the timeout is reached.
> >
> > +config AT91_SAMA5D4_WATCHDOG
> > +   tristate "Atmel SAMA5D4 Watchdog Timer"
> > +   depends on ARCH_AT91
> > +   select WATCHDOG_CORE
> > +   help
> > + Atmel SAMA5D4 watchdog timer is embedded into SAMA5D4 chips.
> > + Its Watchdog Timer Mode Register can be written more than once.
> > + This will reboot your system when the timeout is reached.
> > +
> >  config AT91RM9200_WATCHDOG
> > tristate "AT91RM9200 watchdog"
> > depends on SOC_AT91RM9200 && MFD_SYSCON diff --git
> > a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index
> > 5c19294..c57569c 100644
> > --- a/drivers/watchdog/Makefile
> > +++ b/drivers/watchdog/Makefile
> > @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
> >
> >  # ARM Architecture
> >  obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
> > +obj-$(CONFIG_AT91_SAMA5D4_WATCHDOG) += at91_sama5d4_wdt.o
> consistency? Other AT91 entries don't have an '_' between 'AT91' and the
> remainder of the Kconfig name.
Accept, Remove the prefix AT91_ , use the chip name directly, SAMA5D4 in next 
verison.

> 
> >  obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.ovi 
> >  obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
> [...]
> > +static irqreturn_t atmel_wdt_irq_handler(int irq, void *dev_id) {
> > +   struct atmel_wdt *wdt = platform_get_drvdata(dev_id);
> > +
> > +   if (wdt_read(wdt, AT91_WDT_SR)) {
> > +   pr_crit("Atmel Watchdog Software Reset\n");
> > +   emergency_restart();
> > +   pr_crit("Reboot didn't ?\n");
> >
> Reboot didn't what? 'succeed' perhaps?
Replace it with 'succeed' in next version. 

> 
> > +static const struct of_device_id atmel_wdt_of_match[] = {
> > +   { .compatible = "atmel,sama5d4-wdt", },
> > +   { },
> The empty initializer must always be the last element of the array, so there 
> is no
> point in having a trailing ',' (whose purpose is to facilitate adding more 
> entries after
> the last one).
> Without the comma there will be a compile error if (e.g. due to a badly 
> resolved
> merge conflict) an additional entry would be added after the stop marker. 
> With the
> comma after the stop marker any trailing entries would silently be ignored.
Remove this comma in next version.

> 
> 
> Lothar Waßmann
> --
> ___
> 
> Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
> Geschäftsführer: Matthias Kaussen
> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
> 
> www.karo-electronics.de | i...@karo-electronics.de
> ___

Best Regards,
Wenyou 

RE: [PATCH v2 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer

[Yang, Wenyou]

Hi Guenter,

Thank you very much for your review.

I will send a new version to resolve them.

> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 2015年8月5日 14:14
> To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
> Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free-
> electrons.com; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> linux-
> watch...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v2 1/2] drivers: watchdog: add a driver to support SAMA5D4
> watchdog timer
> 
> On 08/04/2015 07:35 PM, Wenyou Yang wrote:
> >>From SAMA5D4, the watchdog timer is upgrated with a new feature,
> > which is describled as in the datasheet, "WDT_MR can be written until
> > a LOCKMR command is issued in WDT_CR".
> > That is to say, as long as the bootstrap and u-boot don't issue a
> > LOCKMR command, WDT_MR can be written more than once in the driver.
> >
> > So the SAMA5D4 watchdog driver's implementation is different from the
> > previous: the user application open the device file to enable
> 
> Which previous ? Please let the reader know which one you refer to.
> 
> > the watchdog timer hardware, and close to disable it, and set the
> > watchdog timer timeout by seting WDV and WDD fields of WDT_MR
> > register, and ping the watchdog by issuing WDRSTT command to WDT_CR
> > register with hard-coded key.
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> >   drivers/watchdog/Kconfig|9 ++
> >   drivers/watchdog/Makefile   |1 +
> >   drivers/watchdog/at91sam9_wdt.h |4 +
> >   drivers/watchdog/atmel_wdt.c|  290
> +++
> >   4 files changed, 304 insertions(+)
> >   create mode 100644 drivers/watchdog/atmel_wdt.c
> >
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index
> > e5e7c55..4425813 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -152,6 +152,15 @@ config ARM_SP805_WATCHDOG
> >   ARM Primecell SP805 Watchdog timer. This will reboot your system
> when
> >   the timeout is reached.
> >
> > +config ATMEL_WATCHDOG
> > +   tristate "Atmel SAMA5D4 Watchdog Timer"
> > +   depends on ARCH_AT91
> > +   select WATCHDOG_CORE
> > +   help
> > + Atmel watchdog timer embedded into SAMA5D4 chips. Its Watchdog
> Timer
> > + Mode Register(WDT_MR) can be written more than once.
> > + This will reboot your system when the timeout is reached.
> > +
> 
> ATMEL is highly generic. Can you find a more specific name ?
> If this is part of the AT91 family, it could be something like AT91SAMAD54, 
> for
> example.
> 
> Same goes for the driver name.
> 
> >   config AT91RM9200_WATCHDOG
> > tristate "AT91RM9200 watchdog"
> > depends on SOC_AT91RM9200 && MFD_SYSCON diff --git
> > a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index
> > 5c19294..c24a8fc 100644
> > --- a/drivers/watchdog/Makefile
> > +++ b/drivers/watchdog/Makefile
> > @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
> >
> >   # ARM Architecture
> >   obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
> > +obj-$(CONFIG_ATMEL_WATCHDOG) += atmel_wdt.o
> >   obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
> >   obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
> >   obj-$(CONFIG_CADENCE_WATCHDOG) += cadence_wdt.o diff --git
> > a/drivers/watchdog/at91sam9_wdt.h b/drivers/watchdog/at91sam9_wdt.h
> > index c6fbb2e6..79add4f 100644
> > --- a/drivers/watchdog/at91sam9_wdt.h
> > +++ b/drivers/watchdog/at91sam9_wdt.h
> > @@ -22,11 +22,15 @@
> >
> >   #define AT91_WDT_MR   0x04/* Watchdog
> Mode Register */
> >   #define   AT91_WDT_WDV(0xfff << 0)/*
> Counter Value */
> > +#defineAT91_WDT_WDV_MSK(0xfff)
> 
> The ( ) is not necessary. AT91_WDT_WDV is already used as mask.
> You should not need a second one.
> 
> > +#defineAT91_WDT_WDV_(x)(((x) &
> AT91_WDT_WDV_MSK) << 0)
> 
> Please no '_' at the end of the macro name; find another name that isn't as 
> close to
> AT91_WDT_WDV.
> 
> >   #define   AT91_WDT_WDFIEN (1 << 12)   /*
> Fault Interrupt Enable */
> >   #define   AT91_WDT_WD

RE: [PATCH 1/2] drivers: watchdog: at91sam9_wdt: add new feature support

[Yang, Wenyou]

Hi Guenter,

Thank you for your prompt answer.

> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 2015年7月29日 9:23
> To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
> Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free-
> electrons.com; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> linux-
> watch...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 1/2] drivers: watchdog: at91sam9_wdt: add new feature
> support
> 
> On 07/28/2015 05:38 PM, Yang, Wenyou wrote:
> > Hi Guenter,
> >
> > Thank you very much for your review.
> >
> >> -Original Message-
> >> From: Guenter Roeck [mailto:li...@roeck-us.net]
> >> Sent: 2015年7月28日 15:14
> >> To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org;
> >> pawel.m...@arm.com; mark.rutl...@arm.com;
> >> ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
> >> Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas;
> >> boris.brezillon@free- electrons.com; devicet...@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; linux- watch...@vger.kernel.org;
> >> linux-arm-ker...@lists.infradead.org
> >> Subject: Re: [PATCH 1/2] drivers: watchdog: at91sam9_wdt: add new
> >> feature support
> >>
> >> On 07/28/2015 12:00 AM, Wenyou Yang wrote:
> >>> In the datasheet, the new feature is describled as "WDT_MR can be
> >>> written until a LOCKMR command is issued in WDT_CR".
> >>> That is to say, as long as the bootstrap and u-boot don't issue a
> >>> LOCKMR command, WDT_MR can be written in kernel.
> >>>
> >>> So the driver can enable/disable the watchdog timer hardware, set
> >>> WDV(Watchdog Counter Value) and WDD(Watchdog Delta Value) fields of
> >>> WDT_MR register to set the watchdog timer timeout.
> >>>
> >>> The timer is not necessary that regularly sends a keepalive ping to
> >>> the watchdog timer hardware.
> >>>
> >>> It is introduced from sama5d4 SoCs.
> >>>
> >> Since there are so many changes, I wonder is a separate driver would
> >> make more sense.
> > Yes, a bit many changes.
> > I thought reuse the driver code.
> > If a separate driver, I am afraid it includes much duplicated code.
> > After all, it is for the same device with different feature.
> >
> > I don't think it is necessary to have multiple drivers for the same 
> > peripheral with
> different feature.
> >
> 
> The concept for the two mechanisms is all different: In one, the watchdog
> keepalive is triggered from timer code. In the other, the watchdog timeout is
> triggered directly from the heartbeat function. One assumes that the watchdog 
> is
> always running, and that it must be pinged even if closed. The other disables 
> the
> watchdog on close.
> 
> What I _can_ see is that the driver is becoming an unmaintainable mess, with 
> lots
> of if/else in pretty much every function. I consider this much less desirable 
> than a
> bit of code duplication - if there is any. Seriously, most of the added code 
> might as
> well be for a completely different chip.

You are right, I accepted your advice. I will rewrite it. Thanks.

> 
> Guenter

Best Regards,
Wenyou Yang

RE: [PATCH 1/2] drivers: watchdog: at91sam9_wdt: add new feature support

[Yang, Wenyou]

Hi Guenter,

Thank you very much for your review.

> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 2015年7月28日 15:14
> To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
> Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free-
> electrons.com; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; 
> linux-
> watch...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 1/2] drivers: watchdog: at91sam9_wdt: add new feature
> support
> 
> On 07/28/2015 12:00 AM, Wenyou Yang wrote:
> > In the datasheet, the new feature is describled as "WDT_MR can be
> > written until a LOCKMR command is issued in WDT_CR".
> > That is to say, as long as the bootstrap and u-boot don't issue a
> > LOCKMR command, WDT_MR can be written in kernel.
> >
> > So the driver can enable/disable the watchdog timer hardware, set
> > WDV(Watchdog Counter Value) and WDD(Watchdog Delta Value) fields of
> > WDT_MR register to set the watchdog timer timeout.
> >
> > The timer is not necessary that regularly sends a keepalive ping to
> > the watchdog timer hardware.
> >
> > It is introduced from sama5d4 SoCs.
> >
> Since there are so many changes, I wonder is a separate driver would make more
> sense.
Yes, a bit many changes.
I thought reuse the driver code.
If a separate driver, I am afraid it includes much duplicated code. 
After all, it is for the same device with different feature. 

I don't think it is necessary to have multiple drivers for the same peripheral 
with different feature.
 
> 
> Thoughts ?
> 
> Guenter
> 
> > Signed-off-by: Wenyou Yang 
> > ---
> >   drivers/watchdog/at91sam9_wdt.c |  255
> ---
> >   drivers/watchdog/at91sam9_wdt.h |4 +
> >   2 files changed, 190 insertions(+), 69 deletions(-)
> >
> > diff --git a/drivers/watchdog/at91sam9_wdt.c
> > b/drivers/watchdog/at91sam9_wdt.c index 1443b3c..6b61084 100644
> > --- a/drivers/watchdog/at91sam9_wdt.c
> > +++ b/drivers/watchdog/at91sam9_wdt.c
> > @@ -10,9 +10,12 @@
> >*/
> >
> >   /*
> > + * For AT91SAM9x SoCs, the Watchdog Timer has the following constraint.
> >* The Watchdog Timer Mode Register can be only written to once. If the
> >* timeout need to be set from Linux, be sure that the bootstrap or the
> >* bootloader doesn't write to this register.
> > + * From SAMA5D4, the Watchdog Timer Mode Register can be written
> > + * until a LOCKMR command is issued in WDT_CR.
> >*/
> >
> >   #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt @@ -80,6 +83,11 @@
> > MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started
> "
> > "(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
> >
> >   #define to_wdt(wdd) container_of(wdd, struct at91wdt, wdd)
> > +
> > +struct at91wdt_variant {
> > +   bool mr_writable;
> > +};
> > +
> >   struct at91wdt {
> > struct watchdog_device wdd;
> > void __iomem *base;
> > @@ -90,6 +98,9 @@ struct at91wdt {
> > unsigned long heartbeat;/* WDT heartbeat in jiffies */
> > bool nowayout;
> > unsigned int irq;
> > +   bool use_timer;
> > +   bool enabled;
> > +   struct at91wdt_variant *drv_data;
> >   };
> >
> >   /*
> > . 
> > */ @@ -133,21 +144,67 @@
> static void at91_ping(unsigned long data)
> >   static int at91_wdt_start(struct watchdog_device *wdd)
> >   {
> > struct at91wdt *wdt = to_wdt(wdd);
> > -   /* calculate when the next userspace timeout will be */
> > -   wdt->next_heartbeat = jiffies + wdd->timeout * HZ;
> > +   u32 reg;
> > +
> > +   if (wdt->drv_data->mr_writable) {
> > +   reg = wdt_read(wdt, AT91_WDT_MR);
> > +   reg &= ~AT91_WDT_WDDIS;
> > +   wdt_write(wdt, AT91_WDT_MR, reg);
> > +   } else {
> > +   /* calculate when the next userspace timeout will be */
> > +   wdt->next_heartbeat = jiffies + wdd->timeout * HZ;
> > +   }
> > +
> > return 0;
> >   }
> >
> >   static int at91_wdt_stop(struct watchdog_device *wdd)
> >   {
> > -   /* The watchdog timer hardware can not be stopped... */
> > +   struct at91wdt *wdt = to_wdt(wdd);
> > +   u32 reg;
> > +
> > +   if (wdt->drv_dat

RE: [PATCH v2.0 1/2] pm: at91: add the PM initialization for the sama5d3 and sama5d4

[Yang, Wenyou]

Hi Sylvain,

> -Original Message-
> From: Sylvain Rochet [mailto:sylvain.roc...@finsecur.com]
> Sent: 2015年3月16日 18:21
> To: Yang, Wenyou
> Cc: Ferre, Nicolas; li...@arm.linux.org.uk; 
> linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; alexandre.bell...@free-electrons.com;
> p...@axentia.se; sergei.shtyl...@cogentembedded.com; li...@maxim.org.za
> Subject: Re: [PATCH v2.0 1/2] pm: at91: add the PM initialization for the 
> sama5d3
> and sama5d4
> 
> Hello Wenyou,
> 
> On Mon, Mar 09, 2015 at 11:57:08AM +0800, Wenyou Yang wrote:
> > To get the mpddrc peripheral id from the PM initialization, which will
> > be used to disable mpddrc'c clock during suspending.
> 
> > +void __init sam5d3_pm_init(void)
> > +{
> > +   at91_dt_ramc();
> > +   at91_pm_data.uhp_udp_mask = AT91SAM926x_PMC_UHP |
> AT91SAM926x_PMC_UDP;
> > +   at91_pm_data.memctrl = AT91_MEMCTRL_DDRSDR;
> > +   at91_pm_data.ddrc_pid = SAMA5D3_ID_MPDDRC;
> > +   return at91_pm_init();
> > +}
> > +
> > +void __init sam5d4_pm_init(void)
> > +{
> > +   at91_dt_ramc();
> > +   at91_pm_data.uhp_udp_mask = AT91SAM926x_PMC_UHP |
> AT91SAM926x_PMC_UDP;
> > +   at91_pm_data.memctrl = AT91_MEMCTRL_DDRSDR;
> > +   at91_pm_data.ddrc_pid = SAMA5D4_ID_MPDDRC;
> > +   at91_pm_data.is_sama5d4 = true;
> > +   return at91_pm_init();
> > +}
> 
> > +static void __init sama5d4_dt_device_init(void) {
> > +   of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> > +   sam5d4_pm_init();
> > +}
> 
> This doesn't look right, where is sam5d3_pm_init() actually used ?
Oh, I missed it mindlessly during rebasing. I will added it in the next 
version. 

Sorry for being confused. 

> 
> Sylvain

Best Regards,
Wenyou Yang

RE: [PATCH v2.0 0/6] ARM: AT91: pm improvement for 4.1

[Yang, Wenyou]

> -Original Message-
> From: Ferre, Nicolas
> Sent: 2015年3月13日 18:06
> To: Yang, Wenyou; li...@arm.linux.org.uk
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> alexandre.bell...@free-electrons.com; sylvain.roc...@finsecur.com;
> p...@axentia.se; sergei.shtyl...@cogentembedded.com; li...@maxim.org.za
> Subject: Re: [PATCH v2.0 0/6] ARM: AT91: pm improvement for 4.1
> 
> Le 09/03/2015 04:47, Wenyou Yang a écrit :
> > Hi,
> >
> > The patch series purpose is to improve the AT91 pm code.
> > Create a procedure to handle the sdram self-fresh mode.
> > The standby mode uses same sram function as the suspend to memory
> > mode,
> >
> > It is based on the branch, at91-4.0-fixes
> > git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git
> > + [PATCH] ARM: AT91: pm cleanup for 4.1
> >
> > Chang log for v2.0
> >  - reserve the at91_xxx_standby() for at91_cpuidle_device.
> >  - rebase
> >
> > Wenyou Yang (6):
> >   pm: at91: pm_slowclock: create the procedure to handle the sdram
> > self-refresh
> >   pm: at91: move the copying the sram function to the sram
> > initializationi phase
> >   pm: at91: standby mode uses the same sram function as suspend to
> > memory mode
> >   pm: at91: rename file name: pm_slowclock.S -->pm_suspend.S
> >   pm: at91: rename function name:
> > at91_slow_clock()-->at91_pm_suspend_sram_fn
> >   pm: at91: remove unused void (*at91_pm_standby)(void)
> 
> Whole series:
> Acked-by: Nicolas Ferre 
> 
> And stacked on top of at91-4.1-cleanup
> 
> Thanks.
> 
> BTW, I had to rework the commit subject as all AT91 patches must begin
> with: "ARM: at91". So I reworked them as "ARM: at91/pm:"
Thank you so much, lesson learned.

> 
> Bye,
> 
> >  arch/arm/mach-at91/Makefile   |2 +-
> >  arch/arm/mach-at91/pm.c   |  121 +++--
> >  arch/arm/mach-at91/pm.h   |   10 ++
> >  arch/arm/mach-at91/pm_slowclock.S |  296 ---
> >  arch/arm/mach-at91/pm_suspend.S   |  349
> +
> >  5 files changed, 420 insertions(+), 358 deletions(-)  delete mode
> > 100644 arch/arm/mach-at91/pm_slowclock.S  create mode 100644
> > arch/arm/mach-at91/pm_suspend.S
> >
> 
> 
> --
> Nicolas Ferre


Best Regards,
Wenyou Yang

RE: [PATCH] ARM: at91: pm: fix SRAM allocation

[Yang, Wenyou]

Hi Alexandre,

> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: 2015年3月2日 18:58
> To: Jean-Christophe PLAGNIOL-VILLARD
> Cc: Ferre, Nicolas; Yang, Wenyou; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH] ARM: at91: pm: fix SRAM allocation
> 
> On 02/03/2015 at 18:50:27 +0800, Jean-Christophe PLAGNIOL-VILLARD wrote :
> >
> > > On Mar 2, 2015, at 6:42 PM, Alexandre Belloni  electrons.com> wrote:
> > >
> > > On some platforms, there are multiple SRAM nodes defined in the
> > > device tree but some of them are disabled, leading to allocation
> > > failure. Try to find the first enabled SRAM node and allocate from it.
> > >
> > > Signed-off-by: Alexandre Belloni
> > > 
> > > ---
> > > arch/arm/mach-at91/pm.c | 20 +---
> > > 1 file changed, 9 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c index
> > > 5e34fb143309..97cc529b6fa0 100644
> > > --- a/arch/arm/mach-at91/pm.c
> > > +++ b/arch/arm/mach-at91/pm.c
> > > @@ -272,35 +272,33 @@ static void __init at91_pm_sram_init(void)
> > >   struct device_node *node;
> > >   struct platform_device *pdev;
> >
> > pdev not initialised at NULL
> 
> Indeed, I'll fix that. It doesn't really matter for now as all the
> at91 DT have at least one sram node.
> 
> Wenyou, can you test it? If it works, I'll send v2.
It works. Thanks.

Tested it on the AT91SAM9G20EK, AT91SAM9G35EK and SAMA5D36EK board.

Tested-by: Wenyou Yang 

> 
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering http://free-electrons.com


Best Regards,
Wenyou Yang

RE: [PATCH] ARM: dts: at919260/at91sam9g20: fix SRAM device tree node

[Yang, Wenyou]

Hi Alexandre,

> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: 2015年3月2日 17:54
> To: Yang, Wenyou
> Cc: Ferre, Nicolas; mark.rutl...@arm.com; devicet...@vger.kernel.org;
> li...@arm.linux.org.uk; pawel.m...@arm.com; ijc+devicet...@hellion.org.uk; 
> linux-
> ker...@vger.kernel.org; robh...@kernel.org; ga...@codeaurora.org;
> li...@maxim.org.za; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH] ARM: dts: at919260/at91sam9g20: fix SRAM device tree
> node
> 
> Hi Wenyou,
> 
> I'd prefer fixing the sram lookup in pm.c. I'll propose something however, I 
> can't
> test on my side.
I can help test it if you give me your patches to me.

> 
> On 02/03/2015 at 14:03:29 +0800, Wenyou Yang wrote :
> > Fix PM does not work on the at91sam9g20ek board
> > --->8---
> > at91_pm_sram_init: failed to find sram device!
> > ---<8---
> >
> > Signed-off-by: Wenyou Yang 
> > ---
> >  arch/arm/boot/dts/at91sam9260.dtsi |9 +++--
> >  arch/arm/boot/dts/at91sam9g20.dtsi |9 +
> >  2 files changed, 12 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/at91sam9260.dtsi
> > b/arch/arm/boot/dts/at91sam9260.dtsi
> > index fff0ee6..d1eb27c 100644
> > --- a/arch/arm/boot/dts/at91sam9260.dtsi
> > +++ b/arch/arm/boot/dts/at91sam9260.dtsi
> > @@ -69,9 +69,14 @@
> > };
> > };
> >
> > -   sram0: sram@002ff000 {
> > +   sram0: sram@0020 {
> > compatible = "mmio-sram";
> > -   reg = <0x002ff000 0x2000>;
> > +   reg = <0x0020 0x1000>;
> > +   };
> > +
> > +   sram1: sram@0030 {
> > +   compatible = "mmio-sram";
> > +   reg = <0x0030 0x1000>;
> > };
> >
> > ahb {
> > diff --git a/arch/arm/boot/dts/at91sam9g20.dtsi
> > b/arch/arm/boot/dts/at91sam9g20.dtsi
> > index f593016..eb9a62d 100644
> > --- a/arch/arm/boot/dts/at91sam9g20.dtsi
> > +++ b/arch/arm/boot/dts/at91sam9g20.dtsi
> > @@ -16,13 +16,14 @@
> > reg = <0x2000 0x0800>;
> > };
> >
> > -   sram0: sram@002ff000 {
> > -   status = "disabled";
> > +   sram0: sram@0020 {
> > +   compatible = "mmio-sram";
> > +   reg = <0x0020 0x4000>;
> > };
> >
> > -   sram1: sram@002fc000 {
> > +   sram1: sram@0030 {
> > compatible = "mmio-sram";
> > -   reg = <0x002fc000 0x8000>;
> > +   reg = <0x0030 0x4000>;
> > };
> >
> > ahb {
> > --
> > 1.7.9.5
> >
> >
> > ___
> > linux-arm-kernel mailing list
> > linux-arm-ker...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering http://free-electrons.com

Best Regards,
Wenyou Yang

RE: [PATCH v5 00/13] AT91 pm cleanup for 3.20

[Yang, Wenyou]

Hi Nicolas,

> -Original Message-
> From: Ferre, Nicolas
> Sent: Thursday, January 29, 2015 9:09 PM
> To: Yang, Wenyou; li...@arm.linux.org.uk
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> alexandre.bell...@free-electrons.com; sylvain.roc...@finsecur.com;
> p...@axentia.se; sergei.shtyl...@cogentembedded.com; li...@maxim.org.za
> Subject: Re: [PATCH v5 00/13] AT91 pm cleanup for 3.20
> 
> Le 29/01/2015 07:35, Wenyou Yang a écrit :
> > Hi Nicolas,
> >
> > This version is rebased on the branch: at91-3.20-cleanup of the repository
> > git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git
> >
> > It is purpose to clean up the PM code, includes the patches from Peter Rosin
> and Sylvain Rochet.
> >
> > Since verifying the USB clock and USB PLL disabling before suspending
> > to memory, it aslo depends on the following patch serials from Sylvain:
> > [PATCHv6 0/5] USB: gadget: atmel_usba_udc: Driver improvements
> > [PATCHv7 0/6] USB: host: Atmel OHCI and EHCI drivers improvements
> >
> > Removes CONFIG_AT91_SLOW_CLOCK config item to simply the PM config,
> > The suspend to standby mode uses the same sram function as the suspend to
> memory mode.
> > Remove some unused code.
> >
> > Alexandr & Sylvain, Thank you very much for so many feedbacks.
> 
> Wenyou,
> 
> I'm sorry but the PM "cleanup" and "improvement" series won't be merged for 
> 3.20
> (so you can remove this from the series subject). The series are pretty big,
> address a sensitive aspect of the chips and are not completely ready. So I
> propose to slow down the pace of versions and focus on these two objectives:
> 
> 1/ try to extract a handful of patches that could be sent as "fixes" for
> 3.20 (no more than 5-6 patches). If they are enough urgent, I can try to add 
> them to
> an early "fixes" branch during the 3.20 stabilization process.
OK, I will send some stable patches.

> 
> 2/ try to figure out if from this big amount of assembly code can't be 
> extracted
> some parts that can be converted to C or parts that can use ARM common code
> (for cache management for instance).
Yes, I need dig deeply the cache code.

> 
> During 3.21 development phase, we will come back to the "cleanup" series and
> prepare something that can host the sama5 PM support. Finally we will add
> sama5d3/sama5d4 PM enhancements.
> 
> 
> > Changes in v5:
> >  - Rebase the branch: at91-3.20-cleanup HEAD:fa9df37
> >
> > Changes in v4:
> >  - Clear unused state argument in at91_pm_verify_clocks()
> >  - Remove pr_info("AT91:... slow_clock ? ..") in patch 07/13.
> >
> > Changes in v3
> >  - Sylvain splits the patch in two
> >  - Add handling if no sram allocated for PM
> >  - Retain the STANDBY and SUSPEND_MEM select in at91_pm_enter.
> >
> > Changes in v2:
> >  - Rebase on the at91-3.20-cleanup branch
> >  - Recover the verify clock condition, only for suspend to memory.
> >  - Collect ACK from Alexandre
> >  - Add the macro for PM mode
> >
> > Peter Rosin (1):
> >   pm: at91: Workaround DDRSDRC self-refresh bug with LPDDR1 memories.
> >
> > Sylvain Rochet (2):
> >   pm: at91: pm_slowclock: fix suspend/resume hang up in timeouts
> >   pm: at91: pm_slowclock: remove clocks which are already stopped when
> > entering slow clock mode
> >
> > Wenyou Yang (10):
> >   pm: at91: pm_slowclock: remove the unused code related with
> > SLOWDOWN_MASTER_CLOCK
> >   pm: at91: move the copying the sram function to the sram
> > initializationi phase
> >   ARM: at91: move select SRAM to ARCH_AT91
> >   pm: at91: remove the config item CONFIG_AT91_SLOW_CLOCK
> >   pm: at91: the standby mode uses the same sram function as the suspend
> > to memory mode
> >   pm: at91: rename file name: pm_slowclock.S -->pm_suspend.S
> >   pm: at91: rename function name:
> > at91_slow_clock()-->at91_pm_suspend_sram_fn
> >   pm: at91: remove the at91_xxx_standby() function definitions in the
> > pm.h
> >   pm: at91: remove the data member at91_xxx_standby() of struct
> > ramc_ids
> >   pm: at91: amend the pm_suspend entry for at91_cpuidle_device
> >
> >  arch/arm/mach-at91/Kconfig |   17 +-
> >  arch/arm/mach-at91/Makefile|2 +-
> >  arch/arm/mach-at91/pm.c|  166 +-
> >  arch/arm/mach-at91/pm.h|  100 +--
> >  arch/arm/mach-at91/pm_slowclock.S  |  323 
> > --

RE: [PATCH v2 3/3] pm: at91: add disable/enable the L1/L2 cache while suspend/resume

[Yang, Wenyou]

Hi Russell,

Thank you very much for your suggestion.

I will redo this patch to use the cache helper functions ASAP.

> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Thursday, January 29, 2015 7:35 PM
> To: Yang, Wenyou
> Cc: Ferre, Nicolas; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; alexandre.bell...@free-electrons.com;
> sylvain.roc...@finsecur.com; p...@axentia.se;
> sergei.shtyl...@cogentembedded.com; li...@maxim.org.za
> Subject: Re: [PATCH v2 3/3] pm: at91: add disable/enable the L1/L2 cache while
> suspend/resume
> 
> On Wed, Jan 28, 2015 at 10:24:04AM +0800, Wenyou Yang wrote:
> > +   /*
> > +* Clean and invalidate the L2 cache.
> > +* Common cache-l2x0.c functions can't be used here since it
> > +* uses spinlocks. We are out of coherency here with data cache
> > +* disabled. The spinlock implementation uses exclusive load/store
> > +* instruction which can fail without data cache being enabled.
> > +* Because of this, CPU can lead to deadlock.
> 
> We really need to stop needing platforms to create their own L2 handling code.
> Please move this to a helper function in arch/arm/mm/l2c-l...-clean.S, 
> replacing ...
> with the appropriate part for the code fragment.
> 
> > +*/
> > +   ldr r1, at91_l2cc_base_addr
> > +   ldr r2, [r1]
> > +   cmp r2, #0
> > +   beq skip_l2disable
> > +   mov r0, #0xff
> > +   str r0, [r2, #L2X0_CLEAN_INV_WAY]
> > +wait:
> > +   ldr r0, [r2, #L2X0_CLEAN_INV_WAY]
> > +   mov r1, #0xff
> > +   andsr0, r0, r1
> > +   bne wait
> > +
> > +   mov r0, #0
> > +   str r0, [r2, #L2X0_CTRL]
> > +
> > +l2x_sync:
> > +   ldr r0, [r2, #L2X0_CACHE_SYNC]
> > +   bic r0, r0, #0x1
> > +   str r0, [r2, #L2X0_CACHE_SYNC]
> 
> I wonder whether you've actually read the documentation for this.  You don't 
> need
> to read-modify-write this register.  The C code doesn't even do this.  A 
> write to this
> register is sufficient - a write issues the sync, a read returns the 
> completion status.
> 
> > +sync:
> > +   ldr r0, [r2, #L2X0_CACHE_SYNC]
> > +   andsr0, r0, #0x1
> > +   bne sync
> 
> Moreover, do you actually need this - it depends on the L2C model.  Only
> L2C220 needs to spin waiting for the sync operation to complete.
> 
> Also, are you sure the "clean+invalidate, disable, sync" sequence is correct?
> Should it not be "clean+invalidate, sync, disable" ?
> 
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.

Best Regards,
Wenyou Yang
--
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: [PATCH 2/7] pm: at91: pm_suspend: add the WFI support for ARMv7

[Yang, Wenyou]

Hi Lorenzo,

Thanks a lot.

> -Original Message-
> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> Sent: Thursday, January 29, 2015 8:22 PM
> To: Yang, Wenyou
> Cc: Ferre, Nicolas; li...@arm.linux.org.uk; 
> linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; alexandre.bell...@free-electrons.com;
> sylvain.roc...@finsecur.com; p...@axentia.se; Vilchez, Patrice
> Subject: Re: [PATCH 2/7] pm: at91: pm_suspend: add the WFI support for ARMv7
> 
> On Thu, Jan 29, 2015 at 02:36:01AM +, Yang, Wenyou wrote:
> > Hi Lorenzo,
> >
> > Thank you for your review.
> >
> > > -Original Message-
> > > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> > > Sent: Wednesday, January 28, 2015 7:26 PM
> > > To: Yang, Wenyou
> > > Cc: Ferre, Nicolas; li...@arm.linux.org.uk;
> > > linux-arm-ker...@lists.infradead.org;
> > > linux-kernel@vger.kernel.org; alexandre.bell...@free-electrons.com;
> > > sylvain.roc...@finsecur.com; p...@axentia.se; Vilchez, Patrice
> > > Subject: Re: [PATCH 2/7] pm: at91: pm_suspend: add the WFI support
> > > for ARMv7
> > >
> > > On Mon, Jan 26, 2015 at 10:06:01AM +, Wenyou Yang wrote:
> > >
> > > Commit log please.
> > Added in the v2.0
> >
> > >
> > > > Signed-off-by: Wenyou Yang 
> > > > ---
> > > >  arch/arm/mach-at91/pm_suspend.S |   54
> > > ++-
> > > >  1 file changed, 53 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/mach-at91/pm_suspend.S
> > > > b/arch/arm/mach-at91/pm_suspend.S index 122a3f1..e796722 100644
> > > > --- a/arch/arm/mach-at91/pm_suspend.S
> > > > +++ b/arch/arm/mach-at91/pm_suspend.S
> > > > @@ -53,6 +53,58 @@ mode .reqr6
> > > > beq 1b
> > > > .endm
> > > >
> > > > +/*
> > > > + * Put the processor to enter the WFI state  */
> > > > +   .macro _do_wfi
> > >
> > > You will have to explain why you need this, really.
> > I don't understand your meaning.
> 
> I want to understand why this assembly snippet (that can be rewritten in C 
> BTW):
> 
> /* Disable the processor's clock */
> mov   tmp1, #AT91_PMC_PCK
> str   tmp1, [pmc, #AT91_PMC_SCDR]
> 
> +
> 
> cpu_do_idle()
> 
> is not sufficient for you, or put it differently, why do you need this macro.
This assembly snippet will be copied and run in the SRAM, in the period the DDR 
is in the self-refresh state.
So, it can't invoke other functions generally. 

> 
> >
> > >
> > > > +
> > > > +#if defined(CONFIG_CPU_V7)
> > > > +   /*
> > > > +* Execute an ISB instruction to flush the pipeline to ensure
> > > > +* that all of operations have beem completed.
> > >
> > > s/beem/been
> > Thanks.
> >
> > >
> > > > +*/
> > > > +   isb
> 
> This isb should not be there, unless you know a reason why it should and you
> explain it to me.
I encountered system lock during verifying the pm function. 
Anyway, I will tested again whether it works after removing it. 

> 
> > > > +
> > > > +   /*
> > > > +* Execute an ISB instruction to ensure that all of the
> > > > +* CP15 register changes have been committed.
> > > > +*/
> > > > +   dsb
> > >
> > > This is a dsb not an isb.
> > Changed in the v2.0
> 
> Yes, but I still do not understand why you want to execute it before 
> disabling the
> clocks (I really hope that by "disabling the clocks" you mean "set the power
> controller to a state when, on wfi execution, the clocks are gated").
Are you meaning to execute dsb and wfi after disabling the clocks?

> 
> >
> > >
> > > > +   dmb
> > >
> > > You have to explain why you need every single one of these barriers,
> > > otherwise I am NAKing this patch.
> > No need this one?
> 
> No, remove it.
OK, thanks

> 
> >
> > >
> > > > +
> > > > +   /* Disable the processor's clock */
> > > > +   mov tmp1, #AT91_PMC_PCK
> > > > +   str tmp1, [pmc, #AT91_PMC_SCDR]
> > > > +
> > > > +   /* Execute a WFI instruction */
> > > > +   wfi @ Wait For Interrupt
> > >
> > &

RE: [PATCH v4 05/13] pm: at91: move the copying the sram function to the sram initializationi phase

[Yang, Wenyou]

Hi  Alexandre,

> -Original Message-
> From: Alexandre Belloni [mailto:alexandre.bell...@free-electrons.com]
> Sent: Thursday, January 29, 2015 11:09 PM
> To: Russell King - ARM Linux
> Cc: Yang, Wenyou; Ferre, Nicolas; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; sylvain.roc...@finsecur.com; p...@axentia.se;
> sergei.shtyl...@cogentembedded.com; li...@maxim.org.za
> Subject: Re: [PATCH v4 05/13] pm: at91: move the copying the sram function to
> the sram initializationi phase
> 
> Hi,
> 
> On 29/01/2015 at 11:28:00 +, Russell King - ARM Linux wrote :
> > On Wed, Jan 28, 2015 at 09:43:16AM +0800, Wenyou Yang wrote:
> > > -#ifdef CONFIG_AT91_SLOW_CLOCK
> > > - /* copy slow_clock handler to SRAM, and call it 
> > > */
> > > - memcpy(slow_clock, at91_slow_clock,
> at91_slow_clock_sz);
> > > -#endif
> > >   slow_clock(at91_pmc_base, at91_ramc_base[0],
> > >  at91_ramc_base[1],
> > >  at91_pm_data.memctrl);
> > > @@ -272,6 +268,9 @@ static void __init at91_pm_sram_init(void)
> > >   sram_pbase = gen_pool_virt_to_phys(sram_pool, sram_base);
> > >   slow_clock = __arm_ioremap_exec(sram_pbase, at91_slow_clock_sz,
> > > false);
> > >
> > > + /* Copy the slow_clock handler to SRAM */
> > > + memcpy(slow_clock, at91_slow_clock, at91_slow_clock_sz);
> > > +
> >
> > Why is this code not using the fncpy() support for copying functions.
> 
> Indeed, this was done in the original version of the patch that I acked.
Yes, in the original version used the fncpy(), but it works not well for some 
SoCs.
Sorry for that, I forget to record it on the change log.

> 
> > Why is it not checking the return code from __arm_ioremap_exec() or
> > gen_pool_virt_to_phys() for failure?
> 
> gen_pool_virt_to_phys() will not fail as the chunk is allocated just before 
> so it will
> necessarily be found in the list.
> 
> We need to reintroduce a check for slow_clock != NULL before fncpy() since it 
> is
> moved out of its original if block.
> 
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering http://free-electrons.com

Best Regards,
Wenyou yang
--
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: [PATCH v4 05/13] pm: at91: move the copying the sram function to the sram initializationi phase

[Yang, Wenyou]

Hi Russell,

Thank you for your review.

> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Thursday, January 29, 2015 7:28 PM
> To: Yang, Wenyou
> Cc: Ferre, Nicolas; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; alexandre.bell...@free-electrons.com;
> sylvain.roc...@finsecur.com; p...@axentia.se;
> sergei.shtyl...@cogentembedded.com; li...@maxim.org.za
> Subject: Re: [PATCH v4 05/13] pm: at91: move the copying the sram function to
> the sram initializationi phase
> 
> On Wed, Jan 28, 2015 at 09:43:16AM +0800, Wenyou Yang wrote:
> > -#ifdef CONFIG_AT91_SLOW_CLOCK
> > -   /* copy slow_clock handler to SRAM, and call it 
> > */
> > -   memcpy(slow_clock, at91_slow_clock,
> at91_slow_clock_sz);
> > -#endif
> > slow_clock(at91_pmc_base, at91_ramc_base[0],
> >at91_ramc_base[1],
> >at91_pm_data.memctrl);
> > @@ -272,6 +268,9 @@ static void __init at91_pm_sram_init(void)
> > sram_pbase = gen_pool_virt_to_phys(sram_pool, sram_base);
> > slow_clock = __arm_ioremap_exec(sram_pbase, at91_slow_clock_sz,
> > false);
> >
> > +   /* Copy the slow_clock handler to SRAM */
> > +   memcpy(slow_clock, at91_slow_clock, at91_slow_clock_sz);
> > +
> 
> Why is this code not using the fncpy() support for copying functions.
At first, used the fncpy(), but it work not well on the some chip. I will check 
it again.

> Why is it not checking the return code from __arm_ioremap_exec() or
> gen_pool_virt_to_phys() for failure?
> 
> This looks like quite a massive review failure when this code was originally 
> merged.
> It needs fixing.
I will fix it.

> 
> --
> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
> according to speedtest.net.

Best Regards,
Wenyou Yang
--
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: [PATCH v5 05/13] pm: at91: move the copying the sram function to the sram initializationi phase

[Yang, Wenyou]

Hi Sergei,

Thank you for your review and suggestion.

> -Original Message-
> From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com]
> Sent: Thursday, January 29, 2015 6:11 PM
> To: Yang, Wenyou; Ferre, Nicolas; li...@arm.linux.org.uk
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> alexandre.bell...@free-electrons.com; sylvain.roc...@finsecur.com;
> p...@axentia.se; li...@maxim.org.za
> Subject: Re: [PATCH v5 05/13] pm: at91: move the copying the sram function to
> the sram initializationi phase
> 
> Hello.
> 
> On 1/29/2015 9:38 AM, Wenyou Yang wrote:
> 
> > To decrease the suspend time, move the copying the sram function to
> > the sram initialization phase, instead of every time go to suspend.
> 
> > In the meanwhile, if there is no sram allocated for PM, the PM is not 
> > supported.
> 
> > Signed-off-by: Wenyou Yang 
> > Acked-by: Alexandre Belloni 
> > ---
> >   arch/arm/mach-at91/pm.c |   12 +++-
> >   1 file changed, 7 insertions(+), 5 deletions(-)
> 
> > diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c index
> > daa998d..6df0152 100644
> > --- a/arch/arm/mach-at91/pm.c
> > +++ b/arch/arm/mach-at91/pm.c
> > @@ -163,10 +163,6 @@ static int at91_pm_enter(suspend_state_t state)
> >  * turning off the main oscillator; reverse on wakeup.
> >  */
> > if (slow_clock) {
> > -#ifdef CONFIG_AT91_SLOW_CLOCK
> > -   /* copy slow_clock handler to SRAM, and call it 
> > */
> > -   memcpy(slow_clock, at91_slow_clock,
> at91_slow_clock_sz);
> > -#endif
> > slow_clock(at91_pmc_base, at91_ramc_base[0],
> >at91_ramc_base[1],
> >at91_pm_data.memctrl);
> > @@ -311,6 +307,9 @@ static void __init at91_pm_sram_init(void)
> > sram_pbase = gen_pool_virt_to_phys(sram_pool, sram_base);
> > slow_clock = __arm_ioremap_exec(sram_pbase, at91_slow_clock_sz,
> > false);
> >
> > +   /* Copy the slow_clock handler to SRAM */
> > +   memcpy(slow_clock, at91_slow_clock, at91_slow_clock_sz);
> 
> AFAIU (looking at the code above and below), __arm_ioremap_exec() can 
> return
> NULL and in this case memcpy() will cause kernel oops.
Will add a condition before copying 
if (sram_pbase)

> 
> > @@ -328,7 +327,10 @@ static void __init at91_pm_init(void)
> > if (at91_cpuidle_device.dev.platform_data)
> > platform_device_register(&at91_cpuidle_device);
> >
> > -   suspend_set_ops(&at91_pm_ops);
> > +   if (slow_clock)
> > +   suspend_set_ops(&at91_pm_ops);
> > +   else
> > +   pr_info("AT91: PM : Not supported, due to no sram allocated\n");
> 
> I'd suggest upper-casing "sram". And removing of colon after "PM".
Will change.

> 
> [...]
> 
> WBR, Sergei

Best Regards,
Wenyou Yang
--
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/