Re: [PATCH v5 7/8] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

[Chanwoo Choi]

Hi Lin,

I add the some comment on below.

If you modify them, feel free to add the my reviewed tag on next version:
Reviewed-by: Chanwoo Choi 

On 2016년 08월 10일 12:26, Lin Huang wrote:
> base on dfi result, we do ddr frequency scaling, register
> dmc driver to devfreq framework, and use simple-ondemand
> policy.
> 
> Signed-off-by: Lin Huang 
> ---
> Changes in v5:
> - improve dmc driver suggest by Chanwoo Choi
> 
> Changes in v4:
> - use arm_smccc_smc() function talk to bl31
> - delete rockchip_dmc.c file and config
> - delete dmc_notify
> - adjust probe order
> 
> Changes in v3:
> - operate dram setting through sip call
> - imporve set rate flow
> 
> Changes in v2:
> - None
> 
> Changes in v1:
> - move dfi controller to event
> - fix set voltage sequence when set rate fail
> - change Kconfig type from tristate to bool
> - move unuse EXPORT_SYMBOL_GPL()
> 
>  drivers/devfreq/Kconfig  |   9 +
>  drivers/devfreq/Makefile |   1 +
>  drivers/devfreq/rk3399_dmc.c | 512 
> +++
>  3 files changed, 522 insertions(+)
>  create mode 100644 drivers/devfreq/rk3399_dmc.c
> 
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index a5be56e..749499d 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -100,6 +100,15 @@ config ARM_TEGRA_DEVFREQ
>   It reads ACTMON counters of memory controllers and adjusts the
>   operating frequencies and voltages with OPP support.
>  
> +config ARM_RK3399_DMC_DEVFREQ
> + tristate "ARM RK3399 DMC DEVFREQ Driver"

depend on ARCH_ROCKCHIP ?

> + select PM_OPP
> + select DEVFREQ_GOV_SIMPLE_ONDEMAND

This entry needs the following command in Kconfig:
select DEVFREQ_EVENT_ROCKCHIP_DFI

> + help
> +  This adds the DEVFREQ driver for the RK3399 dmc(Dynamic Memory 
> Controller).

Use a capital letter for and abbreviation.

s/dmc -> DMC

> +  It sets the frequency for the memory controller and reads the 
> usage counts
> +  from hardware.
> +
>  source "drivers/devfreq/event/Kconfig"
>  
>  endif # PM_DEVFREQ
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 09f11d9..70d9549 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
>  # DEVFREQ Drivers
>  obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
>  obj-$(CONFIG_ARM_TEGRA_DEVFREQ)  += tegra-devfreq.o
> +obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o

The  entry would be positioned
The position of CONFIG_ARM_RK3399_DMC_DEVFREQ would be good on
between EXYNOS_BUS_DEVFREQ and TEGRA_DEVFREQ because of the alphabetical order.

