Re: [PATCH v3] Add tw5864 driver

[Hans Verkuil]

Hi Andrey,

Thanks for this driver. Some review comments below:

On 07/09/2016 09:46 PM, Andrey Utkin wrote:
> From: Andrey Utkin 
> 
> 
> Changes in v3 since v2:
>  - Kconfig: select VIDEOBUF2_DMA_CONTIG, not SG
>  - drop i2c code as unused
>  - Dropped num_buffers check in queue_setup as suggested by Hans
>  - Drop std autodetect on streaming start as suggested by Hans
>  - Cleanup buf queue on enable_input() failure
>  - Change container_of() to list_entry() where applicable
>  - Changed V4L2_FIELD_NONE to V4L2_FIELD_INTERLACED as suggested
>  - frameinterval rework suggested by Hans
>  - Add enum_framesizes
>  - Report framesize based on std, not input w/h
>  - Add printed warning about known video quality issues
>  - MAINTAINERS: fix path
>  - request_mem_region() -> pci_request_regions()
>  - Rebase onto Hans' "for-v4.8i" branch
>  - Follow changes from patchset "vb2: replace allocation context by device 
> pointer"
> 
> Below log is produced by today's v4l2-compliance from v4l-utils git, and this
> patch based on branch "for-v4.8i" of 
> git://linuxtv.org/hverkuil/media_tree.git .
> Compliance test runs fine.
> 
> checkpatch.pl is happy with this patch except for artifacts_warning which
> produces a bunch of such warnings:
> 
> WARNING: quoted string split across lines
> #155: FILE: drivers/media/pci/tw5864/tw5864-core.c:44:
> +"This driver was developed by Bluecherry LLC by deducing behaviour of 
> original"
> +" manufacturer's driver, from both source code and execution traces.\n"
> 
> I believe I'd better not join all the lines to avoid them looking like
> 
> "Paragraph one.\Paragraph two.\Paragraph three.\n"
> 
>  # v4l2-compliance -d 6 -s
> v4l2-compliance SHA   : 5e74f6a15aa14c01d8319e086d98f33d96a6a04d
> 
> Driver Info:
> Driver name   : tw5864
> Card type : TW5864 Encoder 2
> Bus info  : PCI::06:05.0
> Driver version: 4.7.0
> Capabilities  : 0x8521
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps   : 0x0521
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
> 
> Compliance test for device /dev/video6 (not using libv4l2):
> 
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
> 
> Allow for multiple opens:
> test second video open: OK
> test VIDIOC_QUERYCAP: OK
> test VIDIOC_G/S_PRIORITY: OK
> 
> Debug ioctls:
> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> test VIDIOC_LOG_STATUS: OK
> 
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 1 Audio Inputs: 0 Tuners: 0
> 
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
> 
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> test VIDIOC_G/S_EDID: OK (Not Supported)
> 
> Test input 0:
> 
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
> test VIDIOC_QUERYCTRL: OK
> test VIDIOC_G/S_CTRL: OK
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 11 Private Controls: 0
> 
> Format ioctls:
> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> test VIDIOC_G/S_PARM: OK
> test VIDIOC_G_FBUF: OK (Not Supported)
> test VIDIOC_G_FMT: OK
> test VIDIOC_TRY_FMT: OK
> test VIDIOC_S_FMT: OK
> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> test Cropping: OK (Not Supported)
> test Composing: OK (Not Supported)
> test Scaling: OK (Not Supported)
> 
> Codec ioctls:
> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> 
> Buffer ioctls:
> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> 

Re: [PATCH v3] Add tw5864 driver

[Hans Verkuil]

Hi Andrey,

Thanks for this driver. Some review comments below:

On 07/09/2016 09:46 PM, Andrey Utkin wrote:
> From: Andrey Utkin 
> 
> 
> Changes in v3 since v2:
>  - Kconfig: select VIDEOBUF2_DMA_CONTIG, not SG
>  - drop i2c code as unused
>  - Dropped num_buffers check in queue_setup as suggested by Hans
>  - Drop std autodetect on streaming start as suggested by Hans
>  - Cleanup buf queue on enable_input() failure
>  - Change container_of() to list_entry() where applicable
>  - Changed V4L2_FIELD_NONE to V4L2_FIELD_INTERLACED as suggested
>  - frameinterval rework suggested by Hans
>  - Add enum_framesizes
>  - Report framesize based on std, not input w/h
>  - Add printed warning about known video quality issues
>  - MAINTAINERS: fix path
>  - request_mem_region() -> pci_request_regions()
>  - Rebase onto Hans' "for-v4.8i" branch
>  - Follow changes from patchset "vb2: replace allocation context by device 
> pointer"
> 
> Below log is produced by today's v4l2-compliance from v4l-utils git, and this
> patch based on branch "for-v4.8i" of 
> git://linuxtv.org/hverkuil/media_tree.git .
> Compliance test runs fine.
> 
> checkpatch.pl is happy with this patch except for artifacts_warning which
> produces a bunch of such warnings:
> 
> WARNING: quoted string split across lines
> #155: FILE: drivers/media/pci/tw5864/tw5864-core.c:44:
> +"This driver was developed by Bluecherry LLC by deducing behaviour of 
> original"
> +" manufacturer's driver, from both source code and execution traces.\n"
> 
> I believe I'd better not join all the lines to avoid them looking like
> 
> "Paragraph one.\Paragraph two.\Paragraph three.\n"
> 
>  # v4l2-compliance -d 6 -s
> v4l2-compliance SHA   : 5e74f6a15aa14c01d8319e086d98f33d96a6a04d
> 
> Driver Info:
> Driver name   : tw5864
> Card type : TW5864 Encoder 2
> Bus info  : PCI::06:05.0
> Driver version: 4.7.0
> Capabilities  : 0x8521
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps   : 0x0521
> Video Capture
> Read/Write
> Streaming
> Extended Pix Format
> 
> Compliance test for device /dev/video6 (not using libv4l2):
> 
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
> 
> Allow for multiple opens:
> test second video open: OK
> test VIDIOC_QUERYCAP: OK
> test VIDIOC_G/S_PRIORITY: OK
> 
> Debug ioctls:
> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> test VIDIOC_LOG_STATUS: OK
> 
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 1 Audio Inputs: 0 Tuners: 0
> 
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
> 
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> test VIDIOC_G/S_EDID: OK (Not Supported)
> 
> Test input 0:
> 
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
> test VIDIOC_QUERYCTRL: OK
> test VIDIOC_G/S_CTRL: OK
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 11 Private Controls: 0
> 
> Format ioctls:
> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> test VIDIOC_G/S_PARM: OK
> test VIDIOC_G_FBUF: OK (Not Supported)
> test VIDIOC_G_FMT: OK
> test VIDIOC_TRY_FMT: OK
> test VIDIOC_S_FMT: OK
> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> test Cropping: OK (Not Supported)
> test Composing: OK (Not Supported)
> test Scaling: OK (Not Supported)
> 
> Codec ioctls:
> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> 
> Buffer ioctls:
> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> test VIDIOC_EXPBUF: OK
> 
> Test 

Re: [PATCH 3/3] ARM: dts: exynos: correct the rtc compatible value for exynos5

[Krzysztof Kozlowski]

On 07/09/2016 11:23 AM, Randy Li wrote:
> Those platforms are reported to use the same rtc IP core
> as exynos3250's.

Insufficient. Exynos4 also has to be updated. Actually all SoC from SoC
family requires rtc src clock. I think S3C6410 also requires it but I
don't have all the data necessary to confirm this.

Best regards,
Krzysztof

> 
> Signed-off-by: Randy Li 
> ---
>  arch/arm/boot/dts/exynos3250.dtsi | 2 +-
>  arch/arm/boot/dts/exynos5.dtsi| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 62f3dcd..cdd69a0 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -208,7 +208,7 @@
>   };
>  
>   rtc: rtc@1007 {
> - compatible = "samsung,s3c6410-rtc";
> + compatible = "samsung,exynos3250-rtc";
>   reg = <0x1007 0x100>;
>   interrupts = <0 73 0>, <0 74 0>;
>   interrupt-parent = <_system_controller>;
> diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
> index d5c0f18..71a1ad2 100644
> --- a/arch/arm/boot/dts/exynos5.dtsi
> +++ b/arch/arm/boot/dts/exynos5.dtsi
> @@ -88,7 +88,7 @@
>   };
>  
>   rtc: rtc@101E {
> - compatible = "samsung,s3c6410-rtc";
> + compatible = "samsung,exynos3250-rtc";
>   reg = <0x101E 0x100>;
>   interrupts = <0 43 0>, <0 44 0>;
>   status = "disabled";
> 

Re: [PATCH 3/3] ARM: dts: exynos: correct the rtc compatible value for exynos5

[Krzysztof Kozlowski]

On 07/09/2016 11:23 AM, Randy Li wrote:
> Those platforms are reported to use the same rtc IP core
> as exynos3250's.

Insufficient. Exynos4 also has to be updated. Actually all SoC from SoC
family requires rtc src clock. I think S3C6410 also requires it but I
don't have all the data necessary to confirm this.

Best regards,
Krzysztof

> 
> Signed-off-by: Randy Li 
> ---
>  arch/arm/boot/dts/exynos3250.dtsi | 2 +-
>  arch/arm/boot/dts/exynos5.dtsi| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi 
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 62f3dcd..cdd69a0 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -208,7 +208,7 @@
>   };
>  
>   rtc: rtc@1007 {
> - compatible = "samsung,s3c6410-rtc";
> + compatible = "samsung,exynos3250-rtc";
>   reg = <0x1007 0x100>;
>   interrupts = <0 73 0>, <0 74 0>;
>   interrupt-parent = <_system_controller>;
> diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
> index d5c0f18..71a1ad2 100644
> --- a/arch/arm/boot/dts/exynos5.dtsi
> +++ b/arch/arm/boot/dts/exynos5.dtsi
> @@ -88,7 +88,7 @@
>   };
>  
>   rtc: rtc@101E {
> - compatible = "samsung,s3c6410-rtc";
> + compatible = "samsung,exynos3250-rtc";
>   reg = <0x101E 0x100>;
>   interrupts = <0 43 0>, <0 44 0>;
>   status = "disabled";
> 

Re: [PATCH 2/3] rtc: s3c: add device data for samsung,exynos3250-rtc

[Krzysztof Kozlowski]

On 07/09/2016 11:23 AM, Randy Li wrote:
> The device data for samsung,exynos3250-rtc and samsung,s3c6410-rtc
> are just have a difference, but keeping using the same device data
> would cause the platform using the other IP core not work.

I cannot understand what you wanted to say here. Please rephrase it.

Why not just reverting a42e6eae457837d6a5925f4926f5ba05ccf44f89?

Best regards,
Krzysztof

> 
> Signed-off-by: Randy Li 
> ---
>  drivers/rtc/rtc-s3c.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
> index 5dc18ca..e9f6151 100644
> --- a/drivers/rtc/rtc-s3c.c
> +++ b/drivers/rtc/rtc-s3c.c
> @@ -810,6 +810,18 @@ static struct s3c_rtc_data const s3c6410_rtc_data = {
>   .disable= s3c6410_rtc_disable,
>  };
>  
> +static struct s3c_rtc_data const exynos3250_rtc_data = {
> + .max_user_freq  = 32768,
> + .needs_src_clk  = true,
> + .irq_handler= s3c6410_rtc_irq,
> + .set_freq   = s3c6410_rtc_setfreq,
> + .enable_tick= s3c6410_rtc_enable_tick,
> + .save_tick_cnt  = s3c6410_rtc_save_tick_cnt,
> + .restore_tick_cnt   = s3c6410_rtc_restore_tick_cnt,
> + .enable = s3c24xx_rtc_enable,
> + .disable= s3c6410_rtc_disable,
> +};
> +
>  static const struct of_device_id s3c_rtc_dt_match[] = {
>   {
>   .compatible = "samsung,s3c2410-rtc",
> @@ -825,7 +837,7 @@ static const struct of_device_id s3c_rtc_dt_match[] = {
>   .data = (void *)_rtc_data,
>   }, {
>   .compatible = "samsung,exynos3250-rtc",
> - .data = (void *)_rtc_data,
> + .data = (void *)_rtc_data,
>   },
>   { /* sentinel */ },
>  };
> 

Re: [PATCH 2/3] rtc: s3c: add device data for samsung,exynos3250-rtc

[Krzysztof Kozlowski]

On 07/09/2016 11:23 AM, Randy Li wrote:
> The device data for samsung,exynos3250-rtc and samsung,s3c6410-rtc
> are just have a difference, but keeping using the same device data
> would cause the platform using the other IP core not work.

I cannot understand what you wanted to say here. Please rephrase it.

Why not just reverting a42e6eae457837d6a5925f4926f5ba05ccf44f89?

Best regards,
Krzysztof

> 
> Signed-off-by: Randy Li 
> ---
>  drivers/rtc/rtc-s3c.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
> index 5dc18ca..e9f6151 100644
> --- a/drivers/rtc/rtc-s3c.c
> +++ b/drivers/rtc/rtc-s3c.c
> @@ -810,6 +810,18 @@ static struct s3c_rtc_data const s3c6410_rtc_data = {
>   .disable= s3c6410_rtc_disable,
>  };
>  
> +static struct s3c_rtc_data const exynos3250_rtc_data = {
> + .max_user_freq  = 32768,
> + .needs_src_clk  = true,
> + .irq_handler= s3c6410_rtc_irq,
> + .set_freq   = s3c6410_rtc_setfreq,
> + .enable_tick= s3c6410_rtc_enable_tick,
> + .save_tick_cnt  = s3c6410_rtc_save_tick_cnt,
> + .restore_tick_cnt   = s3c6410_rtc_restore_tick_cnt,
> + .enable = s3c24xx_rtc_enable,
> + .disable= s3c6410_rtc_disable,
> +};
> +
>  static const struct of_device_id s3c_rtc_dt_match[] = {
>   {
>   .compatible = "samsung,s3c2410-rtc",
> @@ -825,7 +837,7 @@ static const struct of_device_id s3c_rtc_dt_match[] = {
>   .data = (void *)_rtc_data,
>   }, {
>   .compatible = "samsung,exynos3250-rtc",
> - .data = (void *)_rtc_data,
> + .data = (void *)_rtc_data,
>   },
>   { /* sentinel */ },
>  };
> 

Re: [PATCH 1/3] Revert "drivers/rtc/rtc-s3c.c: add .needs_src_clk to s3c6410 RTC data"

[Krzysztof Kozlowski]

On 07/09/2016 11:23 AM, Randy Li wrote:
> This reverts commit 8792f7772f4f40ffc68bad5f28311205584b734d.
> The s3c6410 rtc don't use rtc_src property, that property is designed
> for Exynos5250 and Exynos5440. The problem reported in the commit
> I mentioned should be fixed in the other way.

... so you break in this commit all the newer platforms because the
rtc_src clock won't be enabled.

Does not look right.

Best regards,
Krzysztof

> 
> Signed-off-by: Randy Li 
> ---
>  drivers/rtc/rtc-s3c.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
> index d01ad7e..5dc18ca 100644
> --- a/drivers/rtc/rtc-s3c.c
> +++ b/drivers/rtc/rtc-s3c.c
> @@ -801,7 +801,6 @@ static struct s3c_rtc_data const s3c2443_rtc_data = {
>  
>  static struct s3c_rtc_data const s3c6410_rtc_data = {
>   .max_user_freq  = 32768,
> - .needs_src_clk  = true,
>   .irq_handler= s3c6410_rtc_irq,
>   .set_freq   = s3c6410_rtc_setfreq,
>   .enable_tick= s3c6410_rtc_enable_tick,
> 

Re: [PATCH 1/3] Revert "drivers/rtc/rtc-s3c.c: add .needs_src_clk to s3c6410 RTC data"

[Krzysztof Kozlowski]

On 07/09/2016 11:23 AM, Randy Li wrote:
> This reverts commit 8792f7772f4f40ffc68bad5f28311205584b734d.
> The s3c6410 rtc don't use rtc_src property, that property is designed
> for Exynos5250 and Exynos5440. The problem reported in the commit
> I mentioned should be fixed in the other way.

... so you break in this commit all the newer platforms because the
rtc_src clock won't be enabled.

Does not look right.

Best regards,
Krzysztof

> 
> Signed-off-by: Randy Li 
> ---
>  drivers/rtc/rtc-s3c.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
> index d01ad7e..5dc18ca 100644
> --- a/drivers/rtc/rtc-s3c.c
> +++ b/drivers/rtc/rtc-s3c.c
> @@ -801,7 +801,6 @@ static struct s3c_rtc_data const s3c2443_rtc_data = {
>  
>  static struct s3c_rtc_data const s3c6410_rtc_data = {
>   .max_user_freq  = 32768,
> - .needs_src_clk  = true,
>   .irq_handler= s3c6410_rtc_irq,
>   .set_freq   = s3c6410_rtc_setfreq,
>   .enable_tick= s3c6410_rtc_enable_tick,
> 

Re: [PATCH v2 19/22] usb: chipidea: msm: Handle phy power states

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:10PM -0700, Stephen Boyd wrote:
> The ULPI phy on qcom platforms needs to be initialized and
> powered on after a USB reset and before we toggle the run/stop
> bit. Otherwise, the phy locks up and doesn't work properly. Hook
> the phy initialization into the RESET event and the phy power off
> into the STOPPED event.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 40 
> +++---
>  drivers/usb/chipidea/core.c|  8 ++--
>  drivers/usb/chipidea/host.c|  8 ++--
>  include/linux/usb/chipidea.h   |  2 +-
>  4 files changed, 33 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index ab6a7713ee5c..5c486c15e043 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -75,20 +75,33 @@ static const struct reset_control_ops 
> ci_hdrc_msm_reset_ops = {
>   .reset = ci_hdrc_msm_por_reset,
>  };
>  
> -static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
> +static int ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
>  {
>   struct device *dev = ci->dev->parent;
>   struct ci_hdrc_msm *msm_ci = dev_get_drvdata(dev);
> + int ret;
>  
>   switch (event) {
>   case CI_HDRC_CONTROLLER_RESET_EVENT:
>   dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
> +
> + hw_phymode_configure(ci);
>   if (msm_ci->secondary_phy) {
>   u32 val = readl_relaxed(msm_ci->base + HS_PHY_SEC_CTRL);
>   val |= HS_PHY_DIG_CLAMP_N;
>   writel_relaxed(val, msm_ci->base + HS_PHY_SEC_CTRL);
>   }
>  
> + ret = phy_init(ci->phy);
> + if (ret)
> + return ret;
> +
> + ret = phy_power_on(ci->phy);
> + if (ret) {
> + phy_exit(ci->phy);
> + return ret;
> + }
> +
>   /* use AHB transactor, allow posted data writes */
>   hw_write_id_reg(ci, HS_PHY_AHB_MODE, 0x, 0x8);
>  
> @@ -108,21 +121,18 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc 
> *ci, unsigned event)
>HSPHY_SESS_VLD_CTRL);
>  
>   }
> -
> - usb_phy_init(ci->usb_phy);
>   break;
>   case CI_HDRC_CONTROLLER_STOPPED_EVENT:
>   dev_dbg(dev, "CI_HDRC_CONTROLLER_STOPPED_EVENT received\n");
> - /*
> -  * Put the phy in non-driving mode. Otherwise host
> -  * may not detect soft-disconnection.
> -  */
> - usb_phy_notify_disconnect(ci->usb_phy, USB_SPEED_UNKNOWN);
> + phy_power_off(ci->phy);
> + phy_exit(ci->phy);
>   break;
>   default:
>   dev_dbg(dev, "unknown ci_hdrc event\n");
>   break;
>   }
> +
> + return 0;
>  }
>  
>  static int ci_hdrc_msm_mux_phy(struct ci_hdrc_msm *ci,
> @@ -162,7 +172,6 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  {
>   struct ci_hdrc_msm *ci;
>   struct platform_device *plat_ci;
> - struct usb_phy *phy;
>   struct clk *clk;
>   struct reset_control *reset;
>   struct resource *res;
> @@ -176,21 +185,12 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>   platform_set_drvdata(pdev, ci);
>  
> - /*
> -  * OTG(PHY) driver takes care of PHY initialization, clock management,
> -  * powering up VBUS, mapping of registers address space and power
> -  * management.
> -  */
> - phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
> - if (IS_ERR(phy))
> - return PTR_ERR(phy);
> -
>   ci->pdata.name = "ci_hdrc_msm";
>   ci->pdata.capoffset = DEF_CAPOFFSET;
>   ci->pdata.flags = CI_HDRC_REGS_SHARED | CI_HDRC_DISABLE_STREAMING |
> -   CI_HDRC_OVERRIDE_AHB_BURST;
> +   CI_HDRC_OVERRIDE_AHB_BURST |
> +   CI_HDRC_OVERRIDE_PHY_CONTROL;
>   ci->pdata.notify_event = ci_hdrc_msm_notify_event;
> - ci->pdata.usb_phy = phy;
>  
>   reset = devm_reset_control_get(>dev, "core");
>   if (IS_ERR(reset))
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index f144e1bbcc82..0866c03d66df 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -327,6 +327,7 @@ void hw_phymode_configure(struct ci_hdrc *ci)
>   hw_write(ci, OP_PORTSC, PORTSC_STS, PORTSC_STS);
>   }
>  }
> +EXPORT_SYMBOL_GPL(hw_phymode_configure);
>  
>  /**
>   * _ci_usb_phy_init: initialize phy taking in account both phy and usb_phy
> @@ -503,9 +504,12 @@ int hw_device_reset(struct ci_hdrc *ci)
>   

Re: [PATCH v2 20/22] usb: chipidea: msm: Be silent on probe defer errors

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:11PM -0700, Stephen Boyd wrote:
> If something fails in ci_hdrc_add_device() due to probe defer, we
> shouldn't print an error message. Be silent in this case as we'll
> try probe again later.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 5c486c15e043..d4cc45f8e65e 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -257,8 +257,9 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>   plat_ci = ci_hdrc_add_device(>dev, pdev->resource,
>pdev->num_resources, >pdata);
>   if (IS_ERR(plat_ci)) {
> - dev_err(>dev, "ci_hdrc_add_device failed!\n");
>   ret = PTR_ERR(plat_ci);
> + if (ret != -EPROBE_DEFER)
> + dev_err(>dev, "ci_hdrc_add_device failed!\n");
>   goto err_mux;
>   }
>  

Acked-by: Peter Chen 

-- 

Best Regards,
Peter Chen

Re: [PATCH 0/3] making rtc cores from s3c6410 and exynos3250 both work

[Krzysztof Kozlowski]

On 07/09/2016 11:23 AM, Randy Li wrote:
> The 8792f7772f4f40ffc68bad5f28311205584b734d would just make those
> platform using rtc core from exynos3250 work but have a huge 
> effect on those platforms using the rtc core from s3c6410.
> These patches would fix this problem.
> 

Which problem? What huge effect? On which platforms? You didn't describe
it...

Your change breaks the ABI and is not compatible with current bindings
documentation.

Best regards,
Krzysztof

> Randy Li (3):
>   Revert "drivers/rtc/rtc-s3c.c: add .needs_src_clk to s3c6410 RTC data"
>   rtc: s3c: add device data for samsung,exynos3250-rtc
>   ARM: dts: exynos: correct the rtc compatible value for exynos5
> 
>  arch/arm/boot/dts/exynos3250.dtsi |  2 +-
>  arch/arm/boot/dts/exynos5.dtsi|  2 +-
>  drivers/rtc/rtc-s3c.c | 15 +--
>  3 files changed, 15 insertions(+), 4 deletions(-)
> 

Re: [PATCH v2 19/22] usb: chipidea: msm: Handle phy power states

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:10PM -0700, Stephen Boyd wrote:
> The ULPI phy on qcom platforms needs to be initialized and
> powered on after a USB reset and before we toggle the run/stop
> bit. Otherwise, the phy locks up and doesn't work properly. Hook
> the phy initialization into the RESET event and the phy power off
> into the STOPPED event.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 40 
> +++---
>  drivers/usb/chipidea/core.c|  8 ++--
>  drivers/usb/chipidea/host.c|  8 ++--
>  include/linux/usb/chipidea.h   |  2 +-
>  4 files changed, 33 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index ab6a7713ee5c..5c486c15e043 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -75,20 +75,33 @@ static const struct reset_control_ops 
> ci_hdrc_msm_reset_ops = {
>   .reset = ci_hdrc_msm_por_reset,
>  };
>  
> -static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
> +static int ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
>  {
>   struct device *dev = ci->dev->parent;
>   struct ci_hdrc_msm *msm_ci = dev_get_drvdata(dev);
> + int ret;
>  
>   switch (event) {
>   case CI_HDRC_CONTROLLER_RESET_EVENT:
>   dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
> +
> + hw_phymode_configure(ci);
>   if (msm_ci->secondary_phy) {
>   u32 val = readl_relaxed(msm_ci->base + HS_PHY_SEC_CTRL);
>   val |= HS_PHY_DIG_CLAMP_N;
>   writel_relaxed(val, msm_ci->base + HS_PHY_SEC_CTRL);
>   }
>  
> + ret = phy_init(ci->phy);
> + if (ret)
> + return ret;
> +
> + ret = phy_power_on(ci->phy);
> + if (ret) {
> + phy_exit(ci->phy);
> + return ret;
> + }
> +
>   /* use AHB transactor, allow posted data writes */
>   hw_write_id_reg(ci, HS_PHY_AHB_MODE, 0x, 0x8);
>  
> @@ -108,21 +121,18 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc 
> *ci, unsigned event)
>HSPHY_SESS_VLD_CTRL);
>  
>   }
> -
> - usb_phy_init(ci->usb_phy);
>   break;
>   case CI_HDRC_CONTROLLER_STOPPED_EVENT:
>   dev_dbg(dev, "CI_HDRC_CONTROLLER_STOPPED_EVENT received\n");
> - /*
> -  * Put the phy in non-driving mode. Otherwise host
> -  * may not detect soft-disconnection.
> -  */
> - usb_phy_notify_disconnect(ci->usb_phy, USB_SPEED_UNKNOWN);
> + phy_power_off(ci->phy);
> + phy_exit(ci->phy);
>   break;
>   default:
>   dev_dbg(dev, "unknown ci_hdrc event\n");
>   break;
>   }
> +
> + return 0;
>  }
>  
>  static int ci_hdrc_msm_mux_phy(struct ci_hdrc_msm *ci,
> @@ -162,7 +172,6 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  {
>   struct ci_hdrc_msm *ci;
>   struct platform_device *plat_ci;
> - struct usb_phy *phy;
>   struct clk *clk;
>   struct reset_control *reset;
>   struct resource *res;
> @@ -176,21 +185,12 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>   platform_set_drvdata(pdev, ci);
>  
> - /*
> -  * OTG(PHY) driver takes care of PHY initialization, clock management,
> -  * powering up VBUS, mapping of registers address space and power
> -  * management.
> -  */
> - phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
> - if (IS_ERR(phy))
> - return PTR_ERR(phy);
> -
>   ci->pdata.name = "ci_hdrc_msm";
>   ci->pdata.capoffset = DEF_CAPOFFSET;
>   ci->pdata.flags = CI_HDRC_REGS_SHARED | CI_HDRC_DISABLE_STREAMING |
> -   CI_HDRC_OVERRIDE_AHB_BURST;
> +   CI_HDRC_OVERRIDE_AHB_BURST |
> +   CI_HDRC_OVERRIDE_PHY_CONTROL;
>   ci->pdata.notify_event = ci_hdrc_msm_notify_event;
> - ci->pdata.usb_phy = phy;
>  
>   reset = devm_reset_control_get(>dev, "core");
>   if (IS_ERR(reset))
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index f144e1bbcc82..0866c03d66df 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -327,6 +327,7 @@ void hw_phymode_configure(struct ci_hdrc *ci)
>   hw_write(ci, OP_PORTSC, PORTSC_STS, PORTSC_STS);
>   }
>  }
> +EXPORT_SYMBOL_GPL(hw_phymode_configure);
>  
>  /**
>   * _ci_usb_phy_init: initialize phy taking in account both phy and usb_phy
> @@ -503,9 +504,12 @@ int hw_device_reset(struct ci_hdrc *ci)
>   return ret;
>   }
>  
> - if 

Re: [PATCH v2 20/22] usb: chipidea: msm: Be silent on probe defer errors

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:11PM -0700, Stephen Boyd wrote:
> If something fails in ci_hdrc_add_device() due to probe defer, we
> shouldn't print an error message. Be silent in this case as we'll
> try probe again later.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 5c486c15e043..d4cc45f8e65e 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -257,8 +257,9 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>   plat_ci = ci_hdrc_add_device(>dev, pdev->resource,
>pdev->num_resources, >pdata);
>   if (IS_ERR(plat_ci)) {
> - dev_err(>dev, "ci_hdrc_add_device failed!\n");
>   ret = PTR_ERR(plat_ci);
> + if (ret != -EPROBE_DEFER)
> + dev_err(>dev, "ci_hdrc_add_device failed!\n");
>   goto err_mux;
>   }
>  

Acked-by: Peter Chen 

-- 

Best Regards,
Peter Chen

Re: [PATCH 0/3] making rtc cores from s3c6410 and exynos3250 both work

[Krzysztof Kozlowski]

On 07/09/2016 11:23 AM, Randy Li wrote:
> The 8792f7772f4f40ffc68bad5f28311205584b734d would just make those
> platform using rtc core from exynos3250 work but have a huge 
> effect on those platforms using the rtc core from s3c6410.
> These patches would fix this problem.
> 

Which problem? What huge effect? On which platforms? You didn't describe
it...

Your change breaks the ABI and is not compatible with current bindings
documentation.

Best regards,
Krzysztof

> Randy Li (3):
>   Revert "drivers/rtc/rtc-s3c.c: add .needs_src_clk to s3c6410 RTC data"
>   rtc: s3c: add device data for samsung,exynos3250-rtc
>   ARM: dts: exynos: correct the rtc compatible value for exynos5
> 
>  arch/arm/boot/dts/exynos3250.dtsi |  2 +-
>  arch/arm/boot/dts/exynos5.dtsi|  2 +-
>  drivers/rtc/rtc-s3c.c | 15 +--
>  3 files changed, 15 insertions(+), 4 deletions(-)
> 

Re: [PATCH v2 18/22] usb: chipidea: msm: Add reset controller for PHY POR bit

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:09PM -0700, Stephen Boyd wrote:
> The MSM chipidea wrapper has two bits that are used to reset the
> first or second phy. Add support for these bits via the reset
> controller framework, so that phy drivers can reset their
> hardware at the right time during initialization.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/Kconfig   |  1 +
>  drivers/usb/chipidea/ci_hdrc_msm.c | 45 
> --
>  2 files changed, 44 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
> index 4f8c342a8865..488ecdf56bdd 100644
> --- a/drivers/usb/chipidea/Kconfig
> +++ b/drivers/usb/chipidea/Kconfig
> @@ -2,6 +2,7 @@ config USB_CHIPIDEA
>   tristate "ChipIdea Highspeed Dual Role Controller"
>   depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD && 
> !USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA
>   select EXTCON
> + select RESET_CONTROLLER
>   help
> Say Y here if your system has a dual role high speed USB
> controller based on ChipIdea silicon IP. Currently, only the
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index da2d399acdd2..ab6a7713ee5c 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -31,8 +32,10 @@
>  #define HSPHY_SESS_VLD_CTRL  BIT(25)
>  
>  /* Vendor base starts at 0x200 beyond CI base */
> +#define HS_PHY_CTRL  0x0040
>  #define HS_PHY_SEC_CTRL  0x0078
>  #define HS_PHY_DIG_CLAMP_N   BIT(16)
> +#define HS_PHY_POR_ASSERTBIT(0)
>  
>  struct ci_hdrc_msm {
>   struct platform_device *ci;
> @@ -40,11 +43,38 @@ struct ci_hdrc_msm {
>   struct clk *iface_clk;
>   struct clk *fs_clk;
>   struct ci_hdrc_platform_data pdata;
> + struct reset_controller_dev rcdev;
>   bool secondary_phy;
>   bool hsic;
>   void __iomem *base;
>  };
>  
> +static int
> +ci_hdrc_msm_por_reset(struct reset_controller_dev *r, unsigned long id)
> +{
> + struct ci_hdrc_msm *ci_msm = container_of(r, struct ci_hdrc_msm, rcdev);
> + void __iomem *addr = ci_msm->base;
> + u32 val;
> +
> + if (id)
> + addr += HS_PHY_SEC_CTRL;
> + else
> + addr += HS_PHY_CTRL;
> +
> + val = readl_relaxed(addr);
> + val |= HS_PHY_POR_ASSERT;
> + writel(val, addr);
> + udelay(12);

Does this delay is reference manual defines or experienced value?
Do you need to comment it?

Peter
> + val &= ~HS_PHY_POR_ASSERT;
> + writel(val, addr);
> +
> + return 0;
> +}
> +
> +static const struct reset_control_ops ci_hdrc_msm_reset_ops = {
> + .reset = ci_hdrc_msm_por_reset,
> +};
> +
>  static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
>  {
>   struct device *dev = ci->dev->parent;
> @@ -186,10 +216,18 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   if (!ci->base)
>   return -ENOMEM;
>  
> - ret = clk_prepare_enable(ci->fs_clk);
> + ci->rcdev.owner = THIS_MODULE;
> + ci->rcdev.ops = _hdrc_msm_reset_ops;
> + ci->rcdev.of_node = pdev->dev.of_node;
> + ci->rcdev.nr_resets = 2;
> + ret = reset_controller_register(>rcdev);
>   if (ret)
>   return ret;
>  
> + ret = clk_prepare_enable(ci->fs_clk);
> + if (ret)
> + goto err_fs;
> +
>   reset_control_assert(reset);
>   usleep_range(1, 12000);
>   reset_control_deassert(reset);
> @@ -198,7 +236,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  
>   ret = clk_prepare_enable(ci->core_clk);
>   if (ret)
> - return ret;
> + goto err_fs;
>  
>   ret = clk_prepare_enable(ci->iface_clk);
>   if (ret)
> @@ -236,6 +274,8 @@ err_mux:
>   clk_disable_unprepare(ci->iface_clk);
>  err_iface:
>   clk_disable_unprepare(ci->core_clk);
> +err_fs:
> + reset_controller_unregister(>rcdev);
>   return ret;
>  }
>  
> @@ -247,6 +287,7 @@ static int ci_hdrc_msm_remove(struct platform_device 
> *pdev)
>   ci_hdrc_remove_device(ci->ci);
>   clk_disable_unprepare(ci->iface_clk);
>   clk_disable_unprepare(ci->core_clk);
> + reset_controller_unregister(>rcdev);
>  
>   return 0;
>  }
> -- 
> 2.9.0.rc2.8.ga28705d
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

