Re: [PATCH 1/3] soc: fsl: add Platform PM driver QorIQ platforms
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(_pm.lock, flags);
>>> + list_add_tail(>node, _pm.node);
>>> + spin_unlock_irqrestore(_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(_pm.lock, flags);
>>> + list_for_each_entry_safe(p,
Re: [PATCH 3/3] soc: fsl: add RCPM driver
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], _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],
> _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 =
Re: [PATCH 1/3] soc: fsl: add Platform PM driver QorIQ platforms
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(_pm.lock, flags);
> + list_add_tail(>node, _pm.node);
> + spin_unlock_irqrestore(_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(_pm.lock, flags);
> + list_for_each_entry_safe(p, tmp, _pm.node, node) {
> + if (p->handle_priv == handle_priv) {
> + list_del(>node);
> + kfree(p);
> + }
> + }
> + spin_unlock_irqrestore(_pm.lock, flags);
> + return
RE: [PATCH v3 1/2] fsl: Add binding for RCPM
> > +++ 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 v2] video: fbdev: fsl: Fix the sleep function for FSL DIU module
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<jason@freescale.com> > > Signed-off-by: Wang Dongsheng<dongsheng.w...@freescale.com> > > Acked-by: Timur Tabi <ti...@tabi.org> 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
> > +* 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 "" 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
Hi Shawn,
Thanks for your review.
> > From: Wang Dongsheng <dongsheng.w...@freescale.com>
> >
> > 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 <chenhui.z...@freescale.com>
> > Signed-off-by: Tang Yuantian <yuantian.t...@freescale.com>
> > Signed-off-by: Wang Dongsheng <dongsheng.w...@freescale.com>
> > ---
> > *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 v3 1/2] fsl: Add binding for RCPM
> 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 "" 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 "" 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 04/17] powerpc: mpic: use IRQCHIP_SKIP_SET_WAKE instead of redundant mpic_irq_set_wake
> -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 04/17] powerpc: mpic: use IRQCHIP_SKIP_SET_WAKE instead of redundant mpic_irq_set_wake
> -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 v2 1/2] fsl: Add binding for RCPM
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 v2 1/2] fsl: Add binding for RCPM
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
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 <dongsheng.w...@freescale.com> > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang > > > > robh+Huan- > > > > B18965 <alison.w...@freescale.com>; Jin Zhengxiong-R64188 > > > > <jason@freescale.com>; Zhao Chenhui-B35336 > > > > <chenhui.z...@freescale.com>; Tang Yuantian-B29983 > > > > <yuantian.t...@freescale.com> > > > > 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 > > > > >
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 <dongsheng.w...@freescale.com> > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang Huan- > > > B18965 <alison.w...@freescale.com>; Jin Zhengxiong-R64188 > > > <jason@freescale.com>; Zhao Chenhui-B35336 > > > <chenhui.z...@freescale.com>; Tang Yuantian-B29983 > > > <yuantian.t...@freescale.com> > > > 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
> -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 <dongsheng.w...@freescale.com> > > > > > > Cc: devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; > > > > > > robh...@kernel.org; linux-arm-ker...@lists.infradead.org; Wang > > > > > > robh+Huan- > > > > > > B18965 <alison.w...@freescale.com>; Jin Zhengxiong-R64188 > > > > > > <jason@freescale.com>; Zhao Chenhui-B35336 > > > > > > <chenhui.z...@freescale.com>; Tang Yuantian-B29983 > > > > > > <yuantian.t...@freescale.com> > > > > > > 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 >
RE: [PATCH 1/2] fsl: Add binding for RCPM
> -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 <dongsheng.w...@freescale.com>
> > > >
> > > > 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 <chenhui.z...@freescale.com>
> > > > Signed-off-by: Tang Yuantian <yuantian.t...@freescale.com>
> > > > Signed-off-by: Wang Dongsheng <dongsheng.w...@freescale.com>
> > > >
> > > > 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-utilitie
RE: [PATCH 1/2] fsl: Add binding for RCPM
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 <dongsheng.w...@freescale.com>
> >
> > 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 <chenhui.z...@freescale.com>
> > Signed-off-by: Tang Yuantian <yuantian.t...@freescale.com>
> > Signed-off-by: Wang Dongsheng <dongsheng.w...@freescale.com>
> >
> > 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
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 Jinjason@freescale.com Signed-off-by: Wang Dongshengdongsheng.w...@freescale.com Acked-by: Timur Tabi ti...@tabi.org ___ 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
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 dongsheng.w...@freescale.com
SCFG provides SoC specific configuration and status registers for
the chip. Add this for powerpc platform.
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
*V2*
- Remove scfg description in board.txt and create scfg.txt for scfg.
- Change fsl,board-scfg to fsl,chip-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,chip-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
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 jason@freescale.com
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 jason@freescale.com
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
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
-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 dongsheng.w...@freescale.com 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 dongsheng.w...@freescale.com --- 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
-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 dongsheng.w...@freescale.com 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 dongsheng.w...@freescale.com --- 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: [RESEND] powerpc/diu: adjust DIU initialization entry
-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 dongsheng.w...@freescale.com 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 dongsheng.w...@freescale.com --- 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: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-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 dongsheng.w...@freescale.com
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
dongsheng.w...@freescale.com
---
*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
RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-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 = -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.
What does the default have to do with it? The user could have set a
different value, and then read it back.
Plus, how much time corresponds to bit 50 depends on the actual timebase
frequency which could vary.
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 = tb_cycle * (1000 / tb_ticks_per_usec) - 1;
} else {
time = pw20_wt;
}
As we have discussed before we need a variable to save To save the users to set
wait-entry-time value.
See the code, if user have set a value, and the value will be set in pw20_wt.
When the user read it back, the code will do time = pw20_wt branch.
When the user not set the wait-entry-time value and read this sys interface,
the code will do the following branch.
smp_call_function_single(cpu, do_show_pwrmgtcr0, value, 1);
value = (value PWRMGTCR0_PW20_ENT
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 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 dongsheng.w...@freescale.com
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 dongsheng.w...@freescale.com
---
*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
RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-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
-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 dongsheng.w...@freescale.com
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
dongsheng.w...@freescale.com
---
*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
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 dongsheng.w...@freescale.com
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 dongsheng.w...@freescale.com
---
*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 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 dongsheng.w...@freescale.com
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 dongsheng.w...@freescale.com
---
*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
RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-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
-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
-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 dongsheng.w...@freescale.com
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
dongsheng.w...@freescale.com
---
*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
RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-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 dongsheng.w...@freescale.com
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 dongsheng.w...@freescale.com
---
*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.
We do believe it is non-zero but greater than 1000 :)
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.
Not sure what you are describing here related to divide by zero we are
mentioning.
You are talking about if tb_ticks_per_usec is ZERO and we are talking
about if (1000/tb_ticks_per_usec) will be zero.
BTW, div_u64() handle the case where divider is zero.
cycle = div_u64(ns, 1000 / tb_ticks_per_usec);
For this, I think we were discussing the two issues:
1. Scott talking about, when the tb_ticks_per_usec is a zero.
This situation is about tb_ticks_per_usec, and possible to zero. So I answered
Scott.
If I misunderstand scott, please ignore it. :)
2. You are talking about 1000/tb_ticks_per_usec is a zero.
This situation is about TB freq 1GHZ.
I will fix this issue. Like I said before,
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;
#define TB_FREQ_1GHZ
RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-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 dongsheng.w...@freescale.com
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
dongsheng.w...@freescale.com
---
*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.
We do believe it is non-zero but greater than 1000 :)
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.
Not sure what you are describing here related to divide by zero we
are mentioning.
You are talking about if tb_ticks_per_usec is ZERO and we are
talking about if (1000/tb_ticks_per_usec) will be zero.
BTW, div_u64() handle the case
RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-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 dongsheng.w...@freescale.com
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 dongsheng.w...@freescale.com
---
*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 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 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 dongsheng.w...@freescale.com
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 dongsheng.w...@freescale.com
---
*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 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define
/* * 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 v4 1/4] powerpc/fsl: add E6500 PVR and SPRN_PWRMGTCR0 define
-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 dongsheng.w...@freescale.com E6500 PVR and SPRN_PWRMGTCR0 will be used in subsequent pw20/altivec idle patches. Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com --- *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 v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-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 dongsheng.w...@freescale.com 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
-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 dongsheng.w...@freescale.com 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 2/4] powerpc/85xx: add hardware automatically enter altivec idle state
-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 dongsheng.w...@freescale.com 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 dongsheng.w...@freescale.com --- *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 v3 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
-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 dongsheng.w...@freescale.com
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 dongsheng.w...@freescale.com
---
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.
Thanks.
+static DEVICE_ATTR(pw20_state, 0644, show_pw20_state,
+store_pw20_state); static DEVICE_ATTR(pw20_wait_entry_bit, 0644,
show_pw20_wait_entry_bit,
+ store_pw20_wait_entry_bit);
+
+static DEVICE_ATTR(altivec_idle, 0644, show_altivec_idle,
+store_altivec_idle); static DEVICE_ATTR(altivec_idle_wait_entry_bit,
0644,
+ show_altivec_idle_wait_entry_bit,
+ store_altivec_idle_wait_entry_bit);
I'd make these 0600, given their ability to spam other CPUs with IPIs
even on read.
Thanks.
+static int __init create_pw20_altivec_sysfs(void) {
+ int i;
+ struct device *cpu_dev;
+
+ if (!has_pw20_altivec_idle())
+ return -ENODEV;
+
+ for_each_possible_cpu(i) {
+ cpu_dev = get_cpu_device(i
RE: [PATCH v2 2/3] powerpc/85xx: add hardware automatically enter altivec idle state
-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 dongsheng.w...@freescale.com 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 dongsheng.w...@freescale.com --- *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
-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 1/2] powerpc/85xx: add hardware automatically enter altivec idle state
-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 V5 3/5] POWER/cpuidle: Generic IBM-POWER backend cpuidle driver.
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 linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/moduleparam.h
+#include linux/cpuidle.h
+#include linux/cpu.h
+#include linux/notifier.h
+
+#include asm/paca.h
+#include asm/reg.h
+#include asm/machdep.h
+#include asm/firmware.h
+#include asm/runlatch.h
+#include asm/plpar_wrappers.h
+
+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 deep...@linux.vnet.ibm.com);
+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
-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 dongsheng.w...@freescale.com 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 dongsheng.w...@freescale.com 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: [PATCH 1/2] powerpc/85xx: add hardware automatically enter altivec idle state
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 dongsheng.w...@freescale.com 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 dongsheng.w...@freescale.com 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] powerpc: add the missing required isync for the coherent icache flush
-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 haoke...@gmail.com --- 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: [RFC PATCH V3 3/5] powerpc/cpuidle: Generic powerpc backend cpuidle driver.
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 linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/moduleparam.h
+#include linux/cpuidle.h
+#include linux/cpu.h
+#include linux/notifier.h
+
+#include asm/paca.h
+#include asm/reg.h
+#include asm/machdep.h
+#include asm/firmware.h
+#include asm/runlatch.h
+#include asm/plpar_wrappers.h
+
+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
+
RE: [PATCH 2/2] powerpc/hibernate: add restore mmu context after resume
-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
-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 dongsheng.w...@freescale.com
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 dongsheng.w...@freescale.com
---
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 deep...@linux.vnet.ibm.com 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 dongsheng.w...@freescale.com
+ */
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 linux/cpu.h
+#include linux/cpuidle.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/notifier.h
+
+#include asm/machdep.h
+
+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_idle to do the failed.
+static struct cpuidle_state fsl_pw_idle_states[] = {
+ {
+ .name = pw10,
+ .desc = pw10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .exit_latency = 0,
+ .target_residency = 0,
+ .enter = pw10_enter
Where is pw10_enter defined?
In this patch..
+static int cpu_is_feature(unsigned long feature)
+{
+ return (cur_cpu_spec-cpu_features == feature);
+}
+
+static int __init e500_idle_init(void
RE: [PATCH] cpuidle: fix unremovable issue for module driver
-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 dongsheng.w...@freescale.com
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 dongsheng.w...@freescale.com
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: [PATCH] cpuidle: add freescale e500 family porcessors idle support
-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 dongsheng.w...@freescale.com
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 dongsheng.w...@freescale.com
---
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 deep...@linux.vnet.ibm.com 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 dongsheng.w...@freescale.com
+ */
+
+#include linux/cpu.h
+#include linux/cpuidle.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/notifier.h
+
+#include asm/machdep.h
+
+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();
+ }
+}
Nope, this is not the place to add such function.
Thanks.
But Why not? On powerpc there is already have a cpuidle method. We need to
compatible them.
Um.. arch/powerpc/platforms/xxx ?
+static int pw10_enter(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index)
+{
+ fsl_cpuidle_wait();
+ return index;
+}
+
+static
RE: [PATCH V2 4/6] cpuidle/pseries: Move the pseries_idle backend driver to sysdev.
-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 deep...@linux.vnet.ibm.com
---
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 linux/kernel.h
-#include linux/module.h
-#include linux/init.h
-#include linux/moduleparam.h
-#include linux/cpuidle.h
-#include linux/cpu.h
-#include linux/notifier.h
-
-#include asm/paca.h
-#include asm/reg.h
-#include asm/machdep.h
-#include asm/firmware.h
-#include asm/runlatch.h
-#include asm/plpar_wrappers.h
-
-/* 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();
- 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
RE: [PATCH V2 5/6] cpuidle/powerpc: Backend-powerpc idle driver for powernv and pseries.
-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.
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: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel features
-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 dongsheng.w...@freescale.com
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
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: [RFC 1/2] fsl/pm: combined the idle(PHPW) state
-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(PHPW) state
On 07/10/2013 03:27:55 AM, Dongsheng Wang wrote:
From: Wang Dongsheng dongsheng.w...@freescale.com
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: [PATCH 2/2] cpuidle: export cpuidle_idle_call symbol
-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 dongsheng.w...@freescale.com 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 1/2] cpuidle: fix cpu idle driver as a module can not remove
-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 dongsheng.w...@freescale.com 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 dongsheng.w...@freescale.com 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 v2 1/2] powerpc: add Book E support to 64-bit hibernation
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
-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 dongsheng.w...@freescale.com
---
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 linux/of_fdt.h
#include linux/hugetlb.h
+#include asm/current.h
#include asm/tlbflush.h
#include asm/tlb.h
#include asm/code-patching.h
#include asm/hugetlb.h
+#include asm/mmu_context.h
#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: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel features
-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 dongsheng.w...@freescale.com 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 dongsheng.w...@freescale.com 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 1/2] powerpc: add Book E support to 64-bit hibernation
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 dongsheng.w...@freescale.com --- * 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 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: [RFC 2/2] powerpc/cputable: add wait feature for CPU kernel features
-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
-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 dongsheng.w...@freescale.com --- * 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
RE: [PATCH 2/2] powerpc/hibernate: add restore mmu context after resume
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 dongsheng.w...@freescale.com
---
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 linux/of_fdt.h
#include linux/hugetlb.h
+#include asm/current.h
#include asm/tlbflush.h
#include asm/tlb.h
#include asm/code-patching.h
#include asm/hugetlb.h
+#include asm/mmu_context.h
#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 v3 1/4] powerpc/mpic: add irq_set_wake support
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 v3 1/4] powerpc/mpic: add irq_set_wake support
-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 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
-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
-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
[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 dongsheng.w...@freescale.com --- 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(1
[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 dongsheng.w...@freescale.com
---
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 2/2] powerpc/hibernate: PPC64 fix user threads access to kernel space
-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 dongsheng.w...@freescale.com
---
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
RE: [PATCH v2 2/2] powerpc/hibernate: PPC64 fix user threads access to kernel space
-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 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] powerpc/mpc85xx: fix non-bootcpu cannot up after hibernation resume
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 avoront...@ru.mvista.com Add Anton Vorontsov anton.voront...@linaro.org 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 an...@enomsg.org 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 dongsheng.w...@freescale.com 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 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 dongsheng.w...@freescale.com --- * 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
[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 dongsheng.w...@freescale.com
---
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 linux/of_fdt.h
#include linux/hugetlb.h
+#include asm/current.h
#include asm/tlbflush.h
#include asm/tlb.h
#include asm/code-patching.h
#include asm/hugetlb.h
+#include asm/mmu_context.h
#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 v2 1/2] powerpc: add Book E support to 64-bit hibernation
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 dongsheng.w...@freescale.com --- 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_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
RE: [PATCH v2 2/2] powerpc/hibernate: PPC64 fix user threads access to kernel space
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 dongsheng.w...@freescale.com
---
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] powerpc/mpc85xx: fix non-bootcpu cannot up after hibernation resume
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 avoront...@ru.mvista.com Add Anton Vorontsov anton.voront...@linaro.org 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 an...@enomsg.org 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 dongsheng.w...@freescale.com 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
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 dongsheng.w...@freescale.com 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] powerpc/mpc85xx: fix non-bootcpu cannot up after hibernation resume
I send to a wrong email address Anton Vorontsov avoront...@ru.mvista.com Add Anton Vorontsov anton.voront...@linaro.org 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 dongsheng.w...@freescale.com 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
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 v3 1/4] powerpc/mpic: add irq_set_wake support
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
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
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
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 dongsheng.w...@freescale.com
---
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 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 dongsheng.w...@freescale.com
---
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 2/4] powerpc/mpic: add global timer support
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 dongsheng.w...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
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 dongsheng.w...@freescale.com
+ *Li Yang le...@freescale.com
+ *
+ * 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 linux/interrupt.h
+#include linux/time.h
+
+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 dongsheng.w...@freescale.com
+ *Li Yang le...@freescale.com
RE: [PATCH] powerpc: add Book E support to 64-bit hibernation
-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 v2 1/4] powerpc/mpic: add irq_set_wake support
-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 dongsheng.w...@freescale.com
---
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
[PATCH v2 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 dongsheng.w...@freescale.com
---
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;
+
+ 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 v2 2/4] powerpc/mpic: add global timer support
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 dongsheng.w...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
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 dongsheng.w...@freescale.com
+ *Li Yang le...@freescale.com
+ *
+ * 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 linux/interrupt.h
+#include linux/time.h
+
+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 dongsheng.w...@freescale.com
+ *Li Yang le...@freescale.com
[PATCH v2 3/4] powerpc/mpic: create mpic subsystem object
Register a mpic subsystem at /sys/devices/system/
Signed-off-by: Wang Dongsheng dongsheng.w...@freescale.com
---
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 50d1ee1..f07cfe0 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 v2 4/4] powerpc/fsl: add MPIC timer wakeup support
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 dongsheng.w...@freescale.com
Signed-off-by: Zhao Chenhui chenhui.z...@freescale.com
Signed-off-by: Li Yang le...@freescale.com
---
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 linux/kernel.h
+#include linux/slab.h
+#include linux/errno.h
+#include linux/module.h
+#include linux/interrupt.h
+#include linux/device.h
+
+#include asm/mpic_timer.h
+#include asm/mpic.h
+
+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
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 dongsheng.w...@freescale.com
---
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