>  
>  # DEVFREQ Event Drivers
>  obj-$(CONFIG_PM_DEVFREQ_EVENT)   += event/
> diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
> new file mode 100644
> index 000..c1157ba
> --- /dev/null
> +++ b/drivers/devfreq/rk3399_dmc.c
> @@ -0,0 +1,512 @@
> +/*
> + * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd.
> + * Author: Lin Huang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +struct dram_timing {
> + unsigned int ddr3_speed_bin;
> + unsigned int pd_idle;
> + unsigned int sr_idle;
> + unsigned int sr_mc_gate_idle;
> + unsigned int srpd_lite_idle;
> + unsigned int standby_idle;
> + unsigned int dram_dll_dis_freq;
> + unsigned int phy_dll_dis_freq;
> + unsigned int ddr3_odt_dis_freq;
> + unsigned int ddr3_drv;
> + unsigned int ddr3_odt;
> + unsigned int phy_ddr3_ca_drv;
> + unsigned int phy_ddr3_dq_drv;
> + unsigned int phy_ddr3_odt;
> + unsigned int lpddr3_odt_dis_freq;
> + unsigned int lpddr3_drv;
> + unsigned int lpddr3_odt;
> + unsigned int phy_lpddr3_ca_drv;
> + unsigned int phy_lpddr3_dq_drv;
> + unsigned int phy_lpddr3_odt;
> + unsigned int lpddr4_odt_dis_freq;
> + unsigned int lpddr4_drv;
> + unsigned int lpddr4_dq_odt;
> + unsigned int lpddr4_ca_odt;
> + unsigned int phy_lpddr4_ca_drv;
> + unsigned int phy_lpddr4_ck_cs_drv;
> + unsigned int phy_lpddr4_dq_drv;
> + unsigned int phy_lpddr4_odt;
> +};
> +
> +struct rk3399_dmcfreq {
> + struct device *dev;
> + struct devfreq 

Re: [PATCH v5 7/8] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

[Chanwoo Choi]

Hi Lin,

I add the some comment on below.

If you modify them, feel free to add the my reviewed tag on next version:
Reviewed-by: Chanwoo Choi 

On 2016년 08월 10일 12:26, Lin Huang wrote:
> base on dfi result, we do ddr frequency scaling, register
> dmc driver to devfreq framework, and use simple-ondemand
> policy.
> 
> Signed-off-by: Lin Huang 
> ---
> Changes in v5:
> - improve dmc driver suggest by Chanwoo Choi
> 
> Changes in v4:
> - use arm_smccc_smc() function talk to bl31
> - delete rockchip_dmc.c file and config
> - delete dmc_notify
> - adjust probe order
> 
> Changes in v3:
> - operate dram setting through sip call
> - imporve set rate flow
> 
> Changes in v2:
> - None
> 
> Changes in v1:
> - move dfi controller to event
> - fix set voltage sequence when set rate fail
> - change Kconfig type from tristate to bool
> - move unuse EXPORT_SYMBOL_GPL()
> 
>  drivers/devfreq/Kconfig  |   9 +
>  drivers/devfreq/Makefile |   1 +
>  drivers/devfreq/rk3399_dmc.c | 512 
> +++
>  3 files changed, 522 insertions(+)
>  create mode 100644 drivers/devfreq/rk3399_dmc.c
> 
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index a5be56e..749499d 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -100,6 +100,15 @@ config ARM_TEGRA_DEVFREQ
>   It reads ACTMON counters of memory controllers and adjusts the
>   operating frequencies and voltages with OPP support.
>  
> +config ARM_RK3399_DMC_DEVFREQ
> + tristate "ARM RK3399 DMC DEVFREQ Driver"

depend on ARCH_ROCKCHIP ?

> + select PM_OPP
> + select DEVFREQ_GOV_SIMPLE_ONDEMAND

This entry needs the following command in Kconfig:
select DEVFREQ_EVENT_ROCKCHIP_DFI

> + help
> +  This adds the DEVFREQ driver for the RK3399 dmc(Dynamic Memory 
> Controller).

Use a capital letter for and abbreviation.

s/dmc -> DMC

> +  It sets the frequency for the memory controller and reads the 
> usage counts
> +  from hardware.
> +
>  source "drivers/devfreq/event/Kconfig"
>  
>  endif # PM_DEVFREQ
> diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
> index 09f11d9..70d9549 100644
> --- a/drivers/devfreq/Makefile
> +++ b/drivers/devfreq/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE) += governor_passive.o
>  # DEVFREQ Drivers
>  obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ) += exynos-bus.o
>  obj-$(CONFIG_ARM_TEGRA_DEVFREQ)  += tegra-devfreq.o
> +obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ) += rk3399_dmc.o

The  entry would be positioned
The position of CONFIG_ARM_RK3399_DMC_DEVFREQ would be good on
between EXYNOS_BUS_DEVFREQ and TEGRA_DEVFREQ because of the alphabetical order.

>  
>  # DEVFREQ Event Drivers
>  obj-$(CONFIG_PM_DEVFREQ_EVENT)   += event/
> diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
> new file mode 100644
> index 000..c1157ba
> --- /dev/null
> +++ b/drivers/devfreq/rk3399_dmc.c
> @@ -0,0 +1,512 @@
> +/*
> + * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd.
> + * Author: Lin Huang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +struct dram_timing {
> + unsigned int ddr3_speed_bin;
> + unsigned int pd_idle;
> + unsigned int sr_idle;
> + unsigned int sr_mc_gate_idle;
> + unsigned int srpd_lite_idle;
> + unsigned int standby_idle;
> + unsigned int dram_dll_dis_freq;
> + unsigned int phy_dll_dis_freq;
> + unsigned int ddr3_odt_dis_freq;
> + unsigned int ddr3_drv;
> + unsigned int ddr3_odt;
> + unsigned int phy_ddr3_ca_drv;
> + unsigned int phy_ddr3_dq_drv;
> + unsigned int phy_ddr3_odt;
> + unsigned int lpddr3_odt_dis_freq;
> + unsigned int lpddr3_drv;
> + unsigned int lpddr3_odt;
> + unsigned int phy_lpddr3_ca_drv;
> + unsigned int phy_lpddr3_dq_drv;
> + unsigned int phy_lpddr3_odt;
> + unsigned int lpddr4_odt_dis_freq;
> + unsigned int lpddr4_drv;
> + unsigned int lpddr4_dq_odt;
> + unsigned int lpddr4_ca_odt;
> + unsigned int phy_lpddr4_ca_drv;
> + unsigned int phy_lpddr4_ck_cs_drv;
> + unsigned int phy_lpddr4_dq_drv;
> + unsigned int phy_lpddr4_odt;
> +};
> +
> +struct rk3399_dmcfreq {
> + struct device *dev;
> + struct devfreq *devfreq;
> + struct devfreq_simple_ondemand_data ondemand_data;
> 

Re: [RFC][PATCH 3/4] arm64: dts: hikey: Add hikey support for syscon-reboot-mode

[John Stultz]

On Tue, Aug 9, 2016 at 9:34 PM, Bjorn Andersson
 wrote:
> On Mon 08 Aug 16:03 PDT 2016, John Stultz wrote:
>
> [..]
>> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
>> b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> [..]
>>   memory@0 {
>>   device_type = "memory";
>>   reg = <0x 0x 0x 0x05e0>,
>> -   <0x 0x05f0 0x 0x00eff000>,
>> +   <0x 0x05f0 0x 0x1000>,
>> +   <0x 0x05f02000 0x 0x00efd000>,
>> <0x 0x06e0 0x 0x0060f000>,
>> <0x 0x0741 0x 0x36bf>;
>>   };
>
> As I said when talked about this, I don't think you should punch holes
> in the /memory node, but rather add these regions as no-map in a
> /reserved-memory node. But that's a unrelated matter.

Yea. I need to sync w/ Wei and Guodong to see about reworking all of
those to use /reserved-memory, but for now I'd like to stay in sync w/
how they have it setup.

>>
>> + reboot-mode-syscon@5f01000 {
>> + compatible = "syscon", "simple-mfd";
>> + reg = <0x0 0x05f01000 0x0 0x1000>;
>> +
>> + reboot-mode@0 {
>
> Drop the @0

Will do.


>
> Other than that:
> Acked-by: Bjorn Andersson 

Thanks!
-john

Re: [RFC][PATCH 3/4] arm64: dts: hikey: Add hikey support for syscon-reboot-mode

[John Stultz]

On Tue, Aug 9, 2016 at 9:34 PM, Bjorn Andersson
 wrote:
> On Mon 08 Aug 16:03 PDT 2016, John Stultz wrote:
>
> [..]
>> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
>> b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> [..]
>>   memory@0 {
>>   device_type = "memory";
>>   reg = <0x 0x 0x 0x05e0>,
>> -   <0x 0x05f0 0x 0x00eff000>,
>> +   <0x 0x05f0 0x 0x1000>,
>> +   <0x 0x05f02000 0x 0x00efd000>,
>> <0x 0x06e0 0x 0x0060f000>,
>> <0x 0x0741 0x 0x36bf>;
>>   };
>
> As I said when talked about this, I don't think you should punch holes
> in the /memory node, but rather add these regions as no-map in a
> /reserved-memory node. But that's a unrelated matter.

Yea. I need to sync w/ Wei and Guodong to see about reworking all of
those to use /reserved-memory, but for now I'd like to stay in sync w/
how they have it setup.

>>
>> + reboot-mode-syscon@5f01000 {
>> + compatible = "syscon", "simple-mfd";
>> + reg = <0x0 0x05f01000 0x0 0x1000>;
>> +
>> + reboot-mode@0 {
>
> Drop the @0

Will do.


>
> Other than that:
> Acked-by: Bjorn Andersson 

Thanks!
-john

Re: [RFC PATCH 2/3] net: macb: Add support for 1588 for Zynq Ultrascale+ MPSoC

[Harini Katakam]

Hi Nicolas,

Thanks for your reply

On Tue, Aug 9, 2016 at 10:26 PM, Punnaiah Choudary Kalluri
 wrote:
> Hi Nicolas,
>
>  1588 implementation in cadence GEM IP we have in Zynq Ultascale+ MPSoC is
> Different to the one in Zynq SOC.
>
> In earlier version, all timestamp values will be stored in registers and 
> there is no specific
> Mechanism to distinguish the received ethernet frame that contains time stamp 
> information
> Other than parsing the frame for PTP packet type.
>
> We have basic implementation for earlier version in our out of tree driver, 
> which is going to be deprecated
> Soon. You could also check the below driver for 1588 support.
> https://gitenterprise.xilinx.com/Linux/linux-xlnx/blob/master/drivers/net/ethernet/xilinx/xilinx_emacps.c
>
>
> Regards,
> Punnaiah
>
>> -Original Message-
>> From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com]
>> Sent: Tuesday, August 09, 2016 10:10 PM
>> To: Harini Katakam ; Harini Katakam
>> ; Andrei Pistirica 
>> Cc: da...@davemloft.net; Boris Brezillon > electrons.com>; alexandre.bell...@free-electrons.com;
>> net...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> devicet...@vger.kernel.org; Punnaiah Choudary Kalluri
>> ; Michal Simek ; Anirudha
>> Sarangi 
>> Subject: Re: [RFC PATCH 2/3] net: macb: Add support for 1588 for Zynq
>> Ultrascale+ MPSoC
>>
>> Le 21/09/2015 à 19:49, Harini Katakam a écrit :
>> > On Fri, Sep 11, 2015 at 1:27 PM, Harini Katakam
>> >  wrote:
>> >> Cadence GEM in Zynq Ultrascale+ MPSoC supports 1588 and provides a
>> >> 102 bit time counter with 48 bits for seconds, 30 bits for nsecs and
>> >> 24 bits for sub-nsecs. The timestamp is made available to the SW through
>> >> registers as well as (more precisely) through upper two words in
>> >> an extended BD.
>> >>
>> >> This patch does the following:
>> >> - Adds MACB_CAPS_TSU in zynqmp_config.
>> >> - Registers to ptp clock framework (after checking for timestamp support
>> in
>> >>   IP and capability in config).
>> >> - TX BD and RX BD control registers are written to populate timestamp in
>> >>   extended BD words.
>> >> - Timer initialization is done by writing time of day to the timer 
>> >> counter.
>> >> - ns increment register is programmed as NS_PER_SEC/TSU_CLK.
>> >>   For a 24 bit subns precision, the subns increment equals
>> >>   remainder of (NS_PER_SEC/TSU_CLK) * (2^24).
>> >>   TSU (Time stamp unit) clock is obtained by the  driver from devicetree.
>> >> - HW time stamp capabilities are advertised via ethtool and macb ioctl is
>> >>   updated accordingly.
>> >> - For all PTP event frames, nanoseconds and the lower 5 bits of seconds
>> are
>> >>   obtained from the BD. This offers a precise timestamp. The upper bits
>> >>   (which dont vary between consecutive packets) are obtained from the
>> >>   TX/RX PTP event/PEER registers. The timestamp obtained thus is
>> updated
>> >>   in skb for upper layers to access.
>> >> - The drivers register functions with ptp to perform time and frequency
>> >>   adjustment.
>> >> - Time adjustment is done by writing to the 1558_ADJUST register.
>> >>   The controller will read the delta in this register and update the timer
>> >>   counter register. Alternatively, for large time offset adjustments,
>> >>   the driver reads the secs and nsecs counter values, adds/subtracts the
>> >>   delta and updates the timer counter. In order to be as precise as
>> possible,
>> >>   nsecs counter is read again if secs has incremented during the counter
>> read.
>> >> - Frequency adjustment is not directly supported by this IP.
>> >>   addend is the initial value ns increment and similarly addendesub.
>> >>   The ppb (parts per billion) provided is used as
>> >>   ns_incr = addend +/- (ppb/rate).
>> >>   Similarly the remainder of the above is used to populate subns
>> increment.
>> >>   In case the ppb requested is negative AND subns adjustment greater
>> than
>> >>   the addendsub, ns_incr is reduced by 1 and subns_incr is adjusted in
>> >>   positive accordingly.
>> >>
>> >> Signed-off-by: Harini Katakam :
>> >> ---
>> >>  drivers/net/ethernet/cadence/macb.c |  372
>> ++-
>> >>  drivers/net/ethernet/cadence/macb.h |   64 ++
>> >>  2 files changed, 428 insertions(+), 8 deletions(-)
>> >>
>> >> diff --git a/drivers/net/ethernet/cadence/macb.c
>> b/drivers/net/ethernet/cadence/macb.c
>> >> index bb2932c..b531008 100644
>> >> --- a/drivers/net/ethernet/cadence/macb.c
>> >> +++ b/drivers/net/ethernet/cadence/macb.c
>> >> @@ -30,6 +30,8 @@
>> >>  #include 
>> >>  #include 
>>
>> [..]
>>
>> >> +   unsigned intns_incr;
>> >> +   unsigned intsubns_incr;
>> >>  };
>> >>
>> >>  static inline bool macb_is_gem(struct macb *bp)
>> 

Re: [RFC PATCH 2/3] net: macb: Add support for 1588 for Zynq Ultrascale+ MPSoC

[Harini Katakam]

Hi Nicolas,

Thanks for your reply

On Tue, Aug 9, 2016 at 10:26 PM, Punnaiah Choudary Kalluri
 wrote:
> Hi Nicolas,
>
>  1588 implementation in cadence GEM IP we have in Zynq Ultascale+ MPSoC is
> Different to the one in Zynq SOC.
>
> In earlier version, all timestamp values will be stored in registers and 
> there is no specific
> Mechanism to distinguish the received ethernet frame that contains time stamp 
> information
> Other than parsing the frame for PTP packet type.
>
> We have basic implementation for earlier version in our out of tree driver, 
> which is going to be deprecated
> Soon. You could also check the below driver for 1588 support.
> https://gitenterprise.xilinx.com/Linux/linux-xlnx/blob/master/drivers/net/ethernet/xilinx/xilinx_emacps.c
>
>
> Regards,
> Punnaiah
>
>> -Original Message-
>> From: Nicolas Ferre [mailto:nicolas.fe...@atmel.com]
>> Sent: Tuesday, August 09, 2016 10:10 PM
>> To: Harini Katakam ; Harini Katakam
>> ; Andrei Pistirica 
>> Cc: da...@davemloft.net; Boris Brezillon > electrons.com>; alexandre.bell...@free-electrons.com;
>> net...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> devicet...@vger.kernel.org; Punnaiah Choudary Kalluri
>> ; Michal Simek ; Anirudha
>> Sarangi 
>> Subject: Re: [RFC PATCH 2/3] net: macb: Add support for 1588 for Zynq
>> Ultrascale+ MPSoC
>>
>> Le 21/09/2015 à 19:49, Harini Katakam a écrit :
>> > On Fri, Sep 11, 2015 at 1:27 PM, Harini Katakam
>> >  wrote:
>> >> Cadence GEM in Zynq Ultrascale+ MPSoC supports 1588 and provides a
>> >> 102 bit time counter with 48 bits for seconds, 30 bits for nsecs and
>> >> 24 bits for sub-nsecs. The timestamp is made available to the SW through
>> >> registers as well as (more precisely) through upper two words in
>> >> an extended BD.
>> >>
>> >> This patch does the following:
>> >> - Adds MACB_CAPS_TSU in zynqmp_config.
>> >> - Registers to ptp clock framework (after checking for timestamp support
>> in
>> >>   IP and capability in config).
>> >> - TX BD and RX BD control registers are written to populate timestamp in
>> >>   extended BD words.
>> >> - Timer initialization is done by writing time of day to the timer 
>> >> counter.
>> >> - ns increment register is programmed as NS_PER_SEC/TSU_CLK.
>> >>   For a 24 bit subns precision, the subns increment equals
>> >>   remainder of (NS_PER_SEC/TSU_CLK) * (2^24).
>> >>   TSU (Time stamp unit) clock is obtained by the  driver from devicetree.
>> >> - HW time stamp capabilities are advertised via ethtool and macb ioctl is
>> >>   updated accordingly.
>> >> - For all PTP event frames, nanoseconds and the lower 5 bits of seconds
>> are
>> >>   obtained from the BD. This offers a precise timestamp. The upper bits
>> >>   (which dont vary between consecutive packets) are obtained from the
>> >>   TX/RX PTP event/PEER registers. The timestamp obtained thus is
>> updated
>> >>   in skb for upper layers to access.
>> >> - The drivers register functions with ptp to perform time and frequency
>> >>   adjustment.
>> >> - Time adjustment is done by writing to the 1558_ADJUST register.
>> >>   The controller will read the delta in this register and update the timer
>> >>   counter register. Alternatively, for large time offset adjustments,
>> >>   the driver reads the secs and nsecs counter values, adds/subtracts the
>> >>   delta and updates the timer counter. In order to be as precise as
>> possible,
>> >>   nsecs counter is read again if secs has incremented during the counter
>> read.
>> >> - Frequency adjustment is not directly supported by this IP.
>> >>   addend is the initial value ns increment and similarly addendesub.
>> >>   The ppb (parts per billion) provided is used as
>> >>   ns_incr = addend +/- (ppb/rate).
>> >>   Similarly the remainder of the above is used to populate subns
>> increment.
>> >>   In case the ppb requested is negative AND subns adjustment greater
>> than
>> >>   the addendsub, ns_incr is reduced by 1 and subns_incr is adjusted in
>> >>   positive accordingly.
>> >>
>> >> Signed-off-by: Harini Katakam :
>> >> ---
>> >>  drivers/net/ethernet/cadence/macb.c |  372
>> ++-
>> >>  drivers/net/ethernet/cadence/macb.h |   64 ++
>> >>  2 files changed, 428 insertions(+), 8 deletions(-)
>> >>
>> >> diff --git a/drivers/net/ethernet/cadence/macb.c
>> b/drivers/net/ethernet/cadence/macb.c
>> >> index bb2932c..b531008 100644
>> >> --- a/drivers/net/ethernet/cadence/macb.c
>> >> +++ b/drivers/net/ethernet/cadence/macb.c
>> >> @@ -30,6 +30,8 @@
>> >>  #include 
>> >>  #include 
>>
>> [..]
>>
>> >> +   unsigned intns_incr;
>> >> +   unsigned intsubns_incr;
>> >>  };
>> >>
>> >>  static inline bool macb_is_gem(struct macb *bp)
>> >> --
>> >> 1.7.9.5
>> >
>> > Ping
>> >
>> > Thanks.
>>
>> Harini,
>>
>> I come back to this patch of last year and I'm sorry about being so late
>> answering you.
>>
>> Andrei who is added to the discussion will have some time to deal with
>> this 

Re: [PATCH v5 7/8] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

[kbuild test robot]

Hi Lin,

[auto build test WARNING on v4.8-rc1]
[also build test WARNING on next-20160809]
[cannot apply to rockchip/for-next devfreq/for-rafael linux/master]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Lin-Huang/rk3399-support-ddr-frequency-scaling/20160810-114433


coccinelle warnings: (new ones prefixed by >>)

>> drivers/devfreq/rk3399_dmc.c:393:2-3: Unneeded semicolon

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH v5 4/8] Documentation: bindings: add dt documentation for dfi controller

[Chanwoo Choi]

Hi Lin,

On 2016년 08월 10일 12:26, Lin Huang wrote:
> This patch adds the documentation for rockchip dfi devfreq-event driver.
> 
> Signed-off-by: Lin Huang 
> ---
> Changes in v5:
> -None
> 
> Changes in v4:
> -None
> 
> Changes in v3:
> -None
> 
> Changes in v2:
> -None 
> 
> Changes in v1:
> -None
> 
>  .../bindings/devfreq/event/rockchip-dfi.txt  | 20 
> 
>  1 file changed, 20 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
> 
> diff --git a/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt 
> b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
> new file mode 100644
> index 000..bf42255
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
> @@ -0,0 +1,20 @@
> +
> +* Rockchip rk3399 DFI device
> +
> +Required properties:
> +- compatible: Must be "rockchip,rk3399-dfi".
> +- reg: physical base address of each DFI and length of memory mapped region
> +- rockchip,pmu: phandle to the syscon managing the "pmu general register 
> files"
> +- clocks: phandles for clock specified in "clock-names" property
> +- clock-names : the name of clock used by the DFI, must be "pclk_ddr_mon";
> +
> +Example:
> + dfi: dfi@0xff63 {
> + reg = <0x00 0xff63 0x00 0x4000>;
> + compatible = "rockchip,rk3399-dfi";

Usually, the compatible is first entry within Device-tree node.

> + rockchip,pmu = <>;
> + clocks = < PCLK_DDR_MON>;
> + clock-names = "pclk_ddr_mon";
> + status = "disabled";
> + };
> +
> 

Looks good to me. Just I want to change the sequence
between 'compatible' and 'reg' property.

Acked-by: Chanwoo Choi 

Regards,
Chawnoo Choi

Re: [PATCH v5 7/8] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

[kbuild test robot]

Hi Lin,

[auto build test WARNING on v4.8-rc1]
[also build test WARNING on next-20160809]
[cannot apply to rockchip/for-next devfreq/for-rafael linux/master]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Lin-Huang/rk3399-support-ddr-frequency-scaling/20160810-114433


coccinelle warnings: (new ones prefixed by >>)

>> drivers/devfreq/rk3399_dmc.c:393:2-3: Unneeded semicolon

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Re: [PATCH v5 4/8] Documentation: bindings: add dt documentation for dfi controller

[Chanwoo Choi]

Hi Lin,

On 2016년 08월 10일 12:26, Lin Huang wrote:
> This patch adds the documentation for rockchip dfi devfreq-event driver.
> 
> Signed-off-by: Lin Huang 
> ---
> Changes in v5:
> -None
> 
> Changes in v4:
> -None
> 
> Changes in v3:
> -None
> 
> Changes in v2:
> -None 
> 
> Changes in v1:
> -None
> 
>  .../bindings/devfreq/event/rockchip-dfi.txt  | 20 
> 
>  1 file changed, 20 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
> 
> diff --git a/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt 
> b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
> new file mode 100644
> index 000..bf42255
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
> @@ -0,0 +1,20 @@
> +
> +* Rockchip rk3399 DFI device
> +
> +Required properties:
> +- compatible: Must be "rockchip,rk3399-dfi".
> +- reg: physical base address of each DFI and length of memory mapped region
> +- rockchip,pmu: phandle to the syscon managing the "pmu general register 
> files"
> +- clocks: phandles for clock specified in "clock-names" property
> +- clock-names : the name of clock used by the DFI, must be "pclk_ddr_mon";
> +
> +Example:
> + dfi: dfi@0xff63 {
> + reg = <0x00 0xff63 0x00 0x4000>;
> + compatible = "rockchip,rk3399-dfi";

Usually, the compatible is first entry within Device-tree node.

> + rockchip,pmu = <>;
> + clocks = < PCLK_DDR_MON>;
> + clock-names = "pclk_ddr_mon";
> + status = "disabled";
> + };
> +
> 

Looks good to me. Just I want to change the sequence
between 'compatible' and 'reg' property.

Acked-by: Chanwoo Choi 

Regards,
Chawnoo Choi

[PATCH] PM / devfreq: rockchip: fix semicolon.cocci warnings

[kbuild test robot]

drivers/devfreq/rk3399_dmc.c:393:2-3: Unneeded semicolon


 Remove unneeded semicolon.

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

CC: Lin Huang 
Signed-off-by: Fengguang Wu 
---

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

--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -390,7 +390,7 @@ static int rk3399_dmcfreq_probe(struct p
if (IS_ERR(data->dmc_clk)) {
dev_err(dev, "Cannot get the clk dmc_clk\n");
return PTR_ERR(data->dmc_clk);
-   };
+   }
 
data->irq = irq;
ret = devm_request_irq(dev, irq, rk3399_dmc_irq, 0,

[PATCH] PM / devfreq: rockchip: fix semicolon.cocci warnings

[kbuild test robot]

drivers/devfreq/rk3399_dmc.c:393:2-3: Unneeded semicolon


 Remove unneeded semicolon.

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

CC: Lin Huang 
Signed-off-by: Fengguang Wu 
---

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

--- a/drivers/devfreq/rk3399_dmc.c
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -390,7 +390,7 @@ static int rk3399_dmcfreq_probe(struct p
if (IS_ERR(data->dmc_clk)) {
dev_err(dev, "Cannot get the clk dmc_clk\n");
return PTR_ERR(data->dmc_clk);
-   };
+   }
 
data->irq = irq;
ret = devm_request_irq(dev, irq, rk3399_dmc_irq, 0,

Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands

[Damien Le Moal]

Shaun,

On 8/10/16 12:58, Shaun Tancheff wrote:

On Tue, Aug 9, 2016 at 3:09 AM, Damien Le Moal  wrote:

On Aug 9, 2016, at 15:47, Hannes Reinecke  wrote:


[trim]


Since disk type == 0 for everything that isn't HM so I would prefer the
sysfs 'zoned' file just report if the drive is HA or HM.


Okay. So let's put in the 'zoned' attribute the device type:
'host-managed', 'host-aware', or 'device managed'.


I hacked your patches and simply put a "0" or "1" in the sysfs zoned file.
Any drive that has ZBC/ZAC command support gets a "1", "0" for everything
else. This means that drive managed models are not exposed as zoned block
devices. For HM vs HA differentiation, an application can look at the
device type file since it is already present.

We could indeed set the "zoned" file to the device type, but HM drives and
regular drives will both have "0" in it, so no differentiation possible.
The other choice could be the "zoned" bits defined by ZBC, but these
do not define a value for host managed drives, and the drive managed value
being not "0" could be confusing too. So I settled for a simple 0/1 boolean.


This seems good to me.


Another option I forgot is for the "zoned" file to indicate the total 
number of zones of the device, and 0 for a non zoned regular block 
device. That would work as well.


[...]

Done: I hacked Shaun ioctl code and added finish zone too. The
difference with Shaun initial code is that the ioctl are propagated down to
the driver (__blkdev_driver_ioctl -> sd_ioctl) so that there is no need for
BIO request definition for the zone operations. So a lot less code added.


The purpose of the BIO flags is not to enable the ioctls so much as
the other way round. Creating BIO op's is to enable issuing ZBC
commands from device mapper targets and file systems without some
heinous ioctl hacks.
Making the resulting block layer interfaces available via ioctls is just a
reasonable way to exercise the code ... or that was my intent.


Yes, I understood your code. However, since (or if) we keep the zone 
information in the RB-tree cache, there is no need for the report zone 
operation BIO interface. Same for reset write pointer by keeping the 
mapping to discard. blk_lookup_zone can be used in kernel as a report 
zone BIO replacement and works as well for the report zone ioctl 
implementation. For reset, there is blkdev_issue_discrad in kernel, and 
the reset zone ioctl becomes equivalent to BLKDISCARD ioctl. These are 
simple. Open, close and finish zone remains. For these, adding the BIO 
interface seemed an overkill. Hence my choice of propagating the ioctl 
to the driver.
This is debatable of course, and adding an in-kernel interface is not 
hard: we can implement blk_open_zone, blk_close_zone and blk_finish_zone 
using __blkdev_driver_ioctl. That looks clean to me.


Overall, my concern with the BIO based interface for the ZBC commands is 
that it adds one flag for each command, which is not really the 
philosophy of the interface and potentially opens the door for more such 
implementations in the future with new standards and new commands coming 
up. Clearly that is not a sustainable path. So I think that a more 
specific interface for these zone operations is a better choice. That is 
consistent with what happens with the tons of ATA and SCSI commands not 
actually doing data I/Os (mode sense, log pages, SMART, etc). All these 
do not use BIOs and are processed as request REQ_TYPE_BLOCK_PC.



The ioctls do not mimic exactly the ZBC standard. For instance, there is no
reporting options for report zones, nor is the "all" bit supported for open,
close or finish zone commands. But the information provided on zones is complete
and maps to the standard definitions.


For the reporting options I have planned to reuse the stream_id in
struct bio when that is formalized. There are certainly other places in
struct bio to stuff a few extra bits ...


We could add reporting options to blk_lookup_zones to filter the result 
and use that in the ioctl implementation as well. This can be added 
without any problem.



As far as the all bit ... this is being handled by all the zone action
commands. Just pass a sector of ~0ul and it's handled in sd.c by
sd_setup_zone_action_cmnd().

Apologies as apparently my documentation here is lacking :-(


Yes, I got it (libzbc does the same actually). I did not add it for 
simplicity. But indeed may be it should be. The same trick can be used 
with the ioctl to driver interface. No problems.



I also added a reset_wp ioctl for completeness, but this one simply calls
blkdev_issue_discard internally, so it is in fact equivalent to the BLKDISCARD
ioctl call with a range exactly aligned on a zone.


I'm confused as my patch set includes a Reset WP (BLKRESETZONE) that
creates a REQ_OP_ZONE_RESET .. same as open and close. My
expectation being that BLKDISCARD doesn't really need yet another alias.


Yes, we could remove the 

Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands

[Damien Le Moal]

Shaun,

On 8/10/16 12:58, Shaun Tancheff wrote:

On Tue, Aug 9, 2016 at 3:09 AM, Damien Le Moal  wrote:

On Aug 9, 2016, at 15:47, Hannes Reinecke  wrote:


[trim]


Since disk type == 0 for everything that isn't HM so I would prefer the
sysfs 'zoned' file just report if the drive is HA or HM.


Okay. So let's put in the 'zoned' attribute the device type:
'host-managed', 'host-aware', or 'device managed'.


I hacked your patches and simply put a "0" or "1" in the sysfs zoned file.
Any drive that has ZBC/ZAC command support gets a "1", "0" for everything
else. This means that drive managed models are not exposed as zoned block
devices. For HM vs HA differentiation, an application can look at the
device type file since it is already present.

We could indeed set the "zoned" file to the device type, but HM drives and
regular drives will both have "0" in it, so no differentiation possible.
The other choice could be the "zoned" bits defined by ZBC, but these
do not define a value for host managed drives, and the drive managed value
being not "0" could be confusing too. So I settled for a simple 0/1 boolean.


This seems good to me.


Another option I forgot is for the "zoned" file to indicate the total 
number of zones of the device, and 0 for a non zoned regular block 
device. That would work as well.


[...]

Done: I hacked Shaun ioctl code and added finish zone too. The
difference with Shaun initial code is that the ioctl are propagated down to
the driver (__blkdev_driver_ioctl -> sd_ioctl) so that there is no need for
BIO request definition for the zone operations. So a lot less code added.


The purpose of the BIO flags is not to enable the ioctls so much as
the other way round. Creating BIO op's is to enable issuing ZBC
commands from device mapper targets and file systems without some
heinous ioctl hacks.
Making the resulting block layer interfaces available via ioctls is just a
reasonable way to exercise the code ... or that was my intent.


Yes, I understood your code. However, since (or if) we keep the zone 
information in the RB-tree cache, there is no need for the report zone 
operation BIO interface. Same for reset write pointer by keeping the 
mapping to discard. blk_lookup_zone can be used in kernel as a report 
zone BIO replacement and works as well for the report zone ioctl 
implementation. For reset, there is blkdev_issue_discrad in kernel, and 
the reset zone ioctl becomes equivalent to BLKDISCARD ioctl. These are 
simple. Open, close and finish zone remains. For these, adding the BIO 
interface seemed an overkill. Hence my choice of propagating the ioctl 
to the driver.
This is debatable of course, and adding an in-kernel interface is not 
hard: we can implement blk_open_zone, blk_close_zone and blk_finish_zone 
using __blkdev_driver_ioctl. That looks clean to me.


Overall, my concern with the BIO based interface for the ZBC commands is 
that it adds one flag for each command, which is not really the 
philosophy of the interface and potentially opens the door for more such 
implementations in the future with new standards and new commands coming 
up. Clearly that is not a sustainable path. So I think that a more 
specific interface for these zone operations is a better choice. That is 
consistent with what happens with the tons of ATA and SCSI commands not 
actually doing data I/Os (mode sense, log pages, SMART, etc). All these 
do not use BIOs and are processed as request REQ_TYPE_BLOCK_PC.



The ioctls do not mimic exactly the ZBC standard. For instance, there is no
reporting options for report zones, nor is the "all" bit supported for open,
close or finish zone commands. But the information provided on zones is complete
and maps to the standard definitions.


For the reporting options I have planned to reuse the stream_id in
struct bio when that is formalized. There are certainly other places in
struct bio to stuff a few extra bits ...


We could add reporting options to blk_lookup_zones to filter the result 
and use that in the ioctl implementation as well. This can be added 
without any problem.



As far as the all bit ... this is being handled by all the zone action
commands. Just pass a sector of ~0ul and it's handled in sd.c by
sd_setup_zone_action_cmnd().

Apologies as apparently my documentation here is lacking :-(


Yes, I got it (libzbc does the same actually). I did not add it for 
simplicity. But indeed may be it should be. The same trick can be used 
with the ioctl to driver interface. No problems.



I also added a reset_wp ioctl for completeness, but this one simply calls
blkdev_issue_discard internally, so it is in fact equivalent to the BLKDISCARD
ioctl call with a range exactly aligned on a zone.


I'm confused as my patch set includes a Reset WP (BLKRESETZONE) that
creates a REQ_OP_ZONE_RESET .. same as open and close. My
expectation being that BLKDISCARD doesn't really need yet another alias.


Yes, we could remove the BLKRESETZONE ioctl and have applications use 

Re: [PATCH v5 6/8] Documentation: bindings: add dt documentation for rk3399 dmc

[Chanwoo Choi]

Hi Lin,

On 2016년 08월 10일 12:26, Lin Huang wrote:
> This patch adds the documentation for rockchip rk3399 dmc driver.
> 
> Signed-off-by: Lin Huang 
> ---
> Changes in v5:
> -None
> 
> Changes in v4:
> -None
> 
> Changes in v3:
> -None
> 
> Changes in v2:
> -None 
> 
> Changes in v1:
> -None
> 
>  .../devicetree/bindings/devfreq/rk3399_dmc.txt | 35 
> ++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> 
> diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt 
> b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> new file mode 100644
> index 000..90e9581
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> @@ -0,0 +1,35 @@
> +* Rockchip rk3399 dmc device

dmc -> DMC(Dynamic Memory Controller ?)

> +
> +Required properties:
> +- compatible: Must be "rockchip,rk3399-dmc".
> +- devfreq-events: Node to get ddr loading, Refer to
> +   Documentation/devicetree/bindings/devfreq/rockchip-dif.txt
> +- interrupts: The interrupt number to the cpu. The interrupt specifier format
> +   depends on the interrupt controller. 

If you add the specific role of this interrupt, it would be better
to understand the operation of interrupt.

> +- clocks: Phandles for clock specified in "clock-names" property
> +- clock-names : The name of clock used by the DFI, must be "pclk_ddr_mon";

"pclk_ddr_mon" -> "dmc_clk"

> +- operating-points-v2: Refer to 
> Documentation/devicetree/bindings/power/opp.txt
> +for details.
> +- center-supply: Dmc supply node.
> +- status: Marks the node enabled/disabled.
> +
> +Optional properties:
> +- ddr_timing: ddr timing need to pass to arm trust firmware
> +- upthreshold: the upthreshold to simpleondeamnd policy
> +- downdifferential: The downdifferential to simpleondeamnd policy
> +
> +Example:
> + dmc: dmc {
> + compatible = "rockchip,rk3399-dmc";
> + devfreq-events = <>;
> + interrupts = ;
> + clocks = < SCLK_DDRCLK>;
> + clock-names = "dmc_clk";
> + ddr_timing = <_timing>;

I think that you should add the detailed document for 
'ddr_timing' because we don't understand the 'ddr_timing' easily
, it depends on the trust firmware.

> + operating-points-v2 = <_opp_table>;

I think that you better to add the example of 'dmc_opp_table' 
in the documentation.

> + center-supply = <_centerlogic>;
> + upthreshold = <15>;
> + downdifferential = <10>;
> + status = "disabled";
> + };
> +
> 

Regards,
Chanwoo Choi

Re: [PATCH v5 6/8] Documentation: bindings: add dt documentation for rk3399 dmc

[Chanwoo Choi]

Hi Lin,

On 2016년 08월 10일 12:26, Lin Huang wrote:
> This patch adds the documentation for rockchip rk3399 dmc driver.
> 
> Signed-off-by: Lin Huang 
> ---
> Changes in v5:
> -None
> 
> Changes in v4:
> -None
> 
> Changes in v3:
> -None
> 
> Changes in v2:
> -None 
> 
> Changes in v1:
> -None
> 
>  .../devicetree/bindings/devfreq/rk3399_dmc.txt | 35 
> ++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> 
> diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt 
> b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> new file mode 100644
> index 000..90e9581
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
> @@ -0,0 +1,35 @@
> +* Rockchip rk3399 dmc device

dmc -> DMC(Dynamic Memory Controller ?)

> +
> +Required properties:
> +- compatible: Must be "rockchip,rk3399-dmc".
> +- devfreq-events: Node to get ddr loading, Refer to
> +   Documentation/devicetree/bindings/devfreq/rockchip-dif.txt
> +- interrupts: The interrupt number to the cpu. The interrupt specifier format
> +   depends on the interrupt controller. 

If you add the specific role of this interrupt, it would be better
to understand the operation of interrupt.

> +- clocks: Phandles for clock specified in "clock-names" property
> +- clock-names : The name of clock used by the DFI, must be "pclk_ddr_mon";

"pclk_ddr_mon" -> "dmc_clk"

> +- operating-points-v2: Refer to 
> Documentation/devicetree/bindings/power/opp.txt
> +for details.
> +- center-supply: Dmc supply node.
> +- status: Marks the node enabled/disabled.
> +
> +Optional properties:
> +- ddr_timing: ddr timing need to pass to arm trust firmware
> +- upthreshold: the upthreshold to simpleondeamnd policy
> +- downdifferential: The downdifferential to simpleondeamnd policy
> +
> +Example:
> + dmc: dmc {
> + compatible = "rockchip,rk3399-dmc";
> + devfreq-events = <>;
> + interrupts = ;
> + clocks = < SCLK_DDRCLK>;
> + clock-names = "dmc_clk";
> + ddr_timing = <_timing>;

I think that you should add the detailed document for 
'ddr_timing' because we don't understand the 'ddr_timing' easily
, it depends on the trust firmware.

> + operating-points-v2 = <_opp_table>;

I think that you better to add the example of 'dmc_opp_table' 
in the documentation.

> + center-supply = <_centerlogic>;
> + upthreshold = <15>;
> + downdifferential = <10>;
> + status = "disabled";
> + };
> +
> 

Regards,
Chanwoo Choi

Re: [PATCH v3] powerpc: Do not make the entire heap executable

[Michael Ellerman]

Denys Vlasenko  writes:

> On 32-bit powerps the ELF PLT sections of binaries (built with --bss-plt,
> or with a toolchain which defaults to it) look like this:
...
>
>  arch/powerpc/include/asm/page.h| 10 +-
>  arch/powerpc/include/asm/page_32.h |  2 --
>  arch/powerpc/include/asm/page_64.h |  4 
>  fs/binfmt_elf.c| 34 ++
>  include/linux/mm.h |  1 +
>  mm/mmap.c  | 20 +++-
>  6 files changed, 43 insertions(+), 28 deletions(-)

What tree is this against?

I can't get it to apply to either Linus' tree or linux-next.

cheers

$ patch --dry-run -p1 < diff.diff
checking file arch/powerpc/include/asm/page.h
checking file arch/powerpc/include/asm/page_32.h
checking file arch/powerpc/include/asm/page_64.h
checking file fs/binfmt_elf.c
Hunk #3 FAILED at 613.
Hunk #4 FAILED at 633.
Hunk #5 succeeded at 681 (offset 2 lines).
Hunk #6 succeeded at 889 (offset 2 lines).
Hunk #7 succeeded at 984 (offset 2 lines).
Hunk #8 succeeded at 1003 (offset 2 lines).
2 out of 8 hunks FAILED
checking file include/linux/mm.h
checking file mm/mmap.c
Hunk #1 FAILED at 2653.
Hunk #2 succeeded at 2668 (offset 2 lines).
Hunk #3 succeeded at 2736 (offset 2 lines).
Hunk #4 succeeded at 2750 (offset 2 lines).
1 out of 4 hunks FAILED

Re: [PATCH v3] powerpc: Do not make the entire heap executable

[Michael Ellerman]

Denys Vlasenko  writes:

> On 32-bit powerps the ELF PLT sections of binaries (built with --bss-plt,
> or with a toolchain which defaults to it) look like this:
...
>
>  arch/powerpc/include/asm/page.h| 10 +-
>  arch/powerpc/include/asm/page_32.h |  2 --
>  arch/powerpc/include/asm/page_64.h |  4 
>  fs/binfmt_elf.c| 34 ++
>  include/linux/mm.h |  1 +
>  mm/mmap.c  | 20 +++-
>  6 files changed, 43 insertions(+), 28 deletions(-)

What tree is this against?

I can't get it to apply to either Linus' tree or linux-next.

cheers

$ patch --dry-run -p1 < diff.diff
checking file arch/powerpc/include/asm/page.h
checking file arch/powerpc/include/asm/page_32.h
checking file arch/powerpc/include/asm/page_64.h
checking file fs/binfmt_elf.c
Hunk #3 FAILED at 613.
Hunk #4 FAILED at 633.
Hunk #5 succeeded at 681 (offset 2 lines).
Hunk #6 succeeded at 889 (offset 2 lines).
Hunk #7 succeeded at 984 (offset 2 lines).
Hunk #8 succeeded at 1003 (offset 2 lines).
2 out of 8 hunks FAILED
checking file include/linux/mm.h
checking file mm/mmap.c
Hunk #1 FAILED at 2653.
Hunk #2 succeeded at 2668 (offset 2 lines).
Hunk #3 succeeded at 2736 (offset 2 lines).
Hunk #4 succeeded at 2750 (offset 2 lines).
1 out of 4 hunks FAILED

Re: [RFC][PATCH 3/4] arm64: dts: hikey: Add hikey support for syscon-reboot-mode

[Bjorn Andersson]

On Mon 08 Aug 16:03 PDT 2016, John Stultz wrote:

[..]
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
> b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
[..]
>   memory@0 {
>   device_type = "memory";
>   reg = <0x 0x 0x 0x05e0>,
> -   <0x 0x05f0 0x 0x00eff000>,
> +   <0x 0x05f0 0x 0x1000>,
> +   <0x 0x05f02000 0x 0x00efd000>,
> <0x 0x06e0 0x 0x0060f000>,
> <0x 0x0741 0x 0x36bf>;
>   };

As I said when talked about this, I don't think you should punch holes
in the /memory node, but rather add these regions as no-map in a
/reserved-memory node. But that's a unrelated matter.

>  
> + reboot-mode-syscon@5f01000 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0x0 0x05f01000 0x0 0x1000>;
> +
> + reboot-mode@0 {

Drop the @0

Other than that:
Acked-by: Bjorn Andersson 

> + compatible = "syscon-reboot-mode";
> + offset = <0x0>;
> +
> + mode-normal = <0x77665501>;
> + mode-bootloader = <0x77665500>;
> + mode-recovery   = <0x77665502>;
> + };
> + };
> +
>   soc {
>   spi0: spi@f7106000 {
>   status = "ok";

Regards,
Bjorn

Re: [RFC][PATCH 3/4] arm64: dts: hikey: Add hikey support for syscon-reboot-mode

[Bjorn Andersson]

On Mon 08 Aug 16:03 PDT 2016, John Stultz wrote:

[..]
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
> b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
[..]
>   memory@0 {
>   device_type = "memory";
>   reg = <0x 0x 0x 0x05e0>,
> -   <0x 0x05f0 0x 0x00eff000>,
> +   <0x 0x05f0 0x 0x1000>,
> +   <0x 0x05f02000 0x 0x00efd000>,
> <0x 0x06e0 0x 0x0060f000>,
> <0x 0x0741 0x 0x36bf>;
>   };

As I said when talked about this, I don't think you should punch holes
in the /memory node, but rather add these regions as no-map in a
/reserved-memory node. But that's a unrelated matter.

>  
> + reboot-mode-syscon@5f01000 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0x0 0x05f01000 0x0 0x1000>;
> +
> + reboot-mode@0 {

Drop the @0

Other than that:
Acked-by: Bjorn Andersson 

> + compatible = "syscon-reboot-mode";
> + offset = <0x0>;
> +
> + mode-normal = <0x77665501>;
> + mode-bootloader = <0x77665500>;
> + mode-recovery   = <0x77665502>;
> + };
> + };
> +
>   soc {
>   spi0: spi@f7106000 {
>   status = "ok";

Regards,
Bjorn

Re: Is it ok if ModemManager process is killed AFTER network-interface is brought up and IP-Address assigned?

[Ajay Garg]

Ok Greg :)

On Tue, Aug 9, 2016 at 1:44 PM, Greg KH  wrote:
> On Tue, Aug 09, 2016 at 12:48:12PM +0530, Ajay Garg wrote:
>> Hi All.
>>
>> We are using Sierra's USB-to-WWAN driver on Ubuntu-14 for Sierra's
>> MC8090 modem, and we have a requirement wherein we need to have access
>> to the modem-serial-port (from our user-application that is).
>>
>> Right now, we see that /usr/sbin/ModemManager is always connected to
>> /dev/ttyUSB3 (which means we cannot connect to the port from our
>> application at the same time, or even if we can, received-data will be
>> at best inconsistent).
>>
>>
>> We are thinking of the following ::
>>
>> * Initially, let nmcli and ModemManager do their work, and let them
>> bring the WWAN interface up.
>>
>> * Once this happens, we permanently-down the ModemManager from our
>> application-binary, thereby freeing up /dev/ttyUSB3.
>>
>> * Thereafter, we are free to connect to /dev/ttyUSB3 from our
>> application, thereby using features like SMS-notification (+CMTI),
>> signal-strength (+CSQ), etc.
>>
>>
>>
>> Does our approach make sense?
>> We will be grateful to any help.
>
> Why not ask the modem manager team about this?  The kernel doesn't care
> what you do with the device links :)
>
> thanks,
>
> greg k-h



-- 
Regards,
Ajay

Re: Is it ok if ModemManager process is killed AFTER network-interface is brought up and IP-Address assigned?

[Ajay Garg]

Ok Greg :)

On Tue, Aug 9, 2016 at 1:44 PM, Greg KH  wrote:
> On Tue, Aug 09, 2016 at 12:48:12PM +0530, Ajay Garg wrote:
>> Hi All.
>>
>> We are using Sierra's USB-to-WWAN driver on Ubuntu-14 for Sierra's
>> MC8090 modem, and we have a requirement wherein we need to have access
>> to the modem-serial-port (from our user-application that is).
>>
>> Right now, we see that /usr/sbin/ModemManager is always connected to
>> /dev/ttyUSB3 (which means we cannot connect to the port from our
>> application at the same time, or even if we can, received-data will be
>> at best inconsistent).
>>
>>
>> We are thinking of the following ::
>>
>> * Initially, let nmcli and ModemManager do their work, and let them
>> bring the WWAN interface up.
>>
>> * Once this happens, we permanently-down the ModemManager from our
>> application-binary, thereby freeing up /dev/ttyUSB3.
>>
>> * Thereafter, we are free to connect to /dev/ttyUSB3 from our
>> application, thereby using features like SMS-notification (+CMTI),
>> signal-strength (+CSQ), etc.
>>
>>
>>
>> Does our approach make sense?
>> We will be grateful to any help.
>
> Why not ask the modem manager team about this?  The kernel doesn't care
> what you do with the device links :)
>
> thanks,
>
> greg k-h



-- 
Regards,
Ajay

Re: [PATCH] cpufreq: powernv: Fix crash in gpstate_timer_handler

[Michael Ellerman]

Viresh Kumar  writes:

> On 04-08-16, 20:59, Akshay Adiga wrote:
>> 'commit 09ca4c9b5958 ("cpufreq: powernv: Replacing pstate_id with
>> frequency table index")' changes calc_global_pstate() to use
>> cpufreq_table index instead of pstate_id.
>> 
>> But in gpstate_timer_handler() pstate_id was being passed instead
>> of cpufreq_table index, which caused the index_to_pstate() to access
>> out of bound indices, leading to this crash.
>> 
>> Adding sanity check for index and pstate, to ensure only valid pstate
>> and index values are returned.
>> 
>> Call Trace:
>> [c0078d66b130] [c011d224] __free_irq+0x234/0x360
>> (unreliable)
>> [c0078d66b1c0] [c011d44c] free_irq+0x6c/0xa0
>> [c0078d66b1f0] [c006c4f8] opal_event_shutdown+0x88/0xd0
>> [c0078d66b230] [c0067a4c] opal_shutdown+0x1c/0x90
>> [c0078d66b260] [c0063a00] pnv_shutdown+0x20/0x40
>> [c0078d66b280] [c0021538] machine_restart+0x38/0x90
>> [c78d66b310] [c0965ea0] panic+0x284/0x300
>> [c0078d66b3a0] [c001f508] die+0x388/0x450
>> [c0078d66b430] [c0045a50] bad_page_fault+0xd0/0x140
>> [c0078d66b4a0] [c0008964] handle_page_fault+0x2c/0x30
>>interrupt: 300 at gpstate_timer_handler+0x150/0x260
>> LR = gpstate_timer_handler+0x130/0x260
>> [c0078d66b7f0] [c0132b58] call_timer_fn+0x58/0x1c0
>> [c0078d66b880] [c0132e20] expire_timers+0x130/0x1d0
>> [c0078d66b8f0] [c0133068] run_timer_softirq+0x1a8/0x230
>> [c0078d66b980] [c00b535c] __do_softirq+0x18c/0x400
>> [c0078d66ba70] [c00b5828] irq_exit+0xc8/0x100
>> [c0078d66ba90] [c001e214] timer_interrupt+0xa4/0xe0
>> [c0078d66bac0] [c00027d0] decrementer_common+0x150/0x180
>>interrupt: 901 at arch_local_irq_restore+0x74/0x90
>>   0] [c0106b34] call_cpuidle+0x44/0x90
>> [c0078d66be50] [c010708c] cpu_startup_entry+0x38c/0x460
>> [c0078d66bf20] [c003d930] start_secondary+0x330/0x380
>> [c0078d66bf90] [c0008e6c] start_secondary_prolog+0x10/0x14
>> 
>> Fixes: 08d27eb ("cpufreq: powernv: Replacing pstate_id with
>> frequency table index")
>> Reported-by: Madhavan Srinivasan 
>> Signed-off-by: Akshay Adiga 
>> ---
>>  drivers/cpufreq/powernv-cpufreq.c | 21 -
>>  1 file changed, 20 insertions(+), 1 deletion(-)
>
> Acked-by: Viresh Kumar 

Who's merging this?

cheers

Re: [PATCH] cpufreq: powernv: Fix crash in gpstate_timer_handler

[Michael Ellerman]

Viresh Kumar  writes:

> On 04-08-16, 20:59, Akshay Adiga wrote:
>> 'commit 09ca4c9b5958 ("cpufreq: powernv: Replacing pstate_id with
>> frequency table index")' changes calc_global_pstate() to use
>> cpufreq_table index instead of pstate_id.
>> 
>> But in gpstate_timer_handler() pstate_id was being passed instead
>> of cpufreq_table index, which caused the index_to_pstate() to access
>> out of bound indices, leading to this crash.
>> 
>> Adding sanity check for index and pstate, to ensure only valid pstate
>> and index values are returned.
>> 
>> Call Trace:
>> [c0078d66b130] [c011d224] __free_irq+0x234/0x360
>> (unreliable)
>> [c0078d66b1c0] [c011d44c] free_irq+0x6c/0xa0
>> [c0078d66b1f0] [c006c4f8] opal_event_shutdown+0x88/0xd0
>> [c0078d66b230] [c0067a4c] opal_shutdown+0x1c/0x90
>> [c0078d66b260] [c0063a00] pnv_shutdown+0x20/0x40
>> [c0078d66b280] [c0021538] machine_restart+0x38/0x90
>> [c78d66b310] [c0965ea0] panic+0x284/0x300
>> [c0078d66b3a0] [c001f508] die+0x388/0x450
>> [c0078d66b430] [c0045a50] bad_page_fault+0xd0/0x140
>> [c0078d66b4a0] [c0008964] handle_page_fault+0x2c/0x30
>>interrupt: 300 at gpstate_timer_handler+0x150/0x260
>> LR = gpstate_timer_handler+0x130/0x260
>> [c0078d66b7f0] [c0132b58] call_timer_fn+0x58/0x1c0
>> [c0078d66b880] [c0132e20] expire_timers+0x130/0x1d0
>> [c0078d66b8f0] [c0133068] run_timer_softirq+0x1a8/0x230
>> [c0078d66b980] [c00b535c] __do_softirq+0x18c/0x400
>> [c0078d66ba70] [c00b5828] irq_exit+0xc8/0x100
>> [c0078d66ba90] [c001e214] timer_interrupt+0xa4/0xe0
>> [c0078d66bac0] [c00027d0] decrementer_common+0x150/0x180
>>interrupt: 901 at arch_local_irq_restore+0x74/0x90
>>   0] [c0106b34] call_cpuidle+0x44/0x90
>> [c0078d66be50] [c010708c] cpu_startup_entry+0x38c/0x460
>> [c0078d66bf20] [c003d930] start_secondary+0x330/0x380
>> [c0078d66bf90] [c0008e6c] start_secondary_prolog+0x10/0x14
>> 
>> Fixes: 08d27eb ("cpufreq: powernv: Replacing pstate_id with
>> frequency table index")
>> Reported-by: Madhavan Srinivasan 
>> Signed-off-by: Akshay Adiga 
>> ---
>>  drivers/cpufreq/powernv-cpufreq.c | 21 -
>>  1 file changed, 20 insertions(+), 1 deletion(-)
>
> Acked-by: Viresh Kumar 

Who's merging this?

cheers

Re: [PATCH 2/2] device-tree: nexus7: Add IMEM syscon and reboot reason support

[Bjorn Andersson]

On Mon 08 Aug 15:34 PDT 2016, John Stultz wrote:

> This patch add the IMEM syscon memory region to the DT,
> as well as addds support for the magic reboot reason
> values that are written to the address for each mode.
>

This looks good, double checked the addresses and magics. But I think
you should move the entire thing to qcom-apq8064.dtsi, as this is common
to the base platform.

And I would prefer if you updated the subject prefix...

With the move and subject update:
Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> Cc: Rob Herring 
> Cc: Andy Gross 
> Cc: Bjorn Andersson 
> Cc: Stephen Boyd 
> Cc: linux-arm-...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> Signed-off-by: John Stultz 
> ---
>  arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts 
> b/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts
> index 7b05f07..ff856c3 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts
> @@ -272,5 +272,19 @@
>   vqmmc-supply = <_s4>;
>   };
>   };
> +
> + imem@2a03f000 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0x2a03f000 0x1000>;
> +
> + reboot-mode {
> + compatible = "syscon-reboot-mode";
> + offset = <0x65c>;
> +
> + mode-normal = <0x77665501>;
> + mode-bootloader = <0x77665500>;
> + mode-recovery   = <0x77665502>;
> + };
> + };
>   };
>  };
> -- 
> 1.9.1
> 

Re: [PATCH 2/2] device-tree: nexus7: Add IMEM syscon and reboot reason support

[Bjorn Andersson]

On Mon 08 Aug 15:34 PDT 2016, John Stultz wrote:

> This patch add the IMEM syscon memory region to the DT,
> as well as addds support for the magic reboot reason
> values that are written to the address for each mode.
>

This looks good, double checked the addresses and magics. But I think
you should move the entire thing to qcom-apq8064.dtsi, as this is common
to the base platform.

And I would prefer if you updated the subject prefix...

With the move and subject update:
Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> Cc: Rob Herring 
> Cc: Andy Gross 
> Cc: Bjorn Andersson 
> Cc: Stephen Boyd 
> Cc: linux-arm-...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> Signed-off-by: John Stultz 
> ---
>  arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts 
> b/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts
> index 7b05f07..ff856c3 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-asus-nexus7-flo.dts
> @@ -272,5 +272,19 @@
>   vqmmc-supply = <_s4>;
>   };
>   };
> +
> + imem@2a03f000 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0x2a03f000 0x1000>;
> +
> + reboot-mode {
> + compatible = "syscon-reboot-mode";
> + offset = <0x65c>;
> +
> + mode-normal = <0x77665501>;
> + mode-bootloader = <0x77665500>;
> + mode-recovery   = <0x77665502>;
> + };
> + };
>   };
>  };
> -- 
> 1.9.1
> 

[PATCH v3 4/5] x86/ioapic: Fix lost IOAPIC resource after hot-removal and hotadd

[Rui Wang]

IOAPIC resource at 0xfecx gets lost from /proc/iomem after
hot-removing and then hot-adding the IOAPIC device.

After system boot, in /proc/iomem:
fec0-fecf : PNP0003:00
  fec0-fec003ff : IOAPIC 0
  fec01000-fec013ff : IOAPIC 1
  fec4-fec403ff : IOAPIC 2
  fec8-fec803ff : IOAPIC 3
  fecc-fecc03ff : IOAPIC 4

Then hot-remove IOAPIC 2 and hot-add it again:
fec0-fecf : PNP0003:00
  fec0-fec003ff : IOAPIC 0
  fec01000-fec013ff : IOAPIC 1
  fec8-fec803ff : IOAPIC 3
  fecc-fecc03ff : IOAPIC 4

The range at 0xfec4 is lost from /proc/iomem. It is because
handle_ioapic_add() requests resource from either PCI config BAR or
ACPI "_CRS", not both. But Intel platforms map the IOxAPIC registers
both at the PCI config BAR (called MBAR, dynamic), and at the ACPI
"_CRS" (called ABAR, static). The 0xfecX_YZ00 to 0xfecX_YZFF range
appears in "_CRS" of each IOAPIC device. Both ranges should be claimed
from /proc/iomem for exclusive use.

Signed-off-by: Rui Wang 
---
 drivers/acpi/ioapic.c | 36 
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
index 8ab6d42..ee20111 100644
--- a/drivers/acpi/ioapic.c
+++ b/drivers/acpi/ioapic.c
@@ -97,7 +97,7 @@ static acpi_status handle_ioapic_add(acpi_handle handle, u32 
lvl,
unsigned long long gsi_base;
struct acpi_pci_ioapic *ioapic;
struct pci_dev *dev = NULL;
-   struct resource *res = NULL;
+   struct resource *res = NULL, *pci_res = NULL, *crs_res;
char *type = NULL;
 
if (!acpi_is_ioapic(handle, ))
@@ -137,23 +137,28 @@ static acpi_status handle_ioapic_add(acpi_handle handle, 
u32 lvl,
pci_set_master(dev);
if (pci_request_region(dev, 0, type))
goto exit_disable;
-   res = >resource[0];
+   pci_res = >resource[0];
ioapic->pdev = dev;
} else {
pci_dev_put(dev);
dev = NULL;
+   }
 
-   res = >res;
-   acpi_walk_resources(handle, METHOD_NAME__CRS, setup_res, res);
-   if (res->flags == 0) {
-   acpi_handle_warn(handle, "failed to get resource\n");
-   goto exit_free;
-   } else if (request_resource(_resource, res)) {
-   acpi_handle_warn(handle, "failed to insert resource\n");
-   goto exit_free;
-   }
+   crs_res = >res;
+   acpi_walk_resources(handle, METHOD_NAME__CRS, setup_res, crs_res);
+   if (crs_res->flags == 0) {
+   acpi_handle_warn(handle, "failed to get resource\n");
+   goto exit_release;
+   } else if (request_resource(_resource, crs_res)) {
+   acpi_handle_warn(handle, "failed to insert resource\n");
+   goto exit_release;
}
 
+   /* try pci resource first, then "_CRS" resource */
+   res = pci_res;
+   if (!res || !res->flags)
+   res = crs_res;
+
if (acpi_register_ioapic(handle, res->start, (u32)gsi_base)) {
acpi_handle_warn(handle, "failed to register IOAPIC\n");
goto exit_release;
@@ -174,14 +179,13 @@ done:
 exit_release:
if (dev)
pci_release_region(dev, 0);
-   else
-   release_resource(res);
+   if (ioapic->res.flags && ioapic->res.parent)
+   release_resource(>res);
 exit_disable:
if (dev)
pci_disable_device(dev);
 exit_put:
pci_dev_put(dev);
-exit_free:
kfree(ioapic);
 exit:
mutex_unlock(_list_lock);
@@ -217,9 +221,9 @@ int acpi_ioapic_remove(struct acpi_pci_root *root)
pci_release_region(ioapic->pdev, 0);
pci_disable_device(ioapic->pdev);
pci_dev_put(ioapic->pdev);
-   } else if (ioapic->res.flags && ioapic->res.parent) {
-   release_resource(>res);
}
+   if (ioapic->res.flags && ioapic->res.parent)
+   release_resource(>res);
list_del(>list);
kfree(ioapic);
}
-- 
1.8.3.1