Re: [PATCH v2 18/22] usb: chipidea: msm: Add reset controller for PHY POR bit

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:09PM -0700, Stephen Boyd wrote:
> The MSM chipidea wrapper has two bits that are used to reset the
> first or second phy. Add support for these bits via the reset
> controller framework, so that phy drivers can reset their
> hardware at the right time during initialization.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/Kconfig   |  1 +
>  drivers/usb/chipidea/ci_hdrc_msm.c | 45 
> --
>  2 files changed, 44 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
> index 4f8c342a8865..488ecdf56bdd 100644
> --- a/drivers/usb/chipidea/Kconfig
> +++ b/drivers/usb/chipidea/Kconfig
> @@ -2,6 +2,7 @@ config USB_CHIPIDEA
>   tristate "ChipIdea Highspeed Dual Role Controller"
>   depends on ((USB_EHCI_HCD && USB_GADGET) || (USB_EHCI_HCD && 
> !USB_GADGET) || (!USB_EHCI_HCD && USB_GADGET)) && HAS_DMA
>   select EXTCON
> + select RESET_CONTROLLER
>   help
> Say Y here if your system has a dual role high speed USB
> controller based on ChipIdea silicon IP. Currently, only the
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index da2d399acdd2..ab6a7713ee5c 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -31,8 +32,10 @@
>  #define HSPHY_SESS_VLD_CTRL  BIT(25)
>  
>  /* Vendor base starts at 0x200 beyond CI base */
> +#define HS_PHY_CTRL  0x0040
>  #define HS_PHY_SEC_CTRL  0x0078
>  #define HS_PHY_DIG_CLAMP_N   BIT(16)
> +#define HS_PHY_POR_ASSERTBIT(0)
>  
>  struct ci_hdrc_msm {
>   struct platform_device *ci;
> @@ -40,11 +43,38 @@ struct ci_hdrc_msm {
>   struct clk *iface_clk;
>   struct clk *fs_clk;
>   struct ci_hdrc_platform_data pdata;
> + struct reset_controller_dev rcdev;
>   bool secondary_phy;
>   bool hsic;
>   void __iomem *base;
>  };
>  
> +static int
> +ci_hdrc_msm_por_reset(struct reset_controller_dev *r, unsigned long id)
> +{
> + struct ci_hdrc_msm *ci_msm = container_of(r, struct ci_hdrc_msm, rcdev);
> + void __iomem *addr = ci_msm->base;
> + u32 val;
> +
> + if (id)
> + addr += HS_PHY_SEC_CTRL;
> + else
> + addr += HS_PHY_CTRL;
> +
> + val = readl_relaxed(addr);
> + val |= HS_PHY_POR_ASSERT;
> + writel(val, addr);
> + udelay(12);

Does this delay is reference manual defines or experienced value?
Do you need to comment it?

Peter
> + val &= ~HS_PHY_POR_ASSERT;
> + writel(val, addr);
> +
> + return 0;
> +}
> +
> +static const struct reset_control_ops ci_hdrc_msm_reset_ops = {
> + .reset = ci_hdrc_msm_por_reset,
> +};
> +
>  static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
>  {
>   struct device *dev = ci->dev->parent;
> @@ -186,10 +216,18 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   if (!ci->base)
>   return -ENOMEM;
>  
> - ret = clk_prepare_enable(ci->fs_clk);
> + ci->rcdev.owner = THIS_MODULE;
> + ci->rcdev.ops = _hdrc_msm_reset_ops;
> + ci->rcdev.of_node = pdev->dev.of_node;
> + ci->rcdev.nr_resets = 2;
> + ret = reset_controller_register(>rcdev);
>   if (ret)
>   return ret;
>  
> + ret = clk_prepare_enable(ci->fs_clk);
> + if (ret)
> + goto err_fs;
> +
>   reset_control_assert(reset);
>   usleep_range(1, 12000);
>   reset_control_deassert(reset);
> @@ -198,7 +236,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  
>   ret = clk_prepare_enable(ci->core_clk);
>   if (ret)
> - return ret;
> + goto err_fs;
>  
>   ret = clk_prepare_enable(ci->iface_clk);
>   if (ret)
> @@ -236,6 +274,8 @@ err_mux:
>   clk_disable_unprepare(ci->iface_clk);
>  err_iface:
>   clk_disable_unprepare(ci->core_clk);
> +err_fs:
> + reset_controller_unregister(>rcdev);
>   return ret;
>  }
>  
> @@ -247,6 +287,7 @@ static int ci_hdrc_msm_remove(struct platform_device 
> *pdev)
>   ci_hdrc_remove_device(ci->ci);
>   clk_disable_unprepare(ci->iface_clk);
>   clk_disable_unprepare(ci->core_clk);
> + reset_controller_unregister(>rcdev);
>  
>   return 0;
>  }
> -- 
> 2.9.0.rc2.8.ga28705d
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

Re: [PATCH v2 17/22] usb: chipidea: msm: Make platform data driver local instead of global

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:08PM -0700, Stephen Boyd wrote:
> If two devices are probed with this same driver, they'll share
> the same platform data structure, while the chipidea core layer
> writes and modifies it. This can lead to interesting results
> especially if one device is an OTG type chipidea controller and
> another is a host. Let's create a copy of this structure per each
> device instance so that odd things don't happen.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 20 
>  1 file changed, 8 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 81437c8cea82..da2d399acdd2 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -39,6 +39,7 @@ struct ci_hdrc_msm {
>   struct clk *core_clk;
>   struct clk *iface_clk;
>   struct clk *fs_clk;
> + struct ci_hdrc_platform_data pdata;
>   bool secondary_phy;
>   bool hsic;
>   void __iomem *base;
> @@ -94,16 +95,6 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
> unsigned event)
>   }
>  }
>  
> -static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
> - .name   = "ci_hdrc_msm",
> - .capoffset  = DEF_CAPOFFSET,
> - .flags  = CI_HDRC_REGS_SHARED |
> -   CI_HDRC_DISABLE_STREAMING |
> -   CI_HDRC_OVERRIDE_AHB_BURST,
> -
> - .notify_event   = ci_hdrc_msm_notify_event,
> -};
> -
>  static int ci_hdrc_msm_mux_phy(struct ci_hdrc_msm *ci,
>  struct platform_device *pdev)
>  {
> @@ -164,7 +155,12 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(phy))
>   return PTR_ERR(phy);
>  
> - ci_hdrc_msm_platdata.usb_phy = phy;
> + ci->pdata.name = "ci_hdrc_msm";
> + ci->pdata.capoffset = DEF_CAPOFFSET;
> + ci->pdata.flags = CI_HDRC_REGS_SHARED | CI_HDRC_DISABLE_STREAMING |
> +   CI_HDRC_OVERRIDE_AHB_BURST;
> + ci->pdata.notify_event = ci_hdrc_msm_notify_event;
> + ci->pdata.usb_phy = phy;
>  
>   reset = devm_reset_control_get(>dev, "core");
>   if (IS_ERR(reset))
> @@ -221,7 +217,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>   of_node_put(ulpi_node);
>  
>   plat_ci = ci_hdrc_add_device(>dev, pdev->resource,
> -  pdev->num_resources, 
> _hdrc_msm_platdata);
> +  pdev->num_resources, >pdata);

Acked-by: Peter Chen 

-- 

Best Regards,
Peter Chen

Re: [PATCH v2 17/22] usb: chipidea: msm: Make platform data driver local instead of global

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:08PM -0700, Stephen Boyd wrote:
> If two devices are probed with this same driver, they'll share
> the same platform data structure, while the chipidea core layer
> writes and modifies it. This can lead to interesting results
> especially if one device is an OTG type chipidea controller and
> another is a host. Let's create a copy of this structure per each
> device instance so that odd things don't happen.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 20 
>  1 file changed, 8 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 81437c8cea82..da2d399acdd2 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -39,6 +39,7 @@ struct ci_hdrc_msm {
>   struct clk *core_clk;
>   struct clk *iface_clk;
>   struct clk *fs_clk;
> + struct ci_hdrc_platform_data pdata;
>   bool secondary_phy;
>   bool hsic;
>   void __iomem *base;
> @@ -94,16 +95,6 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
> unsigned event)
>   }
>  }
>  
> -static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
> - .name   = "ci_hdrc_msm",
> - .capoffset  = DEF_CAPOFFSET,
> - .flags  = CI_HDRC_REGS_SHARED |
> -   CI_HDRC_DISABLE_STREAMING |
> -   CI_HDRC_OVERRIDE_AHB_BURST,
> -
> - .notify_event   = ci_hdrc_msm_notify_event,
> -};
> -
>  static int ci_hdrc_msm_mux_phy(struct ci_hdrc_msm *ci,
>  struct platform_device *pdev)
>  {
> @@ -164,7 +155,12 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(phy))
>   return PTR_ERR(phy);
>  
> - ci_hdrc_msm_platdata.usb_phy = phy;
> + ci->pdata.name = "ci_hdrc_msm";
> + ci->pdata.capoffset = DEF_CAPOFFSET;
> + ci->pdata.flags = CI_HDRC_REGS_SHARED | CI_HDRC_DISABLE_STREAMING |
> +   CI_HDRC_OVERRIDE_AHB_BURST;
> + ci->pdata.notify_event = ci_hdrc_msm_notify_event;
> + ci->pdata.usb_phy = phy;
>  
>   reset = devm_reset_control_get(>dev, "core");
>   if (IS_ERR(reset))
> @@ -221,7 +217,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>   of_node_put(ulpi_node);
>  
>   plat_ci = ci_hdrc_add_device(>dev, pdev->resource,
> -  pdev->num_resources, 
> _hdrc_msm_platdata);
> +  pdev->num_resources, >pdata);

Acked-by: Peter Chen 

-- 

Best Regards,
Peter Chen

[RFC PATCH v2] clk: move check of CLK_SET_RATE_GATE flag to clk_propagate_rate_change()

[jiada_wang]

From: Jiada Wang 

Previously CLK_SET_RATE_GATE flag is only checked in clk_set_rate()
which only ensures the clock being called by clk_set_rate() won't
change rate when it has been prepared if CLK_SET_RATE_GATE flag is set.
But a clk_set_rate() request may propagate rate change to these clocks
from the requested clock's topmost parent clock to all its offsprings,
when any one of these clocks has CLK_SET_RATE_GATE flag set
and it has been prepared, the clk_set_rate() request should fail.

This patch moves check of CLK_SET_RATE_GATE flag to
clk_propagate_rate_change() to ensure all affected clocks will
be checked if their rate will be changed after clk_set_rate().

