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

2017-01-17 Thread Mylene Josserand

Hi,

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

Hi,

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

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

Signed-off-by: Mylène Josserand 


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


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


Thank you !

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


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

2017-01-17 Thread Mylene Josserand

Hi,

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

Hi,

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

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

Signed-off-by: Mylène Josserand 


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


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


Thank you !

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


Re: [RESEND RFC 1/3] mmc: sdhci: Add platform_dumpregs callback support to sdhci_ops.

2017-01-17 Thread Ritesh Harjani

Hi Shawn,

On 1/10/2017 2:45 PM, Shawn Lin wrote:

On 2017/1/10 14:41, Ritesh Harjani wrote:

From: Sahitya Tummala 

Add new host operation ->platform_dumpregs to provide a
mechanism through which host drivers can dump platform
specific registers in addition to SDHC registers
during error conditions.



Although we have been preventing from adding new callback
for sdhci core, this one makes sense as there are more and more
vendor registers outside the scope of SDHCI spec.

Sure thanks, shall I add your Reviewed-by on this patch 1/3.
Would you be able to review other as well?



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


Re: [RESEND RFC 1/3] mmc: sdhci: Add platform_dumpregs callback support to sdhci_ops.

2017-01-17 Thread Ritesh Harjani

Hi Shawn,

On 1/10/2017 2:45 PM, Shawn Lin wrote:

On 2017/1/10 14:41, Ritesh Harjani wrote:

From: Sahitya Tummala 

Add new host operation ->platform_dumpregs to provide a
mechanism through which host drivers can dump platform
specific registers in addition to SDHC registers
during error conditions.



Although we have been preventing from adding new callback
for sdhci core, this one makes sense as there are more and more
vendor registers outside the scope of SDHCI spec.

Sure thanks, shall I add your Reviewed-by on this patch 1/3.
Would you be able to review other as well?



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


Re: [RESEND PATCHv1 0/8] mmc: sdhci-msm: Provide support for enhanced strobe

2017-01-17 Thread Ritesh Harjani



On 1/17/2017 6:37 AM, Jeremy McNicoll wrote:

On Tue, Jan 10, 2017 at 12:30:44PM +0530, Ritesh Harjani wrote:

Hi,

Resending this patch series, as no one could review it -possibly due to
holidays during that time.

This patch series mainly provides enhanced strobe support to sdhci-msm driver
along with some additions of HW recommended sequence. This has been tested on
8996 based internal target & on db410c.

Patches 1-3 :- Factors out few functions to be re-used again.
   To also simplify large functions and makes it more readable.

Patches 4-5 :- Few recommendations based on HW prog. guide.

Patches 6 :- Clear SDHCI_HS400_TUNING flag after platform_execute_tuning
 so that ->platform_execute_tuning (underlying platform driver) can
 know about HS400 tuning.

Patch 7 :- Implements an additional step as per HPG for HS400 tuning.

Patch 8 :- Implements enhanced strobe functionality in sdhci-msm driver.




I have included this series in my tree while testing my SDHCI V2 series.

One message did occur which looks new or unfamilar and relatively
harmless,

"sdhci_msm f9824900.mmc: TCXO clk not present (-2) "

This should be ok.



Is that something I am missing on my side?

You should provide this in your DT.
@@ -463,8 +463,9 @@
interrupts = <0 141 0>, <0 134 0>;
interrupt-names = "hc_irq", "pwr_irq";
clocks = < GCC_SDCC1_APPS_CLK>,
-< GCC_SDCC1_AHB_CLK>;
-   clock-names = "core", "iface";
+< GCC_SDCC1_AHB_CLK>,
+<_board>;
+   clock-names = "core", "iface", "xo";





In anycase,

Tested-by: Jeremy McNicoll 

Thanks for testing this series.

Hi Adrian/Ulf,
In case if we dont have any other comments, can we please include this 
series in next ?



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


Re: [RESEND PATCHv1 0/8] mmc: sdhci-msm: Provide support for enhanced strobe

2017-01-17 Thread Ritesh Harjani



On 1/17/2017 6:37 AM, Jeremy McNicoll wrote:

On Tue, Jan 10, 2017 at 12:30:44PM +0530, Ritesh Harjani wrote:

Hi,

Resending this patch series, as no one could review it -possibly due to
holidays during that time.

This patch series mainly provides enhanced strobe support to sdhci-msm driver
along with some additions of HW recommended sequence. This has been tested on
8996 based internal target & on db410c.

Patches 1-3 :- Factors out few functions to be re-used again.
   To also simplify large functions and makes it more readable.

Patches 4-5 :- Few recommendations based on HW prog. guide.

Patches 6 :- Clear SDHCI_HS400_TUNING flag after platform_execute_tuning
 so that ->platform_execute_tuning (underlying platform driver) can
 know about HS400 tuning.

Patch 7 :- Implements an additional step as per HPG for HS400 tuning.

Patch 8 :- Implements enhanced strobe functionality in sdhci-msm driver.




I have included this series in my tree while testing my SDHCI V2 series.

One message did occur which looks new or unfamilar and relatively
harmless,

"sdhci_msm f9824900.mmc: TCXO clk not present (-2) "

This should be ok.



Is that something I am missing on my side?

You should provide this in your DT.
@@ -463,8 +463,9 @@
interrupts = <0 141 0>, <0 134 0>;
interrupt-names = "hc_irq", "pwr_irq";
clocks = < GCC_SDCC1_APPS_CLK>,
-< GCC_SDCC1_AHB_CLK>;
-   clock-names = "core", "iface";
+< GCC_SDCC1_AHB_CLK>,
+<_board>;
+   clock-names = "core", "iface", "xo";





In anycase,

Tested-by: Jeremy McNicoll 

Thanks for testing this series.

Hi Adrian/Ulf,
In case if we dont have any other comments, can we please include this 
series in next ?



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


Re: [RFC PATCH] initramfs: finish fput() before accessing any binary from initramfs

2017-01-17 Thread Lokesh Vutla