[PATCH v3 2/5] x86/ioapic: Support hot-removal of IOAPICs present during boot

[Rui Wang]

IOAPICs present during system boot aren't added to ioapic_list,
thus are unable to be hot-removed. Fix it by calling
acpi_ioapic_add() during root bus enumeration.

Signed-off-by: Rui Wang 
---
 drivers/acpi/pci_root.c | 10 ++
 drivers/pci/setup-bus.c |  5 -
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index b07eda1..bf601d4 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -614,6 +614,16 @@ static int acpi_pci_root_add(struct acpi_device *device,
if (hotadd) {
pcibios_resource_survey_bus(root->bus);
pci_assign_unassigned_root_bus_resources(root->bus);
+   /*
+* This is only called for the hotadd case. For the boot-time
+* case, we need to wait until after PCI initialization in
+* order to deal with IOAPICs mapped in on a PCI BAR.
+*
+* This is currently x86-specific, because acpi_ioapic_add()
+* is an empty function without CONFIG_ACPI_HOTPLUG_IOAPIC.
+* And CONFIG_ACPI_HOTPLUG_IOAPIC depends on CONFIG_X86_IO_APIC
+* (see drivers/acpi/Kconfig).
+*/
acpi_ioapic_add(root->device->handle);
}
 
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index c74059e..ec538d3 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "pci.h"
 
 unsigned int pci_flags;
@@ -1852,8 +1853,10 @@ void __init pci_assign_unassigned_resources(void)
 {
struct pci_bus *root_bus;
 
-   list_for_each_entry(root_bus, _root_buses, node)
+   list_for_each_entry(root_bus, _root_buses, node) {
pci_assign_unassigned_root_bus_resources(root_bus);
+   acpi_ioapic_add(ACPI_HANDLE(root_bus->bridge));
+   }
 }
 
 void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
-- 
1.8.3.1

[PATCH v3 1/5] x86/ioapic: Change prototype of acpi_ioapic_add()

[Rui Wang]

Change the argument of acpi_ioapic_add() to a generic ACPI handle, and
move its prototype from drivers/acpi/internal.h to include/linux/acpi.h
so that it can be called from outside the pci_root driver.

Signed-off-by: Rui Wang 
---
 drivers/acpi/internal.h | 2 --
 drivers/acpi/ioapic.c   | 6 +++---
 drivers/acpi/pci_root.c | 2 +-
 include/linux/acpi.h| 6 ++
 4 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 940218f..f26fc1d 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -40,10 +40,8 @@ int acpi_sysfs_init(void);
 void acpi_container_init(void);
 void acpi_memory_hotplug_init(void);
 #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
-int acpi_ioapic_add(struct acpi_pci_root *root);
 int acpi_ioapic_remove(struct acpi_pci_root *root);
 #else
-static inline int acpi_ioapic_add(struct acpi_pci_root *root) { return 0; }
 static inline int acpi_ioapic_remove(struct acpi_pci_root *root) { return 0; }
 #endif
 #ifdef CONFIG_ACPI_DOCK
diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
index ccdc8db..2449377 100644
--- a/drivers/acpi/ioapic.c
+++ b/drivers/acpi/ioapic.c
@@ -189,13 +189,13 @@ exit:
return AE_OK;
 }
 
-int acpi_ioapic_add(struct acpi_pci_root *root)
+int acpi_ioapic_add(acpi_handle root_handle)
 {
acpi_status status, retval = AE_OK;
 
-   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, root->device->handle,
+   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, root_handle,
 UINT_MAX, handle_ioapic_add, NULL,
-root->device->handle, (void **));
+root_handle, (void **));
 
return ACPI_SUCCESS(status) && ACPI_SUCCESS(retval) ? 0 : -ENODEV;
 }
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index d144168..b07eda1 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -614,7 +614,7 @@ static int acpi_pci_root_add(struct acpi_device *device,
if (hotadd) {
pcibios_resource_survey_bus(root->bus);
pci_assign_unassigned_root_bus_resources(root->bus);
-   acpi_ioapic_add(root);
+   acpi_ioapic_add(root->device->handle);
}
 
pci_lock_rescan_remove();
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 4d8452c..c9a596b 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -751,6 +751,12 @@ static inline int acpi_reconfig_notifier_unregister(struct 
notifier_block *nb)
 
 #endif /* !CONFIG_ACPI */
 
+#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
+int acpi_ioapic_add(acpi_handle root);
+#else
+static inline int acpi_ioapic_add(acpi_handle root) { return 0; }
+#endif
+
 #ifdef CONFIG_ACPI
 void acpi_os_set_prepare_sleep(int (*func)(u8 sleep_state,
   u32 pm1a_ctrl,  u32 pm1b_ctrl));
-- 
1.8.3.1

[PATCH v3 4/5] x86/ioapic: Fix lost IOAPIC resource after hot-removal and hotadd

[Rui Wang]

IOAPIC resource at 0xfecx gets lost from /proc/iomem after
hot-removing and then hot-adding the IOAPIC device.

After system boot, in /proc/iomem:
fec0-fecf : PNP0003:00
  fec0-fec003ff : IOAPIC 0
  fec01000-fec013ff : IOAPIC 1
  fec4-fec403ff : IOAPIC 2
  fec8-fec803ff : IOAPIC 3
  fecc-fecc03ff : IOAPIC 4

Then hot-remove IOAPIC 2 and hot-add it again:
fec0-fecf : PNP0003:00
  fec0-fec003ff : IOAPIC 0
  fec01000-fec013ff : IOAPIC 1
  fec8-fec803ff : IOAPIC 3
  fecc-fecc03ff : IOAPIC 4

The range at 0xfec4 is lost from /proc/iomem. It is because
handle_ioapic_add() requests resource from either PCI config BAR or
ACPI "_CRS", not both. But Intel platforms map the IOxAPIC registers
both at the PCI config BAR (called MBAR, dynamic), and at the ACPI
"_CRS" (called ABAR, static). The 0xfecX_YZ00 to 0xfecX_YZFF range
appears in "_CRS" of each IOAPIC device. Both ranges should be claimed
from /proc/iomem for exclusive use.

Signed-off-by: Rui Wang 
---
 drivers/acpi/ioapic.c | 36 
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
index 8ab6d42..ee20111 100644
--- a/drivers/acpi/ioapic.c
+++ b/drivers/acpi/ioapic.c
@@ -97,7 +97,7 @@ static acpi_status handle_ioapic_add(acpi_handle handle, u32 
lvl,
unsigned long long gsi_base;
struct acpi_pci_ioapic *ioapic;
struct pci_dev *dev = NULL;
-   struct resource *res = NULL;
+   struct resource *res = NULL, *pci_res = NULL, *crs_res;
char *type = NULL;
 
if (!acpi_is_ioapic(handle, ))
@@ -137,23 +137,28 @@ static acpi_status handle_ioapic_add(acpi_handle handle, 
u32 lvl,
pci_set_master(dev);
if (pci_request_region(dev, 0, type))
goto exit_disable;
-   res = >resource[0];
+   pci_res = >resource[0];
ioapic->pdev = dev;
} else {
pci_dev_put(dev);
dev = NULL;
+   }
 
-   res = >res;
-   acpi_walk_resources(handle, METHOD_NAME__CRS, setup_res, res);
-   if (res->flags == 0) {
-   acpi_handle_warn(handle, "failed to get resource\n");
-   goto exit_free;
-   } else if (request_resource(_resource, res)) {
-   acpi_handle_warn(handle, "failed to insert resource\n");
-   goto exit_free;
-   }
+   crs_res = >res;
+   acpi_walk_resources(handle, METHOD_NAME__CRS, setup_res, crs_res);
+   if (crs_res->flags == 0) {
+   acpi_handle_warn(handle, "failed to get resource\n");
+   goto exit_release;
+   } else if (request_resource(_resource, crs_res)) {
+   acpi_handle_warn(handle, "failed to insert resource\n");
+   goto exit_release;
}
 
+   /* try pci resource first, then "_CRS" resource */
+   res = pci_res;
+   if (!res || !res->flags)
+   res = crs_res;
+
if (acpi_register_ioapic(handle, res->start, (u32)gsi_base)) {
acpi_handle_warn(handle, "failed to register IOAPIC\n");
goto exit_release;
@@ -174,14 +179,13 @@ done:
 exit_release:
if (dev)
pci_release_region(dev, 0);
-   else
-   release_resource(res);
+   if (ioapic->res.flags && ioapic->res.parent)
+   release_resource(>res);
 exit_disable:
if (dev)
pci_disable_device(dev);
 exit_put:
pci_dev_put(dev);
-exit_free:
kfree(ioapic);
 exit:
mutex_unlock(_list_lock);
@@ -217,9 +221,9 @@ int acpi_ioapic_remove(struct acpi_pci_root *root)
pci_release_region(ioapic->pdev, 0);
pci_disable_device(ioapic->pdev);
pci_dev_put(ioapic->pdev);
-   } else if (ioapic->res.flags && ioapic->res.parent) {
-   release_resource(>res);
}
+   if (ioapic->res.flags && ioapic->res.parent)
+   release_resource(>res);
list_del(>list);
kfree(ioapic);
}
-- 
1.8.3.1

[PATCH v3 2/5] x86/ioapic: Support hot-removal of IOAPICs present during boot

[Rui Wang]

IOAPICs present during system boot aren't added to ioapic_list,
thus are unable to be hot-removed. Fix it by calling
acpi_ioapic_add() during root bus enumeration.

Signed-off-by: Rui Wang 
---
 drivers/acpi/pci_root.c | 10 ++
 drivers/pci/setup-bus.c |  5 -
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index b07eda1..bf601d4 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -614,6 +614,16 @@ static int acpi_pci_root_add(struct acpi_device *device,
if (hotadd) {
pcibios_resource_survey_bus(root->bus);
pci_assign_unassigned_root_bus_resources(root->bus);
+   /*
+* This is only called for the hotadd case. For the boot-time
+* case, we need to wait until after PCI initialization in
+* order to deal with IOAPICs mapped in on a PCI BAR.
+*
+* This is currently x86-specific, because acpi_ioapic_add()
+* is an empty function without CONFIG_ACPI_HOTPLUG_IOAPIC.
+* And CONFIG_ACPI_HOTPLUG_IOAPIC depends on CONFIG_X86_IO_APIC
+* (see drivers/acpi/Kconfig).
+*/
acpi_ioapic_add(root->device->handle);
}
 
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index c74059e..ec538d3 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "pci.h"
 
 unsigned int pci_flags;
@@ -1852,8 +1853,10 @@ void __init pci_assign_unassigned_resources(void)
 {
struct pci_bus *root_bus;
 
-   list_for_each_entry(root_bus, _root_buses, node)
+   list_for_each_entry(root_bus, _root_buses, node) {
pci_assign_unassigned_root_bus_resources(root_bus);
+   acpi_ioapic_add(ACPI_HANDLE(root_bus->bridge));
+   }
 }
 
 void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge)
-- 
1.8.3.1

[PATCH v3 1/5] x86/ioapic: Change prototype of acpi_ioapic_add()

[Rui Wang]

Change the argument of acpi_ioapic_add() to a generic ACPI handle, and
move its prototype from drivers/acpi/internal.h to include/linux/acpi.h
so that it can be called from outside the pci_root driver.

Signed-off-by: Rui Wang 
---
 drivers/acpi/internal.h | 2 --
 drivers/acpi/ioapic.c   | 6 +++---
 drivers/acpi/pci_root.c | 2 +-
 include/linux/acpi.h| 6 ++
 4 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 940218f..f26fc1d 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -40,10 +40,8 @@ int acpi_sysfs_init(void);
 void acpi_container_init(void);
 void acpi_memory_hotplug_init(void);
 #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
-int acpi_ioapic_add(struct acpi_pci_root *root);
 int acpi_ioapic_remove(struct acpi_pci_root *root);
 #else
-static inline int acpi_ioapic_add(struct acpi_pci_root *root) { return 0; }
 static inline int acpi_ioapic_remove(struct acpi_pci_root *root) { return 0; }
 #endif
 #ifdef CONFIG_ACPI_DOCK
diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
index ccdc8db..2449377 100644
--- a/drivers/acpi/ioapic.c
+++ b/drivers/acpi/ioapic.c
@@ -189,13 +189,13 @@ exit:
return AE_OK;
 }
 
-int acpi_ioapic_add(struct acpi_pci_root *root)
+int acpi_ioapic_add(acpi_handle root_handle)
 {
acpi_status status, retval = AE_OK;
 
-   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, root->device->handle,
+   status = acpi_walk_namespace(ACPI_TYPE_DEVICE, root_handle,
 UINT_MAX, handle_ioapic_add, NULL,
-root->device->handle, (void **));
+root_handle, (void **));
 
return ACPI_SUCCESS(status) && ACPI_SUCCESS(retval) ? 0 : -ENODEV;
 }
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index d144168..b07eda1 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -614,7 +614,7 @@ static int acpi_pci_root_add(struct acpi_device *device,
if (hotadd) {
pcibios_resource_survey_bus(root->bus);
pci_assign_unassigned_root_bus_resources(root->bus);
-   acpi_ioapic_add(root);
+   acpi_ioapic_add(root->device->handle);
}
 
pci_lock_rescan_remove();
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 4d8452c..c9a596b 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -751,6 +751,12 @@ static inline int acpi_reconfig_notifier_unregister(struct 
notifier_block *nb)
 
 #endif /* !CONFIG_ACPI */
 
+#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
+int acpi_ioapic_add(acpi_handle root);
+#else
+static inline int acpi_ioapic_add(acpi_handle root) { return 0; }
+#endif
+
 #ifdef CONFIG_ACPI
 void acpi_os_set_prepare_sleep(int (*func)(u8 sleep_state,
   u32 pm1a_ctrl,  u32 pm1b_ctrl));
-- 
1.8.3.1

[PATCH v3 0/5] Fixing a set of bugs for ioapic hotplug

[Rui Wang]

A set of patches fixing bugs found while testing IOAPIC hotplug.

Regards,
Rui

Changelog:

Changes from v2 to v3:
* Rebased on top of 4.8-rc1 per Bjorn & Rafael.
* Improved the commit message of 0003, w/ clearer explanation.

Changes from v1 to v2:
* Split the first patch into two as advised by Bjorn: "would be nicer if
the interface change and header file munging were in a separate patch so
they wouldn't obscure the meat of the change, i.e., the addition of calls
to acpi_ioapic_add()."
* Removed acpi_ioapic_add() as an exported symbol.
* Fixed some typos, and s/acpi/ACPI/, s/ioapic/IOAPIC/ throughout.
* Fixed a warning from 0-day testing.

Rui Wang (5):
  x86/ioapic: Change prototype of acpi_ioapic_add()
  x86/ioapic: Support hot-removal of IOAPICs present during boot
  x86/ioapic: Fix setup_res() failing to get resource
  x86/ioapic: Fix lost IOAPIC resource after hot-removal and hotadd
  x86/ioapic: Fix ioapic failing to request resource

 drivers/acpi/internal.h |  2 --
 drivers/acpi/ioapic.c   | 46 ++
 drivers/acpi/pci_root.c | 12 +++-
 drivers/pci/setup-bus.c |  5 -
 include/linux/acpi.h|  6 ++
 5 files changed, 47 insertions(+), 24 deletions(-)

-- 
1.8.3.1

[PATCH v3 0/5] Fixing a set of bugs for ioapic hotplug

[Rui Wang]

A set of patches fixing bugs found while testing IOAPIC hotplug.

Regards,
Rui

Changelog:

Changes from v2 to v3:
* Rebased on top of 4.8-rc1 per Bjorn & Rafael.
* Improved the commit message of 0003, w/ clearer explanation.

Changes from v1 to v2:
* Split the first patch into two as advised by Bjorn: "would be nicer if
the interface change and header file munging were in a separate patch so
they wouldn't obscure the meat of the change, i.e., the addition of calls
to acpi_ioapic_add()."
* Removed acpi_ioapic_add() as an exported symbol.
* Fixed some typos, and s/acpi/ACPI/, s/ioapic/IOAPIC/ throughout.
* Fixed a warning from 0-day testing.

Rui Wang (5):
  x86/ioapic: Change prototype of acpi_ioapic_add()
  x86/ioapic: Support hot-removal of IOAPICs present during boot
  x86/ioapic: Fix setup_res() failing to get resource
  x86/ioapic: Fix lost IOAPIC resource after hot-removal and hotadd
  x86/ioapic: Fix ioapic failing to request resource

 drivers/acpi/internal.h |  2 --
 drivers/acpi/ioapic.c   | 46 ++
 drivers/acpi/pci_root.c | 12 +++-
 drivers/pci/setup-bus.c |  5 -
 include/linux/acpi.h|  6 ++
 5 files changed, 47 insertions(+), 24 deletions(-)

-- 
1.8.3.1

[PATCH v3 3/5] x86/ioapic: Fix setup_res() failing to get resource

[Rui Wang]

acpi_dev_filter_resource_type() returns 0 on success, and 1 on failure.
A return value of zero means there's a matching resource, so we should
continue within setup_res() to get the resource.

Signed-off-by: Rui Wang 
---
 drivers/acpi/ioapic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
index 2449377..8ab6d42 100644
--- a/drivers/acpi/ioapic.c
+++ b/drivers/acpi/ioapic.c
@@ -46,7 +46,7 @@ static acpi_status setup_res(struct acpi_resource *acpi_res, 
void *data)
struct resource_win win;
 
res->flags = 0;
-   if (acpi_dev_filter_resource_type(acpi_res, IORESOURCE_MEM) == 0)
+   if (acpi_dev_filter_resource_type(acpi_res, IORESOURCE_MEM))
return AE_OK;
 
if (!acpi_dev_resource_memory(acpi_res, res)) {
-- 
1.8.3.1

[PATCH v3 5/5] x86/ioapic: Fix ioapic failing to request resource

[Rui Wang]

handle_ioapic_add() uses request_resource() to request ACPI "_CRS"
resources. This can fail with the following error message:

[  247.325693] ACPI: \_SB_.IIO1.AID1: failed to insert resource

This happens when there are multiple IOAPICs and DSDT groups their
"_CRS" resources as the children of a parent resource, as seen from
/proc/iomem:

fec0-fecf : PNP0003:00
  fec0-fec003ff : IOAPIC 0
  fec01000-fec013ff : IOAPIC 1
  fec4-fec403ff : IOAPIC 2

In this case request_resource() fails because there's a conflicting
resource which is the parent (fec-fecf). Fix it by using
insert_resource() which can request resources by taking the conflicting
resource as the parent.

Signed-off-by: Rui Wang 
---
 drivers/acpi/ioapic.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
index ee20111..6d7ce6e 100644
--- a/drivers/acpi/ioapic.c
+++ b/drivers/acpi/ioapic.c
@@ -146,10 +146,12 @@ static acpi_status handle_ioapic_add(acpi_handle handle, 
u32 lvl,
 
crs_res = >res;
acpi_walk_resources(handle, METHOD_NAME__CRS, setup_res, crs_res);
+   crs_res->name = type;
+   crs_res->flags |= IORESOURCE_BUSY;
if (crs_res->flags == 0) {
acpi_handle_warn(handle, "failed to get resource\n");
goto exit_release;
-   } else if (request_resource(_resource, crs_res)) {
+   } else if (insert_resource(_resource, crs_res)) {
acpi_handle_warn(handle, "failed to insert resource\n");
goto exit_release;
}
-- 
1.8.3.1

[PATCH v3 3/5] x86/ioapic: Fix setup_res() failing to get resource

[Rui Wang]

acpi_dev_filter_resource_type() returns 0 on success, and 1 on failure.
A return value of zero means there's a matching resource, so we should
continue within setup_res() to get the resource.

Signed-off-by: Rui Wang 
---
 drivers/acpi/ioapic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
index 2449377..8ab6d42 100644
--- a/drivers/acpi/ioapic.c
+++ b/drivers/acpi/ioapic.c
@@ -46,7 +46,7 @@ static acpi_status setup_res(struct acpi_resource *acpi_res, 
void *data)
struct resource_win win;
 
res->flags = 0;
-   if (acpi_dev_filter_resource_type(acpi_res, IORESOURCE_MEM) == 0)
+   if (acpi_dev_filter_resource_type(acpi_res, IORESOURCE_MEM))
return AE_OK;
 
if (!acpi_dev_resource_memory(acpi_res, res)) {
-- 
1.8.3.1

[PATCH v3 5/5] x86/ioapic: Fix ioapic failing to request resource

[Rui Wang]

handle_ioapic_add() uses request_resource() to request ACPI "_CRS"
resources. This can fail with the following error message:

[  247.325693] ACPI: \_SB_.IIO1.AID1: failed to insert resource

This happens when there are multiple IOAPICs and DSDT groups their
"_CRS" resources as the children of a parent resource, as seen from
/proc/iomem:

fec0-fecf : PNP0003:00
  fec0-fec003ff : IOAPIC 0
  fec01000-fec013ff : IOAPIC 1
  fec4-fec403ff : IOAPIC 2

In this case request_resource() fails because there's a conflicting
resource which is the parent (fec-fecf). Fix it by using
insert_resource() which can request resources by taking the conflicting
resource as the parent.

Signed-off-by: Rui Wang 
---
 drivers/acpi/ioapic.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/ioapic.c b/drivers/acpi/ioapic.c
index ee20111..6d7ce6e 100644
--- a/drivers/acpi/ioapic.c
+++ b/drivers/acpi/ioapic.c
@@ -146,10 +146,12 @@ static acpi_status handle_ioapic_add(acpi_handle handle, 
u32 lvl,
 
crs_res = >res;
acpi_walk_resources(handle, METHOD_NAME__CRS, setup_res, crs_res);
+   crs_res->name = type;
+   crs_res->flags |= IORESOURCE_BUSY;
if (crs_res->flags == 0) {
acpi_handle_warn(handle, "failed to get resource\n");
goto exit_release;
-   } else if (request_resource(_resource, crs_res)) {
+   } else if (insert_resource(_resource, crs_res)) {
acpi_handle_warn(handle, "failed to insert resource\n");
goto exit_release;
}
-- 
1.8.3.1

Re: [PATCH 1/2] device-tree: aqp8064.dtsi: Remove usb phy dr_mode = "host"

[Bjorn Andersson]

On Mon 08 Aug 15:34 PDT 2016, John Stultz wrote:

Changes in this file is commonly prefixed "ARM: dts: apq8064:", please
follow that. Perhaps:

ARM: dts: apq8064: Drop dr_mode property from usb phy

> Most 8064 devices have micro-usb ports for phy1, so setting
> the dr_mode to host here seems incorrect.
> 
> Leaving it unspecified should default to otg, and then
> any boards that wish to specify something else, can
> override it in their dts file.
> 
> Cc: Rob Herring 
> Cc: Andy Gross 
> Cc: Bjorn Andersson 
> Cc: Stephen Boyd 
> Cc: linux-arm-...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> Signed-off-by: John Stultz 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  arch/arm/boot/dts/qcom-apq8064.dtsi | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
> b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index 9dc83b0..7e43416 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -750,7 +750,6 @@
>   reg = <0x1250 0x400>;
>   interrupts  = ;
>   status  = "disabled";
> - dr_mode = "host";
>  
>   clocks  = < USB_HS1_XCVR_CLK>,
> < USB_HS1_H_CLK>;
> -- 
> 1.9.1
> 

Re: [PATCH 1/2] device-tree: aqp8064.dtsi: Remove usb phy dr_mode = "host"

[Bjorn Andersson]

On Mon 08 Aug 15:34 PDT 2016, John Stultz wrote:

Changes in this file is commonly prefixed "ARM: dts: apq8064:", please
follow that. Perhaps:

ARM: dts: apq8064: Drop dr_mode property from usb phy

> Most 8064 devices have micro-usb ports for phy1, so setting
> the dr_mode to host here seems incorrect.
> 
> Leaving it unspecified should default to otg, and then
> any boards that wish to specify something else, can
> override it in their dts file.
> 
> Cc: Rob Herring 
> Cc: Andy Gross 
> Cc: Bjorn Andersson 
> Cc: Stephen Boyd 
> Cc: linux-arm-...@vger.kernel.org
> Cc: devicet...@vger.kernel.org
> Signed-off-by: John Stultz 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  arch/arm/boot/dts/qcom-apq8064.dtsi | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
> b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index 9dc83b0..7e43416 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -750,7 +750,6 @@
>   reg = <0x1250 0x400>;
>   interrupts  = ;
>   status  = "disabled";
> - dr_mode = "host";
>  
>   clocks  = < USB_HS1_XCVR_CLK>,
> < USB_HS1_H_CLK>;
> -- 
> 1.9.1
> 

Re: [PATCH] cpuset: make sure new tasks conform to the current config of the cpuset

[Tejun Heo]

On Tue, Aug 09, 2016 at 11:25:01AM +0800, Zefan Li wrote:
> A new task inherits cpus_allowed and mems_allowed masks from its parent,
> but if someone changes cpuset's config by writing to cpuset.cpus/cpuset.mems
> before this new task is inserted into the cgroup's task list, the new task
> won't be updated accordingly.
> 
> Signed-off-by: Zefan Li 

Applied to cgroup/for-4.8-fixes w/ stable cc'd.

Thanks.

-- 
tejun

Re: [PATCH] cpuset: make sure new tasks conform to the current config of the cpuset

[Tejun Heo]

On Tue, Aug 09, 2016 at 11:25:01AM +0800, Zefan Li wrote:
> A new task inherits cpus_allowed and mems_allowed masks from its parent,
> but if someone changes cpuset's config by writing to cpuset.cpus/cpuset.mems
> before this new task is inserted into the cgroup's task list, the new task
> won't be updated accordingly.
> 
> Signed-off-by: Zefan Li 

Applied to cgroup/for-4.8-fixes w/ stable cc'd.

Thanks.

-- 
tejun

Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands

[Shaun Tancheff]

On Tue, Aug 9, 2016 at 3:09 AM, Damien Le Moal  wrote:
>> On Aug 9, 2016, at 15:47, Hannes Reinecke  wrote:

[trim]

>>> Since disk type == 0 for everything that isn't HM so I would prefer the
>>> sysfs 'zoned' file just report if the drive is HA or HM.
>>>
>> Okay. So let's put in the 'zoned' attribute the device type:
>> 'host-managed', 'host-aware', or 'device managed'.
>
> I hacked your patches and simply put a "0" or "1" in the sysfs zoned file.
> Any drive that has ZBC/ZAC command support gets a "1", "0" for everything
> else. This means that drive managed models are not exposed as zoned block
> devices. For HM vs HA differentiation, an application can look at the
> device type file since it is already present.
>
> We could indeed set the "zoned" file to the device type, but HM drives and
> regular drives will both have "0" in it, so no differentiation possible.
> The other choice could be the "zoned" bits defined by ZBC, but these
> do not define a value for host managed drives, and the drive managed value
> being not "0" could be confusing too. So I settled for a simple 0/1 boolean.

This seems good to me.

 2) Add ioctls for zone management:
 Report zones (get information from RB tree), reset zone (simple wrapper
 to ioctl for block discard), open zone, close zone and finish zone. That
 will allow mkfs like tools to get zone information without having to parse
 thousands of sysfs files (and can also be integrated in libzbc block 
 backend
 driver for a unified interface with the direct SG_IO path for kernels 
 without
 the ZBC code enabled).
>>>
>>> I can add finish zone ... but I really can't think of a use for it, myself.
>>>
>> Which is not the point. The standard defines this, so clearly someone
>> found it a reasonable addendum. So let's add this for completeness.

Agreed.

> Done: I hacked Shaun ioctl code and added finish zone too. The
> difference with Shaun initial code is that the ioctl are propagated down to
> the driver (__blkdev_driver_ioctl -> sd_ioctl) so that there is no need for
> BIO request definition for the zone operations. So a lot less code added.

The purpose of the BIO flags is not to enable the ioctls so much as
the other way round. Creating BIO op's is to enable issuing ZBC
commands from device mapper targets and file systems without some
heinous ioctl hacks.
Making the resulting block layer interfaces available via ioctls is just a
reasonable way to exercise the code ... or that was my intent.

> The ioctls do not mimic exactly the ZBC standard. For instance, there is no
> reporting options for report zones, nor is the "all" bit supported for open,
> close or finish zone commands. But the information provided on zones is 
> complete
> and maps to the standard definitions.

For the reporting options I have planned to reuse the stream_id in
struct bio when that is formalized. There are certainly other places in
struct bio to stuff a few extra bits ...

As far as the all bit ... this is being handled by all the zone action
commands. Just pass a sector of ~0ul and it's handled in sd.c by
sd_setup_zone_action_cmnd().

Apologies as apparently my documentation here is lacking :-(

> I also added a reset_wp ioctl for completeness, but this one simply calls
> blkdev_issue_discard internally, so it is in fact equivalent to the BLKDISCARD
> ioctl call with a range exactly aligned on a zone.

I'm confused as my patch set includes a Reset WP (BLKRESETZONE) that
creates a REQ_OP_ZONE_RESET .. same as open and close. My
expectation being that BLKDISCARD doesn't really need yet another alias.

[trim]

> Did that too. The blk_zone struct is now exactly 64B. I removed the per zone

Thanks .. being a cache line is harder to whinge about...

> spinlock and replaced it with a flag so that zones can still be locked
> independently using wait_on_bit_lock & friends (I added the functions
> blk_zone_lock, blk_zone_trylock and blk_zone_unlock to do that). This per zone
> locking comes in handy to implement the ioctls code without stalling the 
> command
> queue for read, writes and discard on different zones.
>
> I however kept the zone length in the structure. The reason for doing so is 
> that
> this allows supporting drives with non-constant zone sizes, albeit with a more
> limited interface since in such case the device chunk_sectors is not set (that
> is how a user or application can detect that the zones are not constant size).
> For these drives, the block layer may happily merge BIOs across zone 
> boundaries
> and the discard code will not split and align calls on the zones. But upper 
> layers
> (an FS or a device mapper) can still do all this by themselves if they 
> want/can
> support non-constant zone sizes.
>
> The only exception is drives like the Seagate one with only the last zone of a
> different size. This case is handled exactly as if all zones are the same size
> simply because any operation on the 

Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands

[Shaun Tancheff]

On Tue, Aug 9, 2016 at 3:09 AM, Damien Le Moal  wrote:
>> On Aug 9, 2016, at 15:47, Hannes Reinecke  wrote:

[trim]

>>> Since disk type == 0 for everything that isn't HM so I would prefer the
>>> sysfs 'zoned' file just report if the drive is HA or HM.
>>>
>> Okay. So let's put in the 'zoned' attribute the device type:
>> 'host-managed', 'host-aware', or 'device managed'.
>
> I hacked your patches and simply put a "0" or "1" in the sysfs zoned file.
> Any drive that has ZBC/ZAC command support gets a "1", "0" for everything
> else. This means that drive managed models are not exposed as zoned block
> devices. For HM vs HA differentiation, an application can look at the
> device type file since it is already present.
>
> We could indeed set the "zoned" file to the device type, but HM drives and
> regular drives will both have "0" in it, so no differentiation possible.
> The other choice could be the "zoned" bits defined by ZBC, but these
> do not define a value for host managed drives, and the drive managed value
> being not "0" could be confusing too. So I settled for a simple 0/1 boolean.

This seems good to me.

 2) Add ioctls for zone management:
 Report zones (get information from RB tree), reset zone (simple wrapper
 to ioctl for block discard), open zone, close zone and finish zone. That
 will allow mkfs like tools to get zone information without having to parse
 thousands of sysfs files (and can also be integrated in libzbc block 
 backend
 driver for a unified interface with the direct SG_IO path for kernels 
 without
 the ZBC code enabled).
>>>
>>> I can add finish zone ... but I really can't think of a use for it, myself.
>>>
>> Which is not the point. The standard defines this, so clearly someone
>> found it a reasonable addendum. So let's add this for completeness.

Agreed.

> Done: I hacked Shaun ioctl code and added finish zone too. The
> difference with Shaun initial code is that the ioctl are propagated down to
> the driver (__blkdev_driver_ioctl -> sd_ioctl) so that there is no need for
> BIO request definition for the zone operations. So a lot less code added.

The purpose of the BIO flags is not to enable the ioctls so much as
the other way round. Creating BIO op's is to enable issuing ZBC
commands from device mapper targets and file systems without some
heinous ioctl hacks.
Making the resulting block layer interfaces available via ioctls is just a
reasonable way to exercise the code ... or that was my intent.

> The ioctls do not mimic exactly the ZBC standard. For instance, there is no
> reporting options for report zones, nor is the "all" bit supported for open,
> close or finish zone commands. But the information provided on zones is 
> complete
> and maps to the standard definitions.

For the reporting options I have planned to reuse the stream_id in
struct bio when that is formalized. There are certainly other places in
struct bio to stuff a few extra bits ...

As far as the all bit ... this is being handled by all the zone action
commands. Just pass a sector of ~0ul and it's handled in sd.c by
sd_setup_zone_action_cmnd().

Apologies as apparently my documentation here is lacking :-(

> I also added a reset_wp ioctl for completeness, but this one simply calls
> blkdev_issue_discard internally, so it is in fact equivalent to the BLKDISCARD
> ioctl call with a range exactly aligned on a zone.

I'm confused as my patch set includes a Reset WP (BLKRESETZONE) that
creates a REQ_OP_ZONE_RESET .. same as open and close. My
expectation being that BLKDISCARD doesn't really need yet another alias.

[trim]

> Did that too. The blk_zone struct is now exactly 64B. I removed the per zone

Thanks .. being a cache line is harder to whinge about...

> spinlock and replaced it with a flag so that zones can still be locked
> independently using wait_on_bit_lock & friends (I added the functions
> blk_zone_lock, blk_zone_trylock and blk_zone_unlock to do that). This per zone
> locking comes in handy to implement the ioctls code without stalling the 
> command
> queue for read, writes and discard on different zones.
>
> I however kept the zone length in the structure. The reason for doing so is 
> that
> this allows supporting drives with non-constant zone sizes, albeit with a more
> limited interface since in such case the device chunk_sectors is not set (that
> is how a user or application can detect that the zones are not constant size).
> For these drives, the block layer may happily merge BIOs across zone 
> boundaries
> and the discard code will not split and align calls on the zones. But upper 
> layers
> (an FS or a device mapper) can still do all this by themselves if they 
> want/can
> support non-constant zone sizes.
>
> The only exception is drives like the Seagate one with only the last zone of a
> different size. This case is handled exactly as if all zones are the same size
> simply because any operation on the last smaller zone will naturally align 

Re: [PATCH v2 1/1] blk-mq: fix hang caused by freeze/unfreeze sequence

[Tejun Heo]

Hello,

On Mon, Aug 08, 2016 at 01:39:08PM +0200, Roman Pen wrote:
> Long time ago there was a similar fix proposed by Akinobu Mita[1],
> but it seems that time everyone decided to fix this subtle race in
> percpu-refcount and Tejun Heo[2] did an attempt (as I can see that
> patchset was not applied).

So, I probably forgot about it while waiting for confirmation of fix.
Can you please verify that the patchset fixes the issue?  I can apply
the patchset right away.

Thanks.

-- 
tejun

Re: [PATCH v2 1/1] blk-mq: fix hang caused by freeze/unfreeze sequence

[Tejun Heo]

Hello,

On Mon, Aug 08, 2016 at 01:39:08PM +0200, Roman Pen wrote:
> Long time ago there was a similar fix proposed by Akinobu Mita[1],
> but it seems that time everyone decided to fix this subtle race in
> percpu-refcount and Tejun Heo[2] did an attempt (as I can see that
> patchset was not applied).

So, I probably forgot about it while waiting for confirmation of fix.
Can you please verify that the patchset fixes the issue?  I can apply
the patchset right away.

Thanks.

-- 
tejun

Re: Potential race condition in drivers/ata/sata_mv.ko

[Tejun Heo]

Hello,

On Fri, Aug 05, 2016 at 03:43:30PM +0300, Pavel Andrianov wrote:
> In drivers/ata/sata_mv.ko function mv_set_main_irq_mask is called several
> times. Twice with a spinlock, twice from init function and once without any
> protection. The call without protection rises to several handlers from
> ata_port_operations. The structure with the ata_port_operations is included
> into a structure 'host' in mv_platform_probe and in mv_pci_init_one. At the
> end of these functions ata_host operations are activated together with
> interrupt handler. The conclusion is: interrupt handler may be executed in
> parallel with handlers from ata_port_operations, or, more formally, it may
> interrupt its execution.
> 
> In mv_set_main_irq_mask and in interrupt handler mv_interrupt the interrupt
> mask is modified, but, as I said, handlers from ata_port_operations do not
> acquire any lock. Thus, the interrupt mask may be set incorrectly if the are
> two conflicting modifications.

It depends on which operations.  Most are only called from EH context
and racing there isn't likely to cause any actual issues.  Care to
submit a patch to fix the issue?

Thanks.

-- 
tejun

Re: Potential race condition in drivers/ata/sata_mv.ko

[Tejun Heo]

Hello,

On Fri, Aug 05, 2016 at 03:43:30PM +0300, Pavel Andrianov wrote:
> In drivers/ata/sata_mv.ko function mv_set_main_irq_mask is called several
> times. Twice with a spinlock, twice from init function and once without any
> protection. The call without protection rises to several handlers from
> ata_port_operations. The structure with the ata_port_operations is included
> into a structure 'host' in mv_platform_probe and in mv_pci_init_one. At the
> end of these functions ata_host operations are activated together with
> interrupt handler. The conclusion is: interrupt handler may be executed in
> parallel with handlers from ata_port_operations, or, more formally, it may
> interrupt its execution.
> 
> In mv_set_main_irq_mask and in interrupt handler mv_interrupt the interrupt
> mask is modified, but, as I said, handlers from ata_port_operations do not
> acquire any lock. Thus, the interrupt mask may be set incorrectly if the are
> two conflicting modifications.

It depends on which operations.  Most are only called from EH context
and racing there isn't likely to cause any actual issues.  Care to
submit a patch to fix the issue?

Thanks.

-- 
tejun

Re: [PATCH v5 03/14] arm64/numa: add nid check for memory block

[Leizhen (ThunderTown)]

On 2016/8/10 10:12, Hanjun Guo wrote:
> On 2016/8/8 17:18, Zhen Lei wrote:
>> Use the same tactic to cpu and numa-distance nodes.
>>
>> Signed-off-by: Zhen Lei 
>> ---
>>  arch/arm64/mm/numa.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index c7fe3ec..2601660 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -141,6 +141,11 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
>>  {
>>  int ret;
>>
>> +if (nid >= MAX_NUMNODES) {
>> +pr_warn("NUMA: Node id %u exceeds maximum value\n", nid);
>> +return -EINVAL;
>> +}
> 
> I think this check should be added to of_numa_parse_memory_nodes(), which 
> before
> the numa_add_memblk() called, it's the same logic in 
> of_numa_parse_cpu_nodes() and
> the node id is checked before calling numa_add_memblk() in ACPI.

Yes, you are right. This check is arch independent.

> 
> Thanks
> Hanjun
> 
> 
> 
> .
> 

Re: [PATCH v5 03/14] arm64/numa: add nid check for memory block

[Leizhen (ThunderTown)]

On 2016/8/10 10:12, Hanjun Guo wrote:
> On 2016/8/8 17:18, Zhen Lei wrote:
>> Use the same tactic to cpu and numa-distance nodes.
>>
>> Signed-off-by: Zhen Lei 
>> ---
>>  arch/arm64/mm/numa.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index c7fe3ec..2601660 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -141,6 +141,11 @@ int __init numa_add_memblk(int nid, u64 start, u64 end)
>>  {
>>  int ret;
>>
>> +if (nid >= MAX_NUMNODES) {
>> +pr_warn("NUMA: Node id %u exceeds maximum value\n", nid);
>> +return -EINVAL;
>> +}
> 
> I think this check should be added to of_numa_parse_memory_nodes(), which 
> before
> the numa_add_memblk() called, it's the same logic in 
> of_numa_parse_cpu_nodes() and
> the node id is checked before calling numa_add_memblk() in ACPI.

Yes, you are right. This check is arch independent.

> 
> Thanks
> Hanjun
> 
> 
> 
> .
> 

Re: [PATCH 1/7] ima: on soft reboot, restore the measurement list

[Michael Ellerman]

Thiago Jung Bauermann  writes:

> Am Dienstag, 09 August 2016, 09:01:13 schrieb Mimi Zohar:
>> On Tue, 2016-08-09 at 20:59 +1000, Michael Ellerman wrote:
>> > Mimi Zohar  writes:
>> > > diff --git a/security/integrity/ima/ima.h
>> > > b/security/integrity/ima/ima.h
>> > > index b5728da..84e8d36 100644
>> > > --- a/security/integrity/ima/ima.h
>> > > +++ b/security/integrity/ima/ima.h
>> > > @@ -102,6 +102,13 @@ struct ima_queue_entry {
>> > > 
>> > >  };
>> > >  extern struct list_head ima_measurements;   /* list of all 
> measurements
>> > >  */
>> > > 
>> > > +/* Some details preceding the binary serialized measurement list */
>> > > +struct ima_kexec_hdr {
>> > > +unsigned short version;
>> > > +unsigned long buffer_size;
>> > > +unsigned long count;
>> > > +} __packed;
>> > > +
>> > 
>> > Am I understanding it correctly that this structure is passed between
>> > kernels?
>> Yes, the header prefixes the measurement list, which is being passed on
>> the same computer to the next kernel.  Could the architecture (eg.
>> LE/BE) change between soft re-boots?
>
> Yes. I am able to boot a BE kernel from an LE kernel with my patches. 
> Whether we want to support that or not is another question...

Yes you must support that. BE -> LE and vice versa.

You should also consider the possibility that the next kernel is not
Linux.

cheers

Re: [PATCH 1/7] ima: on soft reboot, restore the measurement list

[Michael Ellerman]

Thiago Jung Bauermann  writes:

> Am Dienstag, 09 August 2016, 09:01:13 schrieb Mimi Zohar:
>> On Tue, 2016-08-09 at 20:59 +1000, Michael Ellerman wrote:
>> > Mimi Zohar  writes:
>> > > diff --git a/security/integrity/ima/ima.h
>> > > b/security/integrity/ima/ima.h
>> > > index b5728da..84e8d36 100644
>> > > --- a/security/integrity/ima/ima.h
>> > > +++ b/security/integrity/ima/ima.h
>> > > @@ -102,6 +102,13 @@ struct ima_queue_entry {
>> > > 
>> > >  };
>> > >  extern struct list_head ima_measurements;   /* list of all 
> measurements
>> > >  */
>> > > 
>> > > +/* Some details preceding the binary serialized measurement list */
>> > > +struct ima_kexec_hdr {
>> > > +unsigned short version;
>> > > +unsigned long buffer_size;
>> > > +unsigned long count;
>> > > +} __packed;
>> > > +
>> > 
>> > Am I understanding it correctly that this structure is passed between
>> > kernels?
>> Yes, the header prefixes the measurement list, which is being passed on
>> the same computer to the next kernel.  Could the architecture (eg.
>> LE/BE) change between soft re-boots?
>
> Yes. I am able to boot a BE kernel from an LE kernel with my patches. 
> Whether we want to support that or not is another question...

Yes you must support that. BE -> LE and vice versa.

You should also consider the possibility that the next kernel is not
Linux.

cheers

Re: [PATCH] w1: fix timeout_us parameter description

[Wei Yongjun]

Hi

On 08/10/2016 06:54 AM, Evgeniy Polyakov wrote:
> Hi
>
> 08.08.2016, 16:52, "Wei Yongjun" :
>> Fix 'timeout_us' parameter description.
>>
>> Signed-off-by: Wei Yongjun 
>> ---
>>  drivers/w1/w1.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
>> index bb34362..e213c67 100644
>> --- a/drivers/w1/w1.c
>> +++ b/drivers/w1/w1.c
>> @@ -53,8 +53,8 @@ int w1_max_slave_ttl = 10;
>>  module_param_named(timeout, w1_timeout, int, 0);
>>  MODULE_PARM_DESC(timeout, "time in seconds between automatic slave 
>> searches");
>>  module_param_named(timeout_us, w1_timeout_us, int, 0);
>> -MODULE_PARM_DESC(timeout, "time in microseconds between automatic slave"
>> - " searches");
>> +MODULE_PARM_DESC(timeout_us,
>> + "time in microseconds between automatic slave searches");
> I believe there will be no harm to put it to on one line, even if it crosses 
> some obscure very-long-line rule

Maybe the bad patch description confused you, this patch the typo in the
first argument of MODULE_PARM_DESC(), use timeout_us instead of timeout.

Re: [PATCH] w1: fix timeout_us parameter description

[Wei Yongjun]

Hi

On 08/10/2016 06:54 AM, Evgeniy Polyakov wrote:
> Hi
>
> 08.08.2016, 16:52, "Wei Yongjun" :
>> Fix 'timeout_us' parameter description.
>>
>> Signed-off-by: Wei Yongjun 
>> ---
>>  drivers/w1/w1.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
>> index bb34362..e213c67 100644
>> --- a/drivers/w1/w1.c
>> +++ b/drivers/w1/w1.c
>> @@ -53,8 +53,8 @@ int w1_max_slave_ttl = 10;
>>  module_param_named(timeout, w1_timeout, int, 0);
>>  MODULE_PARM_DESC(timeout, "time in seconds between automatic slave 
>> searches");
>>  module_param_named(timeout_us, w1_timeout_us, int, 0);
>> -MODULE_PARM_DESC(timeout, "time in microseconds between automatic slave"
>> - " searches");
>> +MODULE_PARM_DESC(timeout_us,
>> + "time in microseconds between automatic slave searches");
> I believe there will be no harm to put it to on one line, even if it crosses 
> some obscure very-long-line rule

Maybe the bad patch description confused you, this patch the typo in the
first argument of MODULE_PARM_DESC(), use timeout_us instead of timeout.

Re: [PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

[Tejun Heo]

On Fri, Jul 22, 2016 at 02:41:54AM +0800, tom.t...@gmail.com wrote:
> From: Tom Yan 
> 
> scsi_done() was called repeatedly and apparently because of that,
> the kernel would call trace when we touch the Control mode page:
> 
> Call Trace:
>  [] dump_stack+0x63/0x81
>  [] __warn+0xcb/0xf0
>  [] warn_slowpath_null+0x1d/0x20
>  [] ata_eh_finish+0xe0/0xf0 [libata]
>  [] sata_pmp_error_handler+0x640/0xa50 [libata]
>  [] ahci_error_handler+0x1d/0x70 [libahci]
>  [] ata_scsi_port_error_handler+0x430/0x770 [libata]
>  [] ? ata_scsi_cmd_error_handler+0xdd/0x160 [libata]
>  [] ata_scsi_error+0xa7/0xf0 [libata]
>  [] scsi_error_handler+0xaa/0x560 [scsi_mod]
>  [] ? scsi_eh_get_sense+0x180/0x180 [scsi_mod]
>  [] kthread+0xd8/0xf0
>  [] ret_from_fork+0x1f/0x40
>  [] ? kthread_worker_fn+0x170/0x170
> ---[ end trace 8b7501047e928a17 ]---
> 
> Removed the unnecessary code and let ata_scsi_translate() do the job.
> 
> Also, since ata_mselect_control() has no ATA command to send to the
> device, ata_scsi_mode_select_xlat() should return 1 for it, so that
> ata_scsi_translate() will finish early to avoid ata_qc_issue().
> 
> Signed-off-by: Tom Yan 

Applied to libata/for-4.9.

Thanks.

-- 
tejun

Re: [PATCH resend 5/5] libata-scsi: fix MODE SELECT translation for Control mode page

[Tejun Heo]

On Fri, Jul 22, 2016 at 02:41:54AM +0800, tom.t...@gmail.com wrote:
> From: Tom Yan 
> 
> scsi_done() was called repeatedly and apparently because of that,
> the kernel would call trace when we touch the Control mode page:
> 
> Call Trace:
>  [] dump_stack+0x63/0x81
>  [] __warn+0xcb/0xf0
>  [] warn_slowpath_null+0x1d/0x20
>  [] ata_eh_finish+0xe0/0xf0 [libata]
>  [] sata_pmp_error_handler+0x640/0xa50 [libata]
>  [] ahci_error_handler+0x1d/0x70 [libahci]
>  [] ata_scsi_port_error_handler+0x430/0x770 [libata]
>  [] ? ata_scsi_cmd_error_handler+0xdd/0x160 [libata]
>  [] ata_scsi_error+0xa7/0xf0 [libata]
>  [] scsi_error_handler+0xaa/0x560 [scsi_mod]
>  [] ? scsi_eh_get_sense+0x180/0x180 [scsi_mod]
>  [] kthread+0xd8/0xf0
>  [] ret_from_fork+0x1f/0x40
>  [] ? kthread_worker_fn+0x170/0x170
> ---[ end trace 8b7501047e928a17 ]---
> 
> Removed the unnecessary code and let ata_scsi_translate() do the job.
> 
> Also, since ata_mselect_control() has no ATA command to send to the
> device, ata_scsi_mode_select_xlat() should return 1 for it, so that
> ata_scsi_translate() will finish early to avoid ata_qc_issue().
> 
> Signed-off-by: Tom Yan 

Applied to libata/for-4.9.

Thanks.

-- 
tejun

[PATCH] FUSE: add the async option for the flush/release operation

[Enke Chen]

Hi, Miklos:

This patch adds the async option for the flush/release operation in FUSE.

The async flush/release option allows a FUSE-based application to be terminated
without being blocked in the flush/release operation even in the presence of
complex external interactions. In addition, the async operation can be more
efficient when a large number of fuse-based files is involved.

---
Deadlock Example:

Process A is a multi-threaded application that interacts with Process B,
a FUSE-server.


   UNIX-domain socket
App (A)  ---  FUSE-server (B)
   |   |
   |   |
   |   |
   +---+
   open/flush/release


When the FUSE-server receives an open and flush/release operations from
Process A, it would in turn interact with Process A (e.g., coordinating
shared memory allocation and de-allocation) using the connection-oriented
UNIX-domain socket.

A deadlock occurs when Process A is terminating:

  1) As part of process termination (i.e., do_exit() in the kernel), it
 would send "flush/release" to Process B, and wait for its reply due
 to the synchronous nature of the operation.

  2) When Process B receives the "flush/release" request, it would in turn
 send a message to Process A (over the UNIX-domain channel) and wait
 for its reply.

  3) As Process A is terminating, it may not be able to reply to Process B,
 resulting in a deadlock.

   The async flush/release option offers a simple and robust solution to the
   deadlock issue.

   With the async flush/release operation, all the files and sockets in Process
   A can be closed without being blocked, which in turn would un-block the
   operation in Process B using the UNIX-domain socket.
---

Signed-off-by: Enke Chen 

Version: 4.7.0_next_20160805

 fs/fuse/file.c|   39 +++
 fs/fuse/fuse_i.h  |4 
 fs/fuse/inode.c   |4 +++-
 include/uapi/linux/fuse.h |7 ++-
 4 files changed, 40 insertions(+), 14 deletions(-)

diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index f394aff..7dd144f 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -273,7 +273,8 @@ void fuse_release_common(struct file *file, int opcode)
 * synchronous RELEASE is allowed (and desirable) in this case
 * because the server can be trusted not to screw up.
 */
-   fuse_file_put(ff, ff->fc->destroy_req != NULL);
+   fuse_file_put(ff, (ff->fc->destroy_req != NULL) &&
+ !ff->fc->async_flush);
 }
 
 static int fuse_open(struct inode *inode, struct file *file)
@@ -394,13 +395,19 @@ static void fuse_sync_writes(struct inode *inode)
fuse_release_nowrite(inode);
 }
 
+static void fuse_flush_end(struct fuse_conn *fc, struct fuse_req *req)
+{
+   if (req->out.h.error == -ENOSYS)
+   fc->no_flush = 1;
+}
+
 static int fuse_flush(struct file *file, fl_owner_t id)
 {
struct inode *inode = file_inode(file);
struct fuse_conn *fc = get_fuse_conn(inode);
struct fuse_file *ff = file->private_data;
struct fuse_req *req;
-   struct fuse_flush_in inarg;
+   struct fuse_flush_in *inarg;
int err;
 
if (is_bad_inode(inode))
@@ -423,20 +430,28 @@ static int fuse_flush(struct file *file, fl_owner_t id)
 
req = fuse_get_req_nofail_nopages(fc, file);
memset(, 0, sizeof(inarg));
-   inarg.fh = ff->fh;
-   inarg.lock_owner = fuse_lock_owner_id(fc, id);
+   inarg = >misc.flush_in;
+   inarg->fh = ff->fh;
+   inarg->lock_owner = fuse_lock_owner_id(fc, id);
req->in.h.opcode = FUSE_FLUSH;
req->in.h.nodeid = get_node_id(inode);
req->in.numargs = 1;
-   req->in.args[0].size = sizeof(inarg);
-   req->in.args[0].value = 
-   __set_bit(FR_FORCE, >flags);
-   fuse_request_send(fc, req);
-   err = req->out.h.error;
-   fuse_put_request(fc, req);
-   if (err == -ENOSYS) {
-   fc->no_flush = 1;
+   req->in.args[0].size = sizeof(struct fuse_flush_in);
+   req->in.args[0].value = inarg;
+   if (fc->async_flush) {
+   req->end = fuse_flush_end;
+   __set_bit(FR_BACKGROUND, >flags);
+   fuse_request_send_background(fc, req);
err = 0;
+   } else {
+   __set_bit(FR_FORCE, >flags);
+   fuse_request_send(fc, req);
+   err = req->out.h.error;
+   fuse_put_request(fc, req);
+   if (err == -ENOSYS) {
+   fc->no_flush = 1;
+   err = 0;
+   }
}
return err;
 }
diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
index d98d8cc..f212cdd 100644
--- a/fs/fuse/fuse_i.h
+++ 

[PATCH] FUSE: add the async option for the flush/release operation

[Enke Chen]

Hi, Miklos:

This patch adds the async option for the flush/release operation in FUSE.

The async flush/release option allows a FUSE-based application to be terminated
without being blocked in the flush/release operation even in the presence of
complex external interactions. In addition, the async operation can be more
efficient when a large number of fuse-based files is involved.

---
Deadlock Example:

Process A is a multi-threaded application that interacts with Process B,
a FUSE-server.


   UNIX-domain socket
App (A)  ---  FUSE-server (B)
   |   |
   |   |
   |   |
   +---+
   open/flush/release


When the FUSE-server receives an open and flush/release operations from
Process A, it would in turn interact with Process A (e.g., coordinating
shared memory allocation and de-allocation) using the connection-oriented
UNIX-domain socket.

A deadlock occurs when Process A is terminating:

  1) As part of process termination (i.e., do_exit() in the kernel), it
 would send "flush/release" to Process B, and wait for its reply due
 to the synchronous nature of the operation.

  2) When Process B receives the "flush/release" request, it would in turn
 send a message to Process A (over the UNIX-domain channel) and wait
 for its reply.

  3) As Process A is terminating, it may not be able to reply to Process B,
 resulting in a deadlock.

   The async flush/release option offers a simple and robust solution to the
   deadlock issue.

   With the async flush/release operation, all the files and sockets in Process
   A can be closed without being blocked, which in turn would un-block the
   operation in Process B using the UNIX-domain socket.
---

Signed-off-by: Enke Chen 

Version: 4.7.0_next_20160805

 fs/fuse/file.c|   39 +++
 fs/fuse/fuse_i.h  |4 
 fs/fuse/inode.c   |4 +++-
 include/uapi/linux/fuse.h |7 ++-
 4 files changed, 40 insertions(+), 14 deletions(-)

diff --git a/fs/fuse/file.c b/fs/fuse/file.c
index f394aff..7dd144f 100644
--- a/fs/fuse/file.c
+++ b/fs/fuse/file.c
@@ -273,7 +273,8 @@ void fuse_release_common(struct file *file, int opcode)
 * synchronous RELEASE is allowed (and desirable) in this case
 * because the server can be trusted not to screw up.
 */
-   fuse_file_put(ff, ff->fc->destroy_req != NULL);
+   fuse_file_put(ff, (ff->fc->destroy_req != NULL) &&
+ !ff->fc->async_flush);
 }
 
 static int fuse_open(struct inode *inode, struct file *file)
@@ -394,13 +395,19 @@ static void fuse_sync_writes(struct inode *inode)
fuse_release_nowrite(inode);
 }
 
+static void fuse_flush_end(struct fuse_conn *fc, struct fuse_req *req)
+{
+   if (req->out.h.error == -ENOSYS)
+   fc->no_flush = 1;
+}
+
 static int fuse_flush(struct file *file, fl_owner_t id)
 {
struct inode *inode = file_inode(file);
struct fuse_conn *fc = get_fuse_conn(inode);
struct fuse_file *ff = file->private_data;
struct fuse_req *req;
-   struct fuse_flush_in inarg;
+   struct fuse_flush_in *inarg;
int err;
 
if (is_bad_inode(inode))
@@ -423,20 +430,28 @@ static int fuse_flush(struct file *file, fl_owner_t id)
 
req = fuse_get_req_nofail_nopages(fc, file);
memset(, 0, sizeof(inarg));
-   inarg.fh = ff->fh;
-   inarg.lock_owner = fuse_lock_owner_id(fc, id);
+   inarg = >misc.flush_in;
+   inarg->fh = ff->fh;
+   inarg->lock_owner = fuse_lock_owner_id(fc, id);
req->in.h.opcode = FUSE_FLUSH;
req->in.h.nodeid = get_node_id(inode);
req->in.numargs = 1;
-   req->in.args[0].size = sizeof(inarg);
-   req->in.args[0].value = 
-   __set_bit(FR_FORCE, >flags);
-   fuse_request_send(fc, req);
-   err = req->out.h.error;
-   fuse_put_request(fc, req);
-   if (err == -ENOSYS) {
-   fc->no_flush = 1;
+   req->in.args[0].size = sizeof(struct fuse_flush_in);
+   req->in.args[0].value = inarg;
+   if (fc->async_flush) {
+   req->end = fuse_flush_end;
+   __set_bit(FR_BACKGROUND, >flags);
+   fuse_request_send_background(fc, req);
err = 0;
+   } else {
+   __set_bit(FR_FORCE, >flags);
+   fuse_request_send(fc, req);
+   err = req->out.h.error;
+   fuse_put_request(fc, req);
+   if (err == -ENOSYS) {
+   fc->no_flush = 1;
+   err = 0;
+   }
}
return err;
 }
diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h
index d98d8cc..f212cdd 100644
--- a/fs/fuse/fuse_i.h
+++ b/fs/fuse/fuse_i.h
@@ -350,6 

Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands

[Shaun Tancheff]

On Tue, Aug 9, 2016 at 1:47 AM, Hannes Reinecke  wrote:
> On 08/05/2016 10:35 PM, Shaun Tancheff wrote:
>> On Tue, Aug 2, 2016 at 8:29 PM, Damien Le Moal  
>> wrote:
 On Aug 2, 2016, at 23:35, Hannes Reinecke  wrote:
 On 08/01/2016 07:07 PM, Shaun Tancheff wrote:
> On Mon, Aug 1, 2016 at 4:41 AM, Christoph Hellwig  wrote:

[trim]
>> Also the zone report is 'slow' in that there is an overhead for the
>> report itself but
>> the number of zones per query can be quite large so 4 or 5 I/Os that
>> run into the
>> hundreds if milliseconds to cache the entire drive isn't really unworkable 
>> for
>> something that is used infrequently.
>>
> No, surely not.
> But one of the _big_ advantages for the RB tree is blkdev_discard().
> Without the RB tree any mkfs program will issue a 'discard' for every
> sector. We will be able to coalesce those into one discard per zone, but
> we still need to issue one for _every_ zone.
> Which is (as indicated) really slow, and easily takes several minutes.
> With the RB tree we can short-circuit discards to empty zones, and speed
> up processing time dramatically.
> Sure we could be moving the logic into mkfs and friends, but that would
> require us to change the programs and agree on a library (libzbc?) which
> should be handling that.

Adding an additional library dependency seems overkill for a program
that is already doing ioctls and raw block I/O ... but I would leave that
up to each file system. As it sits issuing the ioctl and walking the array
of data returned [see blkreport.c] is already quite trivial.

I believe the goal here is for F2FS, and perhaps NILFS? to "just
work" with the DISCARD to Reset WP and zone cache in place.

Still quite skeptical about other common file systems
"just working" without their respective mkfs et. al. being
zone aware and handling the topology of the media at mkfs time.
Perhaps there is something I am unaware of?

[trim]

>> I can add finish zone ... but I really can't think of a use for it, myself.
>>
> Which is not the point. The standard defines this, so clearly someone
> found it a reasonable addendum. So let's add this for completeness.

Agreed and queued for the next version.

Regards,
Shaun

Re: [PATCH v6 0/2] Block layer support ZAC/ZBC commands

[Shaun Tancheff]

On Tue, Aug 9, 2016 at 1:47 AM, Hannes Reinecke  wrote:
> On 08/05/2016 10:35 PM, Shaun Tancheff wrote:
>> On Tue, Aug 2, 2016 at 8:29 PM, Damien Le Moal  
>> wrote:
 On Aug 2, 2016, at 23:35, Hannes Reinecke  wrote:
 On 08/01/2016 07:07 PM, Shaun Tancheff wrote:
> On Mon, Aug 1, 2016 at 4:41 AM, Christoph Hellwig  wrote:

[trim]
>> Also the zone report is 'slow' in that there is an overhead for the
>> report itself but
>> the number of zones per query can be quite large so 4 or 5 I/Os that
>> run into the
>> hundreds if milliseconds to cache the entire drive isn't really unworkable 
>> for
>> something that is used infrequently.
>>
> No, surely not.
> But one of the _big_ advantages for the RB tree is blkdev_discard().
> Without the RB tree any mkfs program will issue a 'discard' for every
> sector. We will be able to coalesce those into one discard per zone, but
> we still need to issue one for _every_ zone.
> Which is (as indicated) really slow, and easily takes several minutes.
> With the RB tree we can short-circuit discards to empty zones, and speed
> up processing time dramatically.
> Sure we could be moving the logic into mkfs and friends, but that would
> require us to change the programs and agree on a library (libzbc?) which
> should be handling that.

Adding an additional library dependency seems overkill for a program
that is already doing ioctls and raw block I/O ... but I would leave that
up to each file system. As it sits issuing the ioctl and walking the array
of data returned [see blkreport.c] is already quite trivial.

I believe the goal here is for F2FS, and perhaps NILFS? to "just
work" with the DISCARD to Reset WP and zone cache in place.

Still quite skeptical about other common file systems
"just working" without their respective mkfs et. al. being
zone aware and handling the topology of the media at mkfs time.
Perhaps there is something I am unaware of?

[trim]

>> I can add finish zone ... but I really can't think of a use for it, myself.
>>
> Which is not the point. The standard defines this, so clearly someone
> found it a reasonable addendum. So let's add this for completeness.

Agreed and queued for the next version.

Regards,
Shaun

[PATCH v5 8/8] drm/rockchip: Add dmc notifier in vop driver

[Lin Huang]

when in ddr frequency scaling process, vop can not do
enable or disable operation, since dcf will base on vop vblank
time to do frequency scaling and need to get vop irq if there
have vop enabled. So need register to devfreq notifier, and we can
get the dmc status. Also, when there have two vop enabled, we need
to disable dmc, since dcf only base on one vop vblank time, so the
other panel will flicker when do ddr frequency scaling.

Signed-off-by: Lin Huang 
---
Changes in v5:
- improve some nits

Changes in v4:
- register notifier to devfreq_register_notifier
- use DEVFREQ_PRECHANGE and DEVFREQ_POSTCHANGE to get dmc status
- when two vop enable, disable dmc
- when two vop back to one vop, enable dmc

Changes in v3:
- when do vop eanble/disable, dmc will wait until it finish

Changes in v2:
- None

Changes in v1:
- use wait_event instead usleep

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 128 +++-
 1 file changed, 125 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 31744fe..7ce3890 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -12,6 +12,8 @@
  * GNU General Public License for more details.
  */
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -118,6 +120,13 @@ struct vop {
 
const struct vop_data *data;
 
+   struct devfreq *devfreq;
+   struct devfreq_event_dev *devfreq_event_dev;
+   struct notifier_block dmc_nb;
+   int dmc_in_process;
+   int vop_switch_status;
+   wait_queue_head_t wait_dmc_queue;
+   wait_queue_head_t wait_vop_switch_queue;
uint32_t *regsbak;
void __iomem *regs;
 
@@ -428,21 +437,59 @@ static void vop_dsp_hold_valid_irq_disable(struct vop 
*vop)
spin_unlock_irqrestore(>irq_lock, flags);
 }
 
+static int dmc_notify(struct notifier_block *nb, unsigned long event,
+ void *data)
+{
+   struct vop *vop = container_of(nb, struct vop, dmc_nb);
+
+   if (event == DEVFREQ_PRECHANGE) {
+   /*
+* check if vop in enable or disable process,
+* if yes, wait until it finishes, use 200ms as
+* timeout.
+*/
+   if (!wait_event_timeout(vop->wait_vop_switch_queue,
+   !vop->vop_switch_status, HZ / 5))
+   dev_warn(vop->dev,
+"Timeout waiting for vop swtich status\n");
+   vop->dmc_in_process = 1;
+   } else if (event == DEVFREQ_POSTCHANGE) {
+   vop->dmc_in_process = 0;
+   wake_up(>wait_dmc_queue);
+   }
+
+   return NOTIFY_OK;
+}
+
 static void vop_enable(struct drm_crtc *crtc)
 {
struct vop *vop = to_vop(crtc);
+   int num_enabled_crtc = 0;
int ret;
 
+   if (vop->is_enabled)
+   return;
+
+   /*
+* if in dmc scaling frequency process, wait until it finishes
+* use 100ms as timeout time.
+*/
+   if (!wait_event_timeout(vop->wait_dmc_queue,
+   !vop->dmc_in_process, HZ / 5))
+   dev_warn(vop->dev,
+"Timeout waiting for dmc when vop enable\n");
+
+   vop->vop_switch_status = 1;
ret = pm_runtime_get_sync(vop->dev);
if (ret < 0) {
dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
-   return;
+   goto err;
}
 
ret = clk_enable(vop->hclk);
if (ret < 0) {
dev_err(vop->dev, "failed to enable hclk - %d\n", ret);
-   return;
+   goto err;
}
 
ret = clk_enable(vop->dclk);
@@ -456,7 +503,6 @@ static void vop_enable(struct drm_crtc *crtc)
dev_err(vop->dev, "failed to enable aclk - %d\n", ret);
goto err_disable_dclk;
}
-
/*
 * Slave iommu shares power, irq and clock with vop.  It was associated
 * automatically with this master device via common driver code.
@@ -485,6 +531,21 @@ static void vop_enable(struct drm_crtc *crtc)
 
drm_crtc_vblank_on(crtc);
 
+   vop->vop_switch_status = 0;
+   wake_up(>wait_vop_switch_queue);
+
+   /* check how many vop we use now */
+   drm_for_each_crtc(crtc, vop->drm_dev) {
+   if (crtc->state->enable)
+   num_enabled_crtc++;
+   }
+
+   /* if enable two vop, need to disable dmc */
+   if ((num_enabled_crtc > 1) && vop->devfreq) {
+   if (vop->devfreq_event_dev)
+   devfreq_event_disable_edev(vop->devfreq_event_dev);
+   devfreq_suspend_device(vop->devfreq);
+   }
return;
 
 err_disable_aclk:
@@ -493,16 +554,32 @@ err_disable_dclk:
clk_disable(vop->dclk);
 err_disable_hclk:

[PATCH v5 8/8] drm/rockchip: Add dmc notifier in vop driver

[Lin Huang]

when in ddr frequency scaling process, vop can not do
enable or disable operation, since dcf will base on vop vblank
time to do frequency scaling and need to get vop irq if there
have vop enabled. So need register to devfreq notifier, and we can
get the dmc status. Also, when there have two vop enabled, we need
to disable dmc, since dcf only base on one vop vblank time, so the
other panel will flicker when do ddr frequency scaling.

Signed-off-by: Lin Huang 
---
Changes in v5:
- improve some nits

Changes in v4:
- register notifier to devfreq_register_notifier
- use DEVFREQ_PRECHANGE and DEVFREQ_POSTCHANGE to get dmc status
- when two vop enable, disable dmc
- when two vop back to one vop, enable dmc

Changes in v3:
- when do vop eanble/disable, dmc will wait until it finish

Changes in v2:
- None

Changes in v1:
- use wait_event instead usleep

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 128 +++-
 1 file changed, 125 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 31744fe..7ce3890 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -12,6 +12,8 @@
  * GNU General Public License for more details.
  */
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -118,6 +120,13 @@ struct vop {
 
const struct vop_data *data;
 
+   struct devfreq *devfreq;
+   struct devfreq_event_dev *devfreq_event_dev;
+   struct notifier_block dmc_nb;
+   int dmc_in_process;
+   int vop_switch_status;
+   wait_queue_head_t wait_dmc_queue;
+   wait_queue_head_t wait_vop_switch_queue;
uint32_t *regsbak;
void __iomem *regs;
 
@@ -428,21 +437,59 @@ static void vop_dsp_hold_valid_irq_disable(struct vop 
*vop)
spin_unlock_irqrestore(>irq_lock, flags);
 }
 
+static int dmc_notify(struct notifier_block *nb, unsigned long event,
+ void *data)
+{
+   struct vop *vop = container_of(nb, struct vop, dmc_nb);
+
+   if (event == DEVFREQ_PRECHANGE) {
+   /*
+* check if vop in enable or disable process,
+* if yes, wait until it finishes, use 200ms as
+* timeout.
+*/
+   if (!wait_event_timeout(vop->wait_vop_switch_queue,
+   !vop->vop_switch_status, HZ / 5))
+   dev_warn(vop->dev,
+"Timeout waiting for vop swtich status\n");
+   vop->dmc_in_process = 1;
+   } else if (event == DEVFREQ_POSTCHANGE) {
+   vop->dmc_in_process = 0;
+   wake_up(>wait_dmc_queue);
+   }
+
+   return NOTIFY_OK;
+}
+
 static void vop_enable(struct drm_crtc *crtc)
 {
struct vop *vop = to_vop(crtc);
+   int num_enabled_crtc = 0;
int ret;
 
+   if (vop->is_enabled)
+   return;
+
+   /*
+* if in dmc scaling frequency process, wait until it finishes
+* use 100ms as timeout time.
+*/
+   if (!wait_event_timeout(vop->wait_dmc_queue,
+   !vop->dmc_in_process, HZ / 5))
+   dev_warn(vop->dev,
+"Timeout waiting for dmc when vop enable\n");
+
+   vop->vop_switch_status = 1;
ret = pm_runtime_get_sync(vop->dev);
if (ret < 0) {
dev_err(vop->dev, "failed to get pm runtime: %d\n", ret);
-   return;
+   goto err;
}
 
ret = clk_enable(vop->hclk);
if (ret < 0) {
dev_err(vop->dev, "failed to enable hclk - %d\n", ret);
-   return;
+   goto err;
}
 
ret = clk_enable(vop->dclk);
@@ -456,7 +503,6 @@ static void vop_enable(struct drm_crtc *crtc)
dev_err(vop->dev, "failed to enable aclk - %d\n", ret);
goto err_disable_dclk;
}
-
/*
 * Slave iommu shares power, irq and clock with vop.  It was associated
 * automatically with this master device via common driver code.
@@ -485,6 +531,21 @@ static void vop_enable(struct drm_crtc *crtc)
 
drm_crtc_vblank_on(crtc);
 
+   vop->vop_switch_status = 0;
+   wake_up(>wait_vop_switch_queue);
+
+   /* check how many vop we use now */
+   drm_for_each_crtc(crtc, vop->drm_dev) {
+   if (crtc->state->enable)
+   num_enabled_crtc++;
+   }
+
+   /* if enable two vop, need to disable dmc */
+   if ((num_enabled_crtc > 1) && vop->devfreq) {
+   if (vop->devfreq_event_dev)
+   devfreq_event_disable_edev(vop->devfreq_event_dev);
+   devfreq_suspend_device(vop->devfreq);
+   }
return;
 
 err_disable_aclk:
@@ -493,16 +554,32 @@ err_disable_dclk:
clk_disable(vop->dclk);
 err_disable_hclk:
clk_disable(vop->hclk);
+err:
+ 

[PATCH v5 0/8] rk3399 support ddr frequency scaling

[Lin Huang]

rk3399 platform have dfi controller can monitor ddr load,
and dcf controller to handle ddr register so we can get the
right ddr frequency and make ddr controller happy work(which
will implement in bl31). So we do ddr frequency scaling with
following flow:

 kernelbl31

monitor ddr load
|
|
get_target_rate
|
|   pass rate to bl31
clk_set_rate(ddr) ->run dcf flow
|   |
|   |
wait dcf interrupt<---trigger dcf interrupt
|
|
  return

Lin Huang (8):
  clk: rockchip: add new clock-type for the ddrclk
  clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc
  clk: rockchip: rk3399: add ddrc clock support
  Documentation: bindings: add dt documentation for dfi controller
  PM / devfreq: event: support rockchip dfi controller
  Documentation: bindings: add dt documentation for rk3399 dmc
  PM / devfreq: rockchip: add devfreq driver for rk3399 dmc
  drm/rockchip: Add dmc notifier in vop driver

 .../bindings/devfreq/event/rockchip-dfi.txt|  20 +
 .../devicetree/bindings/devfreq/rk3399_dmc.txt |  35 ++
 drivers/clk/rockchip/Makefile  |   1 +
 drivers/clk/rockchip/clk-ddr.c | 152 ++
 drivers/clk/rockchip/clk-rk3399.c  |  19 +
 drivers/clk/rockchip/clk.c |   9 +
 drivers/clk/rockchip/clk.h |  33 ++
 drivers/devfreq/Kconfig|   9 +
 drivers/devfreq/Makefile   |   1 +
 drivers/devfreq/event/Kconfig  |   7 +
 drivers/devfreq/event/Makefile |   1 +
 drivers/devfreq/event/rockchip-dfi.c   | 253 ++
 drivers/devfreq/rk3399_dmc.c   | 512 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 128 +-
 include/dt-bindings/clock/rk3399-cru.h |   1 +
 include/soc/rockchip/rockchip_sip.h|  27 ++
 16 files changed, 1205 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
 create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
 create mode 100644 drivers/clk/rockchip/clk-ddr.c
 create mode 100644 drivers/devfreq/event/rockchip-dfi.c
 create mode 100644 drivers/devfreq/rk3399_dmc.c
 create mode 100644 include/soc/rockchip/rockchip_sip.h

-- 
1.9.1

[PATCH v5 6/8] Documentation: bindings: add dt documentation for rk3399 dmc

[Lin Huang]

This patch adds the documentation for rockchip rk3399 dmc driver.

Signed-off-by: Lin Huang 
---
Changes in v5:
-None

Changes in v4:
-None

Changes in v3:
-None

Changes in v2:
-None 

Changes in v1:
-None

 .../devicetree/bindings/devfreq/rk3399_dmc.txt | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt

diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt 
b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
new file mode 100644
index 000..90e9581
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
@@ -0,0 +1,35 @@
+* Rockchip rk3399 dmc device
+
+Required properties:
+- compatible: Must be "rockchip,rk3399-dmc".
+- devfreq-events: Node to get ddr loading, Refer to
+ Documentation/devicetree/bindings/devfreq/rockchip-dif.txt
+- interrupts: The interrupt number to the cpu. The interrupt specifier format
+ depends on the interrupt controller. 
+- clocks: Phandles for clock specified in "clock-names" property
+- clock-names : The name of clock used by the DFI, must be "pclk_ddr_mon";
+- operating-points-v2: Refer to Documentation/devicetree/bindings/power/opp.txt
+  for details.
+- center-supply: Dmc supply node.
+- status: Marks the node enabled/disabled.
+
+Optional properties:
+- ddr_timing: ddr timing need to pass to arm trust firmware
+- upthreshold: the upthreshold to simpleondeamnd policy
+- downdifferential: The downdifferential to simpleondeamnd policy
+
+Example:
+   dmc: dmc {
+   compatible = "rockchip,rk3399-dmc";
+   devfreq-events = <>;
+   interrupts = ;
+   clocks = < SCLK_DDRCLK>;
+   clock-names = "dmc_clk";
+   ddr_timing = <_timing>;
+   operating-points-v2 = <_opp_table>;
+   center-supply = <_centerlogic>;
+   upthreshold = <15>;
+   downdifferential = <10>;
+   status = "disabled";
+   };
+
-- 
1.9.1

[PATCH v5 6/8] Documentation: bindings: add dt documentation for rk3399 dmc

[Lin Huang]

This patch adds the documentation for rockchip rk3399 dmc driver.

Signed-off-by: Lin Huang 
---
Changes in v5:
-None

Changes in v4:
-None

Changes in v3:
-None

Changes in v2:
-None 

Changes in v1:
-None

 .../devicetree/bindings/devfreq/rk3399_dmc.txt | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt

diff --git a/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt 
b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
new file mode 100644
index 000..90e9581
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
@@ -0,0 +1,35 @@
+* Rockchip rk3399 dmc device
+
+Required properties:
+- compatible: Must be "rockchip,rk3399-dmc".
+- devfreq-events: Node to get ddr loading, Refer to
+ Documentation/devicetree/bindings/devfreq/rockchip-dif.txt
+- interrupts: The interrupt number to the cpu. The interrupt specifier format
+ depends on the interrupt controller. 
+- clocks: Phandles for clock specified in "clock-names" property
+- clock-names : The name of clock used by the DFI, must be "pclk_ddr_mon";
+- operating-points-v2: Refer to Documentation/devicetree/bindings/power/opp.txt
+  for details.
+- center-supply: Dmc supply node.
+- status: Marks the node enabled/disabled.
+
+Optional properties:
+- ddr_timing: ddr timing need to pass to arm trust firmware
+- upthreshold: the upthreshold to simpleondeamnd policy
+- downdifferential: The downdifferential to simpleondeamnd policy
+
+Example:
+   dmc: dmc {
+   compatible = "rockchip,rk3399-dmc";
+   devfreq-events = <>;
+   interrupts = ;
+   clocks = < SCLK_DDRCLK>;
+   clock-names = "dmc_clk";
+   ddr_timing = <_timing>;
+   operating-points-v2 = <_opp_table>;
+   center-supply = <_centerlogic>;
+   upthreshold = <15>;
+   downdifferential = <10>;
+   status = "disabled";
+   };
+
-- 
1.9.1

[PATCH v5 0/8] rk3399 support ddr frequency scaling

[Lin Huang]

rk3399 platform have dfi controller can monitor ddr load,
and dcf controller to handle ddr register so we can get the
right ddr frequency and make ddr controller happy work(which
will implement in bl31). So we do ddr frequency scaling with
following flow:

 kernelbl31

monitor ddr load
|
|
get_target_rate
|
|   pass rate to bl31
clk_set_rate(ddr) ->run dcf flow
|   |
|   |
wait dcf interrupt<---trigger dcf interrupt
|
|
  return

Lin Huang (8):
  clk: rockchip: add new clock-type for the ddrclk
  clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc
  clk: rockchip: rk3399: add ddrc clock support
  Documentation: bindings: add dt documentation for dfi controller
  PM / devfreq: event: support rockchip dfi controller
  Documentation: bindings: add dt documentation for rk3399 dmc
  PM / devfreq: rockchip: add devfreq driver for rk3399 dmc
  drm/rockchip: Add dmc notifier in vop driver

 .../bindings/devfreq/event/rockchip-dfi.txt|  20 +
 .../devicetree/bindings/devfreq/rk3399_dmc.txt |  35 ++
 drivers/clk/rockchip/Makefile  |   1 +
 drivers/clk/rockchip/clk-ddr.c | 152 ++
 drivers/clk/rockchip/clk-rk3399.c  |  19 +
 drivers/clk/rockchip/clk.c |   9 +
 drivers/clk/rockchip/clk.h |  33 ++
 drivers/devfreq/Kconfig|   9 +
 drivers/devfreq/Makefile   |   1 +
 drivers/devfreq/event/Kconfig  |   7 +
 drivers/devfreq/event/Makefile |   1 +
 drivers/devfreq/event/rockchip-dfi.c   | 253 ++
 drivers/devfreq/rk3399_dmc.c   | 512 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 128 +-
 include/dt-bindings/clock/rk3399-cru.h |   1 +
 include/soc/rockchip/rockchip_sip.h|  27 ++
 16 files changed, 1205 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
 create mode 100644 Documentation/devicetree/bindings/devfreq/rk3399_dmc.txt
 create mode 100644 drivers/clk/rockchip/clk-ddr.c
 create mode 100644 drivers/devfreq/event/rockchip-dfi.c
 create mode 100644 drivers/devfreq/rk3399_dmc.c
 create mode 100644 include/soc/rockchip/rockchip_sip.h

-- 
1.9.1

[PATCH v5 1/8] clk: rockchip: add new clock-type for the ddrclk

[Lin Huang]

On new rockchip platform(rk3399 etc), there have dcf controller to
do ddr frequency scaling, and this controller will implement in
arm-trust-firmware. We add a special clock-type to handle that.

Signed-off-by: Lin Huang 
---
Changes in v5:
- delete unuse mux_flag
- use div_flag to distinguish sip call and other operate

Changes in v4:
- use arm_smccc_smc() to set/read ddr rate

Changes in v3:
- use sip call to set/read ddr rate

Changes in v2:
- use GENMASK instead val_mask
- use divider_recalc_rate() instead DIV_ROUND_UP_ULL
- cleanup code

Changes in v1:
- None

 drivers/clk/rockchip/Makefile   |   1 +
 drivers/clk/rockchip/clk-ddr.c  | 152 
 drivers/clk/rockchip/clk.c  |   9 +++
 drivers/clk/rockchip/clk.h  |  33 
 include/soc/rockchip/rockchip_sip.h |  27 +++
 5 files changed, 222 insertions(+)
 create mode 100644 drivers/clk/rockchip/clk-ddr.c
 create mode 100644 include/soc/rockchip/rockchip_sip.h

diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index f47a2fa..b5f2c8e 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -8,6 +8,7 @@ obj-y   += clk-pll.o
 obj-y  += clk-cpu.o
 obj-y  += clk-inverter.o
 obj-y  += clk-mmc-phase.o
+obj-y  += clk-ddr.o
 obj-$(CONFIG_RESET_CONTROLLER) += softrst.o
 
 obj-y  += clk-rk3036.o
diff --git a/drivers/clk/rockchip/clk-ddr.c b/drivers/clk/rockchip/clk-ddr.c
new file mode 100644
index 000..756e1ad
--- /dev/null
+++ b/drivers/clk/rockchip/clk-ddr.c
@@ -0,0 +1,152 @@
+/*
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Lin Huang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+struct rockchip_ddrclk {
+   struct clk_hw   hw;
+   void __iomem*reg_base;
+   int mux_offset;
+   int mux_shift;
+   int mux_width;
+   int div_shift;
+   int div_width;
+   int ddr_flag;
+   spinlock_t  *lock;
+};
+
+#define to_rockchip_ddrclk_hw(hw) container_of(hw, struct rockchip_ddrclk, hw)
+
+static int rockchip_ddrclk_set_rate(struct clk_hw *hw, unsigned long drate,
+   unsigned long prate)
+{
+   struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+   unsigned long flags;
+   struct arm_smccc_res res;
+   int ret;
+
+   spin_lock_irqsave(ddrclk->lock, flags);
+   if (ddrclk->ddr_flag == ROCKCHIP_DDRCLK_SIP) {
+   arm_smccc_smc(SIP_DDR_FREQ, drate, 0, CONFIG_DRAM_SET_RATE,
+ 0, 0, 0, 0, );
+   ret = res.a0;
+   }
+   spin_unlock_irqrestore(ddrclk->lock, flags);
+
+   return ret;
+}
+
+static unsigned long
+rockchip_ddrclk_recalc_rate(struct clk_hw *hw,
+   unsigned long parent_rate)
+{
+   struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+   struct arm_smccc_res res;
+   int ret;
+
+   if (ddrclk->ddr_flag == ROCKCHIP_DDRCLK_SIP) {
+   arm_smccc_smc(SIP_DDR_FREQ, 0, 0, CONFIG_DRAM_GET_RATE,
+ 0, 0, 0, 0, );
+   ret = res.a0;
+   }
+
+   return ret;
+}
+
+static long clk_ddrclk_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+   return rate;
+}
+
+static u8 rockchip_ddrclk_get_parent(struct clk_hw *hw)
+{
+   struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+   int num_parents = clk_hw_get_num_parents(hw);
+   u32 val;
+
+   val = clk_readl(ddrclk->reg_base +
+   ddrclk->mux_offset) >> ddrclk->mux_shift;
+   val &= GENMASK(ddrclk->mux_width - 1, 0);
+
+   if (val >= num_parents)
+   return -EINVAL;
+
+   return val;
+}
+
+static const struct clk_ops rockchip_ddrclk_ops = {
+   .recalc_rate = rockchip_ddrclk_recalc_rate,
+   .set_rate = rockchip_ddrclk_set_rate,
+   .round_rate = clk_ddrclk_round_rate,
+   .get_parent = rockchip_ddrclk_get_parent,
+};
+
+struct clk *rockchip_clk_register_ddrclk(const char *name, int flags,
+const char *const *parent_names,
+u8 num_parents, int mux_offset,
+int mux_shift, int mux_width,
+ 

[PATCH v5 1/8] clk: rockchip: add new clock-type for the ddrclk

[Lin Huang]

On new rockchip platform(rk3399 etc), there have dcf controller to
do ddr frequency scaling, and this controller will implement in
arm-trust-firmware. We add a special clock-type to handle that.

Signed-off-by: Lin Huang 
---
Changes in v5:
- delete unuse mux_flag
- use div_flag to distinguish sip call and other operate

Changes in v4:
- use arm_smccc_smc() to set/read ddr rate

Changes in v3:
- use sip call to set/read ddr rate

Changes in v2:
- use GENMASK instead val_mask
- use divider_recalc_rate() instead DIV_ROUND_UP_ULL
- cleanup code

Changes in v1:
- None

 drivers/clk/rockchip/Makefile   |   1 +
 drivers/clk/rockchip/clk-ddr.c  | 152 
 drivers/clk/rockchip/clk.c  |   9 +++
 drivers/clk/rockchip/clk.h  |  33 
 include/soc/rockchip/rockchip_sip.h |  27 +++
 5 files changed, 222 insertions(+)
 create mode 100644 drivers/clk/rockchip/clk-ddr.c
 create mode 100644 include/soc/rockchip/rockchip_sip.h

diff --git a/drivers/clk/rockchip/Makefile b/drivers/clk/rockchip/Makefile
index f47a2fa..b5f2c8e 100644
--- a/drivers/clk/rockchip/Makefile
+++ b/drivers/clk/rockchip/Makefile
@@ -8,6 +8,7 @@ obj-y   += clk-pll.o
 obj-y  += clk-cpu.o
 obj-y  += clk-inverter.o
 obj-y  += clk-mmc-phase.o
+obj-y  += clk-ddr.o
 obj-$(CONFIG_RESET_CONTROLLER) += softrst.o
 
 obj-y  += clk-rk3036.o
diff --git a/drivers/clk/rockchip/clk-ddr.c b/drivers/clk/rockchip/clk-ddr.c
new file mode 100644
index 000..756e1ad
--- /dev/null
+++ b/drivers/clk/rockchip/clk-ddr.c
@@ -0,0 +1,152 @@
+/*
+ * Copyright (c) 2016 Rockchip Electronics Co. Ltd.
+ * Author: Lin Huang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+
+struct rockchip_ddrclk {
+   struct clk_hw   hw;
+   void __iomem*reg_base;
+   int mux_offset;
+   int mux_shift;
+   int mux_width;
+   int div_shift;
+   int div_width;
+   int ddr_flag;
+   spinlock_t  *lock;
+};
+
+#define to_rockchip_ddrclk_hw(hw) container_of(hw, struct rockchip_ddrclk, hw)
+
+static int rockchip_ddrclk_set_rate(struct clk_hw *hw, unsigned long drate,
+   unsigned long prate)
+{
+   struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+   unsigned long flags;
+   struct arm_smccc_res res;
+   int ret;
+
+   spin_lock_irqsave(ddrclk->lock, flags);
+   if (ddrclk->ddr_flag == ROCKCHIP_DDRCLK_SIP) {
+   arm_smccc_smc(SIP_DDR_FREQ, drate, 0, CONFIG_DRAM_SET_RATE,
+ 0, 0, 0, 0, );
+   ret = res.a0;
+   }
+   spin_unlock_irqrestore(ddrclk->lock, flags);
+
+   return ret;
+}
+
+static unsigned long
+rockchip_ddrclk_recalc_rate(struct clk_hw *hw,
+   unsigned long parent_rate)
+{
+   struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+   struct arm_smccc_res res;
+   int ret;
+
+   if (ddrclk->ddr_flag == ROCKCHIP_DDRCLK_SIP) {
+   arm_smccc_smc(SIP_DDR_FREQ, 0, 0, CONFIG_DRAM_GET_RATE,
+ 0, 0, 0, 0, );
+   ret = res.a0;
+   }
+
+   return ret;
+}
+
+static long clk_ddrclk_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+   return rate;
+}
+
+static u8 rockchip_ddrclk_get_parent(struct clk_hw *hw)
+{
+   struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+   int num_parents = clk_hw_get_num_parents(hw);
+   u32 val;
+
+   val = clk_readl(ddrclk->reg_base +
+   ddrclk->mux_offset) >> ddrclk->mux_shift;
+   val &= GENMASK(ddrclk->mux_width - 1, 0);
+
+   if (val >= num_parents)
+   return -EINVAL;
+
+   return val;
+}
+
+static const struct clk_ops rockchip_ddrclk_ops = {
+   .recalc_rate = rockchip_ddrclk_recalc_rate,
+   .set_rate = rockchip_ddrclk_set_rate,
+   .round_rate = clk_ddrclk_round_rate,
+   .get_parent = rockchip_ddrclk_get_parent,
+};
+
+struct clk *rockchip_clk_register_ddrclk(const char *name, int flags,
+const char *const *parent_names,
+u8 num_parents, int mux_offset,
+int mux_shift, int mux_width,
+int 

[PATCH v5 2/8] clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc

[Lin Huang]

Signed-off-by: Lin Huang 
---
Changes in v5:
-None
Changes in v4:
-None

Changes in v3:
-None

Changes in v2:
-None 

Changes in v1:
-None

 include/dt-bindings/clock/rk3399-cru.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/clock/rk3399-cru.h 
b/include/dt-bindings/clock/rk3399-cru.h
index 50a44cf..ce5f3e9 100644
--- a/include/dt-bindings/clock/rk3399-cru.h
+++ b/include/dt-bindings/clock/rk3399-cru.h
@@ -131,6 +131,7 @@
 #define SCLK_DPHY_RX0_CFG  165
 #define SCLK_RMII_SRC  166
 #define SCLK_PCIEPHY_REF100M   167
+#define SCLK_DDRC  168
 
 #define DCLK_VOP0  180
 #define DCLK_VOP1  181
-- 
1.9.1

[PATCH v5 4/8] Documentation: bindings: add dt documentation for dfi controller

[Lin Huang]

This patch adds the documentation for rockchip dfi devfreq-event driver.

Signed-off-by: Lin Huang 
---
Changes in v5:
-None

Changes in v4:
-None

Changes in v3:
-None

Changes in v2:
-None 

Changes in v1:
-None

 .../bindings/devfreq/event/rockchip-dfi.txt  | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt

diff --git a/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt 
b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
new file mode 100644
index 000..bf42255
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
@@ -0,0 +1,20 @@
+
+* Rockchip rk3399 DFI device
+
+Required properties:
+- compatible: Must be "rockchip,rk3399-dfi".
+- reg: physical base address of each DFI and length of memory mapped region
+- rockchip,pmu: phandle to the syscon managing the "pmu general register files"
+- clocks: phandles for clock specified in "clock-names" property
+- clock-names : the name of clock used by the DFI, must be "pclk_ddr_mon";
+
+Example:
+   dfi: dfi@0xff63 {
+   reg = <0x00 0xff63 0x00 0x4000>;
+   compatible = "rockchip,rk3399-dfi";
+   rockchip,pmu = <>;
+   clocks = < PCLK_DDR_MON>;
+   clock-names = "pclk_ddr_mon";
+   status = "disabled";
+   };
+
-- 
1.9.1

[PATCH v5 2/8] clk: rockchip: rk3399: add SCLK_DDRCLK ID for ddrc

[Lin Huang]

Signed-off-by: Lin Huang 
---
Changes in v5:
-None
Changes in v4:
-None

Changes in v3:
-None

Changes in v2:
-None 

Changes in v1:
-None

 include/dt-bindings/clock/rk3399-cru.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/clock/rk3399-cru.h 
b/include/dt-bindings/clock/rk3399-cru.h
index 50a44cf..ce5f3e9 100644
--- a/include/dt-bindings/clock/rk3399-cru.h
+++ b/include/dt-bindings/clock/rk3399-cru.h
@@ -131,6 +131,7 @@
 #define SCLK_DPHY_RX0_CFG  165
 #define SCLK_RMII_SRC  166
 #define SCLK_PCIEPHY_REF100M   167
+#define SCLK_DDRC  168
 
 #define DCLK_VOP0  180
 #define DCLK_VOP1  181
-- 
1.9.1

[PATCH v5 4/8] Documentation: bindings: add dt documentation for dfi controller

[Lin Huang]

This patch adds the documentation for rockchip dfi devfreq-event driver.

Signed-off-by: Lin Huang 
---
Changes in v5:
-None

Changes in v4:
-None

Changes in v3:
-None

Changes in v2:
-None 

Changes in v1:
-None

 .../bindings/devfreq/event/rockchip-dfi.txt  | 20 
 1 file changed, 20 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt

diff --git a/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt 
b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
new file mode 100644
index 000..bf42255
--- /dev/null
+++ b/Documentation/devicetree/bindings/devfreq/event/rockchip-dfi.txt
@@ -0,0 +1,20 @@
+
+* Rockchip rk3399 DFI device
+
+Required properties:
+- compatible: Must be "rockchip,rk3399-dfi".
+- reg: physical base address of each DFI and length of memory mapped region
+- rockchip,pmu: phandle to the syscon managing the "pmu general register files"
+- clocks: phandles for clock specified in "clock-names" property
+- clock-names : the name of clock used by the DFI, must be "pclk_ddr_mon";
+
+Example:
+   dfi: dfi@0xff63 {
+   reg = <0x00 0xff63 0x00 0x4000>;
+   compatible = "rockchip,rk3399-dfi";
+   rockchip,pmu = <>;
+   clocks = < PCLK_DDR_MON>;
+   clock-names = "pclk_ddr_mon";
+   status = "disabled";
+   };
+
-- 
1.9.1

[PATCH v5 7/8] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

[Lin Huang]

base on dfi result, we do ddr frequency scaling, register
dmc driver to devfreq framework, and use simple-ondemand
policy.

Signed-off-by: Lin Huang 
---
Changes in v5:
- improve dmc driver suggest by Chanwoo Choi

Changes in v4:
- use arm_smccc_smc() function talk to bl31
- delete rockchip_dmc.c file and config
- delete dmc_notify
- adjust probe order

Changes in v3:
- operate dram setting through sip call
- imporve set rate flow

Changes in v2:
- None

Changes in v1:
- move dfi controller to event
- fix set voltage sequence when set rate fail
- change Kconfig type from tristate to bool
- move unuse EXPORT_SYMBOL_GPL()

 drivers/devfreq/Kconfig  |   9 +
 drivers/devfreq/Makefile |   1 +
 drivers/devfreq/rk3399_dmc.c | 512 +++
 3 files changed, 522 insertions(+)
 create mode 100644 drivers/devfreq/rk3399_dmc.c

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index a5be56e..749499d 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -100,6 +100,15 @@ config ARM_TEGRA_DEVFREQ
  It reads ACTMON counters of memory controllers and adjusts the
  operating frequencies and voltages with OPP support.
 
+config ARM_RK3399_DMC_DEVFREQ
+   tristate "ARM RK3399 DMC DEVFREQ Driver"
+   select PM_OPP
+   select DEVFREQ_GOV_SIMPLE_ONDEMAND
+   help
+  This adds the DEVFREQ driver for the RK3399 dmc(Dynamic Memory 
Controller).
+  It sets the frequency for the memory controller and reads the usage 
counts
+  from hardware.
+
 source "drivers/devfreq/event/Kconfig"
 
 endif # PM_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 09f11d9..70d9549 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE)   += governor_passive.o
 # DEVFREQ Drivers
 obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ)   += exynos-bus.o
 obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
+obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ)   += rk3399_dmc.o
 
 # DEVFREQ Event Drivers
 obj-$(CONFIG_PM_DEVFREQ_EVENT) += event/
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
new file mode 100644
index 000..c1157ba
--- /dev/null
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -0,0 +1,512 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Lin Huang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct dram_timing {
+   unsigned int ddr3_speed_bin;
+   unsigned int pd_idle;
+   unsigned int sr_idle;
+   unsigned int sr_mc_gate_idle;
+   unsigned int srpd_lite_idle;
+   unsigned int standby_idle;
+   unsigned int dram_dll_dis_freq;
+   unsigned int phy_dll_dis_freq;
+   unsigned int ddr3_odt_dis_freq;
+   unsigned int ddr3_drv;
+   unsigned int ddr3_odt;
+   unsigned int phy_ddr3_ca_drv;
+   unsigned int phy_ddr3_dq_drv;
+   unsigned int phy_ddr3_odt;
+   unsigned int lpddr3_odt_dis_freq;
+   unsigned int lpddr3_drv;
+   unsigned int lpddr3_odt;
+   unsigned int phy_lpddr3_ca_drv;
+   unsigned int phy_lpddr3_dq_drv;
+   unsigned int phy_lpddr3_odt;
+   unsigned int lpddr4_odt_dis_freq;
+   unsigned int lpddr4_drv;
+   unsigned int lpddr4_dq_odt;
+   unsigned int lpddr4_ca_odt;
+   unsigned int phy_lpddr4_ca_drv;
+   unsigned int phy_lpddr4_ck_cs_drv;
+   unsigned int phy_lpddr4_dq_drv;
+   unsigned int phy_lpddr4_odt;
+};
+
+struct rk3399_dmcfreq {
+   struct device *dev;
+   struct devfreq *devfreq;
+   struct devfreq_simple_ondemand_data ondemand_data;
+   struct clk *dmc_clk;
+   struct devfreq_event_dev *edev;
+   struct mutex lock;
+   struct dram_timing *timing;
+
+   /*
+* DDR Converser of Frequency (DCF) is used to implement DDR frequency
+* conversion without the participation of CPU, we will implement and
+* control it in arm trust firmware.
+*/
+   wait_queue_head_t   wait_dcf_queue;
+   int irq;
+   int wait_dcf_flag;
+   struct regulator *vdd_center;
+   unsigned long rate, target_rate;
+   unsigned long volt, target_volt;
+   struct dev_pm_opp *curr_opp;
+};
+
+static int rk3399_dmcfreq_target(struct device *dev, unsigned long *freq,
+

[PATCH v5 3/8] clk: rockchip: rk3399: add ddrc clock support

[Lin Huang]

add ddrc clock setting, so we can do ddr frequency
scaling on rk3399 platform in future.

Signed-off-by: Lin Huang 
---
Changes in v5:
- fit for the ddr type

Changes in v4:
- None

Changes in v3:
- None

Changes in v2:
- remove clk_ddrc_dpll_src from critical clock list

Changes in v1:
- remove ddrc source CLK_IGNORE_UNUSED flag
- move clk_ddrc and clk_ddrc_dpll_src to critical

 drivers/clk/rockchip/clk-rk3399.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/clk/rockchip/clk-rk3399.c 
b/drivers/clk/rockchip/clk-rk3399.c
index c109d80..b962aeb 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -118,6 +118,10 @@ PNAME(mux_armclkb_p)   = { 
"clk_core_b_lpll_src",
"clk_core_b_bpll_src",
"clk_core_b_dpll_src",
"clk_core_b_gpll_src" };
+PNAME(mux_ddrclk_p)= { "clk_ddrc_lpll_src",
+   "clk_ddrc_bpll_src",
+   "clk_ddrc_dpll_src",
+   "clk_ddrc_gpll_src" };
 PNAME(mux_aclk_cci_p)  = { "cpll_aclk_cci_src",
"gpll_aclk_cci_src",
"npll_aclk_cci_src",
@@ -1377,6 +1381,18 @@ static struct rockchip_clk_branch rk3399_clk_branches[] 
__initdata = {
COMPOSITE_NOMUX(0, "clk_test", "clk_test_pre", CLK_IGNORE_UNUSED,
RK3368_CLKSEL_CON(58), 0, 5, DFLAGS,
RK3368_CLKGATE_CON(13), 11, GFLAGS),
+
+   /* ddrc */
+   GATE(0, "clk_ddrc_lpll_src", "lpll", 0, RK3399_CLKGATE_CON(3),
+0, GFLAGS),
+   GATE(0, "clk_ddrc_bpll_src", "bpll", 0, RK3399_CLKGATE_CON(3),
+1, GFLAGS),
+   GATE(0, "clk_ddrc_dpll_src", "dpll", 0, RK3399_CLKGATE_CON(3),
+2, GFLAGS),
+   GATE(0, "clk_ddrc_gpll_src", "gpll", 0, RK3399_CLKGATE_CON(3),
+3, GFLAGS),
+   COMPOSITE_DDRCLK(SCLK_DDRC, "clk_ddrc", mux_ddrclk_p, 0,
+  RK3399_CLKSEL_CON(6), 4, 2, 0, 0, ROCKCHIP_DDRCLK_SIP),
 };
 
 static struct rockchip_clk_branch rk3399_clk_pmu_branches[] __initdata = {
@@ -1487,6 +1503,9 @@ static const char *const rk3399_cru_critical_clocks[] 
__initconst = {
"gpll_hclk_perilp1_src",
"gpll_aclk_perilp0_src",
"gpll_aclk_perihp_src",
+
+   /* ddrc */
+   "clk_ddrc"
 };
 
 static const char *const rk3399_pmucru_critical_clocks[] __initconst = {
-- 
1.9.1

[PATCH v5 5/8] PM / devfreq: event: support rockchip dfi controller

[Lin Huang]

on rk3399 platform, there is dfi conroller can monitor
ddr load, base on this result, we can do ddr freqency
scaling.

Signed-off-by: Lin Huang 
Acked-by: Chanwoo Choi 
---
Changes in v5:
-None

Changes in v4:
-None

Changes in v3:
-None

Changes in v2:
-None 

Changes in v1:
-None

 drivers/devfreq/event/Kconfig|   7 +
 drivers/devfreq/event/Makefile   |   1 +
 drivers/devfreq/event/rockchip-dfi.c | 253 +++
 3 files changed, 261 insertions(+)
 create mode 100644 drivers/devfreq/event/rockchip-dfi.c

diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
index eb6f74a..20d82c2 100644
--- a/drivers/devfreq/event/Kconfig
+++ b/drivers/devfreq/event/Kconfig
@@ -30,4 +30,11 @@ config DEVFREQ_EVENT_EXYNOS_PPMU
  (Platform Performance Monitoring Unit) counters to estimate the
  utilization of each module.
 
+config DEVFREQ_EVENT_ROCKCHIP_DFI
+   tristate "ROCKCHIP DFI DEVFREQ event Driver"
+   depends on ARCH_ROCKCHIP
+   help
+ This add the devfreq-event driver for Rockchip SoC. It provides DFI
+ (DDR Monitor Module) driver to count ddr load.
+
 endif # PM_DEVFREQ_EVENT
diff --git a/drivers/devfreq/event/Makefile b/drivers/devfreq/event/Makefile
index 3d6afd3..dda7090 100644
--- a/drivers/devfreq/event/Makefile
+++ b/drivers/devfreq/event/Makefile
@@ -2,3 +2,4 @@
 
 obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_NOCP) += exynos-nocp.o
 obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU) += exynos-ppmu.o
+obj-$(CONFIG_DEVFREQ_EVENT_ROCKCHIP_DFI) += rockchip-dfi.o
diff --git a/drivers/devfreq/event/rockchip-dfi.c 
b/drivers/devfreq/event/rockchip-dfi.c
new file mode 100644
index 000..3f12be7
--- /dev/null
+++ b/drivers/devfreq/event/rockchip-dfi.c
@@ -0,0 +1,253 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Lin Huang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RK3399_DMC_NUM_CH  2
+
+/* DDRMON_CTRL */
+#define DDRMON_CTRL0x04
+#define CLR_DDRMON_CTRL(0x1f << 0)
+#define LPDDR4_EN  (0x10001 << 4)
+#define HARDWARE_EN(0x10001 << 3)
+#define LPDDR3_EN  (0x10001 << 2)
+#define SOFTWARE_EN(0x10001 << 1)
+#define TIME_CNT_EN(0x10001 << 0)
+
+#define DDRMON_CH0_COUNT_NUM   0x28
+#define DDRMON_CH0_DFI_ACCESS_NUM  0x2c
+#define DDRMON_CH1_COUNT_NUM   0x3c
+#define DDRMON_CH1_DFI_ACCESS_NUM  0x40
+
+/* pmu grf */
+#define PMUGRF_OS_REG2 0x308
+#define DDRTYPE_SHIFT  13
+#define DDRTYPE_MASK   7
+
+enum {
+   DDR3 = 3,
+   LPDDR3 = 6,
+   LPDDR4 = 7,
+   UNUSED = 0xFF
+};
+
+struct dmc_usage {
+   u32 access;
+   u32 total;
+};
+
+struct rockchip_dfi {
+   struct devfreq_event_dev *edev;
+   struct devfreq_event_desc *desc;
+   struct dmc_usage ch_usage[RK3399_DMC_NUM_CH];
+   struct device *dev;
+   void __iomem *regs;
+   struct regmap *regmap_pmu;
+   struct clk *clk;
+};
+
+static void rockchip_dfi_start_hardware_counter(struct devfreq_event_dev *edev)
+{
+   struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+   void __iomem *dfi_regs = info->regs;
+   u32 val;
+   u32 ddr_type;
+
+   /* get ddr type */
+   regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, );
+   ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
+
+   /* clear DDRMON_CTRL setting */
+   writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
+
+   /* set ddr type to dfi */
+   if (ddr_type == LPDDR3)
+   writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
+   else if (ddr_type == LPDDR4)
+   writel_relaxed(LPDDR4_EN, dfi_regs + DDRMON_CTRL);
+
+   /* enable count, use software mode */
+   writel_relaxed(SOFTWARE_EN, dfi_regs + DDRMON_CTRL);
+}
+
+static void rockchip_dfi_stop_hardware_counter(struct devfreq_event_dev *edev)
+{
+   struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+   void __iomem *dfi_regs = info->regs;
+   u32 val;
+
+   val = readl_relaxed(dfi_regs + DDRMON_CTRL);
+   val &= ~SOFTWARE_EN;
+   writel_relaxed(val, dfi_regs + DDRMON_CTRL);
+}
+
+static int rockchip_dfi_get_busier_ch(struct devfreq_event_dev *edev)
+{
+   struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+   u32 tmp, max = 0;
+   u32 i, busier_ch = 0;
+   void 

[PATCH v5 7/8] PM / devfreq: rockchip: add devfreq driver for rk3399 dmc

[Lin Huang]

base on dfi result, we do ddr frequency scaling, register
dmc driver to devfreq framework, and use simple-ondemand
policy.

Signed-off-by: Lin Huang 
---
Changes in v5:
- improve dmc driver suggest by Chanwoo Choi

Changes in v4:
- use arm_smccc_smc() function talk to bl31
- delete rockchip_dmc.c file and config
- delete dmc_notify
- adjust probe order

Changes in v3:
- operate dram setting through sip call
- imporve set rate flow

Changes in v2:
- None

Changes in v1:
- move dfi controller to event
- fix set voltage sequence when set rate fail
- change Kconfig type from tristate to bool
- move unuse EXPORT_SYMBOL_GPL()

 drivers/devfreq/Kconfig  |   9 +
 drivers/devfreq/Makefile |   1 +
 drivers/devfreq/rk3399_dmc.c | 512 +++
 3 files changed, 522 insertions(+)
 create mode 100644 drivers/devfreq/rk3399_dmc.c

diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
index a5be56e..749499d 100644
--- a/drivers/devfreq/Kconfig
+++ b/drivers/devfreq/Kconfig
@@ -100,6 +100,15 @@ config ARM_TEGRA_DEVFREQ
  It reads ACTMON counters of memory controllers and adjusts the
  operating frequencies and voltages with OPP support.
 
+config ARM_RK3399_DMC_DEVFREQ
+   tristate "ARM RK3399 DMC DEVFREQ Driver"
+   select PM_OPP
+   select DEVFREQ_GOV_SIMPLE_ONDEMAND
+   help
+  This adds the DEVFREQ driver for the RK3399 dmc(Dynamic Memory 
Controller).
+  It sets the frequency for the memory controller and reads the usage 
counts
+  from hardware.
+
 source "drivers/devfreq/event/Kconfig"
 
 endif # PM_DEVFREQ
diff --git a/drivers/devfreq/Makefile b/drivers/devfreq/Makefile
index 09f11d9..70d9549 100644
--- a/drivers/devfreq/Makefile
+++ b/drivers/devfreq/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_DEVFREQ_GOV_PASSIVE)   += governor_passive.o
 # DEVFREQ Drivers
 obj-$(CONFIG_ARM_EXYNOS_BUS_DEVFREQ)   += exynos-bus.o
 obj-$(CONFIG_ARM_TEGRA_DEVFREQ)+= tegra-devfreq.o
+obj-$(CONFIG_ARM_RK3399_DMC_DEVFREQ)   += rk3399_dmc.o
 
 # DEVFREQ Event Drivers
 obj-$(CONFIG_PM_DEVFREQ_EVENT) += event/
diff --git a/drivers/devfreq/rk3399_dmc.c b/drivers/devfreq/rk3399_dmc.c
new file mode 100644
index 000..c1157ba
--- /dev/null
+++ b/drivers/devfreq/rk3399_dmc.c
@@ -0,0 +1,512 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Lin Huang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct dram_timing {
+   unsigned int ddr3_speed_bin;
+   unsigned int pd_idle;
+   unsigned int sr_idle;
+   unsigned int sr_mc_gate_idle;
+   unsigned int srpd_lite_idle;
+   unsigned int standby_idle;
+   unsigned int dram_dll_dis_freq;
+   unsigned int phy_dll_dis_freq;
+   unsigned int ddr3_odt_dis_freq;
+   unsigned int ddr3_drv;
+   unsigned int ddr3_odt;
+   unsigned int phy_ddr3_ca_drv;
+   unsigned int phy_ddr3_dq_drv;
+   unsigned int phy_ddr3_odt;
+   unsigned int lpddr3_odt_dis_freq;
+   unsigned int lpddr3_drv;
+   unsigned int lpddr3_odt;
+   unsigned int phy_lpddr3_ca_drv;
+   unsigned int phy_lpddr3_dq_drv;
+   unsigned int phy_lpddr3_odt;
+   unsigned int lpddr4_odt_dis_freq;
+   unsigned int lpddr4_drv;
+   unsigned int lpddr4_dq_odt;
+   unsigned int lpddr4_ca_odt;
+   unsigned int phy_lpddr4_ca_drv;
+   unsigned int phy_lpddr4_ck_cs_drv;
+   unsigned int phy_lpddr4_dq_drv;
+   unsigned int phy_lpddr4_odt;
+};
+
+struct rk3399_dmcfreq {
+   struct device *dev;
+   struct devfreq *devfreq;
+   struct devfreq_simple_ondemand_data ondemand_data;
+   struct clk *dmc_clk;
+   struct devfreq_event_dev *edev;
+   struct mutex lock;
+   struct dram_timing *timing;
+
+   /*
+* DDR Converser of Frequency (DCF) is used to implement DDR frequency
+* conversion without the participation of CPU, we will implement and
+* control it in arm trust firmware.
+*/
+   wait_queue_head_t   wait_dcf_queue;
+   int irq;
+   int wait_dcf_flag;
+   struct regulator *vdd_center;
+   unsigned long rate, target_rate;
+   unsigned long volt, target_volt;
+   struct dev_pm_opp *curr_opp;
+};
+
+static int rk3399_dmcfreq_target(struct device *dev, unsigned long *freq,
+u32 flags)
+{
+   struct 

[PATCH v5 3/8] clk: rockchip: rk3399: add ddrc clock support

[Lin Huang]

add ddrc clock setting, so we can do ddr frequency
scaling on rk3399 platform in future.

Signed-off-by: Lin Huang 
---
Changes in v5:
- fit for the ddr type

Changes in v4:
- None

Changes in v3:
- None

Changes in v2:
- remove clk_ddrc_dpll_src from critical clock list

Changes in v1:
- remove ddrc source CLK_IGNORE_UNUSED flag
- move clk_ddrc and clk_ddrc_dpll_src to critical

 drivers/clk/rockchip/clk-rk3399.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/clk/rockchip/clk-rk3399.c 
b/drivers/clk/rockchip/clk-rk3399.c
index c109d80..b962aeb 100644
--- a/drivers/clk/rockchip/clk-rk3399.c
+++ b/drivers/clk/rockchip/clk-rk3399.c
@@ -118,6 +118,10 @@ PNAME(mux_armclkb_p)   = { 
"clk_core_b_lpll_src",
"clk_core_b_bpll_src",
"clk_core_b_dpll_src",
"clk_core_b_gpll_src" };
+PNAME(mux_ddrclk_p)= { "clk_ddrc_lpll_src",
+   "clk_ddrc_bpll_src",
+   "clk_ddrc_dpll_src",
+   "clk_ddrc_gpll_src" };
 PNAME(mux_aclk_cci_p)  = { "cpll_aclk_cci_src",
"gpll_aclk_cci_src",
"npll_aclk_cci_src",
@@ -1377,6 +1381,18 @@ static struct rockchip_clk_branch rk3399_clk_branches[] 
__initdata = {
COMPOSITE_NOMUX(0, "clk_test", "clk_test_pre", CLK_IGNORE_UNUSED,
RK3368_CLKSEL_CON(58), 0, 5, DFLAGS,
RK3368_CLKGATE_CON(13), 11, GFLAGS),
+
+   /* ddrc */
+   GATE(0, "clk_ddrc_lpll_src", "lpll", 0, RK3399_CLKGATE_CON(3),
+0, GFLAGS),
+   GATE(0, "clk_ddrc_bpll_src", "bpll", 0, RK3399_CLKGATE_CON(3),
+1, GFLAGS),
+   GATE(0, "clk_ddrc_dpll_src", "dpll", 0, RK3399_CLKGATE_CON(3),
+2, GFLAGS),
+   GATE(0, "clk_ddrc_gpll_src", "gpll", 0, RK3399_CLKGATE_CON(3),
+3, GFLAGS),
+   COMPOSITE_DDRCLK(SCLK_DDRC, "clk_ddrc", mux_ddrclk_p, 0,
+  RK3399_CLKSEL_CON(6), 4, 2, 0, 0, ROCKCHIP_DDRCLK_SIP),
 };
 
 static struct rockchip_clk_branch rk3399_clk_pmu_branches[] __initdata = {
@@ -1487,6 +1503,9 @@ static const char *const rk3399_cru_critical_clocks[] 
__initconst = {
"gpll_hclk_perilp1_src",
"gpll_aclk_perilp0_src",
"gpll_aclk_perihp_src",
+
+   /* ddrc */
+   "clk_ddrc"
 };
 
 static const char *const rk3399_pmucru_critical_clocks[] __initconst = {
-- 
1.9.1

[PATCH v5 5/8] PM / devfreq: event: support rockchip dfi controller

[Lin Huang]

on rk3399 platform, there is dfi conroller can monitor
ddr load, base on this result, we can do ddr freqency
scaling.

Signed-off-by: Lin Huang 
Acked-by: Chanwoo Choi 
---
Changes in v5:
-None

Changes in v4:
-None

Changes in v3:
-None

Changes in v2:
-None 

Changes in v1:
-None

 drivers/devfreq/event/Kconfig|   7 +
 drivers/devfreq/event/Makefile   |   1 +
 drivers/devfreq/event/rockchip-dfi.c | 253 +++
 3 files changed, 261 insertions(+)
 create mode 100644 drivers/devfreq/event/rockchip-dfi.c

diff --git a/drivers/devfreq/event/Kconfig b/drivers/devfreq/event/Kconfig
index eb6f74a..20d82c2 100644
--- a/drivers/devfreq/event/Kconfig
+++ b/drivers/devfreq/event/Kconfig
@@ -30,4 +30,11 @@ config DEVFREQ_EVENT_EXYNOS_PPMU
  (Platform Performance Monitoring Unit) counters to estimate the
  utilization of each module.
 
+config DEVFREQ_EVENT_ROCKCHIP_DFI
+   tristate "ROCKCHIP DFI DEVFREQ event Driver"
+   depends on ARCH_ROCKCHIP
+   help
+ This add the devfreq-event driver for Rockchip SoC. It provides DFI
+ (DDR Monitor Module) driver to count ddr load.
+
 endif # PM_DEVFREQ_EVENT
diff --git a/drivers/devfreq/event/Makefile b/drivers/devfreq/event/Makefile
index 3d6afd3..dda7090 100644
--- a/drivers/devfreq/event/Makefile
+++ b/drivers/devfreq/event/Makefile
@@ -2,3 +2,4 @@
 
 obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_NOCP) += exynos-nocp.o
 obj-$(CONFIG_DEVFREQ_EVENT_EXYNOS_PPMU) += exynos-ppmu.o
+obj-$(CONFIG_DEVFREQ_EVENT_ROCKCHIP_DFI) += rockchip-dfi.o
diff --git a/drivers/devfreq/event/rockchip-dfi.c 
b/drivers/devfreq/event/rockchip-dfi.c
new file mode 100644
index 000..3f12be7
--- /dev/null
+++ b/drivers/devfreq/event/rockchip-dfi.c
@@ -0,0 +1,253 @@
+/*
+ * Copyright (c) 2016, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Lin Huang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RK3399_DMC_NUM_CH  2
+
+/* DDRMON_CTRL */
+#define DDRMON_CTRL0x04
+#define CLR_DDRMON_CTRL(0x1f << 0)
+#define LPDDR4_EN  (0x10001 << 4)
+#define HARDWARE_EN(0x10001 << 3)
+#define LPDDR3_EN  (0x10001 << 2)
+#define SOFTWARE_EN(0x10001 << 1)
+#define TIME_CNT_EN(0x10001 << 0)
+
+#define DDRMON_CH0_COUNT_NUM   0x28
+#define DDRMON_CH0_DFI_ACCESS_NUM  0x2c
+#define DDRMON_CH1_COUNT_NUM   0x3c
+#define DDRMON_CH1_DFI_ACCESS_NUM  0x40
+
+/* pmu grf */
+#define PMUGRF_OS_REG2 0x308
+#define DDRTYPE_SHIFT  13
+#define DDRTYPE_MASK   7
+
+enum {
+   DDR3 = 3,
+   LPDDR3 = 6,
+   LPDDR4 = 7,
+   UNUSED = 0xFF
+};
+
+struct dmc_usage {
+   u32 access;
+   u32 total;
+};
+
+struct rockchip_dfi {
+   struct devfreq_event_dev *edev;
+   struct devfreq_event_desc *desc;
+   struct dmc_usage ch_usage[RK3399_DMC_NUM_CH];
+   struct device *dev;
+   void __iomem *regs;
+   struct regmap *regmap_pmu;
+   struct clk *clk;
+};
+
+static void rockchip_dfi_start_hardware_counter(struct devfreq_event_dev *edev)
+{
+   struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+   void __iomem *dfi_regs = info->regs;
+   u32 val;
+   u32 ddr_type;
+
+   /* get ddr type */
+   regmap_read(info->regmap_pmu, PMUGRF_OS_REG2, );
+   ddr_type = (val >> DDRTYPE_SHIFT) & DDRTYPE_MASK;
+
+   /* clear DDRMON_CTRL setting */
+   writel_relaxed(CLR_DDRMON_CTRL, dfi_regs + DDRMON_CTRL);
+
+   /* set ddr type to dfi */
+   if (ddr_type == LPDDR3)
+   writel_relaxed(LPDDR3_EN, dfi_regs + DDRMON_CTRL);
+   else if (ddr_type == LPDDR4)
+   writel_relaxed(LPDDR4_EN, dfi_regs + DDRMON_CTRL);
+
+   /* enable count, use software mode */
+   writel_relaxed(SOFTWARE_EN, dfi_regs + DDRMON_CTRL);
+}
+
+static void rockchip_dfi_stop_hardware_counter(struct devfreq_event_dev *edev)
+{
+   struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+   void __iomem *dfi_regs = info->regs;
+   u32 val;
+
+   val = readl_relaxed(dfi_regs + DDRMON_CTRL);
+   val &= ~SOFTWARE_EN;
+   writel_relaxed(val, dfi_regs + DDRMON_CTRL);
+}
+
+static int rockchip_dfi_get_busier_ch(struct devfreq_event_dev *edev)
+{
+   struct rockchip_dfi *info = devfreq_event_get_drvdata(edev);
+   u32 tmp, max = 0;
+   u32 i, busier_ch = 0;
+   void __iomem *dfi_regs = info->regs;
+
+   

Re: Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)

[Tejun Heo]

Hello, Tom.

On Sun, Aug 07, 2016 at 10:10:17PM +0800, Tom Yan wrote:
> So the (not so) recent bump of BLK_DEF_MAX_SECTORS from 1024 to 2560
> (commit d2be537c3ba3) seemed to have caused trouble to some of the ATA
> devices, which were then worked around with ATA_HORKAGE_MAX_SEC_1024.
> 
> However, I am suspecting that the bump of BLK_DEF_MAX_SECTORS is not
> the "real" cause of the trouble, but the fact that AHCI_MAX_SG has
> been set to a weird value of 168 (with a comment "hardware max is
> 64K", which neither seem to make any sense).

Hmmm.. why not?  The hardware limit is 64k and the driver is using a
lower limit of 168 most likely because it doesn't make noticeable
difference beyond certain point and it determines the size of
contiguous memory which has to be allocated for the command table.
Each sg entry is 16 bytes.  Pushing it to the hardware limit would
require an order 9 allocation for each port.

> AHCI_MAX_SG is used to set the sg_tablesize (i.e. max_segments,
> apparently), which is apparently used to derive the actual "request
> size" (that is, if it is lower than max_sectors(_kb), it will be the
> limiting factor instead).
>
> For example, no matter if the drive has max_sectors set to 2560, or to
> 65535 (by adding it as the Optimal Transfer Length to libata's SATL,
> which is also max_hw_sectors that is set from ATA_MAX_SECTORS_LBA48),
> "avgrq-sz" in `iostat` will be capped at 1344 (168 * 8).

Not necessarily.  A single sg entry can point to an area larger than
PAGE_SIZE.

> However, if I change AHCI_MAX_SG to 128 (which is also the
> sg_tablesize set in libata.h from LIBATA_MAX_PRD), "avgrq-sz" in
> `iostat` will be capped at 1024 (128 * 8), which should make
> ATA_HORKAGE_MAX_SEC_1024 unnecessary.
> 
> So why has AHCI_MAX_SG been set to 168 anyway?

As written above, that probably makes the ahci command table size
nicely aligned.

Thanks.

-- 
tejun

Re: Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)

[Tejun Heo]

Hello, Tom.

On Sun, Aug 07, 2016 at 10:10:17PM +0800, Tom Yan wrote:
> So the (not so) recent bump of BLK_DEF_MAX_SECTORS from 1024 to 2560
> (commit d2be537c3ba3) seemed to have caused trouble to some of the ATA
> devices, which were then worked around with ATA_HORKAGE_MAX_SEC_1024.
> 
> However, I am suspecting that the bump of BLK_DEF_MAX_SECTORS is not
> the "real" cause of the trouble, but the fact that AHCI_MAX_SG has
> been set to a weird value of 168 (with a comment "hardware max is
> 64K", which neither seem to make any sense).

Hmmm.. why not?  The hardware limit is 64k and the driver is using a
lower limit of 168 most likely because it doesn't make noticeable
difference beyond certain point and it determines the size of
contiguous memory which has to be allocated for the command table.
Each sg entry is 16 bytes.  Pushing it to the hardware limit would
require an order 9 allocation for each port.

> AHCI_MAX_SG is used to set the sg_tablesize (i.e. max_segments,
> apparently), which is apparently used to derive the actual "request
> size" (that is, if it is lower than max_sectors(_kb), it will be the
> limiting factor instead).
>
> For example, no matter if the drive has max_sectors set to 2560, or to
> 65535 (by adding it as the Optimal Transfer Length to libata's SATL,
> which is also max_hw_sectors that is set from ATA_MAX_SECTORS_LBA48),
> "avgrq-sz" in `iostat` will be capped at 1344 (168 * 8).

Not necessarily.  A single sg entry can point to an area larger than
PAGE_SIZE.

> However, if I change AHCI_MAX_SG to 128 (which is also the
> sg_tablesize set in libata.h from LIBATA_MAX_PRD), "avgrq-sz" in
> `iostat` will be capped at 1024 (128 * 8), which should make
> ATA_HORKAGE_MAX_SEC_1024 unnecessary.
> 
> So why has AHCI_MAX_SG been set to 168 anyway?

As written above, that probably makes the ahci command table size
nicely aligned.

Thanks.

-- 
tejun

Re: [PATCH v5 5/6] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

[Peter Chen]

On Tue, Aug 09, 2016 at 05:15:36PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-08-08 01:52:10)
> > From: Peter Chen 
> > 
> > At device tree, we have no device node for chipidea core,
> > the glue layer's node is the parent node for host and udc
> > device. But in related driver, the parent device is chipidea
> > core. So, in order to let the common driver get parent's node,
> > we let the core's device node equals glue layer device node.
> > 
> > Signed-off-by: Peter Chen 
> > Tested-by: Maciej S. Szmigiero 
> > Tested-by Joshua Clayton 
> > ---
> >  drivers/usb/chipidea/core.c | 11 +++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index 69426e6..b189dc7 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -954,6 +954,15 @@ static int ci_hdrc_probe(struct platform_device *pdev)
> > dev_err(dev, "unable to init phy: %d\n", ret);
> > return ret;
> > }
> > +   /*
> > +* At device tree, we have no device node for chipidea core,
> > +* the glue layer's node is the parent node for host and udc
> > +* device. But in related driver, the parent device is chipidea
> > +* core. So, in order to let the common driver get parent's node,
> > +* we let the core's device node equals glue layer's node.
> > +*/
> > +   if (dev->parent && dev->parent->of_node)
> > +   dev->of_node = dev->parent->of_node;
> 
> Can this be done earlier? Perhaps after hw_device_init() in this probe
> routine? That would allow me to remove the awkward parent searching in
> my ULPI DT awareness patch.

The reason why I locate it there is to avoid "goto label" for error
path during PHY's get and initialization operation.

Ok, to simplify your work, I will change it at next version.

-- 

Best Regards,
Peter Chen

Re: [PATCH v5 5/6] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

[Peter Chen]

On Tue, Aug 09, 2016 at 05:15:36PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-08-08 01:52:10)
> > From: Peter Chen 
> > 
> > At device tree, we have no device node for chipidea core,
> > the glue layer's node is the parent node for host and udc
> > device. But in related driver, the parent device is chipidea
> > core. So, in order to let the common driver get parent's node,
> > we let the core's device node equals glue layer device node.
> > 
> > Signed-off-by: Peter Chen 
> > Tested-by: Maciej S. Szmigiero 
> > Tested-by Joshua Clayton 
> > ---
> >  drivers/usb/chipidea/core.c | 11 +++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> > index 69426e6..b189dc7 100644
> > --- a/drivers/usb/chipidea/core.c
> > +++ b/drivers/usb/chipidea/core.c
> > @@ -954,6 +954,15 @@ static int ci_hdrc_probe(struct platform_device *pdev)
> > dev_err(dev, "unable to init phy: %d\n", ret);
> > return ret;
> > }
> > +   /*
> > +* At device tree, we have no device node for chipidea core,
> > +* the glue layer's node is the parent node for host and udc
> > +* device. But in related driver, the parent device is chipidea
> > +* core. So, in order to let the common driver get parent's node,
> > +* we let the core's device node equals glue layer's node.
> > +*/
> > +   if (dev->parent && dev->parent->of_node)
> > +   dev->of_node = dev->parent->of_node;
> 
> Can this be done earlier? Perhaps after hw_device_init() in this probe
> routine? That would allow me to remove the awkward parent searching in
> my ULPI DT awareness patch.