Signed-off-by: Jiada Wang 
---
 drivers/clk/clk.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 820a939..2f930c8 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1437,6 +1437,9 @@ static struct clk_core *clk_propagate_rate_change(struct 
clk_core *core,
if (core->rate == core->new_rate)
return NULL;
 
+   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
+   return core;
+
if (core->notifier_count) {
ret = __clk_notify(core, event, core->rate, core->new_rate);
if (ret & NOTIFY_STOP_MASK)
@@ -1571,9 +1574,6 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
if (rate == clk_core_get_rate_nolock(core))
return 0;
 
-   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
-   return -EBUSY;
-
/* calculate new rates and get the topmost changed clock */
top = clk_calc_new_rates(core, rate);
if (!top)
-- 
1.7.9.5

[RFC PATCH v2] clk: move check of CLK_SET_RATE_GATE flag to clk_propagate_rate_change()

[jiada_wang]

From: Jiada Wang 

Previously CLK_SET_RATE_GATE flag is only checked in clk_set_rate()
which only ensures the clock being called by clk_set_rate() won't
change rate when it has been prepared if CLK_SET_RATE_GATE flag is set.
But a clk_set_rate() request may propagate rate change to these clocks
from the requested clock's topmost parent clock to all its offsprings,
when any one of these clocks has CLK_SET_RATE_GATE flag set
and it has been prepared, the clk_set_rate() request should fail.

This patch moves check of CLK_SET_RATE_GATE flag to
clk_propagate_rate_change() to ensure all affected clocks will
be checked if their rate will be changed after clk_set_rate().

Signed-off-by: Jiada Wang 
---
 drivers/clk/clk.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 820a939..2f930c8 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1437,6 +1437,9 @@ static struct clk_core *clk_propagate_rate_change(struct 
clk_core *core,
if (core->rate == core->new_rate)
return NULL;
 
+   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
+   return core;
+
if (core->notifier_count) {
ret = __clk_notify(core, event, core->rate, core->new_rate);
if (ret & NOTIFY_STOP_MASK)
@@ -1571,9 +1574,6 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
if (rate == clk_core_get_rate_nolock(core))
return 0;
 
-   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
-   return -EBUSY;
-
/* calculate new rates and get the topmost changed clock */
top = clk_calc_new_rates(core, rate);
if (!top)
-- 
1.7.9.5

Re: [PATCH v2 16/22] usb: chipidea: msm: Restore wrapper settings after reset

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:07PM -0700, Stephen Boyd wrote:
> When the RESET bit is set in the USBCMD register it resets quite
> a few of the wrapper's registers to their reset state. This
> includes the GENCONFIG and GENCONFIG2 registers. Currently this
> is done by the usb phy and ehci-msm drivers writing into the
> controller wrapper's MMIO address space. Let's consolidate the
> register writes into the wrapper driver instead so that we
> clearly split the wrapper from the phys.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 39 
> ++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 7708bee3ff3e..81437c8cea82 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -14,11 +14,22 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "ci.h"
>  
>  #define HS_PHY_AHB_MODE  0x0098
>  
> +#define HS_PHY_GENCONFIG 0x009c
> +#define HS_PHY_TXFIFO_IDLE_FORCE_DIS BIT(4)
> +
> +#define HS_PHY_GENCONFIG_2   0x00a0
> +#define HS_PHY_SESS_VLD_CTRL_EN  BIT(7)
> +#define HS_PHY_ULPI_TX_PKT_EN_CLR_FIXBIT(19)
> +
> +#define HSPHY_SESS_VLD_CTRL  BIT(25)
> +

Keep alignment please

Others are ok.

Acked-by: Peter Chen 

>  /* Vendor base starts at 0x200 beyond CI base */
>  #define HS_PHY_SEC_CTRL  0x0078
>  #define HS_PHY_DIG_CLAMP_N   BIT(16)
> @@ -29,6 +40,7 @@ struct ci_hdrc_msm {
>   struct clk *iface_clk;
>   struct clk *fs_clk;
>   bool secondary_phy;
> + bool hsic;
>   void __iomem *base;
>  };
>  
> @@ -48,6 +60,24 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
> unsigned event)
>  
>   /* use AHB transactor, allow posted data writes */
>   hw_write_id_reg(ci, HS_PHY_AHB_MODE, 0x, 0x8);
> +
> + /* workaround for rx buffer collision issue */
> + hw_write_id_reg(ci, HS_PHY_GENCONFIG,
> + HS_PHY_TXFIFO_IDLE_FORCE_DIS, 0);
> +
> + if (!msm_ci->hsic)
> + hw_write_id_reg(ci, HS_PHY_GENCONFIG_2,
> + HS_PHY_ULPI_TX_PKT_EN_CLR_FIX, 0);
> +
> + if (ci->platdata->vbus_extcon.edev) {
> + hw_write_id_reg(ci, HS_PHY_GENCONFIG_2,
> + HS_PHY_SESS_VLD_CTRL_EN,
> + HS_PHY_SESS_VLD_CTRL_EN);
> + hw_write(ci, OP_USBCMD, HSPHY_SESS_VLD_CTRL,
> +  HSPHY_SESS_VLD_CTRL);
> +
> + }
> +
>   usb_phy_init(ci->usb_phy);
>   break;
>   case CI_HDRC_CONTROLLER_STOPPED_EVENT:
> @@ -116,6 +146,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>   struct reset_control *reset;
>   struct resource *res;
>   int ret;
> + struct device_node *ulpi_node, *phy_node;
>  
>   dev_dbg(>dev, "ci_hdrc_msm_probe\n");
>  
> @@ -181,6 +212,14 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   if (ret)
>   goto err_mux;
>  
> + ulpi_node = of_find_node_by_name(pdev->dev.of_node, "ulpi");
> + if (ulpi_node) {
> + phy_node = of_get_next_available_child(ulpi_node, NULL);
> + ci->hsic = of_device_is_compatible(phy_node, 
> "qcom,usb-hsic-phy");
> + of_node_put(phy_node);
> + }
> + of_node_put(ulpi_node);
> +
>   plat_ci = ci_hdrc_add_device(>dev, pdev->resource,
>pdev->num_resources, 
> _hdrc_msm_platdata);
>   if (IS_ERR(plat_ci)) {
> -- 
> 2.9.0.rc2.8.ga28705d
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

Re: [PATCH v2 16/22] usb: chipidea: msm: Restore wrapper settings after reset

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:07PM -0700, Stephen Boyd wrote:
> When the RESET bit is set in the USBCMD register it resets quite
> a few of the wrapper's registers to their reset state. This
> includes the GENCONFIG and GENCONFIG2 registers. Currently this
> is done by the usb phy and ehci-msm drivers writing into the
> controller wrapper's MMIO address space. Let's consolidate the
> register writes into the wrapper driver instead so that we
> clearly split the wrapper from the phys.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 39 
> ++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 7708bee3ff3e..81437c8cea82 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -14,11 +14,22 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "ci.h"
>  
>  #define HS_PHY_AHB_MODE  0x0098
>  
> +#define HS_PHY_GENCONFIG 0x009c
> +#define HS_PHY_TXFIFO_IDLE_FORCE_DIS BIT(4)
> +
> +#define HS_PHY_GENCONFIG_2   0x00a0
> +#define HS_PHY_SESS_VLD_CTRL_EN  BIT(7)
> +#define HS_PHY_ULPI_TX_PKT_EN_CLR_FIXBIT(19)
> +
> +#define HSPHY_SESS_VLD_CTRL  BIT(25)
> +

Keep alignment please

Others are ok.

Acked-by: Peter Chen 

>  /* Vendor base starts at 0x200 beyond CI base */
>  #define HS_PHY_SEC_CTRL  0x0078
>  #define HS_PHY_DIG_CLAMP_N   BIT(16)
> @@ -29,6 +40,7 @@ struct ci_hdrc_msm {
>   struct clk *iface_clk;
>   struct clk *fs_clk;
>   bool secondary_phy;
> + bool hsic;
>   void __iomem *base;
>  };
>  
> @@ -48,6 +60,24 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
> unsigned event)
>  
>   /* use AHB transactor, allow posted data writes */
>   hw_write_id_reg(ci, HS_PHY_AHB_MODE, 0x, 0x8);
> +
> + /* workaround for rx buffer collision issue */
> + hw_write_id_reg(ci, HS_PHY_GENCONFIG,
> + HS_PHY_TXFIFO_IDLE_FORCE_DIS, 0);
> +
> + if (!msm_ci->hsic)
> + hw_write_id_reg(ci, HS_PHY_GENCONFIG_2,
> + HS_PHY_ULPI_TX_PKT_EN_CLR_FIX, 0);
> +
> + if (ci->platdata->vbus_extcon.edev) {
> + hw_write_id_reg(ci, HS_PHY_GENCONFIG_2,
> + HS_PHY_SESS_VLD_CTRL_EN,
> + HS_PHY_SESS_VLD_CTRL_EN);
> + hw_write(ci, OP_USBCMD, HSPHY_SESS_VLD_CTRL,
> +  HSPHY_SESS_VLD_CTRL);
> +
> + }
> +
>   usb_phy_init(ci->usb_phy);
>   break;
>   case CI_HDRC_CONTROLLER_STOPPED_EVENT:
> @@ -116,6 +146,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>   struct reset_control *reset;
>   struct resource *res;
>   int ret;
> + struct device_node *ulpi_node, *phy_node;
>  
>   dev_dbg(>dev, "ci_hdrc_msm_probe\n");
>  
> @@ -181,6 +212,14 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   if (ret)
>   goto err_mux;
>  
> + ulpi_node = of_find_node_by_name(pdev->dev.of_node, "ulpi");
> + if (ulpi_node) {
> + phy_node = of_get_next_available_child(ulpi_node, NULL);
> + ci->hsic = of_device_is_compatible(phy_node, 
> "qcom,usb-hsic-phy");
> + of_node_put(phy_node);
> + }
> + of_node_put(ulpi_node);
> +
>   plat_ci = ci_hdrc_add_device(>dev, pdev->resource,
>pdev->num_resources, 
> _hdrc_msm_platdata);
>   if (IS_ERR(plat_ci)) {
> -- 
> 2.9.0.rc2.8.ga28705d
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

Re: linux-next: build failure after merge of the pm tree

[Stephen Rothwell]

Hi Mika,

On Mon, 11 Jul 2016 07:48:17 +0300 Mika Westerberg 
 wrote:
>
> Looks like it is the module name (configfs.o) that confuses modpost or
> linker. The below patch fixes it for me.

That makes sense.  Thanks.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the pm tree

[Stephen Rothwell]

Hi Mika,

On Mon, 11 Jul 2016 07:48:17 +0300 Mika Westerberg 
 wrote:
>
> Looks like it is the module name (configfs.o) that confuses modpost or
> linker. The below patch fixes it for me.

That makes sense.  Thanks.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: manual merge of the clockevents tree with the arm-soc tree

[Stephen Rothwell]

Hi all,

On Thu, 7 Jul 2016 14:12:26 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the clockevents tree got a conflict in:
> 
>   arch/arm/Kconfig
> 
> between commit:
> 
>   c86f51737f8d ("ARM: clps711x: Switch to MULTIPLATFORM")
> 
> from the arm-soc tree and commit:
> 
>   250e46aa3bb3 ("clocksource/drivers/clps_711x: Add the COMPILE_TEST option")
> 
> from the clockevents tree.
> 
> I fixed it up (I used the arm-soc version of this file and then added
> the following merge fix patch) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> From: Stephen Rothwell 
> Date: Thu, 7 Jul 2016 13:59:06 +1000
> Subject: [PATCH] clocksource/drivers/clps_711x: fixup for "ARM: clps711x: 
> Switch to MULTIPLATFORM"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  arch/arm/mach-clps711x/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-clps711x/Kconfig b/arch/arm/mach-clps711x/Kconfig
> index 3b56197ccfd0..dc7c6edeab39 100644
> --- a/arch/arm/mach-clps711x/Kconfig
> +++ b/arch/arm/mach-clps711x/Kconfig
> @@ -3,8 +3,8 @@ menuconfig ARCH_CLPS711X
>   depends on ARCH_MULTI_V4T
>   select ARCH_REQUIRE_GPIOLIB
>   select AUTO_ZRELADDR
> - select CLKSRC_MMIO
>   select CLKSRC_OF
> + select CLPS711X_TIMER
>   select COMMON_CLK
>   select CPU_ARM720T
>   select GENERIC_CLOCKEVENTS
> -- 
> 2.8.1

This merge fix is now applicable to the merge between the arm-soc tree
and the tip tree.

Also, the clockevents tree needs to be cleaned up as all its commits
have been added to the tip tree as different commits (but the same
patches) :-(

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v15 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

Hi Felipe,

On 1 July 2016 at 14:05, Baolin Wang  wrote:
> Currently the Linux kernel does not provide any standard integration of this
> feature that integrates the USB subsystem with the system power regulation
> provided by PMICs meaning that either vendors must add this in their kernels
> or USB gadget devices based on Linux (such as mobile phones) may not behave
> as they should. Thus provide a standard framework for doing this in kernel.
>
> Now introduce one user with wm831x_power to support and test the usb charger,
> which is pending testing. Moreover there may be other potential users will use
> it in future.
>
> Changes since v14:
>  - Add kernel documentation for struct usb_cahrger.
>  - Remove some redundant WARN() functions.
>
> Changes since v13:
>  - Remove the charger checking in usb_gadget_vbus_draw() function.
>  - Rename some functions in charger.c file.
>  - Rebase on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/usb-for-v4.8
>
> Changes since v12:
>  - Remove the class and device things.
>  - Link usb charger to udc-core.ko.
>  - Create one "charger" subdirectory which holds all charger-related 
> attributes.
>
> Changes since v11:
>  - Reviewed and tested by Li Jun.
>
> Changes since v10:
>  - Introduce usb_charger_get_state() function to check charger state.
>  - Remove the mutex lock in usb_charger_set_cur_limit_by_type() function
>  in case will be issued in atomic context.
>
> Baolin Wang (4):
>   usb: gadget: Introduce the usb charger framework
>   usb: gadget: Support for the usb charger framework
>   usb: gadget: Integrate with the usb gadget supporting for usb charger
>   power: wm831x_power: Support USB charger current limit management
>
>  drivers/power/wm831x_power.c |   69 
>  drivers/usb/gadget/Kconfig   |8 +
>  drivers/usb/gadget/udc/Makefile  |1 +
>  drivers/usb/gadget/udc/charger.c |  738 
> ++
>  drivers/usb/gadget/udc/core.c|   17 +
>  include/linux/mfd/wm831x/pdata.h |3 +
>  include/linux/usb/charger.h  |  183 ++
>  include/linux/usb/gadget.h   |3 +
>  include/uapi/linux/usb/charger.h |   31 ++
>  9 files changed, 1053 insertions(+)
>  create mode 100644 drivers/usb/gadget/udc/charger.c
>  create mode 100644 include/linux/usb/charger.h
>  create mode 100644 include/uapi/linux/usb/charger.h
>
> --
> 1.7.9.5
>

Do you have any other comments about this v15 patchset? If not, could
you please add this version patchset into your 'next' branch? Thanks a
lot.

-- 
Baolin.wang
Best Regards

Re: linux-next: manual merge of the clockevents tree with the arm-soc tree

[Stephen Rothwell]

Hi all,

On Thu, 7 Jul 2016 14:12:26 +1000 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the clockevents tree got a conflict in:
> 
>   arch/arm/Kconfig
> 
> between commit:
> 
>   c86f51737f8d ("ARM: clps711x: Switch to MULTIPLATFORM")
> 
> from the arm-soc tree and commit:
> 
>   250e46aa3bb3 ("clocksource/drivers/clps_711x: Add the COMPILE_TEST option")
> 
> from the clockevents tree.
> 
> I fixed it up (I used the arm-soc version of this file and then added
> the following merge fix patch) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> From: Stephen Rothwell 
> Date: Thu, 7 Jul 2016 13:59:06 +1000
> Subject: [PATCH] clocksource/drivers/clps_711x: fixup for "ARM: clps711x: 
> Switch to MULTIPLATFORM"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  arch/arm/mach-clps711x/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-clps711x/Kconfig b/arch/arm/mach-clps711x/Kconfig
> index 3b56197ccfd0..dc7c6edeab39 100644
> --- a/arch/arm/mach-clps711x/Kconfig
> +++ b/arch/arm/mach-clps711x/Kconfig
> @@ -3,8 +3,8 @@ menuconfig ARCH_CLPS711X
>   depends on ARCH_MULTI_V4T
>   select ARCH_REQUIRE_GPIOLIB
>   select AUTO_ZRELADDR
> - select CLKSRC_MMIO
>   select CLKSRC_OF
> + select CLPS711X_TIMER
>   select COMMON_CLK
>   select CPU_ARM720T
>   select GENERIC_CLOCKEVENTS
> -- 
> 2.8.1

This merge fix is now applicable to the merge between the arm-soc tree
and the tip tree.

Also, the clockevents tree needs to be cleaned up as all its commits
have been added to the tip tree as different commits (but the same
patches) :-(

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v15 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

Hi Felipe,

On 1 July 2016 at 14:05, Baolin Wang  wrote:
> Currently the Linux kernel does not provide any standard integration of this
> feature that integrates the USB subsystem with the system power regulation
> provided by PMICs meaning that either vendors must add this in their kernels
> or USB gadget devices based on Linux (such as mobile phones) may not behave
> as they should. Thus provide a standard framework for doing this in kernel.
>
> Now introduce one user with wm831x_power to support and test the usb charger,
> which is pending testing. Moreover there may be other potential users will use
> it in future.
>
> Changes since v14:
>  - Add kernel documentation for struct usb_cahrger.
>  - Remove some redundant WARN() functions.
>
> Changes since v13:
>  - Remove the charger checking in usb_gadget_vbus_draw() function.
>  - Rename some functions in charger.c file.
>  - Rebase on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
> tags/usb-for-v4.8
>
> Changes since v12:
>  - Remove the class and device things.
>  - Link usb charger to udc-core.ko.
>  - Create one "charger" subdirectory which holds all charger-related 
> attributes.
>
> Changes since v11:
>  - Reviewed and tested by Li Jun.
>
> Changes since v10:
>  - Introduce usb_charger_get_state() function to check charger state.
>  - Remove the mutex lock in usb_charger_set_cur_limit_by_type() function
>  in case will be issued in atomic context.
>
> Baolin Wang (4):
>   usb: gadget: Introduce the usb charger framework
>   usb: gadget: Support for the usb charger framework
>   usb: gadget: Integrate with the usb gadget supporting for usb charger
>   power: wm831x_power: Support USB charger current limit management
>
>  drivers/power/wm831x_power.c |   69 
>  drivers/usb/gadget/Kconfig   |8 +
>  drivers/usb/gadget/udc/Makefile  |1 +
>  drivers/usb/gadget/udc/charger.c |  738 
> ++
>  drivers/usb/gadget/udc/core.c|   17 +
>  include/linux/mfd/wm831x/pdata.h |3 +
>  include/linux/usb/charger.h  |  183 ++
>  include/linux/usb/gadget.h   |3 +
>  include/uapi/linux/usb/charger.h |   31 ++
>  9 files changed, 1053 insertions(+)
>  create mode 100644 drivers/usb/gadget/udc/charger.c
>  create mode 100644 include/linux/usb/charger.h
>  create mode 100644 include/uapi/linux/usb/charger.h
>
> --
> 1.7.9.5
>

Do you have any other comments about this v15 patchset? If not, could
you please add this version patchset into your 'next' branch? Thanks a
lot.

-- 
Baolin.wang
Best Regards

linux-next: manual merge of the tip tree with the kspp tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/kernel/x86_init.c

between commit:

  255303026193 ("x86: apply more __ro_after_init and const")

from the kspp tree and commit:

  1bf8915ae515 ("x86/tsc: Enumerate SKL cpu_khz and tsc_khz via CPUID")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kernel/x86_init.c
index 111b838db7fe,58b459296e13..
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@@ -91,7 -91,8 +91,8 @@@ struct x86_cpuinit_ops x86_cpuinit = 
  static void default_nmi_init(void) { };
  static int default_i8042_detect(void) { return 1; };
  
 -struct x86_platform_ops x86_platform = {
 +struct x86_platform_ops x86_platform __ro_after_init = {
+   .calibrate_cpu  = native_calibrate_cpu,
.calibrate_tsc  = native_calibrate_tsc,
.get_wallclock  = mach_get_cmos_time,
.set_wallclock  = mach_set_rtc_mmss,

Re: [lkp] [ext4] 5405511e1a: ltp.acl_test01.fail]

[Ye Xiaolong]

Hi, Theodore

On Sun, Jul 10, 2016 at 11:15:53PM -0400, Theodore Ts'o wrote:
>On Mon, Jul 11, 2016 at 09:59:54AM +0800, kernel test robot wrote:
>> 
>> FYI, we noticed the following commit:
>> 
>> https://github.com/0day-ci/linux 
>> Vegard-Nossum/ext4-validate-number-of-clusters-in-group/20160708-041426
>> commit 5405511e1a984ab644fa9e29a0d3d958b835ab75 ("ext4: validate number of 
>> meta clusters in group")
>
>Hi, many thanks for the report.  One question -- is there some way the
>reporting could be speeded up?  Vegard's patch was sent late on the
>7th, and it looks like it hit the 0day-ci git repo a few hours later
>on the 8th, and was run early in the morning Chinese time.  Was the
>delay until the 11th due to the weekend and the desire to have a human
>sanity check the result?  Is that because there was a concern that
>there would be too many false positives?

Yes, you're right, although we have auto report feature (which has much
less delay) for high confidence errors/regressions detected, we still need
human sanity check for other cases to avoid too many false positives, it
will introduce some delays especially in weekend, sorry for that. We'll
improve our auto report part to cover more sensible cases.

>
>Also, if there was some way the 0day robot report could include a
>In-Reply-To: header to the patch being sent to the mailing list (in
>this case: <577eb740.10...@oracle.com>), it would make this even
>*more* useful.
>

Good point! We'll add this feature later.

Thanks,
Xiaolong

>
>Vegard, I'm guessing you didn't have a chance to test your patch
>before you sent it to the list?
>
>   bit_max = ext4_num_clusters_in_group(sb, i);
>   if ((bit_max >> 3) >= sb->s_blocksize) {
>   ext4_msg(sb, KERN_WARNING, "clusters in "
> "group %u exceeds block size", i);
>   goto failed_mount;
>   }
>
>
>This is the test which is failing, but it will fail by default on
>pretty much all ext4 file systems, since by default there will be
>32768 blocks (clusters) per group, with a 4k block size (and 32768 >>
>3 == 4096).  And in the test that failed, this was a 1k block size
>with 8192 blocks per blocks (and 8192 >> 3 == 1024).
>
>Anyway, as I mentioned before, I'd much rather do very specific sanity
>checking on superblock fields, instead of sanity checking calculated
>values such as ext4_num_clusters_in_group().
>
>Perhaps the easist thing to do is to run e2fsck -n on those file
>systems that are causing problems?
>
>Cheers,
>
>   - Ted

linux-next: manual merge of the tip tree with the kspp tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  arch/x86/kernel/x86_init.c

between commit:

  255303026193 ("x86: apply more __ro_after_init and const")

from the kspp tree and commit:

  1bf8915ae515 ("x86/tsc: Enumerate SKL cpu_khz and tsc_khz via CPUID")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/kernel/x86_init.c
index 111b838db7fe,58b459296e13..
--- a/arch/x86/kernel/x86_init.c
+++ b/arch/x86/kernel/x86_init.c
@@@ -91,7 -91,8 +91,8 @@@ struct x86_cpuinit_ops x86_cpuinit = 
  static void default_nmi_init(void) { };
  static int default_i8042_detect(void) { return 1; };
  
 -struct x86_platform_ops x86_platform = {
 +struct x86_platform_ops x86_platform __ro_after_init = {
+   .calibrate_cpu  = native_calibrate_cpu,
.calibrate_tsc  = native_calibrate_tsc,
.get_wallclock  = mach_get_cmos_time,
.set_wallclock  = mach_set_rtc_mmss,

Re: [lkp] [ext4] 5405511e1a: ltp.acl_test01.fail]

[Ye Xiaolong]

Hi, Theodore

On Sun, Jul 10, 2016 at 11:15:53PM -0400, Theodore Ts'o wrote:
>On Mon, Jul 11, 2016 at 09:59:54AM +0800, kernel test robot wrote:
>> 
>> FYI, we noticed the following commit:
>> 
>> https://github.com/0day-ci/linux 
>> Vegard-Nossum/ext4-validate-number-of-clusters-in-group/20160708-041426
>> commit 5405511e1a984ab644fa9e29a0d3d958b835ab75 ("ext4: validate number of 
>> meta clusters in group")
>
>Hi, many thanks for the report.  One question -- is there some way the
>reporting could be speeded up?  Vegard's patch was sent late on the
>7th, and it looks like it hit the 0day-ci git repo a few hours later
>on the 8th, and was run early in the morning Chinese time.  Was the
>delay until the 11th due to the weekend and the desire to have a human
>sanity check the result?  Is that because there was a concern that
>there would be too many false positives?

Yes, you're right, although we have auto report feature (which has much
less delay) for high confidence errors/regressions detected, we still need
human sanity check for other cases to avoid too many false positives, it
will introduce some delays especially in weekend, sorry for that. We'll
improve our auto report part to cover more sensible cases.

>
>Also, if there was some way the 0day robot report could include a
>In-Reply-To: header to the patch being sent to the mailing list (in
>this case: <577eb740.10...@oracle.com>), it would make this even
>*more* useful.
>

Good point! We'll add this feature later.

Thanks,
Xiaolong

>
>Vegard, I'm guessing you didn't have a chance to test your patch
>before you sent it to the list?
>
>   bit_max = ext4_num_clusters_in_group(sb, i);
>   if ((bit_max >> 3) >= sb->s_blocksize) {
>   ext4_msg(sb, KERN_WARNING, "clusters in "
> "group %u exceeds block size", i);
>   goto failed_mount;
>   }
>
>
>This is the test which is failing, but it will fail by default on
>pretty much all ext4 file systems, since by default there will be
>32768 blocks (clusters) per group, with a 4k block size (and 32768 >>
>3 == 4096).  And in the test that failed, this was a 1k block size
>with 8192 blocks per blocks (and 8192 >> 3 == 1024).
>
>Anyway, as I mentioned before, I'd much rather do very specific sanity
>checking on superblock fields, instead of sanity checking calculated
>values such as ext4_num_clusters_in_group().
>
>Perhaps the easist thing to do is to run e2fsck -n on those file
>systems that are causing problems?
>
>Cheers,
>
>   - Ted

Re: [PATCH v7 1/1] net: ethernet: Add TSE PCS support to dwmac-socfpga

[David Miller]

From: 
Date: Thu, 7 Jul 2016 20:23:30 -0700

> From: Tien Hock Loh 
> 
> This adds support for TSE PCS that uses SGMII adapter when the phy-mode of
> the dwmac is set to sgmii.
> 
> Signed-off-by: Tien Hock Loh 
> Acked-by: Rob Herring 

Applied to net-next, thanks.

Re: [PATCH v7 1/1] net: ethernet: Add TSE PCS support to dwmac-socfpga

[David Miller]

From: 
Date: Thu, 7 Jul 2016 20:23:30 -0700

> From: Tien Hock Loh 
> 
> This adds support for TSE PCS that uses SGMII adapter when the phy-mode of
> the dwmac is set to sgmii.
> 
> Signed-off-by: Tien Hock Loh 
> Acked-by: Rob Herring 

Applied to net-next, thanks.

Re: [PATCH] spi: spi-ti-qspi: clear wlen field while setting word length.

[Vignesh R]

Hi Prahlad,

On Sunday 10 July 2016 01:35 AM, Prahlad V wrote:
> When a word length of 1 byte is selected and writing data of length
> more than QSPI_WLEN_MAX_BYTES, first MAX_BYTES will be transfered
> and remaining will be transfered byte by byte. In that case wlen
> field should be cleared before setting.
> 
> Signed-off-by: Prahlad V 
> ---
>  drivers/spi/spi-ti-qspi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
> index 29ea8d2..6c61f54 100644
> --- a/drivers/spi/spi-ti-qspi.c
> +++ b/drivers/spi/spi-ti-qspi.c
> @@ -276,9 +276,9 @@ static int qspi_write_msg(struct ti_qspi *qspi, struct 
> spi_transfer *t,
>   cmd |= QSPI_WLEN(QSPI_WLEN_MAX_BITS);
>   } else {
>   writeb(*txbuf, qspi->base + QSPI_SPI_DATA_REG);
> - cmd = qspi->cmd | QSPI_WR_SNGL;

qspi->cmd always has WLEN field cleared and set to WLEN = 1 byte (see
ti_qspi_start_transfer_one()). And hence variable 'cmd' will also have
WLEN set to 1 byte.

>   xfer_len = wlen;
> - cmd |= QSPI_WLEN(wlen);
> + cmd = ((qspi->cmd & ~QSPI_WLEN_MASK) |
> +  QSPI_WLEN(wlen));

So, this won't be necessary.

-- 
Regards
Vignesh

Re: [PATCH] spi: spi-ti-qspi: clear wlen field while setting word length.

[Vignesh R]

Hi Prahlad,

On Sunday 10 July 2016 01:35 AM, Prahlad V wrote:
> When a word length of 1 byte is selected and writing data of length
> more than QSPI_WLEN_MAX_BYTES, first MAX_BYTES will be transfered
> and remaining will be transfered byte by byte. In that case wlen
> field should be cleared before setting.
> 
> Signed-off-by: Prahlad V 
> ---
>  drivers/spi/spi-ti-qspi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
> index 29ea8d2..6c61f54 100644
> --- a/drivers/spi/spi-ti-qspi.c
> +++ b/drivers/spi/spi-ti-qspi.c
> @@ -276,9 +276,9 @@ static int qspi_write_msg(struct ti_qspi *qspi, struct 
> spi_transfer *t,
>   cmd |= QSPI_WLEN(QSPI_WLEN_MAX_BITS);
>   } else {
>   writeb(*txbuf, qspi->base + QSPI_SPI_DATA_REG);
> - cmd = qspi->cmd | QSPI_WR_SNGL;

qspi->cmd always has WLEN field cleared and set to WLEN = 1 byte (see
ti_qspi_start_transfer_one()). And hence variable 'cmd' will also have
WLEN set to 1 byte.

>   xfer_len = wlen;
> - cmd |= QSPI_WLEN(wlen);
> + cmd = ((qspi->cmd & ~QSPI_WLEN_MASK) |
> +  QSPI_WLEN(wlen));

So, this won't be necessary.

-- 
Regards
Vignesh

Re: [PATCH v3] sched/deadline: remove useless param from setup_new_dl_entity

[Xunlei Pang]

On 2016/07/08 at 19:28, Juri Lelli wrote:
> setup_new_dl_entity() takes two parameters, but it only actually uses
> one of them, under a different name, to setup a new dl_entity, after:
>
>  2f9f3fdc928 "sched/deadline: Remove dl_new from struct sched_dl_entity"
>
> as we currently do
>
>  setup_new_dl_entity(>dl, >dl)
>
> However, before Luca's change we were doing
>
>  setup_new_dl_entity(dl_se, pi_se)
>
> in update_dl_entity() for a dl_se->new entity: we were using pi_se's
> parameters (the potential PI donor) for setting up a new entity.
>
> Restore this behaviour (as we want to correctly initialize parameters of
> a boosted task that enters DEADLINE) by removing the useless second
> parameter of setup_new_dl_entity() and retrieving the top waiter
> directly from inside that function.
>
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Steven Rostedt 
> Cc: Luca Abeni 
> Signed-off-by: Juri Lelli 
>
> ---
>  Changes from v2:
>- optimize by calling rt_mutex_get_top_task only if the task is
>  boosted (as suggested by Steve)
>
>  Changes from v1:
>- Steve pointed out that we were actually using the second parameter
>  to permorm initialization
>- Luca confirmed that behavior is slightly changed w.r.t. before his
>  change
>- changelog updated and original behavior restored
> ---
>  kernel/sched/deadline.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index fcb7f0217ff4..7aeb21963d3c 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -346,11 +346,12 @@ static void check_preempt_curr_dl(struct rq *rq, struct 
> task_struct *p,
>   * one, and to (try to!) reconcile itself with its own scheduling
>   * parameters.
>   */
> -static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se,
> -struct sched_dl_entity *pi_se)
> +static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se)
>  {
>   struct dl_rq *dl_rq = dl_rq_of_se(dl_se);
>   struct rq *rq = rq_of_dl_rq(dl_rq);
> + struct task_struct *pi_task;
> + struct sched_dl_entity *pi_se = dl_se;
>  
>   WARN_ON(dl_time_before(rq_clock(rq), dl_se->deadline));
>  
> @@ -363,6 +364,15 @@ static inline void setup_new_dl_entity(struct 
> sched_dl_entity *dl_se,
>   return;
>  
>   /*
> +  * Use the scheduling parameters of the top pi-waiter task,
> +  * if we have one from which we can inherit a deadline.
> +  */
> + if (dl_se->dl_boosted &&
> + (pi_task = rt_mutex_get_top_task(dl_task_of(dl_se))) &&
> + dl_prio(pi_task->normal_prio))
> + pi_se = _task->dl;
> +
> + /*
>* We use the regular wall clock time to set deadlines in the
>* future; in fact, we must consider execution overheads (time
>* spent on hardirq context, etc.).
> @@ -1721,7 +1731,7 @@ static void switched_from_dl(struct rq *rq, struct 
> task_struct *p)
>  static void switched_to_dl(struct rq *rq, struct task_struct *p)
>  {
>   if (dl_time_before(p->dl.deadline, rq_clock(rq)))
> - setup_new_dl_entity(>dl, >dl);
> + setup_new_dl_entity(>dl);

I'm curious why we even call setup_new_dl_entity() for non-queued cases?
It seems more reasonable to do it when it really gets queued. We can see
that enqueue_task_dl()->update_dl_entity() also has the same update logic
as switched_to_dl().

If so, for already queued and boosted cases, rt_mutex_setprio() will call
enqueue_task() with ENQUEUE_REPLENISH set, so enqueue_dl_entity()
->replenish_dl_entity() will advance p->dl.deadline beforehand, see code:
replenish_dl_entity():
if (dl_se->dl_deadline == 0) {
dl_se->deadline = rq_clock(rq) + pi_se->dl_deadline;
dl_se->runtime = pi_se->dl_runtime;
}

IOW, we don't need to handle !dl boosted cases in setup_new_dl_entity().

Regards,
Xunlei

>  
>   if (task_on_rq_queued(p) && rq->curr != p) {
>  #ifdef CONFIG_SMP

Re: [PATCH v3] sched/deadline: remove useless param from setup_new_dl_entity

[Xunlei Pang]

On 2016/07/08 at 19:28, Juri Lelli wrote:
> setup_new_dl_entity() takes two parameters, but it only actually uses
> one of them, under a different name, to setup a new dl_entity, after:
>
>  2f9f3fdc928 "sched/deadline: Remove dl_new from struct sched_dl_entity"
>
> as we currently do
>
>  setup_new_dl_entity(>dl, >dl)
>
> However, before Luca's change we were doing
>
>  setup_new_dl_entity(dl_se, pi_se)
>
> in update_dl_entity() for a dl_se->new entity: we were using pi_se's
> parameters (the potential PI donor) for setting up a new entity.
>
> Restore this behaviour (as we want to correctly initialize parameters of
> a boosted task that enters DEADLINE) by removing the useless second
> parameter of setup_new_dl_entity() and retrieving the top waiter
> directly from inside that function.
>
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Steven Rostedt 
> Cc: Luca Abeni 
> Signed-off-by: Juri Lelli 
>
> ---
>  Changes from v2:
>- optimize by calling rt_mutex_get_top_task only if the task is
>  boosted (as suggested by Steve)
>
>  Changes from v1:
>- Steve pointed out that we were actually using the second parameter
>  to permorm initialization
>- Luca confirmed that behavior is slightly changed w.r.t. before his
>  change
>- changelog updated and original behavior restored
> ---
>  kernel/sched/deadline.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
> index fcb7f0217ff4..7aeb21963d3c 100644
> --- a/kernel/sched/deadline.c
> +++ b/kernel/sched/deadline.c
> @@ -346,11 +346,12 @@ static void check_preempt_curr_dl(struct rq *rq, struct 
> task_struct *p,
>   * one, and to (try to!) reconcile itself with its own scheduling
>   * parameters.
>   */
> -static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se,
> -struct sched_dl_entity *pi_se)
> +static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se)
>  {
>   struct dl_rq *dl_rq = dl_rq_of_se(dl_se);
>   struct rq *rq = rq_of_dl_rq(dl_rq);
> + struct task_struct *pi_task;
> + struct sched_dl_entity *pi_se = dl_se;
>  
>   WARN_ON(dl_time_before(rq_clock(rq), dl_se->deadline));
>  
> @@ -363,6 +364,15 @@ static inline void setup_new_dl_entity(struct 
> sched_dl_entity *dl_se,
>   return;
>  
>   /*
> +  * Use the scheduling parameters of the top pi-waiter task,
> +  * if we have one from which we can inherit a deadline.
> +  */
> + if (dl_se->dl_boosted &&
> + (pi_task = rt_mutex_get_top_task(dl_task_of(dl_se))) &&
> + dl_prio(pi_task->normal_prio))
> + pi_se = _task->dl;
> +
> + /*
>* We use the regular wall clock time to set deadlines in the
>* future; in fact, we must consider execution overheads (time
>* spent on hardirq context, etc.).
> @@ -1721,7 +1731,7 @@ static void switched_from_dl(struct rq *rq, struct 
> task_struct *p)
>  static void switched_to_dl(struct rq *rq, struct task_struct *p)
>  {
>   if (dl_time_before(p->dl.deadline, rq_clock(rq)))
> - setup_new_dl_entity(>dl, >dl);
> + setup_new_dl_entity(>dl);

I'm curious why we even call setup_new_dl_entity() for non-queued cases?
It seems more reasonable to do it when it really gets queued. We can see
that enqueue_task_dl()->update_dl_entity() also has the same update logic
as switched_to_dl().

If so, for already queued and boosted cases, rt_mutex_setprio() will call
enqueue_task() with ENQUEUE_REPLENISH set, so enqueue_dl_entity()
->replenish_dl_entity() will advance p->dl.deadline beforehand, see code:
replenish_dl_entity():
if (dl_se->dl_deadline == 0) {
dl_se->deadline = rq_clock(rq) + pi_se->dl_deadline;
dl_se->runtime = pi_se->dl_runtime;
}

IOW, we don't need to handle !dl boosted cases in setup_new_dl_entity().

Regards,
Xunlei

>  
>   if (task_on_rq_queued(p) && rq->curr != p) {
>  #ifdef CONFIG_SMP

Re: [RFT PATCH v5 0/3] Fix preemption timer optimization while nested guests run

[Wanpeng Li]

2016-07-08 20:02 GMT+08:00 Paolo Bonzini :
> As mentioned earlier, I don't have a reproducer yet that requires any
> changes beyond Wanpeng's (patch 1)---it's possible of course to write
> a kvm-unit-test testcase but I haven't had time for that yet.
>
> Thanks,
>
> Paolo Bonzini (2):
>   KVM: VMX: reflect broken preemption timer in vmcs_config
>   KVM: nVMX: keep preemption timer enabled during L2 execution

Cool, this patchset works after my testing. Feel free to add my
Tested-by for your two patches. :)

Regards,
Wanpeng Li

Re: [RFT PATCH v5 0/3] Fix preemption timer optimization while nested guests run

[Wanpeng Li]

2016-07-08 20:02 GMT+08:00 Paolo Bonzini :
> As mentioned earlier, I don't have a reproducer yet that requires any
> changes beyond Wanpeng's (patch 1)---it's possible of course to write
> a kvm-unit-test testcase but I haven't had time for that yet.
>
> Thanks,
>
> Paolo Bonzini (2):
>   KVM: VMX: reflect broken preemption timer in vmcs_config
>   KVM: nVMX: keep preemption timer enabled during L2 execution

Cool, this patchset works after my testing. Feel free to add my
Tested-by for your two patches. :)

Regards,
Wanpeng Li

[RFC PATCH] clk: move check of CLK_SET_RATE_GATE flag to clk_propagate_rate_change()

[jiada_wang]

From: Jiada Wang 

Previously CLK_SET_RATE_GATE flag is only checked in clk_set_rate()
which only ensures the clock being called by clk_set_rate() won't
change rate when it has been prepared if CLK_SET_RATE_GATE flag is set.
But a clk_set_rate() request may propagate rate change to these clocks
from the requested clock's topmost parent clock to all its offsprings,
when any one of these clocks has CLK_SET_RATE_GATE flag set
and it has been prepared, the clk_set_rate() request should fail.

This patch moves check of CLK_SET_RATE_GATE flag to
clk_propagate_rate_change() to ensure all affected clocks will
be checked if their rate will be changed after clk_set_rate().

Signed-off-by: Jiada Wang 
---
 drivers/clk/clk.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 820a939..aa5e4c3 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1437,6 +1437,9 @@ static struct clk_core *clk_propagate_rate_change(struct 
clk_core *core,
if (core->rate == core->new_rate)
return NULL;
 
+   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
+   return -EBUSY;
+
if (core->notifier_count) {
ret = __clk_notify(core, event, core->rate, core->new_rate);
if (ret & NOTIFY_STOP_MASK)
@@ -1571,9 +1574,6 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
if (rate == clk_core_get_rate_nolock(core))
return 0;
 
-   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
-   return -EBUSY;
-
/* calculate new rates and get the topmost changed clock */
top = clk_calc_new_rates(core, rate);
if (!top)
-- 
1.7.9.5

[RFC PATCH] clk: move check of CLK_SET_RATE_GATE flag to clk_propagate_rate_change()

[jiada_wang]

From: Jiada Wang 

Previously CLK_SET_RATE_GATE flag is only checked in clk_set_rate()
which only ensures the clock being called by clk_set_rate() won't
change rate when it has been prepared if CLK_SET_RATE_GATE flag is set.
But a clk_set_rate() request may propagate rate change to these clocks
from the requested clock's topmost parent clock to all its offsprings,
when any one of these clocks has CLK_SET_RATE_GATE flag set
and it has been prepared, the clk_set_rate() request should fail.

This patch moves check of CLK_SET_RATE_GATE flag to
clk_propagate_rate_change() to ensure all affected clocks will
be checked if their rate will be changed after clk_set_rate().

Signed-off-by: Jiada Wang 
---
 drivers/clk/clk.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 820a939..aa5e4c3 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1437,6 +1437,9 @@ static struct clk_core *clk_propagate_rate_change(struct 
clk_core *core,
if (core->rate == core->new_rate)
return NULL;
 
+   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
+   return -EBUSY;
+
if (core->notifier_count) {
ret = __clk_notify(core, event, core->rate, core->new_rate);
if (ret & NOTIFY_STOP_MASK)
@@ -1571,9 +1574,6 @@ static int clk_core_set_rate_nolock(struct clk_core *core,
if (rate == clk_core_get_rate_nolock(core))
return 0;
 
-   if ((core->flags & CLK_SET_RATE_GATE) && core->prepare_count)
-   return -EBUSY;
-
/* calculate new rates and get the topmost changed clock */
top = clk_calc_new_rates(core, rate);
if (!top)
-- 
1.7.9.5

linux-next: manual merge of the block tree with the f2fs tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  fs/f2fs/data.c

between commits:

  19a5f5e2ef37 ("f2fs: drop any block plugging")
  52763a4b7a21 ("f2fs: detect host-managed SMR by feature flag")
  78682f794479 ("f2fs: fix to avoid reading out encrypted data in page cache")

from the f2fs tree and commits:

  4e49ea4a3d27 ("block/fs/drivers: remove rw argument from submit_bio")
  04d328defd06 ("f2fs: use bio op accessors")

from the block tree.

I fixed it up (see below - I am not confident of these fixups, so
please check and let me know if anything else is needed) and can carry
the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/f2fs/data.c
index 20b30162e7b4,8769e8349dff..
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@@ -100,16 -97,11 +100,16 @@@ static struct bio *__bio_alloc(struct f
return bio;
  }
  
- static inline void __submit_bio(struct f2fs_sb_info *sbi, int rw,
-   struct bio *bio, enum page_type type)
 -static inline void __submit_bio(struct f2fs_sb_info *sbi, struct bio *bio)
++static inline void __submit_bio(struct f2fs_sb_info *sbi, struct bio *bio,
++  enum page_type type)
  {
-   if (!is_read_io(rw)) {
 -  if (!is_read_io(bio_op(bio)))
++  if (!is_read_io(bio_op(bio))) {
atomic_inc(>nr_wb_bios);
 +  if (f2fs_sb_mounted_hmsmr(sbi->sb) &&
 +  current->plug && (type == DATA || type == NODE))
 +  blk_finish_plug(current->plug);
 +  }
-   submit_bio(rw, bio);
+   submit_bio(bio);
  }
  
  static void __submit_merged_bio(struct f2fs_bio_info *io)
@@@ -124,7 -116,9 +124,9 @@@
else
trace_f2fs_submit_write_bio(io->sbi->sb, fio, io->bio);
  
-   __submit_bio(io->sbi, fio->rw, io->bio, fio->type);
+   bio_set_op_attrs(io->bio, fio->op, fio->op_flags);
+ 
 -  __submit_bio(io->sbi, io->bio);
++  __submit_bio(io->sbi, io->bio, fio->type);
io->bio = NULL;
  }
  
@@@ -241,8 -237,10 +245,10 @@@ int f2fs_submit_page_bio(struct f2fs_io
bio_put(bio);
return -EFAULT;
}
+   bio->bi_rw = fio->op_flags;
+   bio_set_op_attrs(bio, fio->op, fio->op_flags);
  
-   __submit_bio(fio->sbi, fio->rw, bio, fio->type);
 -  __submit_bio(fio->sbi, bio);
++  __submit_bio(fio->sbi, bio, fio->type);
return 0;
  }
  
@@@ -1080,13 -1057,36 +1087,14 @@@ got_it
 */
if (bio && (last_block_in_bio != block_nr - 1)) {
  submit_and_realloc:
-   __submit_bio(F2FS_I_SB(inode), READ, bio, DATA);
 -  __submit_bio(F2FS_I_SB(inode), bio);
++  __submit_bio(F2FS_I_SB(inode), bio, DATA);
bio = NULL;
}
if (bio == NULL) {
 -  struct fscrypt_ctx *ctx = NULL;
 -
 -  if (f2fs_encrypted_inode(inode) &&
 -  S_ISREG(inode->i_mode)) {
 -
 -  ctx = fscrypt_get_ctx(inode, GFP_NOFS);
 -  if (IS_ERR(ctx))
 -  goto set_error_page;
 -
 -  /* wait the page to be moved by cleaning */
 -  f2fs_wait_on_encrypted_page_writeback(
 -  F2FS_I_SB(inode), block_nr);
 -  }
 -
 -  bio = bio_alloc(GFP_KERNEL,
 -  min_t(int, nr_pages, BIO_MAX_PAGES));
 -  if (!bio) {
 -  if (ctx)
 -  fscrypt_release_ctx(ctx);
 +  bio = f2fs_grab_bio(inode, block_nr, nr_pages);
 +  if (IS_ERR(bio))
goto set_error_page;
 -  }
 -  bio->bi_bdev = bdev;
 -  bio->bi_iter.bi_sector = SECTOR_FROM_BLOCK(block_nr);
 -  bio->bi_end_io = f2fs_read_end_io;
 -  bio->bi_private = ctx;
+   bio_set_op_attrs(bio, REQ_OP_READ, 0);
}
  
if (bio_add_page(bio, page, blocksize, 0) < blocksize)
@@@ -1101,7 -1101,7 +1109,7 @@@ set_error_page
goto next_page;
  confused:
if (bio) {
-   __submit_bio(F2FS_I_SB(inode), READ, bio, DATA);
 -  __submit_bio(F2FS_I_SB(inode), bio);
++  __submit_bio(F2FS_I_SB(inode), bio, DATA);
   

linux-next: manual merge of the block tree with the f2fs tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in:

  fs/f2fs/data.c

between commits:

  19a5f5e2ef37 ("f2fs: drop any block plugging")
  52763a4b7a21 ("f2fs: detect host-managed SMR by feature flag")
  78682f794479 ("f2fs: fix to avoid reading out encrypted data in page cache")

from the f2fs tree and commits:

  4e49ea4a3d27 ("block/fs/drivers: remove rw argument from submit_bio")
  04d328defd06 ("f2fs: use bio op accessors")

from the block tree.

I fixed it up (see below - I am not confident of these fixups, so
please check and let me know if anything else is needed) and can carry
the fix as necessary. This is now fixed as far as linux-next is
concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the
conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/f2fs/data.c
index 20b30162e7b4,8769e8349dff..
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@@ -100,16 -97,11 +100,16 @@@ static struct bio *__bio_alloc(struct f
return bio;
  }
  
- static inline void __submit_bio(struct f2fs_sb_info *sbi, int rw,
-   struct bio *bio, enum page_type type)
 -static inline void __submit_bio(struct f2fs_sb_info *sbi, struct bio *bio)
++static inline void __submit_bio(struct f2fs_sb_info *sbi, struct bio *bio,
++  enum page_type type)
  {
-   if (!is_read_io(rw)) {
 -  if (!is_read_io(bio_op(bio)))
++  if (!is_read_io(bio_op(bio))) {
atomic_inc(>nr_wb_bios);
 +  if (f2fs_sb_mounted_hmsmr(sbi->sb) &&
 +  current->plug && (type == DATA || type == NODE))
 +  blk_finish_plug(current->plug);
 +  }
-   submit_bio(rw, bio);
+   submit_bio(bio);
  }
  
  static void __submit_merged_bio(struct f2fs_bio_info *io)
@@@ -124,7 -116,9 +124,9 @@@
else
trace_f2fs_submit_write_bio(io->sbi->sb, fio, io->bio);
  
-   __submit_bio(io->sbi, fio->rw, io->bio, fio->type);
+   bio_set_op_attrs(io->bio, fio->op, fio->op_flags);
+ 
 -  __submit_bio(io->sbi, io->bio);
++  __submit_bio(io->sbi, io->bio, fio->type);
io->bio = NULL;
  }
  
@@@ -241,8 -237,10 +245,10 @@@ int f2fs_submit_page_bio(struct f2fs_io
bio_put(bio);
return -EFAULT;
}
+   bio->bi_rw = fio->op_flags;
+   bio_set_op_attrs(bio, fio->op, fio->op_flags);
  
-   __submit_bio(fio->sbi, fio->rw, bio, fio->type);
 -  __submit_bio(fio->sbi, bio);
++  __submit_bio(fio->sbi, bio, fio->type);
return 0;
  }
  
@@@ -1080,13 -1057,36 +1087,14 @@@ got_it
 */
if (bio && (last_block_in_bio != block_nr - 1)) {
  submit_and_realloc:
-   __submit_bio(F2FS_I_SB(inode), READ, bio, DATA);
 -  __submit_bio(F2FS_I_SB(inode), bio);
++  __submit_bio(F2FS_I_SB(inode), bio, DATA);
bio = NULL;
}
if (bio == NULL) {
 -  struct fscrypt_ctx *ctx = NULL;
 -
 -  if (f2fs_encrypted_inode(inode) &&
 -  S_ISREG(inode->i_mode)) {
 -
 -  ctx = fscrypt_get_ctx(inode, GFP_NOFS);
 -  if (IS_ERR(ctx))
 -  goto set_error_page;
 -
 -  /* wait the page to be moved by cleaning */
 -  f2fs_wait_on_encrypted_page_writeback(
 -  F2FS_I_SB(inode), block_nr);
 -  }
 -
 -  bio = bio_alloc(GFP_KERNEL,
 -  min_t(int, nr_pages, BIO_MAX_PAGES));
 -  if (!bio) {
 -  if (ctx)
 -  fscrypt_release_ctx(ctx);
 +  bio = f2fs_grab_bio(inode, block_nr, nr_pages);
 +  if (IS_ERR(bio))
goto set_error_page;
 -  }
 -  bio->bi_bdev = bdev;
 -  bio->bi_iter.bi_sector = SECTOR_FROM_BLOCK(block_nr);
 -  bio->bi_end_io = f2fs_read_end_io;
 -  bio->bi_private = ctx;
+   bio_set_op_attrs(bio, REQ_OP_READ, 0);
}
  
if (bio_add_page(bio, page, blocksize, 0) < blocksize)
@@@ -1101,7 -1101,7 +1109,7 @@@ set_error_page
goto next_page;
  confused:
if (bio) {
-   __submit_bio(F2FS_I_SB(inode), READ, bio, DATA);
 -  __submit_bio(F2FS_I_SB(inode), bio);
++  __submit_bio(F2FS_I_SB(inode), bio, DATA);
   

Re: [PATCH v2 15/22] usb: chipidea: msm: Mux over secondary phy at the right time

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:06PM -0700, Stephen Boyd wrote:
> We need to pick the correct phy at runtime based on how the SoC
> has been wired onto the board. If the secondary phy is used, take
> it out of reset and mux over to it by writing into the TCSR
> register. Make sure to do this on reset too, because this
> register is reset to the default value (primary phy) after the
> RESET bit is set in USBCMD.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 67 
> +++---
>  1 file changed, 62 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 7e870a253f55..7708bee3ff3e 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -8,29 +8,44 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  #include "ci.h"
>  
>  #define HS_PHY_AHB_MODE  0x0098
>  
> +/* Vendor base starts at 0x200 beyond CI base */
> +#define HS_PHY_SEC_CTRL  0x0078
> +#define HS_PHY_DIG_CLAMP_N   BIT(16)
> +

Keep alignment

>  struct ci_hdrc_msm {
>   struct platform_device *ci;
>   struct clk *core_clk;
>   struct clk *iface_clk;
>   struct clk *fs_clk;
> + bool secondary_phy;
> + void __iomem *base;
>  };
>  
>  static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
>  {
> - struct device *dev = ci->gadget.dev.parent;
> + struct device *dev = ci->dev->parent;
> + struct ci_hdrc_msm *msm_ci = dev_get_drvdata(dev);
>  
>   switch (event) {
>   case CI_HDRC_CONTROLLER_RESET_EVENT:
>   dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
> + if (msm_ci->secondary_phy) {
> + u32 val = readl_relaxed(msm_ci->base + HS_PHY_SEC_CTRL);
> + val |= HS_PHY_DIG_CLAMP_N;
> + writel_relaxed(val, msm_ci->base + HS_PHY_SEC_CTRL);
> + }
> +
>   /* use AHB transactor, allow posted data writes */
>   hw_write_id_reg(ci, HS_PHY_AHB_MODE, 0x, 0x8);
>   usb_phy_init(ci->usb_phy);
> @@ -59,6 +74,39 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = 
> {
>   .notify_event   = ci_hdrc_msm_notify_event,
>  };
>  
> +static int ci_hdrc_msm_mux_phy(struct ci_hdrc_msm *ci,
> +struct platform_device *pdev)
> +{
> + struct regmap *regmap;
> + struct device *dev = >dev;
> + struct of_phandle_args args;
> + u32 val;
> + int ret;
> +
> + ret = of_parse_phandle_with_fixed_args(dev->of_node, "phy-select", 2, 0,
> +);
> + if (ret)
> + return 0;
> +
> + regmap = syscon_node_to_regmap(args.np);
> + of_node_put(args.np);
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + ret = regmap_write(regmap, args.args[0], args.args[1]);
> + if (ret)
> + return ret;
> +
> + ci->secondary_phy = !!args.args[1];
> + if (ci->secondary_phy) {
> + val = readl_relaxed(ci->base + HS_PHY_SEC_CTRL);
> + val |= HS_PHY_DIG_CLAMP_N;
> + writel_relaxed(val, ci->base + HS_PHY_SEC_CTRL);
> + }
> +
> + return 0;
> +}
> +
>  static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  {
>   struct ci_hdrc_msm *ci;
> @@ -66,6 +114,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>   struct usb_phy *phy;
>   struct clk *clk;
>   struct reset_control *reset;
> + struct resource *res;
>   int ret;
>  
>   dev_dbg(>dev, "ci_hdrc_msm_probe\n");
> @@ -105,6 +154,11 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   ci->fs_clk = NULL;
>   }
>  
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + ci->base = devm_ioremap_resource(>dev, res);
> + if (!ci->base)
> + return -ENOMEM;
> +
>   ret = clk_prepare_enable(ci->fs_clk);
>   if (ret)
>   return ret;
> @@ -123,9 +177,12 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   if (ret)
>   goto err_iface;
>  
> - plat_ci = ci_hdrc_add_device(>dev,
> - pdev->resource, pdev->num_resources,
> - _hdrc_msm_platdata);
> + ret = ci_hdrc_msm_mux_phy(ci, pdev);
> + if (ret)
> + goto err_mux;
> +
> + plat_ci = ci_hdrc_add_device(>dev, pdev->resource,
> +  pdev->num_resources, 
> _hdrc_msm_platdata);

The above line has not changed.

After fixing above, you can add my ack.

Acked-by: Peter Chen 

-- 

Best Regards,

Re: [PATCH v2 15/22] usb: chipidea: msm: Mux over secondary phy at the right time

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:06PM -0700, Stephen Boyd wrote:
> We need to pick the correct phy at runtime based on how the SoC
> has been wired onto the board. If the secondary phy is used, take
> it out of reset and mux over to it by writing into the TCSR
> register. Make sure to do this on reset too, because this
> register is reset to the default value (primary phy) after the
> RESET bit is set in USBCMD.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 67 
> +++---
>  1 file changed, 62 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 7e870a253f55..7708bee3ff3e 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -8,29 +8,44 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  #include "ci.h"
>  
>  #define HS_PHY_AHB_MODE  0x0098
>  
> +/* Vendor base starts at 0x200 beyond CI base */
> +#define HS_PHY_SEC_CTRL  0x0078
> +#define HS_PHY_DIG_CLAMP_N   BIT(16)
> +

Keep alignment

>  struct ci_hdrc_msm {
>   struct platform_device *ci;
>   struct clk *core_clk;
>   struct clk *iface_clk;
>   struct clk *fs_clk;
> + bool secondary_phy;
> + void __iomem *base;
>  };
>  
>  static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
>  {
> - struct device *dev = ci->gadget.dev.parent;
> + struct device *dev = ci->dev->parent;
> + struct ci_hdrc_msm *msm_ci = dev_get_drvdata(dev);
>  
>   switch (event) {
>   case CI_HDRC_CONTROLLER_RESET_EVENT:
>   dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
> + if (msm_ci->secondary_phy) {
> + u32 val = readl_relaxed(msm_ci->base + HS_PHY_SEC_CTRL);
> + val |= HS_PHY_DIG_CLAMP_N;
> + writel_relaxed(val, msm_ci->base + HS_PHY_SEC_CTRL);
> + }
> +
>   /* use AHB transactor, allow posted data writes */
>   hw_write_id_reg(ci, HS_PHY_AHB_MODE, 0x, 0x8);
>   usb_phy_init(ci->usb_phy);
> @@ -59,6 +74,39 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = 
> {
>   .notify_event   = ci_hdrc_msm_notify_event,
>  };
>  
> +static int ci_hdrc_msm_mux_phy(struct ci_hdrc_msm *ci,
> +struct platform_device *pdev)
> +{
> + struct regmap *regmap;
> + struct device *dev = >dev;
> + struct of_phandle_args args;
> + u32 val;
> + int ret;
> +
> + ret = of_parse_phandle_with_fixed_args(dev->of_node, "phy-select", 2, 0,
> +);
> + if (ret)
> + return 0;
> +
> + regmap = syscon_node_to_regmap(args.np);
> + of_node_put(args.np);
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + ret = regmap_write(regmap, args.args[0], args.args[1]);
> + if (ret)
> + return ret;
> +
> + ci->secondary_phy = !!args.args[1];
> + if (ci->secondary_phy) {
> + val = readl_relaxed(ci->base + HS_PHY_SEC_CTRL);
> + val |= HS_PHY_DIG_CLAMP_N;
> + writel_relaxed(val, ci->base + HS_PHY_SEC_CTRL);
> + }
> +
> + return 0;
> +}
> +
>  static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  {
>   struct ci_hdrc_msm *ci;
> @@ -66,6 +114,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>   struct usb_phy *phy;
>   struct clk *clk;
>   struct reset_control *reset;
> + struct resource *res;
>   int ret;
>  
>   dev_dbg(>dev, "ci_hdrc_msm_probe\n");
> @@ -105,6 +154,11 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   ci->fs_clk = NULL;
>   }
>  
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + ci->base = devm_ioremap_resource(>dev, res);
> + if (!ci->base)
> + return -ENOMEM;
> +
>   ret = clk_prepare_enable(ci->fs_clk);
>   if (ret)
>   return ret;
> @@ -123,9 +177,12 @@ static int ci_hdrc_msm_probe(struct platform_device 
> *pdev)
>   if (ret)
>   goto err_iface;
>  
> - plat_ci = ci_hdrc_add_device(>dev,
> - pdev->resource, pdev->num_resources,
> - _hdrc_msm_platdata);
> + ret = ci_hdrc_msm_mux_phy(ci, pdev);
> + if (ret)
> + goto err_mux;
> +
> + plat_ci = ci_hdrc_add_device(>dev, pdev->resource,
> +  pdev->num_resources, 
> _hdrc_msm_platdata);

The above line has not changed.

After fixing above, you can add my ack.

Acked-by: Peter Chen 

-- 

Best Regards,
Peter Chen

Re: linux-next: build failure after merge of the pm tree

[Mika Westerberg]

On Mon, Jul 11, 2016 at 11:46:53AM +1000, Stephen Rothwell wrote:
> Hi Rafael,
> 
> After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> ERROR: "configfs_unregister_subsystem" [samples/configfs/configfs_sample.ko] 
> undefined!
> ERROR: "configfs_register_subsystem" [samples/configfs/configfs_sample.ko] 
> undefined!
> ERROR: "config_group_init" [samples/configfs/configfs_sample.ko] undefined!
> ERROR: "config_item_init_type_name" [samples/configfs/configfs_sample.ko] 
> undefined!
> ERROR: "config_group_init_type_name" [samples/configfs/configfs_sample.ko] 
> undefined!
> ERROR: "configfs_undepend_item" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] 
> undefined!
> ERROR: "config_item_put" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] undefined!
> ERROR: "config_item_init_type_name" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] 
> undefined!
> 
> ... and many more ...
> 
> Presumably (maybe?) caused by commit
> 
>   0bf54fcd9504 ("ACPI: add support for configfs")
> 
> though it is not obvious why this should be a problem.

Looks like it is the module name (configfs.o) that confuses modpost or
linker. The below patch fixes it for me.

From: Mika Westerberg 
Subject: [PATCH] ACPI: Rename configfs.c to acpi_configfs.c to prevent link 
error

If we compile ACPI configfs.c as module it will confuse the linker as it
hides symbols from the actual configfs:

Kernel: arch/x86/boot/bzImage is ready  (#1236)
  MODPOST 5739 modules
ERROR: "configfs_unregister_subsystem" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "configfs_register_subsystem" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "config_group_init" [samples/configfs/configfs_sample.ko] undefined!
ERROR: "config_item_init_type_name" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "config_group_init_type_name" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "configfs_undepend_item" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] 
undefined!
...

Prevent these by renaming the file to acpi_configfs.c instead.

Reported-by: Scott Lawson 
Signed-off-by: Mika Westerberg 
---
 drivers/acpi/Makefile| 2 +-
 drivers/acpi/{configfs.c => acpi_configfs.c} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/acpi/{configfs.c => acpi_configfs.c} (100%)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 1dc2173ad8d0..f72a83df1cf3 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -99,6 +99,6 @@ obj-$(CONFIG_ACPI_EXTLOG) += acpi_extlog.o
 obj-$(CONFIG_PMIC_OPREGION)+= pmic/intel_pmic.o
 obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
 obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
-obj-$(CONFIG_ACPI_CONFIGFS)+= configfs.o
+obj-$(CONFIG_ACPI_CONFIGFS)+= acpi_configfs.o
 
 video-objs += acpi_video.o video_detect.o
diff --git a/drivers/acpi/configfs.c b/drivers/acpi/acpi_configfs.c
similarity index 100%
rename from drivers/acpi/configfs.c
rename to drivers/acpi/acpi_configfs.c
-- 
2.8.1

Re: linux-next: build failure after merge of the pm tree

[Mika Westerberg]

On Mon, Jul 11, 2016 at 11:46:53AM +1000, Stephen Rothwell wrote:
> Hi Rafael,
> 
> After merging the pm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> ERROR: "configfs_unregister_subsystem" [samples/configfs/configfs_sample.ko] 
> undefined!
> ERROR: "configfs_register_subsystem" [samples/configfs/configfs_sample.ko] 
> undefined!
> ERROR: "config_group_init" [samples/configfs/configfs_sample.ko] undefined!
> ERROR: "config_item_init_type_name" [samples/configfs/configfs_sample.ko] 
> undefined!
> ERROR: "config_group_init_type_name" [samples/configfs/configfs_sample.ko] 
> undefined!
> ERROR: "configfs_undepend_item" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] 
> undefined!
> ERROR: "config_item_put" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] undefined!
> ERROR: "config_item_init_type_name" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] 
> undefined!
> 
> ... and many more ...
> 
> Presumably (maybe?) caused by commit
> 
>   0bf54fcd9504 ("ACPI: add support for configfs")
> 
> though it is not obvious why this should be a problem.

Looks like it is the module name (configfs.o) that confuses modpost or
linker. The below patch fixes it for me.

From: Mika Westerberg 
Subject: [PATCH] ACPI: Rename configfs.c to acpi_configfs.c to prevent link 
error

If we compile ACPI configfs.c as module it will confuse the linker as it
hides symbols from the actual configfs:

Kernel: arch/x86/boot/bzImage is ready  (#1236)
  MODPOST 5739 modules
ERROR: "configfs_unregister_subsystem" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "configfs_register_subsystem" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "config_group_init" [samples/configfs/configfs_sample.ko] undefined!
ERROR: "config_item_init_type_name" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "config_group_init_type_name" [samples/configfs/configfs_sample.ko] 
undefined!
ERROR: "configfs_undepend_item" [fs/ocfs2/cluster/ocfs2_nodemanager.ko] 
undefined!
...

Prevent these by renaming the file to acpi_configfs.c instead.

Reported-by: Scott Lawson 
Signed-off-by: Mika Westerberg 
---
 drivers/acpi/Makefile| 2 +-
 drivers/acpi/{configfs.c => acpi_configfs.c} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/acpi/{configfs.c => acpi_configfs.c} (100%)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 1dc2173ad8d0..f72a83df1cf3 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -99,6 +99,6 @@ obj-$(CONFIG_ACPI_EXTLOG) += acpi_extlog.o
 obj-$(CONFIG_PMIC_OPREGION)+= pmic/intel_pmic.o
 obj-$(CONFIG_CRC_PMIC_OPREGION) += pmic/intel_pmic_crc.o
 obj-$(CONFIG_XPOWER_PMIC_OPREGION) += pmic/intel_pmic_xpower.o
-obj-$(CONFIG_ACPI_CONFIGFS)+= configfs.o
+obj-$(CONFIG_ACPI_CONFIGFS)+= acpi_configfs.o
 
 video-objs += acpi_video.o video_detect.o
diff --git a/drivers/acpi/configfs.c b/drivers/acpi/acpi_configfs.c
similarity index 100%
rename from drivers/acpi/configfs.c
rename to drivers/acpi/acpi_configfs.c
-- 
2.8.1

Re: [PATCH v2 14/22] usb: chipidea: msm: Add proper clk and reset support

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:05PM -0700, Stephen Boyd wrote:
> The msm chipidea controller uses two main clks, an AHB clk to
> read/write the MMIO registers and a core clk called the system
> clk that drives the controller itself. Add support for these clks
> as they're required in all designs.
> 
> Also add support for an optional third clk that we need to turn
> on to reset the controller and wrapper logic and other
> "housekeeping" things. This clk was removed in later revisions of
> the hardware because the reset methodology no longer required
> clks to be enabled to propagate resets.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 72 
> +++---
>  1 file changed, 68 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index b282a717bf8c..7e870a253f55 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -10,11 +10,20 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "ci.h"
>  
>  #define HS_PHY_AHB_MODE  0x0098
>  
> +struct ci_hdrc_msm {
> + struct platform_device *ci;
> + struct clk *core_clk;
> + struct clk *iface_clk;
> + struct clk *fs_clk;
> +};
> +
>  static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
>  {
>   struct device *dev = ci->gadget.dev.parent;
> @@ -52,11 +61,20 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata 
> = {
>  
>  static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  {
> + struct ci_hdrc_msm *ci;
>   struct platform_device *plat_ci;
>   struct usb_phy *phy;
> + struct clk *clk;
> + struct reset_control *reset;
> + int ret;
>  
>   dev_dbg(>dev, "ci_hdrc_msm_probe\n");
>  
> + ci = devm_kzalloc(>dev, sizeof(*ci), GFP_KERNEL);
> + if (!ci)
> + return -ENOMEM;
> + platform_set_drvdata(pdev, ci);
> +
>   /*
>* OTG(PHY) driver takes care of PHY initialization, clock management,
>* powering up VBUS, mapping of registers address space and power
> @@ -68,29 +86,75 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  
>   ci_hdrc_msm_platdata.usb_phy = phy;
>  
> + reset = devm_reset_control_get(>dev, "core");
> + if (IS_ERR(reset))
> + return PTR_ERR(reset);
> +
> + ci->core_clk = clk = devm_clk_get(>dev, "core");
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> +
> + ci->iface_clk = clk = devm_clk_get(>dev, "iface");
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> +
> + ci->fs_clk = clk = devm_clk_get(>dev, "fs");
> + if (IS_ERR(clk)) {
> + if (PTR_ERR(clk) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + ci->fs_clk = NULL;
> + }
> +
> + ret = clk_prepare_enable(ci->fs_clk);
> + if (ret)
> + return ret;
> +
> + reset_control_assert(reset);
> + usleep_range(1, 12000);
> + reset_control_deassert(reset);
> +
> + clk_disable_unprepare(ci->fs_clk);
> +
> + ret = clk_prepare_enable(ci->core_clk);
> + if (ret)
> + return ret;
> +
> + ret = clk_prepare_enable(ci->iface_clk);
> + if (ret)
> + goto err_iface;
> +
>   plat_ci = ci_hdrc_add_device(>dev,
>   pdev->resource, pdev->num_resources,
>   _hdrc_msm_platdata);
>   if (IS_ERR(plat_ci)) {
>   dev_err(>dev, "ci_hdrc_add_device failed!\n");
> - return PTR_ERR(plat_ci);
> + ret = PTR_ERR(plat_ci);
> + goto err_mux;
>   }
>  
> - platform_set_drvdata(pdev, plat_ci);
> + ci->ci = plat_ci;
>  
>   pm_runtime_set_active(>dev);
>   pm_runtime_no_callbacks(>dev);
>   pm_runtime_enable(>dev);
>  
>   return 0;
> +
> +err_mux:
> + clk_disable_unprepare(ci->iface_clk);
> +err_iface:
> + clk_disable_unprepare(ci->core_clk);
> + return ret;
>  }
>  
>  static int ci_hdrc_msm_remove(struct platform_device *pdev)
>  {
> - struct platform_device *plat_ci = platform_get_drvdata(pdev);
> + struct ci_hdrc_msm *ci = platform_get_drvdata(pdev);
>  
>   pm_runtime_disable(>dev);
> - ci_hdrc_remove_device(plat_ci);
> + ci_hdrc_remove_device(ci->ci);
> + clk_disable_unprepare(ci->iface_clk);
> + clk_disable_unprepare(ci->core_clk);
>  
>   return 0;
>  }
> -- 

Acked-by: Peter Chen 

-- 

Best Regards,
Peter Chen

Re: [PATCH v2 14/22] usb: chipidea: msm: Add proper clk and reset support

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:05PM -0700, Stephen Boyd wrote:
> The msm chipidea controller uses two main clks, an AHB clk to
> read/write the MMIO registers and a core clk called the system
> clk that drives the controller itself. Add support for these clks
> as they're required in all designs.
> 
> Also add support for an optional third clk that we need to turn
> on to reset the controller and wrapper logic and other
> "housekeeping" things. This clk was removed in later revisions of
> the hardware because the reset methodology no longer required
> clks to be enabled to propagate resets.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 72 
> +++---
>  1 file changed, 68 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index b282a717bf8c..7e870a253f55 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -10,11 +10,20 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "ci.h"
>  
>  #define HS_PHY_AHB_MODE  0x0098
>  
> +struct ci_hdrc_msm {
> + struct platform_device *ci;
> + struct clk *core_clk;
> + struct clk *iface_clk;
> + struct clk *fs_clk;
> +};
> +
>  static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
>  {
>   struct device *dev = ci->gadget.dev.parent;
> @@ -52,11 +61,20 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata 
> = {
>  
>  static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  {
> + struct ci_hdrc_msm *ci;
>   struct platform_device *plat_ci;
>   struct usb_phy *phy;
> + struct clk *clk;
> + struct reset_control *reset;
> + int ret;
>  
>   dev_dbg(>dev, "ci_hdrc_msm_probe\n");
>  
> + ci = devm_kzalloc(>dev, sizeof(*ci), GFP_KERNEL);
> + if (!ci)
> + return -ENOMEM;
> + platform_set_drvdata(pdev, ci);
> +
>   /*
>* OTG(PHY) driver takes care of PHY initialization, clock management,
>* powering up VBUS, mapping of registers address space and power
> @@ -68,29 +86,75 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  
>   ci_hdrc_msm_platdata.usb_phy = phy;
>  
> + reset = devm_reset_control_get(>dev, "core");
> + if (IS_ERR(reset))
> + return PTR_ERR(reset);
> +
> + ci->core_clk = clk = devm_clk_get(>dev, "core");
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> +
> + ci->iface_clk = clk = devm_clk_get(>dev, "iface");
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
> +
> + ci->fs_clk = clk = devm_clk_get(>dev, "fs");
> + if (IS_ERR(clk)) {
> + if (PTR_ERR(clk) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + ci->fs_clk = NULL;
> + }
> +
> + ret = clk_prepare_enable(ci->fs_clk);
> + if (ret)
> + return ret;
> +
> + reset_control_assert(reset);
> + usleep_range(1, 12000);
> + reset_control_deassert(reset);
> +
> + clk_disable_unprepare(ci->fs_clk);
> +
> + ret = clk_prepare_enable(ci->core_clk);
> + if (ret)
> + return ret;
> +
> + ret = clk_prepare_enable(ci->iface_clk);
> + if (ret)
> + goto err_iface;
> +
>   plat_ci = ci_hdrc_add_device(>dev,
>   pdev->resource, pdev->num_resources,
>   _hdrc_msm_platdata);
>   if (IS_ERR(plat_ci)) {
>   dev_err(>dev, "ci_hdrc_add_device failed!\n");
> - return PTR_ERR(plat_ci);
> + ret = PTR_ERR(plat_ci);
> + goto err_mux;
>   }
>  
> - platform_set_drvdata(pdev, plat_ci);
> + ci->ci = plat_ci;
>  
>   pm_runtime_set_active(>dev);
>   pm_runtime_no_callbacks(>dev);
>   pm_runtime_enable(>dev);
>  
>   return 0;
> +
> +err_mux:
> + clk_disable_unprepare(ci->iface_clk);
> +err_iface:
> + clk_disable_unprepare(ci->core_clk);
> + return ret;
>  }
>  
>  static int ci_hdrc_msm_remove(struct platform_device *pdev)
>  {
> - struct platform_device *plat_ci = platform_get_drvdata(pdev);
> + struct ci_hdrc_msm *ci = platform_get_drvdata(pdev);
>  
>   pm_runtime_disable(>dev);
> - ci_hdrc_remove_device(plat_ci);
> + ci_hdrc_remove_device(ci->ci);
> + clk_disable_unprepare(ci->iface_clk);
> + clk_disable_unprepare(ci->core_clk);
>  
>   return 0;
>  }
> -- 

Acked-by: Peter Chen 

-- 

Best Regards,
Peter Chen

Re: [PATCH] vcodec: mediatek: Add g/s_selection support for V4L2 Encoder

[Hans Verkuil]

Hi Tiffany,

My apologies for the delay, but here is my review at last:

On 05/30/2016 09:52 AM, Tiffany Lin wrote:
> This patch add g/s_selection support for MT8173
> 
> Signed-off-by: Tiffany Lin 
> ---
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c |   74 
> 
>  1 file changed, 74 insertions(+)
> 
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c 
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> index 6e72d73..23ef9a1 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> @@ -630,6 +630,77 @@ static int vidioc_try_fmt_vid_out_mplane(struct file 
> *file, void *priv,
>   return vidioc_try_fmt(f, fmt);
>  }
>  
> +static int vidioc_venc_g_selection(struct file *file, void *priv,
> +  struct v4l2_selection *s)
> +{
> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> + struct mtk_q_data *q_data;
> +
> + /* crop means compose for output devices */
> + switch (s->target) {
> + case V4L2_SEL_TGT_CROP_DEFAULT:
> + case V4L2_SEL_TGT_CROP_BOUNDS:
> + case V4L2_SEL_TGT_CROP:
> + case V4L2_SEL_TGT_COMPOSE_DEFAULT:
> + case V4L2_SEL_TGT_COMPOSE_BOUNDS:
> + case V4L2_SEL_TGT_COMPOSE:
> + if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + mtk_v4l2_err("Invalid s->type = %d", s->type);
> + return -EINVAL;
> + }
> + break;
> + default:
> + mtk_v4l2_err("Invalid s->target = %d", s->target);
> + return -EINVAL;
> + }
> +
> + q_data = mtk_venc_get_q_data(ctx, s->type);
> + if (!q_data)
> + return -EINVAL;
> +
> + s->r.top = 0;
> + s->r.left = 0;
> + s->r.width = q_data->visible_width;
> + s->r.height = q_data->visible_height;
> +
> + return 0;
> +}
> +
> +static int vidioc_venc_s_selection(struct file *file, void *priv,
> +  struct v4l2_selection *s)
> +{
> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> + struct mtk_q_data *q_data;
> +
> + switch (s->target) {
> + case V4L2_SEL_TGT_CROP_DEFAULT:
> + case V4L2_SEL_TGT_CROP_BOUNDS:
> + case V4L2_SEL_TGT_CROP:
> + case V4L2_SEL_TGT_COMPOSE_DEFAULT:
> + case V4L2_SEL_TGT_COMPOSE_BOUNDS:
> + case V4L2_SEL_TGT_COMPOSE:
> + if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + mtk_v4l2_err("Invalid s->type = %d", s->type);
> + return -EINVAL;
> + }
> + break;
> + default:
> + mtk_v4l2_err("Invalid s->target = %d", s->target);
> + return -EINVAL;
> + }
> +
> + q_data = mtk_venc_get_q_data(ctx, s->type);
> + if (!q_data)
> + return -EINVAL;
> +
> + s->r.top = 0;
> + s->r.left = 0;
> + q_data->visible_width = s->r.width;
> + q_data->visible_height = s->r.height;

This makes no sense.

See this page:

https://hverkuil.home.xs4all.nl/spec/media.html#selection-api

For the video output direction (memory -> HW encoder) the data source is
the memory, the data sink is the HW encoder. For the video capture direction
(HW encoder -> memory) the data source is the HW encoder and the data sink
is the memory.

Usually for m2m devices the video output direction may support cropping and
the video capture direction may support composing.

It's not clear what you intend here, especially since you set left and right
to 0. That's not what the selection operation is supposed to do.

Regards,

Hans

> +
> + return 0;
> +}
> +
>  static int vidioc_venc_qbuf(struct file *file, void *priv,
>   struct v4l2_buffer *buf)
>  {
> @@ -688,6 +759,9 @@ const struct v4l2_ioctl_ops mtk_venc_ioctl_ops = {
>  
>   .vidioc_create_bufs = v4l2_m2m_ioctl_create_bufs,
>   .vidioc_prepare_buf = v4l2_m2m_ioctl_prepare_buf,
> +
> + .vidioc_g_selection = vidioc_venc_g_selection,
> + .vidioc_s_selection = vidioc_venc_s_selection,
>  };
>  
>  static int vb2ops_venc_queue_setup(struct vb2_queue *vq,
> 

Re: [PATCH] vcodec: mediatek: Add g/s_selection support for V4L2 Encoder

[Hans Verkuil]

Hi Tiffany,

My apologies for the delay, but here is my review at last:

On 05/30/2016 09:52 AM, Tiffany Lin wrote:
> This patch add g/s_selection support for MT8173
> 
> Signed-off-by: Tiffany Lin 
> ---
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c |   74 
> 
>  1 file changed, 74 insertions(+)
> 
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c 
> b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> index 6e72d73..23ef9a1 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c
> @@ -630,6 +630,77 @@ static int vidioc_try_fmt_vid_out_mplane(struct file 
> *file, void *priv,
>   return vidioc_try_fmt(f, fmt);
>  }
>  
> +static int vidioc_venc_g_selection(struct file *file, void *priv,
> +  struct v4l2_selection *s)
> +{
> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> + struct mtk_q_data *q_data;
> +
> + /* crop means compose for output devices */
> + switch (s->target) {
> + case V4L2_SEL_TGT_CROP_DEFAULT:
> + case V4L2_SEL_TGT_CROP_BOUNDS:
> + case V4L2_SEL_TGT_CROP:
> + case V4L2_SEL_TGT_COMPOSE_DEFAULT:
> + case V4L2_SEL_TGT_COMPOSE_BOUNDS:
> + case V4L2_SEL_TGT_COMPOSE:
> + if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + mtk_v4l2_err("Invalid s->type = %d", s->type);
> + return -EINVAL;
> + }
> + break;
> + default:
> + mtk_v4l2_err("Invalid s->target = %d", s->target);
> + return -EINVAL;
> + }
> +
> + q_data = mtk_venc_get_q_data(ctx, s->type);
> + if (!q_data)
> + return -EINVAL;
> +
> + s->r.top = 0;
> + s->r.left = 0;
> + s->r.width = q_data->visible_width;
> + s->r.height = q_data->visible_height;
> +
> + return 0;
> +}
> +
> +static int vidioc_venc_s_selection(struct file *file, void *priv,
> +  struct v4l2_selection *s)
> +{
> + struct mtk_vcodec_ctx *ctx = fh_to_ctx(priv);
> + struct mtk_q_data *q_data;
> +
> + switch (s->target) {
> + case V4L2_SEL_TGT_CROP_DEFAULT:
> + case V4L2_SEL_TGT_CROP_BOUNDS:
> + case V4L2_SEL_TGT_CROP:
> + case V4L2_SEL_TGT_COMPOSE_DEFAULT:
> + case V4L2_SEL_TGT_COMPOSE_BOUNDS:
> + case V4L2_SEL_TGT_COMPOSE:
> + if (s->type != V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> + mtk_v4l2_err("Invalid s->type = %d", s->type);
> + return -EINVAL;
> + }
> + break;
> + default:
> + mtk_v4l2_err("Invalid s->target = %d", s->target);
> + return -EINVAL;
> + }
> +
> + q_data = mtk_venc_get_q_data(ctx, s->type);
> + if (!q_data)
> + return -EINVAL;
> +
> + s->r.top = 0;
> + s->r.left = 0;
> + q_data->visible_width = s->r.width;
> + q_data->visible_height = s->r.height;

This makes no sense.

See this page:

https://hverkuil.home.xs4all.nl/spec/media.html#selection-api

For the video output direction (memory -> HW encoder) the data source is
the memory, the data sink is the HW encoder. For the video capture direction
(HW encoder -> memory) the data source is the HW encoder and the data sink
is the memory.

Usually for m2m devices the video output direction may support cropping and
the video capture direction may support composing.

It's not clear what you intend here, especially since you set left and right
to 0. That's not what the selection operation is supposed to do.

Regards,

Hans

> +
> + return 0;
> +}
> +
>  static int vidioc_venc_qbuf(struct file *file, void *priv,
>   struct v4l2_buffer *buf)
>  {
> @@ -688,6 +759,9 @@ const struct v4l2_ioctl_ops mtk_venc_ioctl_ops = {
>  
>   .vidioc_create_bufs = v4l2_m2m_ioctl_create_bufs,
>   .vidioc_prepare_buf = v4l2_m2m_ioctl_prepare_buf,
> +
> + .vidioc_g_selection = vidioc_venc_g_selection,
> + .vidioc_s_selection = vidioc_venc_s_selection,
>  };
>  
>  static int vb2ops_venc_queue_setup(struct vb2_queue *vq,
> 

Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls

[Andy Lutomirski]

On Jul 9, 2016 1:37 AM, "Ingo Molnar"  wrote:
>
>
> * Dave Hansen  wrote:
>
> > On 07/08/2016 12:18 AM, Ingo Molnar wrote:
> >
> > > So the question is, what is user-space going to do? Do any glibc patches
> > > exist? How are the user-space library side APIs going to look like?
> >
> > My goal at the moment is to get folks enabled to the point that they can 
> > start
> > modifying apps to use pkeys without having to patch their kernels.
> >  I don't have confidence that we can design good high-level userspace 
> > interfaces
> > without seeing some real apps try to use the low-level ones and seeing how 
> > they
> > struggle.
> >
> > I had some glibc code to do the pkey alloc/free operations, but those aren't
> > necessary if we're doing it in the kernel.  Other than getting the syscall
> > wrappers in place, I don't have any immediate plans to do anything in glibc.
> >
> > Was there something you were expecting to see?
>
> Yeah, so (as you probably guessed!) I'm starting to have second thoughts 
> about the
> complexity of the alloc/free/set/get interface I suggested, and Mel's review
> certainly strengthened that feeling.
>
> I have two worries:
>
> 1)
>
> A technical worry I have is that the 'pkey allocation interface' does not 
> seem to
> be taking the per thread property of pkeys into account - while that property
> would be useful for apps. That is a limitation that seems unjustified.
>
> The reason for this is that we are storing the key allocation bitmap in 
> struct_mm,
> in mm->context.pkey_allocation_map - while we should be storing it in 
> task_struct
> or thread_info.

Huh?  Doesn't this have to be per mm?  Sure, PKRU is per thread, but
the page tables are shared.

> 2)
>
> My main worry is that it appears at this stage that we are still pretty far 
> away
> from completely shadowing the hardware pkey state in the kernel - and without 
> that
> we cannot really force user-space to use the 'proper' APIs. They can just use 
> the
> raw instructions, condition them on a CPUID and be done with it: everything 
> can be
> organized in user-space.
>

My vote would be to keep the allocation mechanism but get rid of pkey_set.

Also, I think the debug poisoning feature is overcomplicated.  Let's
just forbid mprotect_key with an unallocated key.

There are still two issues that I think we need to address, though:

1. Signal delivery shouldn't unconditionally clear PKRU.  That's what
the current patches do, and it's unsafe.  I'd rather set PKRU to the
maximally locked down state on signal delivery (except for the
PROT_EXEC key), although that might cause its own set of problems.

2. When thread A allocates a pkey, how does it lock down thread B?

#2 could be addressed by using fully-locked-down as the initial state
post-exec() and copying the state on clone().  Dave, are there any
cases in practice where one thread would allocate a pkey and want
other threads to immediately have access to the memory with that key?

I find myself wondering whether we should stop using XSAVE for PKRU
sooner rather than later.  If we do anything like the above, we
completely lose the init optimization, and the code would be a good
deal simpler if we switched PKRU directly in switch_to and could
therefore treat it like a normal register everywhere else.

--Andy

Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls

[Andy Lutomirski]

On Jul 9, 2016 1:37 AM, "Ingo Molnar"  wrote:
>
>
> * Dave Hansen  wrote:
>
> > On 07/08/2016 12:18 AM, Ingo Molnar wrote:
> >
> > > So the question is, what is user-space going to do? Do any glibc patches
> > > exist? How are the user-space library side APIs going to look like?
> >
> > My goal at the moment is to get folks enabled to the point that they can 
> > start
> > modifying apps to use pkeys without having to patch their kernels.
> >  I don't have confidence that we can design good high-level userspace 
> > interfaces
> > without seeing some real apps try to use the low-level ones and seeing how 
> > they
> > struggle.
> >
> > I had some glibc code to do the pkey alloc/free operations, but those aren't
> > necessary if we're doing it in the kernel.  Other than getting the syscall
> > wrappers in place, I don't have any immediate plans to do anything in glibc.
> >
> > Was there something you were expecting to see?
>
> Yeah, so (as you probably guessed!) I'm starting to have second thoughts 
> about the
> complexity of the alloc/free/set/get interface I suggested, and Mel's review
> certainly strengthened that feeling.
>
> I have two worries:
>
> 1)
>
> A technical worry I have is that the 'pkey allocation interface' does not 
> seem to
> be taking the per thread property of pkeys into account - while that property
> would be useful for apps. That is a limitation that seems unjustified.
>
> The reason for this is that we are storing the key allocation bitmap in 
> struct_mm,
> in mm->context.pkey_allocation_map - while we should be storing it in 
> task_struct
> or thread_info.

Huh?  Doesn't this have to be per mm?  Sure, PKRU is per thread, but
the page tables are shared.

> 2)
>
> My main worry is that it appears at this stage that we are still pretty far 
> away
> from completely shadowing the hardware pkey state in the kernel - and without 
> that
> we cannot really force user-space to use the 'proper' APIs. They can just use 
> the
> raw instructions, condition them on a CPUID and be done with it: everything 
> can be
> organized in user-space.
>

My vote would be to keep the allocation mechanism but get rid of pkey_set.

Also, I think the debug poisoning feature is overcomplicated.  Let's
just forbid mprotect_key with an unallocated key.

There are still two issues that I think we need to address, though:

1. Signal delivery shouldn't unconditionally clear PKRU.  That's what
the current patches do, and it's unsafe.  I'd rather set PKRU to the
maximally locked down state on signal delivery (except for the
PROT_EXEC key), although that might cause its own set of problems.

2. When thread A allocates a pkey, how does it lock down thread B?

#2 could be addressed by using fully-locked-down as the initial state
post-exec() and copying the state on clone().  Dave, are there any
cases in practice where one thread would allocate a pkey and want
other threads to immediately have access to the memory with that key?

I find myself wondering whether we should stop using XSAVE for PKRU
sooner rather than later.  If we do anything like the above, we
completely lose the init optimization, and the code would be a good
deal simpler if we switched PKRU directly in switch_to and could
therefore treat it like a normal register everywhere else.

--Andy

Re: [PATCH] arm64: defconfig: Enable more IP blocks for Exynos7 and Exynos5433

[Alim Akhtar]

Hi Krzysztof,

On 07/09/2016 01:47 AM, Krzysztof Kozlowski wrote:

Enable more drivers for IP blocks for existing Exynos7 and upcoming
Exynos5433:
1. SPI,
2. Watchdog,
3. USB: DWC3, Exynos EHCI and OHCI,
4. Exynos ADC,
5. Samsung PWM.

These are already used by Exynos7 Espresso board or will be used by
Exynos5433 based board.

Signed-off-by: Krzysztof Kozlowski 


Thanks for posting this patch.

Reviewed-by: Alim Akhtar 


---

If there are no objections, I can take it through Samsung SoC tree.
---
  arch/arm64/configs/defconfig | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index c05b8badec2c..fe6d6c34323a 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -183,6 +183,7 @@ CONFIG_SPI_ORION=y
  CONFIG_SPI_PL022=y
  CONFIG_SPI_QUP=y
  CONFIG_SPI_SPIDEV=m
+CONFIG_SPI_S3C64XX=y
  CONFIG_SPMI=y
  CONFIG_PINCTRL_SINGLE=y
  CONFIG_PINCTRL_MSM8916=y
@@ -202,6 +203,7 @@ CONFIG_THERMAL_EMULATION=y
  CONFIG_EXYNOS_THERMAL=y
  CONFIG_WATCHDOG=y
  CONFIG_RENESAS_WDT=y
+CONFIG_S3C2410_WATCHDOG=y
  CONFIG_MFD_SPMI_PMIC=y
  CONFIG_MFD_SEC_CORE=y
  CONFIG_MFD_HI655X_PMIC=y
@@ -221,18 +223,22 @@ CONFIG_SOUND=y
  CONFIG_SND=y
  CONFIG_SND_SOC=y
  CONFIG_SND_SOC_RCAR=y
+CONFIG_SND_SOC_SAMSUNG=y
  CONFIG_SND_SOC_AK4613=y
  CONFIG_USB=y
  CONFIG_USB_OTG=y
  CONFIG_USB_XHCI_HCD=y
  CONFIG_USB_XHCI_RCAR=y
+CONFIG_USB_EHCI_EXYNOS=y
  CONFIG_USB_EHCI_HCD=y
  CONFIG_USB_EHCI_MSM=y
  CONFIG_USB_EHCI_HCD_PLATFORM=y
+CONFIG_USB_OHCI_EXYNOS=y
  CONFIG_USB_OHCI_HCD=y
  CONFIG_USB_OHCI_HCD_PLATFORM=y
  CONFIG_USB_STORAGE=y
  CONFIG_USB_DWC2=y
+CONFIG_USB_DWC3=y
  CONFIG_USB_CHIPIDEA=y
  CONFIG_USB_CHIPIDEA_UDC=y
  CONFIG_USB_CHIPIDEA_HOST=y
@@ -304,6 +310,10 @@ CONFIG_PHY_HI6220_USB=y
  CONFIG_PHY_XGENE=y
  CONFIG_ARM_SCPI_PROTOCOL=y
  CONFIG_ACPI=y
+CONFIG_IIO=y
+CONFIG_EXYNOS_ADC=y
+CONFIG_PWM=y
+CONFIG_PWM_SAMSUNG=y
  CONFIG_EXT2_FS=y
  CONFIG_EXT3_FS=y
  CONFIG_FANOTIFY=y

Re: [PATCH] arm64: defconfig: Enable more IP blocks for Exynos7 and Exynos5433

[Alim Akhtar]

Hi Krzysztof,

On 07/09/2016 01:47 AM, Krzysztof Kozlowski wrote:

Enable more drivers for IP blocks for existing Exynos7 and upcoming
Exynos5433:
1. SPI,
2. Watchdog,
3. USB: DWC3, Exynos EHCI and OHCI,
4. Exynos ADC,
5. Samsung PWM.

These are already used by Exynos7 Espresso board or will be used by
Exynos5433 based board.

Signed-off-by: Krzysztof Kozlowski 


Thanks for posting this patch.

Reviewed-by: Alim Akhtar 


---

If there are no objections, I can take it through Samsung SoC tree.
---
  arch/arm64/configs/defconfig | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index c05b8badec2c..fe6d6c34323a 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -183,6 +183,7 @@ CONFIG_SPI_ORION=y
  CONFIG_SPI_PL022=y
  CONFIG_SPI_QUP=y
  CONFIG_SPI_SPIDEV=m
+CONFIG_SPI_S3C64XX=y
  CONFIG_SPMI=y
  CONFIG_PINCTRL_SINGLE=y
  CONFIG_PINCTRL_MSM8916=y
@@ -202,6 +203,7 @@ CONFIG_THERMAL_EMULATION=y
  CONFIG_EXYNOS_THERMAL=y
  CONFIG_WATCHDOG=y
  CONFIG_RENESAS_WDT=y
+CONFIG_S3C2410_WATCHDOG=y
  CONFIG_MFD_SPMI_PMIC=y
  CONFIG_MFD_SEC_CORE=y
  CONFIG_MFD_HI655X_PMIC=y
@@ -221,18 +223,22 @@ CONFIG_SOUND=y
  CONFIG_SND=y
  CONFIG_SND_SOC=y
  CONFIG_SND_SOC_RCAR=y
+CONFIG_SND_SOC_SAMSUNG=y
  CONFIG_SND_SOC_AK4613=y
  CONFIG_USB=y
  CONFIG_USB_OTG=y
  CONFIG_USB_XHCI_HCD=y
  CONFIG_USB_XHCI_RCAR=y
+CONFIG_USB_EHCI_EXYNOS=y
  CONFIG_USB_EHCI_HCD=y
  CONFIG_USB_EHCI_MSM=y
  CONFIG_USB_EHCI_HCD_PLATFORM=y
+CONFIG_USB_OHCI_EXYNOS=y
  CONFIG_USB_OHCI_HCD=y
  CONFIG_USB_OHCI_HCD_PLATFORM=y
  CONFIG_USB_STORAGE=y
  CONFIG_USB_DWC2=y
+CONFIG_USB_DWC3=y
  CONFIG_USB_CHIPIDEA=y
  CONFIG_USB_CHIPIDEA_UDC=y
  CONFIG_USB_CHIPIDEA_HOST=y
@@ -304,6 +310,10 @@ CONFIG_PHY_HI6220_USB=y
  CONFIG_PHY_XGENE=y
  CONFIG_ARM_SCPI_PROTOCOL=y
  CONFIG_ACPI=y
+CONFIG_IIO=y
+CONFIG_EXYNOS_ADC=y
+CONFIG_PWM=y
+CONFIG_PWM_SAMSUNG=y
  CONFIG_EXT2_FS=y
  CONFIG_EXT3_FS=y
  CONFIG_FANOTIFY=y

Re: [PATCH v3 0/9] Add MT8173 Video Decoder Driver

[tiffany lin]

Hi Hans,

On Fri, 2016-07-08 at 13:44 +0200, Hans Verkuil wrote:
> On 07/07/2016 12:16 PM, tiffany lin wrote:
> > Hi Hans,
> > 
> > 
> > On Wed, 2016-07-06 at 15:19 +0200, Hans Verkuil wrote:
> >> Hi Tiffany,
> >>
> >> I plan to review this patch series on Friday, but one obvious question is
> >> what the reason for these failures is:
> >>
> >>> Input/Output configuration ioctls:
> >>> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> >>> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> >>> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> >>> test VIDIOC_G/S_EDID: OK (Not Supported)
> >>>
> >>> Control ioctls:
> >>> test VIDIOC_QUERYCTRL/MENU: OK
> >>> fail: 
> >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-controls.cpp(357):
> >>>  g_ctrl returned an error (11)
> >>> test VIDIOC_G/S_CTRL: FAIL
> >>> fail: 
> >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-controls.cpp(579):
> >>>  g_ext_ctrls returned an error (11)
> >>> test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
> > These fails are because VIDIOC_G_CTRL and VIDIOC_G_EXT_CTRLS return
> > V4L2_CID_MIN_BUFFERS_FOR_CAPTURE only when dirver in MTK_STATE_HEADER
> > state, or it will return EAGAIN.
> > This could help user space get correct value, not default value that may
> > changed base on media content.
> 
> OK, I really don't like this. I also looked what the s5p-mfc-dec driver does 
> (the only other
> driver currently implementing this), and that returns -EINVAL.
> 
> My proposal would be to change this. If this information isn't known yet, why 
> not
> just return 0 as the value? The doc would have to be updated and (preferably) 
> also
> the s5p-mfc-dec driver. I've added Samsung devs to the Cc list, let me know 
> what you
> think.
> 
Got it. We will return 0 as the value instead EAGAIN.

> > 
> >>> fail: 
> >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-controls.cpp(721):
> >>>  subscribe event for control 'User Controls' failed
> >>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
> > Driver do not support subscribe event for control 'User Controls' for
> > now.
> > Do we need to support this?
> 
> I don't see why this would fail. It's OK to subscribe to such controls, 
> although
> you'll never get an event.
> 
Got it. I will rerun using latest v4l2-compliance test check this.

> >>> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> >>> Standard Controls: 2 Private Controls: 0
> >>>
> >>> Format ioctls:
> >>> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> >>> test VIDIOC_G/S_PARM: OK (Not Supported)
> >>> test VIDIOC_G_FBUF: OK (Not Supported)
> >>> fail: 
> >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-formats.cpp(405):
> >>>  expected EINVAL, but got 11 when getting format for buftype 9
> >>> test VIDIOC_G_FMT: FAIL
> > This is because vidioc_vdec_g_fmt only succeed when context is in
> > MTK_STATE_HEADER state, or user space cannot get correct format data
> > using this function.
> 
> Comparing this to s5p-mfc-dec I see that -EINVAL is returned in that case.
> 
> I am not opposed to using EAGAIN in s5p-mfc-dec as well. Marek, Kamil, what is
> your opinion?
> 
> > 
> >>> test VIDIOC_TRY_FMT: OK (Not Supported)
> >>> test VIDIOC_S_FMT: OK (Not Supported)
> >>> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> >>>
> >>> Codec ioctls:
> >>> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> >>> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> >>> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> >>>
> >>> Buffer ioctls:
> >>> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> >>> fail: 
> >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(500):
> >>>  q.has_expbuf(node)
> > Our OUTPUT and CAPTURE queue support both VB2_DMABUF and VB2_MMAP, user
> > space can select which to use in runtime.
> > So our driver default support v4l2_m2m_ioctl_expbuf functionality.
> > In v4l2-compliance test, it will check v4l2_m2m_ioctl_expbuf only valid
> > when node->valid_memorytype is V4L2_MEMORY_MMAP.
> > So when go through node->valid_memorytype is V4L2_MEMORY_DMABUF, it
> > fail.
> 
> valid_memorytype should have both MMAP and DMABUF flags.
> 
> But v4l-utils-1.6.0 is way too old to be certain it isn't some 
> v4l2-compliance bug
> that has since been fixed.
> 
Got it. I will rerun using master branch to check this.

best regards,
Tiffany

> Regards,
> 
>   Hans
> 
> > 
> > 
> > best regards,
> > Tiffany
> > 
> > 
> > 
> >>> test VIDIOC_EXPBUF: FAIL
> >>>
> >>>
> >>> Total: 38, Succeeded: 33, Failed: 5, Warnings: 0
> >>
> >> If it is due to a bug in 

Re: [PATCH v3 0/9] Add MT8173 Video Decoder Driver

[tiffany lin]

Hi Hans,

On Fri, 2016-07-08 at 13:44 +0200, Hans Verkuil wrote:
> On 07/07/2016 12:16 PM, tiffany lin wrote:
> > Hi Hans,
> > 
> > 
> > On Wed, 2016-07-06 at 15:19 +0200, Hans Verkuil wrote:
> >> Hi Tiffany,
> >>
> >> I plan to review this patch series on Friday, but one obvious question is
> >> what the reason for these failures is:
> >>
> >>> Input/Output configuration ioctls:
> >>> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> >>> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> >>> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> >>> test VIDIOC_G/S_EDID: OK (Not Supported)
> >>>
> >>> Control ioctls:
> >>> test VIDIOC_QUERYCTRL/MENU: OK
> >>> fail: 
> >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-controls.cpp(357):
> >>>  g_ctrl returned an error (11)
> >>> test VIDIOC_G/S_CTRL: FAIL
> >>> fail: 
> >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-controls.cpp(579):
> >>>  g_ext_ctrls returned an error (11)
> >>> test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
> > These fails are because VIDIOC_G_CTRL and VIDIOC_G_EXT_CTRLS return
> > V4L2_CID_MIN_BUFFERS_FOR_CAPTURE only when dirver in MTK_STATE_HEADER
> > state, or it will return EAGAIN.
> > This could help user space get correct value, not default value that may
> > changed base on media content.
> 
> OK, I really don't like this. I also looked what the s5p-mfc-dec driver does 
> (the only other
> driver currently implementing this), and that returns -EINVAL.
> 
> My proposal would be to change this. If this information isn't known yet, why 
> not
> just return 0 as the value? The doc would have to be updated and (preferably) 
> also
> the s5p-mfc-dec driver. I've added Samsung devs to the Cc list, let me know 
> what you
> think.
> 
Got it. We will return 0 as the value instead EAGAIN.

> > 
> >>> fail: 
> >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-controls.cpp(721):
> >>>  subscribe event for control 'User Controls' failed
> >>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
> > Driver do not support subscribe event for control 'User Controls' for
> > now.
> > Do we need to support this?
> 
> I don't see why this would fail. It's OK to subscribe to such controls, 
> although
> you'll never get an event.
> 
Got it. I will rerun using latest v4l2-compliance test check this.

> >>> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> >>> Standard Controls: 2 Private Controls: 0
> >>>
> >>> Format ioctls:
> >>> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> >>> test VIDIOC_G/S_PARM: OK (Not Supported)
> >>> test VIDIOC_G_FBUF: OK (Not Supported)
> >>> fail: 
> >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-formats.cpp(405):
> >>>  expected EINVAL, but got 11 when getting format for buftype 9
> >>> test VIDIOC_G_FMT: FAIL
> > This is because vidioc_vdec_g_fmt only succeed when context is in
> > MTK_STATE_HEADER state, or user space cannot get correct format data
> > using this function.
> 
> Comparing this to s5p-mfc-dec I see that -EINVAL is returned in that case.
> 
> I am not opposed to using EAGAIN in s5p-mfc-dec as well. Marek, Kamil, what is
> your opinion?
> 
> > 
> >>> test VIDIOC_TRY_FMT: OK (Not Supported)
> >>> test VIDIOC_S_FMT: OK (Not Supported)
> >>> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> >>>
> >>> Codec ioctls:
> >>> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> >>> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> >>> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> >>>
> >>> Buffer ioctls:
> >>> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> >>> fail: 
> >>> ../../../v4l-utils-1.6.0/utils/v4l2-compliance/v4l2-test-buffers.cpp(500):
> >>>  q.has_expbuf(node)
> > Our OUTPUT and CAPTURE queue support both VB2_DMABUF and VB2_MMAP, user
> > space can select which to use in runtime.
> > So our driver default support v4l2_m2m_ioctl_expbuf functionality.
> > In v4l2-compliance test, it will check v4l2_m2m_ioctl_expbuf only valid
> > when node->valid_memorytype is V4L2_MEMORY_MMAP.
> > So when go through node->valid_memorytype is V4L2_MEMORY_DMABUF, it
> > fail.
> 
> valid_memorytype should have both MMAP and DMABUF flags.
> 
> But v4l-utils-1.6.0 is way too old to be certain it isn't some 
> v4l2-compliance bug
> that has since been fixed.
> 
Got it. I will rerun using master branch to check this.

best regards,
Tiffany

> Regards,
> 
>   Hans
> 
> > 
> > 
> > best regards,
> > Tiffany
> > 
> > 
> > 
> >>> test VIDIOC_EXPBUF: FAIL
> >>>
> >>>
> >>> Total: 38, Succeeded: 33, Failed: 5, Warnings: 0
> >>
> >> If it is due to a bug in 

Linux 4.7-rc7

[Linus Torvalds]

We've had a nicely calm week, which is what I expected - the last rc
really was bigger just due to random timing issues, and not some
worrying pattern about this release cycle. Whew.

Anyway, there's a couple of regressions still being looked at, but
unless anything odd happens, this is going to be the last rc. However,
due to my travel schedule, I won't be doing the final 4.7 next
weekend, and people will have two weeks to report (and fix) any
remaining bugs.

Yeah, that's the ticket. My travel schedule isn't screwing anything
up, instead think of it as you guys getting a BONUS WEEK! Yay!

Ok, my travel schedule probably _is_ screwing somebody's plans up, for
which I apologize in advance. And hey, even that planned delay could
obviously change, if somebody finds some real killer bug. But it
doesn't look all that likely, considering that this hasn't been a
particularly big or scary release cycle.

But do go out and test. The appended shortlog gives the details on the
preceding calm week, but the overview is very normal: two thirds
drivers (networking, sound, gpio, misc), with the rest being pretty
evenly split between arch fixes and "misc" (in this case mostly core
kernel, networking, and ecryptfs). But all of it is pretty small.

 Linus

---

Aaron Campbell (1):
  iommu/vt-d: Fix infinite loop in free_all_cpu_cached_iovas

Ajit Pandey (1):
  ASoC: wm5110: Add missing route from OUT3R to SYSCLK

Alan Cox (1):
  ASoC: Intel: atom: fix missing breaks that would cause the wrong
operation to execute

Alan Stern (1):
  SCSI: fix new bug in scsi_dev_info_list string matching

Alexander Shiyan (1):
  ASoC: fsl_ssi: Fix number of words per frame for I2S-slave mode

Arnd Bergmann (1):
  ASoC: hdmi-codec: select CONFIG_HDMI

Aviv Heller (1):
  bonding: fix enslavement slave link notifications

Bard Liao (2):
  ASoC: rt5670: fix HP Playback Volume control
  ASoC: rt5645: fix reg-2f default value.

Ben Skeggs (1):
  drm/nouveau/disp/sor/gf119: select correct sor when poking
training pattern

Bjørn Mork (1):
  cdc_ncm: workaround for EM7455 "silent" data interface

Bob Copeland (1):
  ALSA: hda - fix read before array start

Bob Liu (1):
  xen-blkfront: save uncompleted reqs in blkfront_resume()

Borislav Petkov (1):
  x86/amd_nb: Fix boot crash on non-AMD systems

Brian King (1):
  ipr: Clear interrupt on croc/crocodile when running with LSI

Bruno Prémont (1):
  qla2xxx: Fix NULL pointer deref in QLA interrupt

Charles Keepax (1):
  ASoC: wm5102: Correct supported channels on trace compressed DAI

Chris J Arges (1):
  ecryptfs: fix spelling mistakes

Christophe JAILLET (1):
  ALSA: echoaudio: Fix memory allocation

Christophe Jaillet (1):
  fsl/fman: fix error handling

Colin Pitrat (1):
  gpio: sch: Fix Oops on module load on Asus Eee PC 1201

Dan Carpenter (1):
  platform/chrome: cros_ec_dev - double fetch bug in ioctl

Daniel Borkmann (1):
  macsec: set actual real device for xmit when !protect_frames

Daniel Jurgens (5):
  net/mlx5: Fix incorrect page count when in internal error
  net/mlx5: Fix wait_vital for VFs and remove fixed sleep
  net/mlx5e: Timeout if SQ doesn't flush during close
  net/mlx5e: Implement ndo_tx_timeout callback
  net/mlx5e: Handle RQ flush in error cases

David Daney (1):
  MIPS: Fix page table corruption on THP permission changes.

David S. Miller (2):
  packet: Use symmetric hash for PACKET_FANOUT_HASH.
  Revert "fsl/fman: fix error handling"

Eric Dumazet (1):
  bonding: prevent out of bound accesses

Fabio Estevam (1):
  ASoC: ak4613: Remove owner assignment from platform_driver

Florian Fainelli (1):
  net: bcmsysport: Device stats are unsigned long

Ganapatrao Kulkarni (1):
  arm64: Enable workaround for Cavium erratum 27456 on thunderx-81xx

Ganesh Goudar (1):
  cxgb4: update latest firmware version supported

Geert Uytterhoeven (2):
  ASoC: wm8940: Enable cache usage to fix crashes on resume
  ASoC: ak4613: Enable cache usage to fix crashes on resume

Haishuang Yan (1):
  geneve: fix max_mtu setting

Huang Rui (2):
  drm/amd/powerplay: fix incorrect voltage table value for polaris10
  drm/amd/powerplay: fix incorrect voltage table value for tonga

Hugh Dickins (1):
  tmpfs: fix regression hang in fallocate undo

James Morse (1):
  arm64: kernel: Save and restore UAO and addr_limit on exception entry

Jan Beulich (4):
  xenbus: don't BUG() on user mode induced condition
  xenbus: don't bail early from xenbus_dev_request_and_reply()
  xenbus: simplify xenbus_dev_request_and_reply()
  xen/acpi: allow xen-acpi-processor driver to load on Xen 4.7

Janusz Krzysztofik (1):
  ASoC: cx20442: set tty->receiver_room in v253_open

Jarod Wilson (1):
  e1000e: keep Rx/Tx HW_VLAN_CTAG in sync

Jeff Mahoney (2):
  Revert "ecryptfs: forbid opening files without mmap handler"
  

Linux 4.7-rc7

[Linus Torvalds]

We've had a nicely calm week, which is what I expected - the last rc
really was bigger just due to random timing issues, and not some
worrying pattern about this release cycle. Whew.

Anyway, there's a couple of regressions still being looked at, but
unless anything odd happens, this is going to be the last rc. However,
due to my travel schedule, I won't be doing the final 4.7 next
weekend, and people will have two weeks to report (and fix) any
remaining bugs.

Yeah, that's the ticket. My travel schedule isn't screwing anything
up, instead think of it as you guys getting a BONUS WEEK! Yay!

Ok, my travel schedule probably _is_ screwing somebody's plans up, for
which I apologize in advance. And hey, even that planned delay could
obviously change, if somebody finds some real killer bug. But it
doesn't look all that likely, considering that this hasn't been a
particularly big or scary release cycle.

But do go out and test. The appended shortlog gives the details on the
preceding calm week, but the overview is very normal: two thirds
drivers (networking, sound, gpio, misc), with the rest being pretty
evenly split between arch fixes and "misc" (in this case mostly core
kernel, networking, and ecryptfs). But all of it is pretty small.

 Linus

---

Aaron Campbell (1):
  iommu/vt-d: Fix infinite loop in free_all_cpu_cached_iovas

Ajit Pandey (1):
  ASoC: wm5110: Add missing route from OUT3R to SYSCLK

Alan Cox (1):
  ASoC: Intel: atom: fix missing breaks that would cause the wrong
operation to execute

Alan Stern (1):
  SCSI: fix new bug in scsi_dev_info_list string matching

Alexander Shiyan (1):
  ASoC: fsl_ssi: Fix number of words per frame for I2S-slave mode

Arnd Bergmann (1):
  ASoC: hdmi-codec: select CONFIG_HDMI

Aviv Heller (1):
  bonding: fix enslavement slave link notifications

Bard Liao (2):
  ASoC: rt5670: fix HP Playback Volume control
  ASoC: rt5645: fix reg-2f default value.

Ben Skeggs (1):
  drm/nouveau/disp/sor/gf119: select correct sor when poking
training pattern

Bjørn Mork (1):
  cdc_ncm: workaround for EM7455 "silent" data interface

Bob Copeland (1):
  ALSA: hda - fix read before array start

Bob Liu (1):
  xen-blkfront: save uncompleted reqs in blkfront_resume()

Borislav Petkov (1):
  x86/amd_nb: Fix boot crash on non-AMD systems

Brian King (1):
  ipr: Clear interrupt on croc/crocodile when running with LSI

Bruno Prémont (1):
  qla2xxx: Fix NULL pointer deref in QLA interrupt

Charles Keepax (1):
  ASoC: wm5102: Correct supported channels on trace compressed DAI

Chris J Arges (1):
  ecryptfs: fix spelling mistakes

Christophe JAILLET (1):
  ALSA: echoaudio: Fix memory allocation

Christophe Jaillet (1):
  fsl/fman: fix error handling

Colin Pitrat (1):
  gpio: sch: Fix Oops on module load on Asus Eee PC 1201

Dan Carpenter (1):
  platform/chrome: cros_ec_dev - double fetch bug in ioctl

Daniel Borkmann (1):
  macsec: set actual real device for xmit when !protect_frames

Daniel Jurgens (5):
  net/mlx5: Fix incorrect page count when in internal error
  net/mlx5: Fix wait_vital for VFs and remove fixed sleep
  net/mlx5e: Timeout if SQ doesn't flush during close
  net/mlx5e: Implement ndo_tx_timeout callback
  net/mlx5e: Handle RQ flush in error cases

David Daney (1):
  MIPS: Fix page table corruption on THP permission changes.

David S. Miller (2):
  packet: Use symmetric hash for PACKET_FANOUT_HASH.
  Revert "fsl/fman: fix error handling"

Eric Dumazet (1):
  bonding: prevent out of bound accesses

Fabio Estevam (1):
  ASoC: ak4613: Remove owner assignment from platform_driver

Florian Fainelli (1):
  net: bcmsysport: Device stats are unsigned long

Ganapatrao Kulkarni (1):
  arm64: Enable workaround for Cavium erratum 27456 on thunderx-81xx

Ganesh Goudar (1):
  cxgb4: update latest firmware version supported

Geert Uytterhoeven (2):
  ASoC: wm8940: Enable cache usage to fix crashes on resume
  ASoC: ak4613: Enable cache usage to fix crashes on resume

Haishuang Yan (1):
  geneve: fix max_mtu setting

Huang Rui (2):
  drm/amd/powerplay: fix incorrect voltage table value for polaris10
  drm/amd/powerplay: fix incorrect voltage table value for tonga

Hugh Dickins (1):
  tmpfs: fix regression hang in fallocate undo

James Morse (1):
  arm64: kernel: Save and restore UAO and addr_limit on exception entry

Jan Beulich (4):
  xenbus: don't BUG() on user mode induced condition
  xenbus: don't bail early from xenbus_dev_request_and_reply()
  xenbus: simplify xenbus_dev_request_and_reply()
  xen/acpi: allow xen-acpi-processor driver to load on Xen 4.7

Janusz Krzysztofik (1):
  ASoC: cx20442: set tty->receiver_room in v253_open

Jarod Wilson (1):
  e1000e: keep Rx/Tx HW_VLAN_CTAG in sync

Jeff Mahoney (2):
  Revert "ecryptfs: forbid opening files without mmap handler"
  

RE: [PATCH v2 08/17] libnvdimm: introduce nvdimm_flush() and nvdimm_has_flush()

[Li, Philip]

> -Original Message-
> From: Williams, Dan J
> Sent: Sunday, July 10, 2016 1:01 PM
> To: lkp <l...@intel.com>
> Cc: kbuild-...@01.org; linux-nvd...@lists.01.org; linux-fsdevel  fsde...@vger.kernel.org>; Linux ACPI <linux-a...@vger.kernel.org>; Ross
> Zwisler <ross.zwis...@linux.intel.com>; Christoph Hellwig <h...@lst.de>; 
> linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v2 08/17] libnvdimm: introduce nvdimm_flush() and
> nvdimm_has_flush()
> 
> On Sat, Jul 9, 2016 at 9:47 PM, kbuild test robot <l...@intel.com> wrote:
> > Hi,
> >
> > [auto build test ERROR on linux-nvdimm/libnvdimm-for-next]
> > [also build test ERROR on next-20160708]
> > [cannot apply to v4.7-rc6]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help
> improve the system]
> >
> > url:https://github.com/0day-ci/linux/commits/Dan-Williams/replace-
> pcommit-with-ADR-or-directed-flushing/20160710-113558
> > base:   https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
> libnvdimm-for-next
> > config: i386-randconfig-r0-201628 (attached as .config)
> > compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
> > reproduce:
> > # save the attached .config to linux build tree
> > make ARCH=i386
> 
> Hi kbuild team,
> 
> Can we add an "i386 allmodconfig" build to the standard "BUILD
> SUCCESS" notification runs?  I had two positive build results on a

Thanks, yes, currently i386 allmodconfig has been covered for all kinds of test 
including
kbiuld on registered repo or LKML patches. If the test is running on a repo for 
its new commits,
a BUILD SUCCESS mail, it will list the current coverage by the time the mail is 
sent out like

m32r   m32104ut_defconfig
m32r mappi3.smp_defconfig
m32r opsput_defconfig
m32r   usrv_defconfig
xtensa   common_defconfig
xtensa  iss_defconfig
i386 allmodconfig
mips   jz4740
mips  allnoconfig

> private branch prior to posting this series, but the i386 runs did not
> build the nvdimm sub-system.
> 
> In any event this report is valid, so thank you for that!
> 
> 
> >
> > All errors (new ones prefixed by >>):
> >
> >drivers/nvdimm/region_devs.c: In function 'nvdimm_flush':
> >>> drivers/nvdimm/region_devs.c:887:4: error: implicit declaration of 
> >>> function
> 'writeq' [-Werror=implicit-function-declaration]
> >writeq(1, ndrd->flush_wpq[i][0]);
> >^~
> >cc1: some warnings being treated as errors
> >
> > vim +/writeq +887 drivers/nvdimm/region_devs.c
> >
> >881   * writes to avoid the cache via arch_memcpy_to_pmem().  The
> >882   * final wmb() ensures ordering for the NVDIMM flush write.
> >883   */
> >884  wmb();
> >885  for (i = 0; i < nd_region->ndr_mappings; i++)
> >886  if (ndrd->flush_wpq[i][0])
> >  > 887  writeq(1, ndrd->flush_wpq[i][0]);
> >888  wmb();
> >889  }
> >890  EXPORT_SYMBOL_GPL(nvdimm_flush);
> >
> > ---
> > 0-DAY kernel test infrastructureOpen Source Technology 
> > Center
> > https://lists.01.org/pipermail/kbuild-all   Intel 
> > Corporation

RE: [PATCH v2 08/17] libnvdimm: introduce nvdimm_flush() and nvdimm_has_flush()

[Li, Philip]

> -Original Message-
> From: Williams, Dan J
> Sent: Sunday, July 10, 2016 1:01 PM
> To: lkp 
> Cc: kbuild-...@01.org; linux-nvd...@lists.01.org; linux-fsdevel  fsde...@vger.kernel.org>; Linux ACPI ; Ross
> Zwisler ; Christoph Hellwig ; 
> linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v2 08/17] libnvdimm: introduce nvdimm_flush() and
> nvdimm_has_flush()
> 
> On Sat, Jul 9, 2016 at 9:47 PM, kbuild test robot  wrote:
> > Hi,
> >
> > [auto build test ERROR on linux-nvdimm/libnvdimm-for-next]
> > [also build test ERROR on next-20160708]
> > [cannot apply to v4.7-rc6]
> > [if your patch is applied to the wrong git tree, please drop us a note to 
> > help
> improve the system]
> >
> > url:https://github.com/0day-ci/linux/commits/Dan-Williams/replace-
> pcommit-with-ADR-or-directed-flushing/20160710-113558
> > base:   https://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
> libnvdimm-for-next
> > config: i386-randconfig-r0-201628 (attached as .config)
> > compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
> > reproduce:
> > # save the attached .config to linux build tree
> > make ARCH=i386
> 
> Hi kbuild team,
> 
> Can we add an "i386 allmodconfig" build to the standard "BUILD
> SUCCESS" notification runs?  I had two positive build results on a

Thanks, yes, currently i386 allmodconfig has been covered for all kinds of test 
including
kbiuld on registered repo or LKML patches. If the test is running on a repo for 
its new commits,
a BUILD SUCCESS mail, it will list the current coverage by the time the mail is 
sent out like

m32r   m32104ut_defconfig
m32r mappi3.smp_defconfig
m32r opsput_defconfig
m32r   usrv_defconfig
xtensa   common_defconfig
xtensa  iss_defconfig
i386 allmodconfig
mips   jz4740
mips  allnoconfig

> private branch prior to posting this series, but the i386 runs did not
> build the nvdimm sub-system.
> 
> In any event this report is valid, so thank you for that!
> 
> 
> >
> > All errors (new ones prefixed by >>):
> >
> >drivers/nvdimm/region_devs.c: In function 'nvdimm_flush':
> >>> drivers/nvdimm/region_devs.c:887:4: error: implicit declaration of 
> >>> function
> 'writeq' [-Werror=implicit-function-declaration]
> >writeq(1, ndrd->flush_wpq[i][0]);
> >^~
> >cc1: some warnings being treated as errors
> >
> > vim +/writeq +887 drivers/nvdimm/region_devs.c
> >
> >881   * writes to avoid the cache via arch_memcpy_to_pmem().  The
> >882   * final wmb() ensures ordering for the NVDIMM flush write.
> >883   */
> >884  wmb();
> >885  for (i = 0; i < nd_region->ndr_mappings; i++)
> >886  if (ndrd->flush_wpq[i][0])
> >  > 887  writeq(1, ndrd->flush_wpq[i][0]);
> >888  wmb();
> >889  }
> >890  EXPORT_SYMBOL_GPL(nvdimm_flush);
> >
> > ---
> > 0-DAY kernel test infrastructureOpen Source Technology 
> > Center
> > https://lists.01.org/pipermail/kbuild-all   Intel 
> > Corporation

Re: [PATCH 3/3] net: hisilicon: Add Fast Ethernet MAC driver

[Dongpo Li]

Hi Arnd,

On 2016/6/28 17:34, Arnd Bergmann wrote:
> On Tuesday, June 28, 2016 5:21:19 PM CEST Dongpo Li wrote:
>> On 2016/6/15 5:20, Arnd Bergmann wrote:
>>> On Tuesday, June 14, 2016 9:17:44 PM CEST Li Dongpo wrote:
 On 2016/6/13 17:06, Arnd Bergmann wrote:
> On Monday, June 13, 2016 2:07:56 PM CEST Dongpo Li wrote:
> You tx function uses BQL to optimize the queue length, and that
> is great. You also check xmit reclaim for rx interrupts, so
> as long as you have both rx and tx traffic, this should work
> great.
>
> However, I notice that you only have a 'tx fifo empty'
> interrupt triggering the napi poll, so I guess on a tx-only
> workload you will always end up pushing packets into the
> queue until BQL throttles tx, and then get the interrupt
> after all packets have been sent, which will cause BQL to
> make the queue longer up to the maximum queue size, and that
> negates the effect of BQL.
>
> Is there any way you can get a tx interrupt earlier than
> this in order to get a more balanced queue, or is it ok
> to just rely on rx packets to come in occasionally, and
> just use the tx fifo empty interrupt as a fallback?
>
 In tx direction, there are only two kinds of interrupts, 'tx fifo empty'
 and 'tx one packet finish'. I didn't use 'tx one packet finish' because
 it would lead to high hardware interrupts rate. This has been verified in
 our chips. It's ok to just use tx fifo empty interrupt.
>>>
>>> I'm not convinced by the explanation, I don't think that has anything
>>> to do with the hardware design, but instead is about the correctness
>>> of the BQL logic with your driver.
>>>
>>> Maybe your xmit function can do something like
>>>
>>>   if (dql_avail(netdev_get_tx_queue(dev, 0)->dql) < 0)
>>>   enable per-packet interrupt
>>>   else
>>>   use only fifo-empty interrupt
>>>
>>> That way, you don't get a lot of interrupts when the system is
>>> in a state of packets being received and sent continuously,
>>> but if you get to the point where your tx queue fills up
>>> and no rx interrupts arrive, you don't have to wait for it
>>> to become completely empty before adding new packets, and
>>> BQL won't keep growing the queue.
>>>
>> Hi, Arnd
>> I tried enable per-packet interrupt when tx queue full in xmit function
>> and disable it in NAPI poll. But the number of interrupts are a little
>> bigger than only using fifo-empty interrupt.
> 
> Right, I'd expect that to be the case, it basically means that the
> algorithm works as expected.
> 
> Just to be sure you didn't have extra interrupts: you only enable the
> per-packet interrupts if interrupts are currently enabled, not in
> NAPI polling mode, right?
> 
Sorry so long to reply to you. I use the per-packet interrupt like this:
In my xmit function,
if (hardware tx fifo is full) {
enable tx per-packet interrupt;
netif_stop_queue(dev);
return NETDEV_TX_BUSY;
}

In interrupt handle function,
if (interrupt is tx per-packet or tx fifo-empty or rx) {
disable tx per-packet interrupt;
napi_schedule(>napi);
}
We disable tx per-packet interrupt anyway because the NAPI poll will reclaim
the tx fifo.
When the NAPI poll completed, it will only enable the tx fifo-empty interrupt
and rx interrupt except the tx per-packet interrupt.

Is this solution okay?

>> The other hand, this is a fast ethernet MAC. Its maximum speed is 100Mbps.
>> This speed is very easily achived and the efficiency of the BQL is not
>> so important. What we focus on is the lower cpu utilization.
>> So I think it is okay to just use the tx fifo empty interrupt.
> 
> BQL is not about efficiency, it's about keeping the latency down, which
> is at least as important for low-throughput devices as it is for faster
> ones. I don't think that disabling BQL here would be the right answer,
> you'd just end up with the maximum TX queue length all the time.
> 
> Your queue length is 12 packets of 1500 bytes, meaning that you have 1.4ms
> of latency at 100mbit/s rate, or 14ms for 10mbit/s. This is much less
> than most, but it's probably still worth using BQL on it.
> 
I spent some time reading some articles and the goal of BQL is more clear to me.
BQL is designed to get the minimum buffer size that will not make hardware 
under starvation.
The goal is to reduce latency without the side effect of throughput.
Thanks for your explanation.

>   Arnd
> 
> .
> 

Regards,
Dongpo

.

Re: [PATCH 3/3] net: hisilicon: Add Fast Ethernet MAC driver

[Dongpo Li]

Hi Arnd,

On 2016/6/28 17:34, Arnd Bergmann wrote:
> On Tuesday, June 28, 2016 5:21:19 PM CEST Dongpo Li wrote:
>> On 2016/6/15 5:20, Arnd Bergmann wrote:
>>> On Tuesday, June 14, 2016 9:17:44 PM CEST Li Dongpo wrote:
 On 2016/6/13 17:06, Arnd Bergmann wrote:
> On Monday, June 13, 2016 2:07:56 PM CEST Dongpo Li wrote:
> You tx function uses BQL to optimize the queue length, and that
> is great. You also check xmit reclaim for rx interrupts, so
> as long as you have both rx and tx traffic, this should work
> great.
>
> However, I notice that you only have a 'tx fifo empty'
> interrupt triggering the napi poll, so I guess on a tx-only
> workload you will always end up pushing packets into the
> queue until BQL throttles tx, and then get the interrupt
> after all packets have been sent, which will cause BQL to
> make the queue longer up to the maximum queue size, and that
> negates the effect of BQL.
>
> Is there any way you can get a tx interrupt earlier than
> this in order to get a more balanced queue, or is it ok
> to just rely on rx packets to come in occasionally, and
> just use the tx fifo empty interrupt as a fallback?
>
 In tx direction, there are only two kinds of interrupts, 'tx fifo empty'
 and 'tx one packet finish'. I didn't use 'tx one packet finish' because
 it would lead to high hardware interrupts rate. This has been verified in
 our chips. It's ok to just use tx fifo empty interrupt.
>>>
>>> I'm not convinced by the explanation, I don't think that has anything
>>> to do with the hardware design, but instead is about the correctness
>>> of the BQL logic with your driver.
>>>
>>> Maybe your xmit function can do something like
>>>
>>>   if (dql_avail(netdev_get_tx_queue(dev, 0)->dql) < 0)
>>>   enable per-packet interrupt
>>>   else
>>>   use only fifo-empty interrupt
>>>
>>> That way, you don't get a lot of interrupts when the system is
>>> in a state of packets being received and sent continuously,
>>> but if you get to the point where your tx queue fills up
>>> and no rx interrupts arrive, you don't have to wait for it
>>> to become completely empty before adding new packets, and
>>> BQL won't keep growing the queue.
>>>
>> Hi, Arnd
>> I tried enable per-packet interrupt when tx queue full in xmit function
>> and disable it in NAPI poll. But the number of interrupts are a little
>> bigger than only using fifo-empty interrupt.
> 
> Right, I'd expect that to be the case, it basically means that the
> algorithm works as expected.
> 
> Just to be sure you didn't have extra interrupts: you only enable the
> per-packet interrupts if interrupts are currently enabled, not in
> NAPI polling mode, right?
> 
Sorry so long to reply to you. I use the per-packet interrupt like this:
In my xmit function,
if (hardware tx fifo is full) {
enable tx per-packet interrupt;
netif_stop_queue(dev);
return NETDEV_TX_BUSY;
}

In interrupt handle function,
if (interrupt is tx per-packet or tx fifo-empty or rx) {
disable tx per-packet interrupt;
napi_schedule(>napi);
}
We disable tx per-packet interrupt anyway because the NAPI poll will reclaim
the tx fifo.
When the NAPI poll completed, it will only enable the tx fifo-empty interrupt
and rx interrupt except the tx per-packet interrupt.

Is this solution okay?

>> The other hand, this is a fast ethernet MAC. Its maximum speed is 100Mbps.
>> This speed is very easily achived and the efficiency of the BQL is not
>> so important. What we focus on is the lower cpu utilization.
>> So I think it is okay to just use the tx fifo empty interrupt.
> 
> BQL is not about efficiency, it's about keeping the latency down, which
> is at least as important for low-throughput devices as it is for faster
> ones. I don't think that disabling BQL here would be the right answer,
> you'd just end up with the maximum TX queue length all the time.
> 
> Your queue length is 12 packets of 1500 bytes, meaning that you have 1.4ms
> of latency at 100mbit/s rate, or 14ms for 10mbit/s. This is much less
> than most, but it's probably still worth using BQL on it.
> 
I spent some time reading some articles and the goal of BQL is more clear to me.
BQL is designed to get the minimum buffer size that will not make hardware 
under starvation.
The goal is to reduce latency without the side effect of throughput.
Thanks for your explanation.

>   Arnd
> 
> .
> 

Regards,
Dongpo

.

Re: [PATCH v2 12/22] usb: chipidea: msm: Rely on core to override AHBBURST

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:03PM -0700, Stephen Boyd wrote:
> The core framework already handles setting this parameter with a
> platform quirk. Add the appropriate flag so that we always set
> AHBBURST to 0. Technically DT should be doing this, but we always
> do it for msm chipidea devices so setting the flag in the driver
> works just as well.

You may need to mention if the platform needs to set value rather
than 0, it needs to "ahb-burst-config" at dts, others are ok.

Acked-by: Peter Chen 

> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 89c1a02d69b5..719b20caf88e 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -24,7 +24,6 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
> unsigned event)
>   switch (event) {
>   case CI_HDRC_CONTROLLER_RESET_EVENT:
>   dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
> - writel(0, USB_AHBBURST);
>   /* use AHB transactor, allow posted data writes */
>   writel(0x8, USB_AHBMODE);
>   usb_phy_init(ci->usb_phy);
> @@ -47,7 +46,8 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
>   .name   = "ci_hdrc_msm",
>   .capoffset  = DEF_CAPOFFSET,
>   .flags  = CI_HDRC_REGS_SHARED |
> -   CI_HDRC_DISABLE_STREAMING,
> +   CI_HDRC_DISABLE_STREAMING |
> +   CI_HDRC_OVERRIDE_AHB_BURST,
>  
>   .notify_event   = ci_hdrc_msm_notify_event,
>  };
> -- 
> 2.9.0.rc2.8.ga28705d
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

Re: [PATCH v2 12/22] usb: chipidea: msm: Rely on core to override AHBBURST

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:03PM -0700, Stephen Boyd wrote:
> The core framework already handles setting this parameter with a
> platform quirk. Add the appropriate flag so that we always set
> AHBBURST to 0. Technically DT should be doing this, but we always
> do it for msm chipidea devices so setting the flag in the driver
> works just as well.

You may need to mention if the platform needs to set value rather
than 0, it needs to "ahb-burst-config" at dts, others are ok.

Acked-by: Peter Chen 

> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 89c1a02d69b5..719b20caf88e 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -24,7 +24,6 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
> unsigned event)
>   switch (event) {
>   case CI_HDRC_CONTROLLER_RESET_EVENT:
>   dev_dbg(dev, "CI_HDRC_CONTROLLER_RESET_EVENT received\n");
> - writel(0, USB_AHBBURST);
>   /* use AHB transactor, allow posted data writes */
>   writel(0x8, USB_AHBMODE);
>   usb_phy_init(ci->usb_phy);
> @@ -47,7 +46,8 @@ static struct ci_hdrc_platform_data ci_hdrc_msm_platdata = {
>   .name   = "ci_hdrc_msm",
>   .capoffset  = DEF_CAPOFFSET,
>   .flags  = CI_HDRC_REGS_SHARED |
> -   CI_HDRC_DISABLE_STREAMING,
> +   CI_HDRC_DISABLE_STREAMING |
> +   CI_HDRC_OVERRIDE_AHB_BURST,
>  
>   .notify_event   = ci_hdrc_msm_notify_event,
>  };
> -- 
> 2.9.0.rc2.8.ga28705d
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 

Best Regards,
Peter Chen

Re: [lkp] [ACPI / APEI] a3e2acc5e3: kmsg.BERT:Can't_request_iomem_region<#-#>

[Tony Luck]

I'm very surprised that there was a BERT table on an Atom machine. More details 
about the machine please. Also BIOS version.

Sent from my iPhone

> On Jul 10, 2016, at 18:43, kernel test robot  wrote:
> 
> 
> FYI, we noticed the following commit:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> commit a3e2acc5e37b22b6808a0b8e46887c3577de9c9e ("ACPI / APEI: Add Boot Error 
> Record Table (BERT) support")
> 
> in testcase: locktorture
> with following parameters: runtime=300s
> 
> on test machine: Atom with 8G memory
> 
> caused below changes:
> 
> 
> [   12.317148] BERT: Can't request iomem region 
> .
> 
> 
> 
> To reproduce:
> 
>git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>cd lkp-tests
>bin/lkp install job.yaml  # job file is attached in this email
>bin/lkp run job.yaml
> 
> 
> 
> Thanks,
> Xiaolong
> 
> 
> 

Re: [lkp] [ACPI / APEI] a3e2acc5e3: kmsg.BERT:Can't_request_iomem_region<#-#>

[Tony Luck]

I'm very surprised that there was a BERT table on an Atom machine. More details 
about the machine please. Also BIOS version.

Sent from my iPhone

> On Jul 10, 2016, at 18:43, kernel test robot  wrote:
> 
> 
> FYI, we noticed the following commit:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> commit a3e2acc5e37b22b6808a0b8e46887c3577de9c9e ("ACPI / APEI: Add Boot Error 
> Record Table (BERT) support")
> 
> in testcase: locktorture
> with following parameters: runtime=300s
> 
> on test machine: Atom with 8G memory
> 
> caused below changes:
> 
> 
> [   12.317148] BERT: Can't request iomem region 
> .
> 
> 
> 
> To reproduce:
> 
>git clone 
> git://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git
>cd lkp-tests
>bin/lkp install job.yaml  # job file is attached in this email
>bin/lkp run job.yaml
> 
> 
> 
> Thanks,
> Xiaolong
> 
> 
> 

Re: [PATCH v2 11/22] usb: chipidea: msm: Mark device as runtime pm active

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:02PM -0700, Stephen Boyd wrote:
> We're not properly marking the glue layer/wrapper device as
> runtime active, so runtime PM believes that the hardware state is
> inactive when we call pm_runtime_enable() in this driver. This
> causes a problem when the glue layer has a power domain
> associated with it, because runtime PM will go and disable the
> power domain to match the 'inactive' state of the device. Let's
> mark the device as active so that runtime PM doesn't improperly
> power down this device when it's actually active.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 3889809fd0c4..89c1a02d69b5 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -80,6 +80,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  
>   platform_set_drvdata(pdev, plat_ci);
>  
> + pm_runtime_set_active(>dev);
>   pm_runtime_no_callbacks(>dev);
>   pm_runtime_enable(>dev);
>  

Acked-by: Peter Chen 

-- 

Best Regards,
Peter Chen

Re: [PATCH v2 11/22] usb: chipidea: msm: Mark device as runtime pm active

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:02PM -0700, Stephen Boyd wrote:
> We're not properly marking the glue layer/wrapper device as
> runtime active, so runtime PM believes that the hardware state is
> inactive when we call pm_runtime_enable() in this driver. This
> causes a problem when the glue layer has a power domain
> associated with it, because runtime PM will go and disable the
> power domain to match the 'inactive' state of the device. Let's
> mark the device as active so that runtime PM doesn't improperly
> power down this device when it's actually active.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 3889809fd0c4..89c1a02d69b5 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -80,6 +80,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>  
>   platform_set_drvdata(pdev, plat_ci);
>  
> + pm_runtime_set_active(>dev);
>   pm_runtime_no_callbacks(>dev);
>   pm_runtime_enable(>dev);
>  

Acked-by: Peter Chen 

-- 

Best Regards,
Peter Chen

Re: [PATCH v4 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.

[Dave Young]

On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> kexec_locate_mem_hole will be used by the PowerPC kexec_file_load
> implementation to find free memory for the purgatory stack.
> 
> Signed-off-by: Thiago Jung Bauermann 
> Cc: Eric Biederman 
> Cc: Dave Young 
> ---
>  include/linux/kexec.h |  1 +
>  kernel/kexec_file.c   | 25 -
>  2 files changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index ff5fa7707bd7..803f563df81d 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -174,6 +174,7 @@ struct kexec_buf {
>  int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
>  int (*func)(u64, u64, void *));
>  extern int kexec_add_buffer(struct kexec_buf *kbuf);
> +int kexec_locate_mem_hole(struct kexec_buf *kbuf);
>  #endif /* CONFIG_KEXEC_FILE */
>  
>  struct kimage {
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 82ccfc4ee97e..3125d1689712 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -450,6 +450,23 @@ int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
>  }
>  
>  /**
> + * kexec_locate_mem_hole - find free memory for the purgatory or the next 
> kernel
> + * @kbuf:Parameters for the memory search.
> + *
> + * On success, kbuf->mem will have the start address of the memory region 
> found.
> + *
> + * Return: 0 on success, negative errno on error.
> + */
> +int kexec_locate_mem_hole(struct kexec_buf *kbuf)
> +{
> + int ret;
> +
> + ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
> +
> + return ret == 1 ? 0 : -EADDRNOTAVAIL;
> +}
> +
> +/**
>   * kexec_add_buffer - place a buffer in a kexec segment
>   * @kbuf:Buffer contents and memory parameters.
>   *
> @@ -489,11 +506,9 @@ int kexec_add_buffer(struct kexec_buf *kbuf)
>   kbuf->buf_align = max(kbuf->buf_align, PAGE_SIZE);
>  
>   /* Walk the RAM ranges and allocate a suitable range for the buffer */
> - ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
> - if (ret != 1) {
> - /* A suitable memory range could not be found for buffer */
> - return -EADDRNOTAVAIL;
> - }
> + ret = kexec_locate_mem_hole(kbuf);
> + if (ret)
> + return ret;
>  
>   /* Found a suitable memory range */
>   ksegment = >image->segment[kbuf->image->nr_segments];
> -- 
> 1.9.1
> 

Acked-by: Dave Young 

Thanks
Dave

Re: [PATCH v4 3/9] kexec_file: Factor out kexec_locate_mem_hole from kexec_add_buffer.

[Dave Young]

On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> kexec_locate_mem_hole will be used by the PowerPC kexec_file_load
> implementation to find free memory for the purgatory stack.
> 
> Signed-off-by: Thiago Jung Bauermann 
> Cc: Eric Biederman 
> Cc: Dave Young 
> ---
>  include/linux/kexec.h |  1 +
>  kernel/kexec_file.c   | 25 -
>  2 files changed, 21 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index ff5fa7707bd7..803f563df81d 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -174,6 +174,7 @@ struct kexec_buf {
>  int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
>  int (*func)(u64, u64, void *));
>  extern int kexec_add_buffer(struct kexec_buf *kbuf);
> +int kexec_locate_mem_hole(struct kexec_buf *kbuf);
>  #endif /* CONFIG_KEXEC_FILE */
>  
>  struct kimage {
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 82ccfc4ee97e..3125d1689712 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -450,6 +450,23 @@ int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
>  }
>  
>  /**
> + * kexec_locate_mem_hole - find free memory for the purgatory or the next 
> kernel
> + * @kbuf:Parameters for the memory search.
> + *
> + * On success, kbuf->mem will have the start address of the memory region 
> found.
> + *
> + * Return: 0 on success, negative errno on error.
> + */
> +int kexec_locate_mem_hole(struct kexec_buf *kbuf)
> +{
> + int ret;
> +
> + ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
> +
> + return ret == 1 ? 0 : -EADDRNOTAVAIL;
> +}
> +
> +/**
>   * kexec_add_buffer - place a buffer in a kexec segment
>   * @kbuf:Buffer contents and memory parameters.
>   *
> @@ -489,11 +506,9 @@ int kexec_add_buffer(struct kexec_buf *kbuf)
>   kbuf->buf_align = max(kbuf->buf_align, PAGE_SIZE);
>  
>   /* Walk the RAM ranges and allocate a suitable range for the buffer */
> - ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
> - if (ret != 1) {
> - /* A suitable memory range could not be found for buffer */
> - return -EADDRNOTAVAIL;
> - }
> + ret = kexec_locate_mem_hole(kbuf);
> + if (ret)
> + return ret;
>  
>   /* Found a suitable memory range */
>   ksegment = >image->segment[kbuf->image->nr_segments];
> -- 
> 1.9.1
> 

Acked-by: Dave Young 

Thanks
Dave

Re: [PATCH v14 3/8] perf tests: Add testcase for auxiliary evlist

[Wangnan (F)]

On 2016/7/8 22:48, Jiri Olsa wrote:

On Thu, Jul 07, 2016 at 05:34:44AM +, Wang Nan wrote:

SNIP


ret = TEST_FAIL;
-   err = do_test(evlist, opts.mmap_pages, _count,
+   err = do_test(evlist, aux_evlist, opts.mmap_pages,
+ _sample_count, _sample_count,
  _count);
if (err != TEST_OK)
goto out_delete_evlist;
  
-	if ((sample_count != NR_ITERS) || (comm_count != NR_ITERS)) {

-   pr_err("Unexpected counter: sample_count=%d, comm_count=%d\n",
-  sample_count, comm_count);
+   if (enter_sample_count != exit_sample_count) {
+   pr_err("Unexpected counter: enter_sample_count=%d, 
exit_sample_count=%d\n",
+  enter_sample_count, exit_sample_count);
+   goto out_delete_evlist;
+   }
+
+   if ((exit_sample_count != NR_ITERS) || (comm_count != NR_ITERS)) {
+   pr_err("Unexpected counter: exit_sample_count=%d, 
comm_count=%d\n",
+  exit_sample_count, comm_count);
goto out_delete_evlist;
}
  
-	err = do_test(evlist, 1, _count, _count);

+   err = do_test(evlist, aux_evlist, 1, , , );

why dont you test numbers for 1 page mmap?  seems like the data would fit..
is the purpose just to check if we can map just 1 page?


Data won't fit. 1 page map make sure the buffer is overwritten.

Thank you.


thanks,
jirka

Re: [PATCH v4 2/9] kexec_file: Change kexec_add_buffer to take kexec_buf as argument.

[Dave Young]

On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> Adapt all callers to the new function prototype.
> 
> In addition, change the type of kexec_buf.buffer from char * to void *.
> There is no particular reason for it to be a char *, and the change
> allows us to get rid of 3 existing casts to char * in the code.
> 
> Signed-off-by: Thiago Jung Bauermann 
> Cc: Eric Biederman 
> Cc: Dave Young 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: x...@kernel.org
> ---
>  arch/x86/kernel/crash.c   | 37 
>  arch/x86/kernel/kexec-bzimage64.c | 48 +++--
>  include/linux/kexec.h |  8 +---
>  kernel/kexec_file.c   | 88 
> ++-
>  4 files changed, 87 insertions(+), 94 deletions(-)
> 
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 9ef978d69c22..dc026ea361dc 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -615,9 +615,9 @@ static int determine_backup_region(u64 start, u64 end, 
> void *arg)
>  
>  int crash_load_segments(struct kimage *image)
>  {
> - unsigned long src_start, src_sz, elf_sz;
> - void *elf_addr;
>   int ret;
> + struct kexec_buf kbuf = { .image = image, .buf_min = 0,
> +   .buf_max = ULONG_MAX, .top_down = false };
>  
>   /*
>* Determine and load a segment for backup area. First 640K RAM
> @@ -631,43 +631,44 @@ int crash_load_segments(struct kimage *image)
>   if (ret < 0)
>   return ret;
>  
> - src_start = image->arch.backup_src_start;
> - src_sz = image->arch.backup_src_sz;
> -
>   /* Add backup segment. */
> - if (src_sz) {
> + if (image->arch.backup_src_sz) {
> + kbuf.buffer = _zero_bytes;
> + kbuf.bufsz = sizeof(crash_zero_bytes);
> + kbuf.memsz = image->arch.backup_src_sz;
> + kbuf.buf_align = PAGE_SIZE;
>   /*
>* Ideally there is no source for backup segment. This is
>* copied in purgatory after crash. Just add a zero filled
>* segment for now to make sure checksum logic works fine.
>*/
> - ret = kexec_add_buffer(image, (char *)_zero_bytes,
> -sizeof(crash_zero_bytes), src_sz,
> -PAGE_SIZE, 0, -1, 0,
> ->arch.backup_load_addr);
> + ret = kexec_add_buffer();
>   if (ret)
>   return ret;
> + image->arch.backup_load_addr = kbuf.mem;
>   pr_debug("Loaded backup region at 0x%lx backup_start=0x%lx 
> memsz=0x%lx\n",
> -  image->arch.backup_load_addr, src_start, src_sz);
> +  image->arch.backup_load_addr,
> +  image->arch.backup_src_start, kbuf.memsz);
>   }
>  
>   /* Prepare elf headers and add a segment */
> - ret = prepare_elf_headers(image, _addr, _sz);
> + ret = prepare_elf_headers(image, , );
>   if (ret)
>   return ret;
>  
> - image->arch.elf_headers = elf_addr;
> - image->arch.elf_headers_sz = elf_sz;
> + image->arch.elf_headers = kbuf.buffer;
> + image->arch.elf_headers_sz = kbuf.bufsz;
>  
> - ret = kexec_add_buffer(image, (char *)elf_addr, elf_sz, elf_sz,
> - ELF_CORE_HEADER_ALIGN, 0, -1, 0,
> - >arch.elf_load_addr);
> + kbuf.memsz = kbuf.bufsz;
> + kbuf.buf_align = ELF_CORE_HEADER_ALIGN;
> + ret = kexec_add_buffer();
>   if (ret) {
>   vfree((void *)image->arch.elf_headers);
>   return ret;
>   }
> + image->arch.elf_load_addr = kbuf.mem;
>   pr_debug("Loaded ELF headers at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> -  image->arch.elf_load_addr, elf_sz, elf_sz);
> +  image->arch.elf_load_addr, kbuf.bufsz, kbuf.bufsz);
>  
>   return ret;
>  }
> diff --git a/arch/x86/kernel/kexec-bzimage64.c 
> b/arch/x86/kernel/kexec-bzimage64.c
> index f2356bda2b05..4b3a75329fb6 100644
> --- a/arch/x86/kernel/kexec-bzimage64.c
> +++ b/arch/x86/kernel/kexec-bzimage64.c
> @@ -331,17 +331,17 @@ static void *bzImage64_load(struct kimage *image, char 
> *kernel,
>  
>   struct setup_header *header;
>   int setup_sects, kern16_size, ret = 0;
> - unsigned long setup_header_size, params_cmdline_sz, params_misc_sz;
> + unsigned long setup_header_size, params_cmdline_sz;
>   struct boot_params *params;
>   unsigned long bootparam_load_addr, kernel_load_addr, initrd_load_addr;
>   unsigned long purgatory_load_addr;
> - unsigned long kernel_bufsz, kernel_memsz, kernel_align;
> - char *kernel_buf;
>   struct bzimage64_data *ldata;
>   struct kexec_entry64_regs 

Re: [PATCH v14 3/8] perf tests: Add testcase for auxiliary evlist

[Wangnan (F)]

On 2016/7/8 22:48, Jiri Olsa wrote:

On Thu, Jul 07, 2016 at 05:34:44AM +, Wang Nan wrote:

SNIP


ret = TEST_FAIL;
-   err = do_test(evlist, opts.mmap_pages, _count,
+   err = do_test(evlist, aux_evlist, opts.mmap_pages,
+ _sample_count, _sample_count,
  _count);
if (err != TEST_OK)
goto out_delete_evlist;
  
-	if ((sample_count != NR_ITERS) || (comm_count != NR_ITERS)) {

-   pr_err("Unexpected counter: sample_count=%d, comm_count=%d\n",
-  sample_count, comm_count);
+   if (enter_sample_count != exit_sample_count) {
+   pr_err("Unexpected counter: enter_sample_count=%d, 
exit_sample_count=%d\n",
+  enter_sample_count, exit_sample_count);
+   goto out_delete_evlist;
+   }
+
+   if ((exit_sample_count != NR_ITERS) || (comm_count != NR_ITERS)) {
+   pr_err("Unexpected counter: exit_sample_count=%d, 
comm_count=%d\n",
+  exit_sample_count, comm_count);
goto out_delete_evlist;
}
  
-	err = do_test(evlist, 1, _count, _count);

+   err = do_test(evlist, aux_evlist, 1, , , );

why dont you test numbers for 1 page mmap?  seems like the data would fit..
is the purpose just to check if we can map just 1 page?


Data won't fit. 1 page map make sure the buffer is overwritten.

Thank you.


thanks,
jirka

Re: [PATCH v4 2/9] kexec_file: Change kexec_add_buffer to take kexec_buf as argument.

[Dave Young]

On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> Adapt all callers to the new function prototype.
> 
> In addition, change the type of kexec_buf.buffer from char * to void *.
> There is no particular reason for it to be a char *, and the change
> allows us to get rid of 3 existing casts to char * in the code.
> 
> Signed-off-by: Thiago Jung Bauermann 
> Cc: Eric Biederman 
> Cc: Dave Young 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: x...@kernel.org
> ---
>  arch/x86/kernel/crash.c   | 37 
>  arch/x86/kernel/kexec-bzimage64.c | 48 +++--
>  include/linux/kexec.h |  8 +---
>  kernel/kexec_file.c   | 88 
> ++-
>  4 files changed, 87 insertions(+), 94 deletions(-)
> 
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 9ef978d69c22..dc026ea361dc 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -615,9 +615,9 @@ static int determine_backup_region(u64 start, u64 end, 
> void *arg)
>  
>  int crash_load_segments(struct kimage *image)
>  {
> - unsigned long src_start, src_sz, elf_sz;
> - void *elf_addr;
>   int ret;
> + struct kexec_buf kbuf = { .image = image, .buf_min = 0,
> +   .buf_max = ULONG_MAX, .top_down = false };
>  
>   /*
>* Determine and load a segment for backup area. First 640K RAM
> @@ -631,43 +631,44 @@ int crash_load_segments(struct kimage *image)
>   if (ret < 0)
>   return ret;
>  
> - src_start = image->arch.backup_src_start;
> - src_sz = image->arch.backup_src_sz;
> -
>   /* Add backup segment. */
> - if (src_sz) {
> + if (image->arch.backup_src_sz) {
> + kbuf.buffer = _zero_bytes;
> + kbuf.bufsz = sizeof(crash_zero_bytes);
> + kbuf.memsz = image->arch.backup_src_sz;
> + kbuf.buf_align = PAGE_SIZE;
>   /*
>* Ideally there is no source for backup segment. This is
>* copied in purgatory after crash. Just add a zero filled
>* segment for now to make sure checksum logic works fine.
>*/
> - ret = kexec_add_buffer(image, (char *)_zero_bytes,
> -sizeof(crash_zero_bytes), src_sz,
> -PAGE_SIZE, 0, -1, 0,
> ->arch.backup_load_addr);
> + ret = kexec_add_buffer();
>   if (ret)
>   return ret;
> + image->arch.backup_load_addr = kbuf.mem;
>   pr_debug("Loaded backup region at 0x%lx backup_start=0x%lx 
> memsz=0x%lx\n",
> -  image->arch.backup_load_addr, src_start, src_sz);
> +  image->arch.backup_load_addr,
> +  image->arch.backup_src_start, kbuf.memsz);
>   }
>  
>   /* Prepare elf headers and add a segment */
> - ret = prepare_elf_headers(image, _addr, _sz);
> + ret = prepare_elf_headers(image, , );
>   if (ret)
>   return ret;
>  
> - image->arch.elf_headers = elf_addr;
> - image->arch.elf_headers_sz = elf_sz;
> + image->arch.elf_headers = kbuf.buffer;
> + image->arch.elf_headers_sz = kbuf.bufsz;
>  
> - ret = kexec_add_buffer(image, (char *)elf_addr, elf_sz, elf_sz,
> - ELF_CORE_HEADER_ALIGN, 0, -1, 0,
> - >arch.elf_load_addr);
> + kbuf.memsz = kbuf.bufsz;
> + kbuf.buf_align = ELF_CORE_HEADER_ALIGN;
> + ret = kexec_add_buffer();
>   if (ret) {
>   vfree((void *)image->arch.elf_headers);
>   return ret;
>   }
> + image->arch.elf_load_addr = kbuf.mem;
>   pr_debug("Loaded ELF headers at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> -  image->arch.elf_load_addr, elf_sz, elf_sz);
> +  image->arch.elf_load_addr, kbuf.bufsz, kbuf.bufsz);
>  
>   return ret;
>  }
> diff --git a/arch/x86/kernel/kexec-bzimage64.c 
> b/arch/x86/kernel/kexec-bzimage64.c
> index f2356bda2b05..4b3a75329fb6 100644
> --- a/arch/x86/kernel/kexec-bzimage64.c
> +++ b/arch/x86/kernel/kexec-bzimage64.c
> @@ -331,17 +331,17 @@ static void *bzImage64_load(struct kimage *image, char 
> *kernel,
>  
>   struct setup_header *header;
>   int setup_sects, kern16_size, ret = 0;
> - unsigned long setup_header_size, params_cmdline_sz, params_misc_sz;
> + unsigned long setup_header_size, params_cmdline_sz;
>   struct boot_params *params;
>   unsigned long bootparam_load_addr, kernel_load_addr, initrd_load_addr;
>   unsigned long purgatory_load_addr;
> - unsigned long kernel_bufsz, kernel_memsz, kernel_align;
> - char *kernel_buf;
>   struct bzimage64_data *ldata;
>   struct kexec_entry64_regs regs64;
>   void *stack;
>   unsigned int setup_hdr_offset = offsetof(struct boot_params, hdr);
>   unsigned int 

Re: [PATCH v4 1/9] kexec_file: Allow arch-specific memory walking for kexec_add_buffer

[Dave Young]

On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> Allow architectures to specify a different memory walking function for
> kexec_add_buffer. x86 uses iomem to track reserved memory ranges, but
> PowerPC uses the memblock subsystem.
> 
> Signed-off-by: Thiago Jung Bauermann 
> Cc: Eric Biederman 
> Cc: Dave Young 
> ---
>  include/linux/kexec.h   | 29 -
>  kernel/kexec_file.c | 30 ++
>  kernel/kexec_internal.h | 16 
>  3 files changed, 50 insertions(+), 25 deletions(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index e8acb2b43dd9..2549a99a748c 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -146,7 +146,34 @@ struct kexec_file_ops {
>   kexec_verify_sig_t *verify_sig;
>  #endif
>  };
> -#endif
> +
> +/**
> + * struct kexec_buf - parameters for finding a place for a buffer in memory
> + * @image:   kexec image in which memory to search.
> + * @buffer:  Contents which will be copied to the allocated memory.
> + * @bufsz:   Size of @buffer.
> + * @mem: On return will have address of the buffer in memory.
> + * @memsz:   Size for the buffer in memory.
> + * @buf_align:   Minimum alignment needed.
> + * @buf_min: The buffer can't be placed below this address.
> + * @buf_max: The buffer can't be placed above this address.
> + * @top_down:Allocate from top of memory.
> + */
> +struct kexec_buf {
> + struct kimage *image;
> + char *buffer;
> + unsigned long bufsz;
> + unsigned long mem;
> + unsigned long memsz;
> + unsigned long buf_align;
> + unsigned long buf_min;
> + unsigned long buf_max;
> + bool top_down;
> +};
> +
> +int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
> +int (*func)(u64, u64, void *));
> +#endif /* CONFIG_KEXEC_FILE */
>  
>  struct kimage {
>   kimage_entry_t head;
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 01ab82a40d22..9c0c565a08db 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -428,6 +428,27 @@ static int locate_mem_hole_callback(u64 start, u64 end, 
> void *arg)
>   return locate_mem_hole_bottom_up(start, end, kbuf);
>  }
>  
> +/**
> + * arch_kexec_walk_mem - call func(data) on free memory regions
> + * @kbuf:Context info for the search. Also passed to @func.
> + * @func:Function to call for each memory region.
> + *
> + * Return: The memory walk will stop when func returns a non-zero value
> + * and that value will be returned. If all free regions are visited without
> + * func returning non-zero, then zero will be returned.
> + */
> +int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
> +int (*func)(u64, u64, void *))
> +{
> + if (kbuf->image->type == KEXEC_TYPE_CRASH)
> + return walk_iomem_res_desc(crashk_res.desc,
> +IORESOURCE_SYSTEM_RAM | 
> IORESOURCE_BUSY,
> +crashk_res.start, crashk_res.end,
> +kbuf, func);
> + else
> + return walk_system_ram_res(0, ULONG_MAX, kbuf, func);
> +}
> +
>  /*
>   * Helper function for placing a buffer in a kexec segment. This assumes
>   * that kexec_mutex is held.
> @@ -474,14 +495,7 @@ int kexec_add_buffer(struct kimage *image, char *buffer, 
> unsigned long bufsz,
>   kbuf->top_down = top_down;
>  
>   /* Walk the RAM ranges and allocate a suitable range for the buffer */
> - if (image->type == KEXEC_TYPE_CRASH)
> - ret = walk_iomem_res_desc(crashk_res.desc,
> - IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
> - crashk_res.start, crashk_res.end, kbuf,
> - locate_mem_hole_callback);
> - else
> - ret = walk_system_ram_res(0, -1, kbuf,
> -   locate_mem_hole_callback);
> + ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
>   if (ret != 1) {
>   /* A suitable memory range could not be found for buffer */
>   return -EADDRNOTAVAIL;
> diff --git a/kernel/kexec_internal.h b/kernel/kexec_internal.h
> index 0a52315d9c62..4cef7e4706b0 100644
> --- a/kernel/kexec_internal.h
> +++ b/kernel/kexec_internal.h
> @@ -20,22 +20,6 @@ struct kexec_sha_region {
>   unsigned long len;
>  };
>  
> -/*
> - * Keeps track of buffer parameters as provided by caller for requesting
> - * memory placement of buffer.
> - */
> -struct kexec_buf {
> - struct kimage *image;
> - char *buffer;
> - unsigned long bufsz;
> - unsigned long mem;
> - unsigned long memsz;
> - unsigned long buf_align;
> - unsigned long buf_min;
> - unsigned long buf_max;
> - bool top_down;  /* allocate from top of memory hole */
> -};
> -
>  void 

linux-next: build failure after merge of the drm-msm tree

[Stephen Rothwell]

Hi Rob,

After merging the drm-msm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/gpu/drm/msm/hdmi/hdmi.c:523:15: error: initialization from incompatible 
pointer type [-Werror=incompatible-pointer-types]
  .hw_params = msm_hdmi_audio_hw_params,
   ^
drivers/gpu/drm/msm/hdmi/hdmi.c:523:15: note: (near initialization for 
'msm_hdmi_audio_codec_ops.hw_params')
drivers/gpu/drm/msm/hdmi/hdmi.c:524:20: error: initialization from incompatible 
pointer type [-Werror=incompatible-pointer-types]
  .audio_shutdown = msm_hdmi_audio_shutdown,
^
drivers/gpu/drm/msm/hdmi/hdmi.c:524:20: note: (near initialization for 
'msm_hdmi_audio_codec_ops.audio_shutdown')

Caused by commit

  bf714255fed7 ("drm: msm: Add ASoC generic hdmi audio codec support.")

interacting with commit

  efc9194bcff8 ("ASoC: hdmi-codec: callback function will be called with 
private data")

from the sound-asoc (and drm) trees.

I have added this merge fix patch for today (dave will need something
like this when he merges your tree):

From: Stephen Rothwell 
Date: Mon, 11 Jul 2016 13:16:23 +1000
Subject: [PATCH] drm: msm: fix up for "ASoC: hdmi-codec: callback function
 will be called with private data"

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/msm/hdmi/hdmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index aada35547eca..33bf52c6b312 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -438,7 +438,7 @@ static int msm_hdmi_get_gpio(struct device_node *of_node, 
const char *name)
 /*
  * HDMI audio codec callbacks
  */
-static int msm_hdmi_audio_hw_params(struct device *dev,
+static int msm_hdmi_audio_hw_params(struct device *dev, void *data,
struct hdmi_codec_daifmt *daifmt,
struct hdmi_codec_params *params)
 {
@@ -512,7 +512,7 @@ static int msm_hdmi_audio_hw_params(struct device *dev,
return 0;
 }
 
-static void msm_hdmi_audio_shutdown(struct device *dev)
+static void msm_hdmi_audio_shutdown(struct device *dev, void *data)
 {
struct hdmi *hdmi = dev_get_drvdata(dev);
 
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v4 1/9] kexec_file: Allow arch-specific memory walking for kexec_add_buffer

[Dave Young]

On 07/07/16 at 01:23pm, Thiago Jung Bauermann wrote:
> Allow architectures to specify a different memory walking function for
> kexec_add_buffer. x86 uses iomem to track reserved memory ranges, but
> PowerPC uses the memblock subsystem.
> 
> Signed-off-by: Thiago Jung Bauermann 
> Cc: Eric Biederman 
> Cc: Dave Young 
> ---
>  include/linux/kexec.h   | 29 -
>  kernel/kexec_file.c | 30 ++
>  kernel/kexec_internal.h | 16 
>  3 files changed, 50 insertions(+), 25 deletions(-)
> 
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index e8acb2b43dd9..2549a99a748c 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -146,7 +146,34 @@ struct kexec_file_ops {
>   kexec_verify_sig_t *verify_sig;
>  #endif
>  };
> -#endif
> +
> +/**
> + * struct kexec_buf - parameters for finding a place for a buffer in memory
> + * @image:   kexec image in which memory to search.
> + * @buffer:  Contents which will be copied to the allocated memory.
> + * @bufsz:   Size of @buffer.
> + * @mem: On return will have address of the buffer in memory.
> + * @memsz:   Size for the buffer in memory.
> + * @buf_align:   Minimum alignment needed.
> + * @buf_min: The buffer can't be placed below this address.
> + * @buf_max: The buffer can't be placed above this address.
> + * @top_down:Allocate from top of memory.
> + */
> +struct kexec_buf {
> + struct kimage *image;
> + char *buffer;
> + unsigned long bufsz;
> + unsigned long mem;
> + unsigned long memsz;
> + unsigned long buf_align;
> + unsigned long buf_min;
> + unsigned long buf_max;
> + bool top_down;
> +};
> +
> +int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
> +int (*func)(u64, u64, void *));
> +#endif /* CONFIG_KEXEC_FILE */
>  
>  struct kimage {
>   kimage_entry_t head;
> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
> index 01ab82a40d22..9c0c565a08db 100644
> --- a/kernel/kexec_file.c
> +++ b/kernel/kexec_file.c
> @@ -428,6 +428,27 @@ static int locate_mem_hole_callback(u64 start, u64 end, 
> void *arg)
>   return locate_mem_hole_bottom_up(start, end, kbuf);
>  }
>  
> +/**
> + * arch_kexec_walk_mem - call func(data) on free memory regions
> + * @kbuf:Context info for the search. Also passed to @func.
> + * @func:Function to call for each memory region.
> + *
> + * Return: The memory walk will stop when func returns a non-zero value
> + * and that value will be returned. If all free regions are visited without
> + * func returning non-zero, then zero will be returned.
> + */
> +int __weak arch_kexec_walk_mem(struct kexec_buf *kbuf,
> +int (*func)(u64, u64, void *))
> +{
> + if (kbuf->image->type == KEXEC_TYPE_CRASH)
> + return walk_iomem_res_desc(crashk_res.desc,
> +IORESOURCE_SYSTEM_RAM | 
> IORESOURCE_BUSY,
> +crashk_res.start, crashk_res.end,
> +kbuf, func);
> + else
> + return walk_system_ram_res(0, ULONG_MAX, kbuf, func);
> +}
> +
>  /*
>   * Helper function for placing a buffer in a kexec segment. This assumes
>   * that kexec_mutex is held.
> @@ -474,14 +495,7 @@ int kexec_add_buffer(struct kimage *image, char *buffer, 
> unsigned long bufsz,
>   kbuf->top_down = top_down;
>  
>   /* Walk the RAM ranges and allocate a suitable range for the buffer */
> - if (image->type == KEXEC_TYPE_CRASH)
> - ret = walk_iomem_res_desc(crashk_res.desc,
> - IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY,
> - crashk_res.start, crashk_res.end, kbuf,
> - locate_mem_hole_callback);
> - else
> - ret = walk_system_ram_res(0, -1, kbuf,
> -   locate_mem_hole_callback);
> + ret = arch_kexec_walk_mem(kbuf, locate_mem_hole_callback);
>   if (ret != 1) {
>   /* A suitable memory range could not be found for buffer */
>   return -EADDRNOTAVAIL;
> diff --git a/kernel/kexec_internal.h b/kernel/kexec_internal.h
> index 0a52315d9c62..4cef7e4706b0 100644
> --- a/kernel/kexec_internal.h
> +++ b/kernel/kexec_internal.h
> @@ -20,22 +20,6 @@ struct kexec_sha_region {
>   unsigned long len;
>  };
>  
> -/*
> - * Keeps track of buffer parameters as provided by caller for requesting
> - * memory placement of buffer.
> - */
> -struct kexec_buf {
> - struct kimage *image;
> - char *buffer;
> - unsigned long bufsz;
> - unsigned long mem;
> - unsigned long memsz;
> - unsigned long buf_align;
> - unsigned long buf_min;
> - unsigned long buf_max;
> - bool top_down;  /* allocate from top of memory hole */
> -};
> -
>  void kimage_file_post_load_cleanup(struct kimage *image);
>  #else /* 

linux-next: build failure after merge of the drm-msm tree

[Stephen Rothwell]

Hi Rob,

After merging the drm-msm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/gpu/drm/msm/hdmi/hdmi.c:523:15: error: initialization from incompatible 
pointer type [-Werror=incompatible-pointer-types]
  .hw_params = msm_hdmi_audio_hw_params,
   ^
drivers/gpu/drm/msm/hdmi/hdmi.c:523:15: note: (near initialization for 
'msm_hdmi_audio_codec_ops.hw_params')
drivers/gpu/drm/msm/hdmi/hdmi.c:524:20: error: initialization from incompatible 
pointer type [-Werror=incompatible-pointer-types]
  .audio_shutdown = msm_hdmi_audio_shutdown,
^
drivers/gpu/drm/msm/hdmi/hdmi.c:524:20: note: (near initialization for 
'msm_hdmi_audio_codec_ops.audio_shutdown')

Caused by commit

  bf714255fed7 ("drm: msm: Add ASoC generic hdmi audio codec support.")

interacting with commit

  efc9194bcff8 ("ASoC: hdmi-codec: callback function will be called with 
private data")

from the sound-asoc (and drm) trees.

I have added this merge fix patch for today (dave will need something
like this when he merges your tree):

From: Stephen Rothwell 
Date: Mon, 11 Jul 2016 13:16:23 +1000
Subject: [PATCH] drm: msm: fix up for "ASoC: hdmi-codec: callback function
 will be called with private data"

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/msm/hdmi/hdmi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdmi.c
index aada35547eca..33bf52c6b312 100644
--- a/drivers/gpu/drm/msm/hdmi/hdmi.c
+++ b/drivers/gpu/drm/msm/hdmi/hdmi.c
@@ -438,7 +438,7 @@ static int msm_hdmi_get_gpio(struct device_node *of_node, 
const char *name)
 /*
  * HDMI audio codec callbacks
  */
-static int msm_hdmi_audio_hw_params(struct device *dev,
+static int msm_hdmi_audio_hw_params(struct device *dev, void *data,
struct hdmi_codec_daifmt *daifmt,
struct hdmi_codec_params *params)
 {
@@ -512,7 +512,7 @@ static int msm_hdmi_audio_hw_params(struct device *dev,
return 0;
 }
 
-static void msm_hdmi_audio_shutdown(struct device *dev)
+static void msm_hdmi_audio_shutdown(struct device *dev, void *data)
 {
struct hdmi *hdmi = dev_get_drvdata(dev);
 
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

[Zheng, Lv]

Hi,

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> Hi,
> 
> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
> > There are many AML tables reporting wrong initial lid state, and some of
> > them never reports lid state. As a proxy layer acting between, ACPI
> button
> > driver is not able to handle all such cases, but need to re-define the
> > usage model of the ACPI lid. That is:
> > 1. It's initial state is not reliable;
> > 2. There may not be open event;
> > 3. Userspace should only take action against the close event which is
> >reliable, always sent after a real lid close.
> > This patch adds documentation of the usage model.
> >
> > Link: https://lkml.org/2016/3/7/460
> > Link: https://github.com/systemd/systemd/issues/2087
> > Signed-off-by: Lv Zheng 
> > Cc: Bastien Nocera: 
> > Cc: Benjamin Tissoires 
> > Cc: linux-in...@vger.kernel.org
> > ---
> >  Documentation/acpi/acpi-lid.txt |   62
> +++
> >  1 file changed, 62 insertions(+)
> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> >
> > diff --git a/Documentation/acpi/acpi-lid.txt b/Documentation/acpi/acpi-
> lid.txt
> > new file mode 100644
> > index 000..7e4f7ed
> > --- /dev/null
> > +++ b/Documentation/acpi/acpi-lid.txt
> > @@ -0,0 +1,62 @@
> > +Usage Model of the ACPI Control Method Lid Device
> > +
> > +Copyright (C) 2016, Intel Corporation
> > +Author: Lv Zheng 
> > +
> > +
> > +Abstract:
> > +
> > +Platforms containing lids convey lid state (open/close) to OSPMs using
> a
> > +control method lid device. To implement this, the AML tables issue
> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
> > +changed. The _LID control method for the lid device must be
> implemented to
> > +report the "current" state of the lid as either "opened" or "closed".
> > +
> > +This document describes the restrictions and the expections of the
> Linux
> > +ACPI lid device driver.
> > +
> > +
> > +1. Restrictions of the returning value of the _LID control method
> > +
> > +The _LID control method is described to return the "current" lid state.
> > +However the word of "current" has ambiguity, many AML tables return
> the lid
> > +state upon the last lid notification instead of returning the lid state
> > +upon the last _LID evaluation. There won't be difference when the _LID
> > +control method is evaluated during the runtime, the problem is its
> initial
> > +returning value. When the AML tables implement this control method
> with
> > +cached value, the initial returning value is likely not reliable. There are
> > +simply so many examples always retuning "closed" as initial lid state.
> > +
> > +2. Restrictions of the lid state change notifications
> > +
> > +There are many AML tables never notifying when the lid device state is
> > +changed to "opened". But it is ensured that the AML tables always
> notify
> > +"closed" when the lid state is changed to "closed". This is normally used
> > +to trigger some system power saving operations on Windows. Since it is
> > +fully tested, this notification is reliable for all AML tables.
> > +
> > +3. Expections for the userspace users of the ACPI lid device driver
> > +
> > +The userspace programs should stop relying on
> > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is only
> > +used for the validation purpose.
> 
> I'd say: this file actually calls the _LID method described above. And
> given the previous explanation, it is not reliable enough on some
> platforms. So it is strongly advised for user-space program to not
> solely rely on this file to determine the actual lid state.
[Lv Zheng] 
OK.

> 
> > +
> > +New userspace programs should rely on the lid "closed" notification to
> > +trigger some power saving operations and may stop taking actions
> according
> > +to the lid "opened" notification. A new input switch event -
> SW_ACPI_LID is
> > +prepared for the new userspace to implement this ACPI control method
> lid
> > +device specific logics.
> 
> That's not entirely what we discussed before (to prevent regressions):
> - if the device doesn't have reliable LID switch state, then there
> would be the new input event, and so userspace should only rely on
> opened notifications.
> - if the device has reliable switch information, the new input event
> should not be exported and userspace knows that the current input
> switch event is reliable.
> 
> Also, using a new "switch" event is a terrible idea. Switches have a
> state (open/close) and you are using this to forward a single open
> event. So using a switch just allows you to say to userspace you are
> using the "new" LID meaning, but you'll still have to manually reset
> the switch and you will have to document how this 

RE: [PATCH v2 4/4] ACPI / button: Add document for ACPI control method lid device restrictions

[Zheng, Lv]

Hi,

> From: Benjamin Tissoires [mailto:benjamin.tissoi...@gmail.com]
> Subject: Re: [PATCH v2 4/4] ACPI / button: Add document for ACPI control
> method lid device restrictions
> 
> Hi,
> 
> On Thu, Jul 7, 2016 at 9:11 AM, Lv Zheng  wrote:
> > There are many AML tables reporting wrong initial lid state, and some of
> > them never reports lid state. As a proxy layer acting between, ACPI
> button
> > driver is not able to handle all such cases, but need to re-define the
> > usage model of the ACPI lid. That is:
> > 1. It's initial state is not reliable;
> > 2. There may not be open event;
> > 3. Userspace should only take action against the close event which is
> >reliable, always sent after a real lid close.
> > This patch adds documentation of the usage model.
> >
> > Link: https://lkml.org/2016/3/7/460
> > Link: https://github.com/systemd/systemd/issues/2087
> > Signed-off-by: Lv Zheng 
> > Cc: Bastien Nocera: 
> > Cc: Benjamin Tissoires 
> > Cc: linux-in...@vger.kernel.org
> > ---
> >  Documentation/acpi/acpi-lid.txt |   62
> +++
> >  1 file changed, 62 insertions(+)
> >  create mode 100644 Documentation/acpi/acpi-lid.txt
> >
> > diff --git a/Documentation/acpi/acpi-lid.txt b/Documentation/acpi/acpi-
> lid.txt
> > new file mode 100644
> > index 000..7e4f7ed
> > --- /dev/null
> > +++ b/Documentation/acpi/acpi-lid.txt
> > @@ -0,0 +1,62 @@
> > +Usage Model of the ACPI Control Method Lid Device
> > +
> > +Copyright (C) 2016, Intel Corporation
> > +Author: Lv Zheng 
> > +
> > +
> > +Abstract:
> > +
> > +Platforms containing lids convey lid state (open/close) to OSPMs using
> a
> > +control method lid device. To implement this, the AML tables issue
> > +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
> > +changed. The _LID control method for the lid device must be
> implemented to
> > +report the "current" state of the lid as either "opened" or "closed".
> > +
> > +This document describes the restrictions and the expections of the
> Linux
> > +ACPI lid device driver.
> > +
> > +
> > +1. Restrictions of the returning value of the _LID control method
> > +
> > +The _LID control method is described to return the "current" lid state.
> > +However the word of "current" has ambiguity, many AML tables return
> the lid
> > +state upon the last lid notification instead of returning the lid state
> > +upon the last _LID evaluation. There won't be difference when the _LID
> > +control method is evaluated during the runtime, the problem is its
> initial
> > +returning value. When the AML tables implement this control method
> with
> > +cached value, the initial returning value is likely not reliable. There are
> > +simply so many examples always retuning "closed" as initial lid state.
> > +
> > +2. Restrictions of the lid state change notifications
> > +
> > +There are many AML tables never notifying when the lid device state is
> > +changed to "opened". But it is ensured that the AML tables always
> notify
> > +"closed" when the lid state is changed to "closed". This is normally used
> > +to trigger some system power saving operations on Windows. Since it is
> > +fully tested, this notification is reliable for all AML tables.
> > +
> > +3. Expections for the userspace users of the ACPI lid device driver
> > +
> > +The userspace programs should stop relying on
> > +/proc/acpi/button/lid/LID0/state to obtain the lid state. This file is only
> > +used for the validation purpose.
> 
> I'd say: this file actually calls the _LID method described above. And
> given the previous explanation, it is not reliable enough on some
> platforms. So it is strongly advised for user-space program to not
> solely rely on this file to determine the actual lid state.
[Lv Zheng] 
OK.

> 
> > +
> > +New userspace programs should rely on the lid "closed" notification to
> > +trigger some power saving operations and may stop taking actions
> according
> > +to the lid "opened" notification. A new input switch event -
> SW_ACPI_LID is
> > +prepared for the new userspace to implement this ACPI control method
> lid
> > +device specific logics.
> 
> That's not entirely what we discussed before (to prevent regressions):
> - if the device doesn't have reliable LID switch state, then there
> would be the new input event, and so userspace should only rely on
> opened notifications.
> - if the device has reliable switch information, the new input event
> should not be exported and userspace knows that the current input
> switch event is reliable.
> 
> Also, using a new "switch" event is a terrible idea. Switches have a
> state (open/close) and you are using this to forward a single open
> event. So using a switch just allows you to say to userspace you are
> using the "new" LID meaning, but you'll still have to manually reset
> the switch and you will have to document how this event is not a
> switch.
> 
> Please use a simple KEY_LID_OPEN event you will send through
> 

Re: [PATCH v2 10/22] usb: chipidea: Add support for ULPI PHY bus

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:01PM -0700, Stephen Boyd wrote:
> Some phys for the chipidea controller are controlled via the ULPI
> viewport. Add support for the ULPI bus so that these sorts of
> phys can be probed and read/written automatically without having
> to duplicate the viewport logic in each phy driver.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Cc: Heikki Krogerus 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/Kconfig  |   7 +++
>  drivers/usb/chipidea/Makefile |   1 +
>  drivers/usb/chipidea/ci.h |  22 
>  drivers/usb/chipidea/core.c   |  31 +---
>  drivers/usb/chipidea/ulpi.c   | 113 
> ++
>  5 files changed, 168 insertions(+), 6 deletions(-)
>  create mode 100644 drivers/usb/chipidea/ulpi.c
> 
> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
> index 3644a3500b70..4f8c342a8865 100644
> --- a/drivers/usb/chipidea/Kconfig
> +++ b/drivers/usb/chipidea/Kconfig
> @@ -37,4 +37,11 @@ config USB_CHIPIDEA_HOST
> Say Y here to enable host controller functionality of the
> ChipIdea driver.
>  
> +config USB_CHIPIDEA_ULPI
> + bool "ChipIdea ULPI PHY support"
> + depends on USB_ULPI_BUS=y || USB_ULPI_BUS=USB_CHIPIDEA
> + help
> +   Say Y here if you have a ULPI PHY attached to your ChipIdea
> +   controller.
> +
>  endif
> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
> index 518e445476c3..39fca5715ed3 100644
> --- a/drivers/usb/chipidea/Makefile
> +++ b/drivers/usb/chipidea/Makefile
> @@ -4,6 +4,7 @@ ci_hdrc-y := core.o otg.o debug.o
>  ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC)   += udc.o
>  ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST)  += host.o
>  ci_hdrc-$(CONFIG_USB_OTG_FSM)+= otg_fsm.o
> +ci_hdrc-$(CONFIG_USB_CHIPIDEA_ULPI)  += ulpi.o
>  
>  # Glue/Bridge layers go here
>  
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index 05bc4d631cb9..637dd7675e71 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -18,6 +18,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  
> /**
>   * DEFINE
> @@ -52,6 +54,7 @@ enum ci_hw_regs {
>   OP_ENDPTLISTADDR,
>   OP_TTCTRL,
>   OP_BURSTSIZE,
> + OP_ULPI_VIEWPORT,
>   OP_PORTSC,
>   OP_DEVLC,
>   OP_OTGSC,
> @@ -187,6 +190,8 @@ struct hw_bank {
>   * @test_mode: the selected test mode
>   * @platdata: platform specific information supplied by parent device
>   * @vbus_active: is VBUS active
> + * @ulpi: pointer to ULPI device, if any
> + * @ulpi_ops: ULPI read/write ops for this device
>   * @phy: pointer to PHY, if any
>   * @usb_phy: pointer to USB PHY, if any and if using the USB PHY framework
>   * @hcd: pointer to usb_hcd for ehci host driver
> @@ -236,6 +241,10 @@ struct ci_hdrc {
>  
>   struct ci_hdrc_platform_data*platdata;
>   int vbus_active;
> +#ifdef CONFIG_USB_CHIPIDEA_ULPI
> + struct ulpi *ulpi;
> + struct ulpi_ops ulpi_ops;
> +#endif
>   struct phy  *phy;
>   /* old usb_phy interface */
>   struct usb_phy  *usb_phy;
> @@ -418,6 +427,17 @@ static inline bool ci_otg_is_fsm_mode(struct ci_hdrc *ci)
>  #endif
>  }
>  
> +#if IS_ENABLED(CONFIG_USB_CHIPIDEA_ULPI)
> +int ci_ulpi_init(struct ci_hdrc *ci);
> +void ci_ulpi_exit(struct ci_hdrc *ci);
> +int ci_ulpi_resume(struct ci_hdrc *ci);
> +#else
> +static inline int ci_ulpi_init(struct ci_hdrc *ci) { return 0; }
> +static inline void ci_ulpi_exit(struct ci_hdrc *ci) { }
> +static inline int ci_ulpi_resume(struct ci_hdrc *ci) { return 0; }
> +#endif
> +
> +

One more blank line

>  u32 hw_read_intr_enable(struct ci_hdrc *ci);
>  
>  u32 hw_read_intr_status(struct ci_hdrc *ci);
> @@ -428,6 +448,8 @@ int hw_port_test_set(struct ci_hdrc *ci, u8 mode);
>  
>  u8 hw_port_test_get(struct ci_hdrc *ci);
>  
> +void hw_phymode_configure(struct ci_hdrc *ci);
> +
>  void ci_platform_configure(struct ci_hdrc *ci);
>  
>  int dbg_create_files(struct ci_hdrc *ci);
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 532085a096d9..f144e1bbcc82 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -86,6 +86,7 @@ static const u8 ci_regs_nolpm[] = {
>   [OP_ENDPTLISTADDR]  = 0x18U,
>   [OP_TTCTRL] = 0x1CU,
>   [OP_BURSTSIZE]  = 0x20U,
> + [OP_ULPI_VIEWPORT]  = 0x30U,
>   [OP_PORTSC] = 0x44U,
>   [OP_DEVLC]  = 0x84U,
>   [OP_OTGSC]  = 0x64U,
> @@ -110,6 +111,7 @@ static const u8 ci_regs_lpm[] = {
>   [OP_ENDPTLISTADDR]  = 0x18U,
>   [OP_TTCTRL] = 

Re: [PATCH v2 10/22] usb: chipidea: Add support for ULPI PHY bus

[Peter Chen]

On Thu, Jul 07, 2016 at 03:21:01PM -0700, Stephen Boyd wrote:
> Some phys for the chipidea controller are controlled via the ULPI
> viewport. Add support for the ULPI bus so that these sorts of
> phys can be probed and read/written automatically without having
> to duplicate the viewport logic in each phy driver.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Cc: Heikki Krogerus 
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/Kconfig  |   7 +++
>  drivers/usb/chipidea/Makefile |   1 +
>  drivers/usb/chipidea/ci.h |  22 
>  drivers/usb/chipidea/core.c   |  31 +---
>  drivers/usb/chipidea/ulpi.c   | 113 
> ++
>  5 files changed, 168 insertions(+), 6 deletions(-)
>  create mode 100644 drivers/usb/chipidea/ulpi.c
> 
> diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
> index 3644a3500b70..4f8c342a8865 100644
> --- a/drivers/usb/chipidea/Kconfig
> +++ b/drivers/usb/chipidea/Kconfig
> @@ -37,4 +37,11 @@ config USB_CHIPIDEA_HOST
> Say Y here to enable host controller functionality of the
> ChipIdea driver.
>  
> +config USB_CHIPIDEA_ULPI
> + bool "ChipIdea ULPI PHY support"
> + depends on USB_ULPI_BUS=y || USB_ULPI_BUS=USB_CHIPIDEA
> + help
> +   Say Y here if you have a ULPI PHY attached to your ChipIdea
> +   controller.
> +
>  endif
> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
> index 518e445476c3..39fca5715ed3 100644
> --- a/drivers/usb/chipidea/Makefile
> +++ b/drivers/usb/chipidea/Makefile
> @@ -4,6 +4,7 @@ ci_hdrc-y := core.o otg.o debug.o
>  ci_hdrc-$(CONFIG_USB_CHIPIDEA_UDC)   += udc.o
>  ci_hdrc-$(CONFIG_USB_CHIPIDEA_HOST)  += host.o
>  ci_hdrc-$(CONFIG_USB_OTG_FSM)+= otg_fsm.o
> +ci_hdrc-$(CONFIG_USB_CHIPIDEA_ULPI)  += ulpi.o
>  
>  # Glue/Bridge layers go here
>  
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index 05bc4d631cb9..637dd7675e71 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -18,6 +18,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  
> /**
>   * DEFINE
> @@ -52,6 +54,7 @@ enum ci_hw_regs {
>   OP_ENDPTLISTADDR,
>   OP_TTCTRL,
>   OP_BURSTSIZE,
> + OP_ULPI_VIEWPORT,
>   OP_PORTSC,
>   OP_DEVLC,
>   OP_OTGSC,
> @@ -187,6 +190,8 @@ struct hw_bank {
>   * @test_mode: the selected test mode
>   * @platdata: platform specific information supplied by parent device
>   * @vbus_active: is VBUS active
> + * @ulpi: pointer to ULPI device, if any
> + * @ulpi_ops: ULPI read/write ops for this device
>   * @phy: pointer to PHY, if any
>   * @usb_phy: pointer to USB PHY, if any and if using the USB PHY framework
>   * @hcd: pointer to usb_hcd for ehci host driver
> @@ -236,6 +241,10 @@ struct ci_hdrc {
>  
>   struct ci_hdrc_platform_data*platdata;
>   int vbus_active;
> +#ifdef CONFIG_USB_CHIPIDEA_ULPI
> + struct ulpi *ulpi;
> + struct ulpi_ops ulpi_ops;
> +#endif
>   struct phy  *phy;
>   /* old usb_phy interface */
>   struct usb_phy  *usb_phy;
> @@ -418,6 +427,17 @@ static inline bool ci_otg_is_fsm_mode(struct ci_hdrc *ci)
>  #endif
>  }
>  
> +#if IS_ENABLED(CONFIG_USB_CHIPIDEA_ULPI)
> +int ci_ulpi_init(struct ci_hdrc *ci);
> +void ci_ulpi_exit(struct ci_hdrc *ci);
> +int ci_ulpi_resume(struct ci_hdrc *ci);
> +#else
> +static inline int ci_ulpi_init(struct ci_hdrc *ci) { return 0; }
> +static inline void ci_ulpi_exit(struct ci_hdrc *ci) { }
> +static inline int ci_ulpi_resume(struct ci_hdrc *ci) { return 0; }
> +#endif
> +
> +

One more blank line

>  u32 hw_read_intr_enable(struct ci_hdrc *ci);
>  
>  u32 hw_read_intr_status(struct ci_hdrc *ci);
> @@ -428,6 +448,8 @@ int hw_port_test_set(struct ci_hdrc *ci, u8 mode);
>  
>  u8 hw_port_test_get(struct ci_hdrc *ci);
>  
> +void hw_phymode_configure(struct ci_hdrc *ci);
> +
>  void ci_platform_configure(struct ci_hdrc *ci);
>  
>  int dbg_create_files(struct ci_hdrc *ci);
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 532085a096d9..f144e1bbcc82 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -86,6 +86,7 @@ static const u8 ci_regs_nolpm[] = {
>   [OP_ENDPTLISTADDR]  = 0x18U,
>   [OP_TTCTRL] = 0x1CU,
>   [OP_BURSTSIZE]  = 0x20U,
> + [OP_ULPI_VIEWPORT]  = 0x30U,
>   [OP_PORTSC] = 0x44U,
>   [OP_DEVLC]  = 0x84U,
>   [OP_OTGSC]  = 0x64U,
> @@ -110,6 +111,7 @@ static const u8 ci_regs_lpm[] = {
>   [OP_ENDPTLISTADDR]  = 0x18U,
>   [OP_TTCTRL] = 0x1CU,
>   [OP_BURSTSIZE]  = 0x20U,
> + [OP_ULPI_VIEWPORT]  = 0x30U,
>   [OP_PORTSC] 

Re: [lkp] [ext4] 5405511e1a: ltp.acl_test01.fail]

[Theodore Ts'o]

On Mon, Jul 11, 2016 at 09:59:54AM +0800, kernel test robot wrote:
> 
> FYI, we noticed the following commit:
> 
> https://github.com/0day-ci/linux 
> Vegard-Nossum/ext4-validate-number-of-clusters-in-group/20160708-041426
> commit 5405511e1a984ab644fa9e29a0d3d958b835ab75 ("ext4: validate number of 
> meta clusters in group")

Hi, many thanks for the report.  One question -- is there some way the
reporting could be speeded up?  Vegard's patch was sent late on the
7th, and it looks like it hit the 0day-ci git repo a few hours later
on the 8th, and was run early in the morning Chinese time.  Was the
delay until the 11th due to the weekend and the desire to have a human
sanity check the result?  Is that because there was a concern that
there would be too many false positives?

Also, if there was some way the 0day robot report could include a
In-Reply-To: header to the patch being sent to the mailing list (in
this case: <577eb740.10...@oracle.com>), it would make this even
*more* useful.


Vegard, I'm guessing you didn't have a chance to test your patch
before you sent it to the list?

bit_max = ext4_num_clusters_in_group(sb, i);
if ((bit_max >> 3) >= sb->s_blocksize) {
ext4_msg(sb, KERN_WARNING, "clusters in "
  "group %u exceeds block size", i);
goto failed_mount;
}


This is the test which is failing, but it will fail by default on
pretty much all ext4 file systems, since by default there will be
32768 blocks (clusters) per group, with a 4k block size (and 32768 >>
3 == 4096).  And in the test that failed, this was a 1k block size
with 8192 blocks per blocks (and 8192 >> 3 == 1024).

Anyway, as I mentioned before, I'd much rather do very specific sanity
checking on superblock fields, instead of sanity checking calculated
values such as ext4_num_clusters_in_group().

Perhaps the easist thing to do is to run e2fsck -n on those file
systems that are causing problems?

Cheers,

- Ted

Re: [lkp] [ext4] 5405511e1a: ltp.acl_test01.fail]

[Theodore Ts'o]

On Mon, Jul 11, 2016 at 09:59:54AM +0800, kernel test robot wrote:
> 
> FYI, we noticed the following commit:
> 
> https://github.com/0day-ci/linux 
> Vegard-Nossum/ext4-validate-number-of-clusters-in-group/20160708-041426
> commit 5405511e1a984ab644fa9e29a0d3d958b835ab75 ("ext4: validate number of 
> meta clusters in group")

Hi, many thanks for the report.  One question -- is there some way the
reporting could be speeded up?  Vegard's patch was sent late on the
7th, and it looks like it hit the 0day-ci git repo a few hours later
on the 8th, and was run early in the morning Chinese time.  Was the
delay until the 11th due to the weekend and the desire to have a human
sanity check the result?  Is that because there was a concern that
there would be too many false positives?

Also, if there was some way the 0day robot report could include a
In-Reply-To: header to the patch being sent to the mailing list (in
this case: <577eb740.10...@oracle.com>), it would make this even
*more* useful.


Vegard, I'm guessing you didn't have a chance to test your patch
before you sent it to the list?

bit_max = ext4_num_clusters_in_group(sb, i);
if ((bit_max >> 3) >= sb->s_blocksize) {
ext4_msg(sb, KERN_WARNING, "clusters in "
  "group %u exceeds block size", i);
goto failed_mount;
}


This is the test which is failing, but it will fail by default on
pretty much all ext4 file systems, since by default there will be
32768 blocks (clusters) per group, with a 4k block size (and 32768 >>
3 == 4096).  And in the test that failed, this was a 1k block size
with 8192 blocks per blocks (and 8192 >> 3 == 1024).

Anyway, as I mentioned before, I'd much rather do very specific sanity
checking on superblock fields, instead of sanity checking calculated
values such as ext4_num_clusters_in_group().

Perhaps the easist thing to do is to run e2fsck -n on those file
systems that are causing problems?

Cheers,

- Ted

[PATCH v3 1/2] dt-bindings: auxadc: Add binding document for Mediatek auxadc.

[Zhiyong Tao]

The commit adds the device tree binding documentation for the mediatek
auxadc found on Mediatek MT2701.
Thermal gets auxadc sample data by iio device.
So the commit changes auxadc device tree binding documentation from
/soc/mediatek/auxadc.txt to /iio/adc/mt65xx_auxadc.txt.

Signed-off-by: Zhiyong Tao 
---
 .../devicetree/bindings/iio/adc/mt65xx_auxadc.txt  |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/adc/mt65xx_auxadc.txt 
b/Documentation/devicetree/bindings/iio/adc/mt65xx_auxadc.txt
index 47fcd1b..bc23792 100644
--- a/Documentation/devicetree/bindings/iio/adc/mt65xx_auxadc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/mt65xx_auxadc.txt
@@ -14,11 +14,11 @@ Required properties:
   - reg: Address range of the AUXADC unit.
   - clocks: Should contain a clock specifier for each entry in clock-names
   - clock-names: Should contain "main".
-  - io-channel-cells: Should be 1, see ../iio-bindings.txt
+  - #io-channel-cells: Should be 1, see ../iio-bindings.txt
 
 Example:
 
-auxadc: auxadc@11001000 {
+auxadc: adc@11001000 {
compatible = "mediatek,mt2701-auxadc";
reg = <0 0x11001000 0 0x1000>;
clocks = < CLK_PERI_AUXADC>;
-- 
1.7.9.5

Re: [RFC] arm64: kexec_file_load support

[Dave Young]

On 07/08/16 at 11:48am, Thiago Jung Bauermann wrote:
> Am Donnerstag, 07 Juli 2016, 14:12:45 schrieb Dave Young:
> > If so maybe change a bit from your precious mentioned 7 args proposal like
> > below?
> > 
> > struct kexec_file_fd {
> > enum kexec_file_type;
> > int fd;
> > }
> > 
> > struct kexec_fdset {
> > int nr_fd;
> > struct kexec_file_fd fd[0];
> > }
> > 
> > int kexec_file_load(int kernel_fd, int initrd_fd,
> > unsigned long cmdline_len, const char *cmdline_ptr,
> > unsigned long flags, struct kexec_fdset *extra_fds);
> 
> 
> Is there a way for the kernel to distinguish whether the process passed 5 or 
> 6 arguments? How can it know whether extra_fds is a valid argument or just 
> garbage? I think we have to define a new flag KEXEC_FILE_EXTRA_FDS so that 
> the process can signal that it is using the new interface.

Agreed, a new flag is needed.

Thanks
Dave

[PATCH v3 1/2] dt-bindings: auxadc: Add binding document for Mediatek auxadc.

[Zhiyong Tao]

The commit adds the device tree binding documentation for the mediatek
auxadc found on Mediatek MT2701.
Thermal gets auxadc sample data by iio device.
So the commit changes auxadc device tree binding documentation from
/soc/mediatek/auxadc.txt to /iio/adc/mt65xx_auxadc.txt.

Signed-off-by: Zhiyong Tao 
---
 .../devicetree/bindings/iio/adc/mt65xx_auxadc.txt  |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/adc/mt65xx_auxadc.txt 
b/Documentation/devicetree/bindings/iio/adc/mt65xx_auxadc.txt
index 47fcd1b..bc23792 100644
--- a/Documentation/devicetree/bindings/iio/adc/mt65xx_auxadc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/mt65xx_auxadc.txt
@@ -14,11 +14,11 @@ Required properties:
   - reg: Address range of the AUXADC unit.
   - clocks: Should contain a clock specifier for each entry in clock-names
   - clock-names: Should contain "main".
-  - io-channel-cells: Should be 1, see ../iio-bindings.txt
+  - #io-channel-cells: Should be 1, see ../iio-bindings.txt
 
 Example:
 
-auxadc: auxadc@11001000 {
+auxadc: adc@11001000 {
compatible = "mediatek,mt2701-auxadc";
reg = <0 0x11001000 0 0x1000>;
clocks = < CLK_PERI_AUXADC>;
-- 
1.7.9.5

Re: [RFC] arm64: kexec_file_load support

[Dave Young]

On 07/08/16 at 11:48am, Thiago Jung Bauermann wrote:
> Am Donnerstag, 07 Juli 2016, 14:12:45 schrieb Dave Young:
> > If so maybe change a bit from your precious mentioned 7 args proposal like
> > below?
> > 
> > struct kexec_file_fd {
> > enum kexec_file_type;
> > int fd;
> > }
> > 
> > struct kexec_fdset {
> > int nr_fd;
> > struct kexec_file_fd fd[0];
> > }
> > 
> > int kexec_file_load(int kernel_fd, int initrd_fd,
> > unsigned long cmdline_len, const char *cmdline_ptr,
> > unsigned long flags, struct kexec_fdset *extra_fds);
> 
> 
> Is there a way for the kernel to distinguish whether the process passed 5 or 
> 6 arguments? How can it know whether extra_fds is a valid argument or just 
> garbage? I think we have to define a new flag KEXEC_FILE_EXTRA_FDS so that 
> the process can signal that it is using the new interface.

Agreed, a new flag is needed.

Thanks
Dave

[PATCH v3 2/2] iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.

[Zhiyong Tao]

Add Mediatek auxadc driver based on iio.
It will register a device in iio and support iio.
So thermal can read auxadc channel to sample data by iio device.
It is tested successfully on mt2701 platform.
Mt8173 and mt6577 platforms are not tested.
But the expectation is compatible.

Signed-off-by: Zhiyong Tao 
---
 drivers/iio/adc/Kconfig |   26 +++---
 drivers/iio/adc/Makefile|2 +-
 drivers/iio/adc/mt6577_auxadc.c |  186 +++
 3 files changed, 104 insertions(+), 110 deletions(-)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 66e9b44..14929fc 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -305,6 +305,19 @@ config MCP3422
  This driver can also be built as a module. If so, the module will be
  called mcp3422.
 
+config MEDIATEK_MT6577_AUXADC
+tristate "MediaTek AUXADC driver"
+depends on ARCH_MEDIATEK || COMPILE_TEST
+depends on HAS_IOMEM
+help
+  Say yes here to enable support for MediaTek mt65xx AUXADC.
+
+  The driver supports immediate mode operation to read from one of 
sixteen
+  channels (external or internal).
+
+  This driver can also be built as a module. If so, the module will be
+  called mt6577_auxadc.
+
 config MEN_Z188_ADC
tristate "MEN 16z188 ADC IP Core support"
depends on MCB
@@ -315,19 +328,6 @@ config MEN_Z188_ADC
  This driver can also be built as a module. If so, the module will be
  called men_z188_adc.
 
-config MEDIATEK_MT65XX_AUXADC
-   tristate "MediaTek AUXADC driver"
-   depends on ARCH_MEDIATEK || COMPILE_TEST
-   depends on HAS_IOMEM
-   help
- Say yes here to enable support for MediaTek mt65xx AUXADC.
-
- The driver supports immediate mode operation to read from one of 
sixteen
- channels (external or internal).
-
- This driver can also be built as a module. If so, the module will be
- called mt6577_auxadc.
-
 config MXS_LRADC
 tristate "Freescale i.MX23/i.MX28 LRADC"
 depends on (ARCH_MXS || COMPILE_TEST) && HAS_IOMEM
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 14a630f..8306347 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -30,8 +30,8 @@ obj-$(CONFIG_MAX1027) += max1027.o
 obj-$(CONFIG_MAX1363) += max1363.o
 obj-$(CONFIG_MCP320X) += mcp320x.o
 obj-$(CONFIG_MCP3422) += mcp3422.o
+obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
 obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
-obj-$(CONFIG_MEDIATEK_MT65XX_AUXADC) += mt6577_auxadc.o
 obj-$(CONFIG_MXS_LRADC) += mxs-lradc.o
 obj-$(CONFIG_NAU7802) += nau7802.o
 obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
diff --git a/drivers/iio/adc/mt6577_auxadc.c b/drivers/iio/adc/mt6577_auxadc.c
index a56531a..a853ae8 100644
--- a/drivers/iio/adc/mt6577_auxadc.c
+++ b/drivers/iio/adc/mt6577_auxadc.c
@@ -24,80 +24,78 @@
 #include 
 #include 
 
-/* Registers definitions */
-#define MT65XX_AUXADC_CON00x00
-#define MT65XX_AUXADC_CON10x04
-#define MT65XX_AUXADC_CON20x10
-#define MT65XX_AUXADC_STA BIT(0)
+/* Register definitions */
+#define MT6577_AUXADC_CON00x00
+#define MT6577_AUXADC_CON10x04
+#define MT6577_AUXADC_CON20x10
+#define MT6577_AUXADC_STA BIT(0)
 
-#define MT65XX_AUXADC_DAT00x14
-#define MT65XX_AUXADC_RDY0BIT(12)
+#define MT6577_AUXADC_DAT00x14
+#define MT6577_AUXADC_RDY0BIT(12)
 
-#define MT65XX_AUXADC_MISC0x94
-#define MT65XX_AUXADC_PDN_EN  BIT(14)
+#define MT6577_AUXADC_MISC0x94
+#define MT6577_AUXADC_PDN_EN  BIT(14)
 
-#define MT65XX_AUXADC_DAT_MASK0xfff
-#define MT65XX_AUXADC_SLEEP_US1000
-#define MT65XX_AUXADC_TIMEOUT_US  1
-#define MT65XX_AUXADC_POWER_READY_MS  1
-#define MT65XX_AUXADC_SAMPLE_READY_US 25
+#define MT6577_AUXADC_DAT_MASK0xfff
+#define MT6577_AUXADC_SLEEP_US1000
+#define MT6577_AUXADC_TIMEOUT_US  1
+#define MT6577_AUXADC_POWER_READY_MS  1
+#define MT6577_AUXADC_SAMPLE_READY_US 25
 
-struct mt65xx_auxadc_device {
+struct mt6577_auxadc_device {
void __iomem *reg_base;
struct clk *adc_clk;
struct mutex lock;
-   unsigned int power_ready_ms;
-   unsigned int sample_ready_us;
 };
 
-#define MT65XX_AUXADC_CHANNEL(idx) {   \
+#define MT6577_AUXADC_CHANNEL(idx) {   \
.type = IIO_VOLTAGE,\
.indexed = 1,   \
.channel = 

[PATCH v3 2/2] iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.

[Zhiyong Tao]

Add Mediatek auxadc driver based on iio.
It will register a device in iio and support iio.
So thermal can read auxadc channel to sample data by iio device.
It is tested successfully on mt2701 platform.
Mt8173 and mt6577 platforms are not tested.
But the expectation is compatible.

Signed-off-by: Zhiyong Tao 
---
 drivers/iio/adc/Kconfig |   26 +++---
 drivers/iio/adc/Makefile|2 +-
 drivers/iio/adc/mt6577_auxadc.c |  186 +++
 3 files changed, 104 insertions(+), 110 deletions(-)

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 66e9b44..14929fc 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -305,6 +305,19 @@ config MCP3422
  This driver can also be built as a module. If so, the module will be
  called mcp3422.
 
+config MEDIATEK_MT6577_AUXADC
+tristate "MediaTek AUXADC driver"
+depends on ARCH_MEDIATEK || COMPILE_TEST
+depends on HAS_IOMEM
+help
+  Say yes here to enable support for MediaTek mt65xx AUXADC.
+
+  The driver supports immediate mode operation to read from one of 
sixteen
+  channels (external or internal).
+
+  This driver can also be built as a module. If so, the module will be
+  called mt6577_auxadc.
+
 config MEN_Z188_ADC
tristate "MEN 16z188 ADC IP Core support"
depends on MCB
@@ -315,19 +328,6 @@ config MEN_Z188_ADC
  This driver can also be built as a module. If so, the module will be
  called men_z188_adc.
 
-config MEDIATEK_MT65XX_AUXADC
-   tristate "MediaTek AUXADC driver"
-   depends on ARCH_MEDIATEK || COMPILE_TEST
-   depends on HAS_IOMEM
-   help
- Say yes here to enable support for MediaTek mt65xx AUXADC.
-
- The driver supports immediate mode operation to read from one of 
sixteen
- channels (external or internal).
-
- This driver can also be built as a module. If so, the module will be
- called mt6577_auxadc.
-
 config MXS_LRADC
 tristate "Freescale i.MX23/i.MX28 LRADC"
 depends on (ARCH_MXS || COMPILE_TEST) && HAS_IOMEM
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 14a630f..8306347 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -30,8 +30,8 @@ obj-$(CONFIG_MAX1027) += max1027.o
 obj-$(CONFIG_MAX1363) += max1363.o
 obj-$(CONFIG_MCP320X) += mcp320x.o
 obj-$(CONFIG_MCP3422) += mcp3422.o
+obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o
 obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
-obj-$(CONFIG_MEDIATEK_MT65XX_AUXADC) += mt6577_auxadc.o
 obj-$(CONFIG_MXS_LRADC) += mxs-lradc.o
 obj-$(CONFIG_NAU7802) += nau7802.o
 obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
diff --git a/drivers/iio/adc/mt6577_auxadc.c b/drivers/iio/adc/mt6577_auxadc.c
index a56531a..a853ae8 100644
--- a/drivers/iio/adc/mt6577_auxadc.c
+++ b/drivers/iio/adc/mt6577_auxadc.c
@@ -24,80 +24,78 @@
 #include 
 #include 
 
-/* Registers definitions */
-#define MT65XX_AUXADC_CON00x00
-#define MT65XX_AUXADC_CON10x04
-#define MT65XX_AUXADC_CON20x10
-#define MT65XX_AUXADC_STA BIT(0)
+/* Register definitions */
+#define MT6577_AUXADC_CON00x00
+#define MT6577_AUXADC_CON10x04
+#define MT6577_AUXADC_CON20x10
+#define MT6577_AUXADC_STA BIT(0)
 
-#define MT65XX_AUXADC_DAT00x14
-#define MT65XX_AUXADC_RDY0BIT(12)
+#define MT6577_AUXADC_DAT00x14
+#define MT6577_AUXADC_RDY0BIT(12)
 
-#define MT65XX_AUXADC_MISC0x94
-#define MT65XX_AUXADC_PDN_EN  BIT(14)
+#define MT6577_AUXADC_MISC0x94
+#define MT6577_AUXADC_PDN_EN  BIT(14)
 
-#define MT65XX_AUXADC_DAT_MASK0xfff
-#define MT65XX_AUXADC_SLEEP_US1000
-#define MT65XX_AUXADC_TIMEOUT_US  1
-#define MT65XX_AUXADC_POWER_READY_MS  1
-#define MT65XX_AUXADC_SAMPLE_READY_US 25
+#define MT6577_AUXADC_DAT_MASK0xfff
+#define MT6577_AUXADC_SLEEP_US1000
+#define MT6577_AUXADC_TIMEOUT_US  1
+#define MT6577_AUXADC_POWER_READY_MS  1
+#define MT6577_AUXADC_SAMPLE_READY_US 25
 
-struct mt65xx_auxadc_device {
+struct mt6577_auxadc_device {
void __iomem *reg_base;
struct clk *adc_clk;
struct mutex lock;
-   unsigned int power_ready_ms;
-   unsigned int sample_ready_us;
 };
 
-#define MT65XX_AUXADC_CHANNEL(idx) {   \
+#define MT6577_AUXADC_CHANNEL(idx) {   \
.type = IIO_VOLTAGE,\
.indexed = 1,   \
.channel = (idx),  

[PATCH v3 0/2] AUXADC: Mediatek auxadc driver

[Zhiyong Tao]

This series includes three patches:
1.Change the device tree binding documentation.
2.Add auxadc driver based on linux iio.
3.Add auxadc nodes in the mediatek MT2701 dtsi file.

changes in patch v3:
1).Add '#' before 'io-channel-cells' and change 'auxadc@' to 'adc@' in auxadc 
binding document.
2).Fix CONFIG_MEDIATEK_MT65XX_AUXADC sequence as alphabetical order.
3).Change the prefix 'MT65XX' to 'MT6577' to match auxadc driver name.
4).Remove the delays stored in 'mt6577_auxadc_device' and use the defined delay 
directly.
5).Use '-ETIMEDOUT' instead of '-EINVAL'.
6).Return value directly in 'mt6577_auxadc_read_raw'.
7).Add power off and unprepare clock if 'iio_device_register' failed.
8).Change 'Registers' to 'Register'.

changes in patch v2:
1).Change the file name mt65xx_auxadc.c to mt6577_auxadc.c.
2).Add 'depends on ARCH_MEDIATEK || COMPILE_TEST and HAS_IOMEM' for 
MEDIATEK_MT65XX_AUXADC config.
3).Add check case for return value of 'readl_poll_timeout'.
4).Remove returning 1 and 0 for SCALE and OFFSET. use channel type 
'IIO_CHAN_INFO_PROCESSED' instead of 'IIO_CHAN_INFO_RAW'.
5).Remove 'IIO_CHAN_INFO_OFFSET' and 'IIO_CHAN_INFO_SCALE' in 
'MT65XX_AUXADC_CHANNEL' channel type.
6).Add check case when auxadc power on failure. if auxadc power on failure, 
clk_disable_unprepare should be executed.
7).Put 'platform_set_drvdata' before 'iio_device_register'.
8).Fix coding style and spelling error.

Zhiyong Tao (2):
  dt-bindings: auxadc: Add binding document for Mediatek auxadc.
  iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.

 .../devicetree/bindings/iio/adc/mt65xx_auxadc.txt  |4 +-
 drivers/iio/adc/Kconfig|   26 +--
 drivers/iio/adc/Makefile   |2 +-
 drivers/iio/adc/mt6577_auxadc.c|  186 ++--
 4 files changed, 106 insertions(+), 112 deletions(-)

[PATCH v3 0/2] AUXADC: Mediatek auxadc driver

[Zhiyong Tao]

This series includes three patches:
1.Change the device tree binding documentation.
2.Add auxadc driver based on linux iio.
3.Add auxadc nodes in the mediatek MT2701 dtsi file.

changes in patch v3:
1).Add '#' before 'io-channel-cells' and change 'auxadc@' to 'adc@' in auxadc 
binding document.
2).Fix CONFIG_MEDIATEK_MT65XX_AUXADC sequence as alphabetical order.
3).Change the prefix 'MT65XX' to 'MT6577' to match auxadc driver name.
4).Remove the delays stored in 'mt6577_auxadc_device' and use the defined delay 
directly.
5).Use '-ETIMEDOUT' instead of '-EINVAL'.
6).Return value directly in 'mt6577_auxadc_read_raw'.
7).Add power off and unprepare clock if 'iio_device_register' failed.
8).Change 'Registers' to 'Register'.

changes in patch v2:
1).Change the file name mt65xx_auxadc.c to mt6577_auxadc.c.
2).Add 'depends on ARCH_MEDIATEK || COMPILE_TEST and HAS_IOMEM' for 
MEDIATEK_MT65XX_AUXADC config.
3).Add check case for return value of 'readl_poll_timeout'.
4).Remove returning 1 and 0 for SCALE and OFFSET. use channel type 
'IIO_CHAN_INFO_PROCESSED' instead of 'IIO_CHAN_INFO_RAW'.
5).Remove 'IIO_CHAN_INFO_OFFSET' and 'IIO_CHAN_INFO_SCALE' in 
'MT65XX_AUXADC_CHANNEL' channel type.
6).Add check case when auxadc power on failure. if auxadc power on failure, 
clk_disable_unprepare should be executed.
7).Put 'platform_set_drvdata' before 'iio_device_register'.
8).Fix coding style and spelling error.

