* RE: [PATCH 2/3 v2] iommu/fsl: Enable default DMA window for PCIe devices
From: Bhushan Bharat-R65777 @ 2013-10-16 17:21 UTC (permalink / raw)
To: Sethi Varun-B16395, joro@8bytes.org,
iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Yoder Stuart-B08248,
Wood Scott-B07421, alex.williamson@redhat.com
In-Reply-To: <C5ECD7A89D1DC44195F34B25E172658D0A54275D@039-SN2MPN1-013.039d.mgd.msft.net>
> >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Sethi Varun-B16395
> > > > > Sent: Wednesday, October 16, 2013 4:53 PM
> > > > > To: joro@8bytes.org; iommu@lists.linux-foundation.org; linuxppc-
> > > > > dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; Yoder
> > > > > Stuart-B08248; Wood Scott-B07421; alex.williamson@redhat.com;
> > > > > Bhushan
> > > > > Bharat-R65777
> > > > > Cc: Sethi Varun-B16395
> > > > > Subject: [PATCH 2/3 v2] iommu/fsl: Enable default DMA window for
> > > > > PCIe devices
> > > > >
> > > > > Once the PCIe device assigned to a guest VM (via VFIO) gets
> > > > > detached from the iommu domain (when guest terminates), its PAMU
> > > > > table entry is disabled. So, this would prevent the device from
> > > > > being used once it's
> > > > assigned back to the host.
> > > > >
> > > > > This patch allows for creation of a default DMA window
> > > > > corresponding to the device and subsequently enabling the PAMU
> > > > > table entry. Before we enable the entry, we ensure that the
> > > > > device's bus master capability is disabled (device quiesced).
> > > > >
> > > > > Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> > > > > ---
> > > > > drivers/iommu/fsl_pamu.c | 43
> > ++++++++++++++++++++++++++++---
> > > > -----
> > > > > drivers/iommu/fsl_pamu.h | 1 +
> > > > > drivers/iommu/fsl_pamu_domain.c | 46
> > > > ++++++++++++++++++++++++++++++++++++---
> > > > > 3 files changed, 78 insertions(+), 12 deletions(-)
> > > > >
> > > > > diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
> > > > > index
> > > > > cba0498..fb4a031 100644
> > > > > --- a/drivers/iommu/fsl_pamu.c
> > > > > +++ b/drivers/iommu/fsl_pamu.c
> > > > > @@ -225,6 +225,21 @@ static struct paace *pamu_get_spaace(struct
> > > > > paace *paace,
> > > > > u32 wnum)
> > > > > return spaace;
> > > > > }
> > > > >
> > > > > +/*
> > > > > + * Defaul PPAACE settings for an LIODN.
> > > > > + */
> > > > > +static void setup_default_ppaace(struct paace *ppaace) {
> > > > > + pamu_init_ppaace(ppaace);
> > > > > + /* window size is 2^(WSE+1) bytes */
> > > > > + set_bf(ppaace->addr_bitfields, PPAACE_AF_WSE, 35);
> > > > > + ppaace->wbah =3D 0;
> > > > > + set_bf(ppaace->addr_bitfields, PPAACE_AF_WBAL, 0);
> > > > > + set_bf(ppaace->impl_attr, PAACE_IA_ATM,
> > > > > + PAACE_ATM_NO_XLATE);
> > > > > + set_bf(ppaace->addr_bitfields, PAACE_AF_AP,
> > > > > + PAACE_AP_PERMS_ALL);
> > > > > +}
> > > > > /**
> > > > > * pamu_get_fspi_and_allocate() - Allocates fspi index and
> > > > > reserves
> > > > subwindows
> > > > > * required for primary PAACE in
> > the
> > > > secondary
> > > > > @@ -253,6 +268,24 @@ static unsigned long
> > > > > pamu_get_fspi_and_allocate(u32
> > > > > subwin_cnt)
> > > > > return (spaace_addr - (unsigned long)spaact) / (sizeof(struct
> > > > > paace)); }
> > > > >
> > > > > +/* Reset the PAACE entry to the default state */ void
> > > > > +enable_default_dma_window(int liodn) {
> > > > > + struct paace *ppaace;
> > > > > +
> > > > > + ppaace =3D pamu_get_ppaace(liodn);
> > > > > + if (!ppaace) {
> > > > > + pr_debug("Invalid liodn entry\n");
> > > > > + return;
> > > > > + }
> > > > > +
> > > > > + memset(ppaace, 0, sizeof(struct paace));
> > > > > +
> > > > > + setup_default_ppaace(ppaace);
> > > > > + mb();
> > > > > + pamu_enable_liodn(liodn);
> > > > > +}
> > > > > +
> > > > > /* Release the subwindows reserved for a particular LIODN */
> > > > > void pamu_free_subwins(int liodn) { @@ -752,15 +785,7 @@ static
> > > > > void __init
> > > > > setup_liodns(void)
> > > > > continue;
> > > > > }
> > > > > ppaace =3D pamu_get_ppaace(liodn);
> > > > > - pamu_init_ppaace(ppaace);
> > > > > - /* window size is 2^(WSE+1) bytes */
> > > > > - set_bf(ppaace->addr_bitfields, PPAACE_AF_WSE,
> > 35);
> > > > > - ppaace->wbah =3D 0;
> > > > > - set_bf(ppaace->addr_bitfields, PPAACE_AF_WBAL,
> > 0);
> > > > > - set_bf(ppaace->impl_attr, PAACE_IA_ATM,
> > > > > - PAACE_ATM_NO_XLATE);
> > > > > - set_bf(ppaace->addr_bitfields, PAACE_AF_AP,
> > > > > - PAACE_AP_PERMS_ALL);
> > > > > + setup_default_ppaace(ppaace);
> > > > > if (of_device_is_compatible(node, "fsl,qman-
> > portal"))
> > > > > setup_qbman_paace(ppaace,
> > QMAN_PORTAL_PAACE);
> > > > > if (of_device_is_compatible(node, "fsl,qman"))
> > diff --
> > > > git
> > > > > a/drivers/iommu/fsl_pamu.h b/drivers/iommu/fsl_pamu.h index
> > > > > 8fc1a12..0edcbbbb
> > > > > 100644
> > > > > --- a/drivers/iommu/fsl_pamu.h
> > > > > +++ b/drivers/iommu/fsl_pamu.h
> > > > > @@ -406,5 +406,6 @@ void get_ome_index(u32 *omi_index, struct
> > > > > device *dev); int pamu_update_paace_stash(int liodn, u32
> > > > > subwin,
> > > > > u32 value); int pamu_disable_spaace(int liodn, u32 subwin);
> > > > > u32 pamu_get_max_subwin_cnt(void);
> > > > > +void enable_default_dma_window(int liodn);
> > > > >
> > > > > #endif /* __FSL_PAMU_H */
> > > > > diff --git a/drivers/iommu/fsl_pamu_domain.c
> > > > > b/drivers/iommu/fsl_pamu_domain.c index 966ae70..dd6cafc 100644
> > > > > --- a/drivers/iommu/fsl_pamu_domain.c
> > > > > +++ b/drivers/iommu/fsl_pamu_domain.c
> > > > > @@ -340,17 +340,57 @@ static inline struct device_domain_info
> > > > > *find_domain(struct device *dev)
> > > > > return dev->archdata.iommu_domain; }
> > > > >
> > > > > +/* Disable device DMA capability and enable default DMA window
> > > > > +*/ static void disable_device_dma(struct device_domain_info *inf=
o,
> > > > > + int enable_dma_window)
> > > > > +{
> > > > > +#ifdef CONFIG_PCI
> > > > > + if (info->dev->bus =3D=3D &pci_bus_type) {
> > > > > + struct pci_dev *pdev =3D NULL;
> > > > > + pdev =3D to_pci_dev(info->dev);
> > > > > + if (pci_is_enabled(pdev))
> > > > > + pci_disable_device(pdev);
> > > > > + }
> > > > > +#endif
> > > > > +
> > > > > + if (enable_dma_window)
> > > > > + enable_default_dma_window(info->liodn);
> > > > > +}
> > > > > +
> > > > > +static int check_for_shared_liodn(struct device_domain_info
> > > > > +*info)
> > {
> > > > > + struct device_domain_info *tmp;
> > > > > +
> > > > > + /*
> > > > > + * Sanity check, to ensure that this is not a
> > > > > + * shared LIODN. In case of a PCIe controller
> > > > > + * it's possible that all PCIe devices share
> > > > > + * the same LIODN.
> > > > > + */
> > > > > + list_for_each_entry(tmp, &info->domain->devices, link) {
> > > > > + if (info->liodn =3D=3D tmp->liodn)
> > > > > + return 1;
> > > > > + }
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > static void remove_device_ref(struct device_domain_info *info,
> > > > > u32
> > > > win_cnt) {
> > > > > unsigned long flags;
> > > > > + int enable_dma_window =3D 0;
> > > > >
> > > > > list_del(&info->link);
> > > > > spin_lock_irqsave(&iommu_lock, flags);
> > > > > - if (win_cnt > 1)
> > > > > - pamu_free_subwins(info->liodn);
> > > > > - pamu_disable_liodn(info->liodn);
> > > > > + if (!check_for_shared_liodn(info)) {
> > > >
> > > > One query; Do we really need to check for this?
> > > >
> > > [Sethi Varun-B16395] Yes, just a sanity check to ensure that there
> > > are no more devices linked to this LIODN and we can disable it.
> >
> > Varun, trying to understand this; say there are two device under a PCI
> > controller which share the LIODN of PCI controller, So both of the
> > device must be unbound from kernel driver and then bind both to VFIO.
> >
> > Now when guest terminated then remove_device_ref() will be called for
> > both of device but the sanity check will pass for the one which will
> > be called later, is this right?
> >
> Yes, when the first device is detached PAMU LIODN table entry is not disa=
bled.
> The LIODN would only be disabled once all devices are detached.
Ok, thanks for clarification
Patch series looks good to me.
>=20
> -Varun
^ permalink raw reply
* RE: [PATCH 2/3 v2] iommu/fsl: Enable default DMA window for PCIe devices
From: Sethi Varun-B16395 @ 2013-10-16 17:22 UTC (permalink / raw)
To: Bhushan Bharat-R65777, joro@8bytes.org,
iommu@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Yoder Stuart-B08248,
Wood Scott-B07421, alex.williamson@redhat.com
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D071C0A84@039-SN2MPN1-013.039d.mgd.msft.net>
> -----Original Message-----
> From: Bhushan Bharat-R65777
> Sent: Wednesday, October 16, 2013 10:52 PM
> To: Sethi Varun-B16395; joro@8bytes.org; iommu@lists.linux-
> foundation.org; linuxppc-dev@lists.ozlabs.org; linux-
> kernel@vger.kernel.org; Yoder Stuart-B08248; Wood Scott-B07421;
> alex.williamson@redhat.com
> Subject: RE: [PATCH 2/3 v2] iommu/fsl: Enable default DMA window for PCIe
> devices
>=20
>=20
> > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Sethi Varun-B16395
> > > > > > Sent: Wednesday, October 16, 2013 4:53 PM
> > > > > > To: joro@8bytes.org; iommu@lists.linux-foundation.org;
> > > > > > linuxppc- dev@lists.ozlabs.org; linux-kernel@vger.kernel.org;
> > > > > > Yoder Stuart-B08248; Wood Scott-B07421;
> > > > > > alex.williamson@redhat.com; Bhushan
> > > > > > Bharat-R65777
> > > > > > Cc: Sethi Varun-B16395
> > > > > > Subject: [PATCH 2/3 v2] iommu/fsl: Enable default DMA window
> > > > > > for PCIe devices
> > > > > >
> > > > > > Once the PCIe device assigned to a guest VM (via VFIO) gets
> > > > > > detached from the iommu domain (when guest terminates), its
> > > > > > PAMU table entry is disabled. So, this would prevent the
> > > > > > device from being used once it's
> > > > > assigned back to the host.
> > > > > >
> > > > > > This patch allows for creation of a default DMA window
> > > > > > corresponding to the device and subsequently enabling the PAMU
> > > > > > table entry. Before we enable the entry, we ensure that the
> > > > > > device's bus master capability is disabled (device quiesced).
> > > > > >
> > > > > > Signed-off-by: Varun Sethi <Varun.Sethi@freescale.com>
> > > > > > ---
> > > > > > drivers/iommu/fsl_pamu.c | 43
> > > ++++++++++++++++++++++++++++---
> > > > > -----
> > > > > > drivers/iommu/fsl_pamu.h | 1 +
> > > > > > drivers/iommu/fsl_pamu_domain.c | 46
> > > > > ++++++++++++++++++++++++++++++++++++---
> > > > > > 3 files changed, 78 insertions(+), 12 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/iommu/fsl_pamu.c
> > > > > > b/drivers/iommu/fsl_pamu.c index
> > > > > > cba0498..fb4a031 100644
> > > > > > --- a/drivers/iommu/fsl_pamu.c
> > > > > > +++ b/drivers/iommu/fsl_pamu.c
> > > > > > @@ -225,6 +225,21 @@ static struct paace
> > > > > > *pamu_get_spaace(struct paace *paace,
> > > > > > u32 wnum)
> > > > > > return spaace;
> > > > > > }
> > > > > >
> > > > > > +/*
> > > > > > + * Defaul PPAACE settings for an LIODN.
> > > > > > + */
> > > > > > +static void setup_default_ppaace(struct paace *ppaace) {
> > > > > > + pamu_init_ppaace(ppaace);
> > > > > > + /* window size is 2^(WSE+1) bytes */
> > > > > > + set_bf(ppaace->addr_bitfields, PPAACE_AF_WSE, 35);
> > > > > > + ppaace->wbah =3D 0;
> > > > > > + set_bf(ppaace->addr_bitfields, PPAACE_AF_WBAL, 0);
> > > > > > + set_bf(ppaace->impl_attr, PAACE_IA_ATM,
> > > > > > + PAACE_ATM_NO_XLATE);
> > > > > > + set_bf(ppaace->addr_bitfields, PAACE_AF_AP,
> > > > > > + PAACE_AP_PERMS_ALL);
> > > > > > +}
> > > > > > /**
> > > > > > * pamu_get_fspi_and_allocate() - Allocates fspi index and
> > > > > > reserves
> > > > > subwindows
> > > > > > * required for primary PAACE
> in
> > > the
> > > > > secondary
> > > > > > @@ -253,6 +268,24 @@ static unsigned long
> > > > > > pamu_get_fspi_and_allocate(u32
> > > > > > subwin_cnt)
> > > > > > return (spaace_addr - (unsigned long)spaact) /
> > > > > > (sizeof(struct paace)); }
> > > > > >
> > > > > > +/* Reset the PAACE entry to the default state */ void
> > > > > > +enable_default_dma_window(int liodn) {
> > > > > > + struct paace *ppaace;
> > > > > > +
> > > > > > + ppaace =3D pamu_get_ppaace(liodn);
> > > > > > + if (!ppaace) {
> > > > > > + pr_debug("Invalid liodn entry\n");
> > > > > > + return;
> > > > > > + }
> > > > > > +
> > > > > > + memset(ppaace, 0, sizeof(struct paace));
> > > > > > +
> > > > > > + setup_default_ppaace(ppaace);
> > > > > > + mb();
> > > > > > + pamu_enable_liodn(liodn);
> > > > > > +}
> > > > > > +
> > > > > > /* Release the subwindows reserved for a particular LIODN */
> > > > > > void pamu_free_subwins(int liodn) { @@ -752,15 +785,7 @@
> > > > > > static void __init
> > > > > > setup_liodns(void)
> > > > > > continue;
> > > > > > }
> > > > > > ppaace =3D pamu_get_ppaace(liodn);
> > > > > > - pamu_init_ppaace(ppaace);
> > > > > > - /* window size is 2^(WSE+1) bytes */
> > > > > > - set_bf(ppaace->addr_bitfields, PPAACE_AF_WSE,
> > > 35);
> > > > > > - ppaace->wbah =3D 0;
> > > > > > - set_bf(ppaace->addr_bitfields, PPAACE_AF_WBAL,
> > > 0);
> > > > > > - set_bf(ppaace->impl_attr, PAACE_IA_ATM,
> > > > > > - PAACE_ATM_NO_XLATE);
> > > > > > - set_bf(ppaace->addr_bitfields, PAACE_AF_AP,
> > > > > > - PAACE_AP_PERMS_ALL);
> > > > > > + setup_default_ppaace(ppaace);
> > > > > > if (of_device_is_compatible(node, "fsl,qman-
> > > portal"))
> > > > > > setup_qbman_paace(ppaace,
> > > QMAN_PORTAL_PAACE);
> > > > > > if (of_device_is_compatible(node, "fsl,qman"))
> > > diff --
> > > > > git
> > > > > > a/drivers/iommu/fsl_pamu.h b/drivers/iommu/fsl_pamu.h index
> > > > > > 8fc1a12..0edcbbbb
> > > > > > 100644
> > > > > > --- a/drivers/iommu/fsl_pamu.h
> > > > > > +++ b/drivers/iommu/fsl_pamu.h
> > > > > > @@ -406,5 +406,6 @@ void get_ome_index(u32 *omi_index, struct
> > > > > > device *dev); int pamu_update_paace_stash(int liodn, u32
> > > > > > subwin,
> > > > > > u32 value); int pamu_disable_spaace(int liodn, u32 subwin);
> > > > > > u32 pamu_get_max_subwin_cnt(void);
> > > > > > +void enable_default_dma_window(int liodn);
> > > > > >
> > > > > > #endif /* __FSL_PAMU_H */
> > > > > > diff --git a/drivers/iommu/fsl_pamu_domain.c
> > > > > > b/drivers/iommu/fsl_pamu_domain.c index 966ae70..dd6cafc
> > > > > > 100644
> > > > > > --- a/drivers/iommu/fsl_pamu_domain.c
> > > > > > +++ b/drivers/iommu/fsl_pamu_domain.c
> > > > > > @@ -340,17 +340,57 @@ static inline struct device_domain_info
> > > > > > *find_domain(struct device *dev)
> > > > > > return dev->archdata.iommu_domain; }
> > > > > >
> > > > > > +/* Disable device DMA capability and enable default DMA
> > > > > > +window */ static void disable_device_dma(struct
> device_domain_info *info,
> > > > > > + int enable_dma_window)
> > > > > > +{
> > > > > > +#ifdef CONFIG_PCI
> > > > > > + if (info->dev->bus =3D=3D &pci_bus_type) {
> > > > > > + struct pci_dev *pdev =3D NULL;
> > > > > > + pdev =3D to_pci_dev(info->dev);
> > > > > > + if (pci_is_enabled(pdev))
> > > > > > + pci_disable_device(pdev);
> > > > > > + }
> > > > > > +#endif
> > > > > > +
> > > > > > + if (enable_dma_window)
> > > > > > + enable_default_dma_window(info->liodn);
> > > > > > +}
> > > > > > +
> > > > > > +static int check_for_shared_liodn(struct device_domain_info
> > > > > > +*info)
> > > {
> > > > > > + struct device_domain_info *tmp;
> > > > > > +
> > > > > > + /*
> > > > > > + * Sanity check, to ensure that this is not a
> > > > > > + * shared LIODN. In case of a PCIe controller
> > > > > > + * it's possible that all PCIe devices share
> > > > > > + * the same LIODN.
> > > > > > + */
> > > > > > + list_for_each_entry(tmp, &info->domain->devices, link) {
> > > > > > + if (info->liodn =3D=3D tmp->liodn)
> > > > > > + return 1;
> > > > > > + }
> > > > > > +
> > > > > > + return 0;
> > > > > > +}
> > > > > > +
> > > > > > static void remove_device_ref(struct device_domain_info
> > > > > > *info,
> > > > > > u32
> > > > > win_cnt) {
> > > > > > unsigned long flags;
> > > > > > + int enable_dma_window =3D 0;
> > > > > >
> > > > > > list_del(&info->link);
> > > > > > spin_lock_irqsave(&iommu_lock, flags);
> > > > > > - if (win_cnt > 1)
> > > > > > - pamu_free_subwins(info->liodn);
> > > > > > - pamu_disable_liodn(info->liodn);
> > > > > > + if (!check_for_shared_liodn(info)) {
> > > > >
> > > > > One query; Do we really need to check for this?
> > > > >
> > > > [Sethi Varun-B16395] Yes, just a sanity check to ensure that there
> > > > are no more devices linked to this LIODN and we can disable it.
> > >
> > > Varun, trying to understand this; say there are two device under a
> > > PCI controller which share the LIODN of PCI controller, So both of
> > > the device must be unbound from kernel driver and then bind both to
> VFIO.
> > >
> > > Now when guest terminated then remove_device_ref() will be called
> > > for both of device but the sanity check will pass for the one which
> > > will be called later, is this right?
> > >
> > Yes, when the first device is detached PAMU LIODN table entry is not
> disabled.
> > The LIODN would only be disabled once all devices are detached.
>=20
> Ok, thanks for clarification
>=20
> Patch series looks good to me.
Thanks.
-Varun
^ permalink raw reply
* Re: [PATCH] powerpc/qe_lib: Share the qe_lib for the others architecture
From: Kumar Gala @ 2013-10-16 18:12 UTC (permalink / raw)
To: Gerhard Sittig
Cc: Scott Wood, Greg Kroah-Hartman,
linuxppc-dev@lists.ozlabs.org list, Linux Kernel list, Xie Xiaobo
In-Reply-To: <20131015131606.GA2700@book.gsilab.sittig.org>
On Oct 15, 2013, at 8:16 AM, Gerhard Sittig wrote:
> On Mon, Oct 14, 2013 at 13:09 -0700, Greg Kroah-Hartman wrote:
>>=20
>> On Mon, Oct 14, 2013 at 02:40:44PM -0500, Kumar Gala wrote:
>>>=20
>>> Greg,
>>>=20
>>> Wondering your thoughts on drivers/qe vs something like
>>> drivers/soc/fsl/qe. The QuiccEngine (qe) is a communication core on
>>> some of the Freescale networking SoCs that provides the ability to =
do
>>> various networking/communication functionality. "Channels" on the =
QE
>>> can be used for various different things from ethernet, ATM, UART, =
or
>>> other functions.
>>=20
>> What makes the code "QE" specific? Are these devices that live on =
the
>> QE "bus", or are they controlling the QE controller?
>=20
> You may think of the QUICC as a "programmable bitbang machine" if
> you like. The very same component runs arbitrary and rather
> different protocols depending on how you setup its parameters.
>=20
> There have been serial controllers capable of different protocols
> like UART or SPI or I2S, but all of them are "serial
> communication". There have been memory controllers which could
> bitbang different protocols (NAND, NOR/SRAM, DRAM), but all of
> them are "memory".
>=20
> The QUICC is just a little more versatile, and appears to cover
> cases which reside in different Linux kernel subsystems (like:
> it's neither serial nor network exclusively, but can be either
> and potentially more).
>=20
> IIUC the question which Kumar Gala was asking is where to put
> code for the component which is neither a strict subset of any
> subsystem. Please correct me if I'm wrong.
Thanks for the description.
Yeah, the actual ethernet, usb, serial drivers that exist with QE live =
today in proper drivers/ dirs. This is the infrastructure that those =
drivers utilize that isn't quite related to an existing subsystem. =
Mostly set up of channel state/cfg/etc.
- k=
^ permalink raw reply
* Re: Perf not resolving all symbols, showing 0x7ffffxxx
From: Benjamin Herrenschmidt @ 2013-10-16 18:42 UTC (permalink / raw)
To: Martin Hicks; +Cc: Scott Wood, linuxppc-dev, Anton Blanchard
In-Reply-To: <CAJUS3Xm6-Mojvu6WkZNT+31oDazcx5HCr3n0asNqv3+uFbO0JQ@mail.gmail.com>
On Wed, 2013-10-16 at 11:05 -0400, Martin Hicks wrote:
> Actually, I was wrong, the mpc8379 is an e300c4.
>
> So it seems clear to me that we compile in the book3s code because
> this is an 83xx CPU part. I also see that Kconfig knows that I have
> an core-fsl-emb but we don't actually compile the PMU backend for it
> because there's no support for anything but e500.
>
> mort@chinook:~/src/s4v2-glibc/linux-mpc$ grep PERF .config
> CONFIG_FSL_EMB_PERFMON=y
> CONFIG_PPC_PERF_CTRS=y
> CONFIG_HAVE_PERF_EVENTS=y
> CONFIG_PERF_EVENTS=y
> # CONFIG_DEBUG_PERF_USE_VMALLOC is not set
> mort@chinook:~/src/s4v2-glibc/linux-mpc$ grep BOOK3S .config
> CONFIG_PPC_BOOK3S_32=y
> CONFIG_PPC_BOOK3S=y
>
> more below...
>
> On Tue, Oct 15, 2013 at 4:39 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Tue, 2013-10-15 at 15:22 -0500, Scott Wood wrote:
> >> On Tue, 2013-10-15 at 14:53 -0500, Benjamin Herrenschmidt wrote:
> >> > On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote:
> >> > > >
> >> > > > This is an e300 core right ? (603...). Do that have an SIAR at all
> >> > > > (Scott ?)
> >> > >
> >> > > Yes, e300c3.
> >> >
> >> > Ok so I have a hard time figuring out how that patch can make a
> >> > difference since for all I can see, there is no perf backend upstream
> >> > for e300 at all :-(
> >> >
> >> > I must certainly be missing something ... Scott, can you have a look ?
> >>
> >> e300c3 has a core-fsl-emb style performance monitor (though Linux
> >> doesn't support it yet). If a bug was bisected to a change in
> >> core-book3s.c, then it's probably a coincidence due to moving code
> >> around.
>
> CONFIG_PPC_PERF_CTRS seems to give the mpc8379 some kind of basic
> performance measuring. Is this through dummy_perf() in
> arch/powerpc/kernel/pmc.c?
>
> >
> > Mort, can you see if just that change is enough to cause the problem ?
>
> It is not. The patch that does get IPs working again in my 3.11 tree
> is this one:
>
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index eeae308..9a3f572 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -122,10 +122,6 @@ void power_pmu_flush_branch_stack(void) {}
> static inline void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw) {}
> #endif /* CONFIG_PPC32 */
>
> -static bool regs_use_siar(struct pt_regs *regs)
> -{
> - return !!regs->result;
> -}
Can you try instead just chaning regs_use_siar to return false always ?
Do that help ?
Cheers,
Ben.
> /*
> * Things that are specific to 64-bit implementations.
> @@ -1802,14 +1798,13 @@ unsigned long perf_misc_flags(struct pt_regs *regs)
> */
> unsigned long perf_instruction_pointer(struct pt_regs *regs)
> {
> - bool use_siar = regs_use_siar(regs);
> -
> - if (use_siar && siar_valid(regs))
> - return mfspr(SPRN_SIAR) + perf_ip_adjust(regs);
> - else if (use_siar)
> - return 0; // no valid instruction pointer
> - else
> + unsigned long mmcra = regs->dsisr;
> + if (TRAP(regs) != 0xf00)
> + return regs->nip;
> + if ((ppmu->flags & PPMU_NO_CONT_SAMPLING) &&
> + !(mmcra & MMCRA_SAMPLE_ENABLE))
> return regs->nip;
> + return mfspr(SPRN_SIAR) + perf_ip_adjust(regs);
> }
>
> static bool pmc_overflow_power7(unsigned long val)
>
>
> mh
>
^ permalink raw reply
* Re: [PATCH] powerpc 8xx: Fixing memory init issue with CONFIG_PIN_TLB
From: Scott Wood @ 2013-10-16 19:40 UTC (permalink / raw)
To: leroy christophe; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <525E27ED.4000005@c-s.fr>
On Wed, 2013-10-16 at 07:45 +0200, leroy christophe wrote:
> Le 15/10/2013 22:33, Scott Wood a =C3=A9crit :
> > On Tue, 2013-10-15 at 18:27 +0200, leroy christophe wrote:
> >> Le 11/10/2013 17:13, Joakim Tjernlund a =C3=A9crit :
> >>> "Linuxppc-dev"
> >>> <linuxppc-dev-bounces+joakim.tjernlund=3Dtransmode.se@lists.ozlabs.=
org>
> >>> wrote on 2013/10/11 14:56:40:
> >>>> Activating CONFIG_PIN_TLB allows access to the 24 first Mbytes of =
memory
> >>> at
> >>>> bootup instead of 8. It is needed for "big" kernels for instance w=
hen
> >>> activating
> >>>> CONFIG_LOCKDEP_SUPPORT. This needs to be taken into account in ini=
t_32
> >>> too,
> >>>> otherwise memory allocation soon fails after startup.
> >>>>
> >>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> >>>>
> >>>> diff -ur linux-3.11.org/arch/powerpc/kernel/head_8xx.S
> >>> linux-3.11/arch/powerpc/kernel/head_8xx.S
> >>>> --- linux-3.11.org/arch/powerpc/mm/init_32.c 2013-09-02
> >>> 22:46:10.000000000 +0200
> >>>> +++ linux-3.11/arch/powerpc/mm/init_32.c 2013-09-09 11:28:54.000=
000000
> >>> +0200
> >>>> @@ -213,7 +213,12 @@
> >>>> */
> >>>> BUG_ON(first_memblock_base !=3D 0);
> >>>>
> >>>> +#ifdef CONFIG_PIN_TLB
> >>>> + /* 8xx can only access 24MB at the moment */
> >>>> + memblock_set_current_limit(min_t(u64, first_memblock_size,
> >>> 0x01800000));
> >>>> +#else
> >>>> /* 8xx can only access 8MB at the moment */
> >>>> memblock_set_current_limit(min_t(u64, first_memblock_size,
> >>> 0x00800000));
> >>>> +#endif
> >>>> }
> >>>> #endif /* CONFIG_8xx */
> >>> hmm, I think you should always map 24 MB (or less if RAM < 24 MB) a=
nd do
> >>> the same
> >>> in head_8xx.S.
> >>>
> >>> Or to keep it simple, just always map at least 16 MB here and in
> >>> head_8xx.S, assuming
> >>> that 16 MB is min RAM for any 8xx system running 3.x kernels.
> >> Yes we could do a more elaborated modification in the future. Howeve=
r it
> >> also has an impact on the boot loader, so I'm not sure we should mak=
e it
> >> the default without thinking twice.
> >>
> >> In the meantime, my patch does take into account the existing situat=
ion
> >> where you have 8Mb by default and 24Mb when you activate CONFIG_PIN_=
TLB.
> >> I see it as a bug fix and I believe we should include it at least in
> >> order to allow including in the stable releases.
> >>
> >> Do you see any issue with this approach ?
> > The patch is fine, but I don't think it's stable material (BTW, if it
> > were, you should have marked it as such when submitting). If I
> > understand the situation correctly, there's no regression, and nothin=
g
> > fails to work with CONFIG_PIN_TLB that would have worked without it.
> > It's just making CONFIG_PIN_TLB more useful.
> >
> >
> Yes the patch is definitly stable.
It's not about whether the patch itself is "stable", but whether it is a
critical bugfix that should be applied to the 3.11.x stable tree and the
3.12 release, rather than being queued for 3.13.
> How should I have mark it ?
https://www.kernel.org/doc/Documentation/stable_kernel_rules.txt
> The situation is that in 2010, I discovered that I was not able to star=
t=20
> a big Kernel because of the 8Mb limit.
> You told me (see attached mail) that in order to get rid of that limit =
I=20
> shall use CONFIG_PIN_TLB: it was the first step, it helped pass the=20
> memory zeroize at init, but it was not enough as I then got problems=20
> with the Device Tree being erased because being put inside the first 8M=
b=20
> area too. Then I temporarely gave up at that time.
>=20
> Recently I started again. After fixing my bootloader to get the device=20
> tree somewhere else, I discovered this 8Mb limit hardcoded in=20
> mm/init_32.c for the 8xx
> With the patch I submitted I can now boot a kernel which is bigger than=
8Mb.
>=20
> So, I'm a bit lost here on what to do.
There's nothing you need to do -- I'll apply the patch and send it to
Ben for 3.13.
-Scott
^ permalink raw reply
* Re: Perf not resolving all symbols, showing 0x7ffffxxx
From: Martin Hicks @ 2013-10-16 21:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev, Anton Blanchard
In-Reply-To: <1381948928.17841.38.camel@pasglop>
On Wed, Oct 16, 2013 at 2:42 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2013-10-16 at 11:05 -0400, Martin Hicks wrote:
>> Actually, I was wrong, the mpc8379 is an e300c4.
>>
>> So it seems clear to me that we compile in the book3s code because
>> this is an 83xx CPU part. I also see that Kconfig knows that I have
>> an core-fsl-emb but we don't actually compile the PMU backend for it
>> because there's no support for anything but e500.
>>
>> mort@chinook:~/src/s4v2-glibc/linux-mpc$ grep PERF .config
>> CONFIG_FSL_EMB_PERFMON=y
>> CONFIG_PPC_PERF_CTRS=y
>> CONFIG_HAVE_PERF_EVENTS=y
>> CONFIG_PERF_EVENTS=y
>> # CONFIG_DEBUG_PERF_USE_VMALLOC is not set
>> mort@chinook:~/src/s4v2-glibc/linux-mpc$ grep BOOK3S .config
>> CONFIG_PPC_BOOK3S_32=y
>> CONFIG_PPC_BOOK3S=y
>>
>> more below...
>>
>> On Tue, Oct 15, 2013 at 4:39 PM, Benjamin Herrenschmidt
>> <benh@kernel.crashing.org> wrote:
>> > On Tue, 2013-10-15 at 15:22 -0500, Scott Wood wrote:
>> >> On Tue, 2013-10-15 at 14:53 -0500, Benjamin Herrenschmidt wrote:
>> >> > On Tue, 2013-10-15 at 14:44 -0400, Martin Hicks wrote:
>> >> > > >
>> >> > > > This is an e300 core right ? (603...). Do that have an SIAR at all
>> >> > > > (Scott ?)
>> >> > >
>> >> > > Yes, e300c3.
>> >> >
>> >> > Ok so I have a hard time figuring out how that patch can make a
>> >> > difference since for all I can see, there is no perf backend upstream
>> >> > for e300 at all :-(
>> >> >
>> >> > I must certainly be missing something ... Scott, can you have a look ?
>> >>
>> >> e300c3 has a core-fsl-emb style performance monitor (though Linux
>> >> doesn't support it yet). If a bug was bisected to a change in
>> >> core-book3s.c, then it's probably a coincidence due to moving code
>> >> around.
>>
>> CONFIG_PPC_PERF_CTRS seems to give the mpc8379 some kind of basic
>> performance measuring. Is this through dummy_perf() in
>> arch/powerpc/kernel/pmc.c?
>>
>> >
>> > Mort, can you see if just that change is enough to cause the problem ?
>>
>> It is not. The patch that does get IPs working again in my 3.11 tree
>> is this one:
>>
>> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
>> index eeae308..9a3f572 100644
>> --- a/arch/powerpc/perf/core-book3s.c
>> +++ b/arch/powerpc/perf/core-book3s.c
>> @@ -122,10 +122,6 @@ void power_pmu_flush_branch_stack(void) {}
>> static inline void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw) {}
>> #endif /* CONFIG_PPC32 */
>>
>> -static bool regs_use_siar(struct pt_regs *regs)
>> -{
>> - return !!regs->result;
>> -}
>
> Can you try instead just chaning regs_use_siar to return false always ?
> Do that help ?
>
That does fix the problem. v3.11 with the following:
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index eeae308..e91cf67 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -124,7 +124,7 @@ static inline void power_pmu_bhrb_read(struct
cpu_hw_events *cpuhw) {}
static bool regs_use_siar(struct pt_regs *regs)
{
- return !!regs->result;
+ return 0; //!!regs->result;
}
/*
mh
--
Martin Hicks P.Eng. | mort@bork.org
Bork Consulting Inc. | +1 (613) 266-2296
^ permalink raw reply related
* Re: [PATCH v2 RESEND 0/3] cpufreq/ondemand support for Xserve G5 & iMac G5 iSight
From: Rafael J. Wysocki @ 2013-10-16 23:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Viresh Kumar, linux-pm, linuxppc-dev, Aaro Koskinen
In-Reply-To: <1381465935.5630.53.camel@pasglop>
On Friday, October 11, 2013 03:32:15 PM Benjamin Herrenschmidt wrote:
> On Mon, 2013-09-30 at 23:44 +0300, Aaro Koskinen wrote:
> > Hi,
> >
> > This is a resend of the v2 patchset:
> >
> > http://marc.info/?t=137797013200001&r=1&w=2
> >
> > No changes except rebasing. Any chance to get these into v3.13?
>
> BTW. Ack from me, Rafael feel free to merge these.
Queued up for 3.13, sorry for the delay.
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: Perf not resolving all symbols, showing 0x7ffffxxx
From: Benjamin Herrenschmidt @ 2013-10-16 23:01 UTC (permalink / raw)
To: Martin Hicks; +Cc: Scott Wood, linuxppc-dev, Anton Blanchard
In-Reply-To: <CAJUS3Xk6jVHWvWugLGD0LNWgw0+XZeP6z+=U4Xa6_GTGNvObBQ@mail.gmail.com>
On Wed, 2013-10-16 at 17:16 -0400, Martin Hicks wrote:
> That does fix the problem. v3.11 with the following:
>
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index eeae308..e91cf67 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -124,7 +124,7 @@ static inline void power_pmu_bhrb_read(struct
> cpu_hw_events *cpuhw) {}
>
> static bool regs_use_siar(struct pt_regs *regs)
> {
> - return !!regs->result;
> + return 0; //!!regs->result;
> }
Ok, we probably need that function to do that on machines with no
backend :-) Either that or properly clear regs->result always.
I've had a quick look through perf and I admit I'm not sure of all the
ways perf ends up populating "regs" here and how many holes there is
in that scheme :-)
Anton? How do you know for sure regs is always be cooked by your stuff
(for regs->result) ?
Ben.
^ permalink raw reply
* Re: [4/4] powerpc/mpc8548: Add workaround for erratum NMG_SRIO135
From: Scott Wood @ 2013-10-16 23:20 UTC (permalink / raw)
To: chenhui zhao; +Cc: linuxppc-dev
In-Reply-To: <1331025056-15983-4-git-send-email-chenhui.zhao@freescale.com>
On Tue, Mar 06, 2012 at 05:10:56PM +0800, chenhui zhao wrote:
> From: chenhui zhao <chenhui.zhao@freescale.com>
>
> Issue:
> Applications using lwarx/stwcx instructions in the core to
> compete for a software lock or semaphore with a device on
> RapidIO using read atomic set, clr, inc, or dec in a similar
> manner may falsely result in both masters seeing the lock
> as "available". This could result in data corruption as
> both masters try to modify the same piece of data protected
> by the lock.
>
> Workaround:
> Set bits 13 and 29 of CCSR offset 0x01010 (EEBPCR register
> of the ECM) during initialization and leave them set
> indefinitely. This may slightly degrade overall system
> performance.
>
> Refer to SRIO39 in MPC8548 errata document.
>
> Signed-off-by: Gong Chen <g.chen@freescale.com>
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
>
> ---
> arch/powerpc/sysdev/fsl_rio.c | 44 +++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 44 insertions(+), 0 deletions(-)
[snip]
> @@ -358,6 +391,17 @@ int fsl_rio_setup(struct platform_device *dev)
> dev->dev.of_node->full_name);
> return -EFAULT;
> }
> +
> + /* Fix erratum NMG_SRIO135 */
> + if (fsl_svr_is(SVR_8548) || fsl_svr_is(SVR_8548_E)) {
> + rc = fixup_erratum_srio135(&dev->dev);
> + if (rc) {
> + dev_err(&dev->dev,
> + "Failed to fix the erratum NMG_SRIO135.");
> + return rc;
> + }
> + }
This needs to be respun based on the current tree.
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] tty/hvc_console: Add DTR/RTS callback to handle HUPCL control
From: Benjamin Herrenschmidt @ 2013-10-16 23:21 UTC (permalink / raw)
To: Hendrik Brueckner
Cc: linux-s390, gregkh, heiko.carstens, linuxppc-dev, linux-kernel,
brueckner, schwidefsky, jslaby
In-Reply-To: <20131016090432.GA6053@linux.vnet.ibm.com>
On Wed, 2013-10-16 at 11:04 +0200, Hendrik Brueckner wrote:
> Indeed, two callbacks change the DTR line. The main difference is that
> tiocmget/tiocmset can be called from user space by ioctl. That's not the case
> for the dtr_cts callback. Also, tiocmget/tiocmset provide more flags that can
> be changed (ST, SR, CTS, CD, RNG, RI, ...)
>
> Assume we would like to unify them have a single callback to change DTR, then
> we have to take care of these differences. So the question to you now is
> whether you plan for a) other modem flags to be changed and b) if changing the
> DTR line (or other control flags) through an ioctl?
>
> Depending on your results, I could work on sth that helps us both and reduces
> the callbacks.
Can we not just have the users of dtr_cts just call the backend's tiocmset ?
If they need to filter or clamp bits, we could handle all that in hvc_console
by caching the user intended value and passing a cooked value down to the backend..
None of that is urgent or anything, it's just odd and would be nice to cleanup.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_ssi: Fix irq_of_parse_and_map() return value check
From: Guenter Roeck @ 2013-10-17 1:57 UTC (permalink / raw)
To: Mark Brown
Cc: alsa-devel, Timur Tabi, Takashi Iwai, linux-kernel, Liam Girdwood,
Jaroslav Kysela, Geert Uytterhoeven, Grant Likely, linuxppc-dev
In-Reply-To: <20131003155816.GU27287@sirena.org.uk>
On 10/03/2013 08:58 AM, Mark Brown wrote:
> On Wed, Oct 02, 2013 at 09:15:22PM -0700, Guenter Roeck wrote:
>> irq_of_parse_and_map() returns 0 on error, not NO_IRQ.
>
> Applied, thanks.
>
Hi Mark,
do you plan to send this patch upstream anytime soon ?
It fixes an xtensa build problem, so it would be great if it could find its way into 3.13.
Thanks,
Guenter
^ permalink raw reply
* RE: [PATCH v5] powerpc/mpc85xx: Update the clock nodes in device tree
From: Tang Yuantian-B29983 @ 2013-10-17 2:08 UTC (permalink / raw)
To: Wood Scott-B07421
Cc: Mark Rutland, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, Li Yang-Leo-R58472
In-Reply-To: <1381942009.7979.727.camel@snotra.buserror.net>
PiA+ID4gVGhhdCBzaG93cyB0aGUgZGl2aWRlcnMgYXMgYmVpbmcgc29tZXdoZXJlIGluIGJldHdl
ZW4gdGhlIFBMTCBhbmQgdGhlDQo+IE1VWC4NCj4gPiA+IFRoZSBNVVggaXMgd2hlcmUgdGhlIGRp
dmlkZXIgaXMgc2VsZWN0ZWQuICBUaGVyZSdzIG5vdGhpbmcgaW4gdGhlDQo+ID4gPiBQTEwncyBw
cm9ncmFtbWluZyBpbnRlcmZhY2UgdGhhdCByZWxhdGVzIHRvIHRoZSBkaXZpZGVycy4gIEFzIHN1
Y2gNCj4gPiA+IGl0J3Mgc2ltcGxlciB0byBtb2RlbCBpdCBhcyBiZWluZyBwYXJ0IG9mIHRoZSBN
VVguDQo+ID4gPg0KPiA+ID4gLVNjb3R0DQo+ID4gPg0KPiA+IEkgZG9uJ3Qga25vdyB3aGV0aGVy
IGl0IGlzIHNpbXBsZXIsIGJ1dCAibW9kZWxpbmcgZGl2aWRlciBhcyBiZWluZyBwYXJ0DQo+IG9m
IHRoZSBNVVgiDQo+ID4gaXMgeW91ciBndWVzcywgcmlnaHQ/DQo+ID4gSWYgdGhlICJkaXZpZGVy
IiBpcyBpbmNsdWRlZCBpbiBNVVgsIHRoZSBNVVggd291bGQgbm90IGJlIGNhbGxlZCAiTVVYIi4N
Cj4gDQo+IEl0J3Mgc3RpbGwgc2VsZWN0aW5nIGZyb20gbXVsdGlwbGUgUExMcy4NCj4gDQo+ID4g
SSBkb24ndCBrbm93IHdoZXRoZXIgImRpdmlkZXIiIG1vZHVsZSBleGlzdHMgb3Igbm90LiBJZiBp
dCBleGlzdHMsIGl0DQo+ID4gc2hvdWxkIGJlIHBhcnQgb2YgUExMIG9yIGJldHdlZW4gUExMIGFu
ZCBNVVguIHdoZXJldmVyIGl0IHdhcywgdGhlDQo+IGRldmljZSB0cmVlIGJpbmRpbmcgaXMgYXBw
cm9wcmlhdGUuDQo+IA0KPiBUaGUgZGV2aWNlIHRyZWUgYmluZGluZyBpcyB1bm5lY2Vzc2FyaWx5
IGNvbXBsaWNhdGVkLg0KPiANCj4gPiBUaGUgUDMwNDFSTSBzaG93cyBleGFjdGx5IGVhY2ggUExM
IGhhcyAyIG91dHB1dHMgd2hpY2ggZGVmaW5pdGVseSBoYXZlDQo+IG5vICJkaXZpZGVyIiBhdCBh
bGwuDQo+IA0KPiBUaGF0IGRpYWdyYW0gaXMgYSBiaXQgd2VpcmQgLS0gb25lIG9mIHRoZSBvdXRw
dXRzIGlzIHVzZWQgYXMgaXMsIGFuZCB0aGUNCj4gb3RoZXIgaXMgc3BsaXQgaW50byAxLzIgYW5k
IDEvNC4gIEl0IGRvZXNuJ3QgcmVhbGx5IG1hdHRlciB0aG91Z2g7IHRoZQ0KPiBlbmQgcmVzdWx0
IGlzIHRoZSBzYW1lLiAgV2UncmUgZGVzY3JpYmluZyB0aGUgcHJvZ3JhbW1pbmcgaW50ZXJmYWNl
LCBub3QNCj4gYXJ0d29yayBjaG9pY2VzIGluIHRoZSBtYW51YWwuDQo+IA0KPiAtU2NvdHQNCj4g
DQpJZiB0aGUgZGV2aWNlIHRyZWUgbmVlZHMgdG8gYmUgbW9kaWZpZWQsIGNvdWxkIHlvdSBnaXZl
IG1lIHlvdXIgc3VnZ2VzdGlvbnM/DQoNClJlZ2FyZHMsDQpZdWFudGlhbg0K
^ permalink raw reply
* RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Wang Dongsheng-B40534 @ 2013-10-17 2:46 UTC (permalink / raw)
To: Bhushan Bharat-R65777, Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D071C08E4@039-SN2MPN1-013.039d.mgd.msft.net>
> -----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
>=20
>=20
>=20
> > -----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.wang@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.wang@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=3D",
> setup_smt_snooze_delay);
> >
> > #endif /* CONFIG_PPC64 */
> >
> > +#ifdef CONFIG_FSL_SOC
> > +#define MAX_BIT 63
> > +
> > +static u64 pw20_wt;
> > +static u64 altivec_idle_wt;
> > +
> > +static unsigned int get_idle_ticks_bit(u64 ns) {
> > + u64 cycle;
> > +
> > + if (ns >=3D 10000)
> > + cycle =3D div_u64(ns + 500, 1000) * tb_ticks_per_usec;
> > + else
> > + cycle =3D div_u64(ns * tb_ticks_per_usec, 1000);
> > +
> > + if (!cycle)
> > + return 0;
> > +
> > + return ilog2(cycle);
> > +}
> > +
> > +static void do_show_pwrmgtcr0(void *val) {
> > + u32 *value =3D val;
> > +
> > + *value =3D mfspr(SPRN_PWRMGTCR0);
> > +}
> > +
> > +static ssize_t show_pw20_state(struct device *dev,
> > + struct device_attribute *attr, char *buf) {
> > + u32 value;
> > + unsigned int cpu =3D dev->id;
> > +
> > + smp_call_function_single(cpu, do_show_pwrmgtcr0, &value, 1);
> > +
> > + value &=3D PWRMGTCR0_PW20_WAIT;
> > +
> > + return sprintf(buf, "%u\n", value ? 1 : 0); }
> > +
> > +static void do_store_pw20_state(void *val) {
> > + u32 *value =3D val;
> > + u32 pw20_state;
> > +
> > + pw20_state =3D mfspr(SPRN_PWRMGTCR0);
> > +
> > + if (*value)
> > + pw20_state |=3D PWRMGTCR0_PW20_WAIT;
> > + else
> > + pw20_state &=3D ~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 =3D 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 =3D dev->id;
> > +
> > + if (!pw20_wt) {
> > + smp_call_function_single(cpu, do_show_pwrmgtcr0, &value, 1);
> > + value =3D (value & PWRMGTCR0_PW20_ENT) >>
> > + PWRMGTCR0_PW20_ENT_SHIFT;
> > +
> > + tb_cycle =3D (1 << (MAX_BIT - value)) * 2;
>=20
> Is value =3D 0 and value =3D 1 legal? These will make tb_cycle =3D 0,
>=20
> > + time =3D div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
>=20
> And time =3D -1;
>=20
Please look at the end of the function, :)
"return sprintf(buf, "%llu\n", time > 0 ? time : 0);"
-dongsheng
>=20
> > + } else {
> > + time =3D pw20_wt;
> > + }
> > +
> > + return sprintf(buf, "%llu\n", time > 0 ? time : 0);
> > }
> > +
^ permalink raw reply
* RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Bhushan Bharat-R65777 @ 2013-10-17 3:19 UTC (permalink / raw)
To: Wang Dongsheng-B40534, Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <ABB05CD9C9F68C46A5CEDC7F15439259010B1799@039-SN2MPN1-021.039d.mgd.msft.net>
> -----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 al=
tivec
> idle
>=20
>=20
>=20
> > -----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.wang@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.wang@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=3D",
> > setup_smt_snooze_delay);
> > >
> > > #endif /* CONFIG_PPC64 */
> > >
> > > +#ifdef CONFIG_FSL_SOC
> > > +#define MAX_BIT 63
> > > +
> > > +static u64 pw20_wt;
> > > +static u64 altivec_idle_wt;
> > > +
> > > +static unsigned int get_idle_ticks_bit(u64 ns) {
> > > + u64 cycle;
> > > +
> > > + if (ns >=3D 10000)
> > > + cycle =3D div_u64(ns + 500, 1000) * tb_ticks_per_usec;
> > > + else
> > > + cycle =3D div_u64(ns * tb_ticks_per_usec, 1000);
> > > +
> > > + if (!cycle)
> > > + return 0;
> > > +
> > > + return ilog2(cycle);
> > > +}
> > > +
> > > +static void do_show_pwrmgtcr0(void *val) {
> > > + u32 *value =3D val;
> > > +
> > > + *value =3D mfspr(SPRN_PWRMGTCR0);
> > > +}
> > > +
> > > +static ssize_t show_pw20_state(struct device *dev,
> > > + struct device_attribute *attr, char *buf) {
> > > + u32 value;
> > > + unsigned int cpu =3D dev->id;
> > > +
> > > + smp_call_function_single(cpu, do_show_pwrmgtcr0, &value, 1);
> > > +
> > > + value &=3D PWRMGTCR0_PW20_WAIT;
> > > +
> > > + return sprintf(buf, "%u\n", value ? 1 : 0); }
> > > +
> > > +static void do_store_pw20_state(void *val) {
> > > + u32 *value =3D val;
> > > + u32 pw20_state;
> > > +
> > > + pw20_state =3D mfspr(SPRN_PWRMGTCR0);
> > > +
> > > + if (*value)
> > > + pw20_state |=3D PWRMGTCR0_PW20_WAIT;
> > > + else
> > > + pw20_state &=3D ~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 =3D 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 =3D dev->id;
> > > +
> > > + if (!pw20_wt) {
> > > + smp_call_function_single(cpu, do_show_pwrmgtcr0, &value, 1);
> > > + value =3D (value & PWRMGTCR0_PW20_ENT) >>
> > > + PWRMGTCR0_PW20_ENT_SHIFT;
> > > +
> > > + tb_cycle =3D (1 << (MAX_BIT - value)) * 2;
> >
> > Is value =3D 0 and value =3D 1 legal? These will make tb_cycle =3D 0,
> >
> > > + time =3D div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
> >
> > And time =3D -1;
> >
> Please look at the end of the function, :)
>=20
> "return sprintf(buf, "%llu\n", time > 0 ? time : 0);"
I know you return 0 if value =3D 0/1, my question was that, is this correct=
as per specification?
Ahh, also for "value" upto 7 you will return 0, no?
-Bharat
>=20
> -dongsheng
>=20
> >
> > > + } else {
> > > + time =3D pw20_wt;
> > > + }
> > > +
> > > + return sprintf(buf, "%llu\n", time > 0 ? time : 0);
> > > }
> > > +
^ permalink raw reply
* Re: [PATCH] powerpc/vio: Fix modalias_show return values
From: Ben Hutchings @ 2013-10-17 3:53 UTC (permalink / raw)
To: Prarit Bhargava, Benjamin Herrenschmidt; +Cc: linuxppc-dev, stable
[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]
Commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 introduces a trivial
local denial of service.
> --- a/arch/powerpc/kernel/vio.c
> +++ b/arch/powerpc/kernel/vio.c
> @@ -1351,11 +1351,15 @@ static ssize_t modalias_show(struct devi
> const char *cp;
>
> dn = dev->of_node;
> - if (!dn)
> - return -ENODEV;
> + if (!dn) {
> + strcat(buf, "\n");
Every read from the same sysfs file handle uses the same buffer, which
gets zero-initialised just once. So if I open the file, read it and
seek back to 0 repeatedly, I can make modalias_show() write arbitrary
numbers of newlines into *and beyond* that page-sized buffer.
Obviously strcat() should be strcpy().
Ben.
> + return strlen(buf);
> + }
> cp = of_get_property(dn, "compatible", NULL);
> - if (!cp)
> - return -ENODEV;
> + if (!cp) {
> + strcat(buf, "\n");
> + return strlen(buf);
> + }
>
> return sprintf(buf, "vio:T%sS%s\n", vio_dev->type, cp);
> }
--
Ben Hutchings
Horngren's Observation:
Among economists, the real world is often a special case.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH -V2 11/14] kvm: powerpc: book3s: Support building HV and PR KVM as module
From: Aneesh Kumar K.V @ 2013-10-17 5:11 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1381164482-31001-12-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
The below patch fix a compile issue with KVM_XICS. Please fold
diff --git a/arch/powerpc/kvm/book3s_xics.c b/arch/powerpc/kvm/book3s_xics.c
index cef3de9..c3c832b 100644
--- a/arch/powerpc/kvm/book3s_xics.c
+++ b/arch/powerpc/kvm/book3s_xics.c
@@ -840,6 +840,7 @@ int kvmppc_xics_hcall(struct kvm_vcpu *vcpu, u32 req)
return rc;
}
+EXPORT_SYMBOL_GPL(kvmppc_xics_hcall);
/* -- Initialisation code etc. -- */
^ permalink raw reply related
* [PATCH] powerpc: Fix 64K page size support for PPC44x
From: Alistair Popple @ 2013-10-17 5:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alistair Popple, aneesh.kumar
PPC44x supports page sizes other than 4K however when 64K page sizes
are selected compilation fails. This is due to a change in the
definition of pgtable_t introduced by the following patch:
commit 5c1f6ee9a31cbdac90bbb8ae1ba4475031ac74b4
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
powerpc: Reduce PTE table memory wastage
The above patch only implements the new layout for PPC64 so it doesn't
compile for PPC32 with a 64K page size. Ideally we should implement
the same layout for PPC32 however for the meantime this patch reverts
the definition of pgtable_t for PPC32.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
---
arch/powerpc/include/asm/page.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index b9f4262..b142d58 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -403,7 +403,7 @@ void arch_free_page(struct page *page, int order);
struct vm_area_struct;
-#ifdef CONFIG_PPC_64K_PAGES
+#if defined(CONFIG_PPC_64K_PAGES) && defined(PPC64)
typedef pte_t *pgtable_t;
#else
typedef struct page *pgtable_t;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] powerpc: Fix 64K page size support for PPC44x
From: Aneesh Kumar K.V @ 2013-10-17 5:25 UTC (permalink / raw)
To: Alistair Popple, linuxppc-dev; +Cc: Alistair Popple
In-Reply-To: <1381986910-16310-1-git-send-email-alistair@popple.id.au>
Alistair Popple <alistair@popple.id.au> writes:
> PPC44x supports page sizes other than 4K however when 64K page sizes
> are selected compilation fails. This is due to a change in the
> definition of pgtable_t introduced by the following patch:
>
> commit 5c1f6ee9a31cbdac90bbb8ae1ba4475031ac74b4
> Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> powerpc: Reduce PTE table memory wastage
>
> The above patch only implements the new layout for PPC64 so it doesn't
> compile for PPC32 with a 64K page size. Ideally we should implement
> the same layout for PPC32 however for the meantime this patch reverts
> the definition of pgtable_t for PPC32.
>
> Signed-off-by: Alistair Popple <alistair@popple.id.au>
> ---
> arch/powerpc/include/asm/page.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index b9f4262..b142d58 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -403,7 +403,7 @@ void arch_free_page(struct page *page, int order);
>
> struct vm_area_struct;
>
> -#ifdef CONFIG_PPC_64K_PAGES
> +#if defined(CONFIG_PPC_64K_PAGES) && defined(PPC64)
^^^ CONFIG_PPC64 ?
> typedef pte_t *pgtable_t;
> #else
> typedef struct page *pgtable_t;
> --
> 1.7.10.4
^ permalink raw reply
* Re: [PATCH] powerpc: Fix 64K page size support for PPC44x
From: Alistair Popple @ 2013-10-17 5:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Aneesh Kumar K.V
In-Reply-To: <87mwm8qxiy.fsf@linux.vnet.ibm.com>
On Thu, 17 Oct 2013 10:55:25 Aneesh Kumar K.V wrote:
> Alistair Popple <alistair@popple.id.au> writes:
> > diff --git a/arch/powerpc/include/asm/page.h
> > b/arch/powerpc/include/asm/page.h index b9f4262..b142d58 100644
> > --- a/arch/powerpc/include/asm/page.h
> > +++ b/arch/powerpc/include/asm/page.h
> > @@ -403,7 +403,7 @@ void arch_free_page(struct page *page, int order);
> >
> > struct vm_area_struct;
> >
> > -#ifdef CONFIG_PPC_64K_PAGES
> > +#if defined(CONFIG_PPC_64K_PAGES) && defined(PPC64)
>
> ^^^ CONFIG_PPC64 ?
Yes, of course it should be. Thanks for picking that up - I'll send an updated
patch.
> > typedef pte_t *pgtable_t;
> > #else
> > typedef struct page *pgtable_t;
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] powerpc/vio: Fix modalias_show return values
From: Benjamin Herrenschmidt @ 2013-10-17 5:49 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Prarit Bhargava, linuxppc-dev, stable
In-Reply-To: <1381982024.3267.14.camel@deadeye.wl.decadent.org.uk>
On Thu, 2013-10-17 at 04:53 +0100, Ben Hutchings wrote:
> Commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 introduces a trivial
> local denial of service.
Oops. Prarit, please send a fix asap ! I'm travelling right now.
Thanks !
Ben.
> > --- a/arch/powerpc/kernel/vio.c
> > +++ b/arch/powerpc/kernel/vio.c
> > @@ -1351,11 +1351,15 @@ static ssize_t modalias_show(struct devi
> > const char *cp;
> >
> > dn = dev->of_node;
> > - if (!dn)
> > - return -ENODEV;
> > + if (!dn) {
> > + strcat(buf, "\n");
>
> Every read from the same sysfs file handle uses the same buffer, which
> gets zero-initialised just once. So if I open the file, read it and
> seek back to 0 repeatedly, I can make modalias_show() write arbitrary
> numbers of newlines into *and beyond* that page-sized buffer.
>
> Obviously strcat() should be strcpy().
>
> Ben.
>
> > + return strlen(buf);
> > + }
> > cp = of_get_property(dn, "compatible", NULL);
> > - if (!cp)
> > - return -ENODEV;
> > + if (!cp) {
> > + strcat(buf, "\n");
> > + return strlen(buf);
> > + }
> >
> > return sprintf(buf, "vio:T%sS%s\n", vio_dev->type, cp);
> > }
>
^ permalink raw reply
* RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Wang Dongsheng-B40534 @ 2013-10-17 5:51 UTC (permalink / raw)
To: Bhushan Bharat-R65777, Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D071C3279@039-SN2MPN1-013.039d.mgd.msft.net>
> -----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
>=20
>=20
>=20
> > -----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.wang@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.wang@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=3D",
> > > setup_smt_snooze_delay);
> > > >
> > > > #endif /* CONFIG_PPC64 */
> > > >
> > > > +#ifdef CONFIG_FSL_SOC
> > > > +#define MAX_BIT 63
> > > > +
> > > > +static u64 pw20_wt;
> > > > +static u64 altivec_idle_wt;
> > > > +
> > > > +static unsigned int get_idle_ticks_bit(u64 ns) {
> > > > + u64 cycle;
> > > > +
> > > > + if (ns >=3D 10000)
> > > > + cycle =3D div_u64(ns + 500, 1000) * tb_ticks_per_usec;
> > > > + else
> > > > + cycle =3D div_u64(ns * tb_ticks_per_usec, 1000);
> > > > +
> > > > + if (!cycle)
> > > > + return 0;
> > > > +
> > > > + return ilog2(cycle);
> > > > +}
> > > > +
> > > > +static void do_show_pwrmgtcr0(void *val) {
> > > > + u32 *value =3D val;
> > > > +
> > > > + *value =3D mfspr(SPRN_PWRMGTCR0);
> > > > +}
> > > > +
> > > > +static ssize_t show_pw20_state(struct device *dev,
> > > > + struct device_attribute *attr, char *buf) {
> > > > + u32 value;
> > > > + unsigned int cpu =3D dev->id;
> > > > +
> > > > + smp_call_function_single(cpu, do_show_pwrmgtcr0, &value, 1);
> > > > +
> > > > + value &=3D PWRMGTCR0_PW20_WAIT;
> > > > +
> > > > + return sprintf(buf, "%u\n", value ? 1 : 0); }
> > > > +
> > > > +static void do_store_pw20_state(void *val) {
> > > > + u32 *value =3D val;
> > > > + u32 pw20_state;
> > > > +
> > > > + pw20_state =3D mfspr(SPRN_PWRMGTCR0);
> > > > +
> > > > + if (*value)
> > > > + pw20_state |=3D PWRMGTCR0_PW20_WAIT;
> > > > + else
> > > > + pw20_state &=3D ~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 =3D 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 =3D dev->id;
> > > > +
> > > > + if (!pw20_wt) {
> > > > + smp_call_function_single(cpu, do_show_pwrmgtcr0, &value,
> 1);
> > > > + value =3D (value & PWRMGTCR0_PW20_ENT) >>
> > > > + PWRMGTCR0_PW20_ENT_SHIFT;
> > > > +
> > > > + tb_cycle =3D (1 << (MAX_BIT - value)) * 2;
> > >
> > > Is value =3D 0 and value =3D 1 legal? These will make tb_cycle =3D 0,
> > >
> > > > + time =3D div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
> > >
> > > And time =3D -1;
> > >
> > Please look at the end of the function, :)
> >
> > "return sprintf(buf, "%llu\n", time > 0 ? time : 0);"
>=20
> I know you return 0 if value =3D 0/1, my question was that, is this corre=
ct
> as per specification?
>=20
> Ahh, also for "value" upto 7 you will return 0, no?
>=20
If value =3D 0, MAX_BIT - value =3D 63
tb_cycle =3D 0xffffffff_ffffffff, tb_cycle * 1000 will overflow, but this s=
ituation is not possible.
Because if the "value =3D 0" means this feature will be "disable".
Now The default wait bit is 50(MAX_BIT - value, value =3D 13), the PW20/Alt=
ivec Idle wait entry time is about 1ms, this time is very long for wait idl=
e time, and it's cannot be increased(means (MAX_BIT - value) cannot greater=
than 50).
=09
If (MAX_BIT-value) =3D 0, tb_cycle =3D 2,
div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1 =3D ((2 * 1000) / 41) - 1 =
=3D 48 - 1 =3D 47
the return value is 47
> -Bharat
>=20
> >
> > -dongsheng
> >
> > >
> > > > + } else {
> > > > + time =3D pw20_wt;
> > > > + }
> > > > +
> > > > + return sprintf(buf, "%llu\n", time > 0 ? time : 0);
> > > > }
> > > > +
^ permalink raw reply
* Re: [PATCH v11 3/3] DMA: Freescale: update driver to support 8-channel DMA engine
From: Hongbo Zhang @ 2013-10-17 5:56 UTC (permalink / raw)
To: hongbo.zhang, vinod.koul
Cc: mark.rutland, devicetree, ian.campbell, pawel.moll, swarren,
linux-kernel, rob.herring, djbw, linuxppc-dev
In-Reply-To: <1380188023-3936-4-git-send-email-hongbo.zhang@freescale.com>
Hi Vinod,
I have gotten ACK from Mark for both the 1/3 and 2/3 patches.
Thanks.
On 09/26/2013 05:33 PM, hongbo.zhang@freescale.com wrote:
> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>
> This patch adds support to 8-channel DMA engine, thus the driver works for both
> the new 8-channel and the legacy 4-channel DMA engines.
>
> Signed-off-by: Hongbo Zhang <hongbo.zhang@freescale.com>
> ---
> drivers/dma/Kconfig | 9 +++++----
> drivers/dma/fsldma.c | 9 ++++++---
> drivers/dma/fsldma.h | 2 +-
> 3 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 6825957..3979c65 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -89,14 +89,15 @@ config AT_HDMAC
> Support the Atmel AHB DMA controller.
>
> config FSL_DMA
> - tristate "Freescale Elo and Elo Plus DMA support"
> + tristate "Freescale Elo series DMA support"
> depends on FSL_SOC
> select DMA_ENGINE
> select ASYNC_TX_ENABLE_CHANNEL_SWITCH
> ---help---
> - Enable support for the Freescale Elo and Elo Plus DMA controllers.
> - The Elo is the DMA controller on some 82xx and 83xx parts, and the
> - Elo Plus is the DMA controller on 85xx and 86xx parts.
> + Enable support for the Freescale Elo series DMA controllers.
> + The Elo is the DMA controller on some mpc82xx and mpc83xx parts, the
> + EloPlus is on mpc85xx and mpc86xx and Pxxx parts, and the Elo3 is on
> + some Txxx and Bxxx parts.
>
> config MPC512X_DMA
> tristate "Freescale MPC512x built-in DMA engine support"
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index 49e8fbd..16a9a48 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -1261,7 +1261,9 @@ static int fsl_dma_chan_probe(struct fsldma_device *fdev,
> WARN_ON(fdev->feature != chan->feature);
>
> chan->dev = fdev->dev;
> - chan->id = ((res.start - 0x100) & 0xfff) >> 7;
> + chan->id = (res.start & 0xfff) < 0x300 ?
> + ((res.start - 0x100) & 0xfff) >> 7 :
> + ((res.start - 0x200) & 0xfff) >> 7;
> if (chan->id >= FSL_DMA_MAX_CHANS_PER_DEVICE) {
> dev_err(fdev->dev, "too many channels for device\n");
> err = -EINVAL;
> @@ -1434,6 +1436,7 @@ static int fsldma_of_remove(struct platform_device *op)
> }
>
> static const struct of_device_id fsldma_of_ids[] = {
> + { .compatible = "fsl,elo3-dma", },
> { .compatible = "fsl,eloplus-dma", },
> { .compatible = "fsl,elo-dma", },
> {}
> @@ -1455,7 +1458,7 @@ static struct platform_driver fsldma_of_driver = {
>
> static __init int fsldma_init(void)
> {
> - pr_info("Freescale Elo / Elo Plus DMA driver\n");
> + pr_info("Freescale Elo series DMA driver\n");
> return platform_driver_register(&fsldma_of_driver);
> }
>
> @@ -1467,5 +1470,5 @@ static void __exit fsldma_exit(void)
> subsys_initcall(fsldma_init);
> module_exit(fsldma_exit);
>
> -MODULE_DESCRIPTION("Freescale Elo / Elo Plus DMA driver");
> +MODULE_DESCRIPTION("Freescale Elo series DMA driver");
> MODULE_LICENSE("GPL");
> diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
> index f5c3879..1ffc244 100644
> --- a/drivers/dma/fsldma.h
> +++ b/drivers/dma/fsldma.h
> @@ -112,7 +112,7 @@ struct fsldma_chan_regs {
> };
>
> struct fsldma_chan;
> -#define FSL_DMA_MAX_CHANS_PER_DEVICE 4
> +#define FSL_DMA_MAX_CHANS_PER_DEVICE 8
>
> struct fsldma_device {
> void __iomem *regs; /* DGSR register base */
^ permalink raw reply
* RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Bhushan Bharat-R65777 @ 2013-10-17 6:00 UTC (permalink / raw)
To: Wang Dongsheng-B40534, Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <ABB05CD9C9F68C46A5CEDC7F15439259010B189E@039-SN2MPN1-021.039d.mgd.msft.net>
> -----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 al=
tivec
> idle
>=20
>=20
>=20
> > -----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.wang@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.wang@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=3D",
> > > > setup_smt_snooze_delay);
> > > > >
> > > > > #endif /* CONFIG_PPC64 */
> > > > >
> > > > > +#ifdef CONFIG_FSL_SOC
> > > > > +#define MAX_BIT 63
> > > > > +
> > > > > +static u64 pw20_wt;
> > > > > +static u64 altivec_idle_wt;
> > > > > +
> > > > > +static unsigned int get_idle_ticks_bit(u64 ns) {
> > > > > + u64 cycle;
> > > > > +
> > > > > + if (ns >=3D 10000)
> > > > > + cycle =3D div_u64(ns + 500, 1000) * tb_ticks_per_usec;
> > > > > + else
> > > > > + cycle =3D div_u64(ns * tb_ticks_per_usec, 1000);
> > > > > +
> > > > > + if (!cycle)
> > > > > + return 0;
> > > > > +
> > > > > + return ilog2(cycle);
> > > > > +}
> > > > > +
> > > > > +static void do_show_pwrmgtcr0(void *val) {
> > > > > + u32 *value =3D val;
> > > > > +
> > > > > + *value =3D mfspr(SPRN_PWRMGTCR0); }
> > > > > +
> > > > > +static ssize_t show_pw20_state(struct device *dev,
> > > > > + struct device_attribute *attr, char *buf) {
> > > > > + u32 value;
> > > > > + unsigned int cpu =3D dev->id;
> > > > > +
> > > > > + smp_call_function_single(cpu, do_show_pwrmgtcr0, &value, 1);
> > > > > +
> > > > > + value &=3D PWRMGTCR0_PW20_WAIT;
> > > > > +
> > > > > + return sprintf(buf, "%u\n", value ? 1 : 0); }
> > > > > +
> > > > > +static void do_store_pw20_state(void *val) {
> > > > > + u32 *value =3D val;
> > > > > + u32 pw20_state;
> > > > > +
> > > > > + pw20_state =3D mfspr(SPRN_PWRMGTCR0);
> > > > > +
> > > > > + if (*value)
> > > > > + pw20_state |=3D PWRMGTCR0_PW20_WAIT;
> > > > > + else
> > > > > + pw20_state &=3D ~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 =3D 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 =3D dev->id;
> > > > > +
> > > > > + if (!pw20_wt) {
> > > > > + smp_call_function_single(cpu, do_show_pwrmgtcr0, &value,
> > 1);
> > > > > + value =3D (value & PWRMGTCR0_PW20_ENT) >>
> > > > > + PWRMGTCR0_PW20_ENT_SHIFT;
> > > > > +
> > > > > + tb_cycle =3D (1 << (MAX_BIT - value)) * 2;
> > > >
> > > > Is value =3D 0 and value =3D 1 legal? These will make tb_cycle =3D =
0,
> > > >
> > > > > + time =3D div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
> > > >
> > > > And time =3D -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 =3D 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 =3D 0, MAX_BIT - value =3D 63
> tb_cycle =3D 0xffffffff_ffffffff, tb_cycle * 1000 will overflow, but this
> situation is not possible.
> Because if the "value =3D 0" means this feature will be "disable".
> Now The default wait bit is 50(MAX_BIT - value, value =3D 13), the PW20/A=
ltivec
> Idle wait entry time is about 1ms, this time is very long for wait idle t=
ime,
> and it's cannot be increased(means (MAX_BIT - value) cannot greater than =
50).
What you said is not obvious from code and so at least write a comment that=
value will be always >=3D 13 or value will never be less than < 8 and belo=
w calculation will not overflow. may be error out if value is less than 8.
-Bharat
>=20
> If (MAX_BIT-value) =3D 0, tb_cycle =3D 2,
> div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1 =3D ((2 * 1000) / 41) - 1=
=3D 48 - 1
> =3D 47
>=20
> the return value is 47
>=20
> > -Bharat
> >
> > >
> > > -dongsheng
> > >
> > > >
> > > > > + } else {
> > > > > + time =3D pw20_wt;
> > > > > + }
> > > > > +
> > > > > + return sprintf(buf, "%llu\n", time > 0 ? time : 0);
> > > > > }
> > > > > +
^ permalink raw reply
* [PATCH V2] powerpc: Fix 64K page size support for PPC44x
From: Alistair Popple @ 2013-10-17 6:08 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alistair Popple, aneesh.kumar
PPC44x supports page sizes other than 4K however when 64K page sizes
are selected compilation fails. This is due to a change in the
definition of pgtable_t introduced by the following patch:
commit 5c1f6ee9a31cbdac90bbb8ae1ba4475031ac74b4
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
powerpc: Reduce PTE table memory wastage
The above patch only implements the new layout for PPC64 so it doesn't
compile for PPC32 with a 64K page size. Ideally we should implement
the same layout for PPC32 however for the meantime this patch reverts
the definition of pgtable_t for PPC32.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
---
arch/powerpc/include/asm/page.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index b9f4262..7dde512 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -403,7 +403,7 @@ void arch_free_page(struct page *page, int order);
struct vm_area_struct;
-#ifdef CONFIG_PPC_64K_PAGES
+#if defined(CONFIG_PPC_64K_PAGES) && defined(CONFIG_PPC64)
typedef pte_t *pgtable_t;
#else
typedef struct page *pgtable_t;
--
1.7.10.4
^ permalink raw reply related
* RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Wang Dongsheng-B40534 @ 2013-10-17 6:34 UTC (permalink / raw)
To: Bhushan Bharat-R65777, Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D071C34C1@039-SN2MPN1-013.039d.mgd.msft.net>
> -----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
>=20
>=20
>=20
> > -----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.wang@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.wang@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=3D",
> > > > > setup_smt_snooze_delay);
> > > > > >
> > > > > > #endif /* CONFIG_PPC64 */
> > > > > >
> > > > > > +#ifdef CONFIG_FSL_SOC
> > > > > > +#define MAX_BIT 63
> > > > > > +
> > > > > > +static u64 pw20_wt;
> > > > > > +static u64 altivec_idle_wt;
> > > > > > +
> > > > > > +static unsigned int get_idle_ticks_bit(u64 ns) {
> > > > > > + u64 cycle;
> > > > > > +
> > > > > > + if (ns >=3D 10000)
> > > > > > + cycle =3D div_u64(ns + 500, 1000) * tb_ticks_per_usec;
> > > > > > + else
> > > > > > + cycle =3D div_u64(ns * tb_ticks_per_usec, 1000);
> > > > > > +
> > > > > > + if (!cycle)
> > > > > > + return 0;
> > > > > > +
> > > > > > + return ilog2(cycle);
> > > > > > +}
> > > > > > +
> > > > > > +static void do_show_pwrmgtcr0(void *val) {
> > > > > > + u32 *value =3D val;
> > > > > > +
> > > > > > + *value =3D mfspr(SPRN_PWRMGTCR0); }
> > > > > > +
> > > > > > +static ssize_t show_pw20_state(struct device *dev,
> > > > > > + struct device_attribute *attr, char *buf) {
> > > > > > + u32 value;
> > > > > > + unsigned int cpu =3D dev->id;
> > > > > > +
> > > > > > + smp_call_function_single(cpu, do_show_pwrmgtcr0, &value, 1);
> > > > > > +
> > > > > > + value &=3D PWRMGTCR0_PW20_WAIT;
> > > > > > +
> > > > > > + return sprintf(buf, "%u\n", value ? 1 : 0); }
> > > > > > +
> > > > > > +static void do_store_pw20_state(void *val) {
> > > > > > + u32 *value =3D val;
> > > > > > + u32 pw20_state;
> > > > > > +
> > > > > > + pw20_state =3D mfspr(SPRN_PWRMGTCR0);
> > > > > > +
> > > > > > + if (*value)
> > > > > > + pw20_state |=3D PWRMGTCR0_PW20_WAIT;
> > > > > > + else
> > > > > > + pw20_state &=3D ~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 =3D 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 =3D dev->id;
> > > > > > +
> > > > > > + if (!pw20_wt) {
> > > > > > + smp_call_function_single(cpu, do_show_pwrmgtcr0, &value,
> > > 1);
> > > > > > + value =3D (value & PWRMGTCR0_PW20_ENT) >>
> > > > > > + PWRMGTCR0_PW20_ENT_SHIFT;
> > > > > > +
> > > > > > + tb_cycle =3D (1 << (MAX_BIT - value)) * 2;
> > > > >
> > > > > Is value =3D 0 and value =3D 1 legal? These will make tb_cycle =
=3D 0,
> > > > >
> > > > > > + time =3D div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
> > > > >
> > > > > And time =3D -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 =3D 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 =3D 0, MAX_BIT - value =3D 63
> > tb_cycle =3D 0xffffffff_ffffffff, tb_cycle * 1000 will overflow, but
> > this situation is not possible.
> > Because if the "value =3D 0" means this feature will be "disable".
> > Now The default wait bit is 50(MAX_BIT - value, value =3D 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).
>=20
> What you said is not obvious from code and so at least write a comment
> that value will be always >=3D 13 or value will never be less than < 8 an=
d
> below calculation will not overflow. may be error out if value is less
> than 8.
>=20
The "value" less than 10, this will overflow.
There is not error, The code I knew it could not be less than 10, that's wh=
y I use the following code. :)
tb_cycle =3D (1 << (MAX_BIT - value)) * 2;=20
time =3D div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1;
-dongsheng
> -Bharat
>=20
> >
> > If (MAX_BIT-value) =3D 0, tb_cycle =3D 2,
> > div_u64(tb_cycle * 1000, tb_ticks_per_usec) - 1 =3D ((2 * 1000) / 41) -
> > 1 =3D 48 - 1 =3D 47
> >
> > the return value is 47
> >
> > > -Bharat
> > >
> > > >
> > > > -dongsheng
> > > >
> > > > >
> > > > > > + } else {
> > > > > > + time =3D pw20_wt;
> > > > > > + }
> > > > > > +
> > > > > > + return sprintf(buf, "%llu\n", time > 0 ? time : 0);
> > > > > > }
> > > > > > +
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox