Re: [PATCH 1/3] soc: fsl: add Platform PM driver QorIQ platforms

[Wang, Dongsheng]

On 2018/9/7 16:49, Ran Wang wrote:
> Hi Dongsheng
>
>> On 2018/9/5 11:05, Dongsheng Wang wrote:
>>
>> Please change your comments style.
>>
>> On 2018/8/31 11:57, Ran Wang wrote:
>>> This driver is to provide a independent framework for PM service
>>> provider and consumer to configure system level wake up feature. For
>>> example, RCPM driver could register a callback function on this
>>> platform first, and Flex timer driver who want to enable timer wake up
>>> feature, will call generic API provided by this platform driver, and
>>> then it will trigger RCPM driver to do it. The benefit is to isolate
>>> the user and service, such as flex timer driver will not have to know
>>> the implement details of wakeup function it require. Besides, it is
>>> also easy for service side to upgrade its logic when design is changed
>>> and remain user side unchanged.
>>>
>>> Signed-off-by: Ran Wang 
>>> ---
>>>  drivers/soc/fsl/Kconfig   |   14 +
>>>  drivers/soc/fsl/Makefile  |1 +
>>>  drivers/soc/fsl/plat_pm.c |  144
>> +
>>>  include/soc/fsl/plat_pm.h |   22 +++
>>>  4 files changed, 181 insertions(+), 0 deletions(-)  create mode
>>> 100644 drivers/soc/fsl/plat_pm.c  create mode 100644
>>> include/soc/fsl/plat_pm.h
>>>
>>> diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig index
>>> 7a9fb9b..6517412 100644
>>> --- a/drivers/soc/fsl/Kconfig
>>> +++ b/drivers/soc/fsl/Kconfig
>>> @@ -16,3 +16,17 @@ config FSL_GUTS
>>>   Initially only reading SVR and registering soc device are supported.
>>>   Other guts accesses, such as reading RCW, should eventually be
>> moved
>>>   into this driver as well.
>>> +
>>> +config FSL_PLAT_PM
>>> +   bool "Freescale platform PM framework"
>>> +   help
>>> + This driver is to provide a independent framework for PM service
>>> + provider and consumer to configure system level wake up feature.
>> For
>>> + example, RCPM driver could register a callback function on this
>>> + platform first, and Flex timer driver who want to enable timer wake
>>> + up feature, will call generic API provided by this platform driver,
>>> + and then it will trigger RCPM driver to do it. The benefit is to
>>> + isolate the user and service, such as  flex timer driver will not
>>> + have to know the implement details of wakeup function it require.
>>> + Besides, it is also easy for service side to upgrade its logic when
>>> + design changed and remain user side unchanged.
>>> diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile index
>>> 44b3beb..8f9db23 100644
>>> --- a/drivers/soc/fsl/Makefile
>>> +++ b/drivers/soc/fsl/Makefile
>>> @@ -6,3 +6,4 @@ obj-$(CONFIG_FSL_DPAA) += qbman/
>>>  obj-$(CONFIG_QUICC_ENGINE) += qe/
>>>  obj-$(CONFIG_CPM)  += qe/
>>>  obj-$(CONFIG_FSL_GUTS) += guts.o
>>> +obj-$(CONFIG_FSL_PLAT_PM)  += plat_pm.o
>>> diff --git a/drivers/soc/fsl/plat_pm.c b/drivers/soc/fsl/plat_pm.c new
>>> file mode 100644 index 000..19ea14e
>>> --- /dev/null
>>> +++ b/drivers/soc/fsl/plat_pm.c
>>> @@ -0,0 +1,144 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +//
>>> +// plat_pm.c - Freescale platform PM framework // // Copyright 2018
>>> +NXP // // Author: Ran Wang ,
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +
>>> +struct plat_pm_t {
>>> +   struct list_head node;
>>> +   fsl_plat_pm_handle handle;
>>> +   void *handle_priv;
>>> +   spinlock_t  lock;
>>> +};
>>> +
>>> +static struct plat_pm_t plat_pm;
>>> +
>>> +// register_fsl_platform_wakeup_source - Register callback function
>>> +to plat_pm // @handle: Pointer to handle PM feature requirement //
>>> +@handle_priv: Handler specific data struct // // Return 0 on success
>>> +other negative errno int
>>> +register_fsl_platform_wakeup_source(fsl_plat_pm_handle handle,
>>> +   void *handle_priv)
>>> +{
>>> +   struct plat_pm_t *p;
>>> +   unsigned long   flags;
>>> +
>>> +   if (!handle) {
>>> +   pr_err("FSL plat_pm: Handler invalid, reject\n");
>>> +   return -EINVAL;
>>> +   }
>>> +
>>> +   p = kmalloc(sizeof(*p), GFP_KERNEL);
>>> +   if (!p)
>>> +   return -ENOMEM;
>>> +
>>> +   p->handle = handle;
>>> +   p->handle_priv = handle_priv;
>>> +
>>> +   spin_lock_irqsave(&plat_pm.lock, flags);
>>> +   list_add_tail(&p->node, &plat_pm.node);
>>> +   spin_unlock_irqrestore(&plat_pm.lock, flags);
>>> +
>>> +   return 0;
>>> +}
>>> +EXPORT_SYMBOL_GPL(register_fsl_platform_wakeup_source);
>>> +
>>> +// Deregister_fsl_platform_wakeup_source - deregister callback
>>> +function // @handle_priv: Handler specific data struct // // Return 0
>>> +on success other negative errno int
>>> +deregister_fsl_platform_wakeup_source(void *handle_priv) {
>>> +   struct plat_pm_t *p, *tmp;
>>> +   unsigned long   flags;
>>> +
>>> +   spin_lock_irqsave(&plat_pm.lock, flags);
>>> +   list_for

Re: [PATCH 3/3] soc: fsl: add RCPM driver

[Wang, Dongsheng]

Please change your comments style.

On 2018/8/31 11:56, Ran Wang wrote:
> The NXP's QorIQ Processors based on ARM Core have RCPM module (Run
> Control and Power Management), which performs all device-level
> tasks associated with power management such as wakeup source control.
>
> This driver depends on FSL platform PM driver framework which help to
> isolate user and PM service provider (such as RCPM driver).
>
> Signed-off-by: Chenhui Zhao 
> Signed-off-by: Ying Zhang 
> Signed-off-by: Ran Wang 
> ---
>  drivers/soc/fsl/Kconfig   |6 ++
>  drivers/soc/fsl/Makefile  |1 +
>  drivers/soc/fsl/ls-rcpm.c |  153 
> +
>  3 files changed, 160 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/soc/fsl/ls-rcpm.c
>
> diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
> index 6517412..882330d 100644
> --- a/drivers/soc/fsl/Kconfig
> +++ b/drivers/soc/fsl/Kconfig
> @@ -30,3 +30,9 @@ config FSL_PLAT_PM
> have to know the implement details of wakeup function it require.
> Besides, it is also easy for service side to upgrade its logic when
> design changed and remain user side unchanged.
> +
> +config LS_RCPM
> + bool "Freescale RCPM support"
> + depends on (FSL_PLAT_PM)
> + help
> +   This feature is to enable specified wakeup source for system sleep.
> diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> index 8f9db23..43ff71a 100644
> --- a/drivers/soc/fsl/Makefile
> +++ b/drivers/soc/fsl/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_QUICC_ENGINE)+= qe/
>  obj-$(CONFIG_CPM)+= qe/
>  obj-$(CONFIG_FSL_GUTS)   += guts.o
>  obj-$(CONFIG_FSL_PLAT_PM)+= plat_pm.o
> +obj-$(CONFIG_LS_RCPM)+= ls-rcpm.o
> diff --git a/drivers/soc/fsl/ls-rcpm.c b/drivers/soc/fsl/ls-rcpm.c
> new file mode 100644
> index 000..b0feb88
> --- /dev/null
> +++ b/drivers/soc/fsl/ls-rcpm.c
> @@ -0,0 +1,153 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// plat_pm.c - Freescale Layerscape RCPM driver
> +//
> +// Copyright 2018 NXP
> +//
> +// Author: Ran Wang ,
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MAX_COMPATIBLE_NUM   10
> +
> +struct rcpm_t {
> + struct device *dev;
> + void __iomem *ippdexpcr_addr;
> + bool big_endian;/* Big/Little endian of RCPM module */
> +};
> +
> +// rcpm_handle - Configure RCPM reg according to wake up source request
> +// @user_dev: pointer to user's device struct
> +// @flag: to enable(true) or disable(false) wakeup source
> +// @handle_priv: pointer to struct rcpm_t instance
> +//
> +// Return 0 on success other negative errno
> +static int rcpm_handle(struct device *user_dev, bool flag, void *handle_priv)
> +{
> + struct rcpm_t *rcpm;
> + bool big_endian;
> + const char  *dev_compatible_array[MAX_COMPATIBLE_NUM];
> + void __iomem *ippdexpcr_addr;
> + u32 ippdexpcr;
> + u32 set_bit;
> + int ret, num, i;
> +
> + rcpm = handle_priv;
> + big_endian = rcpm->big_endian;
> + ippdexpcr_addr = rcpm->ippdexpcr_addr;
> +
> + num = device_property_read_string_array(user_dev, "compatible",
> + dev_compatible_array, MAX_COMPATIBLE_NUM);
> + if (num < 0)
> + return num;
> +
> + for (i = 0; i < num; i++) {
> + if (!device_property_present(rcpm->dev,
> + dev_compatible_array[i]))
> + continue;
> + else {
Remove this else.
> + ret = device_property_read_u32(rcpm->dev,
> + dev_compatible_array[i], &set_bit);
> + if (ret)
> + return ret;
> +
> + if (!device_property_present(rcpm->dev,
> + dev_compatible_array[i]))
This has been checked. Continue ? or return ENODEV？
> + return -ENODEV;
> + else {
Remove this else.
> + ret = device_property_read_u32(rcpm->dev,
> + dev_compatible_array[i], 
> &set_bit);
> + if (ret)
> + return ret;
> +
> + if (big_endian)
> + ippdexpcr = ioread32be(ippdexpcr_addr);
> + else
> + ippdexpcr = ioread32(ippdexpcr_addr);
> +
> + if (flag)
> + ippdexpcr |= set_bit;
> + else
> + ippdexpcr &= ~set_bit;
> +
> + if (big_endian) {
> + iowrite32be(ippdexpcr, ippdexpcr_addr);
> + ippdexpcr = ioread32

Re: [PATCH 1/3] soc: fsl: add Platform PM driver QorIQ platforms

[Wang, Dongsheng]

Please change your comments style.

On 2018/8/31 11:57, Ran Wang wrote:
> This driver is to provide a independent framework for PM service
> provider and consumer to configure system level wake up feature. For
> example, RCPM driver could register a callback function on this
> platform first, and Flex timer driver who want to enable timer wake
> up feature, will call generic API provided by this platform driver,
> and then it will trigger RCPM driver to do it. The benefit is to
> isolate the user and service, such as flex timer driver will not have
> to know the implement details of wakeup function it require. Besides,
> it is also easy for service side to upgrade its logic when design is
> changed and remain user side unchanged.
>
> Signed-off-by: Ran Wang 
> ---
>  drivers/soc/fsl/Kconfig   |   14 +
>  drivers/soc/fsl/Makefile  |1 +
>  drivers/soc/fsl/plat_pm.c |  144 
> +
>  include/soc/fsl/plat_pm.h |   22 +++
>  4 files changed, 181 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/soc/fsl/plat_pm.c
>  create mode 100644 include/soc/fsl/plat_pm.h
>
> diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig
> index 7a9fb9b..6517412 100644
> --- a/drivers/soc/fsl/Kconfig
> +++ b/drivers/soc/fsl/Kconfig
> @@ -16,3 +16,17 @@ config FSL_GUTS
> Initially only reading SVR and registering soc device are supported.
> Other guts accesses, such as reading RCW, should eventually be moved
> into this driver as well.
> +
> +config FSL_PLAT_PM
> + bool "Freescale platform PM framework"
> + help
> +   This driver is to provide a independent framework for PM service
> +   provider and consumer to configure system level wake up feature. For
> +   example, RCPM driver could register a callback function on this
> +   platform first, and Flex timer driver who want to enable timer wake
> +   up feature, will call generic API provided by this platform driver,
> +   and then it will trigger RCPM driver to do it. The benefit is to
> +   isolate the user and service, such as  flex timer driver will not
> +   have to know the implement details of wakeup function it require.
> +   Besides, it is also easy for service side to upgrade its logic when
> +   design changed and remain user side unchanged.
> diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile
> index 44b3beb..8f9db23 100644
> --- a/drivers/soc/fsl/Makefile
> +++ b/drivers/soc/fsl/Makefile
> @@ -6,3 +6,4 @@ obj-$(CONFIG_FSL_DPAA) += qbman/
>  obj-$(CONFIG_QUICC_ENGINE)   += qe/
>  obj-$(CONFIG_CPM)+= qe/
>  obj-$(CONFIG_FSL_GUTS)   += guts.o
> +obj-$(CONFIG_FSL_PLAT_PM)+= plat_pm.o
> diff --git a/drivers/soc/fsl/plat_pm.c b/drivers/soc/fsl/plat_pm.c
> new file mode 100644
> index 000..19ea14e
> --- /dev/null
> +++ b/drivers/soc/fsl/plat_pm.c
> @@ -0,0 +1,144 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// plat_pm.c - Freescale platform PM framework
> +//
> +// Copyright 2018 NXP
> +//
> +// Author: Ran Wang ,
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +
> +struct plat_pm_t {
> + struct list_head node;
> + fsl_plat_pm_handle handle;
> + void *handle_priv;
> + spinlock_t  lock;
> +};
> +
> +static struct plat_pm_t plat_pm;
> +
> +// register_fsl_platform_wakeup_source - Register callback function to 
> plat_pm
> +// @handle: Pointer to handle PM feature requirement
> +// @handle_priv: Handler specific data struct
> +//
> +// Return 0 on success other negative errno
> +int register_fsl_platform_wakeup_source(fsl_plat_pm_handle handle,
> + void *handle_priv)
> +{
> + struct plat_pm_t *p;
> + unsigned long   flags;
> +
> + if (!handle) {
> + pr_err("FSL plat_pm: Handler invalid, reject\n");
> + return -EINVAL;
> + }
> +
> + p = kmalloc(sizeof(*p), GFP_KERNEL);
> + if (!p)
> + return -ENOMEM;
> +
> + p->handle = handle;
> + p->handle_priv = handle_priv;
> +
> + spin_lock_irqsave(&plat_pm.lock, flags);
> + list_add_tail(&p->node, &plat_pm.node);
> + spin_unlock_irqrestore(&plat_pm.lock, flags);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(register_fsl_platform_wakeup_source);
> +
> +// Deregister_fsl_platform_wakeup_source - deregister callback function
> +// @handle_priv: Handler specific data struct
> +//
> +// Return 0 on success other negative errno
> +int deregister_fsl_platform_wakeup_source(void *handle_priv)
> +{
> + struct plat_pm_t *p, *tmp;
> + unsigned long   flags;
> +
> + spin_lock_irqsave(&plat_pm.lock, flags);
> + list_for_each_entry_safe(p, tmp, &plat_pm.node, node) {
> + if (p->handle_priv == handle_priv) {
> + list_del(&p->node);
> + kfree(p);
> + }
> + }
> + spin_unlock_irqrestore(&p

RE: [PATCH v3 1/2] fsl: Add binding for RCPM

[Wang Dongsheng]

> > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > @@ -0,0 +1,63 @@
> > +* Run Control and Power Management
> > +---
> > +The RCPM performs all device-level tasks associated with device run
> > +control and power management.
> > +
> > +Required properites:
> > +  - reg : Offset and length of the register set of RCPM block.
> 
> s/RCPM block/the RCPM block/
> 
> > +  - fsl,#rcpm-wakeup-cells : The number of cells in rcpm-wakeup property.
> 
> s/rcpm-wakeup-property/the rcpm-wakeup-property/
> 
> > +  - compatible : Sould contain a chip-specific RCPM block compatible
> > + string
> 
> s/Sould/Should
> 
> "Should" means it is recommended, but does not mean "must".  Is it really
> optional?
> 

Thanks for your patient explain, change to "must".

Regards,
-Dongsheng

> > +   and (if applicable) may contain a chassis-version RCPM compatible
> > +   string. Chip-specific strings are of the form "fsl,-rcpm",
> > +   such as:
> > +   * "fsl,p2041-rcpm"
> > +   * "fsl,p3041-rcpm"
> > +   * "fsl,p4080-rcpm"
> > +   * "fsl,p5020-rcpm"
> > +   * "fsl,p5040-rcpm"
> > +   * "fsl,t4240-rcpm"
> > +   * "fsl,b4420-rcpm"
> > +   * "fsl,b4860-rcpm"
> 
> 2 or 3 examples is enough.
> 
> > +   Chassis-version strings are of the form "fsl,qoriq-rcpm-",
> > +   such as:
> > +   * "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
> > +   * "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
> > +   * "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
> > +
> > +All references to "1.0" and "2.0" refer to the QorIQ chassis version
> > +to which the chip complies.
> > +Chassis VersionExample Chips
> > +------
> > +1.0p4080, p5020, p5040, p2041, p3041
> > +2.0t4240, b4860, b4420
> > +2.1t1040, ls1021
> 
> Not sure this binding is the place to maintain a table of chassis versions to
> SoCs.
> 
> Thanks,
> Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 1/2] fsl: Add binding for RCPM

[Wang Dongsheng]

> On Thu, 2015-09-24 at 21:38 -0500, Wang Dongsheng-B40534 wrote:
> > > > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > > > +---
> > > > +Required rcpm-wakeup property should be added to a device node if the
> > > > device
> > > > +can be used as a wakeup source.
> > > > +
> > > > +  - rcpm-wakeup: The value of the property consists of cells, the
> > > > number of
> > > > + cells defined in "fsl,#rcpm-wakeup-cells". The first cell is a
> > > > pointer
> > > > + to the rcpm node, the second cell is the bit mask that should be
> > > > set
> > > > + in IPPDEXPCR0, and the third cell is for IPPDEXPCR1, and so on.
> > >
> > > The phandle should not be included in the cell count.
> > >
> >
> > Yes, the first cell "&rcpm" should be in the cell count, right?
> 
> No.  None of the other #foo-cells work that way.
> 

Sorry a type wrong. I means the first cell "&rcpm" should *NOT* be in the cell 
count.

Regards,
-Dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 1/2] fsl: Add binding for RCPM

[Wang Dongsheng]

> > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > +---
> > +Required rcpm-wakeup property should be added to a device node if the
> > device
> > +can be used as a wakeup source.
> > +
> > +  - rcpm-wakeup: The value of the property consists of cells, the number of
> > + cells defined in "fsl,#rcpm-wakeup-cells". The first cell is a pointer
> > + to the rcpm node, the second cell is the bit mask that should be set
> > + in IPPDEXPCR0, and the third cell is for IPPDEXPCR1, and so on.
> 
> The phandle should not be included in the cell count.
> 

Yes, the first cell "&rcpm" should be in the cell count, right?

Regards,
-Dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 1/2] fsl: Add binding for RCPM

[Wang Dongsheng]

Hi Shawn,

Thanks for your review.

> > From: Wang Dongsheng 
> >
> > RCPM is the Run Control and Power Management module performs all
> > device-level tasks associated with device run control and power
> > management.
> >
> > Add this for freescale powerpc platform and layerscape platform.
> >
> > Signed-off-by: Chenhui Zhao 
> > Signed-off-by: Tang Yuantian 
> > Signed-off-by: Wang Dongsheng 
> > ---
> > *v3*
> > - Add "fsl,#rcpm-wakeup-cells" for rcpm node. The number of cells
> >   correspond rcpm-wakeup property.
> > - Modify rcpm-wakeup property description.
> >
> > *v2*
> > - Remove P4080 example.
> > - Modify rcpm-wakeup property description.
> >
> > diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > new file mode 100644
> > index 000..52110ec
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > @@ -0,0 +1,63 @@
> > +* Run Control and Power Management
> > +---
> > +The RCPM performs all device-level tasks associated with device run
> > +control and power management.
> > +
> > +Required properites:
> > +  - reg : Offset and length of the register set of RCPM block.
> > +  - fsl,#rcpm-wakeup-cells : The number of cells in rcpm-wakeup property.
> > +  - compatible : Sould contain a chip-specific RCPM block compatible string
> > +   and (if applicable) may contain a chassis-version RCPM compatible
> > +   string. Chip-specific strings are of the form "fsl,-rcpm",
> > +   such as:
> > +   * "fsl,p2041-rcpm"
> > +   * "fsl,p3041-rcpm"
> > +   * "fsl,p4080-rcpm"
> > +   * "fsl,p5020-rcpm"
> > +   * "fsl,p5040-rcpm"
> > +   * "fsl,t4240-rcpm"
> > +   * "fsl,b4420-rcpm"
> > +   * "fsl,b4860-rcpm"
> > +
> > +   Chassis-version strings are of the form "fsl,qoriq-rcpm-",
> > +   such as:
> > +   * "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
> > +   * "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
> > +   * "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
> > +
> > +All references to "1.0" and "2.0" refer to the QorIQ chassis version
> > +to which the chip complies.
> > +Chassis VersionExample Chips
> > +------
> > +1.0p4080, p5020, p5040, p2041, p3041
> > +2.0t4240, b4860, b4420
> > +2.1t1040, ls1021
> > +
> > +Example:
> > +The RCPM node for T4240:
> > +   rcpm: global-utilities@e2000 {
> > +   compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
> > +   reg = <0xe2000 0x1000>;
> > +   fsl,#rcpm-wakeup-cells = <2>;
> > +   };
> > +
> > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > +---
> > +Required rcpm-wakeup property should be added to a device node if the
> > +device can be used as a wakeup source.
> > +
> > +  - rcpm-wakeup: The value of the property consists of cells, the
> > + number of
> 
> Shouldn't this vendor specific property be prefixed with 'fsl,' as well?
> 

Okay.

> > +   cells defined in "fsl,#rcpm-wakeup-cells". The first cell is a pointer
> > +   to the rcpm node, the second cell is the bit mask that should be set
> > +   in IPPDEXPCR0, and the third cell is for IPPDEXPCR1, and so on.
> 
> I guess that IPPDEXPCR0 and IPPDEXPCR1 need some documentation too, or a 
> pointer
> to hardware documents containing more detailed info about them.
> 

Following the "rcpm-wakeup" documents put a "Note" to describe IPPDEXPCRx 
registers?

Regards,
-Dongsheng 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2] video: fbdev: fsl: Fix the sleep function for FSL DIU module

[Wang Dongsheng]

Hi Tomi,

Could you apply this patch?

> > For deep sleep, the diu module will power off, when wake up from the
> > deep sleep, the registers need to be reinitialized.
> >
> > Signed-off-by: Jason Jin
> > Signed-off-by: Wang Dongsheng
> 
> Acked-by: Timur Tabi 

Regards,
-Dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 04/17] powerpc: mpic: use IRQCHIP_SKIP_SET_WAKE instead of redundant mpic_irq_set_wake

[Wang Dongsheng]

> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Thomas Gleixner
> Sent: Wednesday, September 23, 2015 11:49 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Sudeep Holla; linux...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Rafael J. Wysocki; Benjamin Herrenschmidt; Paul
> Mackerras; Michael Ellerman; Jia Hongtao-B38951; Marc Zyngier; linuxppc-
> d...@lists.ozlabs.org
> Subject: RE: [PATCH 04/17] powerpc: mpic: use IRQCHIP_SKIP_SET_WAKE instead of
> redundant mpic_irq_set_wake
> 
> On Wed, 23 Sep 2015, Wang Dongsheng wrote:
> > > On Mon, 2015-09-21 at 16:47 +0100, Sudeep Holla wrote:
> > > > mpic_irq_set_wake return -ENXIO for non FSL MPIC and sets 
> > > > IRQF_NO_SUSPEND
> > > > flag for FSL ones. enable_irq_wake already returns -ENXIO if irq_set_wak
> > > > is not implemented. Also there's no need to set the IRQF_NO_SUSPEND flag
> > > > as it doesn't guarantee wakeup for that interrupt.
> > > >
> >
> > Non-freescale return -ENXIO, is there any issue? If non-freescale
> > platform does not support it, but IPs still use
> > enable/disable_irq_wake, we should return a error number.
> 
> You can just set IRQCHIP_SKIP_SET_WAKE for FSL chips and not for the
> others.
> 
> > @Scott:
> > If set this flag we cannot keep a irq as a wakeup source when system going 
> > to
> > SUSPEND or MEM.
> >
> > irq_set_wake() means we can set this irq as a wake source.
> > IRQCHIP_SKIP_SET_WAKE is ignore irq_set_wake() feature.
> 
> Nonsense. IRQCHIP_SKIP_SET_WAKE merily tells the core not to bail on
> !chip->irq_set_wake(), but its still marking the interrupt as wakeup
> source and therefor not masking it on suspend.
> 

Sorry, I just check irq_set_irq_wake() code, right, IRQCHIP_SKIP_SET_WAKE also 
can
going to irqd_set to mask IRQD_WAKEUP_STATE.

Yes, this flag just skip the irq_set_wake() not this feature.

Regards,
-Dongsheng

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 04/17] powerpc: mpic: use IRQCHIP_SKIP_SET_WAKE instead of redundant mpic_irq_set_wake

[Wang Dongsheng]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, September 23, 2015 7:50 AM
> To: Sudeep Holla
> Cc: linux...@vger.kernel.org; linux-ker...@vger.kernel.org; Thomas Gleixner;
> Rafael J. Wysocki; Benjamin Herrenschmidt; Paul Mackerras; Michael Ellerman; 
> Jia
> Hongtao-B38951; Marc Zyngier; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-
> B40534
> Subject: Re: [PATCH 04/17] powerpc: mpic: use IRQCHIP_SKIP_SET_WAKE instead of
> redundant mpic_irq_set_wake
> 
> On Mon, 2015-09-21 at 16:47 +0100, Sudeep Holla wrote:
> > mpic_irq_set_wake return -ENXIO for non FSL MPIC and sets IRQF_NO_SUSPEND
> > flag for FSL ones. enable_irq_wake already returns -ENXIO if irq_set_wak
> > is not implemented. Also there's no need to set the IRQF_NO_SUSPEND flag
> > as it doesn't guarantee wakeup for that interrupt.
> >

Non-freescale return -ENXIO, is there any issue? If non-freescale platform does
not support it, but IPs still use enable/disable_irq_wake, we should return a 
error number.

IRQCHIP_SKIP_SET_WAKE just skip this feature, this is not our expected.
If non-freescale platform need this flag to skip this feature, it should be add
in self platform.

@Scott:
If set this flag we cannot keep a irq as a wakeup source when system going to
SUSPEND or MEM.

irq_set_wake() means we can set this irq as a wake source.
IRQCHIP_SKIP_SET_WAKE is ignore irq_set_wake() feature.

Regards,
-Dongsheng

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 1/2] fsl: Add binding for RCPM

[Wang Dongsheng]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, September 16, 2015 12:14 PM
> To: Wang Dongsheng-B40534
> Cc: Tang Yuantian-B29983; devicet...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; robh...@kernel.org; 
> linux-arm-ker...@lists.infradead.org;
> Wang Huan-B18965; Jin Zhengxiong-R64188; Zhao Chenhui-B35336
> Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> 
> On Tue, 2015-09-15 at 22:18 -0500, Wang Dongsheng-B40534 wrote:
> > Hi Scott,
> >
> > > -Original Message-
> > > From: Wang Dongsheng-B40534
> > > Sent: Wednesday, September 16, 2015 10:44 AM
> > > To: Wood Scott-B07421; Tang Yuantian-B29983
> > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-
> > > B18965; Jin
> > > Zhengxiong-R64188; Zhao Chenhui-B35336
> > > Subject: RE: [PATCH v2 1/2] fsl: Add binding for RCPM
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Wednesday, September 16, 2015 10:38 AM
> > > > To: Tang Yuantian-B29983
> > > > Cc: Wang Dongsheng-B40534; devicet...@vger.kernel.org; linuxppc-
> > > > d...@lists.ozlabs.org; robh...@kernel.org;
> > > > linux-arm-ker...@lists.infradead.org;
> > > > Wang Huan-B18965; Jin Zhengxiong-R64188; Zhao Chenhui-B35336
> > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > >
> > > > On Tue, 2015-09-15 at 21:35 -0500, Tang Yuantian-B29983 wrote:
> > > > >
> > > > > > -Original Message-
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Wednesday, September 16, 2015 10:32 AM
> > > > > > To: Wang Dongsheng-B40534 
> > > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang
> > > > > > robh+Huan-
> > > > > > B18965 ; Jin Zhengxiong-R64188
> > > > > > ; Zhao Chenhui-B35336
> > > > > > ; Tang Yuantian-B29983
> > > > > > 
> > > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > > >
> > > > > > On Tue, 2015-09-15 at 21:30 -0500, Wang Dongsheng-B40534 wrote:
> > > > > > > Hi Scott,
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Wood Scott-B07421
> > > > > > > > Sent: Wednesday, September 16, 2015 10:19 AM
> > > > > > > > To: Wang Dongsheng-B40534
> > > > > > > > Cc: devicet...@vger.kernel.org;
> > > > > > > > linuxppc-dev@lists.ozlabs.org;
> > > > > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org;
> > > > > > > > robh+Wang
> > > > > > > > robh+Huan-
> > > > > > > > B18965; Jin
> > > > > > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang
> > > > > > > > Yuantian-B29983
> > > > > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > > > > >
> > > > > > > > On Tue, 2015-09-15 at 21:15 -0500, Wang Dongsheng-B40534 wrote:
> > > > > > > > > Hi Scott,
> > > > > > > > >
> > > > > > > > > > -Original Message-
> > > > > > > > > > From: Wood Scott-B07421
> > > > > > > > > > Sent: Wednesday, September 16, 2015 7:57 AM
> > > > > > > > > > To: Wang Dongsheng-B40534
> > > > > > > > > > Cc: devicet...@vger.kernel.org;
> > > > > > > > > > linuxppc-dev@lists.ozlabs.org;
> > > > > > > > > > robh...@kernel.org;
> > > > > > > > > > robh+linux-arm-ker...@lists.infradead.org;
> > > > > > > > > > robh+Wang
> > > > > > > > > > robh+Huan-
> > > > > > > > > > B18965; Jin
> > > > > > > > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang
> > > > > > > > > > Yuantian-B29983
> > > > > > > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> &

RE: [PATCH v2 1/2] fsl: Add binding for RCPM

[Wang Dongsheng]

Hi Scott,

> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Wednesday, September 16, 2015 10:44 AM
> To: Wood Scott-B07421; Tang Yuantian-B29983
> Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-B18965; 
> Jin
> Zhengxiong-R64188; Zhao Chenhui-B35336
> Subject: RE: [PATCH v2 1/2] fsl: Add binding for RCPM
> 
> 
> 
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, September 16, 2015 10:38 AM
> > To: Tang Yuantian-B29983
> > Cc: Wang Dongsheng-B40534; devicet...@vger.kernel.org; linuxppc-
> > d...@lists.ozlabs.org; robh...@kernel.org;
> > linux-arm-ker...@lists.infradead.org;
> > Wang Huan-B18965; Jin Zhengxiong-R64188; Zhao Chenhui-B35336
> > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> >
> > On Tue, 2015-09-15 at 21:35 -0500, Tang Yuantian-B29983 wrote:
> > >
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Wednesday, September 16, 2015 10:32 AM
> > > > To: Wang Dongsheng-B40534 
> > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang
> > > > robh+Huan-
> > > > B18965 ; Jin Zhengxiong-R64188
> > > > ; Zhao Chenhui-B35336
> > > > ; Tang Yuantian-B29983
> > > > 
> > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > >
> > > > On Tue, 2015-09-15 at 21:30 -0500, Wang Dongsheng-B40534 wrote:
> > > > > Hi Scott,
> > > > >
> > > > > > -Original Message-
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Wednesday, September 16, 2015 10:19 AM
> > > > > > To: Wang Dongsheng-B40534
> > > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang
> > > > > > robh+Huan-
> > > > > > B18965; Jin
> > > > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > > >
> > > > > > On Tue, 2015-09-15 at 21:15 -0500, Wang Dongsheng-B40534 wrote:
> > > > > > > Hi Scott,
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Wood Scott-B07421
> > > > > > > > Sent: Wednesday, September 16, 2015 7:57 AM
> > > > > > > > To: Wang Dongsheng-B40534
> > > > > > > > Cc: devicet...@vger.kernel.org;
> > > > > > > > linuxppc-dev@lists.ozlabs.org;
> > > > > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org;
> > > > > > > > robh+Wang
> > > > > > > > robh+Huan-
> > > > > > > > B18965; Jin
> > > > > > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang
> > > > > > > > Yuantian-B29983
> > > > > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > > > > >
> > > > > > > > On Tue, 2015-09-15 at 16:55 +0800, Dongsheng Wang wrote:
> > > > > > > > > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > > > > > > > > +---
> > > > > > > > > +Required rcpm-wakeup property should be added to a
> > > > > > > > > +device node if the
> > > > > > > > > device
> > > > > > > > > +can be used as a wakeup source.
> > > > > > > > > +
> > > > > > > > > +  - rcpm-wakeup: The value of the property consists of 3 
> > > > > > > > > cells.
> > > > > > > > > + The
> > > > > > > > > first
> > > > > > > > > cell
> > > > > > > > > + is a pointer to the rcpm node, the second cell is
> > > > > > > > > + the bit mask
> > > > > > > > > that
> > > > > > > > > + should be set in IPPDEXPCR0, and the last cell is
> > > > > > > > > + for
> > > > > > > > &

RE: [PATCH v2 1/2] fsl: Add binding for RCPM

[Wang Dongsheng]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, September 16, 2015 10:38 AM
> To: Tang Yuantian-B29983
> Cc: Wang Dongsheng-B40534; devicet...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; robh...@kernel.org; 
> linux-arm-ker...@lists.infradead.org;
> Wang Huan-B18965; Jin Zhengxiong-R64188; Zhao Chenhui-B35336
> Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> 
> On Tue, 2015-09-15 at 21:35 -0500, Tang Yuantian-B29983 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 16, 2015 10:32 AM
> > > To: Wang Dongsheng-B40534 
> > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-
> > > B18965 ; Jin Zhengxiong-R64188
> > > ; Zhao Chenhui-B35336
> > > ; Tang Yuantian-B29983
> > > 
> > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > >
> > > On Tue, 2015-09-15 at 21:30 -0500, Wang Dongsheng-B40534 wrote:
> > > > Hi Scott,
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, September 16, 2015 10:19 AM
> > > > > To: Wang Dongsheng-B40534
> > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-
> > > > > B18965; Jin
> > > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > >
> > > > > On Tue, 2015-09-15 at 21:15 -0500, Wang Dongsheng-B40534 wrote:
> > > > > > Hi Scott,
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Wood Scott-B07421
> > > > > > > Sent: Wednesday, September 16, 2015 7:57 AM
> > > > > > > To: Wang Dongsheng-B40534
> > > > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang
> > > > > > > robh+Huan-
> > > > > > > B18965; Jin
> > > > > > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > > > > > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > > > > > >
> > > > > > > On Tue, 2015-09-15 at 16:55 +0800, Dongsheng Wang wrote:
> > > > > > > > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > > > > > > > +---
> > > > > > > > +Required rcpm-wakeup property should be added to a device
> > > > > > > > +node if the
> > > > > > > > device
> > > > > > > > +can be used as a wakeup source.
> > > > > > > > +
> > > > > > > > +  - rcpm-wakeup: The value of the property consists of 3 cells.
> > > > > > > > + The
> > > > > > > > first
> > > > > > > > cell
> > > > > > > > + is a pointer to the rcpm node, the second cell is the
> > > > > > > > + bit mask
> > > > > > > > that
> > > > > > > > + should be set in IPPDEXPCR0, and the last cell is for
> > > > > > > > IPPDEXPCR1.
> > > > > > > > + Note: If the platform has no IPPDEXPCR1 register, put a
> > > > > > > > + zero
> > > > > > > > here.
> > > > > > >
> > > > > > > What if a future platform has more than two of these registers?
> > > > > >
> > > > > > Those registers are only used for wakeup device, we have a lot of
> > > > > > available bit for feature. For example, In LS1021a platform only
> > > > > > 7bits has used in the registers, and 57bits is reserved.
> > > > >
> > > > > Still, it'd be better to for the rcpm node to advertise the number
> > > > > of cells it expects.
> > > >
> > > > For the foreseeable future it should be enough to use, even if not
> > > > enough to use in the future at that time we can update the binding.
> > >
> > > That's the whole point.  Device tree is stable ABI.  Updating it later to
> > > not be
> > > fixed to two cells would be a lot harder than getting it right from the
> > > beginning.  Putting the number of cells in the phandle target is a
> > > standard
> > > device tree idiom.
> > >
> > I agree with you. But what's the point a SOC has more than 64 wakeup source?
> 
> I don't know.  Hardware people do strange things sometimes.  They might not
> want to reuse bits they once used for something on some other chip, or they
> might have some encoding scheme in mind that results in the bits not being
> packed as tightly as possible, or there may be some big array of similar
> devices...
> 
> What's the point of skipping this part of the phandle-plus-arguments idiom?

Fine, I will add a property in rcpm node to describe the number of register.

Regards,
-Dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 1/2] fsl: Add binding for RCPM