Zhiyong Tao (2):
  dt-bindings: auxadc: Add binding document for Mediatek auxadc.
  iio: adc: mt2701: Add Mediatek auxadc driver for mt2701.

 .../devicetree/bindings/iio/adc/mt65xx_auxadc.txt  |4 +-
 drivers/iio/adc/Kconfig|   26 +--
 drivers/iio/adc/Makefile   |2 +-
 drivers/iio/adc/mt6577_auxadc.c|  186 ++--
 4 files changed, 106 insertions(+), 112 deletions(-)

Re: [PATCH v2 05/10] power/reset: Add reset driver support for nuc900

[Paul Gortmaker]

[Re: [PATCH v2 05/10] power/reset: Add reset driver support for nuc900] On 
11/07/2016 (Mon 10:30) Wan Zongshun wrote:

> 
> 
> On 2016年07月11日 05:56, Paul Gortmaker wrote:
> >On Sun, Jul 10, 2016 at 3:27 AM, Wan Zongshun  wrote
> >>This driver is to add reset support for nuc900 series,
> >>currently, it only supports nuc970 SoC reset.
> >>
> >>Signed-off-by: Wan Zongshun 
> >>---
> >>  drivers/power/reset/Kconfig|  7 +++
> >>  drivers/power/reset/Makefile   |  1 +
> >>  drivers/power/reset/nuc900-reset.c | 93 
> >> ++
> >>  3 files changed, 101 insertions(+)
> >>  create mode 100644 drivers/power/reset/nuc900-reset.c
> >>
> >>diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> >>index 9bb2622..8c84892 100644
> >>--- a/drivers/power/reset/Kconfig
> >>+++ b/drivers/power/reset/Kconfig
> >>@@ -94,6 +94,13 @@ config POWER_RESET_MSM
> >> help
> >>   Power off and restart support for Qualcomm boards.
> >>
> >>+config POWER_RESET_NUC900
> >>+   bool "Nuc900 restart driver"
> >
> >If this driver is bool and not tristate, then please remove all references
> >to MODULE_ and then the module.h include as well.
> 
> I will remove the following codes in my reset.c driver.
> 
> MODULE_DEVICE_TABLE(of, of_nuc900_reset_match);
> #include 