On Tuesday 17 January 2017 06:23 PM, Tero Kristo wrote:
> On 17/01/17 13:14, Lokesh Vutla wrote:
>> commit 4a9d4b024a31 ("switch fput to task_work_add") implements a
>> schedule_work() for completing fput(), but did not guarantee calling
>> __fput() after unpacking initramfs. Because of this, there is a
>> possibility that during boot a driver can see ETXTBSY when it tries
>> to load a binary from initramfs as fput() is still pending on that
>> binary. This patch makes sure that fput() is completed after unpacking
>> initramfs.
> 
> Good find there.
> 
>>
>> Signed-off-by: Lokesh Vutla 
>> ---
>>
>> - Reproduced on TI K2HK EVM. K2HK Queue Manager subsystem driver[1] tries
>> to load a firmware from initramfs during boot. Sometimes loading of this
>> firmware fails with error ETXTBSY. Digging a bit more observed that
>> deny_write_access() is returning ETXTBSY as inode->i_writecount is > 0
>> for that file. This is because Unpacking initramfs does a
>> get_write_access(from open) but hasn't done put_write_access(from fput)
>> as it hasn't been scheduled yet.
>>
>> [1]
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/ti/knav_qmss_queue.c
>>
>>
>>  init/initramfs.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/init/initramfs.c b/init/initramfs.c
>> index b32ad7d97ac9..c42c69b48a4b 100644
>> --- a/init/initramfs.c
>> +++ b/init/initramfs.c
>> @@ -18,6 +18,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  static ssize_t __init xwrite(int fd, const char *p, size_t count)
>>  {
>> @@ -652,6 +653,7 @@ static int __init populate_rootfs(void)
>>   * us a chance to load before device_initcalls.
>>   */
>>  load_default_modules();
>> +flush_delayed_fput();
> 
> Shouldn't the flush be called before the load_default_modules() though?

Good point. Will wait for sometime for more comments and then repost it.

Thanks and regards,
Lokesh


Re: [RFC PATCH] initramfs: finish fput() before accessing any binary from initramfs

2017-01-17 Thread Lokesh Vutla


On Tuesday 17 January 2017 06:23 PM, Tero Kristo wrote:
> On 17/01/17 13:14, Lokesh Vutla wrote:
>> commit 4a9d4b024a31 ("switch fput to task_work_add") implements a
>> schedule_work() for completing fput(), but did not guarantee calling
>> __fput() after unpacking initramfs. Because of this, there is a
>> possibility that during boot a driver can see ETXTBSY when it tries
>> to load a binary from initramfs as fput() is still pending on that
>> binary. This patch makes sure that fput() is completed after unpacking
>> initramfs.
> 
> Good find there.
> 
>>
>> Signed-off-by: Lokesh Vutla 
>> ---
>>
>> - Reproduced on TI K2HK EVM. K2HK Queue Manager subsystem driver[1] tries
>> to load a firmware from initramfs during boot. Sometimes loading of this
>> firmware fails with error ETXTBSY. Digging a bit more observed that
>> deny_write_access() is returning ETXTBSY as inode->i_writecount is > 0
>> for that file. This is because Unpacking initramfs does a
>> get_write_access(from open) but hasn't done put_write_access(from fput)
>> as it hasn't been scheduled yet.
>>
>> [1]
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/ti/knav_qmss_queue.c
>>
>>
>>  init/initramfs.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/init/initramfs.c b/init/initramfs.c
>> index b32ad7d97ac9..c42c69b48a4b 100644
>> --- a/init/initramfs.c
>> +++ b/init/initramfs.c
>> @@ -18,6 +18,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  static ssize_t __init xwrite(int fd, const char *p, size_t count)
>>  {
>> @@ -652,6 +653,7 @@ static int __init populate_rootfs(void)
>>   * us a chance to load before device_initcalls.
>>   */
>>  load_default_modules();
>> +flush_delayed_fput();
> 
> Shouldn't the flush be called before the load_default_modules() though?

Good point. Will wait for sometime for more comments and then repost it.

Thanks and regards,
Lokesh


Re: [PATCH v11 09/12] drm/mediatek: add dsi transfer function

2017-01-17 Thread CK Hu
Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> From: shaoming chen 
> 
> add dsi read/write commands for transfer function
> 
> Signed-off-by: shaoming chen 

Acked-by: CK Hu 

> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 168 
> -
>  1 file changed, 166 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 474861a..b3c7fd8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "mtk_drm_ddp_comp.h"
> @@ -80,8 +81,16 @@
>  #define DSI_HBP_WC   0x54
>  #define DSI_HFP_WC   0x58
>  
> +#define DSI_CMDQ_SIZE0x60
> +#define CMDQ_SIZE0x3f
> +
>  #define DSI_HSTX_CKL_WC  0x64
>  
> +#define DSI_RX_DATA0 0x74
> +#define DSI_RX_DATA1 0x78
> +#define DSI_RX_DATA2 0x7c
> +#define DSI_RX_DATA3 0x80
> +
>  #define DSI_RACK 0x84
>  #define RACK BIT(0)
>  
> @@ -117,6 +126,15 @@
>  #define CLK_HS_POST  (0xff << 8)
>  #define CLK_HS_EXIT  (0xff << 16)
>  
> +#define DSI_CMDQ00x180
> +#define CONFIG   (0xff << 0)
> +#define SHORT_PACKET 0
> +#define LONG_PACKET  2
> +#define BTA  BIT(2)
> +#define DATA_ID  (0xff << 8)
> +#define DATA_0   (0xff << 16)
> +#define DATA_1   (0xff << 24)
> +
>  #define T_LPX5
>  #define T_HS_PREP6
>  #define T_HS_TRAIL   8
> @@ -125,6 +143,12 @@
>  
>  #define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))
>  
> +#define MTK_DSI_HOST_IS_READ(type) \
> + ((type == MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM) || \
> + (type == MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM) || \
> + (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
> + (type == MIPI_DSI_DCS_READ))
> +
>  struct phy;
>  
>  struct mtk_dsi {
> @@ -497,12 +521,12 @@ static void mtk_dsi_irq_data_set(struct mtk_dsi *dsi, 
> u32 irq_bit)
>   dsi->irq_data |= irq_bit;
>  }
>  
> -static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 
> irq_bit)
> +static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)
>  {
>   dsi->irq_data &= ~irq_bit;
>  }
>  
> -static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 
> irq_flag,
> +static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
>unsigned int timeout)
>  {
>   s32 ret = 0;
> @@ -832,9 +856,149 @@ static int mtk_dsi_host_detach(struct mipi_dsi_host 
> *host,
>   return 0;
>  }
>  
> +static void mtk_dsi_wait_for_idle(struct mtk_dsi *dsi)
> +{
> + u32 timeout_ms = 50; /* total 1s ~ 2s timeout */
> +
> + while (timeout_ms--) {
> + if (!(readl(dsi->regs + DSI_INTSTA) & DSI_BUSY))
> + break;
> +
> + usleep_range(2, 4);
> + }
> +
> + if (timeout_ms == 0) {
> + DRM_WARN("polling dsi wait not busy timeout!\n");
> +
> + mtk_dsi_enable(dsi);
> + mtk_dsi_reset_engine(dsi);
> + }
> +}
> +
> +static u32 mtk_dsi_recv_cnt(u8 type, u8 *read_data)
> +{
> + switch (type) {
> + case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
> + case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
> + return 1;
> + case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE:
> + case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE:
> + return 2;
> + case MIPI_DSI_RX_GENERIC_LONG_READ_RESPONSE:
> + case MIPI_DSI_RX_DCS_LONG_READ_RESPONSE:
> + return read_data[1] + read_data[2] * 16;
> + case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
> + DRM_INFO("type is 0x02, try again\n");
> + break;
> + default:
> + DRM_INFO("type(0x%x) cannot be non-recognite\n", type);
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const struct mipi_dsi_msg *msg)
> +{
> + const char *tx_buf = msg->tx_buf;
> + u8 config, cmdq_size, cmdq_off, type = msg->type;
> + u32 reg_val, cmdq_mask, i;
> +
> + if (MTK_DSI_HOST_IS_READ(type))
> + config = BTA;
> + else
> + config = (msg->tx_len > 2) ? LONG_PACKET : SHORT_PACKET;
> +
> + if (msg->tx_len > 2) {
> + cmdq_size = 1 + (msg->tx_len + 3) / 4;
> + cmdq_off = 4;
> + cmdq_mask = CONFIG | DATA_ID | DATA_0 | DATA_1;
> + reg_val = (msg->tx_len << 16) | (type << 8) | config;
> + } else {
> + cmdq_size = 1;
> + 

Re: [PATCH v11 09/12] drm/mediatek: add dsi transfer function

2017-01-17 Thread CK Hu
Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> From: shaoming chen 
> 
> add dsi read/write commands for transfer function
> 
> Signed-off-by: shaoming chen 

Acked-by: CK Hu 

> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 168 
> -
>  1 file changed, 166 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 474861a..b3c7fd8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include "mtk_drm_ddp_comp.h"
> @@ -80,8 +81,16 @@
>  #define DSI_HBP_WC   0x54
>  #define DSI_HFP_WC   0x58
>  
> +#define DSI_CMDQ_SIZE0x60
> +#define CMDQ_SIZE0x3f
> +
>  #define DSI_HSTX_CKL_WC  0x64
>  
> +#define DSI_RX_DATA0 0x74
> +#define DSI_RX_DATA1 0x78
> +#define DSI_RX_DATA2 0x7c
> +#define DSI_RX_DATA3 0x80
> +
>  #define DSI_RACK 0x84
>  #define RACK BIT(0)
>  
> @@ -117,6 +126,15 @@
>  #define CLK_HS_POST  (0xff << 8)
>  #define CLK_HS_EXIT  (0xff << 16)
>  
> +#define DSI_CMDQ00x180
> +#define CONFIG   (0xff << 0)
> +#define SHORT_PACKET 0
> +#define LONG_PACKET  2
> +#define BTA  BIT(2)
> +#define DATA_ID  (0xff << 8)
> +#define DATA_0   (0xff << 16)
> +#define DATA_1   (0xff << 24)
> +
>  #define T_LPX5
>  #define T_HS_PREP6
>  #define T_HS_TRAIL   8
> @@ -125,6 +143,12 @@
>  
>  #define NS_TO_CYCLE(n, c)((n) / (c) + (((n) % (c)) ? 1 : 0))
>  
> +#define MTK_DSI_HOST_IS_READ(type) \
> + ((type == MIPI_DSI_GENERIC_READ_REQUEST_0_PARAM) || \
> + (type == MIPI_DSI_GENERIC_READ_REQUEST_1_PARAM) || \
> + (type == MIPI_DSI_GENERIC_READ_REQUEST_2_PARAM) || \
> + (type == MIPI_DSI_DCS_READ))
> +
>  struct phy;
>  
>  struct mtk_dsi {
> @@ -497,12 +521,12 @@ static void mtk_dsi_irq_data_set(struct mtk_dsi *dsi, 
> u32 irq_bit)
>   dsi->irq_data |= irq_bit;
>  }
>  
> -static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 
> irq_bit)
> +static void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 irq_bit)
>  {
>   dsi->irq_data &= ~irq_bit;
>  }
>  
> -static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 
> irq_flag,
> +static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
>unsigned int timeout)
>  {
>   s32 ret = 0;
> @@ -832,9 +856,149 @@ static int mtk_dsi_host_detach(struct mipi_dsi_host 
> *host,
>   return 0;
>  }
>  
> +static void mtk_dsi_wait_for_idle(struct mtk_dsi *dsi)
> +{
> + u32 timeout_ms = 50; /* total 1s ~ 2s timeout */
> +
> + while (timeout_ms--) {
> + if (!(readl(dsi->regs + DSI_INTSTA) & DSI_BUSY))
> + break;
> +
> + usleep_range(2, 4);
> + }
> +
> + if (timeout_ms == 0) {
> + DRM_WARN("polling dsi wait not busy timeout!\n");
> +
> + mtk_dsi_enable(dsi);
> + mtk_dsi_reset_engine(dsi);
> + }
> +}
> +
> +static u32 mtk_dsi_recv_cnt(u8 type, u8 *read_data)
> +{
> + switch (type) {
> + case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_1BYTE:
> + case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_1BYTE:
> + return 1;
> + case MIPI_DSI_RX_GENERIC_SHORT_READ_RESPONSE_2BYTE:
> + case MIPI_DSI_RX_DCS_SHORT_READ_RESPONSE_2BYTE:
> + return 2;
> + case MIPI_DSI_RX_GENERIC_LONG_READ_RESPONSE:
> + case MIPI_DSI_RX_DCS_LONG_READ_RESPONSE:
> + return read_data[1] + read_data[2] * 16;
> + case MIPI_DSI_RX_ACKNOWLEDGE_AND_ERROR_REPORT:
> + DRM_INFO("type is 0x02, try again\n");
> + break;
> + default:
> + DRM_INFO("type(0x%x) cannot be non-recognite\n", type);
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static void mtk_dsi_cmdq(struct mtk_dsi *dsi, const struct mipi_dsi_msg *msg)
> +{
> + const char *tx_buf = msg->tx_buf;
> + u8 config, cmdq_size, cmdq_off, type = msg->type;
> + u32 reg_val, cmdq_mask, i;
> +
> + if (MTK_DSI_HOST_IS_READ(type))
> + config = BTA;
> + else
> + config = (msg->tx_len > 2) ? LONG_PACKET : SHORT_PACKET;
> +
> + if (msg->tx_len > 2) {
> + cmdq_size = 1 + (msg->tx_len + 3) / 4;
> + cmdq_off = 4;
> + cmdq_mask = CONFIG | DATA_ID | DATA_0 | DATA_1;
> + reg_val = (msg->tx_len << 16) | (type << 8) | config;
> + } else {
> + cmdq_size = 1;
> + cmdq_off = 2;
> + cmdq_mask = CONFIG | DATA_ID;
> + 

Re: [PATCHSET v2] slab: make memcg slab destruction scalable

2017-01-17 Thread Joonsoo Kim
On Tue, Jan 17, 2017 at 08:49:13AM -0800, Tejun Heo wrote:
> Hello,
> 
> On Tue, Jan 17, 2017 at 09:12:57AM +0900, Joonsoo Kim wrote:
> > Could you confirm that your series solves the problem that is reported
> > by Doug? It would be great if the result is mentioned to the patch
> > description.
> > 
> > https://bugzilla.kernel.org/show_bug.cgi?id=172991
> 
> So, that's an issue in the creation path which is already resolved by
> switching to an ordered workqueue (it'd probably be better to use
> per-cpu wq w/ @max_active == 1 tho).  This patchset is about relesae
> path.  slab_mutex contention would definitely go down with this but
> I don't think there's more connection to it than that.

That problem is caused by slow release path and then contention on the
slab_mutex. With an ordered workqueue, kworker would not be created a
lot but it can be possible that a lot of work items to create a new
cache for memcg is pending for a long time due to slow release path.

Your patchset replaces optimization for release path so it's better to
check that the work isn't pending for a long time in above workload.

Thanks.


Re: [PATCHSET v2] slab: make memcg slab destruction scalable

2017-01-17 Thread Joonsoo Kim
On Tue, Jan 17, 2017 at 08:49:13AM -0800, Tejun Heo wrote:
> Hello,
> 
> On Tue, Jan 17, 2017 at 09:12:57AM +0900, Joonsoo Kim wrote:
> > Could you confirm that your series solves the problem that is reported
> > by Doug? It would be great if the result is mentioned to the patch
> > description.
> > 
> > https://bugzilla.kernel.org/show_bug.cgi?id=172991
> 
> So, that's an issue in the creation path which is already resolved by
> switching to an ordered workqueue (it'd probably be better to use
> per-cpu wq w/ @max_active == 1 tho).  This patchset is about relesae
> path.  slab_mutex contention would definitely go down with this but
> I don't think there's more connection to it than that.

That problem is caused by slow release path and then contention on the
slab_mutex. With an ordered workqueue, kworker would not be created a
lot but it can be possible that a lot of work items to create a new
cache for memcg is pending for a long time due to slow release path.

Your patchset replaces optimization for release path so it's better to
check that the work isn't pending for a long time in above workload.

Thanks.


Re: [PATCH] ARM: dts: sun6i: sina31s: Enable USB OTG controller in peripheral mode

2017-01-17 Thread Maxime Ripard
On Wed, Jan 18, 2017 at 09:01:05AM +0800, Chen-Yu Tsai wrote:
> While the SinA31s does have a proper 5-pin mini USB OTG port, the ID
> pin does not seem to work. The pin used in the schematics is always low,
> regardless of the attached OTG cable or SoC internal pin bias settings.
> 
> The v1.5 board is missing bias resistors shown in the schematics for
> earlier revisions, and the connections of the remaining one does not
> match the schematics either.
> 
> In addition, VBUS for this port is disconnected from the board's 5V
> power rail. The board features a pad to solder jumper pins to connect
> VBUS to 5V manually.
> 
> Given the above and the fact that the board has 5 more USB host ports,
> it makes more sense to have the OTG port work in peripheral mode.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature


Re: [PATCH] ARM: dts: sun6i: sina31s: Enable USB OTG controller in peripheral mode

2017-01-17 Thread Maxime Ripard
On Wed, Jan 18, 2017 at 09:01:05AM +0800, Chen-Yu Tsai wrote:
> While the SinA31s does have a proper 5-pin mini USB OTG port, the ID
> pin does not seem to work. The pin used in the schematics is always low,
> regardless of the attached OTG cable or SoC internal pin bias settings.
> 
> The v1.5 board is missing bias resistors shown in the schematics for
> earlier revisions, and the connections of the remaining one does not
> match the schematics either.
> 
> In addition, VBUS for this port is disconnected from the board's 5V
> power rail. The board features a pad to solder jumper pins to connect
> VBUS to 5V manually.
> 
> Given the above and the fact that the board has 5 more USB host ports,
> it makes more sense to have the OTG port work in peripheral mode.
> 
> Signed-off-by: Chen-Yu Tsai 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature


Re: [PATCH v6 23/25] usb: chipidea: Pullup D+ in device mode via phy APIs

2017-01-17 Thread Peter Chen
On Tue, Jan 17, 2017 at 09:58:33AM -0800, Stephen Boyd wrote:
> Quoting Peter Chen (2017-01-15 19:45:51)
> > 
> > So, you need to call phy_set_mode when switching between host and device.
> > Besides, you also need to toggle VBUSVLDEXT when the external vbus
> > is on or off at device mode (doesn't need for host mode), is it correct?
> 
> Correct.
> 
> > 
> > At include/linux/usb/phy.h, we have .set_vbus interface, maybe you need
> > to port it to generic phy framework.
> > 
> 
> Ok. I'll look into that. Can the other patches in this series be picked
> up? Otherwise I can resend them all again once I fix the phy_set_mode()
> call location and introduce a new phy op.

I can pick up chipidea patches after you test the patch I supplied at:

[PATCH v6 11/25] usb: chipidea: vbus event may exist before starting
gadget

You may ping other maintainers to pick up other patches.

-- 

Best Regards,
Peter Chen


Re: [PATCH v6 23/25] usb: chipidea: Pullup D+ in device mode via phy APIs

2017-01-17 Thread Peter Chen
On Tue, Jan 17, 2017 at 09:58:33AM -0800, Stephen Boyd wrote:
> Quoting Peter Chen (2017-01-15 19:45:51)
> > 
> > So, you need to call phy_set_mode when switching between host and device.
> > Besides, you also need to toggle VBUSVLDEXT when the external vbus
> > is on or off at device mode (doesn't need for host mode), is it correct?
> 
> Correct.
> 
> > 
> > At include/linux/usb/phy.h, we have .set_vbus interface, maybe you need
> > to port it to generic phy framework.
> > 
> 
> Ok. I'll look into that. Can the other patches in this series be picked
> up? Otherwise I can resend them all again once I fix the phy_set_mode()
> call location and introduce a new phy op.

I can pick up chipidea patches after you test the patch I supplied at:

[PATCH v6 11/25] usb: chipidea: vbus event may exist before starting
gadget

You may ping other maintainers to pick up other patches.

-- 

Best Regards,
Peter Chen


[PATCH v2] block: Don't register a registered bdi device

2017-01-17 Thread Yijing Wang
Following calltrace is quoted from Sreekanth Reddy's
patch email, we found the same issue in our platform.
link:https://patchwork.kernel.org/patch/9394471/

Observing below kernel panic while creating second raid disk
on LSI SAS3008 HBA card.
[  +0.55] [ cut here ]
[  +0.07] WARNING: CPU: 2 PID: 281 at fs/sysfs/dir.c:31 
sysfs_warn_dup+0x62/0x80
[  +0.02] sysfs: cannot create duplicate filename 
'/devices/virtual/bdi/8:32'
[  +0.01] Modules linked in: mptctl mptbase xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat  nf_conntrack tun bridge stp 
llc ebtable_filter ebtables ip6table_filter ip6_tables intel_rapl sb_edac 
edac_core x86_pkg_temp_pclmul joydev ghash_clmulni_intel iTCO_wdt ipmi_ssif 
mei_me pcspkr mei iTCO_vendor_support ipmi_si i2c_i801 lpc_ich mfd_corema 
acpi_pad wmi acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace binfmt_misc 
sunrpc xfs libcrc32c ast i2c_algo_bit drm_kore raid_class nvme_core 
scsi_transport_sas dca
[  +0.67] CPU: 2 PID: 281 Comm: kworker/u49:5 Not tainted 4.9.0-rc2 #1
[  +0.02] Hardware name: Supermicro SYS-2028U-TNRT+/X10DRU-i+, BIOS 1.1 
07/22/2015
[  +0.05] Workqueue: events_unbound async_run_entry_fn
[  +0.04] Call Trace:
[  +0.09]  [] dump_stack+0x63/0x85
[  +0.05]  [] __warn+0xcb/0xf0
[  +0.04]  [] warn_slowpath_fmt+0x5f/0x80
[  +0.06]  [] ? kernfs_path_from_node+0x4f/0x60
[  +0.02]  [] sysfs_warn_dup+0x62/0x80
[  +0.02]  [] sysfs_create_dir_ns+0x77/0x90
[  +0.04]  [] kobject_add_internal+0x99/0x330
[  +0.03]  [] ? vsnprintf+0x35b/0x4c0
[  +0.03]  [] kobject_add+0x75/0xd0
[  +0.06]  [] ? device_private_init+0x23/0x70
[  +0.07]  [] ? mutex_lock+0x12/0x30
[  +0.03]  [] device_add+0x119/0x670
[  +0.04]  [] device_create_groups_vargs+0xe0/0xf0
[  +0.03]  [] device_create_vargs+0x1c/0x20
[  +0.06]  [] bdi_register+0x8c/0x180
[  +0.03]  [] bdi_register_owner+0x36/0x60
[  +0.06]  [] device_add_disk+0x168/0x480
[  +0.05]  [] ? update_autosuspend+0x51/0x60
[  +0.05]  [] sd_probe_async+0x110/0x1c0
[  +0.02]  [] async_run_entry_fn+0x39/0x140
[  +0.03]  [] process_one_work+0x15f/0x430
[  +0.02]  [] worker_thread+0x4e/0x490
[  +0.02]  [] ? process_one_work+0x430/0x430
[  +0.03]  [] kthread+0xd9/0xf0
[  +0.03]  [] ? kthread_park+0x60/0x60
[  +0.03]  [] ret_from_fork+0x25/0x30
[  +0.02] [ cut here ]
[  +0.04] WARNING: CPU: 2 PID: 281 at lib/kobject.c:240 
kobject_add_internal+0x2bd/0x330
[  +0.01] kobject_add_internal failed for 8:32 with -EEXIST, don't try to 
register things with the same name in the same
[  +0.01] Modules linked in: mptctl mptbase xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat  nf_conntrack tun bridge stp 
llc ebtable_filter ebtables ip6table_filter ip6_tables intel_rapl sb_edac 
edac_core x86_pkg_temp_pclmul joydev ghash_clmulni_intel iTCO_wdt ipmi_ssif 
mei_me pcspkr mei iTCO_vendor_support ipmi_si i2c_i801 lpc_ich mfd_corema 
acpi_pad wmi acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace binfmt_misc 
sunrpc xfs libcrc32c ast i2c_algo_bit drm_kore raid_class nvme_core 
scsi_transport_sas dca
[  +0.43] CPU: 2 PID: 281 Comm: kworker/u49:5 Tainted: GW   
4.9.0-rc2 #1
[  +0.01] Hardware name: Supermicro SYS-2028U-TNRT+/X10DRU-i+, BIOS 1.1 
07/22/2015
[  +0.02] Workqueue: events_unbound async_run_entry_fn
[  +0.03] Call Trace:
[  +0.03]  [] dump_stack+0x63/0x85
[  +0.03]  [] __warn+0xcb/0xf0
[  +0.04]  [] warn_slowpath_fmt+0x5f/0x80
[  +0.02]  [] ? sysfs_warn_dup+0x6a/0x80
[  +0.03]  [] kobject_add_internal+0x2bd/0x330
[  +0.03]  [] ? vsnprintf+0x35b/0x4c0
[  +0.03]  [] kobject_add+0x75/0xd0
[  +0.03]  [] ? device_private_init+0x23/0x70
[  +0.04]  [] ? mutex_lock+0x12/0x30
[  +0.02]  [] device_add+0x119/0x670
[  +0.04]  [] device_create_groups_vargs+0xe0/0xf0
[  +0.03]  [] device_create_vargs+0x1c/0x20
[  +0.03]  [] bdi_register+0x8c/0x180
[  +0.03]  [] bdi_register_owner+0x36/0x60
[  +0.04]  [] device_add_disk+0x168/0x480
[  +0.03]  [] ? update_autosuspend+0x51/0x60
[  +0.02]  [] sd_probe_async+0x110/0x1c0
[  +0.02]  [] async_run_entry_fn+0x39/0x140
[  +0.02]  [] process_one_work+0x15f/0x430
[  +0.02]  [] worker_thread+0x4e/0x490
[  +0.02]  [] ? process_one_work+0x430/0x430
[  +0.03]  [] kthread+0xd9/0xf0
[  +0.03]  [] ? kthread_park+0x60/0x60
[  +0.03]  [] ret_from_fork+0x25/0x30
[  +0.000949] BUG: unable to handle kernel
[  +0.005263] NULL pointer dereference
[  +0.002853] IP: [] sysfs_do_create_link_sd.isra.2+0x34/0xb0
[  +0.008584] PGD 0

[  +0.006115] Oops:  [#1] SMP
[  +0.004531] Modules linked in: mptctl mptbase xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat  nf_conntrack tun bridge stp 
llc ebtable_filter ebtables ip6table_filter 

[PATCH v2] block: Don't register a registered bdi device

2017-01-17 Thread Yijing Wang
Following calltrace is quoted from Sreekanth Reddy's
patch email, we found the same issue in our platform.
link:https://patchwork.kernel.org/patch/9394471/

Observing below kernel panic while creating second raid disk
on LSI SAS3008 HBA card.
[  +0.55] [ cut here ]
[  +0.07] WARNING: CPU: 2 PID: 281 at fs/sysfs/dir.c:31 
sysfs_warn_dup+0x62/0x80
[  +0.02] sysfs: cannot create duplicate filename 
'/devices/virtual/bdi/8:32'
[  +0.01] Modules linked in: mptctl mptbase xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat  nf_conntrack tun bridge stp 
llc ebtable_filter ebtables ip6table_filter ip6_tables intel_rapl sb_edac 
edac_core x86_pkg_temp_pclmul joydev ghash_clmulni_intel iTCO_wdt ipmi_ssif 
mei_me pcspkr mei iTCO_vendor_support ipmi_si i2c_i801 lpc_ich mfd_corema 
acpi_pad wmi acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace binfmt_misc 
sunrpc xfs libcrc32c ast i2c_algo_bit drm_kore raid_class nvme_core 
scsi_transport_sas dca
[  +0.67] CPU: 2 PID: 281 Comm: kworker/u49:5 Not tainted 4.9.0-rc2 #1
[  +0.02] Hardware name: Supermicro SYS-2028U-TNRT+/X10DRU-i+, BIOS 1.1 
07/22/2015
[  +0.05] Workqueue: events_unbound async_run_entry_fn
[  +0.04] Call Trace:
[  +0.09]  [] dump_stack+0x63/0x85
[  +0.05]  [] __warn+0xcb/0xf0
[  +0.04]  [] warn_slowpath_fmt+0x5f/0x80
[  +0.06]  [] ? kernfs_path_from_node+0x4f/0x60
[  +0.02]  [] sysfs_warn_dup+0x62/0x80
[  +0.02]  [] sysfs_create_dir_ns+0x77/0x90
[  +0.04]  [] kobject_add_internal+0x99/0x330
[  +0.03]  [] ? vsnprintf+0x35b/0x4c0
[  +0.03]  [] kobject_add+0x75/0xd0
[  +0.06]  [] ? device_private_init+0x23/0x70
[  +0.07]  [] ? mutex_lock+0x12/0x30
[  +0.03]  [] device_add+0x119/0x670
[  +0.04]  [] device_create_groups_vargs+0xe0/0xf0
[  +0.03]  [] device_create_vargs+0x1c/0x20
[  +0.06]  [] bdi_register+0x8c/0x180
[  +0.03]  [] bdi_register_owner+0x36/0x60
[  +0.06]  [] device_add_disk+0x168/0x480
[  +0.05]  [] ? update_autosuspend+0x51/0x60
[  +0.05]  [] sd_probe_async+0x110/0x1c0
[  +0.02]  [] async_run_entry_fn+0x39/0x140
[  +0.03]  [] process_one_work+0x15f/0x430
[  +0.02]  [] worker_thread+0x4e/0x490
[  +0.02]  [] ? process_one_work+0x430/0x430
[  +0.03]  [] kthread+0xd9/0xf0
[  +0.03]  [] ? kthread_park+0x60/0x60
[  +0.03]  [] ret_from_fork+0x25/0x30
[  +0.02] [ cut here ]
[  +0.04] WARNING: CPU: 2 PID: 281 at lib/kobject.c:240 
kobject_add_internal+0x2bd/0x330
[  +0.01] kobject_add_internal failed for 8:32 with -EEXIST, don't try to 
register things with the same name in the same
[  +0.01] Modules linked in: mptctl mptbase xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat  nf_conntrack tun bridge stp 
llc ebtable_filter ebtables ip6table_filter ip6_tables intel_rapl sb_edac 
edac_core x86_pkg_temp_pclmul joydev ghash_clmulni_intel iTCO_wdt ipmi_ssif 
mei_me pcspkr mei iTCO_vendor_support ipmi_si i2c_i801 lpc_ich mfd_corema 
acpi_pad wmi acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace binfmt_misc 
sunrpc xfs libcrc32c ast i2c_algo_bit drm_kore raid_class nvme_core 
scsi_transport_sas dca
[  +0.43] CPU: 2 PID: 281 Comm: kworker/u49:5 Tainted: GW   
4.9.0-rc2 #1
[  +0.01] Hardware name: Supermicro SYS-2028U-TNRT+/X10DRU-i+, BIOS 1.1 
07/22/2015
[  +0.02] Workqueue: events_unbound async_run_entry_fn
[  +0.03] Call Trace:
[  +0.03]  [] dump_stack+0x63/0x85
[  +0.03]  [] __warn+0xcb/0xf0
[  +0.04]  [] warn_slowpath_fmt+0x5f/0x80
[  +0.02]  [] ? sysfs_warn_dup+0x6a/0x80
[  +0.03]  [] kobject_add_internal+0x2bd/0x330
[  +0.03]  [] ? vsnprintf+0x35b/0x4c0
[  +0.03]  [] kobject_add+0x75/0xd0
[  +0.03]  [] ? device_private_init+0x23/0x70
[  +0.04]  [] ? mutex_lock+0x12/0x30
[  +0.02]  [] device_add+0x119/0x670
[  +0.04]  [] device_create_groups_vargs+0xe0/0xf0
[  +0.03]  [] device_create_vargs+0x1c/0x20
[  +0.03]  [] bdi_register+0x8c/0x180
[  +0.03]  [] bdi_register_owner+0x36/0x60
[  +0.04]  [] device_add_disk+0x168/0x480
[  +0.03]  [] ? update_autosuspend+0x51/0x60
[  +0.02]  [] sd_probe_async+0x110/0x1c0
[  +0.02]  [] async_run_entry_fn+0x39/0x140
[  +0.02]  [] process_one_work+0x15f/0x430
[  +0.02]  [] worker_thread+0x4e/0x490
[  +0.02]  [] ? process_one_work+0x430/0x430
[  +0.03]  [] kthread+0xd9/0xf0
[  +0.03]  [] ? kthread_park+0x60/0x60
[  +0.03]  [] ret_from_fork+0x25/0x30
[  +0.000949] BUG: unable to handle kernel
[  +0.005263] NULL pointer dereference
[  +0.002853] IP: [] sysfs_do_create_link_sd.isra.2+0x34/0xb0
[  +0.008584] PGD 0

[  +0.006115] Oops:  [#1] SMP
[  +0.004531] Modules linked in: mptctl mptbase xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat  nf_conntrack tun bridge stp 
llc ebtable_filter ebtables ip6table_filter 

Re: [RFC 3/4] mm, page_alloc: move cpuset seqcount checking to slowpath

2017-01-17 Thread Hillf Danton
On Wednesday, January 18, 2017 6:16 AM Vlastimil Babka wrote: 
> 
> This is a preparation for the following patch to make review simpler. While
> the primary motivation is a bug fix, this could also save some cycles in the
> fast path.
> 
This also gets kswapd involved. 
Dunno how frequent cpuset is changed in real life.

Hillf



Re: [RFC 3/4] mm, page_alloc: move cpuset seqcount checking to slowpath

2017-01-17 Thread Hillf Danton
On Wednesday, January 18, 2017 6:16 AM Vlastimil Babka wrote: 
> 
> This is a preparation for the following patch to make review simpler. While
> the primary motivation is a bug fix, this could also save some cycles in the
> fast path.
> 
This also gets kswapd involved. 
Dunno how frequent cpuset is changed in real life.

Hillf



Re: [PATCH] printk: Correctly handle preemption in console_unlock()

2017-01-17 Thread Sergey Senozhatsky
On (01/18/17 14:45), Sergey Senozhatsky wrote:
[..]
> 
> there is a function that clears @console_may_schedule out of
> console_sem scope - console_flush_on_panic().
> so I *may be* can think about a worst case scenario of race
> condition between
>   console_flush_on_panic()->console_may_schedule = 0 on panic CPU
> and
>   console_unlock()->console_may_schedule = 1 from CPU that panic CPU
> failed to stop (smp_send_stop() can return with secondary CPUs still being
> online).

what I mean, is that we can have, let's say, 2 CPUs spinning in
console_unlock(), both with @console_may_schedule == 1 (because secondary
CPU restores global @console_may_schedule value). now, suppose, we have
misbehaving scheduler (well, we are in panic after all). secondary CPU
will cond_resched() and may be lockup somewhere in the scheduler. which is
fine, we don't care about that secondary CPU anyway. but the same can happen
to panic CPU as well.

what do you think?

-ss


Re: [PATCH] printk: Correctly handle preemption in console_unlock()

2017-01-17 Thread Sergey Senozhatsky
On (01/18/17 14:45), Sergey Senozhatsky wrote:
[..]
> 
> there is a function that clears @console_may_schedule out of
> console_sem scope - console_flush_on_panic().
> so I *may be* can think about a worst case scenario of race
> condition between
>   console_flush_on_panic()->console_may_schedule = 0 on panic CPU
> and
>   console_unlock()->console_may_schedule = 1 from CPU that panic CPU
> failed to stop (smp_send_stop() can return with secondary CPUs still being
> online).

what I mean, is that we can have, let's say, 2 CPUs spinning in
console_unlock(), both with @console_may_schedule == 1 (because secondary
CPU restores global @console_may_schedule value). now, suppose, we have
misbehaving scheduler (well, we are in panic after all). secondary CPU
will cond_resched() and may be lockup somewhere in the scheduler. which is
fine, we don't care about that secondary CPU anyway. but the same can happen
to panic CPU as well.

what do you think?

-ss


Re: mm, vmscan: commit makes PAE kernel crash nightly (bisected)

2017-01-17 Thread Trevor Cordes
On 2017-01-17 Michal Hocko wrote:
> On Tue 17-01-17 14:21:14, Mel Gorman wrote:
> > On Tue, Jan 17, 2017 at 02:52:28PM +0100, Michal Hocko wrote:  
> > > On Mon 16-01-17 11:09:34, Mel Gorman wrote:
> > > [...]  
> > > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > > index 532a2a750952..46aac487b89a 100644
> > > > --- a/mm/vmscan.c
> > > > +++ b/mm/vmscan.c
> > > > @@ -2684,6 +2684,7 @@ static void shrink_zones(struct zonelist
> > > > *zonelist, struct scan_control *sc) continue;
> > > >  
> > > > if (sc->priority != DEF_PRIORITY &&
> > > > +   !buffer_heads_over_limit &&
> > > > !pgdat_reclaimable(zone->zone_pgdat))
> > > > continue;   /* Let kswapd
> > > > poll it */  
> > > 
> > > I think we should rather remove pgdat_reclaimable here. This
> > > sounds like a wrong layer to decide whether we want to reclaim
> > > and how much. 
> > 
> > I had considered that but it'd also be important to add the other
> > 32-bit patches you have posted to see the impact. Because of the
> > ratio of LRU pages to slab pages, it may not have an impact but
> > it'd need to be eliminated.  
> 
> OK, Trevor you can pull from
> git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git tree
> fixes/highmem-node-fixes branch. This contains the current mmotm tree
> + the latest highmem fixes. I also do not expect this would help much
> in your case but as Mel've said we should rule that out at least.

OK, ignore my last question re: what to do next.  I am building
this mhocko git tree now per your above instructions and will reboot
into it in a few hours with*out* the cgroup_disable=memory option.
Might take ~50 hours for a result.

I should note that the workload on the box with the bug is mostly as a
file server and iptables firewall/router.  It routes around 8GB(ytes) a
day, and periodic file server loads.  That's about it.  Everything else
that is running is not doing much, and not using much RAM; except
maybe clamav, by far the biggest RAM.

I don't see this bug on other nearly identical boxes, including:
F24 4.8.15 32-bit (no PAE) 1GB ram P4
F24 4.8.15 32-bit (no PAE) 2GB ram Core2 Quad

However, just noticed for the first time today that one other box is
also seeing this bug (gets an oom message), though with much less
frequency: twice in 2 months since upgrading to 4.8.  However, it
recovers from the oom without a reboot and hasn't hanged (yet).  That
could be because this box does not do as much file serving or I/O as
the one I've been building/testing on. Also, this box is a much older
Pentium-D with 4GB (PAE on).  If it would be helpful to see its oom
log, let me know.  (Scanning all my boxes now, I also found 1 single oom
on yet another 1 computer with the same story; but this is a Xeon
E3-1220 32-bit with PAE, 4GB.)

So far the commonality seems to be >2GB RAM and PAE on.  Might be
interesting to boot my build/test box with mem=2G and isolate it to
small RAM vs PAE.  "mem=2G" would make a great, easy, immediate
workaround for this problem for me (as cgroup_disable=memory also seems
to do, so far).  Thanks!


Re: mm, vmscan: commit makes PAE kernel crash nightly (bisected)

2017-01-17 Thread Trevor Cordes
On 2017-01-17 Michal Hocko wrote:
> On Tue 17-01-17 14:21:14, Mel Gorman wrote:
> > On Tue, Jan 17, 2017 at 02:52:28PM +0100, Michal Hocko wrote:  
> > > On Mon 16-01-17 11:09:34, Mel Gorman wrote:
> > > [...]  
> > > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > > index 532a2a750952..46aac487b89a 100644
> > > > --- a/mm/vmscan.c
> > > > +++ b/mm/vmscan.c
> > > > @@ -2684,6 +2684,7 @@ static void shrink_zones(struct zonelist
> > > > *zonelist, struct scan_control *sc) continue;
> > > >  
> > > > if (sc->priority != DEF_PRIORITY &&
> > > > +   !buffer_heads_over_limit &&
> > > > !pgdat_reclaimable(zone->zone_pgdat))
> > > > continue;   /* Let kswapd
> > > > poll it */  
> > > 
> > > I think we should rather remove pgdat_reclaimable here. This
> > > sounds like a wrong layer to decide whether we want to reclaim
> > > and how much. 
> > 
> > I had considered that but it'd also be important to add the other
> > 32-bit patches you have posted to see the impact. Because of the
> > ratio of LRU pages to slab pages, it may not have an impact but
> > it'd need to be eliminated.  
> 
> OK, Trevor you can pull from
> git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git tree
> fixes/highmem-node-fixes branch. This contains the current mmotm tree
> + the latest highmem fixes. I also do not expect this would help much
> in your case but as Mel've said we should rule that out at least.

OK, ignore my last question re: what to do next.  I am building
this mhocko git tree now per your above instructions and will reboot
into it in a few hours with*out* the cgroup_disable=memory option.
Might take ~50 hours for a result.

I should note that the workload on the box with the bug is mostly as a
file server and iptables firewall/router.  It routes around 8GB(ytes) a
day, and periodic file server loads.  That's about it.  Everything else
that is running is not doing much, and not using much RAM; except
maybe clamav, by far the biggest RAM.

I don't see this bug on other nearly identical boxes, including:
F24 4.8.15 32-bit (no PAE) 1GB ram P4
F24 4.8.15 32-bit (no PAE) 2GB ram Core2 Quad

However, just noticed for the first time today that one other box is
also seeing this bug (gets an oom message), though with much less
frequency: twice in 2 months since upgrading to 4.8.  However, it
recovers from the oom without a reboot and hasn't hanged (yet).  That
could be because this box does not do as much file serving or I/O as
the one I've been building/testing on. Also, this box is a much older
Pentium-D with 4GB (PAE on).  If it would be helpful to see its oom
log, let me know.  (Scanning all my boxes now, I also found 1 single oom
on yet another 1 computer with the same story; but this is a Xeon
E3-1220 32-bit with PAE, 4GB.)

So far the commonality seems to be >2GB RAM and PAE on.  Might be
interesting to boot my build/test box with mem=2G and isolate it to
small RAM vs PAE.  "mem=2G" would make a great, easy, immediate
workaround for this problem for me (as cgroup_disable=memory also seems
to do, so far).  Thanks!


Re: [PATCH 12/13] pwm: jz4740: Let the pinctrl driver configure the pins

2017-01-17 Thread Thierry Reding
On Wed, Jan 18, 2017 at 12:14:20AM +0100, Paul Cercueil wrote:
> Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on
> the pins being properly configured before the driver probes.
> 
> One inherent problem of this new approach is that the pinctrl framework
> does not allow us to configure each pin on demand, when the various PWM
> channels are requested or released. For instance, the PWM channels can
> be configured from sysfs, which would require all PWM pins to be configured
> properly beforehand for the PWM function, eventually causing conflicts
> with other platform or board drivers.
> 
> The proper solution here would be to modify the pwm-jz4740 driver to
> handle only one PWM channel, and create an instance of this driver
> for each one of the 8 PWM channels. Then, it could use the pinctrl
> framework to dynamically configure the PWM pin it controls.
> 
> Until this can be done, the only jz4740 board supported upstream
> (Qi lb60) could configure all of its connected PWM pins in PWM function
> mode, if those are not used by other drivers nor by GPIOs on the
> board.
> 
> Signed-off-by: Paul Cercueil 
> ---
>  drivers/pwm/pwm-jz4740.c | 29 -
>  1 file changed, 29 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c
> index 76d13150283f..a75ff3622450 100644
> --- a/drivers/pwm/pwm-jz4740.c
> +++ b/drivers/pwm/pwm-jz4740.c
> @@ -21,22 +21,10 @@
>  #include 
>  #include 
>  
> -#include 

What about the linux/gpio.h header? It seems to me like that would be no
longer needed after this patch either.

Other than that this looks like the patch I'd expect if the pinmux was
configured statically, based on board design.

Thierry


signature.asc
Description: PGP signature


Re: [PATCH 12/13] pwm: jz4740: Let the pinctrl driver configure the pins

2017-01-17 Thread Thierry Reding
On Wed, Jan 18, 2017 at 12:14:20AM +0100, Paul Cercueil wrote:
> Now that the JZ4740 and similar SoCs have a pinctrl driver, we rely on
> the pins being properly configured before the driver probes.
> 
> One inherent problem of this new approach is that the pinctrl framework
> does not allow us to configure each pin on demand, when the various PWM
> channels are requested or released. For instance, the PWM channels can
> be configured from sysfs, which would require all PWM pins to be configured
> properly beforehand for the PWM function, eventually causing conflicts
> with other platform or board drivers.
> 
> The proper solution here would be to modify the pwm-jz4740 driver to
> handle only one PWM channel, and create an instance of this driver
> for each one of the 8 PWM channels. Then, it could use the pinctrl
> framework to dynamically configure the PWM pin it controls.
> 
> Until this can be done, the only jz4740 board supported upstream
> (Qi lb60) could configure all of its connected PWM pins in PWM function
> mode, if those are not used by other drivers nor by GPIOs on the
> board.
> 
> Signed-off-by: Paul Cercueil 
> ---
>  drivers/pwm/pwm-jz4740.c | 29 -
>  1 file changed, 29 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-jz4740.c b/drivers/pwm/pwm-jz4740.c
> index 76d13150283f..a75ff3622450 100644
> --- a/drivers/pwm/pwm-jz4740.c
> +++ b/drivers/pwm/pwm-jz4740.c
> @@ -21,22 +21,10 @@
>  #include 
>  #include 
>  
> -#include 

What about the linux/gpio.h header? It seems to me like that would be no
longer needed after this patch either.

Other than that this looks like the patch I'd expect if the pinmux was
configured statically, based on board design.

Thierry


signature.asc
Description: PGP signature


Re: [PATCH 13/13] MIPS: jz4740: Remove custom GPIO code

2017-01-17 Thread Thierry Reding
On Wed, Jan 18, 2017 at 12:14:21AM +0100, Paul Cercueil wrote:
> All the drivers for the various hardware elements of the jz4740 SoC have
> been modified to use the pinctrl framework for their pin configuration
> needs.
> As such, this platform code is now unused and can be deleted.
> 
> Signed-off-by: Paul Cercueil 
> ---
>  arch/mips/include/asm/mach-jz4740/gpio.h | 371 --
>  arch/mips/jz4740/Makefile|   2 -
>  arch/mips/jz4740/gpio.c  | 519 
> ---
>  3 files changed, 892 deletions(-)
>  delete mode 100644 arch/mips/jz4740/gpio.c

Have you considered how this could best be merged? It's probably easiest
to take all of this through the MIPS tree because we have an addition of
the pinctrl that would be a replacement for the GPIO code, while at the
same time a bunch of drivers rely on the JZ4740 GPIO code for successful
compilation.

That's slightly complicated by the number of drivers, so needs a lot of
coordination, but it's not the worst I've seen.

Maybe one other solution that would make the transition easier would be
to stub out the GPIO functions if the pinctrl driver is enabled, and do
the removal of the mach-jz4740/gpio.h after all drivers have been merged
through their corresponding subsystem trees. That way all drivers should
remain compilable and functional at runtime, while still having the
possibility to merge through the subsystem trees.

That said, the whole series is fairly simple, so merging everything
through the MIPS tree sounds like the easiest way to go.

Thierry


signature.asc
Description: PGP signature


Re: [PATCH 13/13] MIPS: jz4740: Remove custom GPIO code

2017-01-17 Thread Thierry Reding
On Wed, Jan 18, 2017 at 12:14:21AM +0100, Paul Cercueil wrote:
> All the drivers for the various hardware elements of the jz4740 SoC have
> been modified to use the pinctrl framework for their pin configuration
> needs.
> As such, this platform code is now unused and can be deleted.
> 
> Signed-off-by: Paul Cercueil 
> ---
>  arch/mips/include/asm/mach-jz4740/gpio.h | 371 --
>  arch/mips/jz4740/Makefile|   2 -
>  arch/mips/jz4740/gpio.c  | 519 
> ---
>  3 files changed, 892 deletions(-)
>  delete mode 100644 arch/mips/jz4740/gpio.c

Have you considered how this could best be merged? It's probably easiest
to take all of this through the MIPS tree because we have an addition of
the pinctrl that would be a replacement for the GPIO code, while at the
same time a bunch of drivers rely on the JZ4740 GPIO code for successful
compilation.

That's slightly complicated by the number of drivers, so needs a lot of
coordination, but it's not the worst I've seen.

Maybe one other solution that would make the transition easier would be
to stub out the GPIO functions if the pinctrl driver is enabled, and do
the removal of the mach-jz4740/gpio.h after all drivers have been merged
through their corresponding subsystem trees. That way all drivers should
remain compilable and functional at runtime, while still having the
possibility to merge through the subsystem trees.

That said, the whole series is fairly simple, so merging everything
through the MIPS tree sounds like the easiest way to go.

Thierry


signature.asc
Description: PGP signature


Re: [PATCH tip/core/rcu 11/20] sched,rcu: Make cond_resched() provide RCU quiescent state

2017-01-17 Thread Paul E. McKenney
On Tue, Jan 17, 2017 at 01:11:46PM +0100, Michal Hocko wrote:
> On Tue 17-01-17 04:05:13, Paul E. McKenney wrote:
> > On Tue, Jan 17, 2017 at 11:51:41AM +0100, Michal Hocko wrote:
> > > On Mon 16-01-17 16:54:03, Paul E. McKenney wrote:
> > > > On Mon, Jan 16, 2017 at 06:11:30PM +0100, Peter Zijlstra wrote:
> > > > > On Sat, Jan 14, 2017 at 01:13:12AM -0800, Paul E. McKenney wrote:
> > > > > > There is some confusion as to which of cond_resched() or
> > > > > > cond_resched_rcu_qs() should be added to long in-kernel loops.
> > > > > > This commit therefore eliminates the decision by adding RCU
> > > > > > quiescent states to cond_resched().
> > > > > 
> > > > > Which would make: rcu_read_lock(); cond_resched(); rcu_read_unlock();
> > > > > invalid under preemptible RCU. Is it already?
> > > > 
> > > > In theory, yes.  In practice, I just tested it with preemption and
> > > > lockdep enabled, and it didn't complain.  If further testing finds
> > > > complaints, we can either fix those uses (preferred) or revert
> > > > this patch.
> > > > 
> > > > > > Warning: This is a prototype.  For example, it does not correctly
> > > > > > handle Tasks RCU.  Which is OK for the moment, given that no one
> > > > > > actually uses Tasks RCU yet.
> > > > > 
> > > > > > --- a/kernel/sched/core.c
> > > > > > +++ b/kernel/sched/core.c
> > > > > > @@ -4907,6 +4907,7 @@ int __sched _cond_resched(void)
> > > > > > preempt_schedule_common();
> > > > > > return 1;
> > > > > > }
> > > > > > +   rcu_all_qs();
> > > > > > return 0;
> > > > > >  }
> > > > > 
> > > > > Still not a real fan of this, it does make cond_resched() touch a 
> > > > > bunch
> > > > > more cachelines, also, I suppose that if we're going to do this, we
> > > > > should make __cond_resched_lock() and __cond_resched_softirq() act
> > > > > similarly.
> > > > 
> > > > Michal (now CCed) argues that having to distinguish between 
> > > > cond_resched()
> > > > and cond_resched_rcu_qs() is overly burdensome.  Michal?
> > > 
> > > Yes, it is really not clear which one is meant to be in which context. I
> > > really do not see which cond_resched should be turned intto
> > > cond_resched_rcu_qs.
> > > 
> > > > Any thoughts on how we might remove this burden without the additional
> > > > cache misses?  I will take another look as well to see what could make
> > > > it lower cost.  There are probably ways...  Would it make sense to
> > > > have RCU maintain a need-rcu_all_qs() flage in the same cacheline as
> > > > the __preempt_count?  Perhaps throttling the writes to this flag from
> > > > the RCU grace-period kthreads to once per 100 milliseconds or so?
> > > 
> > > Can the stall detector simply request rescheduling when it gets
> > > dangerously close to the timeout?
> > 
> > It is quite possible that half of the stall timeout would be a better
> > choice than my 100 milliseconds, but either way, there would be need
> > for a flag or some such.
> 
> E.g. set_tsk_need_resched() on the task currently running on a cpu which
> is preventing the rcu grace period for too long?
> 
> That would only require change to the stall detector and the cond_resched
> could be left alone completely.

Thank you!!!

The other complication is that under CONFIG_PREEMPT=y, _cond_resched()
is an empty function.  That would be one reason why use of cond_resched()
wasn't always giving RCU the quiescent states that it needs.  And that
is a problem with this patch, which I therefore need to defer to 4.12.

That aside, the reason I am reluctant to use the need-resched approach
except as an emergency measure is that the way I have to set that bit
remotely involves IPIs.

But don't get me wrong, it is extremely useful as an emergency meaure.
I am just trying to get cond_resched() to help on a non-emergency basis.

Thanx, Paul



Re: [PATCH tip/core/rcu 11/20] sched,rcu: Make cond_resched() provide RCU quiescent state

2017-01-17 Thread Paul E. McKenney
On Tue, Jan 17, 2017 at 01:11:46PM +0100, Michal Hocko wrote:
> On Tue 17-01-17 04:05:13, Paul E. McKenney wrote:
> > On Tue, Jan 17, 2017 at 11:51:41AM +0100, Michal Hocko wrote:
> > > On Mon 16-01-17 16:54:03, Paul E. McKenney wrote:
> > > > On Mon, Jan 16, 2017 at 06:11:30PM +0100, Peter Zijlstra wrote:
> > > > > On Sat, Jan 14, 2017 at 01:13:12AM -0800, Paul E. McKenney wrote:
> > > > > > There is some confusion as to which of cond_resched() or
> > > > > > cond_resched_rcu_qs() should be added to long in-kernel loops.
> > > > > > This commit therefore eliminates the decision by adding RCU
> > > > > > quiescent states to cond_resched().
> > > > > 
> > > > > Which would make: rcu_read_lock(); cond_resched(); rcu_read_unlock();
> > > > > invalid under preemptible RCU. Is it already?
> > > > 
> > > > In theory, yes.  In practice, I just tested it with preemption and
> > > > lockdep enabled, and it didn't complain.  If further testing finds
> > > > complaints, we can either fix those uses (preferred) or revert
> > > > this patch.
> > > > 
> > > > > > Warning: This is a prototype.  For example, it does not correctly
> > > > > > handle Tasks RCU.  Which is OK for the moment, given that no one
> > > > > > actually uses Tasks RCU yet.
> > > > > 
> > > > > > --- a/kernel/sched/core.c
> > > > > > +++ b/kernel/sched/core.c
> > > > > > @@ -4907,6 +4907,7 @@ int __sched _cond_resched(void)
> > > > > > preempt_schedule_common();
> > > > > > return 1;
> > > > > > }
> > > > > > +   rcu_all_qs();
> > > > > > return 0;
> > > > > >  }
> > > > > 
> > > > > Still not a real fan of this, it does make cond_resched() touch a 
> > > > > bunch
> > > > > more cachelines, also, I suppose that if we're going to do this, we
> > > > > should make __cond_resched_lock() and __cond_resched_softirq() act
> > > > > similarly.
> > > > 
> > > > Michal (now CCed) argues that having to distinguish between 
> > > > cond_resched()
> > > > and cond_resched_rcu_qs() is overly burdensome.  Michal?
> > > 
> > > Yes, it is really not clear which one is meant to be in which context. I
> > > really do not see which cond_resched should be turned intto
> > > cond_resched_rcu_qs.
> > > 
> > > > Any thoughts on how we might remove this burden without the additional
> > > > cache misses?  I will take another look as well to see what could make
> > > > it lower cost.  There are probably ways...  Would it make sense to
> > > > have RCU maintain a need-rcu_all_qs() flage in the same cacheline as
> > > > the __preempt_count?  Perhaps throttling the writes to this flag from
> > > > the RCU grace-period kthreads to once per 100 milliseconds or so?
> > > 
> > > Can the stall detector simply request rescheduling when it gets
> > > dangerously close to the timeout?
> > 
> > It is quite possible that half of the stall timeout would be a better
> > choice than my 100 milliseconds, but either way, there would be need
> > for a flag or some such.
> 
> E.g. set_tsk_need_resched() on the task currently running on a cpu which
> is preventing the rcu grace period for too long?
> 
> That would only require change to the stall detector and the cond_resched
> could be left alone completely.

Thank you!!!

The other complication is that under CONFIG_PREEMPT=y, _cond_resched()
is an empty function.  That would be one reason why use of cond_resched()
wasn't always giving RCU the quiescent states that it needs.  And that
is a problem with this patch, which I therefore need to defer to 4.12.

That aside, the reason I am reluctant to use the need-resched approach
except as an emergency measure is that the way I have to set that bit
remotely involves IPIs.

But don't get me wrong, it is extremely useful as an emergency meaure.
I am just trying to get cond_resched() to help on a non-emergency basis.

Thanx, Paul



Re: [PATCH 00/13] Ingenic JZ4740 / JZ4780 pinctrl driver

2017-01-17 Thread Thierry Reding
On Wed, Jan 18, 2017 at 12:14:08AM +0100, Paul Cercueil wrote:
[...]
> One problem still unresolved: the pinctrl framework does not allow us to
> configure each pin on demand (someone please prove me wrong), when the
> various PWM channels are requested or released. For instance, the PWM
> channels can be configured from sysfs, which would require all PWM pins
> to be configured properly beforehand for the PWM function, eventually
> causing conflicts with other platform or board drivers.

Still catching up on a lot of email, so I haven't gone through the
entire series. But I don't think the above is true.

My understanding is that you can have separate pin groups for each
pin (provided the hardware supports that) and then control each of
these groups dynamically at runtime.

That is you could have the PWM driver's ->request() and ->free()
call into the pinctrl framework to select the correct pinmux
configuration as necessary.

> The proper solution here would be to modify the pwm-jz4740 driver to
> handle only one PWM channel, and create an instance of this driver
> for each one of the 8 PWM channels. Then, it could use the pinctrl
> framework to dynamically configure the PWM pin it controls.

That could probably work. From only looking at the JZ4740 PWM driver
there's no separate IP block to deal with the PWM outputs, but they are
merely GPIOs controller via a timer, so one instance per GPIO seems like
a fine solution to me.

> Until this can be done, the only jz4740 board supported upstream
> (Qi lb60) could configure all of its connected PWM pins in PWM function
> mode, if those are not used by other drivers nor by GPIOs on the
> board. The only jz4780 board upstream (CI20) does not yet support the
> PWM driver.

Typically all of the pinmux is pre-determined by the board design. That
is if you've got 8 pins that can be driven by a PWM signal, not all of
those might be exposed by the design. If, say, only 0-4 and 6 expose the
PWM signal while 5 and 7 expose a different function then you can simply
use a static pinmux configuration and ignore PWMs 5 and 7. Even if
someone were to configure them, the signal would simply go nowhere.

Of course you'd have to check that your hardware actually matches those
assumptions. They certainly apply to many SoCs that I've come across.

Thierry


signature.asc
Description: PGP signature


Re: [PATCH] arm64: dts: exynos: Remove address node from usb parent node

2017-01-17 Thread Chanwoo Choi
Hi Pankaj,

This issue already posted by Javier Martinez Canillas[1].
Maybe, he will post v2.

[1] https://lkml.org/lkml/2017/1/10/907
- ("Re: [PATCH v2 3/3] arm64: dts: exynos: Remove unneeded unit names in 
Exynos5433 nodes")

On 2017년 01월 18일 14:46, Pankaj Dubey wrote:
> Address node does not required to be put after parent't node,
> so remove address node from usb parent node.
> 
> Signed-off-by: Pankaj Dubey 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index 68f764e..0d7a55d 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -1285,7 +1285,7 @@
>   status = "disabled";
>   };
>  
> - usbdrd30: usb@1540  {
> + usbdrd30: usb3-0 {
>   compatible = "samsung,exynos5250-dwusb3";
>   clocks = <_fsys CLK_ACLK_USBDRD30>,
>   <_fsys CLK_SCLK_USBDRD30>;
> @@ -1332,7 +1332,7 @@
>   status = "disabled";
>   };
>  
> - usbhost30: usb@15a0 {
> + usbhost30: usbhost3-0 {
>   compatible = "samsung,exynos5250-dwusb3";
>   clocks = <_fsys CLK_ACLK_USBHOST30>,
>   <_fsys CLK_SCLK_USBHOST30>;
> 


-- 
Best Regards,
Chanwoo Choi
S/W Center, Samsung Electronics


Re: [PATCH 00/13] Ingenic JZ4740 / JZ4780 pinctrl driver

2017-01-17 Thread Thierry Reding
On Wed, Jan 18, 2017 at 12:14:08AM +0100, Paul Cercueil wrote:
[...]
> One problem still unresolved: the pinctrl framework does not allow us to
> configure each pin on demand (someone please prove me wrong), when the
> various PWM channels are requested or released. For instance, the PWM
> channels can be configured from sysfs, which would require all PWM pins
> to be configured properly beforehand for the PWM function, eventually
> causing conflicts with other platform or board drivers.

Still catching up on a lot of email, so I haven't gone through the
entire series. But I don't think the above is true.

My understanding is that you can have separate pin groups for each
pin (provided the hardware supports that) and then control each of
these groups dynamically at runtime.

That is you could have the PWM driver's ->request() and ->free()
call into the pinctrl framework to select the correct pinmux
configuration as necessary.

> The proper solution here would be to modify the pwm-jz4740 driver to
> handle only one PWM channel, and create an instance of this driver
> for each one of the 8 PWM channels. Then, it could use the pinctrl
> framework to dynamically configure the PWM pin it controls.

That could probably work. From only looking at the JZ4740 PWM driver
there's no separate IP block to deal with the PWM outputs, but they are
merely GPIOs controller via a timer, so one instance per GPIO seems like
a fine solution to me.

> Until this can be done, the only jz4740 board supported upstream
> (Qi lb60) could configure all of its connected PWM pins in PWM function
> mode, if those are not used by other drivers nor by GPIOs on the
> board. The only jz4780 board upstream (CI20) does not yet support the
> PWM driver.

Typically all of the pinmux is pre-determined by the board design. That
is if you've got 8 pins that can be driven by a PWM signal, not all of
those might be exposed by the design. If, say, only 0-4 and 6 expose the
PWM signal while 5 and 7 expose a different function then you can simply
use a static pinmux configuration and ignore PWMs 5 and 7. Even if
someone were to configure them, the signal would simply go nowhere.

Of course you'd have to check that your hardware actually matches those
assumptions. They certainly apply to many SoCs that I've come across.

Thierry


signature.asc
Description: PGP signature


Re: [PATCH] arm64: dts: exynos: Remove address node from usb parent node

2017-01-17 Thread Chanwoo Choi
Hi Pankaj,

This issue already posted by Javier Martinez Canillas[1].
Maybe, he will post v2.

[1] https://lkml.org/lkml/2017/1/10/907
- ("Re: [PATCH v2 3/3] arm64: dts: exynos: Remove unneeded unit names in 
Exynos5433 nodes")

On 2017년 01월 18일 14:46, Pankaj Dubey wrote:
> Address node does not required to be put after parent't node,
> so remove address node from usb parent node.
> 
> Signed-off-by: Pankaj Dubey 
> ---
>  arch/arm64/boot/dts/exynos/exynos5433.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index 68f764e..0d7a55d 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -1285,7 +1285,7 @@
>   status = "disabled";
>   };
>  
> - usbdrd30: usb@1540  {
> + usbdrd30: usb3-0 {
>   compatible = "samsung,exynos5250-dwusb3";
>   clocks = <_fsys CLK_ACLK_USBDRD30>,
>   <_fsys CLK_SCLK_USBDRD30>;
> @@ -1332,7 +1332,7 @@
>   status = "disabled";
>   };
>  
> - usbhost30: usb@15a0 {
> + usbhost30: usbhost3-0 {
>   compatible = "samsung,exynos5250-dwusb3";
>   clocks = <_fsys CLK_ACLK_USBHOST30>,
>   <_fsys CLK_SCLK_USBHOST30>;
> 


-- 
Best Regards,
Chanwoo Choi
S/W Center, Samsung Electronics


Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()

2017-01-17 Thread Greg KH
On Mon, Jan 16, 2017 at 12:01:02PM -0800, Florian Fainelli wrote:
> On 01/15/2017 11:16 AM, Andrew Lunn wrote:
> >>> What exactly is the relationship between these devices (a ascii-art tree
> >>> or sysfs tree output might be nice) so I can try to understand what is
> >>> going on here.
> > 
> > Hi Greg, Florian
> > 
> > A few diagrams and trees which might help understand what is going on.
> > 
> > The first diagram comes from the 2008 patch which added all this code:
> > 
> > +---+   +---+
> > |   | RGMII |   |
> > |   +---+   +-- 1000baseT MDI ("WAN")
> > |   |   |  6-port   +-- 1000baseT MDI ("LAN1")
> > |CPU|   |  ethernet +-- 1000baseT MDI ("LAN2")
> > |   |MIImgmt|  switch   +-- 1000baseT MDI ("LAN3")
> > |   +---+  w/5 PHYs +-- 1000baseT MDI ("LAN4")
> > |   |   |   |
> > +---+   +---+
> > 
> > We have an ethernet switch and a host CPU. The switch is connected to
> > the CPU in two different ways. RGMII allows us to get Ethernet frames
> > from the CPU into the switch. MIImgmt, is the management bus normally
> > used for Ethernet PHYs, but Marvell switches also use it for Managing
> > switches.
> > 
> > The diagram above is the simplest setup. You can have multiple
> > Ethernet switches, connected together via switch ports. Each switch
> > has its own MIImgmt connect to the CPU, but there is only one RGMII
> > link.
> > 
> > When this code was designed back in 2008, it was decided to represent
> > this is a platform device, and it has a platform_data, which i have
> > slightly edited to keep it simple:
> > 
> > struct dsa_platform_data {
> > /*
> >  * Reference to a Linux network interface that connects
> >  * to the root switch chip of the tree.
> >  */
> > struct device   *netdev;
> > 
> > /*
> >  * Info structs describing each of the switch chips
> >  * connected via this network interface.
> >  */
> > int nr_chips;
> > struct dsa_chip_data*chip;
> > };
> > 
> > This netdev is the CPU side of the RGMII interface.
> > 
> > Each switch has a dsa_chip_data, again edited:
> > 
> > struct dsa_chip_data {
> > /*
> >  * How to access the switch configuration registers.
> >  */
> > struct device   *host_dev;
> > int sw_addr;
> > ...
> > }
> > 
> > The host_dev is the CPU side of the MIImgmt, and we have the address
> > the switch is using on the bus.
> > 
> > During probe of this platform device, we need to get from the
> > struct device *netdev to a struct net_device *dev.
> > 
> > So the code looks in the device net class to find the device
> > 
> > |   |   |   |-- f1074000.ethernet
> > |   |   |   |   |-- deferred_probe
> > |   |   |   |   |-- driver -> ../../../../../bus/platform/drivers/mvneta
> > |   |   |   |   |-- driver_override
> > |   |   |   |   |-- modalias
> > |   |   |   |   |-- net
> > |   |   |   |   |   `-- eth1
> > |   |   |   |   |   |-- addr_assign_type
> > |   |   |   |   |   |-- address
> > |   |   |   |   |   |-- addr_len
> > |   |   |   |   |   |-- broadcast
> > |   |   |   |   |   |-- carrier
> > |   |   |   |   |   |-- carrier_changes
> > |   |   |   |   |   |-- deferred_probe
> > |   |   |   |   |   |-- device -> ../../../f1074000.ethernet
> > 
> > and then use container_of() to get the net_device.
> > 
> > Similarly, the code needs to get from struct device *host_dev to a struct 
> > mii_bus *.
> > 
> > |   |   |   |-- f1072004.mdio
> > |   |   |   |   |-- deferred_probe
> > |   |   |   |   |-- driver -> ../../../../../bus/platform/drivers/orion-mdio
> > |   |   |   |   |-- driver_override
> > |   |   |   |   |-- mdio_bus
> > |   |   |   |   |   `-- f1072004.mdio-mi
> > |   |   |   |   |   |-- deferred_probe
> > |   |   |   |   |   |-- device -> ../../../f1072004.mdio
> > 
> 
> Thanks Andrew! Greg, does that make it clearer how these devices
> references are used, do you still think the way this is done is wrong,
> too cautious, or valid?

I'm still not sold on it, I think there is something odd here with your
use/assumptions of the driver model.  Give me a few days to catch up
with other stuff to respond back please...

thanks,

greg k-h


Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()

2017-01-17 Thread Greg KH
On Mon, Jan 16, 2017 at 12:01:02PM -0800, Florian Fainelli wrote:
> On 01/15/2017 11:16 AM, Andrew Lunn wrote:
> >>> What exactly is the relationship between these devices (a ascii-art tree
> >>> or sysfs tree output might be nice) so I can try to understand what is
> >>> going on here.
> > 
> > Hi Greg, Florian
> > 
> > A few diagrams and trees which might help understand what is going on.
> > 
> > The first diagram comes from the 2008 patch which added all this code:
> > 
> > +---+   +---+
> > |   | RGMII |   |
> > |   +---+   +-- 1000baseT MDI ("WAN")
> > |   |   |  6-port   +-- 1000baseT MDI ("LAN1")
> > |CPU|   |  ethernet +-- 1000baseT MDI ("LAN2")
> > |   |MIImgmt|  switch   +-- 1000baseT MDI ("LAN3")
> > |   +---+  w/5 PHYs +-- 1000baseT MDI ("LAN4")
> > |   |   |   |
> > +---+   +---+
> > 
> > We have an ethernet switch and a host CPU. The switch is connected to
> > the CPU in two different ways. RGMII allows us to get Ethernet frames
> > from the CPU into the switch. MIImgmt, is the management bus normally
> > used for Ethernet PHYs, but Marvell switches also use it for Managing
> > switches.
> > 
> > The diagram above is the simplest setup. You can have multiple
> > Ethernet switches, connected together via switch ports. Each switch
> > has its own MIImgmt connect to the CPU, but there is only one RGMII
> > link.
> > 
> > When this code was designed back in 2008, it was decided to represent
> > this is a platform device, and it has a platform_data, which i have
> > slightly edited to keep it simple:
> > 
> > struct dsa_platform_data {
> > /*
> >  * Reference to a Linux network interface that connects
> >  * to the root switch chip of the tree.
> >  */
> > struct device   *netdev;
> > 
> > /*
> >  * Info structs describing each of the switch chips
> >  * connected via this network interface.
> >  */
> > int nr_chips;
> > struct dsa_chip_data*chip;
> > };
> > 
> > This netdev is the CPU side of the RGMII interface.
> > 
> > Each switch has a dsa_chip_data, again edited:
> > 
> > struct dsa_chip_data {
> > /*
> >  * How to access the switch configuration registers.
> >  */
> > struct device   *host_dev;
> > int sw_addr;
> > ...
> > }
> > 
> > The host_dev is the CPU side of the MIImgmt, and we have the address
> > the switch is using on the bus.
> > 
> > During probe of this platform device, we need to get from the
> > struct device *netdev to a struct net_device *dev.
> > 
> > So the code looks in the device net class to find the device
> > 
> > |   |   |   |-- f1074000.ethernet
> > |   |   |   |   |-- deferred_probe
> > |   |   |   |   |-- driver -> ../../../../../bus/platform/drivers/mvneta
> > |   |   |   |   |-- driver_override
> > |   |   |   |   |-- modalias
> > |   |   |   |   |-- net
> > |   |   |   |   |   `-- eth1
> > |   |   |   |   |   |-- addr_assign_type
> > |   |   |   |   |   |-- address
> > |   |   |   |   |   |-- addr_len
> > |   |   |   |   |   |-- broadcast
> > |   |   |   |   |   |-- carrier
> > |   |   |   |   |   |-- carrier_changes
> > |   |   |   |   |   |-- deferred_probe
> > |   |   |   |   |   |-- device -> ../../../f1074000.ethernet
> > 
> > and then use container_of() to get the net_device.
> > 
> > Similarly, the code needs to get from struct device *host_dev to a struct 
> > mii_bus *.
> > 
> > |   |   |   |-- f1072004.mdio
> > |   |   |   |   |-- deferred_probe
> > |   |   |   |   |-- driver -> ../../../../../bus/platform/drivers/orion-mdio
> > |   |   |   |   |-- driver_override
> > |   |   |   |   |-- mdio_bus
> > |   |   |   |   |   `-- f1072004.mdio-mi
> > |   |   |   |   |   |-- deferred_probe
> > |   |   |   |   |   |-- device -> ../../../f1072004.mdio
> > 
> 
> Thanks Andrew! Greg, does that make it clearer how these devices
> references are used, do you still think the way this is done is wrong,
> too cautious, or valid?

I'm still not sold on it, I think there is something odd here with your
use/assumptions of the driver model.  Give me a few days to catch up
with other stuff to respond back please...

thanks,

greg k-h


Re: [PATCH net-next v4 05/10] drivers: base: Add device_find_in_class_name()

2017-01-17 Thread Greg Kroah-Hartman
On Tue, Jan 17, 2017 at 03:21:47PM -0800, Florian Fainelli wrote:
> Add a helper function to lookup a device reference given a class name.
> This is a preliminary patch to remove adhoc code from net/dsa/dsa.c and
> make it more generic.
> 
> Signed-off-by: Florian Fainelli 
> ---
>  drivers/base/core.c| 31 +++
>  include/linux/device.h |  2 ++
>  2 files changed, 33 insertions(+)

My NAK still stands here, please give me a day or so to respond to the
other thread about this...

thanks,

greg k-h


Re: [PATCH net-next v4 05/10] drivers: base: Add device_find_in_class_name()

2017-01-17 Thread Greg Kroah-Hartman
On Tue, Jan 17, 2017 at 03:21:47PM -0800, Florian Fainelli wrote:
> Add a helper function to lookup a device reference given a class name.
> This is a preliminary patch to remove adhoc code from net/dsa/dsa.c and
> make it more generic.
> 
> Signed-off-by: Florian Fainelli 
> ---
>  drivers/base/core.c| 31 +++
>  include/linux/device.h |  2 ++
>  2 files changed, 33 insertions(+)

My NAK still stands here, please give me a day or so to respond to the
other thread about this...

thanks,

greg k-h


Re: [RFC 4/4] mm, page_alloc: fix premature OOM when racing with cpuset mems update

2017-01-17 Thread Hillf Danton

On Wednesday, January 18, 2017 6:16 AM Vlastimil Babka wrote: 
> 
> @@ -3802,13 +3811,8 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int 
> order,
>* Also recalculate the starting point for the zonelist iterator or
>* we could end up iterating over non-eligible zones endlessly.
>*/
Is the newly added comment still needed?

> - if (unlikely(ac.nodemask != nodemask)) {
> -no_zone:
> + if (unlikely(ac.nodemask != nodemask))
>   ac.nodemask = nodemask;
> - ac.preferred_zoneref = first_zones_zonelist(ac.zonelist,
> - ac.high_zoneidx, ac.nodemask);
> - /* If we have NULL preferred zone, slowpath wll handle that */
> - }
> 
>   page = __alloc_pages_slowpath(alloc_mask, order, );
> 
> --
> 2.11.0



Re: [RFC 4/4] mm, page_alloc: fix premature OOM when racing with cpuset mems update

2017-01-17 Thread Hillf Danton

On Wednesday, January 18, 2017 6:16 AM Vlastimil Babka wrote: 
> 
> @@ -3802,13 +3811,8 @@ __alloc_pages_nodemask(gfp_t gfp_mask, unsigned int 
> order,
>* Also recalculate the starting point for the zonelist iterator or
>* we could end up iterating over non-eligible zones endlessly.
>*/
Is the newly added comment still needed?

> - if (unlikely(ac.nodemask != nodemask)) {
> -no_zone:
> + if (unlikely(ac.nodemask != nodemask))
>   ac.nodemask = nodemask;
> - ac.preferred_zoneref = first_zones_zonelist(ac.zonelist,
> - ac.high_zoneidx, ac.nodemask);
> - /* If we have NULL preferred zone, slowpath wll handle that */
> - }
> 
>   page = __alloc_pages_slowpath(alloc_mask, order, );
> 
> --
> 2.11.0



Re: [linux-sunxi] Re: [PATCH] ASoC: sunxi: Add bindings for sun8i to SPDIF

2017-01-17 Thread Code Kipper
On 17 January 2017 at 19:15, Mark Brown  wrote:
> On Thu, Jan 12, 2017 at 06:33:43PM +0100, codekip...@gmail.com wrote:
>> From: Marcus Cooper 
>>
>> The H3 SoC uses the same SPDIF block as found in earlier SoCs, but the
>> transmit fifo is at a different address.
>>
>> Signed-off-by: Marcus Cooper 
>> ---
>>  Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt | 1 +
>>  1 file changed, 1 insertion(+)
>
> This is fine but it doesn't actually add the compatible string to the
> driver which I'd expect.
Hi Mark,
I missed the binding documentation on the patch for the driver so I
pushed it separately instead of pushing a new patch version.
You can find it under the subject heading 'ASoC: sun4i-spdif: Add
support for the H3 SoC' and Maxime has ACK it (on the condition that I
add the binding doc).
BR,
CK
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


Re: [linux-sunxi] Re: [PATCH] ASoC: sunxi: Add bindings for sun8i to SPDIF

2017-01-17 Thread Code Kipper
On 17 January 2017 at 19:15, Mark Brown  wrote:
> On Thu, Jan 12, 2017 at 06:33:43PM +0100, codekip...@gmail.com wrote:
>> From: Marcus Cooper 
>>
>> The H3 SoC uses the same SPDIF block as found in earlier SoCs, but the
>> transmit fifo is at a different address.
>>
>> Signed-off-by: Marcus Cooper 
>> ---
>>  Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt | 1 +
>>  1 file changed, 1 insertion(+)
>
> This is fine but it doesn't actually add the compatible string to the
> driver which I'd expect.
Hi Mark,
I missed the binding documentation on the patch for the driver so I
pushed it separately instead of pushing a new patch version.
You can find it under the subject heading 'ASoC: sun4i-spdif: Add
support for the H3 SoC' and Maxime has ACK it (on the condition that I
add the binding doc).
BR,
CK
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.


Re: mm, vmscan: commit makes PAE kernel crash nightly (bisected)

2017-01-17 Thread Trevor Cordes
On 2017-01-16 Mel Gorman wrote:
> > > You can easily check whether this is memcg related by trying to
> > > run the same workload with cgroup_disable=memory kernel command
> > > line parameter. This will put all the memcg specifics out of the
> > > way.  
> > 
> > I will try booting now into cgroup_disable=memory to see if that
> > helps at all.  I'll reply back in 48 hours, or when it oom's,
> > whichever comes first.
> >   
> 
> Thanks.

It has successfully survived 70 hours and 2 3am cycles (when it
normally oom's) with your first patch *and* cgroup_disable=memory
grafted on Fedora's 4.8.13.  Since it has never survived 2 3am cycles,
I strongly suspect the cgroup_disable=memory mitigates my bug.

> > Also, should I bother trying the latest git HEAD to see if that
> > solves anything?  Thanks!  
> 
> That's worth trying. If that also fails then could you try the
> following hack to encourage direct reclaim to reclaim slab when
> buffers are over the limit please?
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 532a2a750952..46aac487b89a 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2684,6 +2684,7 @@ static void shrink_zones(struct zonelist
> *zonelist, struct scan_control *sc) continue;
>  
>   if (sc->priority != DEF_PRIORITY &&
> + !buffer_heads_over_limit &&
>   !pgdat_reclaimable(zone->zone_pgdat))
>   continue;   /* Let kswapd poll
> it */ 

What's the next best step?  HEAD?  HEAD + the above patch?  A new
patch?  I'll start a HEAD compile until I hear more.  I assume I should
test without cgroup_disable=memory as that's just a kludge/workaround,
right?

Also, is there a way to spot the slab pressure you are talking about
before oom's occur?  slabinfo?  I suppose I'd be able to see some
counter slowly getting too high or low?  Thanks!


Re: mm, vmscan: commit makes PAE kernel crash nightly (bisected)

2017-01-17 Thread Trevor Cordes
On 2017-01-16 Mel Gorman wrote:
> > > You can easily check whether this is memcg related by trying to
> > > run the same workload with cgroup_disable=memory kernel command
> > > line parameter. This will put all the memcg specifics out of the
> > > way.  
> > 
> > I will try booting now into cgroup_disable=memory to see if that
> > helps at all.  I'll reply back in 48 hours, or when it oom's,
> > whichever comes first.
> >   
> 
> Thanks.

It has successfully survived 70 hours and 2 3am cycles (when it
normally oom's) with your first patch *and* cgroup_disable=memory
grafted on Fedora's 4.8.13.  Since it has never survived 2 3am cycles,
I strongly suspect the cgroup_disable=memory mitigates my bug.

> > Also, should I bother trying the latest git HEAD to see if that
> > solves anything?  Thanks!  
> 
> That's worth trying. If that also fails then could you try the
> following hack to encourage direct reclaim to reclaim slab when
> buffers are over the limit please?
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 532a2a750952..46aac487b89a 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2684,6 +2684,7 @@ static void shrink_zones(struct zonelist
> *zonelist, struct scan_control *sc) continue;
>  
>   if (sc->priority != DEF_PRIORITY &&
> + !buffer_heads_over_limit &&
>   !pgdat_reclaimable(zone->zone_pgdat))
>   continue;   /* Let kswapd poll
> it */ 

What's the next best step?  HEAD?  HEAD + the above patch?  A new
patch?  I'll start a HEAD compile until I hear more.  I assume I should
test without cgroup_disable=memory as that's just a kludge/workaround,
right?

Also, is there a way to spot the slab pressure you are talking about
before oom's occur?  slabinfo?  I suppose I'd be able to see some
counter slowly getting too high or low?  Thanks!


[PATCH 2/3] PM / devfreq: Fix wrong trans_stat of passive devfreq device

2017-01-17 Thread Chanwoo Choi
Until now, the trans_stat information of passive devfreq is not updated.
This patch updates the trans_stat information after setting the target
frequency of passive devfreq device.

Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
Cc: sta...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
---
 drivers/devfreq/devfreq.c  | 3 ++-
 drivers/devfreq/governor.h | 2 ++
 drivers/devfreq/governor_passive.c | 5 +
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index a2c575a5a9ab..6c560af2a801 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -135,7 +135,7 @@ static void devfreq_set_freq_table(struct devfreq *devfreq)
  * @devfreq:   the devfreq instance
  * @freq:  the update target frequency
  */
-static int devfreq_update_status(struct devfreq *devfreq, unsigned long freq)
+int devfreq_update_status(struct devfreq *devfreq, unsigned long freq)
 {
int lev, prev_lev, ret = 0;
unsigned long cur_time;
@@ -171,6 +171,7 @@ static int devfreq_update_status(struct devfreq *devfreq, 
unsigned long freq)
devfreq->last_stat_updated = cur_time;
return ret;
 }
+EXPORT_SYMBOL(devfreq_update_status);
 
 /**
  * find_devfreq_governor() - find devfreq governor from name
diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
index fad7d6321978..71576b8bdfef 100644
--- a/drivers/devfreq/governor.h
+++ b/drivers/devfreq/governor.h
@@ -38,4 +38,6 @@ extern void devfreq_interval_update(struct devfreq *devfreq,
 extern int devfreq_add_governor(struct devfreq_governor *governor);
 extern int devfreq_remove_governor(struct devfreq_governor *governor);
 
+extern int devfreq_update_status(struct devfreq *devfreq, unsigned long freq);
+
 #endif /* _GOVERNOR_H */
diff --git a/drivers/devfreq/governor_passive.c 
b/drivers/devfreq/governor_passive.c
index 9ef46e2592c4..443be65f4561 100644
--- a/drivers/devfreq/governor_passive.c
+++ b/drivers/devfreq/governor_passive.c
@@ -112,6 +112,11 @@ static int update_devfreq_passive(struct devfreq *devfreq, 
unsigned long freq)
if (ret < 0)
goto out;
 
+   if (devfreq->profile->freq_table
+   && (devfreq_update_status(devfreq, freq)))
+   dev_err(>dev,
+   "Couldn't update frequency transition information.\n");
+
devfreq->previous_freq = freq;
 
 out:
-- 
1.9.1



[PATCH 2/3] PM / devfreq: Fix wrong trans_stat of passive devfreq device

2017-01-17 Thread Chanwoo Choi
Until now, the trans_stat information of passive devfreq is not updated.
This patch updates the trans_stat information after setting the target
frequency of passive devfreq device.

Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
Cc: sta...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
---
 drivers/devfreq/devfreq.c  | 3 ++-
 drivers/devfreq/governor.h | 2 ++
 drivers/devfreq/governor_passive.c | 5 +
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index a2c575a5a9ab..6c560af2a801 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -135,7 +135,7 @@ static void devfreq_set_freq_table(struct devfreq *devfreq)
  * @devfreq:   the devfreq instance
  * @freq:  the update target frequency
  */
-static int devfreq_update_status(struct devfreq *devfreq, unsigned long freq)
+int devfreq_update_status(struct devfreq *devfreq, unsigned long freq)
 {
int lev, prev_lev, ret = 0;
unsigned long cur_time;
@@ -171,6 +171,7 @@ static int devfreq_update_status(struct devfreq *devfreq, 
unsigned long freq)
devfreq->last_stat_updated = cur_time;
return ret;
 }
+EXPORT_SYMBOL(devfreq_update_status);
 
 /**
  * find_devfreq_governor() - find devfreq governor from name
diff --git a/drivers/devfreq/governor.h b/drivers/devfreq/governor.h
index fad7d6321978..71576b8bdfef 100644
--- a/drivers/devfreq/governor.h
+++ b/drivers/devfreq/governor.h
@@ -38,4 +38,6 @@ extern void devfreq_interval_update(struct devfreq *devfreq,
 extern int devfreq_add_governor(struct devfreq_governor *governor);
 extern int devfreq_remove_governor(struct devfreq_governor *governor);
 
+extern int devfreq_update_status(struct devfreq *devfreq, unsigned long freq);
+
 #endif /* _GOVERNOR_H */
diff --git a/drivers/devfreq/governor_passive.c 
b/drivers/devfreq/governor_passive.c
index 9ef46e2592c4..443be65f4561 100644
--- a/drivers/devfreq/governor_passive.c
+++ b/drivers/devfreq/governor_passive.c
@@ -112,6 +112,11 @@ static int update_devfreq_passive(struct devfreq *devfreq, 
unsigned long freq)
if (ret < 0)
goto out;
 
+   if (devfreq->profile->freq_table
+   && (devfreq_update_status(devfreq, freq)))
+   dev_err(>dev,
+   "Couldn't update frequency transition information.\n");
+
devfreq->previous_freq = freq;
 
 out:
-- 
1.9.1



[PATCH 0/3] PM / devfreq: Fix issues about passive governor

2017-01-17 Thread Chanwoo Choi
This patchset fix the two issues about passive governor
and remove the unneeded separate _remove_devfreq() function.

First, the parent devfreq device can use the governors except for
the passive governor on the fly through sysfs entry and the passive
devfreq device is only possible to use the passive governor.

The 'available_governors' entry doesn't divide this difference
between parent devfreq and passive devfreq device. So, the patch1
fixes the this issue.

Second, the devfreq updates the statistic of frequency for each
device. But, 'trans_stat' of the passive devfreq device doesn't
update the statistic. So, the patch2 fixes this issue by calling
the update_devfreqw_passive() after setting the frequency
of passive devfreq device.

Finally, the patch3 removes the separate _remove_devfreq()
because this function is only called once in devfreq_dev_release().
I think that it is not necessary to make the separate function.


Depends on:
- These patches depends on the devfreq.git[1] and devfreq patches[2].
[1] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch: 
for-4.10-rc)
[2] https://lkml.org/lkml/2017/1/16/254
- ("[PATCH v3 0/4] PM / devfreq: Update the devfreq and devfreq-event device")


For example,
Following exmaple is the bus frequency device
of INT (Internal) block on Exynos5433-based TM2 board.

1. There are differences about 'available_governors' sysfs entry.
- Parent devfreq device (soc\:bus0)
- Passive devfreq device (soc\:bus1) depends on the parent devfreq (soc\:bus0).

1-1. Before applying these patches:
- parent devfreq device
$ cat /sys/class/devfreq/soc\:bus0/available_governors
passive userspace powersave performance simple_ondemand

- passive devfreq device
$ cat /sys/class/devfreq/soc\:bus1/available_governors
passive userspace powersave performance simple_ondemand

1-2. After applying these patches:
- parent devfreq device
$ cat /sys/class/devfreq/soc\:bus0/available_governors
userspace powersave performance simple_ondemand

- passive devfreq device
$ cat /sys/class/devfreq/soc\:bus1/available_governors
passive


2. There are differences about 'trans_stat' sysfs entry.
- Parent devfreq device (soc\:bus0)
- Passive devfreq device (soc\:bus3) depends on the parent devfreq (soc\:bus0).

2-1. Before applying these patches:
- parent devfreq device
$ cat /sys/class/devfreq/soc\:bus0/trans_stat
 From  :   To
   : 1 13400 16000 2 26700 4   
time(ms)
  1: 0 0 1 0 0 0 
80664
  13400: 0 0 0 0 1 0  
7552
  16000: 0 1 0 0 0 0  
8136
  2: 0 0 0 0 0 0
 0
  26700: 0 0 0 0 0 1 
23208
* 4: 0 0 0 0 0 0   
1188144
Total transition : 4

- passive devfreq device
$ cat /sys/class/devfreq/soc\:bus3/trans_stat
 From  :   To
   : 1 13400 16000 2 26700 4   
time(ms)
  1: 0 0 0 0 0 0
 0
  13400: 0 0 0 0 0 0
 0
  16000: 0 0 0 0 0 0
 0
  2: 0 0 0 0 0 0
 0
  26700: 0 0 0 0 0 0
 0
* 4: 0 0 0 0 0 0   
1317400
Total transition : 0


2-2. After applying these patches:
- parent devfreq device
$ cat /sys/class/devfreq/soc\:bus0/trans_stat
 From  :   To
   : 1 13400 16000 2 26700 4   
time(ms)
  1: 0 1 0 0 0 0
110372
  13400: 0 0 1 0 0 0  
6180
  16000: 0 0 0 1 0 0  
3748
  2: 0 0 0 0 1 0  
2992
  26700: 0 0 0 0 0 1  
4648
* 4: 0 0 0 0 0 0  
1636
Total transition : 5

- passive devfreq device
$ cat /sys/class/devfreq/soc\:bus3/trans_stat
 From  :   To
   : 1 13400 16000 2 26700 4   
time(ms)
  1: 0 1 0 0 0 0
110372
  13400: 0 0 1 0 0 0  
6180
  16000: 0 0 0 1 0 0  
3748
  2: 0 0 0 0 1 0  
2992
  26700: 0 0 0 0   

[PATCH 1/3] PM / devfreq: Fix available_governor sysfs

2017-01-17 Thread Chanwoo Choi
The devfreq using passive governor is not able to change the governor.
So, the user can not change the governor through 'available_governor' sysfs
entry. Also, the devfreq which don't use the passive governor is not able to
change to 'passive' governor on the fly.

Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
Cc: sta...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
---
 drivers/devfreq/devfreq.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 4bd7a8f71b07..a2c575a5a9ab 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -43,6 +43,11 @@
 static LIST_HEAD(devfreq_list);
 static DEFINE_MUTEX(devfreq_list_lock);
 
+static int is_passive_gov(const char *governor_name)
+{
+   return (!strncmp(governor_name, "passive", 7)) ? 1 : 0;
+}
+
 /**
  * find_device_devfreq() - find devfreq struct using device pointer
  * @dev:   device pointer used to lookup device devfreq.
@@ -933,6 +938,10 @@ static ssize_t governor_store(struct device *dev, struct 
device_attribute *attr,
if (ret != 1)
return -EINVAL;
 
+   /* The passive devfreq is not able to change the governor. */
+   if (is_passive_gov(df->governor_name))
+   return 0;
+
mutex_lock(_list_lock);
governor = find_devfreq_governor(str_governor);
if (IS_ERR(governor)) {
@@ -972,12 +981,35 @@ static ssize_t available_governors_show(struct device *d,
char *buf)
 {
struct devfreq_governor *tmp_governor;
+   struct devfreq *df = to_devfreq(d);
ssize_t count = 0;
 
mutex_lock(_list_lock);
-   list_for_each_entry(tmp_governor, _governor_list, node)
+
+   /*
+* The passive devfreq shows only passive governor.
+* The governor except for passive are not available
+* for passive devfreq device.
+*/
+   if (is_passive_gov(df->governor_name)) {
+   count += scnprintf([count], (PAGE_SIZE - count - 2),
+  "%s ", df->governor_name);
+   goto out;
+   }
+
+   /*
+* The devfreq device show the registered governor except for
+* 'passive' governor.
+*/
+   list_for_each_entry(tmp_governor, _governor_list, node) {
+   if (is_passive_gov(tmp_governor->name))
+   continue;
+
count += scnprintf([count], (PAGE_SIZE - count - 2),
   "%s ", tmp_governor->name);
+   }
+
+out:
mutex_unlock(_list_lock);
 
/* Truncate the trailing space */
-- 
1.9.1



[PATCH 3/3] PM / devfreq: Remove unnecessary separate _remove_devfreq()

2017-01-17 Thread Chanwoo Choi
The _remove_devfreq() releases the all resources of the devfreq
device. This function is only called in the devfreq_dev_release().
For that reason, the devfreq core doesn't need to leave the
_remove_devfreq() separately. This patch releases the all
resources in the devfreq_dev_release() and then removes the
_remove_devfreq().

Signed-off-by: Chanwoo Choi 
---
 drivers/devfreq/devfreq.c | 23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 6c560af2a801..c908c10c200a 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -480,11 +480,15 @@ static int devfreq_notifier_call(struct notifier_block 
*nb, unsigned long type,
 }
 
 /**
- * _remove_devfreq() - Remove devfreq from the list and release its resources.
- * @devfreq:   the devfreq struct
+ * devfreq_dev_release() - Callback for struct device to release the device.
+ * @dev:   the devfreq device
+ *
+ * Remove devfreq from the list and release its resources.
  */
-static void _remove_devfreq(struct devfreq *devfreq)
+static void devfreq_dev_release(struct device *dev)
 {
+   struct devfreq *devfreq = to_devfreq(dev);
+
mutex_lock(_list_lock);
if (IS_ERR(find_device_devfreq(devfreq->dev.parent))) {
mutex_unlock(_list_lock);
@@ -506,19 +510,6 @@ static void _remove_devfreq(struct devfreq *devfreq)
 }
 
 /**
- * devfreq_dev_release() - Callback for struct device to release the device.
- * @dev:   the devfreq device
- *
- * This calls _remove_devfreq() if _remove_devfreq() is not called.
- */
-static void devfreq_dev_release(struct device *dev)
-{
-   struct devfreq *devfreq = to_devfreq(dev);
-
-   _remove_devfreq(devfreq);
-}
-
-/**
  * devfreq_add_device() - Add devfreq feature to the device
  * @dev:   the device to add devfreq feature.
  * @profile:   device-specific profile to run devfreq.
-- 
1.9.1



[PATCH 0/3] PM / devfreq: Fix issues about passive governor

2017-01-17 Thread Chanwoo Choi
This patchset fix the two issues about passive governor
and remove the unneeded separate _remove_devfreq() function.

First, the parent devfreq device can use the governors except for
the passive governor on the fly through sysfs entry and the passive
devfreq device is only possible to use the passive governor.

The 'available_governors' entry doesn't divide this difference
between parent devfreq and passive devfreq device. So, the patch1
fixes the this issue.

Second, the devfreq updates the statistic of frequency for each
device. But, 'trans_stat' of the passive devfreq device doesn't
update the statistic. So, the patch2 fixes this issue by calling
the update_devfreqw_passive() after setting the frequency
of passive devfreq device.

Finally, the patch3 removes the separate _remove_devfreq()
because this function is only called once in devfreq_dev_release().
I think that it is not necessary to make the separate function.


Depends on:
- These patches depends on the devfreq.git[1] and devfreq patches[2].
[1] https://git.kernel.org/cgit/linux/kernel/git/mzx/devfreq.git/ (branch: 
for-4.10-rc)
[2] https://lkml.org/lkml/2017/1/16/254
- ("[PATCH v3 0/4] PM / devfreq: Update the devfreq and devfreq-event device")


For example,
Following exmaple is the bus frequency device
of INT (Internal) block on Exynos5433-based TM2 board.

1. There are differences about 'available_governors' sysfs entry.
- Parent devfreq device (soc\:bus0)
- Passive devfreq device (soc\:bus1) depends on the parent devfreq (soc\:bus0).

1-1. Before applying these patches:
- parent devfreq device
$ cat /sys/class/devfreq/soc\:bus0/available_governors
passive userspace powersave performance simple_ondemand

- passive devfreq device
$ cat /sys/class/devfreq/soc\:bus1/available_governors
passive userspace powersave performance simple_ondemand

1-2. After applying these patches:
- parent devfreq device
$ cat /sys/class/devfreq/soc\:bus0/available_governors
userspace powersave performance simple_ondemand

- passive devfreq device
$ cat /sys/class/devfreq/soc\:bus1/available_governors
passive


2. There are differences about 'trans_stat' sysfs entry.
- Parent devfreq device (soc\:bus0)
- Passive devfreq device (soc\:bus3) depends on the parent devfreq (soc\:bus0).

2-1. Before applying these patches:
- parent devfreq device
$ cat /sys/class/devfreq/soc\:bus0/trans_stat
 From  :   To
   : 1 13400 16000 2 26700 4   
time(ms)
  1: 0 0 1 0 0 0 
80664
  13400: 0 0 0 0 1 0  
7552
  16000: 0 1 0 0 0 0  
8136
  2: 0 0 0 0 0 0
 0
  26700: 0 0 0 0 0 1 
23208
* 4: 0 0 0 0 0 0   
1188144
Total transition : 4

- passive devfreq device
$ cat /sys/class/devfreq/soc\:bus3/trans_stat
 From  :   To
   : 1 13400 16000 2 26700 4   
time(ms)
  1: 0 0 0 0 0 0
 0
  13400: 0 0 0 0 0 0
 0
  16000: 0 0 0 0 0 0
 0
  2: 0 0 0 0 0 0
 0
  26700: 0 0 0 0 0 0
 0
* 4: 0 0 0 0 0 0   
1317400
Total transition : 0


2-2. After applying these patches:
- parent devfreq device
$ cat /sys/class/devfreq/soc\:bus0/trans_stat
 From  :   To
   : 1 13400 16000 2 26700 4   
time(ms)
  1: 0 1 0 0 0 0
110372
  13400: 0 0 1 0 0 0  
6180
  16000: 0 0 0 1 0 0  
3748
  2: 0 0 0 0 1 0  
2992
  26700: 0 0 0 0 0 1  
4648
* 4: 0 0 0 0 0 0  
1636
Total transition : 5

- passive devfreq device
$ cat /sys/class/devfreq/soc\:bus3/trans_stat
 From  :   To
   : 1 13400 16000 2 26700 4   
time(ms)
  1: 0 1 0 0 0 0
110372
  13400: 0 0 1 0 0 0  
6180
  16000: 0 0 0 1 0 0  
3748
  2: 0 0 0 0 1 0  
2992
  26700: 0 0 0 0   

[PATCH 1/3] PM / devfreq: Fix available_governor sysfs

2017-01-17 Thread Chanwoo Choi
The devfreq using passive governor is not able to change the governor.
So, the user can not change the governor through 'available_governor' sysfs
entry. Also, the devfreq which don't use the passive governor is not able to
change to 'passive' governor on the fly.

Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
Cc: sta...@vger.kernel.org
Signed-off-by: Chanwoo Choi 
---
 drivers/devfreq/devfreq.c | 34 +-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 4bd7a8f71b07..a2c575a5a9ab 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -43,6 +43,11 @@
 static LIST_HEAD(devfreq_list);
 static DEFINE_MUTEX(devfreq_list_lock);
 
+static int is_passive_gov(const char *governor_name)
+{
+   return (!strncmp(governor_name, "passive", 7)) ? 1 : 0;
+}
+
 /**
  * find_device_devfreq() - find devfreq struct using device pointer
  * @dev:   device pointer used to lookup device devfreq.
@@ -933,6 +938,10 @@ static ssize_t governor_store(struct device *dev, struct 
device_attribute *attr,
if (ret != 1)
return -EINVAL;
 
+   /* The passive devfreq is not able to change the governor. */
+   if (is_passive_gov(df->governor_name))
+   return 0;
+
mutex_lock(_list_lock);
governor = find_devfreq_governor(str_governor);
if (IS_ERR(governor)) {
@@ -972,12 +981,35 @@ static ssize_t available_governors_show(struct device *d,
char *buf)
 {
struct devfreq_governor *tmp_governor;
+   struct devfreq *df = to_devfreq(d);
ssize_t count = 0;
 
mutex_lock(_list_lock);
-   list_for_each_entry(tmp_governor, _governor_list, node)
+
+   /*
+* The passive devfreq shows only passive governor.
+* The governor except for passive are not available
+* for passive devfreq device.
+*/
+   if (is_passive_gov(df->governor_name)) {
+   count += scnprintf([count], (PAGE_SIZE - count - 2),
+  "%s ", df->governor_name);
+   goto out;
+   }
+
+   /*
+* The devfreq device show the registered governor except for
+* 'passive' governor.
+*/
+   list_for_each_entry(tmp_governor, _governor_list, node) {
+   if (is_passive_gov(tmp_governor->name))
+   continue;
+
count += scnprintf([count], (PAGE_SIZE - count - 2),
   "%s ", tmp_governor->name);
+   }
+
+out:
mutex_unlock(_list_lock);
 
/* Truncate the trailing space */
-- 
1.9.1



[PATCH 3/3] PM / devfreq: Remove unnecessary separate _remove_devfreq()

2017-01-17 Thread Chanwoo Choi
The _remove_devfreq() releases the all resources of the devfreq
device. This function is only called in the devfreq_dev_release().
For that reason, the devfreq core doesn't need to leave the
_remove_devfreq() separately. This patch releases the all
resources in the devfreq_dev_release() and then removes the
_remove_devfreq().

Signed-off-by: Chanwoo Choi 
---
 drivers/devfreq/devfreq.c | 23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 6c560af2a801..c908c10c200a 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -480,11 +480,15 @@ static int devfreq_notifier_call(struct notifier_block 
*nb, unsigned long type,
 }
 
 /**
- * _remove_devfreq() - Remove devfreq from the list and release its resources.
- * @devfreq:   the devfreq struct
+ * devfreq_dev_release() - Callback for struct device to release the device.
+ * @dev:   the devfreq device
+ *
+ * Remove devfreq from the list and release its resources.
  */
-static void _remove_devfreq(struct devfreq *devfreq)
+static void devfreq_dev_release(struct device *dev)
 {
+   struct devfreq *devfreq = to_devfreq(dev);
+
mutex_lock(_list_lock);
if (IS_ERR(find_device_devfreq(devfreq->dev.parent))) {
mutex_unlock(_list_lock);
@@ -506,19 +510,6 @@ static void _remove_devfreq(struct devfreq *devfreq)
 }
 
 /**
- * devfreq_dev_release() - Callback for struct device to release the device.
- * @dev:   the devfreq device
- *
- * This calls _remove_devfreq() if _remove_devfreq() is not called.
- */
-static void devfreq_dev_release(struct device *dev)
-{
-   struct devfreq *devfreq = to_devfreq(dev);
-
-   _remove_devfreq(devfreq);
-}
-
-/**
  * devfreq_add_device() - Add devfreq feature to the device
  * @dev:   the device to add devfreq feature.
  * @profile:   device-specific profile to run devfreq.
-- 
1.9.1



Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy

2017-01-17 Thread Vivek Gautam

Hi Kishon,


On 01/16/2017 02:19 PM, Kishon Vijay Abraham I wrote:

Hi,

On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote:

Qualcomm chipsets have QMP phy controller that provides
support to a number of controller, viz. PCIe, UFS, and USB.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam 
Acked-by: Rob Herring 
---

Changes since v3:
  - Added #clock-cells = <1>, indicating that phy is a clock provider.

Changes since v2:
  - Removed binding for "ref_clk_src" since we don't request this
clock in the driver.
  - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
  - Using 'phy' for the node name.

Changes since v1:
  - New patch, forked out of the original driver patch:
"phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
  - Added 'Acked-by' from Rob.
  - Updated bindings to include mem resource as a list of
offset - length pair for serdes block and for each lane.
  - Added a new binding for 'lane-offsets' that contains offsets
to tx, rx and pcs blocks from each lane base address.

  .../devicetree/bindings/phy/qcom-qmp-phy.txt   | 76 ++
  1 file changed, 76 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
new file mode 100644
index ..6f510fe48f46
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -0,0 +1,76 @@
+Qualcomm QMP PHY controller
+===
+
+QMP phy controller supports physical layer functionality for a number of
+controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
+
+Required properties:
+ - compatible: compatible list, contains:
+  "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
+  "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996.
+ - reg: list of offset and length pair of the PHY register sets.
+   at index 0: offset and length of register set for PHY common
+   serdes block.
+   from index 1 - N: offset and length of register set for each lane,
+ for N number of phy lanes (ports).
+ - lane-offsets: array of offsets to tx, rx and pcs blocks for phy lanes.
+ - #phy-cells: must be 1
+- Cell after phy phandle should be the port (lane) number.
+ - #clock-cells: must be 1
+- Phy pll outputs a bunch of clocks for Tx, Rx and Pipe
+  interface (for pipe based PHYs). These clock are then gate-controlled
+  by gcc.
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: must be "cfg_ahb" for phy config clock,
+   "aux" for phy aux clock,
+   "ref" for 19.2 MHz ref clk,
+   "pipe" for pipe clock specific to
+   each port/lane (Optional).
+ - resets: a list of phandles and reset controller specifier pairs,
+  one for each entry in reset-names.
+ - reset-names: must be "phy" for reset of phy block,
+   "common" for phy common block reset,
+   "cfg" for phy's ahb cfg block reset (Optional).
+   "port" for reset specific to
+   each port/lane (Optional).
+ - vdda-phy-supply: Phandle to a regulator supply to PHY core block.
+ - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
+
+Optional properties:
+ - vddp-ref-clk-supply: Phandle to a regulator supply to any specific refclk
+   pll block.
+
+Example:
+   pcie_phy: phy@34000 {
+   compatible = "qcom,msm8996-qmp-pcie-phy";
+   reg = <0x034000 0x48f>,
+   <0x035000 0x5bf>,
+   <0x036000 0x5bf>,
+   <0x037000 0x5bf>;
+   /* tx, rx, pcs */
+   lane-offsets = <0x0 0x200 0x400>;
+   #phy-cells = <1>;
+   #clock-cells = <1>;
+
+   clocks = < GCC_PCIE_PHY_AUX_CLK>,
+   < GCC_PCIE_PHY_CFG_AHB_CLK>,
+   < GCC_PCIE_CLKREF_CLK>,
+   < GCC_PCIE_0_PIPE_CLK>,
+   < GCC_PCIE_1_PIPE_CLK>,
+   < GCC_PCIE_2_PIPE_CLK>;
+   clock-names = "aux", "cfg_ahb", "ref",
+   "pipe0", "pipe1", "pipe2";
+
+   vdda-phy-supply = <_l28>;
+   vdda-pll-supply = <_l12>;
+
+   resets = < GCC_PCIE_PHY_BCR>,
+   < GCC_PCIE_PHY_COM_BCR>,
+   < GCC_PCIE_PHY_COM_NOCSR_BCR>,
+   < GCC_PCIE_0_PHY_BCR>,
+   < GCC_PCIE_1_PHY_BCR>,
+   < GCC_PCIE_2_PHY_BCR>;
+   reset-names = "phy", "common", "cfg",
+ 

Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy

2017-01-17 Thread Vivek Gautam

Hi Kishon,


On 01/16/2017 02:19 PM, Kishon Vijay Abraham I wrote:

Hi,

On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote:

Qualcomm chipsets have QMP phy controller that provides
support to a number of controller, viz. PCIe, UFS, and USB.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam 
Acked-by: Rob Herring 
---

Changes since v3:
  - Added #clock-cells = <1>, indicating that phy is a clock provider.

Changes since v2:
  - Removed binding for "ref_clk_src" since we don't request this
clock in the driver.
  - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
  - Using 'phy' for the node name.

Changes since v1:
  - New patch, forked out of the original driver patch:
"phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
  - Added 'Acked-by' from Rob.
  - Updated bindings to include mem resource as a list of
offset - length pair for serdes block and for each lane.
  - Added a new binding for 'lane-offsets' that contains offsets
to tx, rx and pcs blocks from each lane base address.

  .../devicetree/bindings/phy/qcom-qmp-phy.txt   | 76 ++
  1 file changed, 76 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
new file mode 100644
index ..6f510fe48f46
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -0,0 +1,76 @@
+Qualcomm QMP PHY controller
+===
+
+QMP phy controller supports physical layer functionality for a number of
+controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
+
+Required properties:
+ - compatible: compatible list, contains:
+  "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
+  "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996.
+ - reg: list of offset and length pair of the PHY register sets.
+   at index 0: offset and length of register set for PHY common
+   serdes block.
+   from index 1 - N: offset and length of register set for each lane,
+ for N number of phy lanes (ports).
+ - lane-offsets: array of offsets to tx, rx and pcs blocks for phy lanes.
+ - #phy-cells: must be 1
+- Cell after phy phandle should be the port (lane) number.
+ - #clock-cells: must be 1
+- Phy pll outputs a bunch of clocks for Tx, Rx and Pipe
+  interface (for pipe based PHYs). These clock are then gate-controlled
+  by gcc.
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: must be "cfg_ahb" for phy config clock,
+   "aux" for phy aux clock,
+   "ref" for 19.2 MHz ref clk,
+   "pipe" for pipe clock specific to
+   each port/lane (Optional).
+ - resets: a list of phandles and reset controller specifier pairs,
+  one for each entry in reset-names.
+ - reset-names: must be "phy" for reset of phy block,
+   "common" for phy common block reset,
+   "cfg" for phy's ahb cfg block reset (Optional).
+   "port" for reset specific to
+   each port/lane (Optional).
+ - vdda-phy-supply: Phandle to a regulator supply to PHY core block.
+ - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
+
+Optional properties:
+ - vddp-ref-clk-supply: Phandle to a regulator supply to any specific refclk
+   pll block.
+
+Example:
+   pcie_phy: phy@34000 {
+   compatible = "qcom,msm8996-qmp-pcie-phy";
+   reg = <0x034000 0x48f>,
+   <0x035000 0x5bf>,
+   <0x036000 0x5bf>,
+   <0x037000 0x5bf>;
+   /* tx, rx, pcs */
+   lane-offsets = <0x0 0x200 0x400>;
+   #phy-cells = <1>;
+   #clock-cells = <1>;
+
+   clocks = < GCC_PCIE_PHY_AUX_CLK>,
+   < GCC_PCIE_PHY_CFG_AHB_CLK>,
+   < GCC_PCIE_CLKREF_CLK>,
+   < GCC_PCIE_0_PIPE_CLK>,
+   < GCC_PCIE_1_PIPE_CLK>,
+   < GCC_PCIE_2_PIPE_CLK>;
+   clock-names = "aux", "cfg_ahb", "ref",
+   "pipe0", "pipe1", "pipe2";
+
+   vdda-phy-supply = <_l28>;
+   vdda-pll-supply = <_l12>;
+
+   resets = < GCC_PCIE_PHY_BCR>,
+   < GCC_PCIE_PHY_COM_BCR>,
+   < GCC_PCIE_PHY_COM_NOCSR_BCR>,
+   < GCC_PCIE_0_PHY_BCR>,
+   < GCC_PCIE_1_PHY_BCR>,
+   < GCC_PCIE_2_PHY_BCR>;
+   reset-names = "phy", "common", "cfg",
+   "lane0", "lane1", "lane2";


Re: [PATCH v4 15/15] lockdep: Crossrelease feature documentation

2017-01-17 Thread Boqun Feng
On Fri, Dec 09, 2016 at 02:12:11PM +0900, Byungchul Park wrote:
[...]
> +Example 1:
> +
> +   CONTEXT XCONTEXT Y
> +   --
> +   mutext_lock A
> +lock_page B
> +   lock_page B
> +mutext_lock A /* DEADLOCK */

s/mutext_lock/mutex_lock

> +   unlock_page B
> +mutext_unlock A
> +   mutex_unlock A
> +unlock_page B
> +
> +   where A is a lock class and B is a page lock.
> +
> +No, we cannot.
> +
> +Example 2:
> +
> +   CONTEXT XCONTEXT Y   CONTEXT Z
> +   --   --
> +mutex_lock A
> +   lock_page B
> +lock_page B
> +mutext_lock A /* DEADLOCK */
> +mutext_unlock A

Ditto.

> +unlock_page B held by X
> +unlock_page B
> +mutex_unlock A
> +
> +   where A is a lock class and B is a page lock.
> +
> +No, we cannot.
> +
> +Example 3:
> +
> +   CONTEXT XCONTEXT Y
> +   --
> +mutex_lock A
> +   mutex_lock A
> +   mutex_unlock A
> +wait_for_complete B /* DEADLOCK */

I think this part better be:

   CONTEXT X   CONTEXT Y
   -   -
   mutex_lock A
   mutex_lock A
   wait_for_complete B /* DEADLOCK */
   mutex_unlock A

, right? Because Y triggers DEADLOCK before X could run mutex_unlock().

Regards,
Boqun


signature.asc
Description: PGP signature


Re: [PATCH v4 15/15] lockdep: Crossrelease feature documentation

2017-01-17 Thread Boqun Feng
On Fri, Dec 09, 2016 at 02:12:11PM +0900, Byungchul Park wrote:
[...]
> +Example 1:
> +
> +   CONTEXT XCONTEXT Y
> +   --
> +   mutext_lock A
> +lock_page B
> +   lock_page B
> +mutext_lock A /* DEADLOCK */

s/mutext_lock/mutex_lock

> +   unlock_page B
> +mutext_unlock A
> +   mutex_unlock A
> +unlock_page B
> +
> +   where A is a lock class and B is a page lock.
> +
> +No, we cannot.
> +
> +Example 2:
> +
> +   CONTEXT XCONTEXT Y   CONTEXT Z
> +   --   --
> +mutex_lock A
> +   lock_page B
> +lock_page B
> +mutext_lock A /* DEADLOCK */
> +mutext_unlock A

Ditto.

> +unlock_page B held by X
> +unlock_page B
> +mutex_unlock A
> +
> +   where A is a lock class and B is a page lock.
> +
> +No, we cannot.
> +
> +Example 3:
> +
> +   CONTEXT XCONTEXT Y
> +   --
> +mutex_lock A
> +   mutex_lock A
> +   mutex_unlock A
> +wait_for_complete B /* DEADLOCK */

I think this part better be:

   CONTEXT X   CONTEXT Y
   -   -
   mutex_lock A
   mutex_lock A
   wait_for_complete B /* DEADLOCK */
   mutex_unlock A

, right? Because Y triggers DEADLOCK before X could run mutex_unlock().

Regards,
Boqun


signature.asc
Description: PGP signature


RE: [PATCHv2] firmware: Correct handling of fw_state_wait_timeout() return value

2017-01-17 Thread linux-kernel-dev
>From: Jakub Kicinski [mailto:jakub.kicin...@netronome.com]
>Sent: Dienstag, 17. Januar 2017 22:18
>
>On Tue, Jan 17, 2017 at 12:53 PM, Luis R. Rodriguez 
>wrote:
>> On Tue, Jan 17, 2017 at 10:04:20AM -0800, Jakub Kicinski wrote:
>>> On Tue, Jan 17, 2017 at 9:30 AM, Luis R. Rodriguez 
>wrote:
>>> > On Tue, Jan 17, 2017 at 08:30:37AM -0800, Jakub Kicinski wrote:
>>> >> Adding a NULL-check would just paper over the
>>> >> issue and can cause trouble down the line.
>>> >
>>> > We typically bail on errors and use similar code to bail out, and we
>>> > typically do these things. Here its no different. The *real* issue
>>> > is the fact that we have a waiting timeout which can fail race against
>>> > a user imposed error out on the sysfs interface. There is one catch:
>>> >
>>> > We already lock with the big fw_lock and use this to be able to check
>>> > for the status of the fw, so once aborted we technically should not have
>>> > to abort again. A proper way to address then this would have been to
>check
>>> > for the status of the fw prior to aborting again given we also lock on the
>>> > big fw_lock. A problem with this though is the status is part of the buf
>>> > which is set to NULL after we are done aborting.
>>>
>>> Yes, I've seen that too :\  This race seems to have been there prior
>>> to 4.9, though.  I guess we could fix both issues with the NULL-check
>>> although I would prefer if we had both patches.
>>>
>>> FWIW I think the NULL-check could be put in the existing conditional:
>>>
>>>  * There is a small window in which user can write to 'loading'
>>>  * between loading done and disappearance of 'loading'
>>>  */
>>> -   if (fw_state_is_done(>fw_st))
>>> +   if (!buf || fw_state_is_done(>fw_st))
>>> return;
>>>
>>> list_del_init(>pending_list);
>>>
>>> Note that the comment above seems to be mentioning the race we're
>>> trying to solve.
>>
>> Right, I think another approach is to *enable* the state of the buf
>> to be used to avoid further use on the sysfs iterface instead. Fortunately
>> other sysfs interfaces already use fw_state_is_done() to bail out,
>> so all that would be needed I think would be:
>>
>> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
>> index b9ac348e8d33..30ccf7aea3ca 100644
>> --- a/drivers/base/firmware_class.c
>> +++ b/drivers/base/firmware_class.c
>> @@ -558,9 +558,6 @@ static void fw_load_abort(struct firmware_priv
>*fw_priv)
>> struct firmware_buf *buf = fw_priv->buf;
>>
>> __fw_load_abort(buf);
>> -
>> -   /* avoid user action after loading abort */
>> -   fw_priv->buf = NULL;
>>  }
>>
>>  static LIST_HEAD(pending_fw_head);
>> @@ -713,7 +710,7 @@ static ssize_t firmware_loading_store(struct device
>*dev,
>>
>> mutex_lock(_lock);
>> fw_buf = fw_priv->buf;
>> -   if (!fw_buf)
>> +   if (!fw_buf || fw_state_is_aborted(_buf->fw_st))
>> goto out;
>>
>> switch (loading) {
>
>IMHO this one is nice!  I think you can even drop the !fw_buf check in
>this case because AFAICS the only case where fw_buf is set to NULL is
>in the abort function.
>
I can confirm, that patch looks nice and is working for my setup, even without 
the !fw_buf. 
Feel free to grab everything you need from my commit log, if it helps.
Unfortunately there is a crazy spam filter between us, so you can't rely on me.
 


RE: [PATCHv2] firmware: Correct handling of fw_state_wait_timeout() return value

2017-01-17 Thread linux-kernel-dev
>From: Jakub Kicinski [mailto:jakub.kicin...@netronome.com]
>Sent: Dienstag, 17. Januar 2017 22:18
>
>On Tue, Jan 17, 2017 at 12:53 PM, Luis R. Rodriguez 
>wrote:
>> On Tue, Jan 17, 2017 at 10:04:20AM -0800, Jakub Kicinski wrote:
>>> On Tue, Jan 17, 2017 at 9:30 AM, Luis R. Rodriguez 
>wrote:
>>> > On Tue, Jan 17, 2017 at 08:30:37AM -0800, Jakub Kicinski wrote:
>>> >> Adding a NULL-check would just paper over the
>>> >> issue and can cause trouble down the line.
>>> >
>>> > We typically bail on errors and use similar code to bail out, and we
>>> > typically do these things. Here its no different. The *real* issue
>>> > is the fact that we have a waiting timeout which can fail race against
>>> > a user imposed error out on the sysfs interface. There is one catch:
>>> >
>>> > We already lock with the big fw_lock and use this to be able to check
>>> > for the status of the fw, so once aborted we technically should not have
>>> > to abort again. A proper way to address then this would have been to
>check
>>> > for the status of the fw prior to aborting again given we also lock on the
>>> > big fw_lock. A problem with this though is the status is part of the buf
>>> > which is set to NULL after we are done aborting.
>>>
>>> Yes, I've seen that too :\  This race seems to have been there prior
>>> to 4.9, though.  I guess we could fix both issues with the NULL-check
>>> although I would prefer if we had both patches.
>>>
>>> FWIW I think the NULL-check could be put in the existing conditional:
>>>
>>>  * There is a small window in which user can write to 'loading'
>>>  * between loading done and disappearance of 'loading'
>>>  */
>>> -   if (fw_state_is_done(>fw_st))
>>> +   if (!buf || fw_state_is_done(>fw_st))
>>> return;
>>>
>>> list_del_init(>pending_list);
>>>
>>> Note that the comment above seems to be mentioning the race we're
>>> trying to solve.
>>
>> Right, I think another approach is to *enable* the state of the buf
>> to be used to avoid further use on the sysfs iterface instead. Fortunately
>> other sysfs interfaces already use fw_state_is_done() to bail out,
>> so all that would be needed I think would be:
>>
>> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
>> index b9ac348e8d33..30ccf7aea3ca 100644
>> --- a/drivers/base/firmware_class.c
>> +++ b/drivers/base/firmware_class.c
>> @@ -558,9 +558,6 @@ static void fw_load_abort(struct firmware_priv
>*fw_priv)
>> struct firmware_buf *buf = fw_priv->buf;
>>
>> __fw_load_abort(buf);
>> -
>> -   /* avoid user action after loading abort */
>> -   fw_priv->buf = NULL;
>>  }
>>
>>  static LIST_HEAD(pending_fw_head);
>> @@ -713,7 +710,7 @@ static ssize_t firmware_loading_store(struct device
>*dev,
>>
>> mutex_lock(_lock);
>> fw_buf = fw_priv->buf;
>> -   if (!fw_buf)
>> +   if (!fw_buf || fw_state_is_aborted(_buf->fw_st))
>> goto out;
>>
>> switch (loading) {
>
>IMHO this one is nice!  I think you can even drop the !fw_buf check in
>this case because AFAICS the only case where fw_buf is set to NULL is
>in the abort function.
>
I can confirm, that patch looks nice and is working for my setup, even without 
the !fw_buf. 
Feel free to grab everything you need from my commit log, if it helps.
Unfortunately there is a crazy spam filter between us, so you can't rely on me.
 


[RESEND PATCH v5 2/3] perf tool: add PERF_RECORD_NAMESPACES to include namespaces related info

2017-01-17 Thread Hari Bathini
This patch updates perf tool to examine PERF_RECORD_NAMESPACES events
emitted by the kernel when fork, clone, setns or unshare are invoked.
Also, it synthesizes PERF_RECORD_NAMESPACES events for processes that
were running prior to invocation of perf record, the data for which
is taken from /proc/$PID/ns. These changes make way for analyzing
events with regard to namespaces.

Signed-off-by: Hari Bathini 
---

Changes from v4:
* Added warning when nr_namespaces values of the kernel
  and perf tool mismatch.
* Improved printing of namespace records.


 tools/include/uapi/linux/perf_event.h |   38 +
 tools/perf/builtin-annotate.c |1 
 tools/perf/builtin-diff.c |1 
 tools/perf/builtin-inject.c   |   14 +++
 tools/perf/builtin-kmem.c |1 
 tools/perf/builtin-kvm.c  |2 
 tools/perf/builtin-lock.c |1 
 tools/perf/builtin-mem.c  |1 
 tools/perf/builtin-record.c   |   33 +++-
 tools/perf/builtin-report.c   |1 
 tools/perf/builtin-sched.c|1 
 tools/perf/builtin-script.c   |   41 +
 tools/perf/builtin-trace.c|3 -
 tools/perf/perf.h |1 
 tools/perf/util/Build |1 
 tools/perf/util/data-convert-bt.c |2 
 tools/perf/util/event.c   |  143 -
 tools/perf/util/event.h   |   19 
 tools/perf/util/evsel.c   |3 +
 tools/perf/util/machine.c |   34 
 tools/perf/util/machine.h |3 +
 tools/perf/util/namespaces.c  |   35 
 tools/perf/util/namespaces.h  |   26 ++
 tools/perf/util/session.c |7 ++
 tools/perf/util/thread.c  |   44 ++
 tools/perf/util/thread.h  |6 +
 tools/perf/util/tool.h|2 
 27 files changed, 450 insertions(+), 14 deletions(-)
 create mode 100644 tools/perf/util/namespaces.c
 create mode 100644 tools/perf/util/namespaces.h

diff --git a/tools/include/uapi/linux/perf_event.h 
b/tools/include/uapi/linux/perf_event.h
index c66a485..ee60f54 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -344,7 +344,8 @@ struct perf_event_attr {
use_clockid:  1, /* use @clockid for time 
fields */
context_switch :  1, /* context switch data */
write_backward :  1, /* Write ring buffer from 
end to beginning */
-   __reserved_1   : 36;
+   namespaces :  1, /* include namespaces data 
*/
+   __reserved_1   : 35;
 
union {
__u32   wakeup_events;/* wakeup every n events */
@@ -610,6 +611,29 @@ struct perf_event_header {
__u16   size;
 };
 
+/*
+ * The maximum size of the name of each namespace
+ */
+#define NS_NAME_SIZE   8
+
+struct perf_ns_link_info {
+   charname[NS_NAME_SIZE];
+   __u64   dev;
+   __u64   ino;
+};
+
+enum {
+   NET_NS_INDEX= 0,
+   UTS_NS_INDEX= 1,
+   IPC_NS_INDEX= 2,
+   PID_NS_INDEX= 3,
+   USER_NS_INDEX   = 4,
+   MNT_NS_INDEX= 5,
+   CGROUP_NS_INDEX = 6,
+
+   NAMESPACES_MAX, /* maximum available namespaces */
+};
+
 enum perf_event_type {
 
/*
@@ -862,6 +886,18 @@ enum perf_event_type {
 */
PERF_RECORD_SWITCH_CPU_WIDE = 15,
 
+   /*
+* struct {
+*  struct perf_event_headerheader;
+*  u32 pid;
+*  u32 tid;
+*  u32 nr_namespaces;
+*  struct namespace_link_info  link_info[NAMESPACES_MAX];
+*  struct sample_idsample_id;
+* };
+*/
+   PERF_RECORD_NAMESPACES  = 16,
+
PERF_RECORD_MAX,/* non-ABI */
 };
 
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index ebb6283..1b63dc4 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -393,6 +393,7 @@ int cmd_annotate(int argc, const char **argv, const char 
*prefix __maybe_unused)
.comm   = perf_event__process_comm,
.exit   = perf_event__process_exit,
.fork   = perf_event__process_fork,
+   .namespaces = perf_event__process_namespaces,
.ordered_events = true,
.ordering_requires_timestamps = true,
},
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 9ff0db4..c52552f 

[RESEND PATCH v5 0/3] perf: add support for analyzing events for containers

2017-01-17 Thread Hari Bathini
Please ignore the previously sent v5 of this patchset.

Currently, there is no trivial mechanism to analyze events based on
containers. perf -G can be used, but it will not filter events for the
containers created after perf is invoked, making it difficult to assess/
analyze performance issues of multiple containers at once.

This patch-set is aimed at addressing this limitation by introducing a
new PERF_RECORD_NAMESPACES event that records namespaces related info.
As containers are created with namespaces, the new data can be used to
in assessment/analysis of multiple containers.

The first patch introduces PERF_RECORD_NAMESPACES in kernel while the
second patch makes the corresponding changes in perf tool to read this
PERF_RECORD_NAMESPACES events. The third patch demonstrates analysis
of containers with this data by adding a cgroup identifier column in
perf report, which contains the cgroup namespace's device and inode
numbers. This is based on the assumption that each container is created
with it's own cgroup namespace. The third patch has scope for improvement
based on the conventions a container is attributed with, going forward.

---

Hari Bathini (3):
  perf: add PERF_RECORD_NAMESPACES to include namespaces related info
  perf tool: add PERF_RECORD_NAMESPACES to include namespaces related info
  perf tool: add cgroup identifier entry in perf report


 include/linux/perf_event.h|2 
 include/uapi/linux/perf_event.h   |   38 +
 kernel/events/core.c  |  142 +
 kernel/fork.c |3 +
 kernel/nsproxy.c  |5 +
 tools/include/uapi/linux/perf_event.h |   38 +
 tools/perf/builtin-annotate.c |1 
 tools/perf/builtin-diff.c |1 
 tools/perf/builtin-inject.c   |   14 +++
 tools/perf/builtin-kmem.c |1 
 tools/perf/builtin-kvm.c  |2 
 tools/perf/builtin-lock.c |1 
 tools/perf/builtin-mem.c  |1 
 tools/perf/builtin-record.c   |   33 +++-
 tools/perf/builtin-report.c   |1 
 tools/perf/builtin-sched.c|1 
 tools/perf/builtin-script.c   |   41 +
 tools/perf/builtin-trace.c|3 -
 tools/perf/perf.h |1 
 tools/perf/util/Build |1 
 tools/perf/util/data-convert-bt.c |2 
 tools/perf/util/event.c   |  143 -
 tools/perf/util/event.h   |   19 
 tools/perf/util/evsel.c   |3 +
 tools/perf/util/hist.c|7 ++
 tools/perf/util/hist.h|1 
 tools/perf/util/machine.c |   34 
 tools/perf/util/machine.h |3 +
 tools/perf/util/namespaces.c  |   35 
 tools/perf/util/namespaces.h  |   26 ++
 tools/perf/util/session.c |7 ++
 tools/perf/util/sort.c|   41 +
 tools/perf/util/sort.h|7 ++
 tools/perf/util/thread.c  |   44 ++
 tools/perf/util/thread.h  |6 +
 tools/perf/util/tool.h|2 
 36 files changed, 695 insertions(+), 15 deletions(-)
 create mode 100644 tools/perf/util/namespaces.c
 create mode 100644 tools/perf/util/namespaces.h



[RESEND PATCH v5 3/3] perf tool: add cgroup identifier entry in perf report

2017-01-17 Thread Hari Bathini
This patch introduces a cgroup identifier entry field in perf report to
identify or distinguish data of different cgroups. It uses the device
number and inode number of cgroup namespace, included in perf data with
the new PERF_RECORD_NAMESPACES event, as cgroup identifier. With the
assumption that each container is created with it's own cgroup namespace,
this allows assessment/analysis of multiple containers at once.

Shown below is the output of perf report, sorted based on cgroup id, on
a system that was running three containers at the time of perf record
and clearly showing one of the containers' considerable use of kernel
memory in comparison with others:


$ perf report -s cgroup_id,sample --stdio
#
# Total Lost Samples: 0
#
# Samples: 2K of event 'kmem:kmalloc'
# Event count (approx.): 2176
#
# Overhead  cgroup id (dev/inode)   Samples
#   .  
#
89.20%  3/0xf0cf   1941
 3.31%  3/0xeffb 72
 3.08%  3/0xf0d0 67
 2.25%  3/0xf0d1 49
 2.16%  0/0x047

Signed-off-by: Hari Bathini 
---

* No changes since v4.


 tools/perf/util/hist.c |7 +++
 tools/perf/util/hist.h |1 +
 tools/perf/util/sort.c |   41 +
 tools/perf/util/sort.h |7 +++
 4 files changed, 56 insertions(+)

diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 6770a96..9996e0c 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -2,6 +2,7 @@
 #include "build-id.h"
 #include "hist.h"
 #include "session.h"
+#include "namespaces.h"
 #include "sort.h"
 #include "evlist.h"
 #include "evsel.h"
@@ -168,6 +169,7 @@ void hists__calc_col_len(struct hists *hists, struct 
hist_entry *h)
hists__set_unres_dso_col_len(hists, HISTC_MEM_DADDR_DSO);
}
 
+   hists__new_col_len(hists, HISTC_CGROUP_ID, 20);
hists__new_col_len(hists, HISTC_CPU, 3);
hists__new_col_len(hists, HISTC_SOCKET, 6);
hists__new_col_len(hists, HISTC_MEM_LOCKED, 6);
@@ -573,9 +575,14 @@ __hists__add_entry(struct hists *hists,
   bool sample_self,
   struct hist_entry_ops *ops)
 {
+   struct namespaces *ns = thread__namespaces(al->thread);
struct hist_entry entry = {
.thread = al->thread,
.comm = thread__comm(al->thread),
+   .cgroup_id = {
+   .dev = ns ? ns->link_info[CGROUP_NS_INDEX].dev : 0,
+   .ino = ns ? ns->link_info[CGROUP_NS_INDEX].ino : 0,
+   },
.ms = {
.map= al->map,
.sym= al->sym,
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index d4b6514..d7696fd 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -30,6 +30,7 @@ enum hist_column {
HISTC_DSO,
HISTC_THREAD,
HISTC_COMM,
+   HISTC_CGROUP_ID,
HISTC_PARENT,
HISTC_CPU,
HISTC_SOCKET,
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index df622f4..9f5f404 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -536,6 +536,46 @@ struct sort_entry sort_cpu = {
.se_width_idx   = HISTC_CPU,
 };
 
+/* --sort cgroup_id */
+
+static int64_t _sort__cgroup_dev_cmp(u64 left_dev, u64 right_dev)
+{
+   return (int64_t)(right_dev - left_dev);
+}
+
+static int64_t _sort__cgroup_inode_cmp(u64 left_ino, u64 right_ino)
+{
+   return (int64_t)(right_ino - left_ino);
+}
+
+static int64_t
+sort__cgroup_id_cmp(struct hist_entry *left, struct hist_entry *right)
+{
+   int64_t ret;
+
+   ret = _sort__cgroup_dev_cmp(right->cgroup_id.dev, left->cgroup_id.dev);
+   if (ret != 0)
+   return ret;
+
+   return _sort__cgroup_inode_cmp(right->cgroup_id.ino,
+  left->cgroup_id.ino);
+}
+
+static int hist_entry__cgroup_id_snprintf(struct hist_entry *he,
+ char *bf, size_t size,
+ unsigned int width __maybe_unused)
+{
+   return repsep_snprintf(bf, size, "%lu/0x%lx", he->cgroup_id.dev,
+  he->cgroup_id.ino);
+}
+
+struct sort_entry sort_cgroup_id = {
+   .se_header  = "cgroup id (dev/inode)",
+   .se_cmp = sort__cgroup_id_cmp,
+   .se_snprintf= hist_entry__cgroup_id_snprintf,
+   .se_width_idx   = HISTC_CGROUP_ID,
+};
+
 /* --sort socket */
 
 static int64_t
@@ -1418,6 +1458,7 @@ static struct sort_dimension common_sort_dimensions[] = {
DIM(SORT_GLOBAL_WEIGHT, "weight", sort_global_weight),
DIM(SORT_TRANSACTION, "transaction", sort_transaction),

[RESEND PATCH v5 2/3] perf tool: add PERF_RECORD_NAMESPACES to include namespaces related info

2017-01-17 Thread Hari Bathini
This patch updates perf tool to examine PERF_RECORD_NAMESPACES events
emitted by the kernel when fork, clone, setns or unshare are invoked.
Also, it synthesizes PERF_RECORD_NAMESPACES events for processes that
were running prior to invocation of perf record, the data for which
is taken from /proc/$PID/ns. These changes make way for analyzing
events with regard to namespaces.

Signed-off-by: Hari Bathini 
---

Changes from v4:
* Added warning when nr_namespaces values of the kernel
  and perf tool mismatch.
* Improved printing of namespace records.


 tools/include/uapi/linux/perf_event.h |   38 +
 tools/perf/builtin-annotate.c |1 
 tools/perf/builtin-diff.c |1 
 tools/perf/builtin-inject.c   |   14 +++
 tools/perf/builtin-kmem.c |1 
 tools/perf/builtin-kvm.c  |2 
 tools/perf/builtin-lock.c |1 
 tools/perf/builtin-mem.c  |1 
 tools/perf/builtin-record.c   |   33 +++-
 tools/perf/builtin-report.c   |1 
 tools/perf/builtin-sched.c|1 
 tools/perf/builtin-script.c   |   41 +
 tools/perf/builtin-trace.c|3 -
 tools/perf/perf.h |1 
 tools/perf/util/Build |1 
 tools/perf/util/data-convert-bt.c |2 
 tools/perf/util/event.c   |  143 -
 tools/perf/util/event.h   |   19 
 tools/perf/util/evsel.c   |3 +
 tools/perf/util/machine.c |   34 
 tools/perf/util/machine.h |3 +
 tools/perf/util/namespaces.c  |   35 
 tools/perf/util/namespaces.h  |   26 ++
 tools/perf/util/session.c |7 ++
 tools/perf/util/thread.c  |   44 ++
 tools/perf/util/thread.h  |6 +
 tools/perf/util/tool.h|2 
 27 files changed, 450 insertions(+), 14 deletions(-)
 create mode 100644 tools/perf/util/namespaces.c
 create mode 100644 tools/perf/util/namespaces.h

diff --git a/tools/include/uapi/linux/perf_event.h 
b/tools/include/uapi/linux/perf_event.h
index c66a485..ee60f54 100644
--- a/tools/include/uapi/linux/perf_event.h
+++ b/tools/include/uapi/linux/perf_event.h
@@ -344,7 +344,8 @@ struct perf_event_attr {
use_clockid:  1, /* use @clockid for time 
fields */
context_switch :  1, /* context switch data */
write_backward :  1, /* Write ring buffer from 
end to beginning */
-   __reserved_1   : 36;
+   namespaces :  1, /* include namespaces data 
*/
+   __reserved_1   : 35;
 
union {
__u32   wakeup_events;/* wakeup every n events */
@@ -610,6 +611,29 @@ struct perf_event_header {
__u16   size;
 };
 
+/*
+ * The maximum size of the name of each namespace
+ */
+#define NS_NAME_SIZE   8
+
+struct perf_ns_link_info {
+   charname[NS_NAME_SIZE];
+   __u64   dev;
+   __u64   ino;
+};
+
+enum {
+   NET_NS_INDEX= 0,
+   UTS_NS_INDEX= 1,
+   IPC_NS_INDEX= 2,
+   PID_NS_INDEX= 3,
+   USER_NS_INDEX   = 4,
+   MNT_NS_INDEX= 5,
+   CGROUP_NS_INDEX = 6,
+
+   NAMESPACES_MAX, /* maximum available namespaces */
+};
+
 enum perf_event_type {
 
/*
@@ -862,6 +886,18 @@ enum perf_event_type {
 */
PERF_RECORD_SWITCH_CPU_WIDE = 15,
 
+   /*
+* struct {
+*  struct perf_event_headerheader;
+*  u32 pid;
+*  u32 tid;
+*  u32 nr_namespaces;
+*  struct namespace_link_info  link_info[NAMESPACES_MAX];
+*  struct sample_idsample_id;
+* };
+*/
+   PERF_RECORD_NAMESPACES  = 16,
+
PERF_RECORD_MAX,/* non-ABI */
 };
 
diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index ebb6283..1b63dc4 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -393,6 +393,7 @@ int cmd_annotate(int argc, const char **argv, const char 
*prefix __maybe_unused)
.comm   = perf_event__process_comm,
.exit   = perf_event__process_exit,
.fork   = perf_event__process_fork,
+   .namespaces = perf_event__process_namespaces,
.ordered_events = true,
.ordering_requires_timestamps = true,
},
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index 9ff0db4..c52552f 100644
--- 

[RESEND PATCH v5 0/3] perf: add support for analyzing events for containers

2017-01-17 Thread Hari Bathini
Please ignore the previously sent v5 of this patchset.

Currently, there is no trivial mechanism to analyze events based on
containers. perf -G can be used, but it will not filter events for the
containers created after perf is invoked, making it difficult to assess/
analyze performance issues of multiple containers at once.

This patch-set is aimed at addressing this limitation by introducing a
new PERF_RECORD_NAMESPACES event that records namespaces related info.
As containers are created with namespaces, the new data can be used to
in assessment/analysis of multiple containers.

The first patch introduces PERF_RECORD_NAMESPACES in kernel while the
second patch makes the corresponding changes in perf tool to read this
PERF_RECORD_NAMESPACES events. The third patch demonstrates analysis
of containers with this data by adding a cgroup identifier column in
perf report, which contains the cgroup namespace's device and inode
numbers. This is based on the assumption that each container is created
with it's own cgroup namespace. The third patch has scope for improvement
based on the conventions a container is attributed with, going forward.

---

Hari Bathini (3):
  perf: add PERF_RECORD_NAMESPACES to include namespaces related info
  perf tool: add PERF_RECORD_NAMESPACES to include namespaces related info
  perf tool: add cgroup identifier entry in perf report


 include/linux/perf_event.h|2 
 include/uapi/linux/perf_event.h   |   38 +
 kernel/events/core.c  |  142 +
 kernel/fork.c |3 +
 kernel/nsproxy.c  |5 +
 tools/include/uapi/linux/perf_event.h |   38 +
 tools/perf/builtin-annotate.c |1 
 tools/perf/builtin-diff.c |1 
 tools/perf/builtin-inject.c   |   14 +++
 tools/perf/builtin-kmem.c |1 
 tools/perf/builtin-kvm.c  |2 
 tools/perf/builtin-lock.c |1 
 tools/perf/builtin-mem.c  |1 
 tools/perf/builtin-record.c   |   33 +++-
 tools/perf/builtin-report.c   |1 
 tools/perf/builtin-sched.c|1 
 tools/perf/builtin-script.c   |   41 +
 tools/perf/builtin-trace.c|3 -
 tools/perf/perf.h |1 
 tools/perf/util/Build |1 
 tools/perf/util/data-convert-bt.c |2 
 tools/perf/util/event.c   |  143 -
 tools/perf/util/event.h   |   19 
 tools/perf/util/evsel.c   |3 +
 tools/perf/util/hist.c|7 ++
 tools/perf/util/hist.h|1 
 tools/perf/util/machine.c |   34 
 tools/perf/util/machine.h |3 +
 tools/perf/util/namespaces.c  |   35 
 tools/perf/util/namespaces.h  |   26 ++
 tools/perf/util/session.c |7 ++
 tools/perf/util/sort.c|   41 +
 tools/perf/util/sort.h|7 ++
 tools/perf/util/thread.c  |   44 ++
 tools/perf/util/thread.h  |6 +
 tools/perf/util/tool.h|2 
 36 files changed, 695 insertions(+), 15 deletions(-)
 create mode 100644 tools/perf/util/namespaces.c
 create mode 100644 tools/perf/util/namespaces.h



[RESEND PATCH v5 3/3] perf tool: add cgroup identifier entry in perf report

2017-01-17 Thread Hari Bathini
This patch introduces a cgroup identifier entry field in perf report to
identify or distinguish data of different cgroups. It uses the device
number and inode number of cgroup namespace, included in perf data with
the new PERF_RECORD_NAMESPACES event, as cgroup identifier. With the
assumption that each container is created with it's own cgroup namespace,
this allows assessment/analysis of multiple containers at once.

Shown below is the output of perf report, sorted based on cgroup id, on
a system that was running three containers at the time of perf record
and clearly showing one of the containers' considerable use of kernel
memory in comparison with others:


$ perf report -s cgroup_id,sample --stdio
#
# Total Lost Samples: 0
#
# Samples: 2K of event 'kmem:kmalloc'
# Event count (approx.): 2176
#
# Overhead  cgroup id (dev/inode)   Samples
#   .  
#
89.20%  3/0xf0cf   1941
 3.31%  3/0xeffb 72
 3.08%  3/0xf0d0 67
 2.25%  3/0xf0d1 49
 2.16%  0/0x047

Signed-off-by: Hari Bathini 
---

* No changes since v4.


 tools/perf/util/hist.c |7 +++
 tools/perf/util/hist.h |1 +
 tools/perf/util/sort.c |   41 +
 tools/perf/util/sort.h |7 +++
 4 files changed, 56 insertions(+)

diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 6770a96..9996e0c 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -2,6 +2,7 @@
 #include "build-id.h"
 #include "hist.h"
 #include "session.h"
+#include "namespaces.h"
 #include "sort.h"
 #include "evlist.h"
 #include "evsel.h"
@@ -168,6 +169,7 @@ void hists__calc_col_len(struct hists *hists, struct 
hist_entry *h)
hists__set_unres_dso_col_len(hists, HISTC_MEM_DADDR_DSO);
}
 
+   hists__new_col_len(hists, HISTC_CGROUP_ID, 20);
hists__new_col_len(hists, HISTC_CPU, 3);
hists__new_col_len(hists, HISTC_SOCKET, 6);
hists__new_col_len(hists, HISTC_MEM_LOCKED, 6);
@@ -573,9 +575,14 @@ __hists__add_entry(struct hists *hists,
   bool sample_self,
   struct hist_entry_ops *ops)
 {
+   struct namespaces *ns = thread__namespaces(al->thread);
struct hist_entry entry = {
.thread = al->thread,
.comm = thread__comm(al->thread),
+   .cgroup_id = {
+   .dev = ns ? ns->link_info[CGROUP_NS_INDEX].dev : 0,
+   .ino = ns ? ns->link_info[CGROUP_NS_INDEX].ino : 0,
+   },
.ms = {
.map= al->map,
.sym= al->sym,
diff --git a/tools/perf/util/hist.h b/tools/perf/util/hist.h
index d4b6514..d7696fd 100644
--- a/tools/perf/util/hist.h
+++ b/tools/perf/util/hist.h
@@ -30,6 +30,7 @@ enum hist_column {
HISTC_DSO,
HISTC_THREAD,
HISTC_COMM,
+   HISTC_CGROUP_ID,
HISTC_PARENT,
HISTC_CPU,
HISTC_SOCKET,
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index df622f4..9f5f404 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -536,6 +536,46 @@ struct sort_entry sort_cpu = {
.se_width_idx   = HISTC_CPU,
 };
 
+/* --sort cgroup_id */
+
+static int64_t _sort__cgroup_dev_cmp(u64 left_dev, u64 right_dev)
+{
+   return (int64_t)(right_dev - left_dev);
+}
+
+static int64_t _sort__cgroup_inode_cmp(u64 left_ino, u64 right_ino)
+{
+   return (int64_t)(right_ino - left_ino);
+}
+
+static int64_t
+sort__cgroup_id_cmp(struct hist_entry *left, struct hist_entry *right)
+{
+   int64_t ret;
+
+   ret = _sort__cgroup_dev_cmp(right->cgroup_id.dev, left->cgroup_id.dev);
+   if (ret != 0)
+   return ret;
+
+   return _sort__cgroup_inode_cmp(right->cgroup_id.ino,
+  left->cgroup_id.ino);
+}
+
+static int hist_entry__cgroup_id_snprintf(struct hist_entry *he,
+ char *bf, size_t size,
+ unsigned int width __maybe_unused)
+{
+   return repsep_snprintf(bf, size, "%lu/0x%lx", he->cgroup_id.dev,
+  he->cgroup_id.ino);
+}
+
+struct sort_entry sort_cgroup_id = {
+   .se_header  = "cgroup id (dev/inode)",
+   .se_cmp = sort__cgroup_id_cmp,
+   .se_snprintf= hist_entry__cgroup_id_snprintf,
+   .se_width_idx   = HISTC_CGROUP_ID,
+};
+
 /* --sort socket */
 
 static int64_t
@@ -1418,6 +1458,7 @@ static struct sort_dimension common_sort_dimensions[] = {
DIM(SORT_GLOBAL_WEIGHT, "weight", sort_global_weight),
DIM(SORT_TRANSACTION, "transaction", sort_transaction),
DIM(SORT_TRACE, "trace", sort_trace),

[RESEND PATCH v5 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info

2017-01-17 Thread Hari Bathini
With the advert of container technologies like docker, that depend
on namespaces for isolation, there is a need for tracing support for
namespaces. This patch introduces new PERF_RECORD_NAMESPACES event
for tracing based on namespaces related info.

Signed-off-by: Hari Bathini 
---

Changes from v4:
* Added nr_namespaces to PERF_RECORD_NAMESPACES record. Also added the
  name of the namespaces.


 include/linux/perf_event.h  |2 +
 include/uapi/linux/perf_event.h |   38 ++
 kernel/events/core.c|  142 +++
 kernel/fork.c   |3 +
 kernel/nsproxy.c|5 +
 5 files changed, 189 insertions(+), 1 deletion(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 78ed810..063a99f 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1110,6 +1110,7 @@ extern int perf_unregister_guest_info_callbacks(struct 
perf_guest_info_callbacks
 
 extern void perf_event_exec(void);
 extern void perf_event_comm(struct task_struct *tsk, bool exec);
+extern void perf_event_namespaces(struct task_struct *tsk);
 extern void perf_event_fork(struct task_struct *tsk);
 
 /* Callchains */
@@ -1313,6 +1314,7 @@ static inline int perf_unregister_guest_info_callbacks
 static inline void perf_event_mmap(struct vm_area_struct *vma) { }
 static inline void perf_event_exec(void)   { }
 static inline void perf_event_comm(struct task_struct *tsk, bool exec) { }
+static inline void perf_event_namespaces(struct task_struct *tsk)  { }
 static inline void perf_event_fork(struct task_struct *tsk){ }
 static inline void perf_event_init(void)   { }
 static inline int  perf_swevent_get_recursion_context(void){ 
return -1; }
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index c66a485..ee60f54 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -344,7 +344,8 @@ struct perf_event_attr {
use_clockid:  1, /* use @clockid for time 
fields */
context_switch :  1, /* context switch data */
write_backward :  1, /* Write ring buffer from 
end to beginning */
-   __reserved_1   : 36;
+   namespaces :  1, /* include namespaces data 
*/
+   __reserved_1   : 35;
 
union {
__u32   wakeup_events;/* wakeup every n events */
@@ -610,6 +611,29 @@ struct perf_event_header {
__u16   size;
 };
 
+/*
+ * The maximum size of the name of each namespace
+ */
+#define NS_NAME_SIZE   8
+
+struct perf_ns_link_info {
+   charname[NS_NAME_SIZE];
+   __u64   dev;
+   __u64   ino;
+};
+
+enum {
+   NET_NS_INDEX= 0,
+   UTS_NS_INDEX= 1,
+   IPC_NS_INDEX= 2,
+   PID_NS_INDEX= 3,
+   USER_NS_INDEX   = 4,
+   MNT_NS_INDEX= 5,
+   CGROUP_NS_INDEX = 6,
+
+   NAMESPACES_MAX, /* maximum available namespaces */
+};
+
 enum perf_event_type {
 
/*
@@ -862,6 +886,18 @@ enum perf_event_type {
 */
PERF_RECORD_SWITCH_CPU_WIDE = 15,
 
+   /*
+* struct {
+*  struct perf_event_headerheader;
+*  u32 pid;
+*  u32 tid;
+*  u32 nr_namespaces;
+*  struct namespace_link_info  link_info[NAMESPACES_MAX];
+*  struct sample_idsample_id;
+* };
+*/
+   PERF_RECORD_NAMESPACES  = 16,
+
PERF_RECORD_MAX,/* non-ABI */
 };
 
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 110b38a..15ebae1 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -46,6 +46,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "internal.h"
 
@@ -375,6 +377,7 @@ static DEFINE_PER_CPU(struct pmu_event_list, pmu_sb_events);
 
 static atomic_t nr_mmap_events __read_mostly;
 static atomic_t nr_comm_events __read_mostly;
+static atomic_t nr_namespaces_events __read_mostly;
 static atomic_t nr_task_events __read_mostly;
 static atomic_t nr_freq_events __read_mostly;
 static atomic_t nr_switch_events __read_mostly;
@@ -3908,6 +3911,8 @@ static void unaccount_event(struct perf_event *event)
atomic_dec(_mmap_events);
if (event->attr.comm)
atomic_dec(_comm_events);
+   if (event->attr.namespaces)
+   atomic_dec(_namespaces_events);
if (event->attr.task)
atomic_dec(_task_events);
if (event->attr.freq)
@@ -6408,6 +6413,7 @@ 

[RESEND PATCH v5 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info

2017-01-17 Thread Hari Bathini
With the advert of container technologies like docker, that depend
on namespaces for isolation, there is a need for tracing support for
namespaces. This patch introduces new PERF_RECORD_NAMESPACES event
for tracing based on namespaces related info.

Signed-off-by: Hari Bathini 
---

Changes from v4:
* Added nr_namespaces to PERF_RECORD_NAMESPACES record. Also added the
  name of the namespaces.


 include/linux/perf_event.h  |2 +
 include/uapi/linux/perf_event.h |   38 ++
 kernel/events/core.c|  142 +++
 kernel/fork.c   |3 +
 kernel/nsproxy.c|5 +
 5 files changed, 189 insertions(+), 1 deletion(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 78ed810..063a99f 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -1110,6 +1110,7 @@ extern int perf_unregister_guest_info_callbacks(struct 
perf_guest_info_callbacks
 
 extern void perf_event_exec(void);
 extern void perf_event_comm(struct task_struct *tsk, bool exec);
+extern void perf_event_namespaces(struct task_struct *tsk);
 extern void perf_event_fork(struct task_struct *tsk);
 
 /* Callchains */
@@ -1313,6 +1314,7 @@ static inline int perf_unregister_guest_info_callbacks
 static inline void perf_event_mmap(struct vm_area_struct *vma) { }
 static inline void perf_event_exec(void)   { }
 static inline void perf_event_comm(struct task_struct *tsk, bool exec) { }
+static inline void perf_event_namespaces(struct task_struct *tsk)  { }
 static inline void perf_event_fork(struct task_struct *tsk){ }
 static inline void perf_event_init(void)   { }
 static inline int  perf_swevent_get_recursion_context(void){ 
return -1; }
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index c66a485..ee60f54 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -344,7 +344,8 @@ struct perf_event_attr {
use_clockid:  1, /* use @clockid for time 
fields */
context_switch :  1, /* context switch data */
write_backward :  1, /* Write ring buffer from 
end to beginning */
-   __reserved_1   : 36;
+   namespaces :  1, /* include namespaces data 
*/
+   __reserved_1   : 35;
 
union {
__u32   wakeup_events;/* wakeup every n events */
@@ -610,6 +611,29 @@ struct perf_event_header {
__u16   size;
 };
 
+/*
+ * The maximum size of the name of each namespace
+ */
+#define NS_NAME_SIZE   8
+
+struct perf_ns_link_info {
+   charname[NS_NAME_SIZE];
+   __u64   dev;
+   __u64   ino;
+};
+
+enum {
+   NET_NS_INDEX= 0,
+   UTS_NS_INDEX= 1,
+   IPC_NS_INDEX= 2,
+   PID_NS_INDEX= 3,
+   USER_NS_INDEX   = 4,
+   MNT_NS_INDEX= 5,
+   CGROUP_NS_INDEX = 6,
+
+   NAMESPACES_MAX, /* maximum available namespaces */
+};
+
 enum perf_event_type {
 
/*
@@ -862,6 +886,18 @@ enum perf_event_type {
 */
PERF_RECORD_SWITCH_CPU_WIDE = 15,
 
+   /*
+* struct {
+*  struct perf_event_headerheader;
+*  u32 pid;
+*  u32 tid;
+*  u32 nr_namespaces;
+*  struct namespace_link_info  link_info[NAMESPACES_MAX];
+*  struct sample_idsample_id;
+* };
+*/
+   PERF_RECORD_NAMESPACES  = 16,
+
PERF_RECORD_MAX,/* non-ABI */
 };
 
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 110b38a..15ebae1 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -46,6 +46,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "internal.h"
 
@@ -375,6 +377,7 @@ static DEFINE_PER_CPU(struct pmu_event_list, pmu_sb_events);
 
 static atomic_t nr_mmap_events __read_mostly;
 static atomic_t nr_comm_events __read_mostly;
+static atomic_t nr_namespaces_events __read_mostly;
 static atomic_t nr_task_events __read_mostly;
 static atomic_t nr_freq_events __read_mostly;
 static atomic_t nr_switch_events __read_mostly;
@@ -3908,6 +3911,8 @@ static void unaccount_event(struct perf_event *event)
atomic_dec(_mmap_events);
if (event->attr.comm)
atomic_dec(_comm_events);
+   if (event->attr.namespaces)
+   atomic_dec(_namespaces_events);
if (event->attr.task)
atomic_dec(_task_events);
if (event->attr.freq)
@@ -6408,6 +6413,7 @@ static void 

Re: [PATCH v11 08/12] drm/mediatek: add dsi interrupt control

2017-01-17 Thread CK Hu
Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> From: shaoming chen 
> 
> add dsi interrupt control
> 
> Signed-off-by: shaoming chen 

Acked-by: CK Hu 

> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 92 
> ++
>  1 file changed, 92 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 6f4b3bb..474861a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -29,6 +30,16 @@
>  
>  #define DSI_START0x00
>  
> +#define DSI_INTEN0x08
> +
> +#define DSI_INTSTA   0x0c
> +#define LPRX_RD_RDY_INT_FLAG BIT(0)
> +#define CMD_DONE_INT_FLAGBIT(1)
> +#define TE_RDY_INT_FLAG  BIT(2)
> +#define VM_DONE_INT_FLAG BIT(3)
> +#define EXT_TE_RDY_INT_FLAG  BIT(4)
> +#define DSI_BUSY BIT(31)
> +
>  #define DSI_CON_CTRL 0x10
>  #define DSI_RESETBIT(0)
>  #define DSI_EN   BIT(1)
> @@ -71,6 +82,9 @@
>  
>  #define DSI_HSTX_CKL_WC  0x64
>  
> +#define DSI_RACK 0x84
> +#define RACK BIT(0)
> +
>  #define DSI_PHY_LCCON0x104
>  #define LC_HS_TX_EN  BIT(0)
>  #define LC_ULPM_EN   BIT(1)
> @@ -137,6 +151,8 @@ struct mtk_dsi {
>   struct videomode vm;
>   int refcount;
>   bool enabled;
> + u32 irq_data;
> + wait_queue_head_t irq_wait_queue;
>  };
>  
>  static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
> @@ -469,6 +485,64 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
>   writel(1, dsi->regs + DSI_START);
>  }
>  
> +static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
> +{
> + u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> +
> + writel(inten, dsi->regs + DSI_INTEN);
> +}
> +
> +static void mtk_dsi_irq_data_set(struct mtk_dsi *dsi, u32 irq_bit)
> +{
> + dsi->irq_data |= irq_bit;
> +}
> +
> +static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 
> irq_bit)
> +{
> + dsi->irq_data &= ~irq_bit;
> +}
> +
> +static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 
> irq_flag,
> +  unsigned int timeout)
> +{
> + s32 ret = 0;
> + unsigned long jiffies = msecs_to_jiffies(timeout);
> +
> + ret = wait_event_interruptible_timeout(dsi->irq_wait_queue,
> +dsi->irq_data & irq_flag,
> +jiffies);
> + if (ret == 0) {
> + DRM_WARN("Wait DSI IRQ(0x%08x) Timeout\n", irq_flag);
> +
> + mtk_dsi_enable(dsi);
> + mtk_dsi_reset_engine(dsi);
> + }
> +
> + return ret;
> +}
> +
> +static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
> +{
> + struct mtk_dsi *dsi = dev_id;
> + u32 status, tmp;
> + u32 flag = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> +
> + status = readl(dsi->regs + DSI_INTSTA) & flag;
> +
> + if (status) {
> + do {
> + mtk_dsi_mask(dsi, DSI_RACK, RACK, RACK);
> + tmp = readl(dsi->regs + DSI_INTSTA);
> + } while (tmp & DSI_BUSY);
> +
> + mtk_dsi_mask(dsi, DSI_INTSTA, status, 0);
> + mtk_dsi_irq_data_set(dsi, status);
> + wake_up_interruptible(>irq_wait_queue);
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
>  static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>  {
>   if (WARN_ON(dsi->refcount == 0))
> @@ -517,6 +591,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>  
>   mtk_dsi_ps_control_vact(dsi);
>   mtk_dsi_config_vdo_timing(dsi);
> + mtk_dsi_set_interrupt_enable(dsi);
>  
>   mtk_dsi_set_mode(dsi);
>   mtk_dsi_clk_hs_mode(dsi, 1);
> @@ -818,6 +893,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>   struct device *dev = >dev;
>   struct device_node *remote_node, *endpoint;
>   struct resource *regs;
> + int irq_num;
>   int comp_id;
>   int ret;
>  
> @@ -894,6 +970,22 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> + irq_num = platform_get_irq(pdev, 0);
> + if (irq_num < 0) {
> + dev_err(>dev, "failed to request dsi irq resource\n");
> + return -EPROBE_DEFER;
> + }
> +
> + irq_set_status_flags(irq_num, IRQ_TYPE_LEVEL_LOW);
> + ret = devm_request_irq(>dev, irq_num, mtk_dsi_irq,
> +IRQF_TRIGGER_LOW, dev_name(>dev), dsi);
> + if (ret) {
> + dev_err(>dev, "failed to request mediatek dsi 

Re: [PATCH v11 08/12] drm/mediatek: add dsi interrupt control

2017-01-17 Thread CK Hu
Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> From: shaoming chen 
> 
> add dsi interrupt control
> 
> Signed-off-by: shaoming chen 

Acked-by: CK Hu 

> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 92 
> ++
>  1 file changed, 92 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 6f4b3bb..474861a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -18,6 +18,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -29,6 +30,16 @@
>  
>  #define DSI_START0x00
>  
> +#define DSI_INTEN0x08
> +
> +#define DSI_INTSTA   0x0c
> +#define LPRX_RD_RDY_INT_FLAG BIT(0)
> +#define CMD_DONE_INT_FLAGBIT(1)
> +#define TE_RDY_INT_FLAG  BIT(2)
> +#define VM_DONE_INT_FLAG BIT(3)
> +#define EXT_TE_RDY_INT_FLAG  BIT(4)
> +#define DSI_BUSY BIT(31)
> +
>  #define DSI_CON_CTRL 0x10
>  #define DSI_RESETBIT(0)
>  #define DSI_EN   BIT(1)
> @@ -71,6 +82,9 @@
>  
>  #define DSI_HSTX_CKL_WC  0x64
>  
> +#define DSI_RACK 0x84
> +#define RACK BIT(0)
> +
>  #define DSI_PHY_LCCON0x104
>  #define LC_HS_TX_EN  BIT(0)
>  #define LC_ULPM_EN   BIT(1)
> @@ -137,6 +151,8 @@ struct mtk_dsi {
>   struct videomode vm;
>   int refcount;
>   bool enabled;
> + u32 irq_data;
> + wait_queue_head_t irq_wait_queue;
>  };
>  
>  static inline struct mtk_dsi *encoder_to_dsi(struct drm_encoder *e)
> @@ -469,6 +485,64 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
>   writel(1, dsi->regs + DSI_START);
>  }
>  
> +static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
> +{
> + u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> +
> + writel(inten, dsi->regs + DSI_INTEN);
> +}
> +
> +static void mtk_dsi_irq_data_set(struct mtk_dsi *dsi, u32 irq_bit)
> +{
> + dsi->irq_data |= irq_bit;
> +}
> +
> +static __maybe_unused void mtk_dsi_irq_data_clear(struct mtk_dsi *dsi, u32 
> irq_bit)
> +{
> + dsi->irq_data &= ~irq_bit;
> +}
> +
> +static __maybe_unused s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 
> irq_flag,
> +  unsigned int timeout)
> +{
> + s32 ret = 0;
> + unsigned long jiffies = msecs_to_jiffies(timeout);
> +
> + ret = wait_event_interruptible_timeout(dsi->irq_wait_queue,
> +dsi->irq_data & irq_flag,
> +jiffies);
> + if (ret == 0) {
> + DRM_WARN("Wait DSI IRQ(0x%08x) Timeout\n", irq_flag);
> +
> + mtk_dsi_enable(dsi);
> + mtk_dsi_reset_engine(dsi);
> + }
> +
> + return ret;
> +}
> +
> +static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
> +{
> + struct mtk_dsi *dsi = dev_id;
> + u32 status, tmp;
> + u32 flag = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> +
> + status = readl(dsi->regs + DSI_INTSTA) & flag;
> +
> + if (status) {
> + do {
> + mtk_dsi_mask(dsi, DSI_RACK, RACK, RACK);
> + tmp = readl(dsi->regs + DSI_INTSTA);
> + } while (tmp & DSI_BUSY);
> +
> + mtk_dsi_mask(dsi, DSI_INTSTA, status, 0);
> + mtk_dsi_irq_data_set(dsi, status);
> + wake_up_interruptible(>irq_wait_queue);
> + }
> +
> + return IRQ_HANDLED;
> +}
> +
>  static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
>  {
>   if (WARN_ON(dsi->refcount == 0))
> @@ -517,6 +591,7 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
>  
>   mtk_dsi_ps_control_vact(dsi);
>   mtk_dsi_config_vdo_timing(dsi);
> + mtk_dsi_set_interrupt_enable(dsi);
>  
>   mtk_dsi_set_mode(dsi);
>   mtk_dsi_clk_hs_mode(dsi, 1);
> @@ -818,6 +893,7 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>   struct device *dev = >dev;
>   struct device_node *remote_node, *endpoint;
>   struct resource *regs;
> + int irq_num;
>   int comp_id;
>   int ret;
>  
> @@ -894,6 +970,22 @@ static int mtk_dsi_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> + irq_num = platform_get_irq(pdev, 0);
> + if (irq_num < 0) {
> + dev_err(>dev, "failed to request dsi irq resource\n");
> + return -EPROBE_DEFER;
> + }
> +
> + irq_set_status_flags(irq_num, IRQ_TYPE_LEVEL_LOW);
> + ret = devm_request_irq(>dev, irq_num, mtk_dsi_irq,
> +IRQF_TRIGGER_LOW, dev_name(>dev), dsi);
> + if (ret) {
> + dev_err(>dev, "failed to request mediatek dsi irq\n");
> + return -EPROBE_DEFER;
> + }
> +
> + 

Re: [PATCH v5 0/4] usb: early: add support for early printk through USB3 debug port

2017-01-17 Thread Lu Baolu
Hi Greg,

This patch series has been there for 2 months without
further comments. Will you consider it for usb-next?

Best regards,
Lu Baolu

On 11/15/2016 02:02 PM, Lu Baolu wrote:
> xHCI debug capability (DbC) is an optional but standalone
> functionality provided by an xHCI host controller. With DbC
> hardware initialized, the system will present a debug device
> through the USB3 debug port (normally the first USB3 port).
> The debug device is fully compliant with the USB framework
> and provides the equivalent of a very high performance (USB3)
> full-duplex serial link between the debug host and target.
> The DbC functionality is independent of xHCI host. There
> isn't any precondition from xHCI host side for DbC to work.
>
> This patch set adds support for early printk functionality
> through a USB3 debug port by 1) initializing and enabling
> the DbC hardware during early boot; 2) registering a boot
> console to the system so that early printk messages can go
> through the USB3 debug port. It also includes some lines
> of changes in usb_debug driver so that it can be bound when
> a USB3 debug device is enumerated.
>
> This code is designed to be used only for kernel debugging
> when machine crashes very early before the console code is
> initialized. It makes the life of kernel debugging easier
> when people work with a modern machine without any legacy
> serial ports.
>
> ---
> Change log:
> v4->v5:
>   - add raw_spin_lock to make xdbc_bulk_write() reentrant. 
>
> v3->v4:
>   - Rename the document with .dst suffix.
>   - Add the list of hardware that has been succesfuly
> tested on in the document.
>
> v2->v3:
>   - Removed spinlock usage.
>   - Removed work queue usage.
>   - Refined the user guide document.
>
> v1->v2:
>   - Refactor the duplicate code in xdbc_early_start() and
> xdbc_handle_external_reset().
>   - Free resources when hardware not used any more.
>   - Refine the user guide document.
>
> Lu Baolu (4):
>   usb: dbc: early driver for xhci debug capability
>   x86: add support for earlyprintk via USB3 debug port
>   usb: serial: usb_debug: add support for dbc debug device
>   usb: doc: add document for USB3 debug port usage
>
>  Documentation/kernel-parameters.txt   |1 +
>  Documentation/usb/usb3-debug-port.rst |   95 +++
>  arch/x86/Kconfig.debug|   14 +
>  arch/x86/kernel/early_printk.c|5 +
>  arch/x86/kernel/setup.c   |7 +
>  drivers/usb/Kconfig   |3 +
>  drivers/usb/Makefile  |2 +-
>  drivers/usb/early/Makefile|1 +
>  drivers/usb/early/xhci-dbc.c  | 1068 
> +
>  drivers/usb/early/xhci-dbc.h  |  205 +++
>  drivers/usb/serial/usb_debug.c|   28 +-
>  include/linux/usb/xhci-dbgp.h |   22 +
>  12 files changed, 1447 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/usb/usb3-debug-port.rst
>  create mode 100644 drivers/usb/early/xhci-dbc.c
>  create mode 100644 drivers/usb/early/xhci-dbc.h
>  create mode 100644 include/linux/usb/xhci-dbgp.h
>



Re: [PATCH v5 0/4] usb: early: add support for early printk through USB3 debug port

2017-01-17 Thread Lu Baolu
Hi Greg,

This patch series has been there for 2 months without
further comments. Will you consider it for usb-next?

Best regards,
Lu Baolu

On 11/15/2016 02:02 PM, Lu Baolu wrote:
> xHCI debug capability (DbC) is an optional but standalone
> functionality provided by an xHCI host controller. With DbC
> hardware initialized, the system will present a debug device
> through the USB3 debug port (normally the first USB3 port).
> The debug device is fully compliant with the USB framework
> and provides the equivalent of a very high performance (USB3)
> full-duplex serial link between the debug host and target.
> The DbC functionality is independent of xHCI host. There
> isn't any precondition from xHCI host side for DbC to work.
>
> This patch set adds support for early printk functionality
> through a USB3 debug port by 1) initializing and enabling
> the DbC hardware during early boot; 2) registering a boot
> console to the system so that early printk messages can go
> through the USB3 debug port. It also includes some lines
> of changes in usb_debug driver so that it can be bound when
> a USB3 debug device is enumerated.
>
> This code is designed to be used only for kernel debugging
> when machine crashes very early before the console code is
> initialized. It makes the life of kernel debugging easier
> when people work with a modern machine without any legacy
> serial ports.
>
> ---
> Change log:
> v4->v5:
>   - add raw_spin_lock to make xdbc_bulk_write() reentrant. 
>
> v3->v4:
>   - Rename the document with .dst suffix.
>   - Add the list of hardware that has been succesfuly
> tested on in the document.
>
> v2->v3:
>   - Removed spinlock usage.
>   - Removed work queue usage.
>   - Refined the user guide document.
>
> v1->v2:
>   - Refactor the duplicate code in xdbc_early_start() and
> xdbc_handle_external_reset().
>   - Free resources when hardware not used any more.
>   - Refine the user guide document.
>
> Lu Baolu (4):
>   usb: dbc: early driver for xhci debug capability
>   x86: add support for earlyprintk via USB3 debug port
>   usb: serial: usb_debug: add support for dbc debug device
>   usb: doc: add document for USB3 debug port usage
>
>  Documentation/kernel-parameters.txt   |1 +
>  Documentation/usb/usb3-debug-port.rst |   95 +++
>  arch/x86/Kconfig.debug|   14 +
>  arch/x86/kernel/early_printk.c|5 +
>  arch/x86/kernel/setup.c   |7 +
>  drivers/usb/Kconfig   |3 +
>  drivers/usb/Makefile  |2 +-
>  drivers/usb/early/Makefile|1 +
>  drivers/usb/early/xhci-dbc.c  | 1068 
> +
>  drivers/usb/early/xhci-dbc.h  |  205 +++
>  drivers/usb/serial/usb_debug.c|   28 +-
>  include/linux/usb/xhci-dbgp.h |   22 +
>  12 files changed, 1447 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/usb/usb3-debug-port.rst
>  create mode 100644 drivers/usb/early/xhci-dbc.c
>  create mode 100644 drivers/usb/early/xhci-dbc.h
>  create mode 100644 include/linux/usb/xhci-dbgp.h
>



[PATCH] mm/memblock.c: remove unnecessary log and clean up

2017-01-17 Thread Miles Chen
There is no variable named flags in memblock_add() and memblock_reserve()
so remove it from the log messages.
This patch also cleans up the type casting for phys_addr_t by using
%pa to print them.

Signed-off-by: Miles Chen 
---
 mm/memblock.c | 54 +-
 1 file changed, 25 insertions(+), 29 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 7608bc3..8683f02 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -611,10 +611,10 @@ int __init_memblock memblock_add_node(phys_addr_t base, 
phys_addr_t size,
 
 int __init_memblock memblock_add(phys_addr_t base, phys_addr_t size)
 {
-   memblock_dbg("memblock_add: [%#016llx-%#016llx] flags %#02lx %pF\n",
-(unsigned long long)base,
-(unsigned long long)base + size - 1,
-0UL, (void *)_RET_IP_);
+   phys_addr_t end = base + size - 1;
+
+   memblock_dbg("memblock_add: [%pa-%pa] %pF\n",
+, , (void *)_RET_IP_);
 
return memblock_add_range(, base, size, MAX_NUMNODES, 
0);
 }
@@ -718,10 +718,10 @@ int __init_memblock memblock_remove(phys_addr_t base, 
phys_addr_t size)
 
 int __init_memblock memblock_free(phys_addr_t base, phys_addr_t size)
 {
-   memblock_dbg("   memblock_free: [%#016llx-%#016llx] %pF\n",
-(unsigned long long)base,
-(unsigned long long)base + size - 1,
-(void *)_RET_IP_);
+   phys_addr_t end = base + size - 1;
+
+   memblock_dbg("   memblock_free: [%pa-%pa] %pF\n",
+, , (void *)_RET_IP_);
 
kmemleak_free_part_phys(base, size);
return memblock_remove_range(, base, size);
@@ -729,10 +729,10 @@ int __init_memblock memblock_free(phys_addr_t base, 
phys_addr_t size)
 
 int __init_memblock memblock_reserve(phys_addr_t base, phys_addr_t size)
 {
-   memblock_dbg("memblock_reserve: [%#016llx-%#016llx] flags %#02lx %pF\n",
-(unsigned long long)base,
-(unsigned long long)base + size - 1,
-0UL, (void *)_RET_IP_);
+   phys_addr_t end = base + size - 1;
+
+   memblock_dbg("memblock_reserve: [%pa-%pa] %pF\n",
+, , (void *)_RET_IP_);
 
return memblock_add_range(, base, size, MAX_NUMNODES, 
0);
 }
@@ -1202,8 +1202,8 @@ phys_addr_t __init memblock_alloc_base(phys_addr_t size, 
phys_addr_t align, phys
alloc = __memblock_alloc_base(size, align, max_addr);
 
if (alloc == 0)
-   panic("ERROR: Failed to allocate 0x%llx bytes below 0x%llx.\n",
- (unsigned long long) size, (unsigned long long) max_addr);
+   panic("ERROR: Failed to allocate %pa bytes below %pa.\n",
+ , _addr);
 
return alloc;
 }
@@ -1673,7 +1673,7 @@ phys_addr_t __init_memblock 
memblock_get_current_limit(void)
 
 static void __init_memblock memblock_dump(struct memblock_type *type, char 
*name)
 {
-   unsigned long long base, size;
+   phys_addr_t base, end, size;
unsigned long flags;
int idx;
struct memblock_region *rgn;
@@ -1685,23 +1685,24 @@ static void __init_memblock memblock_dump(struct 
memblock_type *type, char *name
 
base = rgn->base;
size = rgn->size;
+   end = base + size - 1;
flags = rgn->flags;
 #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
if (memblock_get_region_node(rgn) != MAX_NUMNODES)
snprintf(nid_buf, sizeof(nid_buf), " on node %d",
 memblock_get_region_node(rgn));
 #endif
-   pr_info(" %s[%#x]\t[%#016llx-%#016llx], %#llx bytes%s flags: 
%#lx\n",
-   name, idx, base, base + size - 1, size, nid_buf, flags);
+   pr_info(" %s[%#x]\t[%pa-%pa], %pa bytes%s flags: %#lx\n",
+   name, idx, , , , nid_buf, flags);
}
 }
 
 void __init_memblock __memblock_dump_all(void)
 {
pr_info("MEMBLOCK configuration:\n");
-   pr_info(" memory size = %#llx reserved size = %#llx\n",
-   (unsigned long long)memblock.memory.total_size,
-   (unsigned long long)memblock.reserved.total_size);
+   pr_info(" memory size = %pa reserved size = %pa\n",
+   _size,
+   _size);
 
memblock_dump(, "memory");
memblock_dump(, "reserved");
@@ -1727,19 +1728,14 @@ static int memblock_debug_show(struct seq_file *m, void 
*private)
struct memblock_type *type = m->private;
struct memblock_region *reg;
int i;
+   phys_addr_t end;
 
for (i = 0; i < type->cnt; i++) {
reg = >regions[i];
-   seq_printf(m, "%4d: ", i);
-   if (sizeof(phys_addr_t) == 4)
-   seq_printf(m, "0x%08lx..0x%08lx\n",
-  (unsigned long)reg->base,
-   

[PATCH] mm/memblock.c: remove unnecessary log and clean up

2017-01-17 Thread Miles Chen
There is no variable named flags in memblock_add() and memblock_reserve()
so remove it from the log messages.
This patch also cleans up the type casting for phys_addr_t by using
%pa to print them.

Signed-off-by: Miles Chen 
---
 mm/memblock.c | 54 +-
 1 file changed, 25 insertions(+), 29 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 7608bc3..8683f02 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -611,10 +611,10 @@ int __init_memblock memblock_add_node(phys_addr_t base, 
phys_addr_t size,
 
 int __init_memblock memblock_add(phys_addr_t base, phys_addr_t size)
 {
-   memblock_dbg("memblock_add: [%#016llx-%#016llx] flags %#02lx %pF\n",
-(unsigned long long)base,
-(unsigned long long)base + size - 1,
-0UL, (void *)_RET_IP_);
+   phys_addr_t end = base + size - 1;
+
+   memblock_dbg("memblock_add: [%pa-%pa] %pF\n",
+, , (void *)_RET_IP_);
 
return memblock_add_range(, base, size, MAX_NUMNODES, 
0);
 }
@@ -718,10 +718,10 @@ int __init_memblock memblock_remove(phys_addr_t base, 
phys_addr_t size)
 
 int __init_memblock memblock_free(phys_addr_t base, phys_addr_t size)
 {
-   memblock_dbg("   memblock_free: [%#016llx-%#016llx] %pF\n",
-(unsigned long long)base,
-(unsigned long long)base + size - 1,
-(void *)_RET_IP_);
+   phys_addr_t end = base + size - 1;
+
+   memblock_dbg("   memblock_free: [%pa-%pa] %pF\n",
+, , (void *)_RET_IP_);
 
kmemleak_free_part_phys(base, size);
return memblock_remove_range(, base, size);
@@ -729,10 +729,10 @@ int __init_memblock memblock_free(phys_addr_t base, 
phys_addr_t size)
 
 int __init_memblock memblock_reserve(phys_addr_t base, phys_addr_t size)
 {
-   memblock_dbg("memblock_reserve: [%#016llx-%#016llx] flags %#02lx %pF\n",
-(unsigned long long)base,
-(unsigned long long)base + size - 1,
-0UL, (void *)_RET_IP_);
+   phys_addr_t end = base + size - 1;
+
+   memblock_dbg("memblock_reserve: [%pa-%pa] %pF\n",
+, , (void *)_RET_IP_);
 
return memblock_add_range(, base, size, MAX_NUMNODES, 
0);
 }
@@ -1202,8 +1202,8 @@ phys_addr_t __init memblock_alloc_base(phys_addr_t size, 
phys_addr_t align, phys
alloc = __memblock_alloc_base(size, align, max_addr);
 
if (alloc == 0)
-   panic("ERROR: Failed to allocate 0x%llx bytes below 0x%llx.\n",
- (unsigned long long) size, (unsigned long long) max_addr);
+   panic("ERROR: Failed to allocate %pa bytes below %pa.\n",
+ , _addr);
 
return alloc;
 }
@@ -1673,7 +1673,7 @@ phys_addr_t __init_memblock 
memblock_get_current_limit(void)
 
 static void __init_memblock memblock_dump(struct memblock_type *type, char 
*name)
 {
-   unsigned long long base, size;
+   phys_addr_t base, end, size;
unsigned long flags;
int idx;
struct memblock_region *rgn;
@@ -1685,23 +1685,24 @@ static void __init_memblock memblock_dump(struct 
memblock_type *type, char *name
 
base = rgn->base;
size = rgn->size;
+   end = base + size - 1;
flags = rgn->flags;
 #ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
if (memblock_get_region_node(rgn) != MAX_NUMNODES)
snprintf(nid_buf, sizeof(nid_buf), " on node %d",
 memblock_get_region_node(rgn));
 #endif
-   pr_info(" %s[%#x]\t[%#016llx-%#016llx], %#llx bytes%s flags: 
%#lx\n",
-   name, idx, base, base + size - 1, size, nid_buf, flags);
+   pr_info(" %s[%#x]\t[%pa-%pa], %pa bytes%s flags: %#lx\n",
+   name, idx, , , , nid_buf, flags);
}
 }
 
 void __init_memblock __memblock_dump_all(void)
 {
pr_info("MEMBLOCK configuration:\n");
-   pr_info(" memory size = %#llx reserved size = %#llx\n",
-   (unsigned long long)memblock.memory.total_size,
-   (unsigned long long)memblock.reserved.total_size);
+   pr_info(" memory size = %pa reserved size = %pa\n",
+   _size,
+   _size);
 
memblock_dump(, "memory");
memblock_dump(, "reserved");
@@ -1727,19 +1728,14 @@ static int memblock_debug_show(struct seq_file *m, void 
*private)
struct memblock_type *type = m->private;
struct memblock_region *reg;
int i;
+   phys_addr_t end;
 
for (i = 0; i < type->cnt; i++) {
reg = >regions[i];
-   seq_printf(m, "%4d: ", i);
-   if (sizeof(phys_addr_t) == 4)
-   seq_printf(m, "0x%08lx..0x%08lx\n",
-  (unsigned long)reg->base,
-  (unsigned 

[PATCH 3/6] usb: xhci-mtk: add reference clock

2017-01-17 Thread Chunfeng Yun
usually, the reference clock comes from 26M oscillator directly,
but some SoCs are not, add it for compatibility.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci-mtk.c |   15 +++
 drivers/usb/host/xhci-mtk.h |1 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 1094ebd..4d75ac5 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -212,6 +212,12 @@ static int xhci_mtk_clks_enable(struct xhci_hcd_mtk *mtk)
 {
int ret;
 
+   ret = clk_prepare_enable(mtk->ref_clk);
+   if (ret) {
+   dev_err(mtk->dev, "failed to enable ref_clk\n");
+   goto ref_clk_err;
+   }
+
ret = clk_prepare_enable(mtk->sys_clk);
if (ret) {
dev_err(mtk->dev, "failed to enable sys_clk\n");
@@ -238,6 +244,8 @@ static int xhci_mtk_clks_enable(struct xhci_hcd_mtk *mtk)
 usb_p0_err:
clk_disable_unprepare(mtk->sys_clk);
 sys_clk_err:
+   clk_disable_unprepare(mtk->ref_clk);
+ref_clk_err:
return -EINVAL;
 }
 
@@ -248,6 +256,7 @@ static void xhci_mtk_clks_disable(struct xhci_hcd_mtk *mtk)
clk_disable_unprepare(mtk->wk_deb_p0);
}
clk_disable_unprepare(mtk->sys_clk);
+   clk_disable_unprepare(mtk->ref_clk);
 }
 
 /* only clocks can be turn off for ip-sleep wakeup mode */
@@ -550,6 +559,12 @@ static int xhci_mtk_probe(struct platform_device *pdev)
return PTR_ERR(mtk->sys_clk);
}
 
+   mtk->ref_clk = devm_clk_get(dev, "ref_ck");
+   if (IS_ERR(mtk->ref_clk)) {
+   dev_err(dev, "fail to get ref_ck\n");
+   return PTR_ERR(mtk->ref_clk);
+   }
+
mtk->lpm_support = of_property_read_bool(node, "usb3-lpm-capable");
 
ret = usb_wakeup_of_property_parse(mtk, node);
diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
index 2845c49..3aa5e1d 100644
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -124,6 +124,7 @@ struct xhci_hcd_mtk {
struct regulator *vusb33;
struct regulator *vbus;
struct clk *sys_clk;/* sys and mac clock */
+   struct clk *ref_clk;
struct clk *wk_deb_p0;  /* port0's wakeup debounce clock */
struct clk *wk_deb_p1;
struct regmap *pericfg;
-- 
1.7.9.5



[PATCH 3/6] usb: xhci-mtk: add reference clock

2017-01-17 Thread Chunfeng Yun
usually, the reference clock comes from 26M oscillator directly,
but some SoCs are not, add it for compatibility.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci-mtk.c |   15 +++
 drivers/usb/host/xhci-mtk.h |1 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 1094ebd..4d75ac5 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -212,6 +212,12 @@ static int xhci_mtk_clks_enable(struct xhci_hcd_mtk *mtk)
 {
int ret;
 
+   ret = clk_prepare_enable(mtk->ref_clk);
+   if (ret) {
+   dev_err(mtk->dev, "failed to enable ref_clk\n");
+   goto ref_clk_err;
+   }
+
ret = clk_prepare_enable(mtk->sys_clk);
if (ret) {
dev_err(mtk->dev, "failed to enable sys_clk\n");
@@ -238,6 +244,8 @@ static int xhci_mtk_clks_enable(struct xhci_hcd_mtk *mtk)
 usb_p0_err:
clk_disable_unprepare(mtk->sys_clk);
 sys_clk_err:
+   clk_disable_unprepare(mtk->ref_clk);
+ref_clk_err:
return -EINVAL;
 }
 
@@ -248,6 +256,7 @@ static void xhci_mtk_clks_disable(struct xhci_hcd_mtk *mtk)
clk_disable_unprepare(mtk->wk_deb_p0);
}
clk_disable_unprepare(mtk->sys_clk);
+   clk_disable_unprepare(mtk->ref_clk);
 }
 
 /* only clocks can be turn off for ip-sleep wakeup mode */
@@ -550,6 +559,12 @@ static int xhci_mtk_probe(struct platform_device *pdev)
return PTR_ERR(mtk->sys_clk);
}
 
+   mtk->ref_clk = devm_clk_get(dev, "ref_ck");
+   if (IS_ERR(mtk->ref_clk)) {
+   dev_err(dev, "fail to get ref_ck\n");
+   return PTR_ERR(mtk->ref_clk);
+   }
+
mtk->lpm_support = of_property_read_bool(node, "usb3-lpm-capable");
 
ret = usb_wakeup_of_property_parse(mtk, node);
diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
index 2845c49..3aa5e1d 100644
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -124,6 +124,7 @@ struct xhci_hcd_mtk {
struct regulator *vusb33;
struct regulator *vbus;
struct clk *sys_clk;/* sys and mac clock */
+   struct clk *ref_clk;
struct clk *wk_deb_p0;  /* port0's wakeup debounce clock */
struct clk *wk_deb_p1;
struct regmap *pericfg;
-- 
1.7.9.5



[PATCH 2/6] usb: mtu3: add reference clock

2017-01-17 Thread Chunfeng Yun
usually, the reference clock comes from 26M oscillator directly,
but some SoCs are not, add it for compatibility.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3.h  |1 +
 drivers/usb/mtu3/mtu3_plat.c |   21 +++--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index ba9df71..aa6fd6a 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -225,6 +225,7 @@ struct ssusb_mtk {
/* common power & clock */
struct regulator *vusb33;
struct clk *sys_clk;
+   struct clk *ref_clk;
/* otg */
struct otg_switch_mtk otg_switch;
enum usb_dr_mode dr_mode;
diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 6344859..19a345d 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -123,7 +123,13 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
ret = clk_prepare_enable(ssusb->sys_clk);
if (ret) {
dev_err(ssusb->dev, "failed to enable sys_clk\n");
-   goto clk_err;
+   goto sys_clk_err;
+   }
+
+   ret = clk_prepare_enable(ssusb->ref_clk);
+   if (ret) {
+   dev_err(ssusb->dev, "failed to enable ref_clk\n");
+   goto ref_clk_err;
}
 
ret = ssusb_phy_init(ssusb);
@@ -143,8 +149,10 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
 phy_err:
ssusb_phy_exit(ssusb);
 phy_init_err:
+   clk_disable_unprepare(ssusb->ref_clk);
+ref_clk_err:
clk_disable_unprepare(ssusb->sys_clk);
-clk_err:
+sys_clk_err:
regulator_disable(ssusb->vusb33);
 vusb33_err:
 
@@ -154,6 +162,7 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
 static void ssusb_rscs_exit(struct ssusb_mtk *ssusb)
 {
clk_disable_unprepare(ssusb->sys_clk);
+   clk_disable_unprepare(ssusb->ref_clk);
regulator_disable(ssusb->vusb33);
ssusb_phy_power_off(ssusb);
ssusb_phy_exit(ssusb);
@@ -216,6 +225,12 @@ static int get_ssusb_rscs(struct platform_device *pdev, 
struct ssusb_mtk *ssusb)
return PTR_ERR(ssusb->sys_clk);
}
 
+   ssusb->ref_clk = devm_clk_get(dev, "ref_ck");
+   if (IS_ERR(ssusb->ref_clk)) {
+   dev_err(dev, "failed to get ref clock\n");
+   return PTR_ERR(ssusb->ref_clk);
+   }
+
ssusb->num_phys = of_count_phandle_with_args(node,
"phys", "#phy-cells");
if (ssusb->num_phys > 0) {
@@ -428,6 +443,7 @@ static int __maybe_unused mtu3_suspend(struct device *dev)
ssusb_host_disable(ssusb, true);
ssusb_phy_power_off(ssusb);
clk_disable_unprepare(ssusb->sys_clk);
+   clk_disable_unprepare(ssusb->ref_clk);
ssusb_wakeup_enable(ssusb);
 
return 0;
@@ -445,6 +461,7 @@ static int __maybe_unused mtu3_resume(struct device *dev)
 
ssusb_wakeup_disable(ssusb);
clk_prepare_enable(ssusb->sys_clk);
+   clk_prepare_enable(ssusb->ref_clk);
ssusb_phy_power_on(ssusb);
ssusb_host_enable(ssusb);
 
-- 
1.7.9.5



[PATCH 2/6] usb: mtu3: add reference clock

2017-01-17 Thread Chunfeng Yun
usually, the reference clock comes from 26M oscillator directly,
but some SoCs are not, add it for compatibility.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3.h  |1 +
 drivers/usb/mtu3/mtu3_plat.c |   21 +++--
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index ba9df71..aa6fd6a 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -225,6 +225,7 @@ struct ssusb_mtk {
/* common power & clock */
struct regulator *vusb33;
struct clk *sys_clk;
+   struct clk *ref_clk;
/* otg */
struct otg_switch_mtk otg_switch;
enum usb_dr_mode dr_mode;
diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 6344859..19a345d 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -123,7 +123,13 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
ret = clk_prepare_enable(ssusb->sys_clk);
if (ret) {
dev_err(ssusb->dev, "failed to enable sys_clk\n");
-   goto clk_err;
+   goto sys_clk_err;
+   }
+
+   ret = clk_prepare_enable(ssusb->ref_clk);
+   if (ret) {
+   dev_err(ssusb->dev, "failed to enable ref_clk\n");
+   goto ref_clk_err;
}
 
ret = ssusb_phy_init(ssusb);
@@ -143,8 +149,10 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
 phy_err:
ssusb_phy_exit(ssusb);
 phy_init_err:
+   clk_disable_unprepare(ssusb->ref_clk);
+ref_clk_err:
clk_disable_unprepare(ssusb->sys_clk);
-clk_err:
+sys_clk_err:
regulator_disable(ssusb->vusb33);
 vusb33_err:
 
@@ -154,6 +162,7 @@ static int ssusb_rscs_init(struct ssusb_mtk *ssusb)
 static void ssusb_rscs_exit(struct ssusb_mtk *ssusb)
 {
clk_disable_unprepare(ssusb->sys_clk);
+   clk_disable_unprepare(ssusb->ref_clk);
regulator_disable(ssusb->vusb33);
ssusb_phy_power_off(ssusb);
ssusb_phy_exit(ssusb);
@@ -216,6 +225,12 @@ static int get_ssusb_rscs(struct platform_device *pdev, 
struct ssusb_mtk *ssusb)
return PTR_ERR(ssusb->sys_clk);
}
 
+   ssusb->ref_clk = devm_clk_get(dev, "ref_ck");
+   if (IS_ERR(ssusb->ref_clk)) {
+   dev_err(dev, "failed to get ref clock\n");
+   return PTR_ERR(ssusb->ref_clk);
+   }
+
ssusb->num_phys = of_count_phandle_with_args(node,
"phys", "#phy-cells");
if (ssusb->num_phys > 0) {
@@ -428,6 +443,7 @@ static int __maybe_unused mtu3_suspend(struct device *dev)
ssusb_host_disable(ssusb, true);
ssusb_phy_power_off(ssusb);
clk_disable_unprepare(ssusb->sys_clk);
+   clk_disable_unprepare(ssusb->ref_clk);
ssusb_wakeup_enable(ssusb);
 
return 0;
@@ -445,6 +461,7 @@ static int __maybe_unused mtu3_resume(struct device *dev)
 
ssusb_wakeup_disable(ssusb);
clk_prepare_enable(ssusb->sys_clk);
+   clk_prepare_enable(ssusb->ref_clk);
ssusb_phy_power_on(ssusb);
ssusb_host_enable(ssusb);
 
-- 
1.7.9.5



logical cpu number is discontinuity

2017-01-17 Thread Masayoshi Mizuma
Hi,

On v4.9 and v4.10 kernel, when I booted my box which has two nodes and
each nodes have 48 logical cpus (Hyper Threading is enabled),
the logical cpu number is discontinuity as follows.

node 0:  0-23, 256-279
node 1: 24-47, 280-303

So the following shell script fail to run.
---
#!/bin/bash

for ((cpu = 0; cpu < `nproc`; cpu++))
do
taskset -c $cpu ./do_work
done
---

I think the logical cpu number should be continuity like as v4.8 and earlier
because user applications may expect the number is continuity.

I believe this behavior was introduced by the patch series beginning with
the following commit.

f7c2883 x86/acpi: Enable acpi to register all possible cpus at boot time

Do anyone have ideas for fix this behavior...?

FYI.
v4.8 kernel, the logical cpu number is continuity as follows.

node 0:  0-23, 48-71
node 1: 24-47, 72-95

- Masayoshi Mizuma


logical cpu number is discontinuity

2017-01-17 Thread Masayoshi Mizuma
Hi,

On v4.9 and v4.10 kernel, when I booted my box which has two nodes and
each nodes have 48 logical cpus (Hyper Threading is enabled),
the logical cpu number is discontinuity as follows.

node 0:  0-23, 256-279
node 1: 24-47, 280-303

So the following shell script fail to run.
---
#!/bin/bash

for ((cpu = 0; cpu < `nproc`; cpu++))
do
taskset -c $cpu ./do_work
done
---

I think the logical cpu number should be continuity like as v4.8 and earlier
because user applications may expect the number is continuity.

I believe this behavior was introduced by the patch series beginning with
the following commit.

f7c2883 x86/acpi: Enable acpi to register all possible cpus at boot time

Do anyone have ideas for fix this behavior...?

FYI.
v4.8 kernel, the logical cpu number is continuity as follows.

node 0:  0-23, 48-71
node 1: 24-47, 72-95

- Masayoshi Mizuma


[PATCH 1/6] usb: mtu3: get resources that cause deferred probe earlier

2017-01-17 Thread Chunfeng Yun
Some resources such as regulator, clock usually cause deferred
probe, get them earlier to avoid more ineffective processing.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3_plat.c |   24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 7833678..6344859 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -204,6 +204,18 @@ static int get_ssusb_rscs(struct platform_device *pdev, 
struct ssusb_mtk *ssusb)
int i;
int ret;
 
+   ssusb->vusb33 = devm_regulator_get(>dev, "vusb33");
+   if (IS_ERR(ssusb->vusb33)) {
+   dev_err(dev, "failed to get vusb33\n");
+   return PTR_ERR(ssusb->vusb33);
+   }
+
+   ssusb->sys_clk = devm_clk_get(dev, "sys_ck");
+   if (IS_ERR(ssusb->sys_clk)) {
+   dev_err(dev, "failed to get sys clock\n");
+   return PTR_ERR(ssusb->sys_clk);
+   }
+
ssusb->num_phys = of_count_phandle_with_args(node,
"phys", "#phy-cells");
if (ssusb->num_phys > 0) {
@@ -230,18 +242,6 @@ static int get_ssusb_rscs(struct platform_device *pdev, 
struct ssusb_mtk *ssusb)
return PTR_ERR(ssusb->ippc_base);
}
 
-   ssusb->vusb33 = devm_regulator_get(>dev, "vusb33");
-   if (IS_ERR(ssusb->vusb33)) {
-   dev_err(dev, "failed to get vusb33\n");
-   return PTR_ERR(ssusb->vusb33);
-   }
-
-   ssusb->sys_clk = devm_clk_get(dev, "sys_ck");
-   if (IS_ERR(ssusb->sys_clk)) {
-   dev_err(dev, "failed to get sys clock\n");
-   return PTR_ERR(ssusb->sys_clk);
-   }
-
ssusb->dr_mode = usb_get_dr_mode(dev);
if (ssusb->dr_mode == USB_DR_MODE_UNKNOWN) {
dev_err(dev, "dr_mode is error\n");
-- 
1.7.9.5



[PATCH 6/6] dt-bindings: mt8173-mtu3: add reference clock

2017-01-17 Thread Chunfeng Yun
add a reference clock for compatibility

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/usb/mt8173-mtu3.txt|   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt 
b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
index e049d19..8c976cd 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
+++ b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
@@ -10,7 +10,7 @@ Required properties:
  - vusb33-supply : regulator of USB avdd3.3v
  - clocks : a list of phandle + clock-specifier pairs, one for each
entry in clock-names
- - clock-names : must contain "sys_ck" for clock of controller;
+ - clock-names : must contain "sys_ck" and "ref_ck" for clock of controller;
"wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are
depends on "mediatek,enable-wakeup"
  - phys : a list of phandle + phy specifier pairs
@@ -56,10 +56,10 @@ ssusb: usb@11271000 {
phys = <_port0 PHY_TYPE_USB3>,
   <_port1 PHY_TYPE_USB2>;
power-domains = < MT8173_POWER_DOMAIN_USB>;
-   clocks = < CLK_TOP_USB30_SEL>,
+   clocks = < CLK_TOP_USB30_SEL>, <>,
 < CLK_PERI_USB0>,
 < CLK_PERI_USB1>;
-   clock-names = "sys_ck",
+   clock-names = "sys_ck", "ref_ck",
  "wakeup_deb_p0",
  "wakeup_deb_p1";
vusb33-supply = <_vusb_reg>;
@@ -79,8 +79,8 @@ ssusb: usb@11271000 {
reg-names = "mac";
interrupts = ;
power-domains = < MT8173_POWER_DOMAIN_USB>;
-   clocks = < CLK_TOP_USB30_SEL>;
-   clock-names = "sys_ck";
+   clocks = < CLK_TOP_USB30_SEL>, <>;
+   clock-names = "sys_ck", "ref_ck";
vusb33-supply = <_vusb_reg>;
status = "disabled";
};
-- 
1.7.9.5



[PATCH 1/6] usb: mtu3: get resources that cause deferred probe earlier

2017-01-17 Thread Chunfeng Yun
Some resources such as regulator, clock usually cause deferred
probe, get them earlier to avoid more ineffective processing.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3_plat.c |   24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 7833678..6344859 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -204,6 +204,18 @@ static int get_ssusb_rscs(struct platform_device *pdev, 
struct ssusb_mtk *ssusb)
int i;
int ret;
 
+   ssusb->vusb33 = devm_regulator_get(>dev, "vusb33");
+   if (IS_ERR(ssusb->vusb33)) {
+   dev_err(dev, "failed to get vusb33\n");
+   return PTR_ERR(ssusb->vusb33);
+   }
+
+   ssusb->sys_clk = devm_clk_get(dev, "sys_ck");
+   if (IS_ERR(ssusb->sys_clk)) {
+   dev_err(dev, "failed to get sys clock\n");
+   return PTR_ERR(ssusb->sys_clk);
+   }
+
ssusb->num_phys = of_count_phandle_with_args(node,
"phys", "#phy-cells");
if (ssusb->num_phys > 0) {
@@ -230,18 +242,6 @@ static int get_ssusb_rscs(struct platform_device *pdev, 
struct ssusb_mtk *ssusb)
return PTR_ERR(ssusb->ippc_base);
}
 
-   ssusb->vusb33 = devm_regulator_get(>dev, "vusb33");
-   if (IS_ERR(ssusb->vusb33)) {
-   dev_err(dev, "failed to get vusb33\n");
-   return PTR_ERR(ssusb->vusb33);
-   }
-
-   ssusb->sys_clk = devm_clk_get(dev, "sys_ck");
-   if (IS_ERR(ssusb->sys_clk)) {
-   dev_err(dev, "failed to get sys clock\n");
-   return PTR_ERR(ssusb->sys_clk);
-   }
-
ssusb->dr_mode = usb_get_dr_mode(dev);
if (ssusb->dr_mode == USB_DR_MODE_UNKNOWN) {
dev_err(dev, "dr_mode is error\n");
-- 
1.7.9.5



[PATCH 6/6] dt-bindings: mt8173-mtu3: add reference clock

2017-01-17 Thread Chunfeng Yun
add a reference clock for compatibility

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/usb/mt8173-mtu3.txt|   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt 
b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
index e049d19..8c976cd 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
+++ b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
@@ -10,7 +10,7 @@ Required properties:
  - vusb33-supply : regulator of USB avdd3.3v
  - clocks : a list of phandle + clock-specifier pairs, one for each
entry in clock-names
- - clock-names : must contain "sys_ck" for clock of controller;
+ - clock-names : must contain "sys_ck" and "ref_ck" for clock of controller;
"wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are
depends on "mediatek,enable-wakeup"
  - phys : a list of phandle + phy specifier pairs
@@ -56,10 +56,10 @@ ssusb: usb@11271000 {
phys = <_port0 PHY_TYPE_USB3>,
   <_port1 PHY_TYPE_USB2>;
power-domains = < MT8173_POWER_DOMAIN_USB>;
-   clocks = < CLK_TOP_USB30_SEL>,
+   clocks = < CLK_TOP_USB30_SEL>, <>,
 < CLK_PERI_USB0>,
 < CLK_PERI_USB1>;
-   clock-names = "sys_ck",
+   clock-names = "sys_ck", "ref_ck",
  "wakeup_deb_p0",
  "wakeup_deb_p1";
vusb33-supply = <_vusb_reg>;
@@ -79,8 +79,8 @@ ssusb: usb@11271000 {
reg-names = "mac";
interrupts = ;
power-domains = < MT8173_POWER_DOMAIN_USB>;
-   clocks = < CLK_TOP_USB30_SEL>;
-   clock-names = "sys_ck";
+   clocks = < CLK_TOP_USB30_SEL>, <>;
+   clock-names = "sys_ck", "ref_ck";
vusb33-supply = <_vusb_reg>;
status = "disabled";
};
-- 
1.7.9.5



[PATCH 4/6] arm64: dts: mt8173: add reference clock for usb

2017-01-17 Thread Chunfeng Yun
add 26M reference clock for ssusb and xhci nodes

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 07fd2eb..e2862b6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -729,9 +729,11 @@
   < PHY_TYPE_USB2>;
power-domains = < MT8173_POWER_DOMAIN_USB>;
clocks = < CLK_TOP_USB30_SEL>,
+<>,
 < CLK_PERI_USB0>,
 < CLK_PERI_USB1>;
clock-names = "sys_ck",
+ "ref_ck",
  "wakeup_deb_p0",
  "wakeup_deb_p1";
mediatek,syscon-wakeup = <>;
@@ -746,8 +748,8 @@
reg-names = "mac";
interrupts = ;
power-domains = < 
MT8173_POWER_DOMAIN_USB>;
-   clocks = < CLK_TOP_USB30_SEL>;
-   clock-names = "sys_ck";
+   clocks = < CLK_TOP_USB30_SEL>, 
<>;
+   clock-names = "sys_ck", "ref_ck";
status = "disabled";
};
};
-- 
1.7.9.5



[PATCH 5/6] dt-bindings: mt8173-xhci: add reference clock

2017-01-17 Thread Chunfeng Yun
add a reference clock for compatibility

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/usb/mt8173-xhci.txt|   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
index 2a930bd..ab8bb27 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -23,6 +23,7 @@ Required properties:
entry in clock-names
  - clock-names : must contain
"sys_ck": for clock of xHCI MAC
+   "ref_ck": for reference clock of xHCI MAC
"wakeup_deb_p0": for USB wakeup debounce clock of port0
"wakeup_deb_p1": for USB wakeup debounce clock of port1
 
@@ -47,10 +48,10 @@ usb30: usb@1127 {
reg-names = "mac", "ippc";
interrupts = ;
power-domains = < MT8173_POWER_DOMAIN_USB>;
-   clocks = < CLK_TOP_USB30_SEL>,
+   clocks = < CLK_TOP_USB30_SEL>, <>,
 < CLK_PERI_USB0>,
 < CLK_PERI_USB1>;
-   clock-names = "sys_ck",
+   clock-names = "sys_ck", "ref_ck",
  "wakeup_deb_p0",
  "wakeup_deb_p1";
phys = <_port0 PHY_TYPE_USB3>,
@@ -82,6 +83,7 @@ Required properties:
entry in clock-names
  - clock-names : must be
"sys_ck": for clock of xHCI MAC
+   "ref_ck": for reference clock of xHCI MAC
 
 Optional properties:
  - vbus-supply : reference to the VBUS regulator;
@@ -94,8 +96,8 @@ usb30: usb@1127 {
reg-names = "mac";
interrupts = ;
power-domains = < MT8173_POWER_DOMAIN_USB>;
-   clocks = < CLK_TOP_USB30_SEL>;
-   clock-names = "sys_ck";
+   clocks = < CLK_TOP_USB30_SEL>, <>;
+   clock-names = "sys_ck", "ref_ck";
vusb33-supply = <_vusb_reg>;
usb3-lpm-capable;
 };
-- 
1.7.9.5



[PATCH 4/6] arm64: dts: mt8173: add reference clock for usb

2017-01-17 Thread Chunfeng Yun
add 26M reference clock for ssusb and xhci nodes

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 07fd2eb..e2862b6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -729,9 +729,11 @@
   < PHY_TYPE_USB2>;
power-domains = < MT8173_POWER_DOMAIN_USB>;
clocks = < CLK_TOP_USB30_SEL>,
+<>,
 < CLK_PERI_USB0>,
 < CLK_PERI_USB1>;
clock-names = "sys_ck",
+ "ref_ck",
  "wakeup_deb_p0",
  "wakeup_deb_p1";
mediatek,syscon-wakeup = <>;
@@ -746,8 +748,8 @@
reg-names = "mac";
interrupts = ;
power-domains = < 
MT8173_POWER_DOMAIN_USB>;
-   clocks = < CLK_TOP_USB30_SEL>;
-   clock-names = "sys_ck";
+   clocks = < CLK_TOP_USB30_SEL>, 
<>;
+   clock-names = "sys_ck", "ref_ck";
status = "disabled";
};
};
-- 
1.7.9.5



[PATCH 5/6] dt-bindings: mt8173-xhci: add reference clock

2017-01-17 Thread Chunfeng Yun
add a reference clock for compatibility

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/usb/mt8173-xhci.txt|   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
index 2a930bd..ab8bb27 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -23,6 +23,7 @@ Required properties:
entry in clock-names
  - clock-names : must contain
"sys_ck": for clock of xHCI MAC
+   "ref_ck": for reference clock of xHCI MAC
"wakeup_deb_p0": for USB wakeup debounce clock of port0
"wakeup_deb_p1": for USB wakeup debounce clock of port1
 
@@ -47,10 +48,10 @@ usb30: usb@1127 {
reg-names = "mac", "ippc";
interrupts = ;
power-domains = < MT8173_POWER_DOMAIN_USB>;
-   clocks = < CLK_TOP_USB30_SEL>,
+   clocks = < CLK_TOP_USB30_SEL>, <>,
 < CLK_PERI_USB0>,
 < CLK_PERI_USB1>;
-   clock-names = "sys_ck",
+   clock-names = "sys_ck", "ref_ck",
  "wakeup_deb_p0",
  "wakeup_deb_p1";
phys = <_port0 PHY_TYPE_USB3>,
@@ -82,6 +83,7 @@ Required properties:
entry in clock-names
  - clock-names : must be
"sys_ck": for clock of xHCI MAC
+   "ref_ck": for reference clock of xHCI MAC
 
 Optional properties:
  - vbus-supply : reference to the VBUS regulator;
@@ -94,8 +96,8 @@ usb30: usb@1127 {
reg-names = "mac";
interrupts = ;
power-domains = < MT8173_POWER_DOMAIN_USB>;
-   clocks = < CLK_TOP_USB30_SEL>;
-   clock-names = "sys_ck";
+   clocks = < CLK_TOP_USB30_SEL>, <>;
+   clock-names = "sys_ck", "ref_ck";
vusb33-supply = <_vusb_reg>;
usb3-lpm-capable;
 };
-- 
1.7.9.5



[PATCH v2 tip/core/rcu 07/18] rcu: Add long-term CPU kicking

2017-01-17 Thread Paul E. McKenney
Commit d2db185bfee8 ("rcu: Remove short-term CPU kicking") removed
frequent calls to resched_cpu(), which means that the only time
resched_cpu() is invoked is after an RCU CPU stall warning.  Although
this is good from an avoid-IPIs perspective, we should try to break
things loose -before- splatting.  This commit therefore starts invoking
resched_cpu() for each holdout at each force-quiescent-state interval
that is more than halfway through the stall-warning interval.

Signed-off-by: Paul E. McKenney 
---
 kernel/rcu/tree.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 83bf054e194e..0e61b62e3f4a 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1225,6 +1225,12 @@ static int rcu_implicit_dynticks_qs(struct rcu_data *rdp,
 rdp->rsp->gp_start + 2 * jiffies_till_sched_qs) ||
ULONG_CMP_GE(jiffies, rdp->rsp->gp_start + jiffies_till_sched_qs))
resched_cpu(rdp->cpu);  /* Force CPU into scheduler. */
+   /*
+* If more than halfway to RCU CPU stall-warning time, do
+* a resched_cpu() to try to loosen things up a bit.
+*/
+   if (jiffies - rdp->rsp->gp_start > rcu_jiffies_till_stall_check() / 2)
+   resched_cpu(rdp->cpu);
 
return 0;
 }
-- 
2.5.2



[PATCH v2 tip/core/rcu 07/18] rcu: Add long-term CPU kicking

2017-01-17 Thread Paul E. McKenney
Commit d2db185bfee8 ("rcu: Remove short-term CPU kicking") removed
frequent calls to resched_cpu(), which means that the only time
resched_cpu() is invoked is after an RCU CPU stall warning.  Although
this is good from an avoid-IPIs perspective, we should try to break
things loose -before- splatting.  This commit therefore starts invoking
resched_cpu() for each holdout at each force-quiescent-state interval
that is more than halfway through the stall-warning interval.

Signed-off-by: Paul E. McKenney 
---
 kernel/rcu/tree.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 83bf054e194e..0e61b62e3f4a 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1225,6 +1225,12 @@ static int rcu_implicit_dynticks_qs(struct rcu_data *rdp,
 rdp->rsp->gp_start + 2 * jiffies_till_sched_qs) ||
ULONG_CMP_GE(jiffies, rdp->rsp->gp_start + jiffies_till_sched_qs))
resched_cpu(rdp->cpu);  /* Force CPU into scheduler. */
+   /*
+* If more than halfway to RCU CPU stall-warning time, do
+* a resched_cpu() to try to loosen things up a bit.
+*/
+   if (jiffies - rdp->rsp->gp_start > rcu_jiffies_till_stall_check() / 2)
+   resched_cpu(rdp->cpu);
 
return 0;
 }
-- 
2.5.2



[PATCH v2 tip/core/rcu 05/18] rcu: Remove unneeded rcu_process_callbacks() declarations

2017-01-17 Thread Paul E. McKenney
The declarations of __rcu_process_callbacks() and rcu_process_callbacks()
are not needed, as the definition of both of these functions appear before
any uses.  This commit therefore removes both declarations.

Reported-by: "Ahmed, Iftekhar" 
Signed-off-by: Paul E. McKenney 
Reviewed-by: Josh Triplett 
---
 kernel/rcu/tiny.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/kernel/rcu/tiny.c b/kernel/rcu/tiny.c
index b23a4d076f3d..fa6a48d3917b 100644
--- a/kernel/rcu/tiny.c
+++ b/kernel/rcu/tiny.c
@@ -41,8 +41,6 @@
 
 /* Forward declarations for tiny_plugin.h. */
 struct rcu_ctrlblk;
-static void __rcu_process_callbacks(struct rcu_ctrlblk *rcp);
-static void rcu_process_callbacks(struct softirq_action *unused);
 static void __call_rcu(struct rcu_head *head,
   rcu_callback_t func,
   struct rcu_ctrlblk *rcp);
-- 
2.5.2



[PATCH v2 tip/core/rcu 05/18] rcu: Remove unneeded rcu_process_callbacks() declarations

2017-01-17 Thread Paul E. McKenney
The declarations of __rcu_process_callbacks() and rcu_process_callbacks()
are not needed, as the definition of both of these functions appear before
any uses.  This commit therefore removes both declarations.

Reported-by: "Ahmed, Iftekhar" 
Signed-off-by: Paul E. McKenney 
Reviewed-by: Josh Triplett 
---
 kernel/rcu/tiny.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/kernel/rcu/tiny.c b/kernel/rcu/tiny.c
index b23a4d076f3d..fa6a48d3917b 100644
--- a/kernel/rcu/tiny.c
+++ b/kernel/rcu/tiny.c
@@ -41,8 +41,6 @@
 
 /* Forward declarations for tiny_plugin.h. */
 struct rcu_ctrlblk;
-static void __rcu_process_callbacks(struct rcu_ctrlblk *rcp);
-static void rcu_process_callbacks(struct softirq_action *unused);
 static void __call_rcu(struct rcu_head *head,
   rcu_callback_t func,
   struct rcu_ctrlblk *rcp);
-- 
2.5.2



[RESEND PATCH 6/6] dt-bindings: phy-mt65xx-usb: add support for mt2712 platform

2017-01-17 Thread Chunfeng Yun
add a new compatible string for "mt2712", and a new reference clock
for SuperSpeed analog phy;

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/phy/phy-mt65xx-usb.txt |   81 +---
 1 file changed, 70 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
index 33a2b1e..8f91136 100644
--- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
+++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
@@ -6,19 +6,25 @@ This binding describes a usb3.0 phy for mt65xx platforms of 
Medaitek SoC.
 Required properties (controller (parent) node):
  - compatible  : should be one of
  "mediatek,mt2701-u3phy"
+ "mediatek,mt2712-u3phy"
  "mediatek,mt8173-u3phy"
- - reg : offset and length of register for phy, exclude port's
- register.
  - clocks  : a list of phandle + clock-specifier pairs, one for each
  entry in clock-names
  - clock-names : must contain
- "u3phya_ref": for reference clock of usb3.0 analog phy.
+ "u2ref_clk": 48M reference clock of HighSpeed analog phy.
+ "u3ref_clk": 26M reference clock of SuperSpeed analog phy,
+   sometimes is 24M, 25M or 27M, depended on platform.
 
 Required nodes : a sub-node is required for each port the controller
  provides. Address range information including the usual
  'reg' property is used inside these nodes to describe
  the controller's topology.
 
+Optional properties (controller (parent) node):
+ - reg : offset and length of register shared by multiple ports,
+ exclude port's private register. It is needed on mt2701
+ and mt8173, but not on mt2712.
+
 Required properties (port (child) node):
 - reg  : address and length of the register set for the port.
 - #phy-cells   : should be 1 (See second example)
@@ -31,21 +37,27 @@ Example:
 u3phy: usb-phy@1129 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x1129 0 0x800>;
-   clocks = < CLK_APMIXED_REF2USB_TX>;
-   clock-names = "u3phya_ref";
+   clocks = < CLK_APMIXED_REF2USB_TX>, <>;
+   clock-names = "u2ref_clk", "u3ref_clk";
#address-cells = <2>;
#size-cells = <2>;
ranges;
status = "okay";
 
-   phy_port0: port@11290800 {
-   reg = <0 0x11290800 0 0x800>;
+   u2port0: port@11290800 {
+   reg = <0 0x11290800 0 0x100>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+
+   u3port0: port@11290900 {
+   reg = <0 0x11290800 0 0x700>;
#phy-cells = <1>;
status = "okay";
};
 
-   phy_port1: port@11291000 {
-   reg = <0 0x11291000 0 0x800>;
+   u2port1: port@11291000 {
+   reg = <0 0x11291000 0 0x100>;
#phy-cells = <1>;
status = "okay";
};
@@ -64,7 +76,54 @@ Example:
 
 usb30: usb@1127 {
...
-   phys = <_port0 PHY_TYPE_USB3>;
-   phy-names = "usb3-0";
+   phys = < PHY_TYPE_USB2>, < PHY_TYPE_USB3>;
+   phy-names = "usb2-0", "usb3-0";
...
 };
+
+
+Layout differences of banks between mt8173/mt2701 and mt2712
+-
+mt8173 and mt2701:
+portoffsetbank
+shared  0xSPLLC
+0x0100FMREG
+u2 port00x0800U2PHY_COM
+u3 port00x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHYA_DA
+u2 port10x1000U2PHY_COM
+u3 port10x1100U3PHYD
+0x1200U3PHYD_BANK2
+0x1300U3PHYA
+0x1400U3PHYA_DA
+u2 port20x1800U2PHY_COM
+...
+
+mt2712:
+portoffsetbank
+u2 port00xMISC
+0x0100FMREG
+0x0300U2PHY_COM
+u3 port00x0700SPLLC
+0x0800CHIP
+0x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHYA_DA
+u2 port10x1000MISC
+0x1100FMREG
+0x1300U2PHY_COM
+u3 port10x1700SPLLC
+0x1800CHIP
+0x1900U3PHYD
+0x1a00U3PHYD_BANK2
+0x1b00U3PHYA
+0x1c00U3PHYA_DA
+u2 port20x2000MISC
+...
+
+SPLLC shared by u3 ports and FMREG shared by u2 ports on
+mt8173/mt2701 are put back into each port; a new bank MISC for
+u2 ports and CHIP for u3 ports are added on mt2712.
-- 
1.7.9.5



[RESEND PATCH 6/6] dt-bindings: phy-mt65xx-usb: add support for mt2712 platform

2017-01-17 Thread Chunfeng Yun
add a new compatible string for "mt2712", and a new reference clock
for SuperSpeed analog phy;

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/phy/phy-mt65xx-usb.txt |   81 +---
 1 file changed, 70 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
index 33a2b1e..8f91136 100644
--- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
+++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
@@ -6,19 +6,25 @@ This binding describes a usb3.0 phy for mt65xx platforms of 
Medaitek SoC.
 Required properties (controller (parent) node):
  - compatible  : should be one of
  "mediatek,mt2701-u3phy"
+ "mediatek,mt2712-u3phy"
  "mediatek,mt8173-u3phy"
- - reg : offset and length of register for phy, exclude port's
- register.
  - clocks  : a list of phandle + clock-specifier pairs, one for each
  entry in clock-names
  - clock-names : must contain
- "u3phya_ref": for reference clock of usb3.0 analog phy.
+ "u2ref_clk": 48M reference clock of HighSpeed analog phy.
+ "u3ref_clk": 26M reference clock of SuperSpeed analog phy,
+   sometimes is 24M, 25M or 27M, depended on platform.
 
 Required nodes : a sub-node is required for each port the controller
  provides. Address range information including the usual
  'reg' property is used inside these nodes to describe
  the controller's topology.
 
+Optional properties (controller (parent) node):
+ - reg : offset and length of register shared by multiple ports,
+ exclude port's private register. It is needed on mt2701
+ and mt8173, but not on mt2712.
+
 Required properties (port (child) node):
 - reg  : address and length of the register set for the port.
 - #phy-cells   : should be 1 (See second example)
@@ -31,21 +37,27 @@ Example:
 u3phy: usb-phy@1129 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x1129 0 0x800>;
-   clocks = < CLK_APMIXED_REF2USB_TX>;
-   clock-names = "u3phya_ref";
+   clocks = < CLK_APMIXED_REF2USB_TX>, <>;
+   clock-names = "u2ref_clk", "u3ref_clk";
#address-cells = <2>;
#size-cells = <2>;
ranges;
status = "okay";
 
-   phy_port0: port@11290800 {
-   reg = <0 0x11290800 0 0x800>;
+   u2port0: port@11290800 {
+   reg = <0 0x11290800 0 0x100>;
+   #phy-cells = <1>;
+   status = "okay";
+   };
+
+   u3port0: port@11290900 {
+   reg = <0 0x11290800 0 0x700>;
#phy-cells = <1>;
status = "okay";
};
 
-   phy_port1: port@11291000 {
-   reg = <0 0x11291000 0 0x800>;
+   u2port1: port@11291000 {
+   reg = <0 0x11291000 0 0x100>;
#phy-cells = <1>;
status = "okay";
};
@@ -64,7 +76,54 @@ Example:
 
 usb30: usb@1127 {
...
-   phys = <_port0 PHY_TYPE_USB3>;
-   phy-names = "usb3-0";
+   phys = < PHY_TYPE_USB2>, < PHY_TYPE_USB3>;
+   phy-names = "usb2-0", "usb3-0";
...
 };
+
+
+Layout differences of banks between mt8173/mt2701 and mt2712
+-
+mt8173 and mt2701:
+portoffsetbank
+shared  0xSPLLC
+0x0100FMREG
+u2 port00x0800U2PHY_COM
+u3 port00x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHYA_DA
+u2 port10x1000U2PHY_COM
+u3 port10x1100U3PHYD
+0x1200U3PHYD_BANK2
+0x1300U3PHYA
+0x1400U3PHYA_DA
+u2 port20x1800U2PHY_COM
+...
+
+mt2712:
+portoffsetbank
+u2 port00xMISC
+0x0100FMREG
+0x0300U2PHY_COM
+u3 port00x0700SPLLC
+0x0800CHIP
+0x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHYA_DA
+u2 port10x1000MISC
+0x1100FMREG
+0x1300U2PHY_COM
+u3 port10x1700SPLLC
+0x1800CHIP
+0x1900U3PHYD
+0x1a00U3PHYD_BANK2
+0x1b00U3PHYA
+0x1c00U3PHYA_DA
+u2 port20x2000MISC
+...
+
+SPLLC shared by u3 ports and FMREG shared by u2 ports on
+mt8173/mt2701 are put back into each port; a new bank MISC for
+u2 ports and CHIP for u3 ports are added on mt2712.
-- 
1.7.9.5



[RESEND PATCH 1/6] phy: phy-mt65xx-usb3: add reference clock of usb3 analog phy

2017-01-17 Thread Chunfeng Yun
usually, the reference clock of usb3 analog phy comes from
26M oscillator directly, but some SoCs are not, add it for
compatibility.

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c |   36 
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index d972067..fc9a4f0 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -149,7 +149,8 @@ struct mt65xx_phy_instance {
 struct mt65xx_u3phy {
struct device *dev;
void __iomem *sif_base; /* include sif2, but exclude port's */
-   struct clk *u3phya_ref; /* reference clock of usb3 anolog phy */
+   struct clk *u2ref_clk;  /* reference clock of u2 analog phy */
+   struct clk *u3ref_clk;  /* reference clock of u3 analog phy */
const struct mt65xx_phy_pdata *pdata;
struct mt65xx_phy_instance **phys;
int nphys;
@@ -429,11 +430,17 @@ static int mt65xx_phy_init(struct phy *phy)
 {
struct mt65xx_phy_instance *instance = phy_get_drvdata(phy);
struct mt65xx_u3phy *u3phy = dev_get_drvdata(phy->dev.parent);
+   struct clk *ref_clk;
int ret;
 
-   ret = clk_prepare_enable(u3phy->u3phya_ref);
+   if (instance->type == PHY_TYPE_USB2)
+   ref_clk = u3phy->u2ref_clk;
+   else
+   ref_clk = u3phy->u3ref_clk;
+
+   ret = clk_prepare_enable(ref_clk);
if (ret) {
-   dev_err(u3phy->dev, "failed to enable u3phya_ref\n");
+   dev_err(u3phy->dev, "failed to enable ref clk\n");
return ret;
}
 
@@ -464,9 +471,16 @@ static int mt65xx_phy_exit(struct phy *phy)
 {
struct mt65xx_phy_instance *instance = phy_get_drvdata(phy);
struct mt65xx_u3phy *u3phy = dev_get_drvdata(phy->dev.parent);
+   struct clk *ref_clk;
 
phy_instance_exit(u3phy, instance);
-   clk_disable_unprepare(u3phy->u3phya_ref);
+
+   if (instance->type == PHY_TYPE_USB2)
+   ref_clk = u3phy->u2ref_clk;
+   else
+   ref_clk = u3phy->u3ref_clk;
+
+   clk_disable_unprepare(ref_clk);
return 0;
 }
 
@@ -566,10 +580,16 @@ static int mt65xx_u3phy_probe(struct platform_device 
*pdev)
return PTR_ERR(u3phy->sif_base);
}
 
-   u3phy->u3phya_ref = devm_clk_get(dev, "u3phya_ref");
-   if (IS_ERR(u3phy->u3phya_ref)) {
-   dev_err(dev, "error to get u3phya_ref\n");
-   return PTR_ERR(u3phy->u3phya_ref);
+   u3phy->u2ref_clk = devm_clk_get(dev, "u2ref_clk");
+   if (IS_ERR(u3phy->u2ref_clk)) {
+   dev_err(dev, "failed to get u2ref_clk\n");
+   return PTR_ERR(u3phy->u2ref_clk);
+   }
+
+   u3phy->u3ref_clk = devm_clk_get(dev, "u3ref_clk");
+   if (IS_ERR(u3phy->u3ref_clk)) {
+   dev_err(dev, "failed to get u3ref_clk\n");
+   return PTR_ERR(u3phy->u3ref_clk);
}
 
port = 0;
-- 
1.7.9.5



[RESEND PATCH 1/6] phy: phy-mt65xx-usb3: add reference clock of usb3 analog phy

2017-01-17 Thread Chunfeng Yun
usually, the reference clock of usb3 analog phy comes from
26M oscillator directly, but some SoCs are not, add it for
compatibility.

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c |   36 
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index d972067..fc9a4f0 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -149,7 +149,8 @@ struct mt65xx_phy_instance {
 struct mt65xx_u3phy {
struct device *dev;
void __iomem *sif_base; /* include sif2, but exclude port's */
-   struct clk *u3phya_ref; /* reference clock of usb3 anolog phy */
+   struct clk *u2ref_clk;  /* reference clock of u2 analog phy */
+   struct clk *u3ref_clk;  /* reference clock of u3 analog phy */
const struct mt65xx_phy_pdata *pdata;
struct mt65xx_phy_instance **phys;
int nphys;
@@ -429,11 +430,17 @@ static int mt65xx_phy_init(struct phy *phy)
 {
struct mt65xx_phy_instance *instance = phy_get_drvdata(phy);
struct mt65xx_u3phy *u3phy = dev_get_drvdata(phy->dev.parent);
+   struct clk *ref_clk;
int ret;
 
-   ret = clk_prepare_enable(u3phy->u3phya_ref);
+   if (instance->type == PHY_TYPE_USB2)
+   ref_clk = u3phy->u2ref_clk;
+   else
+   ref_clk = u3phy->u3ref_clk;
+
+   ret = clk_prepare_enable(ref_clk);
if (ret) {
-   dev_err(u3phy->dev, "failed to enable u3phya_ref\n");
+   dev_err(u3phy->dev, "failed to enable ref clk\n");
return ret;
}
 
@@ -464,9 +471,16 @@ static int mt65xx_phy_exit(struct phy *phy)
 {
struct mt65xx_phy_instance *instance = phy_get_drvdata(phy);
struct mt65xx_u3phy *u3phy = dev_get_drvdata(phy->dev.parent);
+   struct clk *ref_clk;
 
phy_instance_exit(u3phy, instance);
-   clk_disable_unprepare(u3phy->u3phya_ref);
+
+   if (instance->type == PHY_TYPE_USB2)
+   ref_clk = u3phy->u2ref_clk;
+   else
+   ref_clk = u3phy->u3ref_clk;
+
+   clk_disable_unprepare(ref_clk);
return 0;
 }
 
@@ -566,10 +580,16 @@ static int mt65xx_u3phy_probe(struct platform_device 
*pdev)
return PTR_ERR(u3phy->sif_base);
}
 
-   u3phy->u3phya_ref = devm_clk_get(dev, "u3phya_ref");
-   if (IS_ERR(u3phy->u3phya_ref)) {
-   dev_err(dev, "error to get u3phya_ref\n");
-   return PTR_ERR(u3phy->u3phya_ref);
+   u3phy->u2ref_clk = devm_clk_get(dev, "u2ref_clk");
+   if (IS_ERR(u3phy->u2ref_clk)) {
+   dev_err(dev, "failed to get u2ref_clk\n");
+   return PTR_ERR(u3phy->u2ref_clk);
+   }
+
+   u3phy->u3ref_clk = devm_clk_get(dev, "u3ref_clk");
+   if (IS_ERR(u3phy->u3ref_clk)) {
+   dev_err(dev, "failed to get u3ref_clk\n");
+   return PTR_ERR(u3phy->u3ref_clk);
}
 
port = 0;
-- 
1.7.9.5



Re: [PATCH v11 07/12] drm/mediatek: cleaning up and refine

2017-01-17 Thread CK Hu
Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> cleaning up unused define and refine function name and variable
> 
> Signed-off-by: shaoming chen 
> Signed-off-by: YT Shen 

Acked-by: CK Hu 

> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 73 
> --
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.c |  8 ++--
>  2 files changed, 39 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 2c42f90..6f4b3bb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -27,9 +27,6 @@
>  
>  #include "mtk_drm_ddp_comp.h"
>  
> -#define DSI_VIDEO_FIFO_DEPTH (1920 / 4)
> -#define DSI_HOST_FIFO_DEPTH  64
> -
>  #define DSI_START0x00
>  
>  #define DSI_CON_CTRL 0x10
> @@ -46,7 +43,7 @@
>  #define MIX_MODE BIT(17)
>  
>  #define DSI_TXRX_CTRL0x18
> -#define VC_NUM   (2 << 0)
> +#define VC_NUM   BIT(1)
>  #define LANE_NUM (0xf << 2)
>  #define DIS_EOT  BIT(6)
>  #define NULL_EN  BIT(7)
> @@ -164,7 +161,7 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, 
> u32 mask, u32 data)
>   writel((temp & ~mask) | (data & mask), dsi->regs + offset);
>  }
>  
> -static void dsi_phy_timconfig(struct mtk_dsi *dsi)
> +static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
>  {
>   u32 timcon0, timcon1, timcon2, timcon3;
>   u32 ui, cycle_time;
> @@ -196,7 +193,7 @@ static void mtk_dsi_disable(struct mtk_dsi *dsi)
>   mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_EN, 0);
>  }
>  
> -static void mtk_dsi_reset(struct mtk_dsi *dsi)
> +static void mtk_dsi_reset_engine(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, DSI_RESET);
>   mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, 0);
> @@ -267,8 +264,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>   }
>  
>   mtk_dsi_enable(dsi);
> - mtk_dsi_reset(dsi);
> - dsi_phy_timconfig(dsi);
> + mtk_dsi_reset_engine(dsi);
> + mtk_dsi_phy_timconfig(dsi);
>  
>   return 0;
>  
> @@ -281,33 +278,33 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>   return ret;
>  }
>  
> -static void dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
> +static void mtk_dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
>  }
>  
> -static void dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
> +static void mtk_dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, LC_WAKEUP_EN);
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, 0);
>  }
>  
> -static void dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
> +static void mtk_dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_HS_TX_EN, 0);
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
>  }
>  
> -static void dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
> +static void mtk_dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, LD0_WAKEUP_EN);
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, 0);
>  }
>  
> -static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
> +static bool mtk_dsi_clk_hs_state(struct mtk_dsi *dsi)
>  {
>   u32 tmp_reg1;
>  
> @@ -315,15 +312,15 @@ static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
>   return ((tmp_reg1 & LC_HS_TX_EN) == 1) ? true : false;
>  }
>  
> -static void dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
> +static void mtk_dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
>  {
> - if (enter && !dsi_clk_hs_state(dsi))
> + if (enter && !mtk_dsi_clk_hs_state(dsi))
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, LC_HS_TX_EN);
> - else if (!enter && dsi_clk_hs_state(dsi))
> + else if (!enter && mtk_dsi_clk_hs_state(dsi))
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
>  }
>  
> -static void dsi_set_mode(struct mtk_dsi *dsi)
> +static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
>  {
>   u32 vid_mode = CMD_MODE;
>  
> @@ -338,7 +335,7 @@ static void dsi_set_mode(struct mtk_dsi *dsi)
>   writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
>  }
>  
> -static void dsi_ps_control_vact(struct mtk_dsi *dsi)
> +static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
>  {
>   struct videomode *vm = >vm;
>   u32 dsi_buf_bpp, ps_wc;
> @@ -372,7 +369,7 @@ static void dsi_ps_control_vact(struct mtk_dsi *dsi)
>   writel(ps_wc, dsi->regs + DSI_HSTX_CKL_WC);
>  }
>  
> -static void dsi_rxtx_control(struct mtk_dsi *dsi)
> 

[RESEND PATCH 4/6] arm64: dts: mt8173: add a new reference clock for usb3 analog phy

2017-01-17 Thread Chunfeng Yun
add a new reference clock which comes from 26M oscillator directly
for SuperSpeed analog phy. and the old one which comes for PLL is
48M for HighSpeed analog phy.

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e7027..5d1663b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -754,8 +754,8 @@
u3phy: usb-phy@1129 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x1129 0 0x800>;
-   clocks = < CLK_APMIXED_REF2USB_TX>;
-   clock-names = "u3phya_ref";
+   clocks = < CLK_APMIXED_REF2USB_TX>, 
<>;
+   clock-names = "u2ref_clk", "u3ref_clk";
#address-cells = <2>;
#size-cells = <2>;
ranges;
-- 
1.7.9.5



[RESEND PATCH 2/6] phy: phy-mt65xx-usb3: split SuperSpeed port into two ones

2017-01-17 Thread Chunfeng Yun
Currently usb3 port in fact includes two sub-ports, but it is not
flexible for some cases, such as following one:
usb3 port0 includes u2port0 and u3port0;
usb2 port0 includes u2port1;
If wants to support only HS, we can use u2port0 or u2port1, when
select u2port0, u3port0 is not needed;
If wants to support SS, we can compound u2port0 and u3port0,
or u2port1 and u3port0, if select latter one, u2port0 is not needed.

So it's more flexible to split usb3 port into two ones and also try
best to save power by disabling unnecessary ports.

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c |  124 -
 1 file changed, 61 insertions(+), 63 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index fc9a4f0..c187a3b 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -30,11 +30,11 @@
 #define SSUSB_SIFSLV_SPLLC 0x
 #define SSUSB_SIFSLV_U2FREQ0x0100
 
-/* offsets of sub-segment in each port registers */
+/* offsets of banks in each u2phy registers */
 #define SSUSB_SIFSLV_U2PHY_COM_BASE0x
-#define SSUSB_SIFSLV_U3PHYD_BASE   0x0100
-#define SSUSB_USB30_PHYA_SIV_B_BASE0x0300
-#define SSUSB_SIFSLV_U3PHYA_DA_BASE0x0400
+/* offsets of banks in each u3phy registers */
+#define SSUSB_SIFSLV_U3PHYD_BASE   0x
+#define SSUSB_SIFSLV_U3PHYA_BASE   0x0200
 
 #define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x)
 #define PA0_RG_U2PLL_FORCE_ON  BIT(15)
@@ -49,7 +49,6 @@
 #define PA5_RG_U2_HS_100U_U3_ENBIT(11)
 
 #define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018)
-#define PA6_RG_U2_ISO_EN   BIT(31)
 #define PA6_RG_U2_BC11_SW_EN   BIT(23)
 #define PA6_RG_U2_OTG_VBUSCMP_EN   BIT(20)
 #define PA6_RG_U2_SQTH GENMASK(3, 0)
@@ -91,18 +90,18 @@
 #define P2C_RG_SESSEND BIT(4)
 #define P2C_RG_AVALID  BIT(2)
 
-#define U3P_U3_PHYA_REG0   (SSUSB_USB30_PHYA_SIV_B_BASE + 0x)
+#define U3P_U3_PHYA_REG0   (SSUSB_SIFSLV_U3PHYA_BASE + 0x)
 #define P3A_RG_U3_VUSB10_ONBIT(5)
 
-#define U3P_U3_PHYA_REG6   (SSUSB_USB30_PHYA_SIV_B_BASE + 0x0018)
+#define U3P_U3_PHYA_REG6   (SSUSB_SIFSLV_U3PHYA_BASE + 0x0018)
 #define P3A_RG_TX_EIDLE_CM GENMASK(31, 28)
 #define P3A_RG_TX_EIDLE_CM_VAL(x)  ((0xf & (x)) << 28)
 
-#define U3P_U3_PHYA_REG9   (SSUSB_USB30_PHYA_SIV_B_BASE + 0x0024)
+#define U3P_U3_PHYA_REG9   (SSUSB_SIFSLV_U3PHYA_BASE + 0x0024)
 #define P3A_RG_RX_DAC_MUX  GENMASK(5, 1)
 #define P3A_RG_RX_DAC_MUX_VAL(x)   ((0x1f & (x)) << 1)
 
-#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_DA_BASE + 0x)
+#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0100)
 #define P3A_RG_XTAL_EXT_EN_U3  GENMASK(11, 10)
 #define P3A_RG_XTAL_EXT_EN_U3_VAL(x)   ((0x3 & (x)) << 10)
 
@@ -148,7 +147,7 @@ struct mt65xx_phy_instance {
 
 struct mt65xx_u3phy {
struct device *dev;
-   void __iomem *sif_base; /* include sif2, but exclude port's */
+   void __iomem *sif_base; /* only shared sif */
struct clk *u2ref_clk;  /* reference clock of u2 analog phy */
struct clk *u3ref_clk;  /* reference clock of u3 analog phy */
const struct mt65xx_phy_pdata *pdata;
@@ -179,7 +178,7 @@ static void hs_slew_rate_calibrate(struct mt65xx_u3phy 
*u3phy,
tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
tmp &= ~(P2F_RG_CYCLECNT | P2F_RG_MONCLK_SEL);
tmp |= P2F_RG_CYCLECNT_VAL(U3P_FM_DET_CYCLE_CNT);
-   tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index);
+   tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index >> 1);
writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
 
/* enable frequency meter */
@@ -227,6 +226,41 @@ static void hs_slew_rate_calibrate(struct mt65xx_u3phy 
*u3phy,
writel(tmp, instance->port_base + U3P_USBPHYACR5);
 }
 
+static void u3_phy_instance_init(struct mt65xx_u3phy *u3phy,
+   struct mt65xx_phy_instance *instance)
+{
+   void __iomem *port_base = instance->port_base;
+   u32 tmp;
+
+   /* gating PCIe Analog XTAL clock */
+   tmp = readl(u3phy->sif_base + U3P_XTALCTL3);
+   tmp |= XC3_RG_U3_XTAL_RX_PWD | XC3_RG_U3_FRC_XTAL_RX_PWD;
+   writel(tmp, u3phy->sif_base + U3P_XTALCTL3);
+
+   /* gating XSQ */
+   tmp = readl(port_base + U3P_U3PHYA_DA_REG0);
+   tmp &= ~P3A_RG_XTAL_EXT_EN_U3;
+   tmp |= P3A_RG_XTAL_EXT_EN_U3_VAL(2);
+   writel(tmp, port_base + U3P_U3PHYA_DA_REG0);
+
+   tmp = readl(port_base + U3P_U3_PHYA_REG9);
+   tmp &= ~P3A_RG_RX_DAC_MUX;
+   tmp |= P3A_RG_RX_DAC_MUX_VAL(4);
+   writel(tmp, port_base + U3P_U3_PHYA_REG9);
+
+   tmp = readl(port_base + U3P_U3_PHYA_REG6);
+   tmp &= ~P3A_RG_TX_EIDLE_CM;
+   tmp |= P3A_RG_TX_EIDLE_CM_VAL(0xe);
+   writel(tmp, port_base + U3P_U3_PHYA_REG6);
+
+   tmp = 

Re: [PATCH v11 07/12] drm/mediatek: cleaning up and refine

2017-01-17 Thread CK Hu
Hi, YT:

On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> cleaning up unused define and refine function name and variable
> 
> Signed-off-by: shaoming chen 
> Signed-off-by: YT Shen 

Acked-by: CK Hu 

> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 73 
> --
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.c |  8 ++--
>  2 files changed, 39 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 2c42f90..6f4b3bb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -27,9 +27,6 @@
>  
>  #include "mtk_drm_ddp_comp.h"
>  
> -#define DSI_VIDEO_FIFO_DEPTH (1920 / 4)
> -#define DSI_HOST_FIFO_DEPTH  64
> -
>  #define DSI_START0x00
>  
>  #define DSI_CON_CTRL 0x10
> @@ -46,7 +43,7 @@
>  #define MIX_MODE BIT(17)
>  
>  #define DSI_TXRX_CTRL0x18
> -#define VC_NUM   (2 << 0)
> +#define VC_NUM   BIT(1)
>  #define LANE_NUM (0xf << 2)
>  #define DIS_EOT  BIT(6)
>  #define NULL_EN  BIT(7)
> @@ -164,7 +161,7 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, 
> u32 mask, u32 data)
>   writel((temp & ~mask) | (data & mask), dsi->regs + offset);
>  }
>  
> -static void dsi_phy_timconfig(struct mtk_dsi *dsi)
> +static void mtk_dsi_phy_timconfig(struct mtk_dsi *dsi)
>  {
>   u32 timcon0, timcon1, timcon2, timcon3;
>   u32 ui, cycle_time;
> @@ -196,7 +193,7 @@ static void mtk_dsi_disable(struct mtk_dsi *dsi)
>   mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_EN, 0);
>  }
>  
> -static void mtk_dsi_reset(struct mtk_dsi *dsi)
> +static void mtk_dsi_reset_engine(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, DSI_RESET);
>   mtk_dsi_mask(dsi, DSI_CON_CTRL, DSI_RESET, 0);
> @@ -267,8 +264,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>   }
>  
>   mtk_dsi_enable(dsi);
> - mtk_dsi_reset(dsi);
> - dsi_phy_timconfig(dsi);
> + mtk_dsi_reset_engine(dsi);
> + mtk_dsi_phy_timconfig(dsi);
>  
>   return 0;
>  
> @@ -281,33 +278,33 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
>   return ret;
>  }
>  
> -static void dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
> +static void mtk_dsi_clk_ulp_mode_enter(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
>  }
>  
> -static void dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
> +static void mtk_dsi_clk_ulp_mode_leave(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_ULPM_EN, 0);
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, LC_WAKEUP_EN);
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_WAKEUP_EN, 0);
>  }
>  
> -static void dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
> +static void mtk_dsi_lane0_ulp_mode_enter(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_HS_TX_EN, 0);
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
>  }
>  
> -static void dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
> +static void mtk_dsi_lane0_ulp_mode_leave(struct mtk_dsi *dsi)
>  {
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_ULPM_EN, 0);
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, LD0_WAKEUP_EN);
>   mtk_dsi_mask(dsi, DSI_PHY_LD0CON, LD0_WAKEUP_EN, 0);
>  }
>  
> -static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
> +static bool mtk_dsi_clk_hs_state(struct mtk_dsi *dsi)
>  {
>   u32 tmp_reg1;
>  
> @@ -315,15 +312,15 @@ static bool dsi_clk_hs_state(struct mtk_dsi *dsi)
>   return ((tmp_reg1 & LC_HS_TX_EN) == 1) ? true : false;
>  }
>  
> -static void dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
> +static void mtk_dsi_clk_hs_mode(struct mtk_dsi *dsi, bool enter)
>  {
> - if (enter && !dsi_clk_hs_state(dsi))
> + if (enter && !mtk_dsi_clk_hs_state(dsi))
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, LC_HS_TX_EN);
> - else if (!enter && dsi_clk_hs_state(dsi))
> + else if (!enter && mtk_dsi_clk_hs_state(dsi))
>   mtk_dsi_mask(dsi, DSI_PHY_LCCON, LC_HS_TX_EN, 0);
>  }
>  
> -static void dsi_set_mode(struct mtk_dsi *dsi)
> +static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
>  {
>   u32 vid_mode = CMD_MODE;
>  
> @@ -338,7 +335,7 @@ static void dsi_set_mode(struct mtk_dsi *dsi)
>   writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
>  }
>  
> -static void dsi_ps_control_vact(struct mtk_dsi *dsi)
> +static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
>  {
>   struct videomode *vm = >vm;
>   u32 dsi_buf_bpp, ps_wc;
> @@ -372,7 +369,7 @@ static void dsi_ps_control_vact(struct mtk_dsi *dsi)
>   writel(ps_wc, dsi->regs + DSI_HSTX_CKL_WC);
>  }
>  
> -static void dsi_rxtx_control(struct mtk_dsi *dsi)
> +static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
>  {
>   u32 

[RESEND PATCH 4/6] arm64: dts: mt8173: add a new reference clock for usb3 analog phy

2017-01-17 Thread Chunfeng Yun
add a new reference clock which comes from 26M oscillator directly
for SuperSpeed analog phy. and the old one which comes for PLL is
48M for HighSpeed analog phy.

Signed-off-by: Chunfeng Yun 
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e7027..5d1663b 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -754,8 +754,8 @@
u3phy: usb-phy@1129 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x1129 0 0x800>;
-   clocks = < CLK_APMIXED_REF2USB_TX>;
-   clock-names = "u3phya_ref";
+   clocks = < CLK_APMIXED_REF2USB_TX>, 
<>;
+   clock-names = "u2ref_clk", "u3ref_clk";
#address-cells = <2>;
#size-cells = <2>;
ranges;
-- 
1.7.9.5



[RESEND PATCH 2/6] phy: phy-mt65xx-usb3: split SuperSpeed port into two ones

2017-01-17 Thread Chunfeng Yun
Currently usb3 port in fact includes two sub-ports, but it is not
flexible for some cases, such as following one:
usb3 port0 includes u2port0 and u3port0;
usb2 port0 includes u2port1;
If wants to support only HS, we can use u2port0 or u2port1, when
select u2port0, u3port0 is not needed;
If wants to support SS, we can compound u2port0 and u3port0,
or u2port1 and u3port0, if select latter one, u2port0 is not needed.

So it's more flexible to split usb3 port into two ones and also try
best to save power by disabling unnecessary ports.

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c |  124 -
 1 file changed, 61 insertions(+), 63 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index fc9a4f0..c187a3b 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -30,11 +30,11 @@
 #define SSUSB_SIFSLV_SPLLC 0x
 #define SSUSB_SIFSLV_U2FREQ0x0100
 
-/* offsets of sub-segment in each port registers */
+/* offsets of banks in each u2phy registers */
 #define SSUSB_SIFSLV_U2PHY_COM_BASE0x
-#define SSUSB_SIFSLV_U3PHYD_BASE   0x0100
-#define SSUSB_USB30_PHYA_SIV_B_BASE0x0300
-#define SSUSB_SIFSLV_U3PHYA_DA_BASE0x0400
+/* offsets of banks in each u3phy registers */
+#define SSUSB_SIFSLV_U3PHYD_BASE   0x
+#define SSUSB_SIFSLV_U3PHYA_BASE   0x0200
 
 #define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x)
 #define PA0_RG_U2PLL_FORCE_ON  BIT(15)
@@ -49,7 +49,6 @@
 #define PA5_RG_U2_HS_100U_U3_ENBIT(11)
 
 #define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018)
-#define PA6_RG_U2_ISO_EN   BIT(31)
 #define PA6_RG_U2_BC11_SW_EN   BIT(23)
 #define PA6_RG_U2_OTG_VBUSCMP_EN   BIT(20)
 #define PA6_RG_U2_SQTH GENMASK(3, 0)
@@ -91,18 +90,18 @@
 #define P2C_RG_SESSEND BIT(4)
 #define P2C_RG_AVALID  BIT(2)
 
-#define U3P_U3_PHYA_REG0   (SSUSB_USB30_PHYA_SIV_B_BASE + 0x)
+#define U3P_U3_PHYA_REG0   (SSUSB_SIFSLV_U3PHYA_BASE + 0x)
 #define P3A_RG_U3_VUSB10_ONBIT(5)
 
-#define U3P_U3_PHYA_REG6   (SSUSB_USB30_PHYA_SIV_B_BASE + 0x0018)
+#define U3P_U3_PHYA_REG6   (SSUSB_SIFSLV_U3PHYA_BASE + 0x0018)
 #define P3A_RG_TX_EIDLE_CM GENMASK(31, 28)
 #define P3A_RG_TX_EIDLE_CM_VAL(x)  ((0xf & (x)) << 28)
 
-#define U3P_U3_PHYA_REG9   (SSUSB_USB30_PHYA_SIV_B_BASE + 0x0024)
+#define U3P_U3_PHYA_REG9   (SSUSB_SIFSLV_U3PHYA_BASE + 0x0024)
 #define P3A_RG_RX_DAC_MUX  GENMASK(5, 1)
 #define P3A_RG_RX_DAC_MUX_VAL(x)   ((0x1f & (x)) << 1)
 
-#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_DA_BASE + 0x)
+#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0100)
 #define P3A_RG_XTAL_EXT_EN_U3  GENMASK(11, 10)
 #define P3A_RG_XTAL_EXT_EN_U3_VAL(x)   ((0x3 & (x)) << 10)
 
@@ -148,7 +147,7 @@ struct mt65xx_phy_instance {
 
 struct mt65xx_u3phy {
struct device *dev;
-   void __iomem *sif_base; /* include sif2, but exclude port's */
+   void __iomem *sif_base; /* only shared sif */
struct clk *u2ref_clk;  /* reference clock of u2 analog phy */
struct clk *u3ref_clk;  /* reference clock of u3 analog phy */
const struct mt65xx_phy_pdata *pdata;
@@ -179,7 +178,7 @@ static void hs_slew_rate_calibrate(struct mt65xx_u3phy 
*u3phy,
tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
tmp &= ~(P2F_RG_CYCLECNT | P2F_RG_MONCLK_SEL);
tmp |= P2F_RG_CYCLECNT_VAL(U3P_FM_DET_CYCLE_CNT);
-   tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index);
+   tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index >> 1);
writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
 
/* enable frequency meter */
@@ -227,6 +226,41 @@ static void hs_slew_rate_calibrate(struct mt65xx_u3phy 
*u3phy,
writel(tmp, instance->port_base + U3P_USBPHYACR5);
 }
 
+static void u3_phy_instance_init(struct mt65xx_u3phy *u3phy,
+   struct mt65xx_phy_instance *instance)
+{
+   void __iomem *port_base = instance->port_base;
+   u32 tmp;
+
+   /* gating PCIe Analog XTAL clock */
+   tmp = readl(u3phy->sif_base + U3P_XTALCTL3);
+   tmp |= XC3_RG_U3_XTAL_RX_PWD | XC3_RG_U3_FRC_XTAL_RX_PWD;
+   writel(tmp, u3phy->sif_base + U3P_XTALCTL3);
+
+   /* gating XSQ */
+   tmp = readl(port_base + U3P_U3PHYA_DA_REG0);
+   tmp &= ~P3A_RG_XTAL_EXT_EN_U3;
+   tmp |= P3A_RG_XTAL_EXT_EN_U3_VAL(2);
+   writel(tmp, port_base + U3P_U3PHYA_DA_REG0);
+
+   tmp = readl(port_base + U3P_U3_PHYA_REG9);
+   tmp &= ~P3A_RG_RX_DAC_MUX;
+   tmp |= P3A_RG_RX_DAC_MUX_VAL(4);
+   writel(tmp, port_base + U3P_U3_PHYA_REG9);
+
+   tmp = readl(port_base + U3P_U3_PHYA_REG6);
+   tmp &= ~P3A_RG_TX_EIDLE_CM;
+   tmp |= P3A_RG_TX_EIDLE_CM_VAL(0xe);
+   writel(tmp, port_base + U3P_U3_PHYA_REG6);
+
+   tmp = readl(port_base + 

  1   2   3   4   5   6   7   8   9   10   >