[Wang Dongsheng]

Hi Scott,

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, September 16, 2015 10:19 AM
> To: Wang Dongsheng-B40534
> Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-B18965; 
> Jin
> Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> 
> On Tue, 2015-09-15 at 21:15 -0500, Wang Dongsheng-B40534 wrote:
> > Hi Scott,
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, September 16, 2015 7:57 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-
> > > B18965; Jin
> > > Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> > > Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> > >
> > > On Tue, 2015-09-15 at 16:55 +0800, Dongsheng Wang wrote:
> > > > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > > > +---
> > > > +Required rcpm-wakeup property should be added to a device node if
> > > > +the
> > > > device
> > > > +can be used as a wakeup source.
> > > > +
> > > > +  - rcpm-wakeup: The value of the property consists of 3 cells.
> > > > + The
> > > > first
> > > > cell
> > > > + is a pointer to the rcpm node, the second cell is the bit
> > > > + mask
> > > > that
> > > > + should be set in IPPDEXPCR0, and the last cell is for IPPDEXPCR1.
> > > > + Note: If the platform has no IPPDEXPCR1 register, put a zero here.
> > >
> > > What if a future platform has more than two of these registers?
> >
> > Those registers are only used for wakeup device, we have a lot of
> > available bit for feature. For example, In LS1021a platform only 7bits
> > has used in the registers, and 57bits is reserved.
> 
> Still, it'd be better to for the rcpm node to advertise the number of cells it
> expects.

For the foreseeable future it should be enough to use, even if not enough to 
use in
the future at that time we can update the binding.

Regards,
-Dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 1/2] fsl: Add binding for RCPM

[Wang Dongsheng]

Hi Scott,

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, September 16, 2015 7:57 AM
> To: Wang Dongsheng-B40534
> Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org;
> robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan-B18965; 
> Jin
> Zhengxiong-R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983
> Subject: Re: [PATCH v2 1/2] fsl: Add binding for RCPM
> 
> On Tue, 2015-09-15 at 16:55 +0800, Dongsheng Wang wrote:
> > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > +---
> > +Required rcpm-wakeup property should be added to a device node if the
> > device
> > +can be used as a wakeup source.
> > +
> > +  - rcpm-wakeup: The value of the property consists of 3 cells. The first
> > cell
> > + is a pointer to the rcpm node, the second cell is the bit mask that
> > + should be set in IPPDEXPCR0, and the last cell is for IPPDEXPCR1.
> > + Note: If the platform has no IPPDEXPCR1 register, put a zero here.
> 
> What if a future platform has more than two of these registers?

Those registers are only used for wakeup device, we have a lot of available bit
for feature. For example, In LS1021a platform only 7bits has used in the 
registers,
and 57bits is reserved.

Regards,
-Dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 1/2] fsl: Add binding for RCPM

[Wang Dongsheng]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, September 11, 2015 12:47 AM
> To: Wang Dongsheng-B40534
> Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Jin Zhengxiong-
> R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983; Wang Huan-B18965;
> robh...@kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 1/2] fsl: Add binding for RCPM
> 
> On Wed, 2015-09-09 at 21:03 -0500, Wang Dongsheng-B40534 wrote:
> > Hi Scott,
> >
> > Thanks for your review.
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Thursday, September 10, 2015 3:57 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Jin
> > > Zhengxiong-
> > > R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983; Wang Huan-B18965;
> > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org
> > > Subject: Re: [PATCH 1/2] fsl: Add binding for RCPM
> > >
> > > On Wed, 2015-09-09 at 14:42 +0800, Dongsheng Wang wrote:
> > > > From: Wang Dongsheng 
> > > >
> > > > RCPM is the Run Control and Power Management module performs all
> > > > device-level tasks associated with device run control and power
> > > > management.
> > > >
> > > > Add this for freescale powerpc platform and layerscape platform.
> > > >
> > > > Signed-off-by: Chenhui Zhao 
> > > > Signed-off-by: Tang Yuantian 
> > > > Signed-off-by: Wang Dongsheng 
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > new file mode 100644
> > > > index 000..284070c
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > > > @@ -0,0 +1,64 @@
> > > > +* Run Control and Power Management
> > > > +---
> > > > +The RCPM performs all device-level tasks associated with device
> > > > +run
> > > > control
> > > > +and power management.
> > > > +
> > > > +Required properites:
> > > > +  - reg : Offset and length of the register set of RCPM block.
> > > > +  - compatible : Sould contain a chip-specific RCPM block
> > > > +compatible
> > > > string
> > > > + and (if applicable) may contain a chassis-version RCPM
> > > > + compatible
> > > > string.
> > > > + Chip-specific strings are of the form "fsl,-rcpm", such as:
> > > > + * "fsl,p2041-rcpm"
> > > > + * "fsl,p3041-rcpm"
> > > > + * "fsl,p4080-rcpm"
> > > > + * "fsl,p5020-rcpm"
> > > > + * "fsl,p5040-rcpm"
> > > > + * "fsl,t4240-rcpm"
> > > > + * "fsl,b4420-rcpm"
> > > > + * "fsl,b4860-rcpm"
> > > > +
> > > > + Chassis-version strings are of the form "fsl,qoriq-rcpm-
> > > > ",
> > > > + such as:
> > > > + * "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
> > > > + * "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
> > > > + * "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
> > > > +
> > > > +All references to "1.0" and "2.0" refer to the QorIQ chassis
> > > > +version to which the chip complies.
> > > > +Chassis Version  Example Chips
> > > > +---  ---
> > > > +1.0  p4080, p5020, p5040, p2041, p3041
> > > > +2.0  t4240, b4860, b4420
> > > > +2.1  t1040, ls1021
> > > > +
> > > > +Example:
> > > > +The RCPM node for T4240:
> > > > + rcpm:  global-utilities@e2000{
> > > > + compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
> > > > + reg = <0xe2000 0x1000>;
> > > > + };
> > > > +
> > > > +The RCPM node for P4080:
> > > > + rcpm:  global-utilities@e2000{
> > > > + compatible = "fsl,qoriq-rcpm-1.0";
> > > > + reg = <0xe2000 0x1000>;
> > > > + };
> > >
> > > I would avoid putting the p4080 example in the binding, as we don't
> > > want to make it look like it's OK to leave out the specific chip
> > > compatible.
> > >
> >
> > Fine, I will add the specific chip compatible in this example.
> > compatible = "fsl,p4080-rcpm", "fsl,qoriq-rcpm-1.0";
> 
> Just drop that example.
> 

Thanks.

> > > > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > > > +---
> > > > +Required rcpm-wakeup property should be added to a device node if
> > > > +the
> > > > device
> > > > +can be used as a wakeup source.
> > > > +
> > > > +  - rcpm-wakeup: should contain a pointer to the rcpm node and the
> > > > + corresponding bit of device in the register.
> > >
> > > The corresponding bit in *what* register?
> > >
> >
> > RCPM_IPPDEXPCRx register, I will add a explain to this.
> 
> How do you encode which "x" it is?

Just means IPPDEXPCR0 IPPDEXPCR1.

"&rcpm IPPDEXPCR0 IPPDEXPCR1" will explain "what register" in this property.

Regards,
-Dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 1/2] fsl: Add binding for RCPM

[Wang Dongsheng]

Hi Scott,

Thanks for your review.

> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, September 10, 2015 3:57 AM
> To: Wang Dongsheng-B40534
> Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Jin Zhengxiong-
> R64188; Zhao Chenhui-B35336; Tang Yuantian-B29983; Wang Huan-B18965;
> robh...@kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 1/2] fsl: Add binding for RCPM
> 
> On Wed, 2015-09-09 at 14:42 +0800, Dongsheng Wang wrote:
> > From: Wang Dongsheng 
> >
> > RCPM is the Run Control and Power Management module performs all
> > device-level tasks associated with device run control and power
> > management.
> >
> > Add this for freescale powerpc platform and layerscape platform.
> >
> > Signed-off-by: Chenhui Zhao 
> > Signed-off-by: Tang Yuantian 
> > Signed-off-by: Wang Dongsheng 
> >
> > diff --git a/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > new file mode 100644
> > index 000..284070c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt
> > @@ -0,0 +1,64 @@
> > +* Run Control and Power Management
> > +---
> > +The RCPM performs all device-level tasks associated with device run control
> > +and power management.
> > +
> > +Required properites:
> > +  - reg : Offset and length of the register set of RCPM block.
> > +  - compatible : Sould contain a chip-specific RCPM block compatible string
> > + and (if applicable) may contain a chassis-version RCPM compatible 
> > string.
> > + Chip-specific strings are of the form "fsl,-rcpm", such as:
> > + * "fsl,p2041-rcpm"
> > + * "fsl,p3041-rcpm"
> > + * "fsl,p4080-rcpm"
> > + * "fsl,p5020-rcpm"
> > + * "fsl,p5040-rcpm"
> > + * "fsl,t4240-rcpm"
> > + * "fsl,b4420-rcpm"
> > + * "fsl,b4860-rcpm"
> > +
> > + Chassis-version strings are of the form "fsl,qoriq-rcpm-",
> > + such as:
> > + * "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm
> > + * "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm
> > + * "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm
> > +
> > +All references to "1.0" and "2.0" refer to the QorIQ chassis version to
> > +which the chip complies.
> > +Chassis Version  Example Chips
> > +---  ---
> > +1.0  p4080, p5020, p5040, p2041, p3041
> > +2.0  t4240, b4860, b4420
> > +2.1  t1040, ls1021
> > +
> > +Example:
> > +The RCPM node for T4240:
> > + rcpm:  global-utilities@e2000{
> > + compatible = "fsl,t4240-rcpm", "fsl,qoriq-rcpm-2.0";
> > + reg = <0xe2000 0x1000>;
> > + };
> > +
> > +The RCPM node for P4080:
> > + rcpm:  global-utilities@e2000{
> > + compatible = "fsl,qoriq-rcpm-1.0";
> > + reg = <0xe2000 0x1000>;
> > + };
> 
> I would avoid putting the p4080 example in the binding, as we don't want to
> make it look like it's OK to leave out the specific chip compatible.
> 

Fine, I will add the specific chip compatible in this example.
compatible = "fsl,p4080-rcpm", "fsl,qoriq-rcpm-1.0";

> > +* Freescale RCPM Wakeup Source Device Tree Bindings
> > +---
> > +Required rcpm-wakeup property should be added to a device node if the
> > device
> > +can be used as a wakeup source.
> > +
> > +  - rcpm-wakeup: should contain a pointer to the rcpm node and the
> > + corresponding bit of device in the register.
> 
> The corresponding bit in *what* register?
> 

RCPM_IPPDEXPCRx register, I will add a explain to this.

Regards,
-Dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2] video: fbdev: fsl: Fix the sleep function for FSL DIU module

[Wang Dongsheng]

Thanks Timur.

@Scott,
Could you apply this patch?

Regards,
-Dongsheng

> -Original Message-
> From: Timur Tabi [mailto:ti...@tabi.org]
> Sent: Saturday, August 15, 2015 11:45 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Jin Zhengxiong-R64188; linuxppc-dev@lists.ozlabs.org;
> linux-fb...@vger.kernel.org
> Subject: Re: [PATCH v2] video: fbdev: fsl: Fix the sleep function for FSL DIU
> module
> 
> Dongsheng Wang wrote:
> > For deep sleep, the diu module will power off, when wake up from the
> > deep sleep, the registers need to be reinitialized.
> >
> > Signed-off-by: Jason Jin
> > Signed-off-by: Wang Dongsheng
> 
> Acked-by: Timur Tabi 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 1/2] powerpc/85xx: Add binding for SCFG

[Wang Dongsheng]

Hi Scott,

Could you apply the patches?

Regards,
-Dongsheng

> -Original Message-
> From: Dongsheng Wang [mailto:dongsheng.w...@freescale.com]
> Sent: Friday, August 14, 2015 11:12 AM
> To: Wood Scott-B07421
> Cc: Jain Priyanka-B32167; devicet...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; Wang Dongsheng-B40534
> Subject: [PATCH v2 1/2] powerpc/85xx: Add binding for SCFG
> 
> From: Wang Dongsheng 
> 
> SCFG provides SoC specific configuration and status registers for
> the chip. Add this for powerpc platform.
> 
> Signed-off-by: Wang Dongsheng 
> ---
> *V2*
> - Remove scfg description in board.txt and create scfg.txt for scfg.
> - Change "fsl,-scfg" to "fsl,-scfg"
> 
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/scfg.txt
> b/Documentation/devicetree/bindings/powerpc/fsl/scfg.txt
> new file mode 100644
> index 000..0532c46
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/scfg.txt
> @@ -0,0 +1,18 @@
> +Freescale Supplement configuration unit (SCFG)
> +
> +SCFG is the supplemental configuration unit, that provides SoC specific
> +configuration and status registers for the chip. Such as getting PEX port
> +status.
> +
> +Required properties:
> +
> +- compatible: should be "fsl,-scfg"
> +- reg: should contain base address and length of SCFG memory-mapped
> +registers
> +
> +Example:
> +
> + scfg: global-utilities@fc000 {
> + compatible = "fsl,t1040-scfg";
> + reg = <0xfc000 0x1000>;
> + };
> --
> 2.1.0.27.g96db324

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] video/fsl: Fix the sleep function for FSL DIU module

[Wang Dongsheng]

Hi Tabi,

> -Original Message-
> From: Timur Tabi [mailto:ti...@tabi.org]
> Sent: Tuesday, March 25, 2014 11:55 PM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Jin Zhengxiong-R64188; Li Yang-Leo-R58472; linuxppc-
> d...@lists.ozlabs.org; linux-fb...@vger.kernel.org
> Subject: Re: [PATCH] video/fsl: Fix the sleep function for FSL DIU module
> 
> On 03/25/2014 02:56 AM, Dongsheng Wang wrote:
> > From: Jason Jin 
> >
> > For deep sleep, the diu module will power off, when wake up from the
> > deep sleep, the registers need to be reinitialized.
> >
> > Signed-off-by: Jason Jin 
> > Signed-off-by: Wang Dongsheng 
> >
> > diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
> > index e8758b9..7ec780c 100644
> > --- a/drivers/video/fsl-diu-fb.c
> > +++ b/drivers/video/fsl-diu-fb.c
> > @@ -1628,9 +1628,18 @@ static int fsl_diu_suspend(struct platform_device
> *ofdev, pm_message_t state)
> >   static int fsl_diu_resume(struct platform_device *ofdev)
> >   {
> > struct fsl_diu_data *data;
> > +   struct mfb_info *mfbi;
> 
> You don't need this, if ...
> 
> > +   int i;
> >
> > data = dev_get_drvdata(&ofdev->dev);
> > -   enable_lcdc(data->fsl_diu_info);
> > +   fsl_diu_enable_interrupts(data);
> > +   update_lcdc(data->fsl_diu_info);
> > +
> > +   for (i = 0; i < NUM_AOIS; i++) {
> > +   mfbi = &data->mfb[i];
> > +   if (mfbi->count)
> 
> ... you do this:
> 
>   if (data->mfb[i].count)
> 
> Also, 'i' should be an 'unsigned int'.
> 
> > +   fsl_diu_enable_panel(&data->fsl_diu_info[i]);
> > +   }
> >
> > return 0;
> >   }
> >
> 
> Other than that, this seems okay.
> 

Thanks, send v2 to update this patch.

Regards,
-Dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [RESEND] powerpc/diu: adjust DIU initialization entry

[Wang Dongsheng]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 08, 2015 10:48 AM
> To: Wang Dongsheng-B40534
> Cc: Sun York-R58495; linuxppc-dev@lists.ozlabs.org; Jin Zhengxiong-R64188
> Subject: Re: [RESEND] powerpc/diu: adjust DIU initialization entry
> 
> On Tue, 2015-07-07 at 21:46 -0500, Wang Dongsheng-B40534 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, July 08, 2015 10:41 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Sun York-R58495; linuxppc-dev@lists.ozlabs.org; Jin
> > > Zhengxiong-R64188
> > > Subject: Re: [RESEND] powerpc/diu: adjust DIU initialization entry
> > >
> > > On Tue, 2015-07-07 at 21:30 -0500, Wang Dongsheng-B40534 wrote:
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, July 08, 2015 5:51 AM
> > > > > To: Wang Dongsheng-B40534
> > > > > Cc: Sun York-R58495; linuxppc-dev@lists.ozlabs.org; Jin
> > > > > Zhengxiong-R64188
> > > > > Subject: Re: [RESEND] powerpc/diu: adjust DIU initialization
> > > > > entry
> > > > >
> > > > > On Tue, 2015-07-07 at 15:51 +0800, Dongsheng Wang wrote:
> > > > > > From: Wang Dongsheng 
> > > > > >
> > > > > > Move fsl_diu_init into diu probe function, because it should
> > > > > > be initialized when system get diu device tree node, not
> > > > > > always do initialization.
> > > > > >
> > > > > > Signed-off-by: Wang Dongsheng 
> > > > > > ---
> > > > > > Changes:
> > > > > > Rebase original patch for upstream because fsl-diu-fb.c has
> > > > > > moved to fbdev dir.
> > > > > >
> > > > > > This patch is a long time ago, there is no feedback, and the
> > > > > > Patchwork state has been modified for the changes requested, I
> > > > > > don't know
> > > why.
> > > > > > So I resend this patch to upstream.
> > > > >
> > > > > Please send this to the proper list and maintainer, and with a
> > > > > subject prefix that indicates it's an fbdev patch.
> > > > >
> > > > Thanks.
> > > >
> > > > I will send this patch to linux-fb...@vger.kernel.org.
> > > >
> > > > Please ignore this patch.
> > >
> > > You still didn't fix the subject line...
> > >
> >
> > The DIU belongs to the POWERPC,
> 
> No, it doesn't belong to arch/powerpc, it belongs to drivers/video/fbdev.
> 
> >  need I fix this? fbdev/diu?
> 
> "video: fbdev: fsl-diu:" seems to be the style that subtree uses.

Fix it in next version. Please comment in my new patch, I will fix it.

Regards,
-Dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [RESEND] powerpc/diu: adjust DIU initialization entry

[Wang Dongsheng]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 08, 2015 10:41 AM
> To: Wang Dongsheng-B40534
> Cc: Sun York-R58495; linuxppc-dev@lists.ozlabs.org; Jin Zhengxiong-R64188
> Subject: Re: [RESEND] powerpc/diu: adjust DIU initialization entry
> 
> On Tue, 2015-07-07 at 21:30 -0500, Wang Dongsheng-B40534 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, July 08, 2015 5:51 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Sun York-R58495; linuxppc-dev@lists.ozlabs.org; Jin
> > > Zhengxiong-R64188
> > > Subject: Re: [RESEND] powerpc/diu: adjust DIU initialization entry
> > >
> > > On Tue, 2015-07-07 at 15:51 +0800, Dongsheng Wang wrote:
> > > > From: Wang Dongsheng 
> > > >
> > > > Move fsl_diu_init into diu probe function, because it should be
> > > > initialized when system get diu device tree node, not always do
> > > > initialization.
> > > >
> > > > Signed-off-by: Wang Dongsheng 
> > > > ---
> > > > Changes:
> > > > Rebase original patch for upstream because fsl-diu-fb.c has moved
> > > > to fbdev dir.
> > > >
> > > > This patch is a long time ago, there is no feedback, and the
> > > > Patchwork state has been modified for the changes requested, I don't 
> > > > know
> why.
> > > > So I resend this patch to upstream.
> > >
> > > Please send this to the proper list and maintainer, and with a
> > > subject prefix that indicates it's an fbdev patch.
> > >
> > Thanks.
> >
> > I will send this patch to linux-fb...@vger.kernel.org.
> >
> > Please ignore this patch.
> 
> You still didn't fix the subject line...
> 

The DIU belongs to the POWERPC, need I fix this? fbdev/diu?

Regards,
-Dongsheng

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [RESEND] powerpc/diu: adjust DIU initialization entry

[Wang Dongsheng]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 08, 2015 5:51 AM
> To: Wang Dongsheng-B40534
> Cc: Sun York-R58495; linuxppc-dev@lists.ozlabs.org; Jin Zhengxiong-R64188
> Subject: Re: [RESEND] powerpc/diu: adjust DIU initialization entry
> 
> On Tue, 2015-07-07 at 15:51 +0800, Dongsheng Wang wrote:
> > From: Wang Dongsheng 
> >
> > Move fsl_diu_init into diu probe function, because it should be
> > initialized when system get diu device tree node, not always do
> > initialization.
> >
> > Signed-off-by: Wang Dongsheng 
> > ---
> > Changes:
> > Rebase original patch for upstream because fsl-diu-fb.c has moved to
> > fbdev dir.
> >
> > This patch is a long time ago, there is no feedback, and the Patchwork
> > state has been modified for the changes requested, I don't know why.
> > So I resend this patch to upstream.
> 
> Please send this to the proper list and maintainer, and with a subject prefix
> that indicates it's an fbdev patch.
> 
Thanks.

I will send this patch to linux-fb...@vger.kernel.org.

Please ignore this patch.

Regards,
-Dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Saturday, October 19, 2013 3:23 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> 
> On Thu, 2013-10-17 at 21:36 -0500, Wang Dongsheng-B40534 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Friday, October 18, 2013 12:52 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> > > d...@lists.ozlabs.org
> > > Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
> > > and altivec idle
> > >
> > > On Thu, 2013-10-17 at 00:51 -0500, Wang Dongsheng-B40534 wrote:
> > > >
> > > > > -Original Message-
> > > > > From: Bhushan Bharat-R65777
> > > > > Sent: Thursday, October 17, 2013 11:20 AM
> > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > state and altivec idle
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Wang Dongsheng-B40534
> > > > > > Sent: Thursday, October 17, 2013 8:16 AM
> > > > > > To: Bhushan Bharat-R65777; Wood Scott-B07421
> > > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > state and altivec idle
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Bhushan Bharat-R65777
> > > > > > > Sent: Thursday, October 17, 2013 1:01 AM
> > > > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > > state and altivec idle
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Wang Dongsheng-B40534
> > > > > > > > Sent: Tuesday, October 15, 2013 2:51 PM
> > > > > > > > To: Wood Scott-B07421
> > > > > > > > Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org;
> > > > > > > > Wang
> > > > > > > Dongsheng-B40534
> > > > > > > > Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > > > state and
> > > > > > > altivec idle
> > > > > > > >
> > > > > > > > +static ssize_t show_pw20_wait_time(struct device *dev,
> > > > > > > > +   struct device_attribute *attr, 
> > > > > > > > char
> *buf) {
> > > > > > > > +   u32 value;
> > > > > > > > +   u64 tb_cycle;
> > > > > > > > +   s64 time;
> > > > > > > > +
> > > > > > > > +   unsigned int cpu = dev->id;
> > > > > > > > +
> > > > > > > > +   if (!pw20_wt) {
> > > > > > > > +   smp_call_function_single(cpu, do_show_pwrmgtcr0,
> > > > > > > > +&value,
> > > > > 1);
> > > > > > > > +   value = (value & PWRMGTCR0_PW20_ENT) >>
> > > > > > > > +   
> > > > > > > > PWRMGTCR0_PW20_ENT_SHIFT;
> > > > > > > > +
> > > > > > > > +   tb_cycle = (1 << (MAX_BIT - value)) * 2;
> > > > > > >
> > > > > > > Is value = 0 and value = 1 legal? These will make tb_cycle =
> > > > > > > 0,
> > > > > > >
> > > > > > > > +   time = div_u64(tb_cycle * 1000, 
> > > > > > > > tb_ticks_per_usec)
> - 1;
> > > > > > >
> > > > > > > And time = 

RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Saturday, October 19, 2013 3:22 AM
> To: Wang Dongsheng-B40534
> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> 
> On Thu, 2013-10-17 at 22:02 -0500, Wang Dongsheng-B40534 wrote:
> >
> > > -Original Message-
> > > From: Bhushan Bharat-R65777
> > > Sent: Thursday, October 17, 2013 2:46 PM
> > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > Cc: linuxppc-dev@lists.ozlabs.org
> > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
> > > and altivec idle
> > >
> > >
> > >
> > > > > > -Original Message-
> > > > > > From: Wang Dongsheng-B40534
> > > > > > Sent: Thursday, October 17, 2013 11:22 AM
> > > > > > To: Bhushan Bharat-R65777; Wood Scott-B07421
> > > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > state and altivec idle
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Bhushan Bharat-R65777
> > > > > > > Sent: Thursday, October 17, 2013 11:20 AM
> > > > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > > state and altivec idle
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Wang Dongsheng-B40534
> > > > > > > > Sent: Thursday, October 17, 2013 8:16 AM
> > > > > > > > To: Bhushan Bharat-R65777; Wood Scott-B07421
> > > > > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for
> > > > > > > > pw20 state and altivec idle
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -Original Message-
> > > > > > > > > From: Bhushan Bharat-R65777
> > > > > > > > > Sent: Thursday, October 17, 2013 1:01 AM
> > > > > > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for
> > > > > > > > > pw20 state and altivec idle
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > -Original Message-
> > > > > > > > > > From: Wang Dongsheng-B40534
> > > > > > > > > > Sent: Tuesday, October 15, 2013 2:51 PM
> > > > > > > > > > To: Wood Scott-B07421
> > > > > > > > > > Cc: Bhushan Bharat-R65777;
> > > > > > > > > > linuxppc-dev@lists.ozlabs.org; Wang
> > > > > > > > > Dongsheng-B40534
> > > > > > > > > > Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for
> > > > > > > > > > pw20 state and
> > > > > > > > > altivec idle
> > > > > > > > > >
> > > > > > > > > > From: Wang Dongsheng 
> > > > > > > > > >
> > > > > > > > > > Add a sys interface to enable/diable pw20 state or
> > > > > > > > > > altivec idle, and
> > > > > > > > > control the
> > > > > > > > > > wait entry time.
> > > > > > > > > >
> > > > > > > > > > Enable/Disable interface:
> > > > > > > > > > 0, disable. 1, enable.
> > > > > > > > > > /sys/devices/system/cpu/cpuX/pw20_state
> > > > > > > > > > /sys/devices/system/cpu/cpuX/altivec_idle
> &g

RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

[Wang Dongsheng-B40534]

> -Original Message-
> From: Bhushan Bharat-R65777
> Sent: Thursday, October 17, 2013 2:46 PM
> To: Wang Dongsheng-B40534; Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> 
> 
> 
> > > > -----Original Message-
> > > > From: Wang Dongsheng-B40534
> > > > Sent: Thursday, October 17, 2013 11:22 AM
> > > > To: Bhushan Bharat-R65777; Wood Scott-B07421
> > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > and altivec idle
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Bhushan Bharat-R65777
> > > > > Sent: Thursday, October 17, 2013 11:20 AM
> > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > state and altivec idle
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Wang Dongsheng-B40534
> > > > > > Sent: Thursday, October 17, 2013 8:16 AM
> > > > > > To: Bhushan Bharat-R65777; Wood Scott-B07421
> > > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > state and altivec idle
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Bhushan Bharat-R65777
> > > > > > > Sent: Thursday, October 17, 2013 1:01 AM
> > > > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > > state and altivec idle
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Wang Dongsheng-B40534
> > > > > > > > Sent: Tuesday, October 15, 2013 2:51 PM
> > > > > > > > To: Wood Scott-B07421
> > > > > > > > Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org;
> > > > > > > > Wang
> > > > > > > Dongsheng-B40534
> > > > > > > > Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > > > state and
> > > > > > > altivec idle
> > > > > > > >
> > > > > > > > From: Wang Dongsheng 
> > > > > > > >
> > > > > > > > Add a sys interface to enable/diable pw20 state or altivec
> > > > > > > > idle, and
> > > > > > > control the
> > > > > > > > wait entry time.
> > > > > > > >
> > > > > > > > Enable/Disable interface:
> > > > > > > > 0, disable. 1, enable.
> > > > > > > > /sys/devices/system/cpu/cpuX/pw20_state
> > > > > > > > /sys/devices/system/cpu/cpuX/altivec_idle
> > > > > > > >
> > > > > > > > Set wait time interface:(Nanosecond)
> > > > > > > > /sys/devices/system/cpu/cpuX/pw20_wait_time
> > > > > > > > /sys/devices/system/cpu/cpuX/altivec_idle_wait_time
> > > > > > > > Example: Base on TBfreq is 41MHZ.
> > > > > > > > 1~48(ns): TB[63]
> > > > > > > > 49~97(ns): TB[62]
> > > > > > > > 98~195(ns): TB[61]
> > > > > > > > 196~390(ns): TB[60]
> > > > > > > > 391~780(ns): TB[59]
> > > > > > > > 781~1560(ns): TB[58]
> > > > > > > > ...
> > > > > > > >
> > > > > > > > Signed-off-by: Wang Dongsheng
> > > > > > > > 
> > > > > > > > ---
> > > > > > > > *v5:
> > > > > > > > Change get_idle_ticks_bit function implementation.
> > > > > > > >
> > >

RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, October 18, 2013 12:52 AM
> To: Wang Dongsheng-B40534
> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> 
> On Thu, 2013-10-17 at 00:51 -0500, Wang Dongsheng-B40534 wrote:
> >
> > > -Original Message-
> > > From: Bhushan Bharat-R65777
> > > Sent: Thursday, October 17, 2013 11:20 AM
> > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > Cc: linuxppc-dev@lists.ozlabs.org
> > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
> > > and altivec idle
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Wang Dongsheng-B40534
> > > > Sent: Thursday, October 17, 2013 8:16 AM
> > > > To: Bhushan Bharat-R65777; Wood Scott-B07421
> > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > and altivec idle
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Bhushan Bharat-R65777
> > > > > Sent: Thursday, October 17, 2013 1:01 AM
> > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > state and altivec idle
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Wang Dongsheng-B40534
> > > > > > Sent: Tuesday, October 15, 2013 2:51 PM
> > > > > > To: Wood Scott-B07421
> > > > > > Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org; Wang
> > > > > Dongsheng-B40534
> > > > > > Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > > > and
> > > > > altivec idle
> > > > > >
> > > > > > +static ssize_t show_pw20_wait_time(struct device *dev,
> > > > > > +   struct device_attribute *attr, char 
> > > > > > *buf) {
> > > > > > +   u32 value;
> > > > > > +   u64 tb_cycle;
> > > > > > +   s64 time;
> > > > > > +
> > > > > > +   unsigned int cpu = dev->id;
> > > > > > +
> > > > > > +   if (!pw20_wt) {
> > > > > > +   smp_call_function_single(cpu, do_show_pwrmgtcr0, &value,
> > > 1);
> > > > > > +   value = (value & PWRMGTCR0_PW20_ENT) >>
> > > > > > +   PWRMGTCR0_PW20_ENT_SHIFT;
> > > > > > +
> > > > > > +   tb_cycle = (1 << (MAX_BIT - value)) * 2;
> > > > >
> > > > > Is value = 0 and value = 1 legal? These will make tb_cycle = 0,
> > > > >
> > > > > > +   time = div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
> > > > >
> > > > > And time = -1;
> > > > >
> > > > Please look at the end of the function, :)
> > > >
> > > > "return sprintf(buf, "%llu\n", time > 0 ? time : 0);"
> > >
> > > I know you return 0 if value = 0/1, my question was that, is this
> > > correct as per specification?
> > >
> > > Ahh, also for "value" upto 7 you will return 0, no?
> > >
> > If value = 0, MAX_BIT - value = 63
> > tb_cycle = 0x_,
> 
> Actually, tb_cycle will be undefined because you shifted a 32-bit value
> (1) by more than 31 bits.  s/1/1ULL/
> 
Actually, we have been discussing this situation that could not have happened.
See !pw20_wt branch, this branch is read default wait bit.
The default wait bit is 50, the time is about 1ms.
The default wait bit cannot less than 50, means the wait entry time cannot 
greater than 1ms.
We have already begun benchmark test, and we got a preliminary results.
55, 56, 57bit looks good, but we need more benchmark to get the default bit.

if (!pw20_wt) {
smp_call_function_single(cpu, do_show_pwrmgtcr0, &value, 1);
value = (value & PWRMGTCR0_PW20_ENT) >>
PWRMGTCR0_PW20_ENT_SHIFT;

tb_cycle = (1 << (MAX_BIT - value)) * 2;
time = div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
} else {
time = pw20_wt;
}

If it caused confusion, we can add a comment. As I discuss with Bharat.

> > tb_cycle * 1000 will overflow, but this situation is not possible.
> > Because if the "value = 0" means this feature will be "disable".
> > Now The default wait bit is 50(MAX_BIT - value, value = 13), the
> > PW20/Altivec Idle wait entry time is about 1ms, this time is very long
> > for wait idle time, and it's cannot be increased(means (MAX_BIT -
> > value) cannot greater than 50).
> 
> Why can it not be increased?
>
see above, :)

-dongsheng
> -Scott
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

[Wang Dongsheng-B40534]

> -Original Message-
> From: Bhushan Bharat-R65777
> Sent: Thursday, October 17, 2013 2:00 PM
> To: Wang Dongsheng-B40534; Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> 
> 
> 
> > -Original Message-
> > From: Wang Dongsheng-B40534
> > Sent: Thursday, October 17, 2013 11:22 AM
> > To: Bhushan Bharat-R65777; Wood Scott-B07421
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
> > altivec idle
> >
> >
> >
> > > -Original Message-----
> > > From: Bhushan Bharat-R65777
> > > Sent: Thursday, October 17, 2013 11:20 AM
> > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > Cc: linuxppc-dev@lists.ozlabs.org
> > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
> > > and altivec idle
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Wang Dongsheng-B40534
> > > > Sent: Thursday, October 17, 2013 8:16 AM
> > > > To: Bhushan Bharat-R65777; Wood Scott-B07421
> > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > and altivec idle
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Bhushan Bharat-R65777
> > > > > Sent: Thursday, October 17, 2013 1:01 AM
> > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20
> > > > > state and altivec idle
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Wang Dongsheng-B40534
> > > > > > Sent: Tuesday, October 15, 2013 2:51 PM
> > > > > > To: Wood Scott-B07421
> > > > > > Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org; Wang
> > > > > Dongsheng-B40534
> > > > > > Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > > > and
> > > > > altivec idle
> > > > > >
> > > > > > From: Wang Dongsheng 
> > > > > >
> > > > > > Add a sys interface to enable/diable pw20 state or altivec
> > > > > > idle, and
> > > > > control the
> > > > > > wait entry time.
> > > > > >
> > > > > > Enable/Disable interface:
> > > > > > 0, disable. 1, enable.
> > > > > > /sys/devices/system/cpu/cpuX/pw20_state
> > > > > > /sys/devices/system/cpu/cpuX/altivec_idle
> > > > > >
> > > > > > Set wait time interface:(Nanosecond)
> > > > > > /sys/devices/system/cpu/cpuX/pw20_wait_time
> > > > > > /sys/devices/system/cpu/cpuX/altivec_idle_wait_time
> > > > > > Example: Base on TBfreq is 41MHZ.
> > > > > > 1~48(ns): TB[63]
> > > > > > 49~97(ns): TB[62]
> > > > > > 98~195(ns): TB[61]
> > > > > > 196~390(ns): TB[60]
> > > > > > 391~780(ns): TB[59]
> > > > > > 781~1560(ns): TB[58]
> > > > > > ...
> > > > > >
> > > > > > Signed-off-by: Wang Dongsheng 
> > > > > > ---
> > > > > > *v5:
> > > > > > Change get_idle_ticks_bit function implementation.
> > > > > >
> > > > > > *v4:
> > > > > > Move code from 85xx/common.c to kernel/sysfs.c.
> > > > > >
> > > > > > Remove has_pw20_altivec_idle function.
> > > > > >
> > > > > > Change wait "entry_bit" to wait time.
> > > > > >
> > > > > > diff --git a/arch/powerpc/kernel/sysfs.c
> > > > > > b/arch/powerpc/kernel/sysfs.c
> > > > > index
> > > > > > 27a90b9..10d1128 100644
> > > > > > --- a/arch/powerpc/kernel/sysfs.c
> > > > > > +++ b/arch/powerpc/kernel/sysfs.c
> > > > > > @@ -85,6 +85,284 @@ __setup("smt-snooze-delay=",
> > > > > setup_smt_snooze_delay);
> > > > > >
> > > 

RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

[Wang Dongsheng-B40534]

> -Original Message-
> From: Bhushan Bharat-R65777
> Sent: Thursday, October 17, 2013 11:20 AM
> To: Wang Dongsheng-B40534; Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> 
> 
> 
> > -Original Message-
> > From: Wang Dongsheng-B40534
> > Sent: Thursday, October 17, 2013 8:16 AM
> > To: Bhushan Bharat-R65777; Wood Scott-B07421
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
> > altivec idle
> >
> >
> >
> > > -Original Message-----
> > > From: Bhushan Bharat-R65777
> > > Sent: Thursday, October 17, 2013 1:01 AM
> > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > Cc: linuxppc-dev@lists.ozlabs.org
> > > Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state
> > > and altivec idle
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Wang Dongsheng-B40534
> > > > Sent: Tuesday, October 15, 2013 2:51 PM
> > > > To: Wood Scott-B07421
> > > > Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org; Wang
> > > Dongsheng-B40534
> > > > Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
> > > altivec idle
> > > >
> > > > From: Wang Dongsheng 
> > > >
> > > > Add a sys interface to enable/diable pw20 state or altivec idle,
> > > > and
> > > control the
> > > > wait entry time.
> > > >
> > > > Enable/Disable interface:
> > > > 0, disable. 1, enable.
> > > > /sys/devices/system/cpu/cpuX/pw20_state
> > > > /sys/devices/system/cpu/cpuX/altivec_idle
> > > >
> > > > Set wait time interface:(Nanosecond)
> > > > /sys/devices/system/cpu/cpuX/pw20_wait_time
> > > > /sys/devices/system/cpu/cpuX/altivec_idle_wait_time
> > > > Example: Base on TBfreq is 41MHZ.
> > > > 1~48(ns): TB[63]
> > > > 49~97(ns): TB[62]
> > > > 98~195(ns): TB[61]
> > > > 196~390(ns): TB[60]
> > > > 391~780(ns): TB[59]
> > > > 781~1560(ns): TB[58]
> > > > ...
> > > >
> > > > Signed-off-by: Wang Dongsheng 
> > > > ---
> > > > *v5:
> > > > Change get_idle_ticks_bit function implementation.
> > > >
> > > > *v4:
> > > > Move code from 85xx/common.c to kernel/sysfs.c.
> > > >
> > > > Remove has_pw20_altivec_idle function.
> > > >
> > > > Change wait "entry_bit" to wait time.
> > > >
> > > > diff --git a/arch/powerpc/kernel/sysfs.c
> > > > b/arch/powerpc/kernel/sysfs.c
> > > index
> > > > 27a90b9..10d1128 100644
> > > > --- a/arch/powerpc/kernel/sysfs.c
> > > > +++ b/arch/powerpc/kernel/sysfs.c
> > > > @@ -85,6 +85,284 @@ __setup("smt-snooze-delay=",
> > > setup_smt_snooze_delay);
> > > >
> > > >  #endif /* CONFIG_PPC64 */
> > > >
> > > > +#ifdef CONFIG_FSL_SOC
> > > > +#define MAX_BIT63
> > > > +
> > > > +static u64 pw20_wt;
> > > > +static u64 altivec_idle_wt;
> > > > +
> > > > +static unsigned int get_idle_ticks_bit(u64 ns) {
> > > > +   u64 cycle;
> > > > +
> > > > +   if (ns >= 1)
> > > > +   cycle = div_u64(ns + 500, 1000) * tb_ticks_per_usec;
> > > > +   else
> > > > +   cycle = div_u64(ns * tb_ticks_per_usec, 1000);
> > > > +
> > > > +   if (!cycle)
> > > > +   return 0;
> > > > +
> > > > +   return ilog2(cycle);
> > > > +}
> > > > +
> > > > +static void do_show_pwrmgtcr0(void *val) {
> > > > +   u32 *value = val;
> > > > +
> > > > +   *value = mfspr(SPRN_PWRMGTCR0);
> > > > +}
> > > > +
> > > > +static ssize_t show_pw20_state(struct device *dev,
> > > > +   struct device_attribute *attr, char 
> > > > *buf) {
> > > > +   u32 value;
> > > > +   unsigned int cpu = dev->id;
> > > > +
> > > > +   smp_call_function_single(cpu, do_show_p

RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

[Wang Dongsheng-B40534]

> -Original Message-
> From: Bhushan Bharat-R65777
> Sent: Thursday, October 17, 2013 1:01 AM
> To: Wang Dongsheng-B40534; Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> 
> 
> 
> > -Original Message-
> > From: Wang Dongsheng-B40534
> > Sent: Tuesday, October 15, 2013 2:51 PM
> > To: Wood Scott-B07421
> > Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org; Wang
> Dongsheng-B40534
> > Subject: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> >
> > From: Wang Dongsheng 
> >
> > Add a sys interface to enable/diable pw20 state or altivec idle, and
> control the
> > wait entry time.
> >
> > Enable/Disable interface:
> > 0, disable. 1, enable.
> > /sys/devices/system/cpu/cpuX/pw20_state
> > /sys/devices/system/cpu/cpuX/altivec_idle
> >
> > Set wait time interface:(Nanosecond)
> > /sys/devices/system/cpu/cpuX/pw20_wait_time
> > /sys/devices/system/cpu/cpuX/altivec_idle_wait_time
> > Example: Base on TBfreq is 41MHZ.
> > 1~48(ns): TB[63]
> > 49~97(ns): TB[62]
> > 98~195(ns): TB[61]
> > 196~390(ns): TB[60]
> > 391~780(ns): TB[59]
> > 781~1560(ns): TB[58]
> > ...
> >
> > Signed-off-by: Wang Dongsheng 
> > ---
> > *v5:
> > Change get_idle_ticks_bit function implementation.
> >
> > *v4:
> > Move code from 85xx/common.c to kernel/sysfs.c.
> >
> > Remove has_pw20_altivec_idle function.
> >
> > Change wait "entry_bit" to wait time.
> >
> > diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
> index
> > 27a90b9..10d1128 100644
> > --- a/arch/powerpc/kernel/sysfs.c
> > +++ b/arch/powerpc/kernel/sysfs.c
> > @@ -85,6 +85,284 @@ __setup("smt-snooze-delay=",
> setup_smt_snooze_delay);
> >
> >  #endif /* CONFIG_PPC64 */
> >
> > +#ifdef CONFIG_FSL_SOC
> > +#define MAX_BIT63
> > +
> > +static u64 pw20_wt;
> > +static u64 altivec_idle_wt;
> > +
> > +static unsigned int get_idle_ticks_bit(u64 ns) {
> > +   u64 cycle;
> > +
> > +   if (ns >= 1)
> > +   cycle = div_u64(ns + 500, 1000) * tb_ticks_per_usec;
> > +   else
> > +   cycle = div_u64(ns * tb_ticks_per_usec, 1000);
> > +
> > +   if (!cycle)
> > +   return 0;
> > +
> > +   return ilog2(cycle);
> > +}
> > +
> > +static void do_show_pwrmgtcr0(void *val) {
> > +   u32 *value = val;
> > +
> > +   *value = mfspr(SPRN_PWRMGTCR0);
> > +}
> > +
> > +static ssize_t show_pw20_state(struct device *dev,
> > +   struct device_attribute *attr, char *buf) {
> > +   u32 value;
> > +   unsigned int cpu = dev->id;
> > +
> > +   smp_call_function_single(cpu, do_show_pwrmgtcr0, &value, 1);
> > +
> > +   value &= PWRMGTCR0_PW20_WAIT;
> > +
> > +   return sprintf(buf, "%u\n", value ? 1 : 0); }
> > +
> > +static void do_store_pw20_state(void *val) {
> > +   u32 *value = val;
> > +   u32 pw20_state;
> > +
> > +   pw20_state = mfspr(SPRN_PWRMGTCR0);
> > +
> > +   if (*value)
> > +   pw20_state |= PWRMGTCR0_PW20_WAIT;
> > +   else
> > +   pw20_state &= ~PWRMGTCR0_PW20_WAIT;
> > +
> > +   mtspr(SPRN_PWRMGTCR0, pw20_state);
> > +}
> > +
> > +static ssize_t store_pw20_state(struct device *dev,
> > +   struct device_attribute *attr,
> > +   const char *buf, size_t count)
> > +{
> > +   u32 value;
> > +   unsigned int cpu = dev->id;
> > +
> > +   if (kstrtou32(buf, 0, &value))
> > +   return -EINVAL;
> > +
> > +   if (value > 1)
> > +   return -EINVAL;
> > +
> > +   smp_call_function_single(cpu, do_store_pw20_state, &value, 1);
> > +
> > +   return count;
> > +}
> > +
> > +static ssize_t show_pw20_wait_time(struct device *dev,
> > +   struct device_attribute *attr, char *buf) {
> > +   u32 value;
> > +   u64 tb_cycle;
> > +   s64 time;
> > +
> > +   unsigned int cpu = dev->id;
> > +
> > +   if (!pw20_wt) {
> > +   smp_call_function_single(cpu, do_show_pwrmgtcr0, &value, 1);
> > +   value = (value & PWRMGTCR0_PW20_ENT) >>
> > +   PWRMGTCR0_PW20_ENT_SHIFT;
> > +
> > +   tb_cycle = (1 << (MAX_BIT - value)) * 2;
> 
> Is value = 0 and value = 1 legal? These will make tb_cycle = 0,
> 
> > +   time = div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
> 
> And time = -1;
> 
Please look at the end of the function, :)

"return sprintf(buf, "%llu\n", time > 0 ? time : 0);"

-dongsheng

> 
> > +   } else {
> > +   time = pw20_wt;
> > +   }
> > +
> > +   return sprintf(buf, "%llu\n", time > 0 ? time : 0);
> > }
> > +


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, October 08, 2013 10:50 PM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> 
> On Mon, 2013-10-07 at 22:58 -0500, Wang Dongsheng-B40534 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, October 01, 2013 7:06 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc-
> > > d...@lists.ozlabs.org
> > > Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
> and
> > > altivec idle
> > >
> > > On Sun, 2013-09-29 at 01:57 -0500, Wang Dongsheng-B40534 wrote:
> > > > I think we need to do this:
> > > >
> > > > #define U64_LOW_MASK0xULL
> > > > #define U64_MASK0xULL
> > > >
> > > > u32 tmp_rem;
> > > > u64 ns_u_rem, ns_u, ns_l, ns_l_carry;
> > > > u64 cycle;
> > > >
> > > > ns_u = ns >> 32;
> > > > ns_l = ns & U64_LOW_MASK;
> > > >
> > > > ns_l *= tb_ticks_per_usec;
> > > > ns_l_carry = ns_l >> 32;
> > > > ns_u *= tb_ticks_per_usec;
> > > > ns_u += ns_l_carry;
> > > >
> > > > ns_u = div_u64_rem(ns_u, 1000, &tmp_rem);
> > > > ns_u_rem = tmp_rem;
> > > > ns_l = (ns_l & U64_LOW_MASK) | ((ns_u_rem) << 32);
> > > > ns_l = div_u64(ns_l, 1000);
> > > >
> > > > if (ns_u >> 32)
> > > > cycle = U64_MASK;
> > > > else
> > > > cycle = (ns_u << 32) | (ns_l & U64_LOW_MASK);
> > > >
> > > > I has already tested this code, and works good. :)
> > >
> > > Ugh.  I don't think we need to get this complicated (and I'd rather
> not
> > > spend the time verifying the correctness of this).
> > >
> > > If for some reason we did need something like this in some other
> context
> > > (I don't want to see it just for pw20), I'd be more inclined to see
> > > general 128-bit mult/divide support.
> > >
> > I would like to use my version,:), because it can handle any situation
> and we do not need to restrict users.
> 
> It also would take more time to review than I have to spend on it, not
> to mention the impact on anyone in the future that wants to understand
> or maintain this code -- all for very unlikely situations (and the
> "failure" in those very unlikely situations is just that we go into PW20
> more often than intended).
> 
OK, I will use your verison, :)

if (ns >= 1)
cycle = ((ns + 500) / 1000) * tb_ticks_per_usec;
else
cycle = div_u64((u64)ns * tb_ticks_per_usec, 1000);

-dongsheng

> -Scott
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, October 01, 2013 7:06 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> 
> On Sun, 2013-09-29 at 01:57 -0500, Wang Dongsheng-B40534 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Saturday, September 28, 2013 5:33 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc-
> > > d...@lists.ozlabs.org
> > > Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
> > > and altivec idle
> > >
> > > On Thu, 2013-09-26 at 22:34 -0500, Wang Dongsheng-B40534 wrote:
> > > > cycle = div_u64(ns * tb_ticks_per_usec, 1000); It's look good.
> > > > But why we need:
> > > > if (ns >= 1)
> > > > cycle = ((ns + 500) / 1000) * tb_ticks_per_usec; ?
> > > >
> > > > I think "cycle = div_u64(ns * tb_ticks_per_usec, 1000)" is good
> > > > enough. :)
> > >
> > > It's to deal with overflow if a very large value of ns is provided
> > > (and/or tb_ticks_per_usec is larger than we expect).
> > >
> > :), as I think, it's to deal with overflow. But you version cannot do
> deal with it.
> > Because ns is u64, if ns > 0x_fe0b, ns + 500 will overflow,
> And if tb_ticks_per_usec > 1000 and ns > (0x_ / 10) cycle
> also will overflow.
> 
> Sigh... It significantly increases the value of ns at which you'll get
> overflow problems. :-)  I was more concerned with large-but-somewhat-
> reasonable values of ns (e.g. than with trying to handle every possible
> input.  Even without that test, getting overflow is stretching the bounds
> of reasonableness (e.g. a 1 GHz timebase would require a timeout of over
> 7 months to overflow), but it was low-hanging fruit.  And the worst case
> is we go to pw20 sooner than the user wanted, so let's not go too
> overboard.
> 
> I doubt you would see > 0x_fe0b except if someone is trying
> to disable it by setting 0x_ even though a separate API
> is provided to cleanly disable it.
> 
> > I think we need to do this:
> >
> > #define U64_LOW_MASK0xULL
> > #define U64_MASK0xULL
> >
> > u32 tmp_rem;
> > u64 ns_u_rem, ns_u, ns_l, ns_l_carry;
> > u64 cycle;
> >
> > ns_u = ns >> 32;
> > ns_l = ns & U64_LOW_MASK;
> >
> > ns_l *= tb_ticks_per_usec;
> > ns_l_carry = ns_l >> 32;
> > ns_u *= tb_ticks_per_usec;
> > ns_u += ns_l_carry;
> >
> > ns_u = div_u64_rem(ns_u, 1000, &tmp_rem);
> > ns_u_rem = tmp_rem;
> > ns_l = (ns_l & U64_LOW_MASK) | ((ns_u_rem) << 32);
> > ns_l = div_u64(ns_l, 1000);
> >
> > if (ns_u >> 32)
> > cycle = U64_MASK;
> > else
> > cycle = (ns_u << 32) | (ns_l & U64_LOW_MASK);
> >
> > I has already tested this code, and works good. :)
> 
> Ugh.  I don't think we need to get this complicated (and I'd rather not
> spend the time verifying the correctness of this).
> 
> If for some reason we did need something like this in some other context
> (I don't want to see it just for pw20), I'd be more inclined to see
> general 128-bit mult/divide support.
> 
I would like to use my version,:), because it can handle any situation and we 
do not need to restrict users.
Here is a kind of special way to get the cycle. If this 128-bit situation is 
more and more, at that time we go to support it.

-dongsheng

> -Scott
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Saturday, September 28, 2013 5:33 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Bhushan Bharat-R65777; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> 
> On Thu, 2013-09-26 at 22:34 -0500, Wang Dongsheng-B40534 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Friday, September 27, 2013 5:37 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> > > d...@lists.ozlabs.org
> > > Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
> > > and altivec idle
> > >
> > > On Thu, 2013-09-26 at 01:18 -0500, Wang Dongsheng-B40534 wrote:
> > > >
> > > > > -Original Message-
> > > > > From: Bhushan Bharat-R65777
> > > > > Sent: Thursday, September 26, 2013 12:23 PM
> > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
> > > > > state and altivec idle
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Wang Dongsheng-B40534
> > > > > > Sent: Thursday, September 26, 2013 8:02 AM
> > > > > > To: Wood Scott-B07421
> > > > > > Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org
> > > > > > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > state and altivec idle
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Wood Scott-B07421
> > > > > > > Sent: Thursday, September 26, 2013 1:57 AM
> > > > > > > To: Wang Dongsheng-B40534
> > > > > > > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> > > > > > > d...@lists.ozlabs.org
> > > > > > > Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > > state and altivec idle
> > > > > > >
> > > > > > > On Wed, 2013-09-25 at 03:10 -0500, Wang Dongsheng-B40534
> wrote:
> > > > > > > >
> > > > > > > > > -Original Message-
> > > > > > > > > From: Bhushan Bharat-R65777
> > > > > > > > > Sent: Wednesday, September 25, 2013 2:23 PM
> > > > > > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > > > > > Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > > > > > > > > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for
> > > > > > > > > pw20 state and altivec idle
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > -Original Message-
> > > > > > > > > > From: Linuxppc-dev [mailto:linuxppc-dev-
> > > > > > > > > > bounces+bharat.bhushan=freescale@lists.ozlabs.org]
> > > > > > > > > > bounces+On Behalf Of Dongsheng
> > > > > > > > > > Wang
> > > > > > > > > > Sent: Tuesday, September 24, 2013 2:59 PM
> > > > > > > > > > To: Wood Scott-B07421
> > > > > > > > > > Cc: linuxppc-dev@lists.ozlabs.org; Wang
> > > > > > > > > > Dongsheng-B40534
> > > > > > > > > > Subject: [PATCH v4 4/4] powerpc/85xx: add sysfs for
> > > > > > > > > > pw20 state and altivec idle
> > > > > > > > > >
> > > > > > > > > > From: Wang Dongsheng 
> > > > > > > > > >
> > > > > > > > > > Add a sys interface to enable/diable pw20 state or
> > > > > > > > > > altivec idle, and control the wait entry time.
> > > > > > > > > >
> > > > > > > > > > Enable/Disable interface:
> > > > > > > > > > 0, disable. 1, enable.
> > > > &g

RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, September 27, 2013 5:37 AM
> To: Wang Dongsheng-B40534
> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> 
> On Thu, 2013-09-26 at 01:18 -0500, Wang Dongsheng-B40534 wrote:
> >
> > > -Original Message-
> > > From: Bhushan Bharat-R65777
> > > Sent: Thursday, September 26, 2013 12:23 PM
> > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > Cc: linuxppc-dev@lists.ozlabs.org
> > > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
> > > and altivec idle
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Wang Dongsheng-B40534
> > > > Sent: Thursday, September 26, 2013 8:02 AM
> > > > To: Wood Scott-B07421
> > > > Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org
> > > > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > and altivec idle
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Thursday, September 26, 2013 1:57 AM
> > > > > To: Wang Dongsheng-B40534
> > > > > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> > > > > d...@lists.ozlabs.org
> > > > > Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
> > > > > state and altivec idle
> > > > >
> > > > > On Wed, 2013-09-25 at 03:10 -0500, Wang Dongsheng-B40534 wrote:
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Bhushan Bharat-R65777
> > > > > > > Sent: Wednesday, September 25, 2013 2:23 PM
> > > > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > > > Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > > > > > > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > > state and altivec idle
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Linuxppc-dev [mailto:linuxppc-dev-
> > > > > > > > bounces+bharat.bhushan=freescale@lists.ozlabs.org] On
> > > > > > > > bounces+Behalf Of Dongsheng
> > > > > > > > Wang
> > > > > > > > Sent: Tuesday, September 24, 2013 2:59 PM
> > > > > > > > To: Wood Scott-B07421
> > > > > > > > Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > > > > > > > Subject: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > > > state and altivec idle
> > > > > > > >
> > > > > > > > From: Wang Dongsheng 
> > > > > > > >
> > > > > > > > Add a sys interface to enable/diable pw20 state or altivec
> > > > > > > > idle, and control the wait entry time.
> > > > > > > >
> > > > > > > > Enable/Disable interface:
> > > > > > > > 0, disable. 1, enable.
> > > > > > > > /sys/devices/system/cpu/cpuX/pw20_state
> > > > > > > > /sys/devices/system/cpu/cpuX/altivec_idle
> > > > > > > >
> > > > > > > > Set wait time interface:(Nanosecond)
> > > > > > > > /sys/devices/system/cpu/cpuX/pw20_wait_time
> > > > > > > > /sys/devices/system/cpu/cpuX/altivec_idle_wait_time
> > > > > > > > Example: Base on TBfreq is 41MHZ.
> > > > > > > > 1~47(ns): TB[63]
> > > > > > > > 48~95(ns): TB[62]
> > > > > > > > 96~191(ns): TB[61]
> > > > > > > > 192~383(ns): TB[62]
> > > > > > > > 384~767(ns): TB[60]
> > > > > > > > ...
> > > > > > > >
> > > > > > > > Signed-off-by: Wang Dongsheng
> > > > > > > > 
> > > > > > > > ---
> > > > > > > > *v4:
> > > > > > > > Move code from 85xx/common.c to kernel/sysfs.c.
>

RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

[Wang Dongsheng-B40534]

> -Original Message-
> From: Bhushan Bharat-R65777
> Sent: Thursday, September 26, 2013 12:23 PM
> To: Wang Dongsheng-B40534; Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> 
> 
> 
> > -Original Message-
> > From: Wang Dongsheng-B40534
> > Sent: Thursday, September 26, 2013 8:02 AM
> > To: Wood Scott-B07421
> > Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org
> > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
> > altivec idle
> >
> >
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Thursday, September 26, 2013 1:57 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> > > d...@lists.ozlabs.org
> > > Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
> > > and altivec idle
> > >
> > > On Wed, 2013-09-25 at 03:10 -0500, Wang Dongsheng-B40534 wrote:
> > > >
> > > > > -Original Message-
> > > > > From: Bhushan Bharat-R65777
> > > > > Sent: Wednesday, September 25, 2013 2:23 PM
> > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > > > > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
> > > > > state and altivec idle
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Linuxppc-dev [mailto:linuxppc-dev-
> > > > > > bounces+bharat.bhushan=freescale@lists.ozlabs.org] On
> > > > > > bounces+Behalf Of Dongsheng
> > > > > > Wang
> > > > > > Sent: Tuesday, September 24, 2013 2:59 PM
> > > > > > To: Wood Scott-B07421
> > > > > > Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > > > > > Subject: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > > > and altivec idle
> > > > > >
> > > > > > From: Wang Dongsheng 
> > > > > >
> > > > > > Add a sys interface to enable/diable pw20 state or altivec
> > > > > > idle, and control the wait entry time.
> > > > > >
> > > > > > Enable/Disable interface:
> > > > > > 0, disable. 1, enable.
> > > > > > /sys/devices/system/cpu/cpuX/pw20_state
> > > > > > /sys/devices/system/cpu/cpuX/altivec_idle
> > > > > >
> > > > > > Set wait time interface:(Nanosecond)
> > > > > > /sys/devices/system/cpu/cpuX/pw20_wait_time
> > > > > > /sys/devices/system/cpu/cpuX/altivec_idle_wait_time
> > > > > > Example: Base on TBfreq is 41MHZ.
> > > > > > 1~47(ns): TB[63]
> > > > > > 48~95(ns): TB[62]
> > > > > > 96~191(ns): TB[61]
> > > > > > 192~383(ns): TB[62]
> > > > > > 384~767(ns): TB[60]
> > > > > > ...
> > > > > >
> > > > > > Signed-off-by: Wang Dongsheng 
> > > > > > ---
> > > > > > *v4:
> > > > > > Move code from 85xx/common.c to kernel/sysfs.c.
> > > > > >
> > > > > > Remove has_pw20_altivec_idle function.
> > > > > >
> > > > > > Change wait "entry_bit" to wait time.
> > > > > >
> > > > > >  arch/powerpc/kernel/sysfs.c | 291
> > > > > > 
> > > > > >  1 file changed, 291 insertions(+)
> > > > > >
> > > > > > diff --git a/arch/powerpc/kernel/sysfs.c
> > > > > > b/arch/powerpc/kernel/sysfs.c index 27a90b9..23fece6 100644
> > > > > > --- a/arch/powerpc/kernel/sysfs.c
> > > > > > +++ b/arch/powerpc/kernel/sysfs.c
> > > > > > @@ -85,6 +85,279 @@ __setup("smt-snooze-delay=",
> > > > > > setup_smt_snooze_delay);
> > > > > >
> > > > > >  #endif /* CONFIG_PPC64 */
> > > > > >
> > > > > > +#ifdef CONFIG_FSL_SOC
> > > > > > +#define MAX_BIT63
> > > > > > +
> > > > > > +static u64 pw20_wt;
&

RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, September 26, 2013 1:57 AM
> To: Wang Dongsheng-B40534
> Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> 
> On Wed, 2013-09-25 at 03:10 -0500, Wang Dongsheng-B40534 wrote:
> >
> > > -Original Message-
> > > From: Bhushan Bharat-R65777
> > > Sent: Wednesday, September 25, 2013 2:23 PM
> > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
> > > and altivec idle
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Linuxppc-dev [mailto:linuxppc-dev-
> > > > bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf
> > > > bounces+Of Dongsheng
> > > > Wang
> > > > Sent: Tuesday, September 24, 2013 2:59 PM
> > > > To: Wood Scott-B07421
> > > > Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > > > Subject: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
> > > > altivec idle
> > > >
> > > > From: Wang Dongsheng 
> > > >
> > > > Add a sys interface to enable/diable pw20 state or altivec idle,
> > > > and control the wait entry time.
> > > >
> > > > Enable/Disable interface:
> > > > 0, disable. 1, enable.
> > > > /sys/devices/system/cpu/cpuX/pw20_state
> > > > /sys/devices/system/cpu/cpuX/altivec_idle
> > > >
> > > > Set wait time interface:(Nanosecond)
> > > > /sys/devices/system/cpu/cpuX/pw20_wait_time
> > > > /sys/devices/system/cpu/cpuX/altivec_idle_wait_time
> > > > Example: Base on TBfreq is 41MHZ.
> > > > 1~47(ns): TB[63]
> > > > 48~95(ns): TB[62]
> > > > 96~191(ns): TB[61]
> > > > 192~383(ns): TB[62]
> > > > 384~767(ns): TB[60]
> > > > ...
> > > >
> > > > Signed-off-by: Wang Dongsheng 
> > > > ---
> > > > *v4:
> > > > Move code from 85xx/common.c to kernel/sysfs.c.
> > > >
> > > > Remove has_pw20_altivec_idle function.
> > > >
> > > > Change wait "entry_bit" to wait time.
> > > >
> > > >  arch/powerpc/kernel/sysfs.c | 291
> > > > 
> > > >  1 file changed, 291 insertions(+)
> > > >
> > > > diff --git a/arch/powerpc/kernel/sysfs.c
> > > > b/arch/powerpc/kernel/sysfs.c index 27a90b9..23fece6 100644
> > > > --- a/arch/powerpc/kernel/sysfs.c
> > > > +++ b/arch/powerpc/kernel/sysfs.c
> > > > @@ -85,6 +85,279 @@ __setup("smt-snooze-delay=",
> > > > setup_smt_snooze_delay);
> > > >
> > > >  #endif /* CONFIG_PPC64 */
> > > >
> > > > +#ifdef CONFIG_FSL_SOC
> > > > +#define MAX_BIT63
> > > > +
> > > > +static u64 pw20_wt;
> > > > +static u64 altivec_idle_wt;
> > > > +
> > > > +static unsigned int get_idle_ticks_bit(u64 ns) {
> > > > +   u64 cycle;
> > > > +
> > > > +   cycle = div_u64(ns, 1000 / tb_ticks_per_usec);
> > >
> > > When tb_ticks_per_usec  > 1000 (timebase frequency > 1GHz) then this
> > > will always be ns, which is not correct, no?
> 
> Actually it'll be a divide by zero in that case.
> 
tb_ticks_per_usec = ppc_tb_freq / 100; Means TB freq should be more than 
1MHZ.

if ppc_tb_freq less than 100, the tb_ticks_per_usec will be a divide by 
zero.
If this condition is established, I think kernel cannot work as a normal.

So I think we need to believe that the variable is not zero. And I think TB 
freq should not less than 1MHZ on PPC platform, because if TB freq less than 
1MHZ, the precision time will become very poor and system response time will be 
slower.

> > "1000 / tb_ticks_per_usec" means nsec_ticks_per_tb
> >
> > If timebase frequency > 1GHz, this should be "tb_ticks_per_usec / 1000"
> and to get tb_ticks_per_nsec.
> > This should be changed to "cycle = ns * tb_ticks_per_nsec;"
> >
> > But at present we do not have such a platform that timebase frequency
> > more than 1GHz. And I think it is not need to support such a situation.
> > Because we have no environment to test it.
> 
> You can test it by hacking a wrong timebase frequency in and seeing what
> the calculation does.
> 
> Or do something like this:
> 
>   if (ns >= 1)
>   cycle = ((ns + 500) / 1000) * tb_ticks_per_usec;
>   else
>   cycle = div_u64((u64)ns * tb_ticks_per_usec, 1000);
> 
We cannot do this, because if (ns+500) < 1000, we cannot get the entry bit, 
it'll always zero bit.

We must to use per_nsec_tb_ticks, like my code 1000 / tb_ticks_per_usec.

> ...which can be tested just by varying ns.
> 
> > If later there will be more than 1GHZ platform at that time to add this
> support.
> 
Yes, I agree this point. :)

-dongsheng

> There almost certainly won't be timebases that run that fast, but divide
> by zero is a rather nasty way of responding if such a thing does happen.
> 
> -Scott
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

[Wang Dongsheng-B40534]

> -Original Message-
> From: Bhushan Bharat-R65777
> Sent: Wednesday, September 25, 2013 2:23 PM
> To: Wang Dongsheng-B40534; Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> 
> 
> 
> > -Original Message-
> > From: Linuxppc-dev [mailto:linuxppc-dev-
> > bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of
> > bounces+Dongsheng
> > Wang
> > Sent: Tuesday, September 24, 2013 2:59 PM
> > To: Wood Scott-B07421
> > Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > Subject: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
> > altivec idle
> >
> > From: Wang Dongsheng 
> >
> > Add a sys interface to enable/diable pw20 state or altivec idle, and
> > control the wait entry time.
> >
> > Enable/Disable interface:
> > 0, disable. 1, enable.
> > /sys/devices/system/cpu/cpuX/pw20_state
> > /sys/devices/system/cpu/cpuX/altivec_idle
> >
> > Set wait time interface:(Nanosecond)
> > /sys/devices/system/cpu/cpuX/pw20_wait_time
> > /sys/devices/system/cpu/cpuX/altivec_idle_wait_time
> > Example: Base on TBfreq is 41MHZ.
> > 1~47(ns): TB[63]
> > 48~95(ns): TB[62]
> > 96~191(ns): TB[61]
> > 192~383(ns): TB[62]
> > 384~767(ns): TB[60]
> > ...
> >
> > Signed-off-by: Wang Dongsheng 
> > ---
> > *v4:
> > Move code from 85xx/common.c to kernel/sysfs.c.
> >
> > Remove has_pw20_altivec_idle function.
> >
> > Change wait "entry_bit" to wait time.
> >
> >  arch/powerpc/kernel/sysfs.c | 291
> > 
> >  1 file changed, 291 insertions(+)
> >
> > diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
> > index 27a90b9..23fece6 100644
> > --- a/arch/powerpc/kernel/sysfs.c
> > +++ b/arch/powerpc/kernel/sysfs.c
> > @@ -85,6 +85,279 @@ __setup("smt-snooze-delay=",
> > setup_smt_snooze_delay);
> >
> >  #endif /* CONFIG_PPC64 */
> >
> > +#ifdef CONFIG_FSL_SOC
> > +#define MAX_BIT63
> > +
> > +static u64 pw20_wt;
> > +static u64 altivec_idle_wt;
> > +
> > +static unsigned int get_idle_ticks_bit(u64 ns) {
> > +   u64 cycle;
> > +
> > +   cycle = div_u64(ns, 1000 / tb_ticks_per_usec);
> 
> When tb_ticks_per_usec  > 1000 (timebase frequency > 1GHz) then this will
> always be ns, which is not correct, no?
> 
"1000 / tb_ticks_per_usec" means nsec_ticks_per_tb

If timebase frequency > 1GHz, this should be "tb_ticks_per_usec / 1000" and to 
get tb_ticks_per_nsec.
This should be changed to "cycle = ns * tb_ticks_per_nsec;"

But at present we do not have such a platform that timebase frequency more than 
1GHz. And I think it is not need to support such a situation. Because we have 
no environment to test it.

If later there will be more than 1GHZ platform at that time to add this support.

Thanks.

-dongsheng


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v4 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define

[Wang Dongsheng-B40534]

> -Original Message-
> From: Bhushan Bharat-R65777
> Sent: Wednesday, September 25, 2013 11:43 AM
> To: Kumar Gala
> Cc: Wang Dongsheng-B40534; Wood Scott-B07421; linuxppc-
> d...@lists.ozlabs.org
> Subject: RE: [PATCH v4 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0
> define
> 
> 
> 
> > -Original Message-
> > From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> > Sent: Tuesday, September 24, 2013 9:19 PM
> > To: Bhushan Bharat-R65777
> > Cc: Wang Dongsheng-B40534; Wood Scott-B07421;
> > linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH v4 1/4] powerpc/fsl: add E6500 PVR and
> > SPRN_PWRMGTCR0 define
> >
> >
> > On Sep 24, 2013, at 6:21 AM, Bhushan Bharat-R65777 wrote:
> >
> > >
> > >
> > >> -Original Message-
> > >> From: Linuxppc-dev [mailto:linuxppc-dev-
> > >> bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of
> > >> bounces+Dongsheng
> > >> Wang
> > >> Sent: Tuesday, September 24, 2013 2:58 PM
> > >> To: Wood Scott-B07421
> > >> Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > >> Subject: [PATCH v4 1/4] powerpc/fsl: add E6500 PVR and
> > >> SPRN_PWRMGTCR0 define
> > >>
> > >> From: Wang Dongsheng 
> > >>
> > >> E6500 PVR and SPRN_PWRMGTCR0 will be used in subsequent
> > >> pw20/altivec idle patches.
> > >>
> > >> Signed-off-by: Wang Dongsheng 
> > >> ---
> > >> *v3:
> > >> Add bit definitions for PWRMGTCR0.
> > >>
> > >> arch/powerpc/include/asm/reg.h   | 2 ++
> > >> arch/powerpc/include/asm/reg_booke.h | 9 +
> > >> 2 files changed, 11 insertions(+)
> > >>
> > >> diff --git a/arch/powerpc/include/asm/reg.h
> > >> b/arch/powerpc/include/asm/reg.h index 64264bf..d4160ca 100644
> > >> --- a/arch/powerpc/include/asm/reg.h
> > >> +++ b/arch/powerpc/include/asm/reg.h
> > >> @@ -1053,6 +1053,8 @@
> > >> #define PVR_8560 0x8020
> > >> #define PVR_VER_E500V1   0x8020
> > >> #define PVR_VER_E500V2   0x8021
> > >> +#define PVR_VER_E6500   0x8040
> > >> +
> > >> /*
> > >>  * For the 8xx processors, all of them report the same PVR family
> > >> for
> > >>  * the PowerPC core. The various versions of these processors must
> > >> be diff -- git a/arch/powerpc/include/asm/reg_booke.h
> > >> b/arch/powerpc/include/asm/reg_booke.h
> > >> index ed8f836..4a6457e 100644
> > >> --- a/arch/powerpc/include/asm/reg_booke.h
> > >> +++ b/arch/powerpc/include/asm/reg_booke.h
> > >> @@ -170,6 +170,7 @@
> > >> #define SPRN_L2CSR1  0x3FA   /* L2 Data Cache Control and Status
> Register 1
> > >> */
> > >> #define SPRN_DCCR0x3FA   /* Data Cache Cacheability Register */
> > >> #define SPRN_ICCR0x3FB   /* Instruction Cache Cacheability 
> > >> Register
> */
> > >> +#define SPRN_PWRMGTCR0  0x3FB   /* Power management control register
> 0 */
> > >
> > > Is this generic for booke or e6500 specific? I can't see this
> > > register either
> > in ISA and EREF.
> > > Also I can see SPRN_ICCR also with same SPRN, how that is possible?
> >
> > Its possibly because the register maybe in implementation specific
> > region.  I'm guessing ICCR is a 40x specific register.
> 
> Kumar, this seems to create confusion? 
I don't think this define will create a confusion, because this is only SPR 
number
definition and we already have a document(like EREF, ISA, this register define 
in
E6500-EREF) to describe these registers. There are no conflicts and other 
platform
and different platforms for the same register have different purposes, it looks 
normal.
Instead we should put together, so as to remind that the SPR will be reuse from 
other platforms.

-dongsheng


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v4 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define

[Wang Dongsheng-B40534]

> >> /*
> >>  * For the 8xx processors, all of them report the same PVR family for
> >>  * the PowerPC core. The various versions of these processors must be
> >> diff -- git a/arch/powerpc/include/asm/reg_booke.h
> >> b/arch/powerpc/include/asm/reg_booke.h
> >> index ed8f836..4a6457e 100644
> >> --- a/arch/powerpc/include/asm/reg_booke.h
> >> +++ b/arch/powerpc/include/asm/reg_booke.h
> >> @@ -170,6 +170,7 @@
> >> #define SPRN_L2CSR10x3FA   /* L2 Data Cache Control and Status
> Register 1
> >> */
> >> #define SPRN_DCCR  0x3FA   /* Data Cache Cacheability Register */
> >> #define SPRN_ICCR  0x3FB   /* Instruction Cache Cacheability Register
> */
> >> +#define SPRN_PWRMGTCR00x3FB   /* Power management control register
> 0 */
> >
> > Is this generic for booke or e6500 specific? I can't see this register
> either in ISA and EREF.

Yes, now only e6500 have this register. There is no problem in this definition,
because no conflict in FSL platform.

> > Also I can see SPRN_ICCR also with same SPRN, how that is possible?
> 
> Its possibly because the register maybe in implementation specific region.
> I'm guessing ICCR is a 40x specific register.

Yes, kumar is right. Its use only in 4xx series of chips.

ICTC(arch/powerpc/include/asm/reg.h) also use 0x3FB, Its use only in 6xx series 
of chips.

-dongsheng


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, September 17, 2013 5:09 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; ga...@kernel.crashing.org; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> 
> On Thu, 2013-09-12 at 21:53 -0500, Wang Dongsheng-B40534 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Friday, September 13, 2013 2:07 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Wood Scott-B07421; ga...@kernel.crashing.org; linuxppc-
> > > d...@lists.ozlabs.org
> > > Subject: Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state
> > > and altivec idle
> > >
> > > On Wed, 2013-09-11 at 22:48 -0500, Wang Dongsheng-B40534 wrote:
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Thursday, September 12, 2013 7:04 AM
> > > > > To: Wang Dongsheng-B40534
> > > > > Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
> > > > > Subject: Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20
> > > > > state and altivec idle
> > > > >
> > > > > On Wed, 2013-09-11 at 13:56 +0800, Dongsheng Wang wrote:
> > > > > > From: Wang Dongsheng 
> > > > > >
> > > > > > Add a sys interface to enable/diable pw20 state or altivec
> > > > > > idle, and control the wait entry time.
> > > > > >
> > > > > > Enable/Disable interface:
> > > > > > 0, disable. 1, enable.
> > > > > > /sys/devices/system/cpu/cpuX/pw20_state
> > > > > > /sys/devices/system/cpu/cpuX/altivec_idle
> > > > > >
> > > > > > Set wait entry bit interface:
> > > > > > bit value range 0~63, 0 bit is Mintime, 63 bit is Maxtime.
> > > > > > /sys/devices/system/cpu/cpuX/pw20_wait_entry_bit
> > > > > > /sys/devices/system/cpu/cpuX/altivec_idle_wait_entry_bit
> > > > >
> > > > > I'm no fan of the way powerpc does bit numbering, but don't flip
> > > > > it around here -- you'll just cause confusion.
> > > > >
> > > > OK. 0 bit is maxtime, 63 bit is mintime.
> > > >
> > > > > Better yet, this interface should take real time units rather
> > > > > than a timebase bit.
> > > > >
> > > > I think the real time is not suitable, because timebase bit does
> > > > not correspond with real time.
> > >
> > > It's a bit sloppy due to how the hardware works, but you could
> > > convert it like you did in earlier patches.  Semantically it should
> > > probably be the minimum time to wait before entering the low power
> state.
> > >
> > But there has a problem, we can't convert bit to the real time when
> user read this sysfs.
> > Like:
> > echo 1000(us) > /sys/*/pw20_wait_entry_bit, after convert we get bit is
> 49.
> > cat /sys/*/pw20_wait_entry_bit, after convert the time is 1598(us).
> >
> > The read out of the time is not real time. Unless we define a variable
> to save the real time.
> 
> It's not the end of the world if the value is different when read back.
> It just gets rounded up when you write it.
> 
Ok, make a variable to save it.

> > > > > Also, you disable the power saving mode if the maximum interval
> > > > > is selected,
> > > > It's not disable the pw20 state or altivec idle, just max-delay
> > > > entry
> > > time.
> > >
> > > No, the code checks for zero to set or clear the enabling bit (e.g.
> > > PW20_WAIT).
> > >
> > There has pw20_state/altivec_idle sys interface to control
> > "enable/disable", There is only to control wait bit. Did you mean
> remove "pw20_state/altivec_idle"
> > sys interface, and reuse "pw20_wait_entry_bit/altivec_idle*" sys
> interface?
> > When echo zero into "pw20_wait_entry_bit" we just to disable pw20
> > state, I think that is reasonable. :)
> 
> Sorry, I misread the patch and didn't realize these were separate
> interfaces.
Keep the "pw20_state/altivec_idle" interfaces.

-dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, September 13, 2013 2:07 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; ga...@kernel.crashing.org; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> 
> On Wed, 2013-09-11 at 22:48 -0500, Wang Dongsheng-B40534 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Thursday, September 12, 2013 7:04 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state
> > > and altivec idle
> > >
> > > On Wed, 2013-09-11 at 13:56 +0800, Dongsheng Wang wrote:
> > > > From: Wang Dongsheng 
> > > >
> > > > Add a sys interface to enable/diable pw20 state or altivec idle,
> > > > and control the wait entry time.
> > > >
> > > > Enable/Disable interface:
> > > > 0, disable. 1, enable.
> > > > /sys/devices/system/cpu/cpuX/pw20_state
> > > > /sys/devices/system/cpu/cpuX/altivec_idle
> > > >
> > > > Set wait entry bit interface:
> > > > bit value range 0~63, 0 bit is Mintime, 63 bit is Maxtime.
> > > > /sys/devices/system/cpu/cpuX/pw20_wait_entry_bit
> > > > /sys/devices/system/cpu/cpuX/altivec_idle_wait_entry_bit
> > >
> > > I'm no fan of the way powerpc does bit numbering, but don't flip it
> > > around here -- you'll just cause confusion.
> > >
> > OK. 0 bit is maxtime, 63 bit is mintime.
> >
> > > Better yet, this interface should take real time units rather than a
> > > timebase bit.
> > >
> > I think the real time is not suitable, because timebase bit does not
> > correspond with real time.
> 
> It's a bit sloppy due to how the hardware works, but you could convert it
> like you did in earlier patches.  Semantically it should probably be the
> minimum time to wait before entering the low power state.
> 
But there has a problem, we can't convert bit to the real time when user read 
this sysfs.
Like:
echo 1000(us) > /sys/*/pw20_wait_entry_bit, after convert we get bit is 49.
cat /sys/*/pw20_wait_entry_bit, after convert the time is 1598(us).

The read out of the time is not real time. Unless we define a variable to save 
the real time.

> > > Also, you disable the power saving mode if the maximum interval is
> > > selected,
> > It's not disable the pw20 state or altivec idle, just max-delay entry
> time.
> 
> No, the code checks for zero to set or clear the enabling bit (e.g.
> PW20_WAIT).
> 
There has pw20_state/altivec_idle sys interface to control "enable/disable",
There is only to control wait bit. Did you mean remove "pw20_state/altivec_idle"
sys interface, and reuse "pw20_wait_entry_bit/altivec_idle*" sys interface?
When echo zero into "pw20_wait_entry_bit" we just to disable pw20 state, I 
think that is reasonable. :)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, September 12, 2013 7:04 AM
> To: Wang Dongsheng-B40534
> Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH v3 4/4] powerpc/85xx: add sysfs for pw20 state and
> altivec idle
> 
> On Wed, 2013-09-11 at 13:56 +0800, Dongsheng Wang wrote:
> > From: Wang Dongsheng 
> >
> > Add a sys interface to enable/diable pw20 state or altivec idle, and
> > control the wait entry time.
> >
> > Enable/Disable interface:
> > 0, disable. 1, enable.
> > /sys/devices/system/cpu/cpuX/pw20_state
> > /sys/devices/system/cpu/cpuX/altivec_idle
> >
> > Set wait entry bit interface:
> > bit value range 0~63, 0 bit is Mintime, 63 bit is Maxtime.
> > /sys/devices/system/cpu/cpuX/pw20_wait_entry_bit
> > /sys/devices/system/cpu/cpuX/altivec_idle_wait_entry_bit
> 
> I'm no fan of the way powerpc does bit numbering, but don't flip it
> around here -- you'll just cause confusion.
> 
OK. 0 bit is maxtime, 63 bit is mintime.

> Better yet, this interface should take real time units rather than a
> timebase bit.
> 
I think the real time is not suitable, because timebase bit does not correspond 
with
real time.
 
> Also, you disable the power saving mode if the maximum interval is
> selected, 
It's not disable the pw20 state or altivec idle, just max-delay entry time.

>but the documentation doesn't say that -- and the documentation
> should be in the code (or other easily findable place), not just in the
> commit message.
> 
Also add a comment in the 85xx/common.c ?

> > Signed-off-by: Wang Dongsheng 
> > ---
> > diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> > b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> > index 7389d49..7395d79 100644
> > --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> > +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> > @@ -53,6 +53,21 @@ _GLOBAL(__e500_dcache_setup)
> > isync
> > blr
> >
> > +_GLOBAL(has_pw20_altivec_idle)
> > +   /* 0 false, 1 true */
> > +   li  r3, 0
> > +
> > +   /* PW20 & AltiVec idle feature only exists for E6500 */
> > +   mfspr   r0, SPRN_PVR
> > +   rlwinm  r4, r0, 16, 16, 31
> > +   lis r12, 0
> > +   ori r12, r12, PVR_VER_E6500@l
> > +   cmpwr4, r12
> > +   bne 2f
> > +   li  r3, 1
> > +2:
> > +   blr
> 
> Why is this in asm?  And shouldn't this go in the cputable somehow?
> 
Not a special reason for this, just asm...
I see that, we can use cpu_spec->pvr_value in c code.

> > +static void query_pwrmgtcr0(void *val) {
> > +   u32 *value = val;
> > +
> > +   *value = mfspr(SPRN_PWRMGTCR0);
> > +}
> > +
> > +static ssize_t show_pw20_state(struct device *dev,
> > +   struct device_attribute *attr, char *buf) {
> > +   u32 value;
> > +   unsigned int cpu = dev->id;
> > +
> > +   smp_call_function_single(cpu, query_pwrmgtcr0, &value, 1);
> > +
> > +   value &= PWRMGTCR0_PW20_WAIT;
> > +
> > +   return sprintf(buf, "%u\n", value ? 1 : 0); }
> > +
> > +static void control_pw20_state(void *val) {
> > +   u32 *value = val;
> > +   u32 pw20_state;
> > +
> > +   pw20_state = mfspr(SPRN_PWRMGTCR0);
> > +
> > +   if (*value)
> > +   pw20_state |= PWRMGTCR0_PW20_WAIT;
> > +   else
> > +   pw20_state &= ~PWRMGTCR0_PW20_WAIT;
> > +
> > +   mtspr(SPRN_PWRMGTCR0, pw20_state);
> > +}
> > +
> > +static ssize_t store_pw20_state(struct device *dev,
> > +   struct device_attribute *attr,
> > +   const char *buf, size_t count)
> 
> The difference between query/show and control/store is a bit awkward...
> I'd s/query/do_show/ and s/control/do_store/ (or local_ or other
> appropriate prefix).
> 
do_show/do_store looks better than others.

> > +static ssize_t show_altivec_idle_wait_entry_bit(struct device *dev,
> > +   struct device_attribute *attr, char *buf) {
> > +   u32 value;
> > +   unsigned int cpu = dev->id;
> > +
> > +   smp_call_function_single(cpu, query_pwrmgtcr0, &value, 1);
> > +
> > +   value = MAX_BIT - ((value & PWRMGTCR0_AV_IDLE_CNT) >>
> > +   PWRMGTCR0_AV_IDLE_CNT_SHIFT);
> > +
> > +   return sprintf(buf, "wait entry bit is %u\n", value); }
> 
> Reading a sysfs value should just return the value, not a human-readable
> string.
> 

RE: [PATCH v3 2/4] powerpc/85xx: add hardware automatically enter altivec idle state

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, September 12, 2013 6:43 AM
> To: Wang Dongsheng-B40534
> Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH v3 2/4] powerpc/85xx: add hardware automatically
> enter altivec idle state
> 
> On Wed, 2013-09-11 at 13:56 +0800, Dongsheng Wang wrote:
> > From: Wang Dongsheng 
> >
> > Each core's AltiVec unit may be placed into a power savings mode
> > by turning off power to the unit. Core hardware will automatically
> > power down the AltiVec unit after no AltiVec instructions have
> > executed in N cycles. The AltiVec power-control is triggered by
> hardware.
> >
> > Signed-off-by: Wang Dongsheng 
> > ---
> > *v3:
> > Assembly code instead of C code.
> >
> > *v2:
> > Remove:
> > delete setup_idle_hw_governor function.
> > delete "Fix erratum" for rev1.
> >
> > Move:
> > move setup_* into __setup/restore_cpu_e6500.
> >
> >  arch/powerpc/kernel/cpu_setup_fsl_booke.S | 20 
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> > index bfb18c7..3c03c109 100644
> > --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> > +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> > @@ -53,11 +53,30 @@ _GLOBAL(__e500_dcache_setup)
> > isync
> > blr
> >
> > +/*
> > + * FIXME - We don't know the AltiVec application scenarios.
> > + */
> > +#define AV_WAIT_IDLE_BIT   50 /* 1ms, TB frequency is 41.66MHZ
> */
> > +_GLOBAL(setup_altivec_idle)
> > +   mfspr   r3, SPRN_PWRMGTCR0
> > +
> > +   /* Enable Altivec Idle */
> > +   orisr3, r3, PWRMGTCR0_AV_IDLE_PD_EN@h
> > +   li  r4, AV_WAIT_IDLE_BIT
> > +
> > +   /* Set Automatic AltiVec Idle Count */
> > +   rlwimi  r3, r4, PWRMGTCR0_AV_IDLE_CNT_SHIFT,
> PWRMGTCR0_AV_IDLE_CNT
> > +
> > +   mtspr   SPRN_PWRMGTCR0, r3
> > +
> > +   blr
> 
> The FIXME comment is not clear.  If you mean that we haven't yet done
> testing to determine a reasonable default value for AV_WAIT_IDLE_BIT,
> then just say that.  Likewise with the FIXME comment in the pw20 patch
> -- the uncertainty is due to a lack of investigation, not "because we
> don't know the current state of the cpu load".
> 
> While some workloads may want a different value than whatever default we
> set, that's what the sysfs interface is for.  The only thing missing
> here is benchmarking to determine a good overall default.
> 
Thanks.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 2/3] powerpc/85xx: add hardware automatically enter altivec idle state

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Tuesday, August 27, 2013 4:42 PM
> To: Wood Scott-B07421; ga...@kernel.crashing.org
> Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> Subject: [PATCH v2 2/3] powerpc/85xx: add hardware automatically enter
> altivec idle state
> 
> From: Wang Dongsheng 
> 
> Each core's AltiVec unit may be placed into a power savings mode
> by turning off power to the unit. Core hardware will automatically
> power down the AltiVec unit after no AltiVec instructions have
> executed in N cycles. The AltiVec power-control is triggered by hardware.
> 
> Signed-off-by: Wang Dongsheng 
> ---
> *v2:
> Remove:
> delete setup_idle_hw_governor function.
> delete "Fix erratum" for rev1.
> 
> Move:
> move setup_* into __setup/restore_cpu_e6500.
> 
> diff --git a/arch/powerpc/include/asm/reg_booke.h
> b/arch/powerpc/include/asm/reg_booke.h
> index 86ede76..8364bbe 100644
> --- a/arch/powerpc/include/asm/reg_booke.h
> +++ b/arch/powerpc/include/asm/reg_booke.h
> @@ -217,6 +217,9 @@
>  #define  CCR1_DPC0x0100 /* Disable L1 I-Cache/D-Cache parity
> checking */
>  #define  CCR1_TCS0x0080 /* Timer Clock Select */
> 
> +/* Bit definitions for PWRMGTCR0. */
> +#define PWRMGTCR0_ALTIVEC_IDLE   (1 << 22) /* Altivec idle enable */
> +
>  /* Bit definitions for the MCSR. */
>  #define MCSR_MCS 0x8000 /* Machine Check Summary */
>  #define MCSR_IB  0x4000 /* Instruction PLB Error */
> diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> index bfb18c7..90bbb46 100644
> --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> @@ -58,6 +58,7 @@ _GLOBAL(__setup_cpu_e6500)
>  #ifdef CONFIG_PPC64
>   bl  .setup_altivec_ivors
>  #endif
> + bl  setup_altivec_idle
>   bl  __setup_cpu_e5500
>   mtlrr6
>   blr
> @@ -119,6 +120,7 @@ _GLOBAL(__setup_cpu_e5500)
>  _GLOBAL(__restore_cpu_e6500)
>   mflrr5
>   bl  .setup_altivec_ivors
> + bl  setup_altivec_idle
>   bl  __restore_cpu_e5500
>   mtlrr5
>   blr
> diff --git a/arch/powerpc/platforms/85xx/common.c
> b/arch/powerpc/platforms/85xx/common.c
> index d0861a0..93b563b 100644
> --- a/arch/powerpc/platforms/85xx/common.c
> +++ b/arch/powerpc/platforms/85xx/common.c
> @@ -11,6 +11,16 @@
> 
>  #include "mpc85xx.h"
> 
> +#define MAX_BIT  64
> +
This should be change to 63, i will fix this in next patch.

- dongsheng

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, August 23, 2013 11:31 PM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Kumar Gala; Zhao Chenhui-B35336; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter
> altivec idle state
> 
> On Thu, 2013-08-22 at 21:52 -0500, Wang Dongsheng-B40534 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Thursday, August 22, 2013 11:19 PM
> > > To: Wang Dongsheng-B40534
> > > Cc: Wood Scott-B07421; Kumar Gala; Zhao Chenhui-B35336; linuxppc-
> > > d...@lists.ozlabs.org
> > > Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically
> enter
> > > altivec idle state
> > >
> > > On Wed, 2013-08-21 at 22:13 -0500, Wang Dongsheng-B40534 wrote:
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Tuesday, August 20, 2013 8:39 AM
> > > > > To: Wang Dongsheng-B40534
> > > > > Cc: Wood Scott-B07421; Kumar Gala; linuxppc-dev@lists.ozlabs.org
> > > > > Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically
> > > > > enter altivec idle state
> > > > >
> > > > > It just seems wrong to have an ad-hoc mechanism for running
> > > > > core-specific code when we have cputable...  If we really need
> this,
> > > > > maybe we should add a "cpu_setup_late" function pointer.
> > > > >
> > > > > With your patch, when does the power management register get set
> > > > > when hot plugging a cpu?
> > > > >
> > > > Um.. I don't deal with this situation. I will fix it.
> > > > __setup/restore_cpu_e6500 looks good. But only bootcpu call
> > > __setup_cpu_e6500, not on each cpu.
> > > > I think this is a bug.
> > >
> > > Other CPUs call __restore_cpu_e6500.
> > >
> > No, there is bootcore of secondary thread, and other cores of first
> thread call __restore_cpu_e6500.
> 
> This is the upstream list -- there is no e6500 thread support yet. :-)
> 
> But in the SDK I do see generic_secondary_common_init being called from
> generic_secondary_thread_init, which means __restore_cpu_e6500 will be
> called.

Thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH V5 3/5] POWER/cpuidle: Generic IBM-POWER backend cpuidle driver.

[Wang Dongsheng-B40534]

> diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
> index 0e2cd5c..e805dcd 100644
> --- a/drivers/cpuidle/Kconfig
> +++ b/drivers/cpuidle/Kconfig

Maybe drivers/cpuidle/Kconfig.powerpc is better? Like arm.

> +obj-$(CONFIG_CPU_IDLE_IBM_POWER) += cpuidle-ibm-power.o
> diff --git a/drivers/cpuidle/cpuidle-ibm-power.c
> b/drivers/cpuidle/cpuidle-ibm-power.c
> new file mode 100644
> index 000..4ee5a94
> --- /dev/null
> +++ b/drivers/cpuidle/cpuidle-ibm-power.c
> @@ -0,0 +1,304 @@
> +/*
> + *  cpuidle-ibm-power - idle state cpuidle driver.
> + *  Adapted from drivers/idle/intel_idle.c and
> + *  drivers/acpi/processor_idle.c
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct cpuidle_driver power_idle_driver = {
> + .name = "IBM-POWER-Idle",
> + .owner= THIS_MODULE,
> +};
> +
> +#define MAX_IDLE_STATE_COUNT 2
> +
> +static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;

Again, do not use the macro.

> +static struct cpuidle_state *cpuidle_state_table;
> +
> +static inline void idle_loop_prolog(unsigned long *in_purr)
> +{
> + *in_purr = mfspr(SPRN_PURR);
> + /*
> +  * Indicate to the HV that we are idle. Now would be
> +  * a good time to find other work to dispatch.
> +  */
> + get_lppaca()->idle = 1;
> +}
> +
> +static inline void idle_loop_epilog(unsigned long in_purr)
> +{
> + get_lppaca()->wait_state_cycles += mfspr(SPRN_PURR) - in_purr;
> + get_lppaca()->idle = 0;
> +}
> +
> +static int snooze_loop(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv,
> + int index)
> +{
> + unsigned long in_purr;
> +
> + idle_loop_prolog(&in_purr);
> + local_irq_enable();

snooze_loop has already registered in cpuidle framework to handle snooze state.
where disable the irq? Why do "enable" here?

> +/*
> + * States for dedicated partition case.
> + */
> +static struct cpuidle_state dedicated_states[MAX_IDLE_STATE_COUNT] = {
> + { /* Snooze */
> + .name = "snooze",
> + .desc = "snooze",
> + .flags = CPUIDLE_FLAG_TIME_VALID,
> + .exit_latency = 0,
> + .target_residency = 0,
> + .enter = &snooze_loop },
> + { /* CEDE */
> + .name = "CEDE",
> + .desc = "CEDE",
> + .flags = CPUIDLE_FLAG_TIME_VALID,
> + .exit_latency = 10,
> + .target_residency = 100,
> + .enter = &dedicated_cede_loop },
> +};
> +
> +/*
> + * States for shared partition case.
> + */
> +static struct cpuidle_state shared_states[MAX_IDLE_STATE_COUNT] = {
> + { /* Shared Cede */
> + .name = "Shared Cede",
> + .desc = "Shared Cede",
> + .flags = CPUIDLE_FLAG_TIME_VALID,
> + .exit_latency = 0,
> + .target_residency = 0,
> + .enter = &shared_cede_loop },
> +};
> +
> +static void __exit power_processor_idle_exit(void)
> +{
> +
> + unregister_cpu_notifier(&setup_hotplug_notifier);

Remove a blank line.

> + cpuidle_unregister(&power_idle_driver);
> + return;
> +}
> +
> +module_init(power_processor_idle_init);
> +module_exit(power_processor_idle_exit);
> +

Did you have tested the module? If not tested, please don't use the module.

> +MODULE_AUTHOR("Deepthi Dharwar ");
> +MODULE_DESCRIPTION("Cpuidle driver for IBM POWER platforms");
> +MODULE_LICENSE("GPL");
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, August 22, 2013 11:19 PM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Kumar Gala; Zhao Chenhui-B35336; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter
> altivec idle state
> 
> On Wed, 2013-08-21 at 22:13 -0500, Wang Dongsheng-B40534 wrote:
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, August 20, 2013 8:39 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Wood Scott-B07421; Kumar Gala; linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically
> > > enter altivec idle state
> > >
> > > It just seems wrong to have an ad-hoc mechanism for running
> > > core-specific code when we have cputable...  If we really need this,
> > > maybe we should add a "cpu_setup_late" function pointer.
> > >
> > > With your patch, when does the power management register get set
> > > when hot plugging a cpu?
> > >
> > Um.. I don't deal with this situation. I will fix it.
> > __setup/restore_cpu_e6500 looks good. But only bootcpu call
> __setup_cpu_e6500, not on each cpu.
> > I think this is a bug.
> 
> Other CPUs call __restore_cpu_e6500.
> 
No, there is bootcore of secondary thread, and other cores of first thread call 
__restore_cpu_e6500.
This flow is correct?

> > > > > As for the PVR check, the upstream kernel doesn't need to care
> > > > > about rev1, so knowing it's an e6500 is good enough.
> > > > >
> > > > But AltiVec idle & PW20 cannot work on rev1 platform.
> > > > We didn't have to deal with it?
> > >
> > > Upstream does not run on rev1.
> > >
> > :), But already have customers in the use of rev1.
> > Why we don't need to care about that?
> 
> rev1 is not production-qualified.  Those customers are supposed to only
> be using rev1 for evaluation and early development.  It's not that we
> don't care about rev1 now (we have the SDK for that) but that we won't
> care about it long-term and don't want to have to carry around a bunch of
> baggage for it.  Some of the workarounds are pretty nasty (especially A-
> 006198).
> 
Thanks.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, August 20, 2013 8:39 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Kumar Gala; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter
> altivec idle state
> 
> On Sun, 2013-08-18 at 21:53 -0500, Wang Dongsheng-B40534 wrote:
> > Thanks for your feedback.
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Saturday, August 17, 2013 12:51 AM
> > > To: Kumar Gala
> > > Cc: Wang Dongsheng-B40534; linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically
> enter
> > > altivec idle state
> > >
> > > On Fri, 2013-08-16 at 06:02 -0500, Kumar Gala wrote:
> > > > On Aug 16, 2013, at 2:23 AM, Dongsheng Wang wrote:
> > > >
> > > > > From: Wang Dongsheng 
> > > > >
> > > > > Each core's AltiVec unit may be placed into a power savings mode
> > > > > by turning off power to the unit. Core hardware will
> automatically
> > > > > power down the AltiVec unit after no AltiVec instructions have
> > > > > executed in N cycles. The AltiVec power-control is triggered by
> > > hardware.
> > > > >
> > > > > Signed-off-by: Wang Dongsheng 
> > > >
> > > > Why treat this as a idle HW governor vs just some one time setup at
> > > boot of the time delay?
> > >
> > > It is being done as one-time setup, despite the function name.
> > >
> > > Maybe it should be moved into __setup/restore_cpu_e6500 (BTW, we
> really
> > > should refactor those to reduce duplication) with the timebase bit
> > > number hardcoded rather than a time in us.
> > >
> > The frequency of the different platforms timebase is not the same.
> 
> It's close enough.  Remember, this number is a vague initial guess, not
> something that's been carefully calibrated.  Though, it would make it
> harder to substitute the number with one that's been more carefully
> calibrated...  but wouldn't different chips possibly have different
> optimal delays anyway?
> 
> > If we use it, we need to set different timebase bit on each platform.
> > That is why I did not put the code in __setup/restore_cpu_e6500, I need
> > use tb_ticks_per_usec to get timebase bit. So we only need to set a
> time
> > for each platform, and not set different timebase bit.
> 
> It just seems wrong to have an ad-hoc mechanism for running
> core-specific code when we have cputable...  If we really need this,
> maybe we should add a "cpu_setup_late" function pointer.
> 
> With your patch, when does the power management register get set when
> hot plugging a cpu?
> 
Um.. I don't deal with this situation. I will fix it.
__setup/restore_cpu_e6500 looks good. But only bootcpu call __setup_cpu_e6500, 
not on each cpu.
I think this is a bug.

Fix code:

diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 2cfed9e..2a9a718 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -603,6 +603,9 @@ __secondary_start:
/* Set thread priority to MEDIUM */
HMT_MEDIUM

+#ifdef CONFIG_PPC_BOOK3E
+   bl  call_setup_cpu  /* Call setup_cpu for this CPU */
+#endif
/* Initialize the kernel stack */
LOAD_REG_ADDR(r3, current_set)
sldir28,r24,3   /* get current_set[cpu#] */
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index b863b87..7d84bf4 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -55,6 +55,17 @@ _GLOBAL(call_handle_irq)
mtlrr0
blr

+_GLOBAL(call_setup_cpu)
+   LOAD_REG_ADDR(r4, cur_cpu_spec)
+   ld  r4, 0(r4)
+   ld  r5, CPU_SPEC_SETUP(r4)
+
+   cmpwi   0, r5, 0
+   beqlr
+   ld  r5, 0(r5)
+   mtctr   r5
+   bctr
+
.section".toc","aw"
 PPC64_CACHES:
.tc ppc64_caches[TC],ppc64_caches

> > > As for the PVR check, the upstream kernel doesn't need to care about
> > > rev1, so knowing it's an e6500 is good enough.
> > >
> > But AltiVec idle & PW20 cannot work on rev1 platform.
> > We didn't have to deal with it?
> 
> Upstream does not run on rev1.
> 
:), But already have customers in the use of rev1.
Why we don't need to care about that?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [RFC PATCH V3 3/5] powerpc/cpuidle: Generic powerpc backend cpuidle driver.

[Wang Dongsheng-B40534]

I think we should move the states and handle function to arch/power/platform*
The states and handle function is belong to backend driver, not for this, 
different platform have different state.
Different platforms to make their own deal with these states.

I think we cannot put all the status of different platforms and handler in this 
driver.

> diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
> index 0e2cd5c..99ee5d4 100644
> --- a/drivers/cpuidle/Kconfig
> +++ b/drivers/cpuidle/Kconfig
> @@ -42,6 +42,13 @@ config CPU_IDLE_ZYNQ
>   help
> Select this to enable cpuidle on Xilinx Zynq processors.
> 
> +config CPU_IDLE_POWERPC
> + bool "CPU Idle driver for POWERPC platforms"
> + depends on PPC64

Why not PPC?