Thanks -- it is not a specific criticism of your driver, but just a
mistake that we have consistently copied from one driver to the next,
and I hope we can stop doing that with the right reviews.

P.
--

> 
> 
> >
> >Thanks,
> >Paul.
> >--
> >
> >>+   depends on ARCH_W90X900
> >>+   help
> >>+ Power off and restart support for Nuvoton NUC900 family of
> >>+ reference boards.
> >>+
> >>  config POWER_RESET_LTC2952
> >> bool "LTC2952 PowerPath power-off driver"
> >> depends on OF_GPIO
> >>diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> >>index ab7aa86..d4df889 100644
> >>--- a/drivers/power/reset/Makefile
> >>+++ b/drivers/power/reset/Makefile
> >>@@ -9,6 +9,7 @@ obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
> >>  obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
> >>  obj-$(CONFIG_POWER_RESET_IMX) += imx-snvs-poweroff.o
> >>  obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
> >>+obj-$(CONFIG_POWER_RESET_NUC900) += nuc900-reset.o
> >>  obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
> >>  obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
> >>  obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
> >>diff --git a/drivers/power/reset/nuc900-reset.c 
> >>b/drivers/power/reset/nuc900-reset.c
> >>new file mode 100644
> >>index 000..49986b7
> >>--- /dev/null
> >>+++ b/drivers/power/reset/nuc900-reset.c
> >>@@ -0,0 +1,93 @@
> >>+/*
> >>+ * Copyright 2016 Wan Zongshun 
> >>+ *
> >>+ * The code contained herein is licensed under the GNU General Public
> >>+ * License. You may obtain a copy of the GNU General Public License
> >>+ * Version 2 or later at the following locations:
> >>+ *
> >>+ * http://www.opensource.org/licenses/gpl-license.html
> >>+ * http://www.gnu.org/copyleft/gpl.html
> >>+ */
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>
> >
> >[...]
> >
> >___
> >linux-arm-kernel mailing list
> >linux-arm-ker...@lists.infradead.org
> >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> >