The reason why I locate it there is to avoid "goto label" for error
path during PHY's get and initialization operation.

Ok, to simplify your work, I will change it at next version.

-- 

Best Regards,
Peter Chen

Re: [PATCH v2] mm/slub: Run free_partial() outside of the kmem_cache_node->list_lock

[Vladimir Davydov]

On Tue, Aug 09, 2016 at 04:27:46PM +0100, Chris Wilson wrote:
...
> diff --git a/mm/slub.c b/mm/slub.c
> index 825ff45..58f0eb6 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -3479,6 +3479,7 @@ static void list_slab_objects(struct kmem_cache *s, 
> struct page *page,
>   */
>  static void free_partial(struct kmem_cache *s, struct kmem_cache_node *n)
>  {
> + LIST_HEAD(partial_list);

nit: slabs added to this list are not partially used - they are free, so
let's call it 'free_slabs' or 'discard_list' or just 'discard', please

>   struct page *page, *h;
>  
>   BUG_ON(irqs_disabled());
> @@ -3486,13 +3487,16 @@ static void free_partial(struct kmem_cache *s, struct 
> kmem_cache_node *n)
>   list_for_each_entry_safe(page, h, >partial, lru) {
>   if (!page->inuse) {
>   remove_partial(n, page);
> - discard_slab(s, page);
> + list_add(>lru, _list);

If there are objects left in the cache on destruction, the cache won't
be destroyed. Instead it will be left on the slab_list and can get
reused later. So we should use list_move() here to always leave
n->partial in a consistent state, even in case of a leak.

>   } else {
>   list_slab_objects(s, page,
>   "Objects remaining in %s on __kmem_cache_shutdown()");
>   }
>   }
>   spin_unlock_irq(>list_lock);
> +
> + list_for_each_entry_safe(page, h, _list, lru)
> + discard_slab(s, page);
>  }
>  
>  /*

Re: [PATCH v2] mm/slub: Run free_partial() outside of the kmem_cache_node->list_lock

[Vladimir Davydov]

On Tue, Aug 09, 2016 at 04:27:46PM +0100, Chris Wilson wrote:
...
> diff --git a/mm/slub.c b/mm/slub.c
> index 825ff45..58f0eb6 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -3479,6 +3479,7 @@ static void list_slab_objects(struct kmem_cache *s, 
> struct page *page,
>   */
>  static void free_partial(struct kmem_cache *s, struct kmem_cache_node *n)
>  {
> + LIST_HEAD(partial_list);

nit: slabs added to this list are not partially used - they are free, so
let's call it 'free_slabs' or 'discard_list' or just 'discard', please

>   struct page *page, *h;
>  
>   BUG_ON(irqs_disabled());
> @@ -3486,13 +3487,16 @@ static void free_partial(struct kmem_cache *s, struct 
> kmem_cache_node *n)
>   list_for_each_entry_safe(page, h, >partial, lru) {
>   if (!page->inuse) {
>   remove_partial(n, page);
> - discard_slab(s, page);
> + list_add(>lru, _list);

If there are objects left in the cache on destruction, the cache won't
be destroyed. Instead it will be left on the slab_list and can get
reused later. So we should use list_move() here to always leave
n->partial in a consistent state, even in case of a leak.

>   } else {
>   list_slab_objects(s, page,
>   "Objects remaining in %s on __kmem_cache_shutdown()");
>   }
>   }
>   spin_unlock_irq(>list_lock);
> +
> + list_for_each_entry_safe(page, h, _list, lru)
> + discard_slab(s, page);
>  }
>  
>  /*

Re: [PATCH V3 1/3] tracing: add a possibility of exporting function trace to other places instead of ring buffer only

[Chunyan Zhang]

On Tue, Aug 9, 2016 at 11:35 PM, Steven Rostedt  wrote:
> On Tue,  9 Aug 2016 14:32:39 +0800
> Chunyan Zhang  wrote:
>
>> Currently ring buffer is the only output of Function traces, this patch
>> added trace_export concept which would process the traces and export
>> traces to a registered destination which can be ring buffer or some other
>> storage, in this way if we want Function traces to be sent to other
>> destination rather than ring buffer only, we just need to register a new
>> trace_export and implement its own .commit() callback or just use
>> 'trace_generic_commit()' which this patch also added and hooks up its
>> own .write() functio for writing traces to the storage.
>>
>> Currently, only Function trace (TRACE_FN) is supported.
>>
>> Signed-off-by: Chunyan Zhang 
>> ---
>>  include/linux/trace.h |  31 +
>>  kernel/trace/trace.c  | 124 
>> +-
>>  kernel/trace/trace.h  |  31 +
>>  3 files changed, 185 insertions(+), 1 deletion(-)
>>  create mode 100644 include/linux/trace.h
>>
>> diff --git a/include/linux/trace.h b/include/linux/trace.h
>> new file mode 100644
>> index 000..bc7f503
>> --- /dev/null
>> +++ b/include/linux/trace.h
>> @@ -0,0 +1,31 @@
>> +#ifndef _LINUX_TRACE_H
>> +#define _LINUX_TRACE_H
>> +
>> +#include 
>> +struct trace_array;
>> +
>> +#ifdef CONFIG_TRACING
>> +/*
>> + * The trace export - an export of function traces.  Every ftrace_ops
>> + * has at least one export which would output function traces to ring
>> + * buffer.
>> + *
>> + * tr- the trace_array this export belongs to
>> + * commit- commit the traces to ring buffer and/or some other places
>> + * write - copy traces which have been delt with ->commit() to
>> + * the destination
>> + */
>> +struct trace_export {
>> + char name[16];
>> + struct trace_export *next;
>
> Should document above name and next. What's name used for? Is it

Sure, I will document them in the next revision.

Speaking to the 'name' here... I just think it will probably be useful
in the future, for example, if we need an userspace interface for
users to decide which trace_export should be used.

> visible to userspace? Add "next" just to be consistent as that's pretty
> obvious what it is for.
>
>> + struct trace_array  *tr;
>> + void (*commit)(struct trace_array *, struct ring_buffer_event *);
>> + void (*write)(const char *, unsigned int);
>> +};
>> +
>> +int register_trace_export(struct trace_export *export);
>> +int unregister_trace_export(struct trace_export *export);
>> +
>> +#endif   /* CONFIG_TRACING */
>> +
>> +#endif   /* _LINUX_TRACE_H */
>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>> index dade4c9..67ae581 100644
>> --- a/kernel/trace/trace.c
>> +++ b/kernel/trace/trace.c
>> @@ -40,6 +40,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>>  #include "trace.h"
>> @@ -2128,6 +2129,127 @@ void trace_buffer_unlock_commit_regs(struct 
>> trace_array *tr,
>>   ftrace_trace_userstack(buffer, flags, pc);
>>  }
>>
>> +static inline void
>> +trace_generic_commit(struct trace_array *tr,
>> +struct ring_buffer_event *event)
>> +{
>> + struct trace_entry *entry;
>> + struct trace_export *export = tr->export;
>> + unsigned int size = 0;
>> +
>> + entry = ring_buffer_event_data(event);
>> +
>> + trace_entry_size(size, entry->type);
>> + if (!size)
>> + return;
>> +
>> + if (export->write)
>> + export->write((char *)entry, size);
>> +}
>> +
>> +static inline void
>> +trace_rb_commit(struct trace_array *tr,
>> +struct ring_buffer_event *event)
>> +{
>> + __buffer_unlock_commit(tr->trace_buffer.buffer, event);
>> +}
>> +
>> +static DEFINE_MUTEX(trace_export_lock);
>> +
>> +static struct trace_export trace_export_rb __read_mostly = {
>> + .name   = "rb",
>> + .commit = trace_rb_commit,
>> + .next   = NULL,
>> +};
>> +static struct trace_export *trace_fn_exports __read_mostly = 
>> _export_rb;
>> +
>> +inline void
>> +trace_function_exports(struct trace_array *tr,
>> +struct ring_buffer_event *event)
>> +{
>> + struct trace_export *export;
>> +
>> + mutex_lock(_export_lock);
>
> Wait! Are you calling a mutex from the function tracer? This will blow
> up easily. The function callbacks must be totally lockless!

Okay, I just wanted to protect the list from being changed while being used.
What do you think if I change to make adding/removing trace exports
from the list are only permitted when the trace isn't enabled?

>
>> +
>> + for (export = trace_fn_exports; export && export->commit;
>> +  export = export->next) {
>> + tr->export = export;
>> + export->commit(tr, event);
>> + }
>> +
>> + 

Re: [PATCH V3 1/3] tracing: add a possibility of exporting function trace to other places instead of ring buffer only

[Chunyan Zhang]

On Tue, Aug 9, 2016 at 11:35 PM, Steven Rostedt  wrote:
> On Tue,  9 Aug 2016 14:32:39 +0800
> Chunyan Zhang  wrote:
>
>> Currently ring buffer is the only output of Function traces, this patch
>> added trace_export concept which would process the traces and export
>> traces to a registered destination which can be ring buffer or some other
>> storage, in this way if we want Function traces to be sent to other
>> destination rather than ring buffer only, we just need to register a new
>> trace_export and implement its own .commit() callback or just use
>> 'trace_generic_commit()' which this patch also added and hooks up its
>> own .write() functio for writing traces to the storage.
>>
>> Currently, only Function trace (TRACE_FN) is supported.
>>
>> Signed-off-by: Chunyan Zhang 
>> ---
>>  include/linux/trace.h |  31 +
>>  kernel/trace/trace.c  | 124 
>> +-
>>  kernel/trace/trace.h  |  31 +
>>  3 files changed, 185 insertions(+), 1 deletion(-)
>>  create mode 100644 include/linux/trace.h
>>
>> diff --git a/include/linux/trace.h b/include/linux/trace.h
>> new file mode 100644
>> index 000..bc7f503
>> --- /dev/null
>> +++ b/include/linux/trace.h
>> @@ -0,0 +1,31 @@
>> +#ifndef _LINUX_TRACE_H
>> +#define _LINUX_TRACE_H
>> +
>> +#include 
>> +struct trace_array;
>> +
>> +#ifdef CONFIG_TRACING
>> +/*
>> + * The trace export - an export of function traces.  Every ftrace_ops
>> + * has at least one export which would output function traces to ring
>> + * buffer.
>> + *
>> + * tr- the trace_array this export belongs to
>> + * commit- commit the traces to ring buffer and/or some other places
>> + * write - copy traces which have been delt with ->commit() to
>> + * the destination
>> + */
>> +struct trace_export {
>> + char name[16];
>> + struct trace_export *next;
>
> Should document above name and next. What's name used for? Is it

Sure, I will document them in the next revision.

Speaking to the 'name' here... I just think it will probably be useful
in the future, for example, if we need an userspace interface for
users to decide which trace_export should be used.

> visible to userspace? Add "next" just to be consistent as that's pretty
> obvious what it is for.
>
>> + struct trace_array  *tr;
>> + void (*commit)(struct trace_array *, struct ring_buffer_event *);
>> + void (*write)(const char *, unsigned int);
>> +};
>> +
>> +int register_trace_export(struct trace_export *export);
>> +int unregister_trace_export(struct trace_export *export);
>> +
>> +#endif   /* CONFIG_TRACING */
>> +
>> +#endif   /* _LINUX_TRACE_H */
>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>> index dade4c9..67ae581 100644
>> --- a/kernel/trace/trace.c
>> +++ b/kernel/trace/trace.c
>> @@ -40,6 +40,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>>  #include "trace.h"
>> @@ -2128,6 +2129,127 @@ void trace_buffer_unlock_commit_regs(struct 
>> trace_array *tr,
>>   ftrace_trace_userstack(buffer, flags, pc);
>>  }
>>
>> +static inline void
>> +trace_generic_commit(struct trace_array *tr,
>> +struct ring_buffer_event *event)
>> +{
>> + struct trace_entry *entry;
>> + struct trace_export *export = tr->export;
>> + unsigned int size = 0;
>> +
>> + entry = ring_buffer_event_data(event);
>> +
>> + trace_entry_size(size, entry->type);
>> + if (!size)
>> + return;
>> +
>> + if (export->write)
>> + export->write((char *)entry, size);
>> +}
>> +
>> +static inline void
>> +trace_rb_commit(struct trace_array *tr,
>> +struct ring_buffer_event *event)
>> +{
>> + __buffer_unlock_commit(tr->trace_buffer.buffer, event);
>> +}
>> +
>> +static DEFINE_MUTEX(trace_export_lock);
>> +
>> +static struct trace_export trace_export_rb __read_mostly = {
>> + .name   = "rb",
>> + .commit = trace_rb_commit,
>> + .next   = NULL,
>> +};
>> +static struct trace_export *trace_fn_exports __read_mostly = 
>> _export_rb;
>> +
>> +inline void
>> +trace_function_exports(struct trace_array *tr,
>> +struct ring_buffer_event *event)
>> +{
>> + struct trace_export *export;
>> +
>> + mutex_lock(_export_lock);
>
> Wait! Are you calling a mutex from the function tracer? This will blow
> up easily. The function callbacks must be totally lockless!

Okay, I just wanted to protect the list from being changed while being used.
What do you think if I change to make adding/removing trace exports
from the list are only permitted when the trace isn't enabled?

>
>> +
>> + for (export = trace_fn_exports; export && export->commit;
>> +  export = export->next) {
>> + tr->export = export;
>> + export->commit(tr, event);
>> + }
>> +
>> + mutex_unlock(_export_lock);
>> +}
>> +
>> +static void add_trace_fn_export(struct trace_export 

Re: [PATCH v5 6/6] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

[Peter Chen]

On Tue, Aug 09, 2016 at 04:33:35PM -0700, Joshua Clayton wrote:
> Hi Peter,
> 
> On 08/08/2016 01:52 AM, Peter Chen wrote:
> > The current dts describes USB HUB's property at USB controller's
> > entry, it is improper. The USB HUB should be the child node
> > under USB controller, and power sequence properties are under
> > it.
> >
> > Signed-off-by: Peter Chen 
> > ---
> >  arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 +-
> >  1 file changed, 13 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi 
> > b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> > index 3bee2f9..f29a72c2f 100644
> > --- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> > @@ -9,6 +9,8 @@
> >   *
> >   */
> >  
> > +#include 
> > +
> >  / {
> > aliases {
> > backlight = 
> > @@ -58,17 +60,6 @@
> > #address-cells = <1>;
> > #size-cells = <0>;
> >  
> > -   reg_usb_h1_vbus: regulator@0 {
> > -   compatible = "regulator-fixed";
> > -   reg = <0>;
> > -   regulator-name = "usb_h1_vbus";
> > -   regulator-min-microvolt = <500>;
> > -   regulator-max-microvolt = <500>;
> > -   enable-active-high;
> > -   startup-delay-us = <2>; /* USB2415 requires a POR of 1 
> > us minimum */
> > -   gpio = < 12 0>;
> > -   };
> > -
> > reg_panel: regulator@1 {
> > compatible = "regulator-fixed";
> > reg = <1>;
> > @@ -259,9 +250,18 @@
> >   {
> > pinctrl-names = "default";
> > pinctrl-0 = <_usbh>;
> > -   vbus-supply = <_usb_h1_vbus>;
> > -   clocks = < IMX6QDL_CLK_CKO>;
> > status = "okay";
> > +
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> Assuming they are needed,
> #address-cells and #size-cells should go in imx6qdl.dtsi,
> rather than in board dts files, shouldn't they?

Yes, you are right. All imx USB controller has only one port.


> > +   usb2415: hub@1 {
> > +   compatible = "usb424,2514";
> > +   reg = <1>;
> Does   have any effect?
> I couldn't find any reference to it in the patches.
> (so apologies if it is in core code)
> Does it matter?

Please see 69bec7259853 ("USB: core: let USB device know device node")
for detail.

> Would it be possible to connect
> more than one hub to the same usb phy?

No possible for current imx, but possible for other SoCs.

-- 

Best Regards,
Peter Chen

Re: [PATCH v5 6/6] ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property

[Peter Chen]

On Tue, Aug 09, 2016 at 04:33:35PM -0700, Joshua Clayton wrote:
> Hi Peter,
> 
> On 08/08/2016 01:52 AM, Peter Chen wrote:
> > The current dts describes USB HUB's property at USB controller's
> > entry, it is improper. The USB HUB should be the child node
> > under USB controller, and power sequence properties are under
> > it.
> >
> > Signed-off-by: Peter Chen 
> > ---
> >  arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 +-
> >  1 file changed, 13 insertions(+), 13 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx6qdl-udoo.dtsi 
> > b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> > index 3bee2f9..f29a72c2f 100644
> > --- a/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-udoo.dtsi
> > @@ -9,6 +9,8 @@
> >   *
> >   */
> >  
> > +#include 
> > +
> >  / {
> > aliases {
> > backlight = 
> > @@ -58,17 +60,6 @@
> > #address-cells = <1>;
> > #size-cells = <0>;
> >  
> > -   reg_usb_h1_vbus: regulator@0 {
> > -   compatible = "regulator-fixed";
> > -   reg = <0>;
> > -   regulator-name = "usb_h1_vbus";
> > -   regulator-min-microvolt = <500>;
> > -   regulator-max-microvolt = <500>;
> > -   enable-active-high;
> > -   startup-delay-us = <2>; /* USB2415 requires a POR of 1 
> > us minimum */
> > -   gpio = < 12 0>;
> > -   };
> > -
> > reg_panel: regulator@1 {
> > compatible = "regulator-fixed";
> > reg = <1>;
> > @@ -259,9 +250,18 @@
> >   {
> > pinctrl-names = "default";
> > pinctrl-0 = <_usbh>;
> > -   vbus-supply = <_usb_h1_vbus>;
> > -   clocks = < IMX6QDL_CLK_CKO>;
> > status = "okay";
> > +
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> Assuming they are needed,
> #address-cells and #size-cells should go in imx6qdl.dtsi,
> rather than in board dts files, shouldn't they?

Yes, you are right. All imx USB controller has only one port.


> > +   usb2415: hub@1 {
> > +   compatible = "usb424,2514";
> > +   reg = <1>;
> Does   have any effect?
> I couldn't find any reference to it in the patches.
> (so apologies if it is in core code)
> Does it matter?

Please see 69bec7259853 ("USB: core: let USB device know device node")
for detail.

> Would it be possible to connect
> more than one hub to the same usb phy?

No possible for current imx, but possible for other SoCs.

-- 

Best Regards,
Peter Chen

Re: [PATCH 1/1] Add CPU temperature sensor support for i.MX53

[Tejun Heo]

Hello, Fabien.

Is $SUBJ right?  CPU temperature?

On Wed, Aug 03, 2016 at 09:35:56AM +0200, Fabien Lahoudere wrote:
> From: Csaba Kertesz 
> 
> The original patch was made by Richard Zhu for kernel 2.6.x:
> 
> ENGR00134041-MX53-Add-the-SATA-AHCI-temperature-monitor.patch
> 
> The old source code was migrated to the new kernel 3.x. The concept of
> value reading was changed a bit:
> 
> 1. The new 3.x kernel functions (imx_phy_reg_read, imx_phy_reg_write) use
>16 bit registers while the original implementation used 32 bit integers
>for this purpose.

The description seems pretty dated.

> 2. The communication is guarded against infinite loop to give up a certain
>register reading after 10 attempts. This number comes from the
>original implementation. A new variable (read_attempt) is introduced to
>count the trials.

That's a very high number for a retry counter.

> +/* SATA AHCI temperature monitor */
> +static ssize_t sata_ahci_current_tmp(struct device *dev, struct 
> device_attribute

Abbreviating temperature to tmp probably isn't the best idea.

Patch looks good to me except for the above nits; however, I wonder
whether it being a one-off sysfs attribute is the right approach.
Don't we have subsystems and interfaces for things like temperature
readings?

Thanks.

-- 
tejun

Re: [PATCH 1/1] Add CPU temperature sensor support for i.MX53

[Tejun Heo]

Hello, Fabien.

Is $SUBJ right?  CPU temperature?

On Wed, Aug 03, 2016 at 09:35:56AM +0200, Fabien Lahoudere wrote:
> From: Csaba Kertesz 
> 
> The original patch was made by Richard Zhu for kernel 2.6.x:
> 
> ENGR00134041-MX53-Add-the-SATA-AHCI-temperature-monitor.patch
> 
> The old source code was migrated to the new kernel 3.x. The concept of
> value reading was changed a bit:
> 
> 1. The new 3.x kernel functions (imx_phy_reg_read, imx_phy_reg_write) use
>16 bit registers while the original implementation used 32 bit integers
>for this purpose.

The description seems pretty dated.

> 2. The communication is guarded against infinite loop to give up a certain
>register reading after 10 attempts. This number comes from the
>original implementation. A new variable (read_attempt) is introduced to
>count the trials.

That's a very high number for a retry counter.

> +/* SATA AHCI temperature monitor */
> +static ssize_t sata_ahci_current_tmp(struct device *dev, struct 
> device_attribute

Abbreviating temperature to tmp probably isn't the best idea.

Patch looks good to me except for the above nits; however, I wonder
whether it being a one-off sysfs attribute is the right approach.
Don't we have subsystems and interfaces for things like temperature
readings?

Thanks.

-- 
tejun

Re: c6x linker issue on linux-next-20160808 + some linker table work

[Mark Salter]

On Tue, 2016-08-09 at 19:09 -0700, Luis R. Rodriguez wrote:
> On Aug 9, 2016 6:50 PM, "Mark Salter"  wrote:
> >
> > On Tue, 2016-08-09 at 20:40 +0200, Luis R. Rodriguez wrote:
> > > On Tue, Aug 09, 2016 at 01:04:00PM -0400, Mark Salter wrote:
> > > >
> > > > On Tue, 2016-08-09 at 06:37 -0700, Guenter Roeck wrote:
> > > > >
> > > > > On 08/09/2016 01:11 AM, Luis R. Rodriguez wrote:
> > > > > >
> > > > > >
> > > > > > Mark, Aurelien,
> > > > > >
> > > > > > I've run into a linker (ld) issue caused by the linker table work 
> > > > > > I've
> > > > > > been working on [0]. I looked into this and for the life of me, I
> > > > > > cannot comprehend what the problem is, so was hoping you folks might
> > > > > > be able to chime in.
> > > > > >
> > > > > For reference, the error is
> > > > >
> > > > > c6x-elf-ld: drivers/built-in.o: SB-relative relocation but 
> > > > > __c6xabi_DSBT_BASE not defined
> > > > > c6x-elf-ld: drivers/built-in.o: SB-relative relocation but 
> > > > > __c6xabi_DSBT_BASE not defined
> > > > DSBT is a reference to the no-MMU userspace ABI used by c6x. The kernel 
> > > > shouldn't
> > > > be referencing DSBT base. The -mno-dsbt gcc flag should prevent it.
> > > I see -mno-dsbt on arch/c6x/Makefile already -- however at link time this 
> > > is
> > > an issue if linker tables are used it seems. Do you have any other 
> > > recommendation?
> > >
> > > I will note that it would seem that even i386 and x86-64 
> > > compiler/binutils seem
> > > to have relocation issues on older compiler/binutils, for instance:
> >
> > I see the problem with gcc 6 as well.
> >
> > So there appears to be some toolchain issues at play here. We build the 
> > kernel with two
> > c6x-specific options: -mno-dsbt and -msdata=none. I already mentioned dsbt. 
> > The sdata
> > option may be one of:
> >
> > -msdata=default
> >      Put small global and static data in the .neardata section, which is 
> > pointed to by
> >      register B14. Put small uninitialized global and static data in the 
> > .bss section,
> >      which is adjacent to the .neardata section. Put small read-only data 
> > into the 
> >      .rodata section. The corresponding sections used for large pieces of 
> > data are
> >      .fardata, .far and .const.
> >
> > -msdata=all
> >     Put all data, not just small objects, into the sections reserved for 
> > small data,
> >     and use addressing relative to the B14 register to access them.
> >
> > -msdata=none
> >     Make no use of the sections reserved for small data, and use absolute 
> > addresses
> >     to access all data. Put all initialized global and static data in the 
> > .fardata
> >     section, and all uninitialized data in the .far section. Put all 
> > constant data
> >     into the .const section.
> >
> >
> > Both small data and DSBT make use of base register + 15-bit offset to 
> > access data
> > and thus the SB-relative reloc in the above error message.
> >
> > I think that gcc sees the .rodata section from DEFINE_LINKTABLE_RO() for 
> > builtin_fw
> > and thinks it needs an SB-relative reloc. When the linker sees that reloc, 
> > it thinks
> > it needs the dsbt base register and thus the error. Interestingly, weak 
> > data is
> > never put in the small data section so if gcc sees that data is weak, it 
> > doesn't
> > check the section name to see if it is a small data section. So SB-relative 
> > only
> > gets used for builtin_fw__end, but not the weak builtin_fw even though they 
> > both
> > are in the .rodata section.
> >
> > I suspect gcc should avoid being fooled by .rodata if -msdata=none is used.
> > Regardless, I think this could all be avoided if the RO tables used .const
> > instead of .rodata for c6x.
> Thanks for the thorough analysis, would you be OK for c6x to use .const for 
> all read only linker tables or section ranges ?
> I had not added #ifndef around the core-sections.h main ELF definitons but 
> could add one as its needed. In this case perhals that is needed and fine by 
> you
> for SECTION_RODATA.
> We can also override any of the core section setter helpers for archs but in 
> this case based on what you say it seems this is needed. Unless of course just
> -msdata=none is fine and that's not yet used and you prefer that.
>   Luis

We're already using -msdata=none for kernel builds. From the gcc docs, one 
would think
all const data goes into .const with -msdata=none, but the kernel forces a lot 
of weak
const kallsyms data ,rodata so c6x vmlinux.lds still needs to have a .rodata 
section. I
think we need to use .const for the c6x read-only linker tables and keep 
.rodata for
RO_DATA_SECTION in vmlinux.lds.h.

Re: c6x linker issue on linux-next-20160808 + some linker table work

[Mark Salter]

On Tue, 2016-08-09 at 19:09 -0700, Luis R. Rodriguez wrote:
> On Aug 9, 2016 6:50 PM, "Mark Salter"  wrote:
> >
> > On Tue, 2016-08-09 at 20:40 +0200, Luis R. Rodriguez wrote:
> > > On Tue, Aug 09, 2016 at 01:04:00PM -0400, Mark Salter wrote:
> > > >
> > > > On Tue, 2016-08-09 at 06:37 -0700, Guenter Roeck wrote:
> > > > >
> > > > > On 08/09/2016 01:11 AM, Luis R. Rodriguez wrote:
> > > > > >
> > > > > >
> > > > > > Mark, Aurelien,
> > > > > >
> > > > > > I've run into a linker (ld) issue caused by the linker table work 
> > > > > > I've
> > > > > > been working on [0]. I looked into this and for the life of me, I
> > > > > > cannot comprehend what the problem is, so was hoping you folks might
> > > > > > be able to chime in.
> > > > > >
> > > > > For reference, the error is
> > > > >
> > > > > c6x-elf-ld: drivers/built-in.o: SB-relative relocation but 
> > > > > __c6xabi_DSBT_BASE not defined
> > > > > c6x-elf-ld: drivers/built-in.o: SB-relative relocation but 
> > > > > __c6xabi_DSBT_BASE not defined
> > > > DSBT is a reference to the no-MMU userspace ABI used by c6x. The kernel 
> > > > shouldn't
> > > > be referencing DSBT base. The -mno-dsbt gcc flag should prevent it.
> > > I see -mno-dsbt on arch/c6x/Makefile already -- however at link time this 
> > > is
> > > an issue if linker tables are used it seems. Do you have any other 
> > > recommendation?
> > >
> > > I will note that it would seem that even i386 and x86-64 
> > > compiler/binutils seem
> > > to have relocation issues on older compiler/binutils, for instance:
> >
> > I see the problem with gcc 6 as well.
> >
> > So there appears to be some toolchain issues at play here. We build the 
> > kernel with two
> > c6x-specific options: -mno-dsbt and -msdata=none. I already mentioned dsbt. 
> > The sdata
> > option may be one of:
> >
> > -msdata=default
> >      Put small global and static data in the .neardata section, which is 
> > pointed to by
> >      register B14. Put small uninitialized global and static data in the 
> > .bss section,
> >      which is adjacent to the .neardata section. Put small read-only data 
> > into the 
> >      .rodata section. The corresponding sections used for large pieces of 
> > data are
> >      .fardata, .far and .const.
> >
> > -msdata=all
> >     Put all data, not just small objects, into the sections reserved for 
> > small data,
> >     and use addressing relative to the B14 register to access them.
> >
> > -msdata=none
> >     Make no use of the sections reserved for small data, and use absolute 
> > addresses
> >     to access all data. Put all initialized global and static data in the 
> > .fardata
> >     section, and all uninitialized data in the .far section. Put all 
> > constant data
> >     into the .const section.
> >
> >
> > Both small data and DSBT make use of base register + 15-bit offset to 
> > access data
> > and thus the SB-relative reloc in the above error message.
> >
> > I think that gcc sees the .rodata section from DEFINE_LINKTABLE_RO() for 
> > builtin_fw
> > and thinks it needs an SB-relative reloc. When the linker sees that reloc, 
> > it thinks
> > it needs the dsbt base register and thus the error. Interestingly, weak 
> > data is
> > never put in the small data section so if gcc sees that data is weak, it 
> > doesn't
> > check the section name to see if it is a small data section. So SB-relative 
> > only
> > gets used for builtin_fw__end, but not the weak builtin_fw even though they 
> > both
> > are in the .rodata section.
> >
> > I suspect gcc should avoid being fooled by .rodata if -msdata=none is used.
> > Regardless, I think this could all be avoided if the RO tables used .const
> > instead of .rodata for c6x.
> Thanks for the thorough analysis, would you be OK for c6x to use .const for 
> all read only linker tables or section ranges ?
> I had not added #ifndef around the core-sections.h main ELF definitons but 
> could add one as its needed. In this case perhals that is needed and fine by 
> you
> for SECTION_RODATA.
> We can also override any of the core section setter helpers for archs but in 
> this case based on what you say it seems this is needed. Unless of course just
> -msdata=none is fine and that's not yet used and you prefer that.
>   Luis

We're already using -msdata=none for kernel builds. From the gcc docs, one 
would think
all const data goes into .const with -msdata=none, but the kernel forces a lot 
of weak
const kallsyms data ,rodata so c6x vmlinux.lds still needs to have a .rodata 
section. I
think we need to use .const for the c6x read-only linker tables and keep 
.rodata for
RO_DATA_SECTION in vmlinux.lds.h.

Re: [PATCH v6 1/3] PCI: Add Precision Time Measurement (PTM) support

[Yong, Jonathan]

On 06/14/2016 03:05, Bjorn Helgaas wrote:
> From: Jonathan Yong 
> 
> Add Precision Time Measurement (PTM) support (see PCIe r3.1, sec 6.22).
> 
> Enable PTM on PTM Root devices and switch ports.  This does not enable PTM
> on endpoints.
> 
> There currently are no PTM-capable devices on the market, but it is
> expected to be supported by the Intel Apollo Lake platform.
> 
> [bhelgaas: complete rework]
> Signed-off-by: Jonathan Yong 
> Signed-off-by: Bjorn Helgaas 

Hi,

Any updates on the PTM changes?

Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Linus Torvalds]

On Tue, Aug 9, 2016 at 1:14 PM, Luis R. Rodriguez  wrote:
>
> I'm personally fine with MODULE_LICENSE("GPL") being used with copyleft-next 
> code
> and find it sensible.

I'd rather have the kernel license be as clear as possible, so I'd
tend to prefer that

  MODULE_LICENSE("GPL")

and then if you want to dual-license it, just put something like "or,
at your option, copyleft-next" in the comment at the top.

That makes it clear that as far as the kernel is concerned, it's
GPLv2, but if somebody finds it useful for other projects, they can
choose to take that file under copyleft-next (whatever version that
would be..).

  Linus

Re: [PATCH v6 1/3] PCI: Add Precision Time Measurement (PTM) support

[Yong, Jonathan]

On 06/14/2016 03:05, Bjorn Helgaas wrote:
> From: Jonathan Yong 
> 
> Add Precision Time Measurement (PTM) support (see PCIe r3.1, sec 6.22).
> 
> Enable PTM on PTM Root devices and switch ports.  This does not enable PTM
> on endpoints.
> 
> There currently are no PTM-capable devices on the market, but it is
> expected to be supported by the Intel Apollo Lake platform.
> 
> [bhelgaas: complete rework]
> Signed-off-by: Jonathan Yong 
> Signed-off-by: Bjorn Helgaas 

Hi,

Any updates on the PTM changes?

Re: Kernel modules under new copyleft licence : (was Re: [PATCH v2] module.h: add copyleft-next >= 0.3.1 as GPL compatible)

[Linus Torvalds]

On Tue, Aug 9, 2016 at 1:14 PM, Luis R. Rodriguez  wrote:
>
> I'm personally fine with MODULE_LICENSE("GPL") being used with copyleft-next 
> code
> and find it sensible.

I'd rather have the kernel license be as clear as possible, so I'd
tend to prefer that

  MODULE_LICENSE("GPL")

and then if you want to dual-license it, just put something like "or,
at your option, copyleft-next" in the comment at the top.

That makes it clear that as far as the kernel is concerned, it's
GPLv2, but if somebody finds it useful for other projects, they can
choose to take that file under copyleft-next (whatever version that
would be..).

  Linus

Re: [PATCH v6 2/4] mfd: lp873x: Add lp873x PMIC support

[Keerthy]

On Tuesday 09 August 2016 06:23 PM, Lee Jones wrote:

On Mon, 08 Aug 2016, Keerthy wrote:


The LP873X chip is a power management IC for Portable Navigation Systems
 and Tablet Computing devices. It contains the following components:

  - Regulators.
  - Configurable General Purpose Output Signals(GPO).

PMIC interacts with the main processor through i2c. PMIC has
couple of LDOs(Linear Regulators), couple of BUCKs (Step-Down DC-DC
Converter Cores) and GPOs(General Purpose Output Signals).

Signed-off-by: Keerthy 
---
Changes in v6:

   * Rebased on top of 
http://www.gossamer-threads.com/lists/linux/kernel/2457552.
   * Hence added probe_new instead of probe and removed unused i2c_device_id.


No, please don't do that.  This patch-set is blocked.

Please rebase on top of a mainline release and re-send.

We still need the I2C table, for now.


Okay. Guess i did some testing for that series then :-P.
I will revert only that and send patch[es [2-4].

Regards,
Keerthy



Changes in v4:

   * Added Author.
   * Added the mfd_cell for gpio.

Changes in v3:

   * Reordered the probe code.
   * Fixed Typo in Kconfig description.
   * Removed unused member from struct lp873x.

  drivers/mfd/Kconfig|  14 +++
  drivers/mfd/Makefile   |   2 +
  drivers/mfd/lp873x.c   |  89 +++
  include/linux/mfd/lp873x.h | 264 +
  4 files changed, 369 insertions(+)
  create mode 100644 drivers/mfd/lp873x.c
  create mode 100644 include/linux/mfd/lp873x.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2d1fb64..45fe00a 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1224,6 +1224,20 @@ config MFD_TPS65217
  This driver can also be built as a module.  If so, the module
  will be called tps65217.

+config MFD_TI_LP873X
+   tristate "TI LP873X Power Management IC"
+   depends on I2C
+   select MFD_CORE
+   select REGMAP_I2C
+   help
+ If you say yes here then you get support for the LP873X series of
+ Power Management Integrated Circuits(PMIC).
+ These include voltage regulators, Thermal protection, Configurable
+ General Purpose Outputs(GPO) that are used in portable devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called lp873x.
+
  config MFD_TPS65218
tristate "TI TPS65218 Power Management chips"
depends on I2C
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 2ba3ba3..42acbcd 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -22,6 +22,8 @@ obj-$(CONFIG_HTC_EGPIO)   += htc-egpio.o
  obj-$(CONFIG_HTC_PASIC3)  += htc-pasic3.o
  obj-$(CONFIG_HTC_I2CPLD)  += htc-i2cpld.o

+obj-$(CONFIG_MFD_TI_LP873X)+= lp873x.o
+
  obj-$(CONFIG_MFD_DAVINCI_VOICECODEC)  += davinci_voicecodec.o
  obj-$(CONFIG_MFD_DM355EVM_MSP)+= dm355evm_msp.o
  obj-$(CONFIG_MFD_TI_AM335X_TSCADC)+= ti_am335x_tscadc.o
diff --git a/drivers/mfd/lp873x.c b/drivers/mfd/lp873x.c
new file mode 100644
index 000..3c8e8d0
--- /dev/null
+++ b/drivers/mfd/lp873x.c
@@ -0,0 +1,89 @@
+/*
+ * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Keerthy 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static const struct regmap_config lp873x_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .max_register = LP873X_REG_MAX,
+};
+
+static const struct mfd_cell lp873x_cells[] = {
+   { .name = "lp873x-regulator", },
+   { .name = "lp873x-gpio", },
+};
+
+static int lp873x_probe(struct i2c_client *client)
+{
+   struct lp873x *lp873;
+   int ret;
+   unsigned int otpid;
+
+   lp873 = devm_kzalloc(>dev, sizeof(*lp873), GFP_KERNEL);
+   if (!lp873)
+   return -ENOMEM;
+
+   lp873->dev = >dev;
+
+   lp873->regmap = devm_regmap_init_i2c(client, _regmap_config);
+   if (IS_ERR(lp873->regmap)) {
+   ret = PTR_ERR(lp873->regmap);
+   dev_err(lp873->dev,
+   "Failed to initialize register map: %d\n", ret);
+   return ret;
+   }
+
+   mutex_init(>lock);
+
+   ret = regmap_read(lp873->regmap, LP873X_REG_OTP_REV, );
+   if (ret) {
+   dev_err(lp873->dev, "Failed to read OTP ID\n");
+   return ret;
+   }
+
+   lp873->rev = otpid & LP873X_OTP_REV_OTP_ID;
+   

Re: [PATCH v6 2/4] mfd: lp873x: Add lp873x PMIC support

[Keerthy]

On Tuesday 09 August 2016 06:23 PM, Lee Jones wrote:

On Mon, 08 Aug 2016, Keerthy wrote:


The LP873X chip is a power management IC for Portable Navigation Systems
 and Tablet Computing devices. It contains the following components:

  - Regulators.
  - Configurable General Purpose Output Signals(GPO).

PMIC interacts with the main processor through i2c. PMIC has
couple of LDOs(Linear Regulators), couple of BUCKs (Step-Down DC-DC
Converter Cores) and GPOs(General Purpose Output Signals).

Signed-off-by: Keerthy 
---
Changes in v6:

   * Rebased on top of 
http://www.gossamer-threads.com/lists/linux/kernel/2457552.
   * Hence added probe_new instead of probe and removed unused i2c_device_id.


No, please don't do that.  This patch-set is blocked.

Please rebase on top of a mainline release and re-send.

We still need the I2C table, for now.


Okay. Guess i did some testing for that series then :-P.
I will revert only that and send patch[es [2-4].

Regards,
Keerthy



Changes in v4:

   * Added Author.
   * Added the mfd_cell for gpio.

Changes in v3:

   * Reordered the probe code.
   * Fixed Typo in Kconfig description.
   * Removed unused member from struct lp873x.

  drivers/mfd/Kconfig|  14 +++
  drivers/mfd/Makefile   |   2 +
  drivers/mfd/lp873x.c   |  89 +++
  include/linux/mfd/lp873x.h | 264 +
  4 files changed, 369 insertions(+)
  create mode 100644 drivers/mfd/lp873x.c
  create mode 100644 include/linux/mfd/lp873x.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2d1fb64..45fe00a 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1224,6 +1224,20 @@ config MFD_TPS65217
  This driver can also be built as a module.  If so, the module
  will be called tps65217.

+config MFD_TI_LP873X
+   tristate "TI LP873X Power Management IC"
+   depends on I2C
+   select MFD_CORE
+   select REGMAP_I2C
+   help
+ If you say yes here then you get support for the LP873X series of
+ Power Management Integrated Circuits(PMIC).
+ These include voltage regulators, Thermal protection, Configurable
+ General Purpose Outputs(GPO) that are used in portable devices.
+
+ This driver can also be built as a module. If so, the module
+ will be called lp873x.
+
  config MFD_TPS65218
tristate "TI TPS65218 Power Management chips"
depends on I2C
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 2ba3ba3..42acbcd 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -22,6 +22,8 @@ obj-$(CONFIG_HTC_EGPIO)   += htc-egpio.o
  obj-$(CONFIG_HTC_PASIC3)  += htc-pasic3.o
  obj-$(CONFIG_HTC_I2CPLD)  += htc-i2cpld.o

+obj-$(CONFIG_MFD_TI_LP873X)+= lp873x.o
+
  obj-$(CONFIG_MFD_DAVINCI_VOICECODEC)  += davinci_voicecodec.o
  obj-$(CONFIG_MFD_DM355EVM_MSP)+= dm355evm_msp.o
  obj-$(CONFIG_MFD_TI_AM335X_TSCADC)+= ti_am335x_tscadc.o
diff --git a/drivers/mfd/lp873x.c b/drivers/mfd/lp873x.c
new file mode 100644
index 000..3c8e8d0
--- /dev/null
+++ b/drivers/mfd/lp873x.c
@@ -0,0 +1,89 @@
+/*
+ * Copyright (C) 2016 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Keerthy 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+static const struct regmap_config lp873x_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .max_register = LP873X_REG_MAX,
+};
+
+static const struct mfd_cell lp873x_cells[] = {
+   { .name = "lp873x-regulator", },
+   { .name = "lp873x-gpio", },
+};
+
+static int lp873x_probe(struct i2c_client *client)
+{
+   struct lp873x *lp873;
+   int ret;
+   unsigned int otpid;
+
+   lp873 = devm_kzalloc(>dev, sizeof(*lp873), GFP_KERNEL);
+   if (!lp873)
+   return -ENOMEM;
+
+   lp873->dev = >dev;
+
+   lp873->regmap = devm_regmap_init_i2c(client, _regmap_config);
+   if (IS_ERR(lp873->regmap)) {
+   ret = PTR_ERR(lp873->regmap);
+   dev_err(lp873->dev,
+   "Failed to initialize register map: %d\n", ret);
+   return ret;
+   }
+
+   mutex_init(>lock);
+
+   ret = regmap_read(lp873->regmap, LP873X_REG_OTP_REV, );
+   if (ret) {
+   dev_err(lp873->dev, "Failed to read OTP ID\n");
+   return ret;
+   }
+
+   lp873->rev = otpid & LP873X_OTP_REV_OTP_ID;
+   i2c_set_clientdata(client, lp873);
+   ret = 

Re: [PATCH v6 1/4] Documentation: mfd: LP873X: Add information for the mfd driver

[Keerthy]

On Tuesday 09 August 2016 06:20 PM, Lee Jones wrote:

On Mon, 08 Aug 2016, Keerthy wrote:


The lp873x series of PMICs have a bunch of regulators and a couple
of GPO(General Purpose Outputs).
Add information for the MFD and regulator drivers.

Acked-by: Rob Herring 
Signed-off-by: Keerthy 


These should be in chronological order.  Rob could not have Acked the
patch before you sent it.


---
Changes in v6:

   * Added more formating for properties.

Changes in v4:

   * Added the GPIO properties.

Changes in v3:

   * Changed the example node lable to pmic from lp8733.

  Documentation/devicetree/bindings/mfd/lp873x.txt | 59 
  1 file changed, 59 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/mfd/lp873x.txt


Patch looks good though.

I'll fix the nit above.


Okay thanks.



Applied, thanks.


diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt 
b/Documentation/devicetree/bindings/mfd/lp873x.txt
new file mode 100644
index 000..1377c25
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
@@ -0,0 +1,59 @@
+TI LP873X PMIC MFD driver
+
+Required properties:
+  - compatible:"ti,lp8732", "ti,lp8733"
+  - reg:   I2C slave address.
+  - gpio-controller:   Marks the device node as a GPIO Controller.
+  - #gpio-cells:   Should be two.  The first cell is the pin number and
+   the second cell is used to specify flags.
+   See ../gpio/gpio.txt for more information.
+  - regulators:List of child nodes that specify the regulator
+   initialization data.
+Example:
+
+pmic: lp8733@60 {
+   compatible = "ti,lp8733";
+   reg = <0x60>;
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   regulators {
+   lp8733_buck0: buck0 {
+   regulator-name = "lp8733-buck0";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-min-microamp = <150>;
+   regulator-max-microamp = <400>;
+   regulator-ramp-delay = <1>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   lp8733_buck1: buck1 {
+   regulator-name = "lp8733-buck1";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-min-microamp = <150>;
+   regulator-max-microamp = <400>;
+   regulator-ramp-delay = <1>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   lp8733_ldo0: ldo0 {
+   regulator-name = "lp8733-ldo0";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <300>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   lp8733_ldo1: ldo1 {
+   regulator-name = "lp8733-ldo1";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <300>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+   };
+};

Re: [PATCH v6 1/4] Documentation: mfd: LP873X: Add information for the mfd driver

[Keerthy]

On Tuesday 09 August 2016 06:20 PM, Lee Jones wrote:

On Mon, 08 Aug 2016, Keerthy wrote:


The lp873x series of PMICs have a bunch of regulators and a couple
of GPO(General Purpose Outputs).
Add information for the MFD and regulator drivers.

Acked-by: Rob Herring 
Signed-off-by: Keerthy 


These should be in chronological order.  Rob could not have Acked the
patch before you sent it.


---
Changes in v6:

   * Added more formating for properties.

Changes in v4:

   * Added the GPIO properties.

Changes in v3:

   * Changed the example node lable to pmic from lp8733.

  Documentation/devicetree/bindings/mfd/lp873x.txt | 59 
  1 file changed, 59 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/mfd/lp873x.txt


Patch looks good though.

I'll fix the nit above.


Okay thanks.



Applied, thanks.


diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt 
b/Documentation/devicetree/bindings/mfd/lp873x.txt
new file mode 100644
index 000..1377c25
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
@@ -0,0 +1,59 @@
+TI LP873X PMIC MFD driver
+
+Required properties:
+  - compatible:"ti,lp8732", "ti,lp8733"
+  - reg:   I2C slave address.
+  - gpio-controller:   Marks the device node as a GPIO Controller.
+  - #gpio-cells:   Should be two.  The first cell is the pin number and
+   the second cell is used to specify flags.
+   See ../gpio/gpio.txt for more information.
+  - regulators:List of child nodes that specify the regulator
+   initialization data.
+Example:
+
+pmic: lp8733@60 {
+   compatible = "ti,lp8733";
+   reg = <0x60>;
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   regulators {
+   lp8733_buck0: buck0 {
+   regulator-name = "lp8733-buck0";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-min-microamp = <150>;
+   regulator-max-microamp = <400>;
+   regulator-ramp-delay = <1>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   lp8733_buck1: buck1 {
+   regulator-name = "lp8733-buck1";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <140>;
+   regulator-min-microamp = <150>;
+   regulator-max-microamp = <400>;
+   regulator-ramp-delay = <1>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   lp8733_ldo0: ldo0 {
+   regulator-name = "lp8733-ldo0";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <300>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   lp8733_ldo1: ldo1 {
+   regulator-name = "lp8733-ldo1";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <300>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+   };
+};