> + default y
> +help
> +  Select this option to enable processor idle state management
> +   for POWERPC platform.
>  endif
> 
>  config ARCH_NEEDS_CPU_IDLE_COUPLED
> diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
> index 8767a7b..d12e205 100644
> --- a/drivers/cpuidle/Makefile
> +++ b/drivers/cpuidle/Makefile
> @@ -8,3 +8,5 @@ obj-$(CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED) += coupled.o
>  obj-$(CONFIG_CPU_IDLE_CALXEDA) += cpuidle-calxeda.o
>  obj-$(CONFIG_ARCH_KIRKWOOD) += cpuidle-kirkwood.o
>  obj-$(CONFIG_CPU_IDLE_ZYNQ) += cpuidle-zynq.o
> +
> +obj-$(CONFIG_CPU_IDLE_POWERPC) += cpuidle-powerpc.o
> diff --git a/drivers/cpuidle/cpuidle-powerpc.c b/drivers/cpuidle/cpuidle-
> powerpc.c
> new file mode 100644
> index 000..5756085
> --- /dev/null
> +++ b/drivers/cpuidle/cpuidle-powerpc.c
> @@ -0,0 +1,361 @@
> +/*
> + *  processor_idle - idle state cpuidle driver.
> + *  Adapted from drivers/idle/intel_idle.c and
> + *  drivers/acpi/processor_idle.c
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct cpuidle_driver powerpc_idle_driver = {
> + .name = "powerpc_idle",
> + .owner= THIS_MODULE,
> +};
> +
> +#define MAX_IDLE_STATE_COUNT 2
> +
> +static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
If this is a generic driver, do not define MAX_IDLE_STATE_COUNT, because we 
don't know how many state on other platforms.

How about using ARRAY_SIZE to get the max idle state?

> +static struct cpuidle_device __percpu *powerpc_cpuidle_devices;
> +static struct cpuidle_state *cpuidle_state_table;
> +
Should be remove all about *device*.
If the notifier handle using device, you can use 
"cpuidle_devices"(include/linux/cpuidle.h).

> +static inline void idle_loop_prolog(unsigned long *in_purr)
> +{
> + *in_purr = mfspr(SPRN_PURR);
> + /*
> +  * Indicate to the HV that we are idle. Now would be
> +  * a good time to find other work to dispatch.
> +  */
> + set_lppaca_idle(1);
> +}
> +
> +static inline void idle_loop_epilog(unsigned long in_purr)
> +{
> + add_lppaca_wait_state(mfspr(SPRN_PURR) - in_purr);
> + set_lppaca_idle(0);
> +}
> +
> +static int snooze_loop(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv,
> + int index)
> +{
> + unsigned long in_purr;
> +
> + idle_loop_prolog(&in_purr);
> + local_irq_enable();
> + set_thread_flag(TIF_POLLING_NRFLAG);
> +
> + while (!need_resched()) {
> + ppc64_runlatch_off();
> + HMT_low();
> + HMT_very_low();
> + }
> +
> + HMT_medium();
> + clear_thread_flag(TIF_POLLING_NRFLAG);
> + smp_mb();
> +
> + idle_loop_epilog(in_purr);
> +
> + return index;
> +}
> +
> +static void check_and_cede_processor(void)
> +{
> + /*
> +  * Ensure our interrupt state is properly tracked,
> +  * also checks if no interrupt has occurred while we
> +  * were soft-disabled
> +  */
> + if (prep_irq_for_idle()) {
> + cede_processor();
> +#ifdef CONFIG_TRACE_IRQFLAGS
> + /* Ensure that H_CEDE returns with IRQs on */
> + if (WARN_ON(!(mfmsr() & MSR_EE)))
> + __hard_irq_enable();
> +#endif
> + }
> +}
> +
> +static int dedicated_cede_loop(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv,
> + int index)
> +{
> + unsigned long in_purr;
> +
> + idle_loop_prolog(&in_purr);
> + set_lppaca_donate_dedicated_cpu(1);
> +
> + ppc64_runlatch_off();
> + HMT_medium();
> + check_and_cede_processor();
> +
> + set_lppaca_donate_dedicated_cpu(0);
> + idle_loop_epilog(in_purr);
> +
> + return index;
> +}
> +
> +static int shared_cede_loop(struct cpuidle_device *dev,
> + struct cpuidle_driver *drv,
> + int index)
> +{
> + unsigned long in_purr;
> +
> + idle_loop_prolog(&in_purr);
> +
> + /*
> +  * Yield the processor to the hypervisor.  We return if
> +  * an external i

RE: [PATCH] powerpc: add the missing required isync for the coherent icache flush

[Wang Dongsheng-B40534]

> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+b40534=freescale@lists.ozlabs.org] On Behalf Of Kevin Hao
> Sent: Thursday, August 15, 2013 7:56 PM
> To: Benjamin Herrenschmidt
> Cc: linuxppc
> Subject: [PATCH] powerpc: add the missing required isync for the coherent
> icache flush
> 
> Even we don't need to flush the dcache and invalidate the icache
> on the CPU which has coherent icache. But we do need an isync to
> discard the prefetched instructions in this case.
> 
> Signed-off-by: Kevin Hao 
> ---
>  arch/powerpc/kernel/misc_32.S | 2 ++
>  arch/powerpc/kernel/misc_64.S | 1 +
>  2 files changed, 3 insertions(+)
> 
> diff --git a/arch/powerpc/kernel/misc_32.S
> b/arch/powerpc/kernel/misc_32.S
> index 777d999..0b84c8d 100644
> --- a/arch/powerpc/kernel/misc_32.S
> +++ b/arch/powerpc/kernel/misc_32.S
> @@ -433,6 +433,7 @@ _GLOBAL(invalidate_dcache_range)
>   */
>  _GLOBAL(__flush_dcache_icache)
>  BEGIN_FTR_SECTION
> + isync
There is not touch the icache, why need we to do this?

>   blr
>  END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
>   rlwinm  r3,r3,0,0,31-PAGE_SHIFT /* Get page base address
> */
> @@ -474,6 +475,7 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_TYPE_44x)
>   */
>  _GLOBAL(__flush_dcache_icache_phys)
>  BEGIN_FTR_SECTION
> + isync
>   blr /* for 601, do nothing */
>  END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
>   mfmsr   r10
> diff --git a/arch/powerpc/kernel/misc_64.S
> b/arch/powerpc/kernel/misc_64.S
> index 992a78e..d74fefb 100644
> --- a/arch/powerpc/kernel/misc_64.S
> +++ b/arch/powerpc/kernel/misc_64.S
> @@ -69,6 +69,7 @@ PPC64_CACHES:
> 
>  _KPROBE(flush_icache_range)
>  BEGIN_FTR_SECTION
> + isync
>   blr
>  END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
>  /*
> --
> 1.8.3.1
> 
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state

[Wang Dongsheng-B40534]

Thanks for your feedback.

> -Original Message-
> From: Wood Scott-B07421
> Sent: Saturday, August 17, 2013 12:51 AM
> To: Kumar Gala
> Cc: Wang Dongsheng-B40534; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 1/2] powerpc/85xx: add hardware automatically enter
> altivec idle state
> 
> On Fri, 2013-08-16 at 06:02 -0500, Kumar Gala wrote:
> > On Aug 16, 2013, at 2:23 AM, Dongsheng Wang wrote:
> >
> > > From: Wang Dongsheng 
> > >
> > > Each core's AltiVec unit may be placed into a power savings mode
> > > by turning off power to the unit. Core hardware will automatically
> > > power down the AltiVec unit after no AltiVec instructions have
> > > executed in N cycles. The AltiVec power-control is triggered by
> hardware.
> > >
> > > Signed-off-by: Wang Dongsheng 
> >
> > Why treat this as a idle HW governor vs just some one time setup at
> boot of the time delay?
> 
> It is being done as one-time setup, despite the function name.
> 
> Maybe it should be moved into __setup/restore_cpu_e6500 (BTW, we really
> should refactor those to reduce duplication) with the timebase bit
> number hardcoded rather than a time in us.
> 
The frequency of the different platforms timebase is not the same.
If we use it, we need to set different timebase bit on each platform.
That is why I did not put the code in __setup/restore_cpu_e6500, I need
use tb_ticks_per_usec to get timebase bit. So we only need to set a time
for each platform, and not set different timebase bit.

> As for the PVR check, the upstream kernel doesn't need to care about
> rev1, so knowing it's an e6500 is good enough.
> 
But AltiVec idle & PW20 cannot work on rev1 platform.
We didn't have to deal with it?

-dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 2/2] powerpc/hibernate: add restore mmu context after resume

[Wang Dongsheng-B40534]

> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Saturday, July 13, 2013 7:07 AM
> To: Wood Scott-B07421
> Cc: Wang Dongsheng-B40534; Wood Scott-B07421; johan...@sipsolutions.net;
> an...@enomsg.org; ga...@kernel.crashing.org; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH 2/2] powerpc/hibernate: add restore mmu context after
> resume
> 
> On Fri, 2013-07-12 at 16:54 -0500, Scott Wood wrote:
> > set_context() doesn't exist for hash MMUs.
> >
> > Whatever you do, please try actually building it on various targets,
> > including both 32 and 64 bits, and both hash and non-hash.  And make
> > sure that whatever effect PPC32 was depending on switch_mmu_context
> > for
> > is preserved, including on non-booke.
> 
> The right thing to do is probably to have the various tlb_* files
How about mmu_context_* files to provide a pair of save/restore context 
functions?

> provide a pair of save/restore functions that do the right thing
> for that specific MMU type.
> 
> Ben.
> 
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] cpuidle: add freescale e500 family porcessors idle support

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 31, 2013 3:38 AM
> To: Wang Dongsheng-B40534
> Cc: r...@sisk.pl; daniel.lezc...@linaro.org; b...@kernel.crashing.org; Li
> Yang-R58472; Zhao Chenhui-B35336; linux...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH] cpuidle: add freescale e500 family porcessors idle
> support
> 
> On 07/30/2013 02:00:03 AM, Dongsheng Wang wrote:
> > From: Wang Dongsheng 
> >
> > Add cpuidle support for e500 family, using cpuidle framework to
> > manage various low power modes. The new implementation will remain
> > compatible with original idle method.
> >
> > Initially, this supports PW10, and subsequent patches will support
> > PW20/DOZE/NAP.
> 
> Could you explain what the cpuidle framework does for us that the
> current idle code doesn't?
> 

The current idle code, Only a state of low power can make the core idle.
The core can't get into more low power state.

> In particular, what scenario do you see where we would require a
> software
> governor to choose between idle states, and how much power is saved
> compared to a simpler approach?  There is timer that can be used to
> automatically enter PW20 after a certain amount of time in PW10.

Yes, the hardware can automatically enter PW20 state. But this is hardware
feature, we need to software to manage it. Only for PW20 state, we can drop
this cpuidle and using the hardware to control it. But if we need to support
PH10/PH15/PH20/PH30, the current idle code cannot support them. 

> How much better results do you get from a software governor?  Do we even
> have the right data to characterize each state so that a software governor
> could make good decisions?  Is cpuidle capable of governing the interval
> of such a timer, rather than directly governing states?
> 
>From now on we did not benchmark these data, because we only have PW10 state.

I can do support doze/nap for e6500. To get some data to show you.

> As for doze/nap, why would we want to use those on newer cores?  Do you
> have numbers for how much power each mode saves?
> 
The PH state is plan to support, if the core can make into more low power state,
why not to do this.

PH10(doze)/PH15(nap)/PH20/PH30, These states can save more CPU power.

> Active governors may be useful on older cores that only have doze/nap,
> to
> select between them, but if that's the use case then why start with
> pw10?
Pw10 is supported on E500MC/E5500/E6500. And we plan to support PW20 for E65OO 
core.
I will take doze/nap up a bit later.

> And I'd want to see numbers for how much power nap saves versus doze.
> 
> > Signed-off-by: Wang Dongsheng 
> > ---
> > This patch keep using cpuidle_register_device(), because we need to
> > support cpu
> > hotplug. I will fix "device" issue in this driver, after
> > Deepthi Dharwar  add a hotplug handler
> > into cpuidle
> > freamwork.
> 
> Where's the diffstat?
> 
See, http://patchwork.ozlabs.org/patch/260997/

> > @@ -0,0 +1,222 @@
> > +/*
> > + * Copyright 2013 Freescale Semiconductor, Inc.
> > + *
> > + * CPU Idle driver for Freescale PowerPC e500 family processors.
> > + *
> > + * This program is free software; you can redistribute it and/or
> > modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * Author: Wang Dongsheng 
> > + */
> 
> Is this derived from some other file?  It looks like it...  Where's the
> attribution?
> 
The copyright is from drivers/cpufreq/ppc-corenet-cpufreq.c

> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +static struct cpuidle_driver e500_idle_driver = {
> > +   .name = "e500_idle",
> > +   .owner = THIS_MODULE,
> > +};
> > +
> > +static struct cpuidle_device __percpu *e500_cpuidle_devices;
> > +
> > +static void e500_cpuidle(void)
> > +{
> > +   /*
> > +* This would call on the cpuidle framework, and the back-end
> > +* driver to go to idle states.
> > +*/
> > +   if (cpuidle_idle_call()) {
> > +   /*
> > +* On error, execute default handler
> > +* to go into low thread priority and possibly
> > +* low power mode.
> > +*/
> > +   HMT_low();
> > +   HMT_very_low();
> 
> This HMT stuff doesn't do anything on e500 derivatives AFAIK.
> 
Yes, there should do nothing, let arch_cpu

RE: [PATCH V2 4/6] cpuidle/pseries: Move the pseries_idle backend driver to sysdev.

[Wang Dongsheng-B40534]

Hi Preeti,

> -Original Message-
> From: Preeti U Murthy [mailto:pre...@linux.vnet.ibm.com]
> Sent: Wednesday, July 31, 2013 12:00 PM
> To: Wang Dongsheng-B40534
> Cc: Deepthi Dharwar; b...@kernel.crashing.org; daniel.lezc...@linaro.org;
> linux-ker...@vger.kernel.org; mich...@ellerman.id.au;
> srivatsa.b...@linux.vnet.ibm.com; sva...@linux.vnet.ibm.com; linuxppc-
> d...@lists.ozlabs.org; r...@sisk.pl; linux...@vger.kernel.org
> Subject: Re: [PATCH V2 4/6] cpuidle/pseries: Move the pseries_idle
> backend driver to sysdev.
> 
> Hi Dongsheng,
> 
> On 07/31/2013 08:52 AM, Wang Dongsheng-B40534 wrote:
> >
> >
> >> -Original Message-
> >> From: Deepthi Dharwar [mailto:deep...@linux.vnet.ibm.com]
> >> Sent: Wednesday, July 31, 2013 10:59 AM
> >> To: b...@kernel.crashing.org; daniel.lezc...@linaro.org; linux-
> >> ker...@vger.kernel.org; mich...@ellerman.id.au;
> >> srivatsa.b...@linux.vnet.ibm.com; pre...@linux.vnet.ibm.com;
> >> sva...@linux.vnet.ibm.com; linuxppc-dev@lists.ozlabs.org
> >> Cc: r...@sisk.pl; Wang Dongsheng-B40534; linux...@vger.kernel.org
> >> Subject: [PATCH V2 4/6] cpuidle/pseries: Move the pseries_idle
> >> backend driver to sysdev.
> >>
> >> Move pseries_idle backend driver code to arch/powerpc/sysdev so that
> >> the code can be used for a common driver for powernv and pseries.
> >> This removes a lot of code duplicacy.
> >>
> > Why not drivers/cpuidle/?
> >
> > I think it should be move to drivers/cpuidle.
> 
> Please take a look at what the cpuidle under drivers has to provide.
> cpuidle has two parts to it. The front end and the back end. The front
> end constitutes the cpuidle governors, registering of arch specific
> cpuidle drivers, disabling and enabling of cpuidle feature. It is this
> front end code which is present under drivers/cpuidle.
> 
> The arch specific cpuidle drivers which decide what needs to be done to
> enter a specific idle state chosen by the cpuidle governor is what
> constitutes the back end of cpuidle. This will not be in drivers/cpuidle
> but in an arch/ specific code.
> 
> The cpuidle under drivers/cpuidle drives the idle power management, but
> the low level handling of the entry into idle states should be taken care
> of by the architecture.
> 
> Your recent patch :
> cpuidle: add freescale e500 family porcessors idle support IMO should
> hook onto the backend cpuidle driver that this patchset provides.
> 
Sorry, I don't think so, cpuidle framework has been already very common.
Here we just need to do state definition and handling. I wonder whether
we need this layer.

If your handle is platform dependent, it should be in arch/platform.

If it is only for some platforms and the operation of these platforms can be
multiplexed, Why cannot as a driver to put into driver/cpuidle?

If it a general driver, I think we can put some common operating to 
driver/cpuidle
and make the platform specific code to arch/powerpc/platform.

This patch include front end and back end, not just back end.

This patch include too many state of different platforms and handle function. 
This state
and handle that should belong to itself platforms. Not a general way. If 
Deepthi will do
a general powerpc cpuidle, I think, it's cannot just using the macro to 
distinguish
platform. the front end code maybe move to driver/cpuidle(drvier register) 
should be better,
make the Low Power State and what should be handle to arch/powerpc/platform/**, 
because different
platforms have different state of low power consumption, and the processing 
method.
The front end can provide some general methods to register into general powerpc 
cpuidle driver.

-dongsheng

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH V2 5/6] cpuidle/powerpc: Backend-powerpc idle driver for powernv and pseries.

[Wang Dongsheng-B40534]

> 
> -static int pseries_cpuidle_add_cpu_notifier(struct notifier_block *n,
> +static int powerpc_cpuidle_add_cpu_notifier(struct notifier_block *n,
>   unsigned long action, void *hcpu)
>  {
>   int hotcpu = (unsigned long)hcpu;
>   struct cpuidle_device *dev =
> - per_cpu_ptr(pseries_cpuidle_devices, hotcpu);
> + per_cpu_ptr(powerpc_cpuidle_devices, hotcpu);
> 
>   if (dev && cpuidle_get_driver()) {
>   switch (action) {
> @@ -235,16 +270,16 @@ static int pseries_cpuidle_add_cpu_notifier(struct
> notifier_block *n,
>  }
> 
>  static struct notifier_block setup_hotplug_notifier = {
> - .notifier_call = pseries_cpuidle_add_cpu_notifier,
> + .notifier_call = powerpc_cpuidle_add_cpu_notifier,
>  };
> 
I think Daniel means move the notifier to cpuidle framework, not just powerpc.

And should be remove all about *device*. If the notifier handle using device,
you can use "cpuidle_devices".

- dongsheng

> -static int __init pseries_processor_idle_init(void)
> +static int __init powerpc_processor_idle_init(void)
>  {
>   int retval;
> 
> - retval = pseries_idle_probe();
> + retval = powerpc_idle_probe();
>   if (retval)
>   return retval;
> 
> - pseries_cpuidle_driver_init();
> - retval = cpuidle_register_driver(&pseries_idle_driver);
> + powerpc_cpuidle_driver_init();
> + retval = cpuidle_register_driver(&powerpc_idle_driver);
>   if (retval) {
> - printk(KERN_DEBUG "Registration of pseries driver failed.\n");
> + printk(KERN_DEBUG "Registration of powerpc driver failed.\n");
>   return retval;
>   }
> 
>   update_smt_snooze_delay(-1, per_cpu(smt_snooze_delay, 0));
> 
> - retval = pseries_idle_devices_init();
> + retval = powerpc_idle_devices_init();
Should be remove all *device*, using cpuidle_register.

- dongsheng

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH V2 4/6] cpuidle/pseries: Move the pseries_idle backend driver to sysdev.

[Wang Dongsheng-B40534]

> -Original Message-
> From: Deepthi Dharwar [mailto:deep...@linux.vnet.ibm.com]
> Sent: Wednesday, July 31, 2013 10:59 AM
> To: b...@kernel.crashing.org; daniel.lezc...@linaro.org; linux-
> ker...@vger.kernel.org; mich...@ellerman.id.au;
> srivatsa.b...@linux.vnet.ibm.com; pre...@linux.vnet.ibm.com;
> sva...@linux.vnet.ibm.com; linuxppc-dev@lists.ozlabs.org
> Cc: r...@sisk.pl; Wang Dongsheng-B40534; linux...@vger.kernel.org
> Subject: [PATCH V2 4/6] cpuidle/pseries: Move the pseries_idle backend
> driver to sysdev.
> 
> Move pseries_idle backend driver code to arch/powerpc/sysdev
> so that the code can be used for a common driver for powernv
> and pseries. This removes a lot of code duplicacy.
> 
Why not drivers/cpuidle/?

I think it should be move to drivers/cpuidle.

-dongsheng

> Signed-off-by: Deepthi Dharwar 
> ---
>  arch/powerpc/platforms/pseries/Kconfig  |9 -
>  arch/powerpc/platforms/pseries/Makefile |1
>  arch/powerpc/platforms/pseries/processor_idle.c |  384 -
> --
>  arch/powerpc/sysdev/Kconfig |9 +
>  arch/powerpc/sysdev/Makefile|1
>  arch/powerpc/sysdev/processor_idle.c|  384
> +++
>  6 files changed, 394 insertions(+), 394 deletions(-)
>  delete mode 100644 arch/powerpc/platforms/pseries/processor_idle.c
>  create mode 100644 arch/powerpc/sysdev/processor_idle.c
> 
> diff --git a/arch/powerpc/platforms/pseries/Kconfig
> b/arch/powerpc/platforms/pseries/Kconfig
> index 62b4f80..bb59bb0 100644
> --- a/arch/powerpc/platforms/pseries/Kconfig
> +++ b/arch/powerpc/platforms/pseries/Kconfig
> @@ -119,12 +119,3 @@ config DTL
> which are accessible through a debugfs file.
> 
> Say N if you are unsure.
> -
> -config PSERIES_IDLE
> - bool "Cpuidle driver for pSeries platforms"
> - depends on CPU_IDLE
> - depends on PPC_PSERIES
> - default y
> - help
> -   Select this option to enable processor idle state management
> -   through cpuidle subsystem.
> diff --git a/arch/powerpc/platforms/pseries/Makefile
> b/arch/powerpc/platforms/pseries/Makefile
> index 8ae0103..4b22379 100644
> --- a/arch/powerpc/platforms/pseries/Makefile
> +++ b/arch/powerpc/platforms/pseries/Makefile
> @@ -21,7 +21,6 @@ obj-$(CONFIG_HCALL_STATS)   += hvCall_inst.o
>  obj-$(CONFIG_CMM)+= cmm.o
>  obj-$(CONFIG_DTL)+= dtl.o
>  obj-$(CONFIG_IO_EVENT_IRQ)   += io_event_irq.o
> -obj-$(CONFIG_PSERIES_IDLE)   += processor_idle.o
> 
>  ifeq ($(CONFIG_PPC_PSERIES),y)
>  obj-$(CONFIG_SUSPEND)+= suspend.o
> diff --git a/arch/powerpc/platforms/pseries/processor_idle.c
> b/arch/powerpc/platforms/pseries/processor_idle.c
> deleted file mode 100644
> index 0d75a54..000
> --- a/arch/powerpc/platforms/pseries/processor_idle.c
> +++ /dev/null
> @@ -1,384 +0,0 @@
> -/*
> - *  processor_idle - idle state cpuidle driver.
> - *  Adapted from drivers/idle/intel_idle.c and
> - *  drivers/acpi/processor_idle.c
> - *
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -/* Snooze Delay, pseries_idle */
> -DECLARE_PER_CPU(long, smt_snooze_delay);
> -
> -struct cpuidle_driver pseries_idle_driver = {
> - .name = "pseries_idle",
> - .owner= THIS_MODULE,
> -};
> -
> -#define MAX_IDLE_STATE_COUNT 2
> -
> -static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
> -static struct cpuidle_device __percpu *pseries_cpuidle_devices;
> -static struct cpuidle_state *cpuidle_state_table;
> -
> -static inline void idle_loop_prolog(unsigned long *in_purr)
> -{
> - *in_purr = mfspr(SPRN_PURR);
> - /*
> -  * Indicate to the HV that we are idle. Now would be
> -  * a good time to find other work to dispatch.
> -  */
> - get_lppaca()->idle = 1;
> -}
> -
> -static inline void idle_loop_epilog(unsigned long in_purr)
> -{
> - get_lppaca()->wait_state_cycles += mfspr(SPRN_PURR) - in_purr;
> - get_lppaca()->idle = 0;
> -}
> -
> -static int snooze_loop(struct cpuidle_device *dev,
> - struct cpuidle_driver *drv,
> - int index)
> -{
> - unsigned long in_purr;
> - int cpu = dev->cpu;
> -
> - idle_loop_prolog(&in_purr);
> - local_irq_enable();
> - set_thread_flag(TIF_POLLING_NRFLAG);
> -
> - while ((!need_resched()) && cpu_online(cpu)) {
> - ppc64_runlatch_off();
> 

RE: [PATCH] cpuidle: add freescale e500 family porcessors idle support

[Wang Dongsheng-B40534]

> -Original Message-
> From: Daniel Lezcano [mailto:daniel.lezc...@linaro.org]
> Sent: Tuesday, July 30, 2013 5:51 PM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; r...@sisk.pl; b...@kernel.crashing.org; Li Yang-
> R58472; Zhao Chenhui-B35336; linux...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH] cpuidle: add freescale e500 family porcessors idle
> support
> 
> On 07/30/2013 09:00 AM, Dongsheng Wang wrote:
> > From: Wang Dongsheng 
> >
> > Add cpuidle support for e500 family, using cpuidle framework to manage
> > various low power modes. The new implementation will remain compatible
> > with original idle method.
> >
> > Initially, this supports PW10, and subsequent patches will support
> > PW20/DOZE/NAP.
> >
> > Signed-off-by: Wang Dongsheng 
> > ---
> > This patch keep using cpuidle_register_device(), because we need to
> > support cpu hotplug. I will fix "device" issue in this driver, after
> > Deepthi Dharwar  add a hotplug handler
> > into cpuidle freamwork.
> >
> > diff --git a/arch/powerpc/include/asm/machdep.h
> > b/arch/powerpc/include/asm/machdep.h
> > index 8b48090..cbdbe25 100644
> > --- a/arch/powerpc/include/asm/machdep.h
> > +++ b/arch/powerpc/include/asm/machdep.h
> > @@ -271,6 +271,16 @@ extern void power7_idle(void);  extern void
> > ppc6xx_idle(void);  extern void book3e_idle(void);
> >
> > +/* Wait for Interrupt */
> > +static inline void fsl_cpuidle_wait(void) { #ifdef CONFIG_PPC64
> > +   book3e_idle();
> > +#else
> > +   e500_idle();
> > +#endif
> > +}
> > +
> >  /*
> >   * ppc_md contains a copy of the machine description structure for the
> >   * current platform. machine_id contains the initial address where the
> > diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
> > index b3fb81d..7ed114b 100644
> > --- a/drivers/cpuidle/Kconfig
> > +++ b/drivers/cpuidle/Kconfig
> > @@ -35,6 +35,11 @@ depends on ARM
> >  source "drivers/cpuidle/Kconfig.arm"
> >  endmenu
> >
> > +menu "PowerPC CPU Idle Drivers"
> > +depends on PPC32 || PPC64
> > +source "drivers/cpuidle/Kconfig.powerpc"
> > +endmenu
> > +
> >  endif
> >
> >  config ARCH_NEEDS_CPU_IDLE_COUPLED
> > diff --git a/drivers/cpuidle/Kconfig.powerpc
> b/drivers/cpuidle/Kconfig.powerpc
> > new file mode 100644
> > index 000..9f3f5ef
> > --- /dev/null
> > +++ b/drivers/cpuidle/Kconfig.powerpc
> > @@ -0,0 +1,9 @@
> > +#
> > +# PowerPC CPU Idle drivers
> > +#
> > +
> > +config PPC_E500_CPUIDLE
> > +   bool "CPU Idle Driver for E500 family processors"
> > +   depends on FSL_SOC_BOOKE
> > +   help
> > + Select this to enable cpuidle on e500 family processors.
> > diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
> > index 0b9d200..0dde3db 100644
> > --- a/drivers/cpuidle/Makefile
> > +++ b/drivers/cpuidle/Makefile
> > @@ -11,3 +11,7 @@ obj-$(CONFIG_ARM_HIGHBANK_CPUIDLE)+= cpuidle-
> calxeda.o
> >  obj-$(CONFIG_ARM_KIRKWOOD_CPUIDLE) += cpuidle-kirkwood.o
> >  obj-$(CONFIG_ARM_ZYNQ_CPUIDLE) += cpuidle-zynq.o
> >  obj-$(CONFIG_ARM_U8500_CPUIDLE) += cpuidle-ux500.o
> > +
> >
> +
> ##
> > +# PowerPC platform drivers
> > +obj-$(CONFIG_PPC_E500_CPUIDLE) += cpuidle-e500.o
> > diff --git a/drivers/cpuidle/cpuidle-e500.c b/drivers/cpuidle/cpuidle-
> e500.c
> > new file mode 100644
> > index 000..1919cea
> > --- /dev/null
> > +++ b/drivers/cpuidle/cpuidle-e500.c
> > @@ -0,0 +1,222 @@
> > +/*
> > + * Copyright 2013 Freescale Semiconductor, Inc.
> > + *
> > + * CPU Idle driver for Freescale PowerPC e500 family processors.
> > + *
> > + * This program is free software; you can redistribute it and/or
> modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + *
> > + * Author: Wang Dongsheng 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +static struct cpuidle_driver e500_idle_driver = {
> > +   .name = "e500_idle",
> > +   .owner = THIS_MODULE,
> > +};
> > +
> > +static struct cpuidle_device __percpu *e500_cpuidle_devices;
&g

RE: [PATCH] cpuidle: fix unremovable issue for module driver

[Wang Dongsheng-B40534]

> -Original Message-
> From: Daniel Lezcano [mailto:daniel.lezc...@linaro.org]
> Sent: Tuesday, July 30, 2013 5:28 PM
> To: Wang Dongsheng-B40534
> Cc: r...@sisk.pl; linux...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] cpuidle: fix unremovable issue for module driver
> 
> On 07/30/2013 08:55 AM, Dongsheng Wang wrote:
> > From: Wang Dongsheng 
> >
> > After __cpuidle_register_device, the cpu incs are added up, but decs
> > are not, thus the module refcount is not match. So the module "exit"
> > function can not be executed when we do remove operation. Move
> > module_put into __cpuidle_register_device to fix it.
> 
> Sorry, I still don't get it :/
> 
> register->module_get
> unregister->module_put
> 
> you change it by:
> 
> register->module_get
> register->module_put
> unregister->none
> 
> which is wrong.
> 
module_get->set per cpu incs=1
module_put->set per cpu decs=1

module_refcount-> incs - decs;

"unregister" usually call in module->exit function. 
But if module_refcount is not zero, the module->exit() cannot be executed.

See, kernel/module.c +874
delete_module()-->try_stop_module();

Test Log:
root:~# rmmod cpuidle-e500
module_refcount: incs[9], decs[1]
rmmod: can't unload 'cpuidle_e500': Resource temporarily unavailable

> Can you describe the problem you are facing ? (a bit more than "I can't
> unload the module").
> 
> > Signed-off-by: Wang Dongsheng 
> >
> > diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> > index d75040d..e964ada 100644
> > --- a/drivers/cpuidle/cpuidle.c
> > +++ b/drivers/cpuidle/cpuidle.c
> > @@ -351,11 +351,8 @@ EXPORT_SYMBOL_GPL(cpuidle_disable_device);
> >
> >  static void __cpuidle_unregister_device(struct cpuidle_device *dev)
> > {
> > -   struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
> > -
> > list_del(&dev->device_list);
> > per_cpu(cpuidle_devices, dev->cpu) = NULL;
> > -   module_put(drv->owner);
> >  }
> >
> >  static int __cpuidle_device_init(struct cpuidle_device *dev) @@
> > -384,6 +381,8 @@ static int __cpuidle_register_device(struct
> cpuidle_device *dev)
> > per_cpu(cpuidle_devices, dev->cpu) = dev;
> > list_add(&dev->device_list, &cpuidle_detected_devices);
> >
> > +   module_put(drv->owner);
> > +
> > ret = cpuidle_coupled_register_device(dev);
> > if (ret) {
> > __cpuidle_unregister_device(dev);
> >
> 
> 
> --
>  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
> 
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [RFC 1/2] fsl/pm: combined the idle(PH&PW) state

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, July 30, 2013 1:22 AM
> To: Wang Dongsheng-B40534
> Cc: b...@kernel.crashing.org; ga...@kernel.crashing.org; Zhao Chenhui-
> B35336; Li Yang-R58472; Wang Dongsheng-B40534
> Subject: Re: [RFC 1/2] fsl/pm: combined the idle(PH&PW) state
> 
> On 07/10/2013 03:27:55 AM, Dongsheng Wang wrote:
> > From: Wang Dongsheng 
> >
> > move wait instructions from idle_e500.S to idle_book3e.S
> >
> > idle_e500.S: rename e500_idle to e500_idle_ph.
> 
> What does _ph mean?
> 
> If this is a reference to the new PHnn/PWnn terminology used on e6500, I
> don't see how that's relevant to this file, which isn't used on e6500.
> Or if you do plan to use this on e6500, why?
> 
ph10/ph15 means doze/nap on freescale e500 family processors. On the IBM
platform does not "ph" concept.

Yes, "ph" maybe that's not a good idea. We should keep e500_idle.
On e500 processor, there is doze/nap, but e500mc/e5500/e6500 is using "wait".

I want to move "wait" from idle_e500.S into idle_book3e.S, but "book3e" means
64bit mode... Now 32bit using idle_e500, 64bit using idle_book3e, and the idle 
method
does not distinguish according to the platform, only in accordance with the CPU
running mode(32bit/64bit) to distinguish.

So did you have any idea about this? Or another way as follows,

We do not touch idle_e500.S and idle_e6500.S, add fsl_cpuidle_wait() into 
"machdep.h"

arch/powerpc/include/asm/machdep.h
/* Wait for Interrupt */
static inline void fsl_cpuidle_wait(void)
{
#ifdef CONFIG_PPC64
book3e_idle();
#else
e500_idle();
#endif
}

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel features

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, July 30, 2013 1:27 AM
> To: Wang Dongsheng-B40534
> Cc: b...@kernel.crashing.org; ga...@kernel.crashing.org; Zhao Chenhui-
> B35336; Li Yang-R58472; Wang Dongsheng-B40534
> Subject: Re: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel
> features
> 
> On 07/10/2013 03:27:56 AM, Dongsheng Wang wrote:
> > From: Wang Dongsheng 
> >
> > Signed-off-by: Wang Dongsheng 
> >
> > diff --git a/arch/powerpc/include/asm/cputable.h
> > b/arch/powerpc/include/asm/cputable.h
> > index 6f3887d..0a8d0cb 100644
> > --- a/arch/powerpc/include/asm/cputable.h
> > +++ b/arch/powerpc/include/asm/cputable.h
> > @@ -138,6 +138,7 @@ extern const char *powerpc_base_platform;
> >  #define CPU_FTR_NOEXECUTE  ASM_CONST(0x1000)
> >  #define CPU_FTR_INDEXED_DCRASM_CONST(0x2000)
> >  #define CPU_FTR_EMB_HV ASM_CONST(0x4000)
> > +#define CPU_FTR_CAN_WAIT   ASM_CONST(0x8000)
> 
> Note that this is the last 32-bit CPU feature flag; it's time to start
> thinking about other mechanisms.  We should probably reserve feature
> flags for things that need to use code patching due to being on a
> performance critical path, and move other things into struct cpu_spec.
> CPU_FTR_CAN_WAIT seems like a good candidate to be moved.
> 
First of all, why should I do, I need to distinguish between the core, which
is to support the wait instruction. The CPU_FTR_CAN_WAIT looks easy.

How to fix this problem:
1/ I can drop this cpu feature, and move it into struct cpu_spec.
Add a pm_feature in struct cpu_spec? like,

struct cpu_spec {
...
unsigned long pm_features;
...
}

2/ Drop this cpu feature, using CPU_FTRS_E6500/CPU_FTRS_E5500.. to distinguish 
wait or doze/nap.
Like,

CPU_FTRS_E500/CPU_FTRS_E500_2 support doze/nap.

CPU_FTRS_E500MC/CPU_FTRS_E5500/CPU_FTRS_E6500 support wait.

If using this method, inside the cpuidle driver needs to do a lot of judgment. 
So I'm not sure this
is a very good solution.

Thanks.
- dongsheng

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 1/2] cpuidle: fix cpu idle driver as a module can not remove

[Wang Dongsheng-B40534]

> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Wednesday, July 24, 2013 5:33 AM
> To: Wang Dongsheng-B40534
> Cc: daniel.lezc...@linaro.org; linux...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH 1/2] cpuidle: fix cpu idle driver as a module can not
> remove
> 
> On Tuesday, July 23, 2013 05:28:00 PM Dongsheng Wang wrote:
> > From: Wang Dongsheng 
> >
> > The module can not be removed when execute "rmmod". rmmod not use
> > "--force".
> >
> > Log:
> > root:~# rmmod cpuidle-e500
> > incs[9], decs[1]
> > rmmod: can't unload 'cpuidle_e500': Resource temporarily unavailable
> >
> > Signed-off-by: Wang Dongsheng 
> 
> Can you please check the current linux-next branch of the linux-pm.git
> tree
> and see if that doesn't conflict with the material in there?
> 
> Also please explain in the changelog how your changes help to fix the
> problem.
> 
Yes, Linux-next branch also have this problem.

Should I base on Linux-next to fix this problem?

Thanks.
- dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 2/2] cpuidle: export cpuidle_idle_call symbol

[Wang Dongsheng-B40534]

> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@sisk.pl]
> Sent: Wednesday, July 24, 2013 5:33 AM
> To: Wang Dongsheng-B40534
> Cc: daniel.lezc...@linaro.org; linux...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH 2/2] cpuidle: export cpuidle_idle_call symbol
> 
> On Tuesday, July 23, 2013 05:28:01 PM Dongsheng Wang wrote:
> > From: Wang Dongsheng 
> >
> > Export cpuidle_idle_call symbol, make this function can be invoked in
> > the module.
> 
> Why?
> 
On powerpc platform, there is already have cpu idle implementation.

I want use cpuidle framework to control various low power modes. But need to
be compatible with the current implementation. And driver should be as a module,
The user can using this module at any time.

We need cpuidle_idle_call to drive the new implementation in modules.

Thanks.
- dongsheng

> Rafael


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 1/2] powerpc: add Book E support to 64-bit hibernation

[Wang Dongsheng-B40534]

> From: Wood Scott-B07421
> Sent: Saturday, July 13, 2013 5:49
> To: Wang Dongsheng-B40534
> Cc: b...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang 
> Dongsheng-B40534
> Subject: Re: [PATCH v2 1/2] powerpc: add Book E support to 64-bit hibernation
>
> On 07/11/2013 11:58:08 PM, Dongsheng Wang wrote:
>> + /* Invalidate all tlbs */
>> + bl  _tlbil_all
>
> Again, this will break on non-booke.
>
> -Scott

Thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 2/2] powerpc/hibernate: add restore mmu context after resume

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, July 11, 2013 5:43 AM
> To: Wang Dongsheng-B40534
> Cc: Wang Dongsheng-B40534; b...@kernel.crashing.org; Wood Scott-B07421;
> johan...@sipsolutions.net; an...@enomsg.org; ga...@kernel.crashing.org;
> linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 2/2] powerpc/hibernate: add restore mmu context after
> resume
> 
> On 07/10/2013 05:11:54 AM, Wang Dongsheng-B40534 wrote:
> > Hi scott & ben,
> >
> > About this patch do you have any suggestions?
> >
> > Thanks
> >
> > - dongsheng
> >
> > > -Original Message-
> > > From: Wang Dongsheng-B40534
> > > Sent: Sunday, June 09, 2013 6:38 PM
> > > To: b...@kernel.crashing.org
> > > Cc: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421;
> > > ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang
> > Dongsheng-
> > > B40534
> > > Subject: [PATCH 2/2] powerpc/hibernate: add restore mmu context
> > after
> > > resume
> > >
> > > add restore_mmu_context to replace switch_mmu_context in
> > > restore_processor_state, because the switch_mmu_context will do a
> > > whole pile of stuff that are probably completely unnecessary.
> > >
> > > There just need to restore the existing process context, and
> > > invalidate TLB for boot core.
> > >
> > > Signed-off-by: Wang Dongsheng 
> > > ---
> > >  arch/powerpc/include/asm/tlbflush.h |  2 ++
> > >  arch/powerpc/kernel/swsusp.c|  4 +---
> > >  arch/powerpc/mm/tlb_nohash.c| 12 
> > >  3 files changed, 15 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/powerpc/include/asm/tlbflush.h
> > > b/arch/powerpc/include/asm/tlbflush.h
> > > index 61a5927..c401fe3 100644
> > > --- a/arch/powerpc/include/asm/tlbflush.h
> > > +++ b/arch/powerpc/include/asm/tlbflush.h
> > > @@ -44,6 +44,8 @@ extern void local_flush_tlb_page(struct
> > vm_area_struct
> > > *vma, unsigned long vmadd
> > >  extern void __local_flush_tlb_page(struct mm_struct *mm, unsigned
> > long
> > > vmaddr,
> > >  int tsize, int ind);
> > >
> > > +extern void restore_mmu_context(void);
> > > +
> > >  #ifdef CONFIG_SMP
> > >  extern void flush_tlb_mm(struct mm_struct *mm);  extern void
> > > flush_tlb_page(struct vm_area_struct *vma, unsigned
> > long
> > > vmaddr);
> > > diff --git a/arch/powerpc/kernel/swsusp.c
> > b/arch/powerpc/kernel/swsusp.c
> > > index eae33e1..0b104d7 100644
> > > --- a/arch/powerpc/kernel/swsusp.c
> > > +++ b/arch/powerpc/kernel/swsusp.c
> > > @@ -32,7 +32,5 @@ void save_processor_state(void)
> > >
> > >  void restore_processor_state(void)
> > >  {
> > > -#ifdef CONFIG_PPC32
> > > - switch_mmu_context(current->active_mm, current->active_mm);
> > > -#endif
> > > + restore_mmu_context();
> > >  }
> > > diff --git a/arch/powerpc/mm/tlb_nohash.c
> > b/arch/powerpc/mm/tlb_nohash.c
> > > index df32a83..a5a0708 100644
> > > --- a/arch/powerpc/mm/tlb_nohash.c
> > > +++ b/arch/powerpc/mm/tlb_nohash.c
> > > @@ -39,10 +39,12 @@
> > >  #include 
> > >  #include 
> > >
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >
> > >  #include "mmu_decl.h"
> > >
> > > @@ -193,6 +195,16 @@ void local_flush_tlb_page(struct
> > vm_area_struct *vma,
> > > unsigned long vmaddr)
> > >  }
> > >  EXPORT_SYMBOL(local_flush_tlb_page);
> > >
> > > +void restore_mmu_context(void)
> > > +{
> > > + struct mm_struct *mm = current->active_mm;
> > > +
> > > + set_context(mm->context.id, mm->pgd);
> > > +
> > > + _tlbil_all();
> > > +}
> > > +EXPORT_SYMBOL(restore_mmu_context);
> 
> What about targets that don't use tlb_nohash.c?
> 
Yes, you are right, if we used PPC_STD_MMU, compilation error will occur.
And _tlbil_all should be remove, because all of the tlb already invalidated in 
swsusp_*.S .
So we should invalid tlb in swsusp_asm64.S & swsusp_booke.S on freescale 
platform.

How about add restore_mmu_context(struct mm_struct* mm) into 
"arch/powerpc/include/asm/mmu_context.h"

Path: arch/powerpc/include/asm/mmu_context.h
static void restore_mmu_context(struct mm_struct *mm)
{
   set_context(mm->context.id, mm->pgd);
}

> -Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 2/2] powerpc/hibernate: add restore mmu context after resume

[Wang Dongsheng-B40534]

Hi scott & ben,

About this patch do you have any suggestions?

Thanks

- dongsheng

> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Sunday, June 09, 2013 6:38 PM
> To: b...@kernel.crashing.org
> Cc: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421;
> ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-
> B40534
> Subject: [PATCH 2/2] powerpc/hibernate: add restore mmu context after
> resume
> 
> add restore_mmu_context to replace switch_mmu_context in
> restore_processor_state, because the switch_mmu_context will do
> a whole pile of stuff that are probably completely unnecessary.
> 
> There just need to restore the existing process context, and
> invalidate TLB for boot core.
> 
> Signed-off-by: Wang Dongsheng 
> ---
>  arch/powerpc/include/asm/tlbflush.h |  2 ++
>  arch/powerpc/kernel/swsusp.c|  4 +---
>  arch/powerpc/mm/tlb_nohash.c| 12 
>  3 files changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/tlbflush.h
> b/arch/powerpc/include/asm/tlbflush.h
> index 61a5927..c401fe3 100644
> --- a/arch/powerpc/include/asm/tlbflush.h
> +++ b/arch/powerpc/include/asm/tlbflush.h
> @@ -44,6 +44,8 @@ extern void local_flush_tlb_page(struct vm_area_struct
> *vma, unsigned long vmadd
>  extern void __local_flush_tlb_page(struct mm_struct *mm, unsigned long
> vmaddr,
>  int tsize, int ind);
> 
> +extern void restore_mmu_context(void);
> +
>  #ifdef CONFIG_SMP
>  extern void flush_tlb_mm(struct mm_struct *mm);
>  extern void flush_tlb_page(struct vm_area_struct *vma, unsigned long
> vmaddr);
> diff --git a/arch/powerpc/kernel/swsusp.c b/arch/powerpc/kernel/swsusp.c
> index eae33e1..0b104d7 100644
> --- a/arch/powerpc/kernel/swsusp.c
> +++ b/arch/powerpc/kernel/swsusp.c
> @@ -32,7 +32,5 @@ void save_processor_state(void)
> 
>  void restore_processor_state(void)
>  {
> -#ifdef CONFIG_PPC32
> - switch_mmu_context(current->active_mm, current->active_mm);
> -#endif
> + restore_mmu_context();
>  }
> diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
> index df32a83..a5a0708 100644
> --- a/arch/powerpc/mm/tlb_nohash.c
> +++ b/arch/powerpc/mm/tlb_nohash.c
> @@ -39,10 +39,12 @@
>  #include 
>  #include 
> 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "mmu_decl.h"
> 
> @@ -193,6 +195,16 @@ void local_flush_tlb_page(struct vm_area_struct *vma,
> unsigned long vmaddr)
>  }
>  EXPORT_SYMBOL(local_flush_tlb_page);
> 
> +void restore_mmu_context(void)
> +{
> + struct mm_struct *mm = current->active_mm;
> +
> + set_context(mm->context.id, mm->pgd);
> +
> + _tlbil_all();
> +}
> +EXPORT_SYMBOL(restore_mmu_context);
> +
>  /*
>   * And here are the SMP non-local implementations
>   */
> --
> 1.8.0


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 1/2] powerpc: add Book E support to 64-bit hibernation

[Wang Dongsheng-B40534]

> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Wednesday, July 10, 2013 5:52 PM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; johan...@sipsolutions.net; an...@enomsg.org;
> ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 1/2] powerpc: add Book E support to 64-bit
> hibernation
> 
> On Wed, 2013-07-10 at 09:41 +, Wang Dongsheng-B40534 wrote:
> > Hi scott,
> >
> > Could you apply this patch?
> 
> There were a numbre of comments, were there addressed ? Do you need to
> save all the SPRGs for example ?
> 
> Ben.
> 
Um...yes, sorry, not all of the SPRGs.
the discussion about SPRG1 and SPRG2. I can fix them, just to save SRPG1 & 
SPRG2.
But those registers can be used by software, I think those register should be 
save,
even now some SPRG register not be use.

> > Thanks.
> >
> > -dongsheng
> >
> > > -Original Message-
> > > From: Wang Dongsheng-B40534
> > > Sent: Sunday, June 09, 2013 6:38 PM
> > > To: b...@kernel.crashing.org
> > > Cc: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421;
> > > ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang
> > > Dongsheng-
> > > B40534
> > > Subject: [PATCH 1/2] powerpc: add Book E support to 64-bit
> > > hibernation
> > >
> > > Update the 64-bit hibernation code to support Book E CPUs.
> > > Some registers and instructions are not defined for Book3e (SDR reg,
> > > tlbia instruction).
> > >
> > > SDR: Storage Description Register. Book3S and Book3E have different
> > > address translation mode, we do not need HTABORG & HTABSIZE to
> > > translate virtual address to real address.
> > >
> > > More registers are saved in BookE-64bit.(TCR, SPRGx, ...)
> > >
> > > Signed-off-by: Wang Dongsheng 
> > > ---
> > > * History:
> > > * Wood Scott(A): Please investigate the issue of whether we are
> loading
> > > *kernel module code in this step
> > > * R: Kernel will allocate the memory for module code segment and data
> > > *segment. First allocate a memory, and copy the umod to hdr
> members
> > > *of the struct load_info. Due to the temporary assigned module
> > > belongs
> > > *to the kernel space, so it belongs to the kernel data.
> > > *
> > > *The kernel of all data will be saved when hibernation suspend.
> So
> > > *the module which has already been inserted will be saved.
> > >
> > >  arch/powerpc/kernel/swsusp_asm64.S | 64
> > > --
> > >  1 file changed, 62 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/powerpc/kernel/swsusp_asm64.S
> > > b/arch/powerpc/kernel/swsusp_asm64.S
> > > index 86ac1d9..608e4ceb 100644
> > > --- a/arch/powerpc/kernel/swsusp_asm64.S
> > > +++ b/arch/powerpc/kernel/swsusp_asm64.S
> > > @@ -46,10 +46,29 @@
> > >  #define SL_r29   0xe8
> > >  #define SL_r30   0xf0
> > >  #define SL_r31   0xf8
> > > -#define SL_SIZE  SL_r31+8
> > > +#define SL_SPRG0 0x100
> > > +#define SL_SPRG1 0x108
> > > +#define SL_SPRG2 0x110
> > > +#define SL_SPRG3 0x118
> > > +#define SL_SPRG4 0x120
> > > +#define SL_SPRG5 0x128
> > > +#define SL_SPRG6 0x130
> > > +#define SL_SPRG7 0x138
> > > +#define SL_TCR   0x140
> > > +#define SL_SIZE  SL_TCR+8
> > >
> > >  /* these macros rely on the save area being
> > >   * pointed to by r11 */
> > > +
> > > +#define SAVE_SPR(register)   \
> > > + mfspr   r0,SPRN_##register  ;\
> > > + std r0,SL_##register(r11)
> > > +#define RESTORE_SPR(register)\
> > > + ld  r0,SL_##register(r11)   ;\
> > > + mtspr   SPRN_##register,r0
> > > +#define RESTORE_SPRG(n)  \
> > > + ld  r0,SL_SPRG##n(r11)  ;\
> > > + mtsprg  n,r0
> > >  #define SAVE_SPECIAL(special)\
> > >   mf##special r0  ;\
> > >   std r0, SL_##special(r11)
> > > @@ -103,8 +122,21 @@ _GLOBAL(swsusp_arch_suspend)
> > >   SAVE_REGISTER(r30)
> > >   SAVE_REGISTER(r31)
> > >   SAVE_SPECIAL(MSR)
> > > - SAVE_SPECIAL(SDR1)
> > >   SAVE_SPECIAL(XER)
> > > +#ifdef CONFIG_PPC_BOOK3S_64
> > > + SAVE_SPECIAL(SDR

RE: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel features

[Wang Dongsheng-B40534]

> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Wednesday, July 10, 2013 5:33 PM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; ga...@kernel.crashing.org; Zhao Chenhui-B35336; Li
> Yang-R58472; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel
> features
> 
> On Wed, 2013-07-10 at 09:29 +, Wang Dongsheng-B40534 wrote:
> > >
> > Yes, the wait instructions is for cpu idle, It will be make cpu into
> > low power mode, like DOZE & NAP. Each thread have this.
> 
> I don't need you to tell me by email, I need you to put a proper comment
> in the patch submission so it ends up in the repository and if possible a
> bit more detailed than that.
> 
> Ben.
> 
Ok, Thanks ben.
I will add a description for next RFC patch.

- dongsheng
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 1/2] powerpc: add Book E support to 64-bit hibernation

[Wang Dongsheng-B40534]

Hi scott,

Could you apply this patch?

Thanks.

-dongsheng

> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Sunday, June 09, 2013 6:38 PM
> To: b...@kernel.crashing.org
> Cc: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421;
> ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-
> B40534
> Subject: [PATCH 1/2] powerpc: add Book E support to 64-bit hibernation
> 
> Update the 64-bit hibernation code to support Book E CPUs.
> Some registers and instructions are not defined for Book3e
> (SDR reg, tlbia instruction).
> 
> SDR: Storage Description Register. Book3S and Book3E have different
> address translation mode, we do not need HTABORG & HTABSIZE to
> translate virtual address to real address.
> 
> More registers are saved in BookE-64bit.(TCR, SPRGx, ...)
> 
> Signed-off-by: Wang Dongsheng 
> ---
> * History:
> * Wood Scott(A): Please investigate the issue of whether we are loading
> *kernel module code in this step
> * R: Kernel will allocate the memory for module code segment and data
> *segment. First allocate a memory, and copy the umod to hdr members
> *of the struct load_info. Due to the temporary assigned module
> belongs
> *to the kernel space, so it belongs to the kernel data.
> *
> *The kernel of all data will be saved when hibernation suspend. So
> *the module which has already been inserted will be saved.
> 
>  arch/powerpc/kernel/swsusp_asm64.S | 64
> --
>  1 file changed, 62 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/swsusp_asm64.S
> b/arch/powerpc/kernel/swsusp_asm64.S
> index 86ac1d9..608e4ceb 100644
> --- a/arch/powerpc/kernel/swsusp_asm64.S
> +++ b/arch/powerpc/kernel/swsusp_asm64.S
> @@ -46,10 +46,29 @@
>  #define SL_r29   0xe8
>  #define SL_r30   0xf0
>  #define SL_r31   0xf8
> -#define SL_SIZE  SL_r31+8
> +#define SL_SPRG0 0x100
> +#define SL_SPRG1 0x108
> +#define SL_SPRG2 0x110
> +#define SL_SPRG3 0x118
> +#define SL_SPRG4 0x120
> +#define SL_SPRG5 0x128
> +#define SL_SPRG6 0x130
> +#define SL_SPRG7 0x138
> +#define SL_TCR   0x140
> +#define SL_SIZE  SL_TCR+8
> 
>  /* these macros rely on the save area being
>   * pointed to by r11 */
> +
> +#define SAVE_SPR(register)   \
> + mfspr   r0,SPRN_##register  ;\
> + std r0,SL_##register(r11)
> +#define RESTORE_SPR(register)\
> + ld  r0,SL_##register(r11)   ;\
> + mtspr   SPRN_##register,r0
> +#define RESTORE_SPRG(n)  \
> + ld  r0,SL_SPRG##n(r11)  ;\
> + mtsprg  n,r0
>  #define SAVE_SPECIAL(special)\
>   mf##special r0  ;\
>   std r0, SL_##special(r11)
> @@ -103,8 +122,21 @@ _GLOBAL(swsusp_arch_suspend)
>   SAVE_REGISTER(r30)
>   SAVE_REGISTER(r31)
>   SAVE_SPECIAL(MSR)
> - SAVE_SPECIAL(SDR1)
>   SAVE_SPECIAL(XER)
> +#ifdef CONFIG_PPC_BOOK3S_64
> + SAVE_SPECIAL(SDR1)
> +#else
> + SAVE_SPR(TCR)
> + /* Save SPRGs */
> + SAVE_SPR(SPRG0)
> + SAVE_SPR(SPRG1)
> + SAVE_SPR(SPRG2)
> + SAVE_SPR(SPRG3)
> + SAVE_SPR(SPRG4)
> + SAVE_SPR(SPRG5)
> + SAVE_SPR(SPRG6)
> + SAVE_SPR(SPRG7)
> +#endif
> 
>   /* we push the stack up 128 bytes but don't store the
>* stack pointer on the stack like a real stackframe */
> @@ -151,6 +183,7 @@ copy_page_loop:
>   bne+copyloop
>  nothing_to_copy:
> 
> +#ifdef CONFIG_PPC_BOOK3S_64
>   /* flush caches */
>   lis r3, 0x10
>   mtctr   r3
> @@ -167,6 +200,7 @@ nothing_to_copy:
>   sync
> 
>   tlbia
> +#endif
> 
>   ld  r11,swsusp_save_area_ptr@toc(r2)
> 
> @@ -208,16 +242,42 @@ nothing_to_copy:
>   RESTORE_REGISTER(r29)
>   RESTORE_REGISTER(r30)
>   RESTORE_REGISTER(r31)
> +
> +#ifdef CONFIG_PPC_BOOK3S_64
>   /* can't use RESTORE_SPECIAL(MSR) */
>   ld  r0, SL_MSR(r11)
>   mtmsrd  r0, 0
>   RESTORE_SPECIAL(SDR1)
> +#else
> + /* Save SPRGs */
> + RESTORE_SPRG(0)
> + RESTORE_SPRG(1)
> + RESTORE_SPRG(2)
> + RESTORE_SPRG(3)
> + RESTORE_SPRG(4)
> + RESTORE_SPRG(5)
> + RESTORE_SPRG(6)
> + RESTORE_SPRG(7)
> +
> + RESTORE_SPECIAL(MSR)
> +
> + /* Restore TCR and clear any pending bits in TSR. */
> + RESTORE_SPR(TCR)
> + lis r0, (TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS)@h
> + mtspr   SPRN_TSR,r0
> +
> + /* Kick decre

RE: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel features

[Wang Dongsheng-B40534]

> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Wednesday, July 10, 2013 5:23 PM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; ga...@kernel.crashing.org; Zhao Chenhui-B35336; Li
> Yang-R58472
> Subject: Re: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel
> features
> 
> On Wed, 2013-07-10 at 16:27 +0800, Dongsheng Wang wrote:
> > From: Wang Dongsheng 
> 
> This is missing an explanation of what that feature bit means...
> 
> possibly with a description of the corresponding HW feature.
> 
> Ben.
> 
Yes, the wait instructions is for cpu idle, It will be make cpu into
low power mode, like DOZE & NAP. Each thread have this.

> > Signed-off-by: Wang Dongsheng 
> >
> > diff --git a/arch/powerpc/include/asm/cputable.h
> b/arch/powerpc/include/asm/cputable.h
> > index 6f3887d..0a8d0cb 100644
> > --- a/arch/powerpc/include/asm/cputable.h
> > +++ b/arch/powerpc/include/asm/cputable.h
> > @@ -138,6 +138,7 @@ extern const char *powerpc_base_platform;
> >  #define CPU_FTR_NOEXECUTE  ASM_CONST(0x1000)
> >  #define CPU_FTR_INDEXED_DCRASM_CONST(0x2000)
> >  #define CPU_FTR_EMB_HV ASM_CONST(0x4000)
> > +#define CPU_FTR_CAN_WAIT   ASM_CONST(0x8000)
> >
> >  /*
> >   * Add the 64-bit processor unique features in the top half of the
> word;
> > @@ -250,9 +251,11 @@ extern const char *powerpc_base_platform;
> >  #ifndef CONFIG_BDI_SWITCH
> >  #define CPU_FTR_MAYBE_CAN_DOZE CPU_FTR_CAN_DOZE
> >  #define CPU_FTR_MAYBE_CAN_NAP  CPU_FTR_CAN_NAP
> > +#define CPU_FTR_MAYBE_CAN_WAIT CPU_FTR_CAN_WAIT
> >  #else
> >  #define CPU_FTR_MAYBE_CAN_DOZE 0
> >  #define CPU_FTR_MAYBE_CAN_NAP  0
> > +#define CPU_FTR_MAYBE_CAN_WAIT 0
> >  #endif
> >
> >  #define CLASSIC_PPC (!defined(CONFIG_8xx) && !defined(CONFIG_4xx) && \
> > @@ -370,15 +373,17 @@ extern const char *powerpc_base_platform;
> > CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE)
> >  #define CPU_FTRS_E500MC(CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | \
> > CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
> > -   CPU_FTR_DBELL | CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV)
> > +   CPU_FTR_DBELL | CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV | \
> > +   CPU_FTR_MAYBE_CAN_WAIT)
> >  #define CPU_FTRS_E5500 (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | \
> > CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
> > CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \
> > -   CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV)
> > +   CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV | CPU_FTR_MAYBE_CAN_WAIT)
> >  #define CPU_FTRS_E6500 (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | \
> > CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
> > CPU_FTR_DBELL | CPU_FTR_POPCNTB | CPU_FTR_POPCNTD | \
> > -   CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV | CPU_FTR_ALTIVEC_COMP)
> > +   CPU_FTR_DEBUG_LVL_EXC | CPU_FTR_EMB_HV | CPU_FTR_ALTIVEC_COMP |
> \
> > +   CPU_FTR_MAYBE_CAN_WAIT)
> >  #define CPU_FTRS_GENERIC_32(CPU_FTR_COMMON |
> CPU_FTR_NODSISRALIGN)
> >
> >  /* 64-bit CPUs */
> 
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support

[Wang Dongsheng-B40534]

> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Monday, July 01, 2013 10:49 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; ga...@kernel.crashing.org; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> 
> On Mon, 2013-07-01 at 02:38 +, Wang Dongsheng-B40534 wrote:
> > Hi Benjamin & Kumar & scott,
> >
> > I am not sure who can apply these patches...
> >
> > Scott already ACK these patches.
> >
> > A few days ago Scott have a pull request, Scott can accept them? Or ?
> 
> I'm happy to pull from Scott. 

Thanks Ben.

-dongsheng

>Do somebody other than me has access to an
> old Mac (a G5 for example) to check they don't break anything there ?
> 
> Ben.
> 
> > [v3,1/4] powerpc/mpic: add irq_set_wake support
> > http://patchwork.ozlabs.org/patch/234934/
> >
> > [v3,2/4] powerpc/mpic: add global timer support
> > http://patchwork.ozlabs.org/patch/234935/
> >
> > [v3,3/4] powerpc/mpic: create mpic subsystem object
> > http://patchwork.ozlabs.org/patch/234936
> >
> > [v3,4/4] powerpc/fsl: add MPIC timer wakeup support
> > http://patchwork.ozlabs.org/patch/234937/
> >
> > Thanks.
> >
> > -dongsheng
> >
> > > -Original Message-
> > > From: Wang Dongsheng-B40534
> > > Sent: Sunday, June 09, 2013 4:20 PM
> > > To: 'Benjamin Herrenschmidt'
> > > Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
> > > ga...@kernel.crashing.org
> > > Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> > >
> > > Hi ben,
> > >
> > > Could you apply these patches? Thanks. :)
> > >
> > > - dongsheng
> > >
> > > > -Original Message-
> > > > From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> > > > Sent: Monday, May 13, 2013 1:00 PM
> > > > To: Wang Dongsheng-B40534
> > > > Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
> > > > ga...@kernel.crashing.org
> > > > Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> > > >
> > > > On Mon, 2013-05-13 at 04:25 +, Wang Dongsheng-B40534 wrote:
> > > > > Hi Benjamin,
> > > > >
> > > > > Could you apply these patches?
> > > >
> > > > I'll have a look, I was assuming Kumar would take them but since
> not
> > > > I'll queue them up.
> > > >
> > > > Cheers,
> > > > Ben.
> > > >
> > > > > Scott already ACK.
> > > > >
> > > > > [v3,1/4] powerpc/mpic: add irq_set_wake support
> > > > > http://patchwork.ozlabs.org/patch/234934/
> > > > >
> > > > > [v3,2/4] powerpc/mpic: add global timer support
> > > > > http://patchwork.ozlabs.org/patch/234935/
> > > > >
> > > > > [v3,3/4] powerpc/mpic: create mpic subsystem object
> > > > > http://patchwork.ozlabs.org/patch/234936/
> > > > >
> > > > > [v3,4/4] powerpc/fsl: add MPIC timer wakeup support
> > > > > http://patchwork.ozlabs.org/patch/234937/
> > > > >
> > > > > Thanks.
> > > > >
> > > > > > -Original Message-
> > > > > > From: Wang Dongsheng-B40534
> > > > > > Sent: Friday, May 03, 2013 9:54 AM
> > > > > > To: 'ga...@kernel.crashing.org'
> > > > > > Cc: 'linuxppc-dev@lists.ozlabs.org'; Wood Scott-B07421;
> > > > > > 'b...@kernel.crashing.org'
> > > > > > Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake
> support
> > > > > >
> > > > > > Hi Kumar,
> > > > > >
> > > > > > Could you apply these patches?
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Wang Dongsheng-B40534
> > > > > > > Sent: Tuesday, April 23, 2013 6:10 PM
> > > > > > > To: ga...@kernel.crashing.org
> > > > > > > Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421
> > > > > > > Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake
> > > > > > > support
> > > &

RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support

[Wang Dongsheng-B40534]

Hi Benjamin & Kumar & scott,

I am not sure who can apply these patches...

Scott already ACK these patches.

A few days ago Scott have a pull request, Scott can accept them? Or ?

[v3,1/4] powerpc/mpic: add irq_set_wake support
http://patchwork.ozlabs.org/patch/234934/

[v3,2/4] powerpc/mpic: add global timer support
http://patchwork.ozlabs.org/patch/234935/

[v3,3/4] powerpc/mpic: create mpic subsystem object
http://patchwork.ozlabs.org/patch/234936

[v3,4/4] powerpc/fsl: add MPIC timer wakeup support
http://patchwork.ozlabs.org/patch/234937/

Thanks.

-dongsheng

> -Original Message-----
> From: Wang Dongsheng-B40534
> Sent: Sunday, June 09, 2013 4:20 PM
> To: 'Benjamin Herrenschmidt'
> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
> ga...@kernel.crashing.org
> Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> 
> Hi ben,
> 
> Could you apply these patches? Thanks. :)
> 
> - dongsheng
> 
> > -Original Message-
> > From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> > Sent: Monday, May 13, 2013 1:00 PM
> > To: Wang Dongsheng-B40534
> > Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
> > ga...@kernel.crashing.org
> > Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> >
> > On Mon, 2013-05-13 at 04:25 +, Wang Dongsheng-B40534 wrote:
> > > Hi Benjamin,
> > >
> > > Could you apply these patches?
> >
> > I'll have a look, I was assuming Kumar would take them but since not
> > I'll queue them up.
> >
> > Cheers,
> > Ben.
> >
> > > Scott already ACK.
> > >
> > > [v3,1/4] powerpc/mpic: add irq_set_wake support
> > > http://patchwork.ozlabs.org/patch/234934/
> > >
> > > [v3,2/4] powerpc/mpic: add global timer support
> > > http://patchwork.ozlabs.org/patch/234935/
> > >
> > > [v3,3/4] powerpc/mpic: create mpic subsystem object
> > > http://patchwork.ozlabs.org/patch/234936/
> > >
> > > [v3,4/4] powerpc/fsl: add MPIC timer wakeup support
> > > http://patchwork.ozlabs.org/patch/234937/
> > >
> > > Thanks.
> > >
> > > > -Original Message-
> > > > From: Wang Dongsheng-B40534
> > > > Sent: Friday, May 03, 2013 9:54 AM
> > > > To: 'ga...@kernel.crashing.org'
> > > > Cc: 'linuxppc-dev@lists.ozlabs.org'; Wood Scott-B07421;
> > > > 'b...@kernel.crashing.org'
> > > > Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> > > >
> > > > Hi Kumar,
> > > >
> > > > Could you apply these patches?
> > > >
> > > > Thanks.
> > > >
> > > > > -Original Message-
> > > > > From: Wang Dongsheng-B40534
> > > > > Sent: Tuesday, April 23, 2013 6:10 PM
> > > > > To: ga...@kernel.crashing.org
> > > > > Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421
> > > > > Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake
> > > > > support
> > > > >
> > > > > Hi Kumar,
> > > > >
> > > > > Could you apply these patches?
> > > > >
> > > > > Thanks.
> > > > >
> > > > > [v3,1/4] powerpc/mpic: add irq_set_wake support
> > > > > http://patchwork.ozlabs.org/patch/234934/
> > > > >
> > > > > [v3,2/4] powerpc/mpic: add global timer support
> > > > > http://patchwork.ozlabs.org/patch/234935/
> > > > >
> > > > > [v3,3/4] powerpc/mpic: create mpic subsystem object
> > > > > http://patchwork.ozlabs.org/patch/234936/
> > > > >
> > > > > [v3,4/4] powerpc/fsl: add MPIC timer wakeup support
> > > > > http://patchwork.ozlabs.org/patch/234937/
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Wednesday, April 17, 2013 7:30 AM
> > > > > > To: Wang Dongsheng-B40534
> > > > > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org;
> > > > > > ga...@kernel.crashing.org
> > > > > > Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake
> > > > > > support
> > > > > >
> > > > > > ACK
> > > > > >
> > > > > > -Scott
> > > > > >
> > > > > > On 04/16/2013 05:58:52 AM, Wang Dongsheng-B40534 wrote:
> > > > > > > Hi scott,
> > > > > > >
> > > > > > > Could you ACK these patches?
> > > > > > >
> > > > > > > [PATCH v3 2/4] powerpc/mpic: add global timer support [PATCH
> > > > > > > v3 3/4]
> > > > > > > powerpc/mpic: create mpic subsystem object [PATCH v3 4/4]
> > > > > > > powerpc/fsl: add MPIC timer wakeup support
> > > > > > >
> > > > > > > Thanks.
> > > > > > >
> >
> >

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 1/2] powerpc: add Book E support to 64-bit hibernation

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, June 14, 2013 12:51 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; b...@kernel.crashing.org;
> johan...@sipsolutions.net; an...@enomsg.org; ga...@kernel.crashing.org;
> linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH 1/2] powerpc: add Book E support to 64-bit
> hibernation
> 
> On 06/13/2013 04:55:43 AM, Wang Dongsheng-B40534 wrote:
> > > > +#else
> > > > +   /* Save SPRGs */
> > > > +   RESTORE_SPRG(0)
> > > > +   RESTORE_SPRG(1)
> > > > +   RESTORE_SPRG(2)
> > > > +   RESTORE_SPRG(3)
> > > > +   RESTORE_SPRG(4)
> > > > +   RESTORE_SPRG(5)
> > > > +   RESTORE_SPRG(6)
> > > > +   RESTORE_SPRG(7)
> > >
> > > Why do we need this on book3e and not on book3s?
> > >
> > Book3e: SPRG1 used save paca, SPRG2 be defined
> > SPRN_SPRG_TLB_EXFRAME,...
> > I think those register should be save, even now some SPRG register not
> > be use.
> 
> Are those expected/allowed to change as a result of the restore?
> 
Those registers are used by software, some allowed to change.
Exception handling is used in some registers, see exception-64e.h
These registers can be modified and saved.

> -Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 1/2] powerpc: add Book E support to 64-bit hibernation

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, June 13, 2013 6:04 AM
> To: Wang Dongsheng-B40534
> Cc: b...@kernel.crashing.org; johan...@sipsolutions.net; an...@enomsg.org;
> ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-
> B40534
> Subject: Re: [PATCH 1/2] powerpc: add Book E support to 64-bit
> hibernation
> 
> On 06/09/2013 05:37:39 AM, Wang Dongsheng wrote:
> >  /* these macros rely on the save area being
> >   * pointed to by r11 */
> > +
> > +#define SAVE_SPR(register) \
> > +   mfspr   r0,SPRN_##register  ;\
> > +   std r0,SL_##register(r11)
> > +#define RESTORE_SPR(register)  \
> > +   ld  r0,SL_##register(r11)   ;\
> > +   mtspr   SPRN_##register,r0
> > +#define RESTORE_SPRG(n)\
> > +   ld  r0,SL_SPRG##n(r11)  ;\
> > +   mtsprg  n,r0
> >  #define SAVE_SPECIAL(special)  \
> > mf##special r0  ;\
> > std r0, SL_##special(r11)
> 
> Is there a particular SPR that you're trying to save, for which
> SAVE_SPECIAL doesn't work?
> 
Yes, like pid, tcr.

> > +#else
> > +   /* Save SPRGs */
> > +   RESTORE_SPRG(0)
> > +   RESTORE_SPRG(1)
> > +   RESTORE_SPRG(2)
> > +   RESTORE_SPRG(3)
> > +   RESTORE_SPRG(4)
> > +   RESTORE_SPRG(5)
> > +   RESTORE_SPRG(6)
> > +   RESTORE_SPRG(7)
> 
> Why do we need this on book3e and not on book3s?
> 
Book3e: SPRG1 used save paca, SPRG2 be defined SPRN_SPRG_TLB_EXFRAME,...
I think those register should be save, even now some SPRG register not be use.

Book3s: Sorry, I not clear why book3s not do this. I think Anton or Ben could 
know the reason.

> > +
> > +   RESTORE_SPECIAL(MSR)
> > +
> > +   /* Restore TCR and clear any pending bits in TSR. */
> > +   RESTORE_SPR(TCR)
> > +   lis r0, (TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS)@h
> > +   mtspr   SPRN_TSR,r0
> 
> Please be internally consistent with whitespace after commas, even if the
> rest of the file is already inconsistent. :-P
> 
Thanks.

> > +
> > +   /* Kick decrementer */
> > +   li  r0,1
> > +   mtdec   r0
> 
> Why doesn't book3s need to kick the decrementer?
> 
Sorry, I not clear why book3s not do this. I think Anton or Ben could know the 
reason.

> -Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 2/2] powerpc/hibernate: PPC64 fix user threads access to kernel space

[Wang Dongsheng-B40534]

Sorry, Please ignore this patch.
This is replaced.
Replace by: http://patchwork.ozlabs.org/patch/250033/

- dongsheng

> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Sunday, June 09, 2013 1:23 PM
> To: b...@kernel.crashing.org; johan...@sipsolutions.net; an...@enomsg.org
> Cc: Wood Scott-B07421; ga...@kernel.crashing.org; linuxppc-
> d...@lists.ozlabs.org; Wang Dongsheng-B40534
> Subject: [PATCH v2 2/2] powerpc/hibernate: PPC64 fix user threads access
> to kernel space
> 
> If PID is used in the TLB, after hibernation resume, the user
> threads will access to kernel space.
> 
> We must restore PID register, because TLB will use PID. The
> hibernation suspend flow is trapped from user space to kernel
> space, the PID register is user thread pid.
> 
> The hibernation resume is begin in kernel start flow, the PID
> alway 0. After the kernel thread back to user thread, there is
> not have context switch and the pid can not update, because the
> kernel thread is trapped form user space. So if we did't restore
> PID the user space of thread will be addressing in the kernel
> space.
> 
> There are two ways to restore PID:
> 1/ In swsusp_arch_suspend/swsusp_arch_resume, save/resotre PID register.
> 2/ Form restore_processor_state to restore. this function will
>do context switch.
>switch_mmu_context(current->active_mm, current->active_mm)
> 
> PPC32 Using the second method. For consistency reason, PPC64 using
> the same way.
> 
> Signed-off-by: Wang Dongsheng 
> ---
>  arch/powerpc/kernel/swsusp.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/swsusp.c b/arch/powerpc/kernel/swsusp.c
> index eae33e1..1930e44 100644
> --- a/arch/powerpc/kernel/swsusp.c
> +++ b/arch/powerpc/kernel/swsusp.c
> @@ -32,7 +32,5 @@ void save_processor_state(void)
> 
>  void restore_processor_state(void)
>  {
> -#ifdef CONFIG_PPC32
>   switch_mmu_context(current->active_mm, current->active_mm);
> -#endif
>  }
> --
> 1.8.0


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 1/2] powerpc: add Book E support to 64-bit hibernation

[Wang Dongsheng-B40534]

Sorry, Please ignore this patch.
This is replaced.
Replace by: http://patchwork.ozlabs.org/patch/250032/

- dongsheng

> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Sunday, June 09, 2013 1:21 PM
> To: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421
> Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Wang
> Dongsheng-B40534
> Subject: [PATCH v2 1/2] powerpc: add Book E support to 64-bit hibernation
> 
> Update the 64-bit hibernation code to support Book E CPUs.
> Some registers and instructions are not defined for Book3e
> (SDR reg, tlbia instruction).
> 
> SDR: Storage Description Register. Book3S and Book3E have different
> address translation mode, we do not need HTABORG & HTABSIZE to
> translate virtual address to real address.
> 
> More registers are saved in BookE-64bit.(TCR, SPRGx, ...)
> 
> Signed-off-by: Wang Dongsheng 
> ---
> v2:
> * Add: _tlbil_all
> *
> * The boot core get a virtual address, when the boot process,
> * the virtual address corresponds to a physical address. After
> * hibernation resume memory snapshots, The corresponding
> * relationship between the virtual memory and physical memory
> * might change again. We need to get a new page table. So we
> * need to invalidate TLB after resume pages.
> *
> * Invalidations TLB Using tlbilx/tlbivax/MMUCSR0.
> * tlbilx used here.
> *
> * Add: save/restore PID
> *
> * We must restore PID register, because TLB will use PID. The
> * hibernation suspend flow is trapped from user space to kernel
> * space, the PID register is user thread pid.
> *
> * The hibernation resume is begin in kernel start flow, the PID
> * alway 0. After the kernel thread back to user thread, there is
> * not have context switch and the pid can not update, because the
> * kernel thread is trapped form user space. So if we did't restore
> * PID the user space of thread will be addressing in the kernel
> * space.
> *
> * There are two ways to restore PID:
> * 1/ In this file save/resotre PID register.
> * 2/ Form restore_processor_state to restore. this function will
> *do context switch.
> *switch_mmu_context(current->active_mm, current->active_mm)
> *
> * PPC32 Using the second method. For consistency reason, PPC64
> * using the same way.
> *
> * History:
> * Wood Scott(A): Please investigate the issue of whether we are loading
> *kernel module code in this step
> * R: Kernel will allocate the memory for module code segment and data
> *segment. First allocate a memory, and copy the umod to hdr members
> *of the struct load_info. Due to the temporary assigned module
> belongs
> *to the kernel space, so it belongs to the kernel data.
> *
> *The kernel of all data will be saved when hibernation suspend. So
> *the module which has already been inserted will be saved.
> 
>  arch/powerpc/kernel/swsusp_asm64.S | 102
> -
>  1 file changed, 100 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/swsusp_asm64.S
> b/arch/powerpc/kernel/swsusp_asm64.S
> index 86ac1d9..c7e2b4a 100644
> --- a/arch/powerpc/kernel/swsusp_asm64.S
> +++ b/arch/powerpc/kernel/swsusp_asm64.S
> @@ -46,10 +46,30 @@
>  #define SL_r29   0xe8
>  #define SL_r30   0xf0
>  #define SL_r31   0xf8
> -#define SL_SIZE  SL_r31+8
> +#define SL_SPRG0 0x100
> +#define SL_SPRG1 0x108
> +#define SL_SPRG2 0x110
> +#define SL_SPRG3 0x118
> +#define SL_SPRG4 0x120
> +#define SL_SPRG5 0x128
> +#define SL_SPRG6 0x130
> +#define SL_SPRG7 0x138
> +#define SL_TCR   0x140
> +#define SL_PID   0x148
> +#define SL_SIZE  SL_PID+8
> 
>  /* these macros rely on the save area being
>   * pointed to by r11 */
> +
> +#define SAVE_SPR(register)   \
> + mfspr   r0,SPRN_##register  ;\
> + std r0,SL_##register(r11)
> +#define RESTORE_SPR(register)\
> + ld  r0,SL_##register(r11)   ;\
> + mtspr   SPRN_##register,r0
> +#define RESTORE_SPRG(n)  \
> + ld  r0,SL_SPRG##n(r11)  ;\
> + mtsprg  n,r0
>  #define SAVE_SPECIAL(special)\
>   mf##special r0  ;\
>   std r0, SL_##special(r11)
> @@ -103,8 +123,22 @@ _GLOBAL(swsusp_arch_suspend)
>   SAVE_REGISTER(r30)
>   SAVE_REGISTER(r31)
>   SAVE_SPECIAL(MSR)
> - SAVE_SPECIAL(SDR1)
>   SAVE_SPECIAL(XER)
> +#ifdef CONFIG_PPC_BOOK3S_64
> + SAVE_SPECIAL(SDR1)
> +#else
> + SAVE_SPR(TCR)
> + /* Save SPRGs */
> + SAVE_SP

[PATCH 2/2] powerpc/hibernate: add restore mmu context after resume

[Wang Dongsheng]

add restore_mmu_context to replace switch_mmu_context in
restore_processor_state, because the switch_mmu_context will do
a whole pile of stuff that are probably completely unnecessary.

There just need to restore the existing process context, and
invalidate TLB for boot core.

Signed-off-by: Wang Dongsheng 
---
 arch/powerpc/include/asm/tlbflush.h |  2 ++
 arch/powerpc/kernel/swsusp.c|  4 +---
 arch/powerpc/mm/tlb_nohash.c| 12 
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/tlbflush.h 
b/arch/powerpc/include/asm/tlbflush.h
index 61a5927..c401fe3 100644
--- a/arch/powerpc/include/asm/tlbflush.h
+++ b/arch/powerpc/include/asm/tlbflush.h
@@ -44,6 +44,8 @@ extern void local_flush_tlb_page(struct vm_area_struct *vma, 
unsigned long vmadd
 extern void __local_flush_tlb_page(struct mm_struct *mm, unsigned long vmaddr,
   int tsize, int ind);
 
+extern void restore_mmu_context(void);
+
 #ifdef CONFIG_SMP
 extern void flush_tlb_mm(struct mm_struct *mm);
 extern void flush_tlb_page(struct vm_area_struct *vma, unsigned long vmaddr);
diff --git a/arch/powerpc/kernel/swsusp.c b/arch/powerpc/kernel/swsusp.c
index eae33e1..0b104d7 100644
--- a/arch/powerpc/kernel/swsusp.c
+++ b/arch/powerpc/kernel/swsusp.c
@@ -32,7 +32,5 @@ void save_processor_state(void)
 
 void restore_processor_state(void)
 {
-#ifdef CONFIG_PPC32
-   switch_mmu_context(current->active_mm, current->active_mm);
-#endif
+   restore_mmu_context();
 }
diff --git a/arch/powerpc/mm/tlb_nohash.c b/arch/powerpc/mm/tlb_nohash.c
index df32a83..a5a0708 100644
--- a/arch/powerpc/mm/tlb_nohash.c
+++ b/arch/powerpc/mm/tlb_nohash.c
@@ -39,10 +39,12 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "mmu_decl.h"
 
@@ -193,6 +195,16 @@ void local_flush_tlb_page(struct vm_area_struct *vma, 
unsigned long vmaddr)
 }
 EXPORT_SYMBOL(local_flush_tlb_page);
 
+void restore_mmu_context(void)
+{
+   struct mm_struct *mm = current->active_mm;
+
+   set_context(mm->context.id, mm->pgd);
+
+   _tlbil_all();
+}
+EXPORT_SYMBOL(restore_mmu_context);
+
 /*
  * And here are the SMP non-local implementations
  */
-- 
1.8.0


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/2] powerpc: add Book E support to 64-bit hibernation

[Wang Dongsheng]

Update the 64-bit hibernation code to support Book E CPUs.
Some registers and instructions are not defined for Book3e
(SDR reg, tlbia instruction).

SDR: Storage Description Register. Book3S and Book3E have different
address translation mode, we do not need HTABORG & HTABSIZE to
translate virtual address to real address.

More registers are saved in BookE-64bit.(TCR, SPRGx, ...)

Signed-off-by: Wang Dongsheng 
---
* History:
* Wood Scott(A): Please investigate the issue of whether we are loading
*kernel module code in this step
* R: Kernel will allocate the memory for module code segment and data
*segment. First allocate a memory, and copy the umod to hdr members
*of the struct load_info. Due to the temporary assigned module belongs
*to the kernel space, so it belongs to the kernel data.
*
*The kernel of all data will be saved when hibernation suspend. So
*the module which has already been inserted will be saved.

 arch/powerpc/kernel/swsusp_asm64.S | 64 --
 1 file changed, 62 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/swsusp_asm64.S 
b/arch/powerpc/kernel/swsusp_asm64.S
index 86ac1d9..608e4ceb 100644
--- a/arch/powerpc/kernel/swsusp_asm64.S
+++ b/arch/powerpc/kernel/swsusp_asm64.S
@@ -46,10 +46,29 @@
 #define SL_r29 0xe8
 #define SL_r30 0xf0
 #define SL_r31 0xf8
-#define SL_SIZESL_r31+8
+#define SL_SPRG0   0x100
+#define SL_SPRG1   0x108
+#define SL_SPRG2   0x110
+#define SL_SPRG3   0x118
+#define SL_SPRG4   0x120
+#define SL_SPRG5   0x128
+#define SL_SPRG6   0x130
+#define SL_SPRG7   0x138
+#define SL_TCR 0x140
+#define SL_SIZESL_TCR+8
 
 /* these macros rely on the save area being
  * pointed to by r11 */
+
+#define SAVE_SPR(register) \
+   mfspr   r0,SPRN_##register  ;\
+   std r0,SL_##register(r11)
+#define RESTORE_SPR(register)  \
+   ld  r0,SL_##register(r11)   ;\
+   mtspr   SPRN_##register,r0
+#define RESTORE_SPRG(n)\
+   ld  r0,SL_SPRG##n(r11)  ;\
+   mtsprg  n,r0
 #define SAVE_SPECIAL(special)  \
mf##special r0  ;\
std r0, SL_##special(r11)
@@ -103,8 +122,21 @@ _GLOBAL(swsusp_arch_suspend)
SAVE_REGISTER(r30)
SAVE_REGISTER(r31)
SAVE_SPECIAL(MSR)
-   SAVE_SPECIAL(SDR1)
SAVE_SPECIAL(XER)
+#ifdef CONFIG_PPC_BOOK3S_64
+   SAVE_SPECIAL(SDR1)
+#else
+   SAVE_SPR(TCR)
+   /* Save SPRGs */
+   SAVE_SPR(SPRG0)
+   SAVE_SPR(SPRG1)
+   SAVE_SPR(SPRG2)
+   SAVE_SPR(SPRG3)
+   SAVE_SPR(SPRG4)
+   SAVE_SPR(SPRG5)
+   SAVE_SPR(SPRG6)
+   SAVE_SPR(SPRG7)
+#endif
 
/* we push the stack up 128 bytes but don't store the
 * stack pointer on the stack like a real stackframe */
@@ -151,6 +183,7 @@ copy_page_loop:
bne+copyloop
 nothing_to_copy:
 
+#ifdef CONFIG_PPC_BOOK3S_64
/* flush caches */
lis r3, 0x10
mtctr   r3
@@ -167,6 +200,7 @@ nothing_to_copy:
sync
 
tlbia
+#endif
 
ld  r11,swsusp_save_area_ptr@toc(r2)
 
@@ -208,16 +242,42 @@ nothing_to_copy:
RESTORE_REGISTER(r29)
RESTORE_REGISTER(r30)
RESTORE_REGISTER(r31)
+
+#ifdef CONFIG_PPC_BOOK3S_64
/* can't use RESTORE_SPECIAL(MSR) */
ld  r0, SL_MSR(r11)
mtmsrd  r0, 0
RESTORE_SPECIAL(SDR1)
+#else
+   /* Save SPRGs */
+   RESTORE_SPRG(0)
+   RESTORE_SPRG(1)
+   RESTORE_SPRG(2)
+   RESTORE_SPRG(3)
+   RESTORE_SPRG(4)
+   RESTORE_SPRG(5)
+   RESTORE_SPRG(6)
+   RESTORE_SPRG(7)
+
+   RESTORE_SPECIAL(MSR)
+
+   /* Restore TCR and clear any pending bits in TSR. */
+   RESTORE_SPR(TCR)
+   lis r0, (TSR_ENW | TSR_WIS | TSR_DIS | TSR_FIS)@h
+   mtspr   SPRN_TSR,r0
+
+   /* Kick decrementer */
+   li  r0,1
+   mtdec   r0
+#endif
RESTORE_SPECIAL(XER)
 
sync
 
addir1,r1,-128
+#ifdef CONFIG_PPC_BOOK3S_64
bl  slb_flush_and_rebolt
+#endif
bl  do_after_copyback
addir1,r1,128
 
-- 
1.8.0


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] powerpc/mpc85xx: fix non-bootcpu cannot up after hibernation resume

[Wang Dongsheng-B40534]

Hi kumar,

Could you apply this patche? 

Thanks.

-dongsheng

> -Original Message-
> From: Anton Vorontsov [mailto:an...@scarybugs.org] On Behalf Of Anton
> Vorontsov
> Sent: Friday, May 24, 2013 1:34 AM
> To: Wang Dongsheng-B40534
> Cc: pau...@samba.org; r...@sisk.pl; b...@kernel.crashing.org;
> johan...@sipsolutions.net; Wood Scott-B07421; Li Yang-R58472; Zhao
> Chenhui-B35336; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] powerpc/mpc85xx: fix non-bootcpu cannot up after
> hibernation resume
> 
> Hi!
> 
> On Tue, May 14, 2013 at 08:59:13AM +, Wang Dongsheng-B40534 wrote:
> > I send to a wrong email address "Anton Vorontsov
> "
> >
> > Add Anton Vorontsov  to this email.
> 
> I don't have any means to test it, but the patch itself looks good and
> the description makes sense. So,
> 
> Reviewed-by: Anton Vorontsov 
> 
> Thanks!
> 
> >
> > Thanks all.
> >
> > > -Original Message-
> > > From: Wang Dongsheng-B40534
> > > Sent: Tuesday, May 14, 2013 4:06 PM
> > > To: avoront...@ru.mvista.com
> > > Cc: pau...@samba.org; r...@sisk.pl; b...@kernel.crashing.org;
> > > johan...@sipsolutions.net; Wood Scott-B07421; Li Yang-R58472; Zhao
> > > Chenhui-B35336; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > > Subject: [PATCH] powerpc/mpc85xx: fix non-bootcpu cannot up after
> > > hibernation resume
> > >
> > > This problem belongs to the core synchronization issues.
> > > The cpu1 already updated spin_table values, but bootcore cannot get
> > > this value in time.
> > >
> > > After bootcpu hibiernation restore the pages. we are now running
> > > with the kernel data of the old kernel fully restored. if we reset
> > > the non-bootcpus that will be reset cache(tlb), the non-bootcpus
> > > will get new address(map virtual and physical address spaces).
> > > but bootcpu tlb cache still use boot kernel data, so we need to
> > > invalidate the bootcpu tlb cache make it to get new main memory data.
> > >
> > > log:
> > > Enabling non-boot CPUs ...
> > > smp_85xx_kick_cpu: timeout waiting for core 1 to reset
> > > smp: failed starting cpu 1 (rc -2)
> > > Error taking CPU1 up: -2
> > >
> > > Signed-off-by: Wang Dongsheng 
> > >
> > > diff --git a/arch/powerpc/kernel/swsusp_booke.S
> > > b/arch/powerpc/kernel/swsusp_booke.S
> > > index 11a3930..9503249 100644
> > > --- a/arch/powerpc/kernel/swsusp_booke.S
> > > +++ b/arch/powerpc/kernel/swsusp_booke.S
> > > @@ -141,6 +141,19 @@ _GLOBAL(swsusp_arch_resume)
> > >   lis r11,swsusp_save_area@h
> > >   ori r11,r11,swsusp_save_area@l
> > >
> > > + /*
> > > +  * The boot core get a virtual address, when the boot process,
> > > +  * the virtual address corresponds to a physical address. After
> > > +  * hibernation resume memory snapshots, The corresponding
> > > +  * relationship between the virtual memory and physical memory
> > > +  * might change again. We need to get a new page table. So we
> > > +  * need to invalidate TLB after resume pages.
> > > +  *
> > > +  * Invalidations TLB Using tlbilx/tlbivax/MMUCSR0.
> > > +  * tlbilx used here.
> > > +  */
> > > + bl  _tlbil_all
> > > +
> > >   lwz r4,SL_SPRG0(r11)
> > >   mtsprg  0,r4
> > >   lwz r4,SL_SPRG1(r11)
> > > --
> > > 1.8.0
> >
> >

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support

[Wang Dongsheng-B40534]

Hi ben,

Could you apply these patches? Thanks. :)

- dongsheng

> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Monday, May 13, 2013 1:00 PM
> To: Wang Dongsheng-B40534
> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
> ga...@kernel.crashing.org
> Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> 
> On Mon, 2013-05-13 at 04:25 +, Wang Dongsheng-B40534 wrote:
> > Hi Benjamin,
> >
> > Could you apply these patches?
> 
> I'll have a look, I was assuming Kumar would take them but since not I'll
> queue them up.
> 
> Cheers,
> Ben.
> 
> > Scott already ACK.
> >
> > [v3,1/4] powerpc/mpic: add irq_set_wake support
> > http://patchwork.ozlabs.org/patch/234934/
> >
> > [v3,2/4] powerpc/mpic: add global timer support
> > http://patchwork.ozlabs.org/patch/234935/
> >
> > [v3,3/4] powerpc/mpic: create mpic subsystem object
> > http://patchwork.ozlabs.org/patch/234936/
> >
> > [v3,4/4] powerpc/fsl: add MPIC timer wakeup support
> > http://patchwork.ozlabs.org/patch/234937/
> >
> > Thanks.
> >
> > > -Original Message-
> > > From: Wang Dongsheng-B40534
> > > Sent: Friday, May 03, 2013 9:54 AM
> > > To: 'ga...@kernel.crashing.org'
> > > Cc: 'linuxppc-dev@lists.ozlabs.org'; Wood Scott-B07421;
> > > 'b...@kernel.crashing.org'
> > > Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> > >
> > > Hi Kumar,
> > >
> > > Could you apply these patches?
> > >
> > > Thanks.
> > >
> > > > -Original Message-
> > > > From: Wang Dongsheng-B40534
> > > > Sent: Tuesday, April 23, 2013 6:10 PM
> > > > To: ga...@kernel.crashing.org
> > > > Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421
> > > > Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> > > >
> > > > Hi Kumar,
> > > >
> > > > Could you apply these patches?
> > > >
> > > > Thanks.
> > > >
> > > > [v3,1/4] powerpc/mpic: add irq_set_wake support
> > > > http://patchwork.ozlabs.org/patch/234934/
> > > >
> > > > [v3,2/4] powerpc/mpic: add global timer support
> > > > http://patchwork.ozlabs.org/patch/234935/
> > > >
> > > > [v3,3/4] powerpc/mpic: create mpic subsystem object
> > > > http://patchwork.ozlabs.org/patch/234936/
> > > >
> > > > [v3,4/4] powerpc/fsl: add MPIC timer wakeup support
> > > > http://patchwork.ozlabs.org/patch/234937/
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, April 17, 2013 7:30 AM
> > > > > To: Wang Dongsheng-B40534
> > > > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org;
> > > > > ga...@kernel.crashing.org
> > > > > Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake
> > > > > support
> > > > >
> > > > > ACK
> > > > >
> > > > > -Scott
> > > > >
> > > > > On 04/16/2013 05:58:52 AM, Wang Dongsheng-B40534 wrote:
> > > > > > Hi scott,
> > > > > >
> > > > > > Could you ACK these patches?
> > > > > >
> > > > > > [PATCH v3 2/4] powerpc/mpic: add global timer support [PATCH
> > > > > > v3 3/4]
> > > > > > powerpc/mpic: create mpic subsystem object [PATCH v3 4/4]
> > > > > > powerpc/fsl: add MPIC timer wakeup support
> > > > > >
> > > > > > Thanks.
> > > > > >
> 
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 2/2] powerpc/hibernate: PPC64 fix user threads access to kernel space

[Wang Dongsheng-B40534]

> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Sunday, June 09, 2013 3:46 PM
> To: Wang Dongsheng-B40534
> Cc: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421;
> ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH v2 2/2] powerpc/hibernate: PPC64 fix user threads
> access to kernel space
> 
> On Sun, 2013-06-09 at 07:44 +, Wang Dongsheng-B40534 wrote:
> > So we just need set set_context() in restore_mmu_context().
> >
> > void restore_mmu_context(struct mm_struct *next) {
> > set_context(next->context.id, next->pgd); }
> 
> We probably also want to flush the TLB, just in case the boot kernel has
> left "something" there (though I wouldn't expect it to have run userspace
> it's not completely impossible).
> 
Yes, but TLB has already invalidated.
See my other patch:
http://patchwork.ozlabs.org/patch/250006/

> Cheers,
> Ben.
> 
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 2/2] powerpc/hibernate: PPC64 fix user threads access to kernel space

[Wang Dongsheng-B40534]

> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Sunday, June 09, 2013 2:44 PM
> To: Wang Dongsheng-B40534
> Cc: johan...@sipsolutions.net; an...@enomsg.org; Wood Scott-B07421;
> ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH v2 2/2] powerpc/hibernate: PPC64 fix user threads
> access to kernel space
> 
> On Sun, 2013-06-09 at 13:22 +0800, Wang Dongsheng wrote:
> > If PID is used in the TLB, after hibernation resume, the user threads
> > will access to kernel space.
> 
>  .../...
> 
> I think the explanation is way more convoluted and confusing here than
> anything else.
> 
> Simply say that upon resume from hibernation, the MMU context needs to be
> restored (this includes the PID register today it might include more if
> we decided to pre-set some MAS for example
> etc...) and be done with it.
> 
> Note that switch_mmu_context() used the way you do is quite "full on", it
> will do a whole pile of stuff that are probably completely unnecessary,
> and in addition might still miss the need to completely flush the TLB
> anyway.
> 
> I would suggest that instead, somebody adds the necessary routine to
> tlb_nohash.c, something like restore_mmu_context() which will do that.
> 
Thanks ben, This is a good idea.

We do not need to decide the current thread has a context in 
restore_mmu_context().
Because the current has already get a context in hibernation suspend flow.

So we just need set set_context() in restore_mmu_context().

void restore_mmu_context(struct mm_struct *next) {
set_context(next->context.id, next->pgd);
}

-dongsheng

> Cheers,
> Ben.
> 
> > Signed-off-by: Wang Dongsheng 
> > ---
> >  arch/powerpc/kernel/swsusp.c | 2 --
> >  1 file changed, 2 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/swsusp.c
> > b/arch/powerpc/kernel/swsusp.c index eae33e1..1930e44 100644
> > --- a/arch/powerpc/kernel/swsusp.c
> > +++ b/arch/powerpc/kernel/swsusp.c
> > @@ -32,7 +32,5 @@ void save_processor_state(void)
> >
> >  void restore_processor_state(void)
> >  {
> > -#ifdef CONFIG_PPC32
> > switch_mmu_context(current->active_mm, current->active_mm); -#endif
> > }
> 
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 2/2] powerpc/hibernate: PPC64 fix user threads access to kernel space

[Wang Dongsheng]

If PID is used in the TLB, after hibernation resume, the user
threads will access to kernel space.

We must restore PID register, because TLB will use PID. The
hibernation suspend flow is trapped from user space to kernel
space, the PID register is user thread pid.

The hibernation resume is begin in kernel start flow, the PID
alway 0. After the kernel thread back to user thread, there is
not have context switch and the pid can not update, because the
kernel thread is trapped form user space. So if we did't restore
PID the user space of thread will be addressing in the kernel
space.

There are two ways to restore PID:
1/ In swsusp_arch_suspend/swsusp_arch_resume, save/resotre PID register.
2/ Form restore_processor_state to restore. this function will
   do context switch.
   switch_mmu_context(current->active_mm, current->active_mm)

PPC32 Using the second method. For consistency reason, PPC64 using
the same way.

Signed-off-by: Wang Dongsheng 
---
 arch/powerpc/kernel/swsusp.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/powerpc/kernel/swsusp.c b/arch/powerpc/kernel/swsusp.c
index eae33e1..1930e44 100644
--- a/arch/powerpc/kernel/swsusp.c
+++ b/arch/powerpc/kernel/swsusp.c
@@ -32,7 +32,5 @@ void save_processor_state(void)
 
 void restore_processor_state(void)
 {
-#ifdef CONFIG_PPC32
switch_mmu_context(current->active_mm, current->active_mm);
-#endif
 }
-- 
1.8.0


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 1/2] powerpc: add Book E support to 64-bit hibernation

[Wang Dongsheng]

Update the 64-bit hibernation code to support Book E CPUs.
Some registers and instructions are not defined for Book3e
(SDR reg, tlbia instruction).

SDR: Storage Description Register. Book3S and Book3E have different
address translation mode, we do not need HTABORG & HTABSIZE to
translate virtual address to real address.

More registers are saved in BookE-64bit.(TCR, SPRGx, ...)

Signed-off-by: Wang Dongsheng 
---
v2:
* Add: _tlbil_all
*
* The boot core get a virtual address, when the boot process,
* the virtual address corresponds to a physical address. After
* hibernation resume memory snapshots, The corresponding
* relationship between the virtual memory and physical memory
* might change again. We need to get a new page table. So we
* need to invalidate TLB after resume pages.
*
* Invalidations TLB Using tlbilx/tlbivax/MMUCSR0.
* tlbilx used here.
*
* Add: save/restore PID
*
* We must restore PID register, because TLB will use PID. The
* hibernation suspend flow is trapped from user space to kernel
* space, the PID register is user thread pid.
*
* The hibernation resume is begin in kernel start flow, the PID
* alway 0. After the kernel thread back to user thread, there is
* not have context switch and the pid can not update, because the
* kernel thread is trapped form user space. So if we did't restore
* PID the user space of thread will be addressing in the kernel
* space.
*
* There are two ways to restore PID:
* 1/ In this file save/resotre PID register.
* 2/ Form restore_processor_state to restore. this function will
*do context switch.
*switch_mmu_context(current->active_mm, current->active_mm)
*
* PPC32 Using the second method. For consistency reason, PPC64
* using the same way.
*
* History:
* Wood Scott(A): Please investigate the issue of whether we are loading
*kernel module code in this step
* R: Kernel will allocate the memory for module code segment and data
*segment. First allocate a memory, and copy the umod to hdr members
*of the struct load_info. Due to the temporary assigned module belongs
*to the kernel space, so it belongs to the kernel data.
*
*The kernel of all data will be saved when hibernation suspend. So
*the module which has already been inserted will be saved.

 arch/powerpc/kernel/swsusp_asm64.S | 102 -
 1 file changed, 100 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/swsusp_asm64.S 
b/arch/powerpc/kernel/swsusp_asm64.S
index 86ac1d9..c7e2b4a 100644
--- a/arch/powerpc/kernel/swsusp_asm64.S
+++ b/arch/powerpc/kernel/swsusp_asm64.S
@@ -46,10 +46,30 @@
 #define SL_r29 0xe8
 #define SL_r30 0xf0
 #define SL_r31 0xf8
-#define SL_SIZESL_r31+8
+#define SL_SPRG0   0x100
+#define SL_SPRG1   0x108
+#define SL_SPRG2   0x110
+#define SL_SPRG3   0x118
+#define SL_SPRG4   0x120
+#define SL_SPRG5   0x128
+#define SL_SPRG6   0x130
+#define SL_SPRG7   0x138
+#define SL_TCR 0x140
+#define SL_PID 0x148
+#define SL_SIZESL_PID+8
 
 /* these macros rely on the save area being
  * pointed to by r11 */
+
+#define SAVE_SPR(register) \
+   mfspr   r0,SPRN_##register  ;\
+   std r0,SL_##register(r11)
+#define RESTORE_SPR(register)  \
+   ld  r0,SL_##register(r11)   ;\
+   mtspr   SPRN_##register,r0
+#define RESTORE_SPRG(n)\
+   ld  r0,SL_SPRG##n(r11)  ;\
+   mtsprg  n,r0
 #define SAVE_SPECIAL(special)  \
mf##special r0  ;\
std r0, SL_##special(r11)
@@ -103,8 +123,22 @@ _GLOBAL(swsusp_arch_suspend)
SAVE_REGISTER(r30)
SAVE_REGISTER(r31)
SAVE_SPECIAL(MSR)
-   SAVE_SPECIAL(SDR1)
SAVE_SPECIAL(XER)
+#ifdef CONFIG_PPC_BOOK3S_64
+   SAVE_SPECIAL(SDR1)
+#else
+   SAVE_SPR(TCR)
+   /* Save SPRGs */
+   SAVE_SPR(SPRG0)
+   SAVE_SPR(SPRG1)
+   SAVE_SPR(SPRG2)
+   SAVE_SPR(SPRG3)
+   SAVE_SPR(SPRG4)
+   SAVE_SPR(SPRG5)
+   SAVE_SPR(SPRG6)
+   SAVE_SPR(SPRG7)
+   SAVE_SPR(PID);
+#endif
 
/* we push the stack up 128 bytes but don't store the
 * stack pointer on the stack like a real stackframe */
@@ -151,6 +185,7 @@ copy_page_loop:
bne+copyloop
 nothing_to_copy:
 
+#ifdef CONFIG_PPC_BOOK3S_64
/* flush caches */
lis r3, 0x10
mtctr   r3
@@ -167,6 +202,7 @@ nothing_to_copy:
sync
 
tlbia
+#endif
 
ld  r11,swsusp_save_area_ptr@toc(r2)
 
@@ -208,16 +244,78 @@ nothing_to_copy:
RESTORE_REGISTER(r29)
RESTORE_REGISTER(r30)
RESTORE_REGISTER(r31)
+
+#ifdef CONFIG_PPC_BOOK3S_64
/* can't use RESTORE_SPECIAL(MSR) */
ld  r0, SL_MSR(r11)
mtmsrd  r0, 0
RESTORE_SPECIAL(SDR1)
+#else
+   /* Save SPRGs */
+   RESTORE_SPRG(0)
+   RESTORE_SPRG(

RE: [PATCH] powerpc/mpc85xx: fix non-bootcpu cannot up after hibernation resume

[Wang Dongsheng-B40534]

Thanks anton.

> -Original Message-
> From: Anton Vorontsov [mailto:an...@scarybugs.org] On Behalf Of Anton
> Vorontsov
> Sent: Friday, May 24, 2013 1:34 AM
> To: Wang Dongsheng-B40534
> Cc: pau...@samba.org; r...@sisk.pl; b...@kernel.crashing.org;
> johan...@sipsolutions.net; Wood Scott-B07421; Li Yang-R58472; Zhao
> Chenhui-B35336; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] powerpc/mpc85xx: fix non-bootcpu cannot up after
> hibernation resume
> 
> Hi!
> 
> On Tue, May 14, 2013 at 08:59:13AM +, Wang Dongsheng-B40534 wrote:
> > I send to a wrong email address "Anton Vorontsov
> "
> >
> > Add Anton Vorontsov  to this email.
> 
> I don't have any means to test it, but the patch itself looks good and
> the description makes sense. So,
> 
> Reviewed-by: Anton Vorontsov 
> 
> Thanks!
> 
> >
> > Thanks all.
> >
> > > -Original Message-
> > > From: Wang Dongsheng-B40534
> > > Sent: Tuesday, May 14, 2013 4:06 PM
> > > To: avoront...@ru.mvista.com
> > > Cc: pau...@samba.org; r...@sisk.pl; b...@kernel.crashing.org;
> > > johan...@sipsolutions.net; Wood Scott-B07421; Li Yang-R58472; Zhao
> > > Chenhui-B35336; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > > Subject: [PATCH] powerpc/mpc85xx: fix non-bootcpu cannot up after
> > > hibernation resume
> > >
> > > This problem belongs to the core synchronization issues.
> > > The cpu1 already updated spin_table values, but bootcore cannot get
> > > this value in time.
> > >
> > > After bootcpu hibiernation restore the pages. we are now running
> > > with the kernel data of the old kernel fully restored. if we reset
> > > the non-bootcpus that will be reset cache(tlb), the non-bootcpus
> > > will get new address(map virtual and physical address spaces).
> > > but bootcpu tlb cache still use boot kernel data, so we need to
> > > invalidate the bootcpu tlb cache make it to get new main memory data.
> > >
> > > log:
> > > Enabling non-boot CPUs ...
> > > smp_85xx_kick_cpu: timeout waiting for core 1 to reset
> > > smp: failed starting cpu 1 (rc -2)
> > > Error taking CPU1 up: -2
> > >
> > > Signed-off-by: Wang Dongsheng 
> > >
> > > diff --git a/arch/powerpc/kernel/swsusp_booke.S
> > > b/arch/powerpc/kernel/swsusp_booke.S
> > > index 11a3930..9503249 100644
> > > --- a/arch/powerpc/kernel/swsusp_booke.S
> > > +++ b/arch/powerpc/kernel/swsusp_booke.S
> > > @@ -141,6 +141,19 @@ _GLOBAL(swsusp_arch_resume)
> > >   lis r11,swsusp_save_area@h
> > >   ori r11,r11,swsusp_save_area@l
> > >
> > > + /*
> > > +  * The boot core get a virtual address, when the boot process,
> > > +  * the virtual address corresponds to a physical address. After
> > > +  * hibernation resume memory snapshots, The corresponding
> > > +  * relationship between the virtual memory and physical memory
> > > +  * might change again. We need to get a new page table. So we
> > > +  * need to invalidate TLB after resume pages.
> > > +  *
> > > +  * Invalidations TLB Using tlbilx/tlbivax/MMUCSR0.
> > > +  * tlbilx used here.
> > > +  */
> > > + bl  _tlbil_all
> > > +
> > >   lwz r4,SL_SPRG0(r11)
> > >   mtsprg  0,r4
> > >   lwz r4,SL_SPRG1(r11)
> > > --
> > > 1.8.0
> >
> >

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support

[Wang Dongsheng-B40534]

Thanks ben. :)

- dongsheng.

> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
> Sent: Monday, May 13, 2013 1:00 PM
> To: Wang Dongsheng-B40534
> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
> ga...@kernel.crashing.org
> Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> 
> On Mon, 2013-05-13 at 04:25 +, Wang Dongsheng-B40534 wrote:
> > Hi Benjamin,
> >
> > Could you apply these patches?
> 
> I'll have a look, I was assuming Kumar would take them but since not I'll
> queue them up.
> 
> Cheers,
> Ben.
> 
> > Scott already ACK.
> >
> > [v3,1/4] powerpc/mpic: add irq_set_wake support
> > http://patchwork.ozlabs.org/patch/234934/
> >
> > [v3,2/4] powerpc/mpic: add global timer support
> > http://patchwork.ozlabs.org/patch/234935/
> >
> > [v3,3/4] powerpc/mpic: create mpic subsystem object
> > http://patchwork.ozlabs.org/patch/234936/
> >
> > [v3,4/4] powerpc/fsl: add MPIC timer wakeup support
> > http://patchwork.ozlabs.org/patch/234937/
> >
> > Thanks.
> >
> > > -Original Message-
> > > From: Wang Dongsheng-B40534
> > > Sent: Friday, May 03, 2013 9:54 AM
> > > To: 'ga...@kernel.crashing.org'
> > > Cc: 'linuxppc-dev@lists.ozlabs.org'; Wood Scott-B07421;
> > > 'b...@kernel.crashing.org'
> > > Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> > >
> > > Hi Kumar,
> > >
> > > Could you apply these patches?
> > >
> > > Thanks.
> > >
> > > > -Original Message-
> > > > From: Wang Dongsheng-B40534
> > > > Sent: Tuesday, April 23, 2013 6:10 PM
> > > > To: ga...@kernel.crashing.org
> > > > Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421
> > > > Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> > > >
> > > > Hi Kumar,
> > > >
> > > > Could you apply these patches?
> > > >
> > > > Thanks.
> > > >
> > > > [v3,1/4] powerpc/mpic: add irq_set_wake support
> > > > http://patchwork.ozlabs.org/patch/234934/
> > > >
> > > > [v3,2/4] powerpc/mpic: add global timer support
> > > > http://patchwork.ozlabs.org/patch/234935/
> > > >
> > > > [v3,3/4] powerpc/mpic: create mpic subsystem object
> > > > http://patchwork.ozlabs.org/patch/234936/
> > > >
> > > > [v3,4/4] powerpc/fsl: add MPIC timer wakeup support
> > > > http://patchwork.ozlabs.org/patch/234937/
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, April 17, 2013 7:30 AM
> > > > > To: Wang Dongsheng-B40534
> > > > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org;
> > > > > ga...@kernel.crashing.org
> > > > > Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake
> > > > > support
> > > > >
> > > > > ACK
> > > > >
> > > > > -Scott
> > > > >
> > > > > On 04/16/2013 05:58:52 AM, Wang Dongsheng-B40534 wrote:
> > > > > > Hi scott,
> > > > > >
> > > > > > Could you ACK these patches?
> > > > > >
> > > > > > [PATCH v3 2/4] powerpc/mpic: add global timer support [PATCH
> > > > > > v3 3/4]
> > > > > > powerpc/mpic: create mpic subsystem object [PATCH v3 4/4]
> > > > > > powerpc/fsl: add MPIC timer wakeup support
> > > > > >
> > > > > > Thanks.
> > > > > >
> 
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] powerpc/mpc85xx: fix non-bootcpu cannot up after hibernation resume

[Wang Dongsheng-B40534]

I send to a wrong email address "Anton Vorontsov "