Re: [PATCH v2 05/10] power/reset: Add reset driver support for nuc900

[Paul Gortmaker]

[Re: [PATCH v2 05/10] power/reset: Add reset driver support for nuc900] On 
11/07/2016 (Mon 10:30) Wan Zongshun wrote:

> 
> 
> On 2016年07月11日 05:56, Paul Gortmaker wrote:
> >On Sun, Jul 10, 2016 at 3:27 AM, Wan Zongshun  wrote
> >>This driver is to add reset support for nuc900 series,
> >>currently, it only supports nuc970 SoC reset.
> >>
> >>Signed-off-by: Wan Zongshun 
> >>---
> >>  drivers/power/reset/Kconfig|  7 +++
> >>  drivers/power/reset/Makefile   |  1 +
> >>  drivers/power/reset/nuc900-reset.c | 93 
> >> ++
> >>  3 files changed, 101 insertions(+)
> >>  create mode 100644 drivers/power/reset/nuc900-reset.c
> >>
> >>diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> >>index 9bb2622..8c84892 100644
> >>--- a/drivers/power/reset/Kconfig
> >>+++ b/drivers/power/reset/Kconfig
> >>@@ -94,6 +94,13 @@ config POWER_RESET_MSM
> >> help
> >>   Power off and restart support for Qualcomm boards.
> >>
> >>+config POWER_RESET_NUC900
> >>+   bool "Nuc900 restart driver"
> >
> >If this driver is bool and not tristate, then please remove all references
> >to MODULE_ and then the module.h include as well.
> 
> I will remove the following codes in my reset.c driver.
> 
> MODULE_DEVICE_TABLE(of, of_nuc900_reset_match);
> #include 