Add Anton Vorontsov  to this email.

Thanks all.

> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Tuesday, May 14, 2013 4:06 PM
> To: avoront...@ru.mvista.com
> Cc: pau...@samba.org; r...@sisk.pl; b...@kernel.crashing.org;
> johan...@sipsolutions.net; Wood Scott-B07421; Li Yang-R58472; Zhao
> Chenhui-B35336; linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> Subject: [PATCH] powerpc/mpc85xx: fix non-bootcpu cannot up after
> hibernation resume
> 
> This problem belongs to the core synchronization issues.
> The cpu1 already updated spin_table values, but bootcore cannot get
> this value in time.
> 
> After bootcpu hibiernation restore the pages. we are now running
> with the kernel data of the old kernel fully restored. if we reset
> the non-bootcpus that will be reset cache(tlb), the non-bootcpus
> will get new address(map virtual and physical address spaces).
> but bootcpu tlb cache still use boot kernel data, so we need to
> invalidate the bootcpu tlb cache make it to get new main memory data.
> 
> log:
> Enabling non-boot CPUs ...
> smp_85xx_kick_cpu: timeout waiting for core 1 to reset
> smp: failed starting cpu 1 (rc -2)
> Error taking CPU1 up: -2
> 
> Signed-off-by: Wang Dongsheng 
> 
> diff --git a/arch/powerpc/kernel/swsusp_booke.S
> b/arch/powerpc/kernel/swsusp_booke.S
> index 11a3930..9503249 100644
> --- a/arch/powerpc/kernel/swsusp_booke.S
> +++ b/arch/powerpc/kernel/swsusp_booke.S
> @@ -141,6 +141,19 @@ _GLOBAL(swsusp_arch_resume)
>   lis r11,swsusp_save_area@h
>   ori r11,r11,swsusp_save_area@l
> 
> + /*
> +  * The boot core get a virtual address, when the boot process,
> +  * the virtual address corresponds to a physical address. After
> +  * hibernation resume memory snapshots, The corresponding
> +  * relationship between the virtual memory and physical memory
> +  * might change again. We need to get a new page table. So we
> +  * need to invalidate TLB after resume pages.
> +  *
> +  * Invalidations TLB Using tlbilx/tlbivax/MMUCSR0.
> +  * tlbilx used here.
> +  */
> + bl  _tlbil_all
> +
>   lwz r4,SL_SPRG0(r11)
>   mtsprg  0,r4
>   lwz r4,SL_SPRG1(r11)
> --
> 1.8.0


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/mpc85xx: fix non-bootcpu cannot up after hibernation resume

[Wang Dongsheng]

This problem belongs to the core synchronization issues.
The cpu1 already updated spin_table values, but bootcore cannot get
this value in time.

After bootcpu hibiernation restore the pages. we are now running
with the kernel data of the old kernel fully restored. if we reset
the non-bootcpus that will be reset cache(tlb), the non-bootcpus
will get new address(map virtual and physical address spaces).
but bootcpu tlb cache still use boot kernel data, so we need to
invalidate the bootcpu tlb cache make it to get new main memory data.

log:
Enabling non-boot CPUs ...
smp_85xx_kick_cpu: timeout waiting for core 1 to reset
smp: failed starting cpu 1 (rc -2)
Error taking CPU1 up: -2

Signed-off-by: Wang Dongsheng 

diff --git a/arch/powerpc/kernel/swsusp_booke.S 
b/arch/powerpc/kernel/swsusp_booke.S
index 11a3930..9503249 100644
--- a/arch/powerpc/kernel/swsusp_booke.S
+++ b/arch/powerpc/kernel/swsusp_booke.S
@@ -141,6 +141,19 @@ _GLOBAL(swsusp_arch_resume)
lis r11,swsusp_save_area@h
ori r11,r11,swsusp_save_area@l
 
+   /*
+* The boot core get a virtual address, when the boot process,
+* the virtual address corresponds to a physical address. After
+* hibernation resume memory snapshots, The corresponding
+* relationship between the virtual memory and physical memory
+* might change again. We need to get a new page table. So we
+* need to invalidate TLB after resume pages.
+*
+* Invalidations TLB Using tlbilx/tlbivax/MMUCSR0.
+* tlbilx used here.
+*/
+   bl  _tlbil_all
+
lwz r4,SL_SPRG0(r11)
mtsprg  0,r4
lwz r4,SL_SPRG1(r11)
-- 
1.8.0


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support

[Wang Dongsheng-B40534]

Hi Benjamin,

Could you apply these patches?

Scott already ACK.

[v3,1/4] powerpc/mpic: add irq_set_wake support
http://patchwork.ozlabs.org/patch/234934/

[v3,2/4] powerpc/mpic: add global timer support
http://patchwork.ozlabs.org/patch/234935/

[v3,3/4] powerpc/mpic: create mpic subsystem object
http://patchwork.ozlabs.org/patch/234936/

[v3,4/4] powerpc/fsl: add MPIC timer wakeup support
http://patchwork.ozlabs.org/patch/234937/

Thanks.

> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Friday, May 03, 2013 9:54 AM
> To: 'ga...@kernel.crashing.org'
> Cc: 'linuxppc-dev@lists.ozlabs.org'; Wood Scott-B07421;
> 'b...@kernel.crashing.org'
> Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> 
> Hi Kumar,
> 
> Could you apply these patches?
> 
> Thanks.
> 
> > -Original Message-
> > From: Wang Dongsheng-B40534
> > Sent: Tuesday, April 23, 2013 6:10 PM
> > To: ga...@kernel.crashing.org
> > Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421
> > Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> >
> > Hi Kumar,
> >
> > Could you apply these patches?
> >
> > Thanks.
> >
> > [v3,1/4] powerpc/mpic: add irq_set_wake support
> > http://patchwork.ozlabs.org/patch/234934/
> >
> > [v3,2/4] powerpc/mpic: add global timer support
> > http://patchwork.ozlabs.org/patch/234935/
> >
> > [v3,3/4] powerpc/mpic: create mpic subsystem object
> > http://patchwork.ozlabs.org/patch/234936/
> >
> > [v3,4/4] powerpc/fsl: add MPIC timer wakeup support
> > http://patchwork.ozlabs.org/patch/234937/
> >
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, April 17, 2013 7:30 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org;
> > > ga...@kernel.crashing.org
> > > Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> > >
> > > ACK
> > >
> > > -Scott
> > >
> > > On 04/16/2013 05:58:52 AM, Wang Dongsheng-B40534 wrote:
> > > > Hi scott,
> > > >
> > > > Could you ACK these patches?
> > > >
> > > > [PATCH v3 2/4] powerpc/mpic: add global timer support [PATCH v3
> > > > 3/4]
> > > > powerpc/mpic: create mpic subsystem object [PATCH v3 4/4]
> > > > powerpc/fsl: add MPIC timer wakeup support
> > > >
> > > > Thanks.
> > > >

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support

[Wang Dongsheng-B40534]

Hi Kumar,

Could you apply these patches?

Thanks.

> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Tuesday, April 23, 2013 6:10 PM
> To: ga...@kernel.crashing.org
> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421
> Subject: RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> 
> Hi Kumar,
> 
> Could you apply these patches?
> 
> Thanks.
> 
> [v3,1/4] powerpc/mpic: add irq_set_wake support
> http://patchwork.ozlabs.org/patch/234934/
> 
> [v3,2/4] powerpc/mpic: add global timer support
> http://patchwork.ozlabs.org/patch/234935/
> 
> [v3,3/4] powerpc/mpic: create mpic subsystem object
> http://patchwork.ozlabs.org/patch/234936/
> 
> [v3,4/4] powerpc/fsl: add MPIC timer wakeup support
> http://patchwork.ozlabs.org/patch/234937/
> 
> 
> > -Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, April 17, 2013 7:30 AM
> > To: Wang Dongsheng-B40534
> > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org;
> > ga...@kernel.crashing.org
> > Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> >
> > ACK
> >
> > -Scott
> >
> > On 04/16/2013 05:58:52 AM, Wang Dongsheng-B40534 wrote:
> > > Hi scott,
> > >
> > > Could you ACK these patches?
> > >
> > > [PATCH v3 2/4] powerpc/mpic: add global timer support [PATCH v3 3/4]
> > > powerpc/mpic: create mpic subsystem object [PATCH v3 4/4]
> > > powerpc/fsl: add MPIC timer wakeup support
> > >
> > > Thanks.
> > >

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support

[Wang Dongsheng-B40534]

Hi Kumar,

Could you apply these patches?

Thanks.

[v3,1/4] powerpc/mpic: add irq_set_wake support
http://patchwork.ozlabs.org/patch/234934/

[v3,2/4] powerpc/mpic: add global timer support
http://patchwork.ozlabs.org/patch/234935/

[v3,3/4] powerpc/mpic: create mpic subsystem object
http://patchwork.ozlabs.org/patch/234936/

[v3,4/4] powerpc/fsl: add MPIC timer wakeup support
http://patchwork.ozlabs.org/patch/234937/


> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, April 17, 2013 7:30 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org;
> ga...@kernel.crashing.org
> Subject: Re: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> 
> ACK
> 
> -Scott
> 
> On 04/16/2013 05:58:52 AM, Wang Dongsheng-B40534 wrote:
> > Hi scott,
> >
> > Could you ACK these patches?
> >
> > [PATCH v3 2/4] powerpc/mpic: add global timer support
> > [PATCH v3 3/4] powerpc/mpic: create mpic subsystem object
> > [PATCH v3 4/4] powerpc/fsl: add MPIC timer wakeup support
> >
> > Thanks.
> >

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support

[Wang Dongsheng-B40534]

Hi scott,

Could you ACK these patches?

[PATCH v3 2/4] powerpc/mpic: add global timer support
[PATCH v3 3/4] powerpc/mpic: create mpic subsystem object
[PATCH v3 4/4] powerpc/fsl: add MPIC timer wakeup support

Thanks.

> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Tuesday, April 09, 2013 10:22 AM
> To: Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> Subject: [PATCH v3 1/4] powerpc/mpic: add irq_set_wake support
> 
> Add irq_set_wake support. Just add IRQF_NO_SUSPEND to desc->action->flag.
> So the wake up interrupt will not be disable in suspend_device_irqs.
> 
> Signed-off-by: Wang Dongsheng 
> ---
> v3:
> * Modify: Change "EINVAL" to "ENXIO" in mpic_irq_set_wake()
> 
> v2:
> * Add: Check freescale chip in mpic_irq_set_wake().
> * Remove: Support mpic_irq_set_wake() in ht_chip.
> 
>  arch/powerpc/sysdev/mpic.c | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index 3b2efd4..ae709d2 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -920,6 +920,22 @@ int mpic_set_irq_type(struct irq_data *d, unsigned
> int flow_type)
>   return IRQ_SET_MASK_OK_NOCOPY;
>  }
> 
> +static int mpic_irq_set_wake(struct irq_data *d, unsigned int on) {
> + struct irq_desc *desc = container_of(d, struct irq_desc, irq_data);
> + struct mpic *mpic = mpic_from_irq_data(d);
> +
> + if (!(mpic->flags & MPIC_FSL))
> + return -ENXIO;
> +
> + if (on)
> + desc->action->flags |= IRQF_NO_SUSPEND;
> + else
> + desc->action->flags &= ~IRQF_NO_SUSPEND;
> +
> + return 0;
> +}
> +
>  void mpic_set_vector(unsigned int virq, unsigned int vector)  {
>   struct mpic *mpic = mpic_from_irq(virq); @@ -957,6 +973,7 @@ static
> struct irq_chip mpic_irq_chip = {
>   .irq_unmask = mpic_unmask_irq,
>   .irq_eoi= mpic_end_irq,
>   .irq_set_type   = mpic_set_irq_type,
> + .irq_set_wake   = mpic_irq_set_wake,
>  };
> 
>  #ifdef CONFIG_SMP
> @@ -971,6 +988,7 @@ static struct irq_chip mpic_tm_chip = {
>   .irq_mask   = mpic_mask_tm,
>   .irq_unmask = mpic_unmask_tm,
>   .irq_eoi= mpic_end_irq,
> + .irq_set_wake   = mpic_irq_set_wake,
>  };
> 
>  #ifdef CONFIG_MPIC_U3_HT_IRQS
> --
> 1.8.0


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 4/4] powerpc/fsl: add MPIC timer wakeup support

[Wang Dongsheng]

The driver provides a way to wake up the system by the MPIC timer.

For example,
echo 5 > /sys/devices/system/mpic/timer_wakeup
echo standby > /sys/power/state

After 5 seconds the MPIC timer will generate an interrupt to wake up
the system.

Signed-off-by: Wang Dongsheng 
Signed-off-by: Zhao Chenhui 
Signed-off-by: Li Yang 
---
v2:
* Remove: Create mpic subsystem.

 arch/powerpc/platforms/Kconfig  |   9 ++
 arch/powerpc/sysdev/Makefile|   1 +
 arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c | 161 
 3 files changed, 171 insertions(+)
 create mode 100644 arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c

diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index c447b3c..3d934ba 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -99,6 +99,15 @@ config MPIC_TIMER
  chip, but it can potentially support other global timers
  complying with the OpenPIC standard.
 
+config FSL_MPIC_TIMER_WAKEUP
+   tristate "Freescale MPIC global timer wakeup driver"
+   depends on FSL_SOC &&  MPIC_TIMER && PM
+   default n
+   help
+ The driver provides a way to wake up the system by MPIC
+ timer.
+ e.g. "echo 5 > /sys/devices/system/mpic/timer_wakeup"
+
 config PPC_EPAPR_HV_PIC
bool
default n
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index ff6184a..e1b8a80 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -5,6 +5,7 @@ ccflags-$(CONFIG_PPC64) := -mno-minimal-toc
 mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
 obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
 obj-$(CONFIG_MPIC_TIMER)+= mpic_timer.o
+obj-$(CONFIG_FSL_MPIC_TIMER_WAKEUP)+= fsl_mpic_timer_wakeup.o
 mpic-msgr-obj-$(CONFIG_MPIC_MSGR)  += mpic_msgr.o
 obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y) $(mpic-msgr-obj-y)
 obj-$(CONFIG_PPC_EPAPR_HV_PIC) += ehv_pic.o
diff --git a/arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c 
b/arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c
new file mode 100644
index 000..1707bf0
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c
@@ -0,0 +1,161 @@
+/*
+ * MPIC timer wakeup driver
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct fsl_mpic_timer_wakeup {
+   struct mpic_timer *timer;
+   struct work_struct free_work;
+};
+
+static struct fsl_mpic_timer_wakeup *fsl_wakeup;
+static DEFINE_MUTEX(sysfs_lock);
+
+static void fsl_free_resource(struct work_struct *ws)
+{
+   struct fsl_mpic_timer_wakeup *wakeup =
+   container_of(ws, struct fsl_mpic_timer_wakeup, free_work);
+
+   mutex_lock(&sysfs_lock);
+
+   if (wakeup->timer) {
+   disable_irq_wake(wakeup->timer->irq);
+   mpic_free_timer(wakeup->timer);
+   }
+
+   wakeup->timer = NULL;
+   mutex_unlock(&sysfs_lock);
+}
+
+static irqreturn_t fsl_mpic_timer_irq(int irq, void *dev_id)
+{
+   struct fsl_mpic_timer_wakeup *wakeup = dev_id;
+
+   schedule_work(&wakeup->free_work);
+
+   return wakeup->timer ? IRQ_HANDLED : IRQ_NONE;
+}
+
+static ssize_t fsl_timer_wakeup_show(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct timeval interval;
+   int val = 0;
+
+   mutex_lock(&sysfs_lock);
+   if (fsl_wakeup->timer) {
+   mpic_get_remain_time(fsl_wakeup->timer, &interval);
+   val = interval.tv_sec + 1;
+   }
+   mutex_unlock(&sysfs_lock);
+
+   return sprintf(buf, "%d\n", val);
+}
+
+static ssize_t fsl_timer_wakeup_store(struct device *dev,
+   struct device_attribute *attr,
+   const char *buf,
+   size_t count)
+{
+   struct timeval interval;
+   int ret;
+
+   interval.tv_usec = 0;
+   if (kstrtol(buf, 0, &interval.tv_sec))
+   return -EINVAL;
+
+   mutex_lock(&sysfs_lock);
+
+   if (fsl_wakeup->timer) {
+   disable_irq_wake(fsl_wakeup->timer->irq);
+   mpic_free_timer(fsl_wakeup->timer);
+   fsl_wakeup->timer = NULL;
+   }
+
+   if (!interval.tv_sec) {
+   mutex_unlock(&sysfs_lock);
+   return count;
+   }
+
+   fsl_wakeup->timer = mpic_request_timer(fsl_mpic_timer_irq

[PATCH v3 3/4] powerpc/mpic: create mpic subsystem object

[Wang Dongsheng]

Register a mpic subsystem at /sys/devices/system/

Signed-off-by: Wang Dongsheng 
---
 arch/powerpc/include/asm/mpic.h | 2 ++
 arch/powerpc/sysdev/mpic.c  | 8 
 2 files changed, 10 insertions(+)

diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index c0f9ef9..fa70e9b 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -339,6 +339,8 @@ struct mpic
 #endif
 };
 
+extern struct bus_type mpic_subsys;
+
 /*
  * MPIC flags (passed to mpic_alloc)
  *
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index ae709d2..58e7661 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -48,6 +48,12 @@
 #define DBG(fmt...)
 #endif
 
+struct bus_type mpic_subsys = {
+   .name = "mpic",
+   .dev_name = "mpic",
+};
+EXPORT_SYMBOL_GPL(mpic_subsys);
+
 static struct mpic *mpics;
 static struct mpic *mpic_primary;
 static DEFINE_RAW_SPINLOCK(mpic_lock);
@@ -1989,6 +1995,8 @@ static struct syscore_ops mpic_syscore_ops = {
 static int mpic_init_sys(void)
 {
register_syscore_ops(&mpic_syscore_ops);
+   subsys_system_register(&mpic_subsys, NULL);
+
return 0;
 }
 
-- 
1.8.0


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v3 2/4] powerpc/mpic: add global timer support

[Wang Dongsheng]

The MPIC global timer is a hardware timer inside the Freescale PIC complying
with OpenPIC standard. When the specified interval times out, the hardware
timer generates an interrupt. The driver currently is only tested on fsl chip,
but it can potentially support other global timers complying to OpenPIC
standard.

The two independent groups of global timer on fsl chip, group A and group B,
are identical in their functionality, except that they appear at different
locations within the PIC register map. The hardware timer can be cascaded to
create timers larger than the default 31-bit global timers. Timer cascade
fields allow configuration of up to two 63-bit timers. But These two groups
of timers cannot be cascaded together.

It can be used as a wakeup source for low power modes. It also could be used
as periodical timer for protocols, drivers and etc.

Signed-off-by: Wang Dongsheng 
Signed-off-by: Li Yang 
---
v2:
* Modify: Set timer clock frequency in timer_group_get_freq().
* Modify: Change some of the comments. 

 arch/powerpc/include/asm/mpic_timer.h |  46 +++
 arch/powerpc/platforms/Kconfig|  12 +
 arch/powerpc/sysdev/Makefile  |   1 +
 arch/powerpc/sysdev/mpic_timer.c  | 593 ++
 4 files changed, 652 insertions(+)
 create mode 100644 arch/powerpc/include/asm/mpic_timer.h
 create mode 100644 arch/powerpc/sysdev/mpic_timer.c

diff --git a/arch/powerpc/include/asm/mpic_timer.h 
b/arch/powerpc/include/asm/mpic_timer.h
new file mode 100644
index 000..0e23cd4
--- /dev/null
+++ b/arch/powerpc/include/asm/mpic_timer.h
@@ -0,0 +1,46 @@
+/*
+ * arch/powerpc/include/asm/mpic_timer.h
+ *
+ * Header file for Mpic Global Timer
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * Author: Wang Dongsheng 
+ *Li Yang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#ifndef __MPIC_TIMER__
+#define __MPIC_TIMER__
+
+#include 
+#include 
+
+struct mpic_timer {
+   void*dev;
+   struct cascade_priv *cascade_handle;
+   unsigned intnum;
+   unsigned intirq;
+};
+
+#ifdef CONFIG_MPIC_TIMER
+struct mpic_timer *mpic_request_timer(irq_handler_t fn,  void *dev,
+   const struct timeval *time);
+void mpic_start_timer(struct mpic_timer *handle);
+void mpic_stop_timer(struct mpic_timer *handle);
+void mpic_get_remain_time(struct mpic_timer *handle, struct timeval *time);
+void mpic_free_timer(struct mpic_timer *handle);
+#else
+struct mpic_timer *mpic_request_timer(irq_handler_t fn,  void *dev,
+   const struct timeval *time) { return NULL; }
+void mpic_start_timer(struct mpic_timer *handle) { }
+void mpic_stop_timer(struct mpic_timer *handle) { }
+void mpic_get_remain_time(struct mpic_timer *handle, struct timeval *time) { }
+void mpic_free_timer(struct mpic_timer *handle) { }
+#endif
+
+#endif
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 48a920d..c447b3c 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -87,6 +87,18 @@ config MPIC
bool
default n
 
+config MPIC_TIMER
+   bool "MPIC Global Timer"
+   depends on MPIC && FSL_SOC
+   default n
+   help
+ The MPIC global timer is a hardware timer inside the
+ Freescale PIC complying with OpenPIC standard. When the
+ specified interval times out, the hardware timer generates
+ an interrupt. The driver currently is only tested on fsl
+ chip, but it can potentially support other global timers
+ complying with the OpenPIC standard.
+
 config PPC_EPAPR_HV_PIC
bool
default n
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index a57600b..ff6184a 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -4,6 +4,7 @@ ccflags-$(CONFIG_PPC64) := -mno-minimal-toc
 
 mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
 obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
+obj-$(CONFIG_MPIC_TIMER)+= mpic_timer.o
 mpic-msgr-obj-$(CONFIG_MPIC_MSGR)  += mpic_msgr.o
 obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y) $(mpic-msgr-obj-y)
 obj-$(CONFIG_PPC_EPAPR_HV_PIC) += ehv_pic.o
diff --git a/arch/powerpc/sysdev/mpic_timer.c b/arch/powerpc/sysdev/mpic_timer.c
new file mode 100644
index 000..c06db92
--- /dev/null
+++ b/arch/powerpc/sysdev/mpic_timer.c
@@ -0,0 +1,593 @@
+/*
+ * MPIC timer driver
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ * Author: Dongsheng Wang 
+ *Li Yang 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as publish

[PATCH v3 1/4] powerpc/mpic: add irq_set_wake support

[Wang Dongsheng]

Add irq_set_wake support. Just add IRQF_NO_SUSPEND to desc->action->flag.
So the wake up interrupt will not be disable in suspend_device_irqs.

Signed-off-by: Wang Dongsheng 
---
v3:
* Modify: Change "EINVAL" to "ENXIO" in mpic_irq_set_wake()

v2:
* Add: Check freescale chip in mpic_irq_set_wake().
* Remove: Support mpic_irq_set_wake() in ht_chip.

 arch/powerpc/sysdev/mpic.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 3b2efd4..ae709d2 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -920,6 +920,22 @@ int mpic_set_irq_type(struct irq_data *d, unsigned int 
flow_type)
return IRQ_SET_MASK_OK_NOCOPY;
 }
 
+static int mpic_irq_set_wake(struct irq_data *d, unsigned int on)
+{
+   struct irq_desc *desc = container_of(d, struct irq_desc, irq_data);
+   struct mpic *mpic = mpic_from_irq_data(d);
+
+   if (!(mpic->flags & MPIC_FSL))
+   return -ENXIO;
+
+   if (on)
+   desc->action->flags |= IRQF_NO_SUSPEND;
+   else
+   desc->action->flags &= ~IRQF_NO_SUSPEND;
+
+   return 0;
+}
+
 void mpic_set_vector(unsigned int virq, unsigned int vector)
 {
struct mpic *mpic = mpic_from_irq(virq);
@@ -957,6 +973,7 @@ static struct irq_chip mpic_irq_chip = {
.irq_unmask = mpic_unmask_irq,
.irq_eoi= mpic_end_irq,
.irq_set_type   = mpic_set_irq_type,
+   .irq_set_wake   = mpic_irq_set_wake,
 };
 
 #ifdef CONFIG_SMP
@@ -971,6 +988,7 @@ static struct irq_chip mpic_tm_chip = {
.irq_mask   = mpic_mask_tm,
.irq_unmask = mpic_unmask_tm,
.irq_eoi= mpic_end_irq,
+   .irq_set_wake   = mpic_irq_set_wake,
 };
 
 #ifdef CONFIG_MPIC_U3_HT_IRQS
-- 
1.8.0


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wang Dongsheng-B40534
> Sent: Wednesday, April 03, 2013 10:49 AM
> To: Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: RE: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support
> 
> 
> 
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, April 03, 2013 8:37 AM
> > To: Wang Dongsheng-B40534
> > Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > Subject: Re: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support
> >
> > On 04/02/2013 01:40:37 AM, Wang Dongsheng wrote:
> > > Add irq_set_wake support. Just add IRQF_NO_SUSPEND to
> > > desc->action->flag.
> > > So the wake up interrupt will not be disable in suspend_device_irqs.
> > >
> > > Signed-off-by: Wang Dongsheng 
> > > ---
> > > v2:
> > > * Add: Check freescale chip in mpic_irq_set_wake().
> > > * Remove: Support mpic_irq_set_wake() in ht_chip.
> > >
> > >  arch/powerpc/sysdev/mpic.c | 18 ++
> > >  1 file changed, 18 insertions(+)
> > >
> > > diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> > > index 3b2efd4..50d1ee1 100644
> > > --- a/arch/powerpc/sysdev/mpic.c
> > > +++ b/arch/powerpc/sysdev/mpic.c
> > > @@ -920,6 +920,22 @@ int mpic_set_irq_type(struct irq_data *d,
> > > unsigned int flow_type)
> > >   return IRQ_SET_MASK_OK_NOCOPY;
> > >  }
> > >
> > > +static int mpic_irq_set_wake(struct irq_data *d, unsigned int on) {
> > > + struct irq_desc *desc = container_of(d, struct irq_desc,
> > > irq_data);
> > > + struct mpic *mpic = mpic_from_irq_data(d);
> > > +
> > > + if (!(mpic->flags & MPIC_FSL))
> > > + return -EINVAL;
> >
> > I was thinking more along the lines of using MPIC_FSL during init to
> > decide whether to write this function to .irq_set_wake,
> 
> I think the static registration method is more reasonable. We must
> consider readability. And mpic_irq_set_wake() will not be frequent calls.
> So within
> mpic_irq_set_wake() to decide is reasonable.
> 
> > though that could probably wait until there's a second type of MPIC
> > that needs this (if ever).
> Even if the mpic_irq_set_wake() register in the first type of MPIC that
> is not belong MPIC_FSL, the function can return errno. I think the errno
> should be "-ENXIO".
> See kernel/irq/manage.c, set_irq_wake_real() the return value.
> The desc->irq_data.chip->irq_set_wake is null, the errno is -ENXIO.
> 
> s/-EINVAL/-ENXIO/
About patches, if there are no other suggestion I'll send the V3.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] powerpc: add Book E support to 64-bit hibernation

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Thursday, April 04, 2013 4:16 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Johannes Berg; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] powerpc: add Book E support to 64-bit hibernation
> 
> On 04/03/2013 12:36:41 AM, Wang Dongsheng-B40534 wrote:
> >
> >
> > > -Original Message-
> > > From: Wood Scott-B07421
> > > Sent: Wednesday, April 03, 2013 8:35 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Wood Scott-B07421; Johannes Berg; linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: [PATCH] powerpc: add Book E support to 64-bit
> > hibernation
> > >
> > > On 04/02/2013 12:28:40 AM, Wang Dongsheng-B40534 wrote:
> > > > Hi scott & Johannes,
> > > >
> > > > Thanks for reviewing.
> > > >
> > > > @scott, About this patch, could you please help ack this patch?
> > >
> > > Please investigate the issue of whether we are loading kernel module
> > > code in this step, and whether cache flushing is needed as a result.
> > >
> > Sorry, I am not very clear what you mean.
> > When the kernel boot end, modprobe some xx.ko?
> 
> Suppose, before the kernel was suspended, modules had been loaded.  At
> what point do those modules get restored, and when does the cache get
> flushed?
> 
Before the kernel was suspended, modules had been loaded, the modules is
already in memory. And /lib/modules/* is belong to vfs.
When suspend to disk, all used pages will be saved.(Include VFS, Loaded modules)
When restore, the kernel will not modprobe again.
The non-bootcpu will restore all pages.(Include VFS, Loaded modules)

So, It does not need to flush.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH] powerpc: add Book E support to 64-bit hibernation

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, April 03, 2013 8:35 AM
> To: Wang Dongsheng-B40534
> Cc: Wood Scott-B07421; Johannes Berg; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] powerpc: add Book E support to 64-bit hibernation
> 
> On 04/02/2013 12:28:40 AM, Wang Dongsheng-B40534 wrote:
> > Hi scott & Johannes,
> >
> > Thanks for reviewing.
> >
> > @scott, About this patch, could you please help ack this patch?
> 
> Please investigate the issue of whether we are loading kernel module
> code in this step, and whether cache flushing is needed as a result.
> 
Sorry, I am not very clear what you mean.
When the kernel boot end, modprobe some xx.ko?

> Is there any chance we could even be loading user code here, e.g. if
> it's mlocked and thus couldn't be swapped out?


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support

[Wang Dongsheng-B40534]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, April 03, 2013 8:37 AM
> To: Wang Dongsheng-B40534
> Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> Subject: Re: [PATCH v2 1/4] powerpc/mpic: add irq_set_wake support
> 
> On 04/02/2013 01:40:37 AM, Wang Dongsheng wrote:
> > Add irq_set_wake support. Just add IRQF_NO_SUSPEND to
> > desc->action->flag.
> > So the wake up interrupt will not be disable in suspend_device_irqs.
> >
> > Signed-off-by: Wang Dongsheng 
> > ---
> > v2:
> > * Add: Check freescale chip in mpic_irq_set_wake().
> > * Remove: Support mpic_irq_set_wake() in ht_chip.
> >
> >  arch/powerpc/sysdev/mpic.c | 18 ++
> >  1 file changed, 18 insertions(+)
> >
> > diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> > index 3b2efd4..50d1ee1 100644
> > --- a/arch/powerpc/sysdev/mpic.c
> > +++ b/arch/powerpc/sysdev/mpic.c
> > @@ -920,6 +920,22 @@ int mpic_set_irq_type(struct irq_data *d,
> > unsigned int flow_type)
> > return IRQ_SET_MASK_OK_NOCOPY;
> >  }
> >
> > +static int mpic_irq_set_wake(struct irq_data *d, unsigned int on) {
> > +   struct irq_desc *desc = container_of(d, struct irq_desc,
> > irq_data);
> > +   struct mpic *mpic = mpic_from_irq_data(d);
> > +
> > +   if (!(mpic->flags & MPIC_FSL))
> > +   return -EINVAL;
> 
> I was thinking more along the lines of using MPIC_FSL during init to
> decide whether to write this function to .irq_set_wake,

I think the static registration method is more reasonable. We must consider
readability. And mpic_irq_set_wake() will not be frequent calls. So within 
mpic_irq_set_wake() to decide is reasonable.

> though that could probably wait until there's a second type of MPIC
> that needs this (if ever).
Even if the mpic_irq_set_wake() register in the first type of MPIC that is not
belong MPIC_FSL, the function can return errno. I think the errno should be
"-ENXIO".
See kernel/irq/manage.c, set_irq_wake_real() the return value.
The desc->irq_data.chip->irq_set_wake is null, the errno is -ENXIO.

s/-EINVAL/-ENXIO/

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 4/4] powerpc/fsl: add MPIC timer wakeup support

[Wang Dongsheng]

The driver provides a way to wake up the system by the MPIC timer.

For example,
echo 5 > /sys/devices/system/mpic/timer_wakeup
echo standby > /sys/power/state

After 5 seconds the MPIC timer will generate an interrupt to wake up
the system.

Signed-off-by: Wang Dongsheng 
Signed-off-by: Zhao Chenhui 
Signed-off-by: Li Yang 
---
v2:
* Remove: Create mpic subsystem.

 arch/powerpc/platforms/Kconfig  |   9 ++
 arch/powerpc/sysdev/Makefile|   1 +
 arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c | 161 
 3 files changed, 171 insertions(+)
 create mode 100644 arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c

diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index c447b3c..3d934ba 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -99,6 +99,15 @@ config MPIC_TIMER
  chip, but it can potentially support other global timers
  complying with the OpenPIC standard.
 
+config FSL_MPIC_TIMER_WAKEUP
+   tristate "Freescale MPIC global timer wakeup driver"
+   depends on FSL_SOC &&  MPIC_TIMER && PM
+   default n
+   help
+ The driver provides a way to wake up the system by MPIC
+ timer.
+ e.g. "echo 5 > /sys/devices/system/mpic/timer_wakeup"
+
 config PPC_EPAPR_HV_PIC
bool
default n
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index ff6184a..e1b8a80 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -5,6 +5,7 @@ ccflags-$(CONFIG_PPC64) := -mno-minimal-toc
 mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
 obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
 obj-$(CONFIG_MPIC_TIMER)+= mpic_timer.o
+obj-$(CONFIG_FSL_MPIC_TIMER_WAKEUP)+= fsl_mpic_timer_wakeup.o
 mpic-msgr-obj-$(CONFIG_MPIC_MSGR)  += mpic_msgr.o
 obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y) $(mpic-msgr-obj-y)
 obj-$(CONFIG_PPC_EPAPR_HV_PIC) += ehv_pic.o
diff --git a/arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c 
b/arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c
new file mode 100644
index 000..1707bf0
--- /dev/null
+++ b/arch/powerpc/sysdev/fsl_mpic_timer_wakeup.c
@@ -0,0 +1,161 @@
+/*
+ * MPIC timer wakeup driver
+ *
+ * Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct fsl_mpic_timer_wakeup {
+   struct mpic_timer *timer;
+   struct work_struct free_work;
+};
+
+static struct fsl_mpic_timer_wakeup *fsl_wakeup;
+static DEFINE_MUTEX(sysfs_lock);
+
+static void fsl_free_resource(struct work_struct *ws)
+{
+   struct fsl_mpic_timer_wakeup *wakeup =
+   container_of(ws, struct fsl_mpic_timer_wakeup, free_work);
+
+   mutex_lock(&sysfs_lock);
+
+   if (wakeup->timer) {
+   disable_irq_wake(wakeup->timer->irq);
+   mpic_free_timer(wakeup->timer);
+   }
+
+   wakeup->timer = NULL;
+   mutex_unlock(&sysfs_lock);
+}
+
+static irqreturn_t fsl_mpic_timer_irq(int irq, void *dev_id)
+{
+   struct fsl_mpic_timer_wakeup *wakeup = dev_id;
+
+   schedule_work(&wakeup->free_work);
+
+   return wakeup->timer ? IRQ_HANDLED : IRQ_NONE;
+}
+
+static ssize_t fsl_timer_wakeup_show(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct timeval interval;
+   int val = 0;
+
+   mutex_lock(&sysfs_lock);
+   if (fsl_wakeup->timer) {
+   mpic_get_remain_time(fsl_wakeup->timer, &interval);
+   val = interval.tv_sec + 1;
+   }
+   mutex_unlock(&sysfs_lock);
+
+   return sprintf(buf, "%d\n", val);
+}
+
+static ssize_t fsl_timer_wakeup_store(struct device *dev,
+   struct device_attribute *attr,
+   const char *buf,
+   size_t count)
+{
+   struct timeval interval;
+   int ret;
+
+   interval.tv_usec = 0;
+   if (kstrtol(buf, 0, &interval.tv_sec))
+   return -EINVAL;
+
+   mutex_lock(&sysfs_lock);
+
+   if (fsl_wakeup->timer) {
+   disable_irq_wake(fsl_wakeup->timer->irq);
+   mpic_free_timer(fsl_wakeup->timer);
+   fsl_wakeup->timer = NULL;
+   }
+
+   if (!interval.tv_sec) {
+   mutex_unlock(&sysfs_lock);
+   return count;
+   }
+
+   fsl_wakeup->timer = mpic_request_timer(fsl_mpic_timer_irq