Thanks -- it is not a specific criticism of your driver, but just a
mistake that we have consistently copied from one driver to the next,
and I hope we can stop doing that with the right reviews.

P.
--

> 
> 
> >
> >Thanks,
> >Paul.
> >--
> >
> >>+   depends on ARCH_W90X900
> >>+   help
> >>+ Power off and restart support for Nuvoton NUC900 family of
> >>+ reference boards.
> >>+
> >>  config POWER_RESET_LTC2952
> >> bool "LTC2952 PowerPath power-off driver"
> >> depends on OF_GPIO
> >>diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
> >>index ab7aa86..d4df889 100644
> >>--- a/drivers/power/reset/Makefile
> >>+++ b/drivers/power/reset/Makefile
> >>@@ -9,6 +9,7 @@ obj-$(CONFIG_POWER_RESET_GPIO_RESTART) += gpio-restart.o
> >>  obj-$(CONFIG_POWER_RESET_HISI) += hisi-reboot.o
> >>  obj-$(CONFIG_POWER_RESET_IMX) += imx-snvs-poweroff.o
> >>  obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
> >>+obj-$(CONFIG_POWER_RESET_NUC900) += nuc900-reset.o
> >>  obj-$(CONFIG_POWER_RESET_LTC2952) += ltc2952-poweroff.o
> >>  obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
> >>  obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
> >>diff --git a/drivers/power/reset/nuc900-reset.c 
> >>b/drivers/power/reset/nuc900-reset.c
> >>new file mode 100644
> >>index 000..49986b7
> >>--- /dev/null
> >>+++ b/drivers/power/reset/nuc900-reset.c
> >>@@ -0,0 +1,93 @@
> >>+/*
> >>+ * Copyright 2016 Wan Zongshun 
> >>+ *
> >>+ * The code contained herein is licensed under the GNU General Public
> >>+ * License. You may obtain a copy of the GNU General Public License
> >>+ * Version 2 or later at the following locations:
> >>+ *
> >>+ * http://www.opensource.org/licenses/gpl-license.html
> >>+ * http://www.gnu.org/copyleft/gpl.html
> >>+ */
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>+#include 
> >>
> >
> >[...]
> >
> >___
> >linux-arm-kernel mailing list
> >linux-arm-ker...@lists.infradead.org
> >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
> >

Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver

[tiffany lin]

Hi Hans,

On Fri, 2016-07-08 at 12:23 +0200, Hans Verkuil wrote:
> On 05/30/2016 02:29 PM, Tiffany Lin wrote:
> > Add V4L2_PIX_FMT_MT21 documentation
> > 
> > Signed-off-by: Tiffany Lin 
> > ---
> >  Documentation/DocBook/media/v4l/pixfmt.xml |6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
> > b/Documentation/DocBook/media/v4l/pixfmt.xml
> > index 5a08aee..d40e0ce 100644
> > --- a/Documentation/DocBook/media/v4l/pixfmt.xml
> > +++ b/Documentation/DocBook/media/v4l/pixfmt.xml
> > @@ -1980,6 +1980,12 @@ array. Anything what's in between the UYVY lines is 
> > JPEG data and should be
> >  concatenated to form the JPEG stream. 
> >  
> >   
> > + 
> > +   V4L2_PIX_FMT_MT21
> > +   'MT21'
> > +   Compressed two-planar YVU420 format used by Mediatek MT8173
> > +   codec driver.
> 
> Can you give a few more details? The encoder driver doesn't seem to produce 
> this
> format, so who is creating this? Where is this format documented?
> 

It can be as input format for encoder, MDP and display drivers in our
platform.
This private format is only available in our platform.
So I put it in "Reserved Format Identifiers" sections.


best regards,
Tiffany

> Regards,
> 
>   Hans
> 
> > + 
> > 
> >
> >  
> > 

Re: [PATCH v3 3/9] DocBook/v4l: Add compressed video formats used on MT8173 codec driver

[tiffany lin]

Hi Hans,

On Fri, 2016-07-08 at 12:23 +0200, Hans Verkuil wrote:
> On 05/30/2016 02:29 PM, Tiffany Lin wrote:
> > Add V4L2_PIX_FMT_MT21 documentation
> > 
> > Signed-off-by: Tiffany Lin 
> > ---
> >  Documentation/DocBook/media/v4l/pixfmt.xml |6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
> > b/Documentation/DocBook/media/v4l/pixfmt.xml
> > index 5a08aee..d40e0ce 100644
> > --- a/Documentation/DocBook/media/v4l/pixfmt.xml
> > +++ b/Documentation/DocBook/media/v4l/pixfmt.xml
> > @@ -1980,6 +1980,12 @@ array. Anything what's in between the UYVY lines is 
> > JPEG data and should be
> >  concatenated to form the JPEG stream. 
> >  
> >   
> > + 
> > +   V4L2_PIX_FMT_MT21
> > +   'MT21'
> > +   Compressed two-planar YVU420 format used by Mediatek MT8173
> > +   codec driver.
> 
> Can you give a few more details? The encoder driver doesn't seem to produce 
> this
> format, so who is creating this? Where is this format documented?
> 

It can be as input format for encoder, MDP and display drivers in our
platform.
This private format is only available in our platform.
So I put it in "Reserved Format Identifiers" sections.


best regards,
Tiffany

> Regards,
> 
>   Hans
> 
> > + 
> > 
> >
> >  
> > 

Re: [PATCH v9 1/4] dt-bindings: soc: Add documentation for the MediaTek GCE unit

[Horng-Shyang Liao]

Hi Jan,

On Fri, 2016-07-08 at 12:17 +0200, Jan Lübbe wrote:
> On Do, 2016-06-30 at 15:14 +0800, HS Liao wrote:
> [...]
> > +Required properties:
> > +- compatible: Must be "mediatek,mt8173-gce"
> > +- reg: Address range of the GCE unit
> > +- interrupts: The interrupt signal from the GCE block
> > +- clock: Clocks according to the common clock binding
> > +- clock-names: Must be "gce" to stand for GCE clock
> > +- #mbox-cells: Should be 1
> [...]
> > +   #mbox-cells = <1>;
> [...]
> > +   mediatek,gce = <>;
> > +   mboxes = < 0 1 /* main display with merging wfe */
> > +  1 1>; /* sub display with merging wfe */
> 
> It seems that you use two cells instead of one as you declared above.
> This should be consistent.

Will correct it as 2.

> Also, why do you need an explicit phandle to the gce if you already use
> mailboxes?

"mediatek,gce" should be added to all clients which ask gce to access 
their registers.

"mboxes" should be added to all clients which will communicate with gce
via mailbox.

For example, if mmsys send cmdq tasks to ask gce to write registers of 
mmsys and ovl, mmsys should have "mediatek,gce" and "mboxes", and ovl
should have "mediatek,gce".

I will explain their difference in GCE's device tree document.

> Best regards,
> Jan Lübbe

Thanks,
HS

Re: [PATCH v9 1/4] dt-bindings: soc: Add documentation for the MediaTek GCE unit

[Horng-Shyang Liao]

Hi Jan,

On Fri, 2016-07-08 at 12:17 +0200, Jan Lübbe wrote:
> On Do, 2016-06-30 at 15:14 +0800, HS Liao wrote:
> [...]
> > +Required properties:
> > +- compatible: Must be "mediatek,mt8173-gce"
> > +- reg: Address range of the GCE unit
> > +- interrupts: The interrupt signal from the GCE block
> > +- clock: Clocks according to the common clock binding
> > +- clock-names: Must be "gce" to stand for GCE clock
> > +- #mbox-cells: Should be 1
> [...]
> > +   #mbox-cells = <1>;
> [...]
> > +   mediatek,gce = <>;
> > +   mboxes = < 0 1 /* main display with merging wfe */
> > +  1 1>; /* sub display with merging wfe */
> 
> It seems that you use two cells instead of one as you declared above.
> This should be consistent.

Will correct it as 2.

> Also, why do you need an explicit phandle to the gce if you already use
> mailboxes?

"mediatek,gce" should be added to all clients which ask gce to access 
their registers.

"mboxes" should be added to all clients which will communicate with gce
via mailbox.

For example, if mmsys send cmdq tasks to ask gce to write registers of 
mmsys and ovl, mmsys should have "mediatek,gce" and "mboxes", and ovl
should have "mediatek,gce".

I will explain their difference in GCE's device tree document.

> Best regards,
> Jan Lübbe

Thanks,
HS