* [PATCH] powerpc/pseries: Fix endian issues in pseries iommu code
From: Anton Blanchard @ 2013-10-17 12:21 UTC (permalink / raw)
To: benh, paulus, tony, aik; +Cc: linuxppc-dev
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index 0307901..f253361 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -52,7 +52,7 @@
static void tce_invalidate_pSeries_sw(struct iommu_table *tbl,
- u64 *startp, u64 *endp)
+ __be64 *startp, __be64 *endp)
{
u64 __iomem *invalidate = (u64 __iomem *)tbl->it_index;
unsigned long start, end, inc;
@@ -86,7 +86,7 @@ static int tce_build_pSeries(struct iommu_table *tbl, long index,
struct dma_attrs *attrs)
{
u64 proto_tce;
- u64 *tcep, *tces;
+ __be64 *tcep, *tces;
u64 rpn;
proto_tce = TCE_PCI_READ; // Read allowed
@@ -94,12 +94,12 @@ static int tce_build_pSeries(struct iommu_table *tbl, long index,
if (direction != DMA_TO_DEVICE)
proto_tce |= TCE_PCI_WRITE;
- tces = tcep = ((u64 *)tbl->it_base) + index;
+ tces = tcep = ((__be64 *)tbl->it_base) + index;
while (npages--) {
/* can't move this out since we might cross MEMBLOCK boundary */
rpn = __pa(uaddr) >> TCE_SHIFT;
- *tcep = proto_tce | (rpn & TCE_RPN_MASK) << TCE_RPN_SHIFT;
+ *tcep = cpu_to_be64(proto_tce | (rpn & TCE_RPN_MASK) << TCE_RPN_SHIFT);
uaddr += TCE_PAGE_SIZE;
tcep++;
@@ -113,9 +113,9 @@ static int tce_build_pSeries(struct iommu_table *tbl, long index,
static void tce_free_pSeries(struct iommu_table *tbl, long index, long npages)
{
- u64 *tcep, *tces;
+ __be64 *tcep, *tces;
- tces = tcep = ((u64 *)tbl->it_base) + index;
+ tces = tcep = ((__be64 *)tbl->it_base) + index;
while (npages--)
*(tcep++) = 0;
@@ -126,11 +126,11 @@ static void tce_free_pSeries(struct iommu_table *tbl, long index, long npages)
static unsigned long tce_get_pseries(struct iommu_table *tbl, long index)
{
- u64 *tcep;
+ __be64 *tcep;
- tcep = ((u64 *)tbl->it_base) + index;
+ tcep = ((__be64 *)tbl->it_base) + index;
- return *tcep;
+ return be64_to_cpu(*tcep);
}
static void tce_free_pSeriesLP(struct iommu_table*, long, long);
@@ -177,7 +177,7 @@ static int tce_build_pSeriesLP(struct iommu_table *tbl, long tcenum,
return ret;
}
-static DEFINE_PER_CPU(u64 *, tce_page);
+static DEFINE_PER_CPU(__be64 *, tce_page);
static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,
long npages, unsigned long uaddr,
@@ -186,7 +186,7 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,
{
u64 rc = 0;
u64 proto_tce;
- u64 *tcep;
+ __be64 *tcep;
u64 rpn;
long l, limit;
long tcenum_start = tcenum, npages_start = npages;
@@ -206,7 +206,7 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,
* from iommu_alloc{,_sg}()
*/
if (!tcep) {
- tcep = (u64 *)__get_free_page(GFP_ATOMIC);
+ tcep = (__be64 *)__get_free_page(GFP_ATOMIC);
/* If allocation fails, fall back to the loop implementation */
if (!tcep) {
local_irq_restore(flags);
@@ -230,7 +230,7 @@ static int tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,
limit = min_t(long, npages, 4096/TCE_ENTRY_SIZE);
for (l = 0; l < limit; l++) {
- tcep[l] = proto_tce | (rpn & TCE_RPN_MASK) << TCE_RPN_SHIFT;
+ tcep[l] = cpu_to_be64(proto_tce | (rpn & TCE_RPN_MASK) << TCE_RPN_SHIFT);
rpn++;
}
@@ -329,16 +329,16 @@ struct direct_window {
/* Dynamic DMA Window support */
struct ddw_query_response {
- u32 windows_available;
- u32 largest_available_block;
- u32 page_size;
- u32 migration_capable;
+ __be32 windows_available;
+ __be32 largest_available_block;
+ __be32 page_size;
+ __be32 migration_capable;
};
struct ddw_create_response {
- u32 liobn;
- u32 addr_hi;
- u32 addr_lo;
+ __be32 liobn;
+ __be32 addr_hi;
+ __be32 addr_lo;
};
static LIST_HEAD(direct_window_list);
@@ -392,7 +392,8 @@ static int tce_setrange_multi_pSeriesLP(unsigned long start_pfn,
unsigned long num_pfn, const void *arg)
{
const struct dynamic_dma_window_prop *maprange = arg;
- u64 *tcep, tce_size, num_tce, dma_offset, next, proto_tce, liobn;
+ u64 tce_size, num_tce, dma_offset, next, proto_tce, liobn;
+ __be64 *tcep;
u32 tce_shift;
u64 rc = 0;
long l, limit;
@@ -401,7 +402,7 @@ static int tce_setrange_multi_pSeriesLP(unsigned long start_pfn,
tcep = __get_cpu_var(tce_page);
if (!tcep) {
- tcep = (u64 *)__get_free_page(GFP_ATOMIC);
+ tcep = (__be64 *)__get_free_page(GFP_ATOMIC);
if (!tcep) {
local_irq_enable();
return -ENOMEM;
@@ -435,7 +436,7 @@ static int tce_setrange_multi_pSeriesLP(unsigned long start_pfn,
dma_offset = next + be64_to_cpu(maprange->dma_base);
for (l = 0; l < limit; l++) {
- tcep[l] = proto_tce | next;
+ tcep[l] = cpu_to_be64(proto_tce | next);
next += tce_size;
}
@@ -780,7 +781,7 @@ static u64 find_existing_ddw(struct device_node *pdn)
list_for_each_entry(window, &direct_window_list, list) {
if (window->device == pdn) {
direct64 = window->prop;
- dma_addr = direct64->dma_base;
+ dma_addr = be64_to_cpu(direct64->dma_base);
break;
}
}
@@ -1045,11 +1046,11 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
dev_dbg(&dev->dev, "no free dynamic windows");
goto out_restore_window;
}
- if (query.page_size & 4) {
+ if (be32_to_cpu(query.page_size) & 4) {
page_shift = 24; /* 16MB */
- } else if (query.page_size & 2) {
+ } else if (be32_to_cpu(query.page_size) & 2) {
page_shift = 16; /* 64kB */
- } else if (query.page_size & 1) {
+ } else if (be32_to_cpu(query.page_size) & 1) {
page_shift = 12; /* 4kB */
} else {
dev_dbg(&dev->dev, "no supported direct page size in mask %x",
@@ -1059,7 +1060,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
/* verify the window * number of ptes will map the partition */
/* check largest block * page size > max memory hotplug addr */
max_addr = memory_hotplug_max();
- if (query.largest_available_block < (max_addr >> page_shift)) {
+ if (be32_to_cpu(query.largest_available_block) < (max_addr >> page_shift)) {
dev_dbg(&dev->dev, "can't map partiton max 0x%llx with %u "
"%llu-sized pages\n", max_addr, query.largest_available_block,
1ULL << page_shift);
@@ -1085,7 +1086,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
if (ret != 0)
goto out_free_prop;
- ddwprop->liobn = cpu_to_be32(create.liobn);
+ ddwprop->liobn = create.liobn;
ddwprop->dma_base = cpu_to_be64(of_read_number(&create.addr_hi, 2));
ddwprop->tce_shift = cpu_to_be32(page_shift);
ddwprop->window_shift = cpu_to_be32(len);
^ permalink raw reply related
* RE: [PATCH] [PATCH] powerpc/vio: use strcpy in modalias_show
From: David Laight @ 2013-10-17 12:22 UTC (permalink / raw)
To: Prarit Bhargava, linuxppc-dev; +Cc: ben, stable
In-Reply-To: <1382011211-15272-1-git-send-email-prarit@redhat.com>
> Commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 used strcat instead of
> strcpy which can result in an overflow of newlines on the buffer.
...
> --- a/arch/powerpc/kernel/vio.c
> +++ b/arch/powerpc/kernel/vio.c
> @@ -1531,12 +1531,12 @@ static ssize_t modalias_show(struct device =
*dev, struct device_attribute
> *attr,
>=20
> dn =3D dev->of_node;
> if (!dn) {
> - strcat(buf, "\n");
> + strcpy(buf, "\n");
> return strlen(buf);
> }
> cp =3D of_get_property(dn, "compatible", NULL);
> if (!cp) {
> - strcat(buf, "\n");
> + strcpy(buf, "\n");
> return strlen(buf);
> }
Why not just:
buf[0] =3D '\n';
buf[1] =3D 0;
return 1;
The assignment to buf[1] might not even be needed.
David
^ permalink raw reply
* Re: [PATCH] [PATCH] powerpc/vio: use strcpy in modalias_show
From: Prarit Bhargava @ 2013-10-17 12:29 UTC (permalink / raw)
To: David Laight; +Cc: ben, linuxppc-dev, stable
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7393@saturn3.aculab.com>
On 10/17/2013 08:22 AM, David Laight wrote:
>> Commit e82b89a6f19bae73fb064d1b3dd91fcefbb478f4 used strcat instead of
>> strcpy which can result in an overflow of newlines on the buffer.
> ...
>> --- a/arch/powerpc/kernel/vio.c
>> +++ b/arch/powerpc/kernel/vio.c
>> @@ -1531,12 +1531,12 @@ static ssize_t modalias_show(struct device *dev, struct device_attribute
>> *attr,
>>
>> dn = dev->of_node;
>> if (!dn) {
>> - strcat(buf, "\n");
>> + strcpy(buf, "\n");
>> return strlen(buf);
>> }
>> cp = of_get_property(dn, "compatible", NULL);
>> if (!cp) {
>> - strcat(buf, "\n");
>> + strcpy(buf, "\n");
>> return strlen(buf);
>> }
>
> Why not just:
> buf[0] = '\n';
> buf[1] = 0;
> return 1;
>
> The assignment to buf[1] might not even be needed.
Sure, I guess that'd work too. But it really seems like 1/2 a dozen of one and
six of the other. I'll defer to the preference of the maintainers to see what
they want.
P.
>
> David
>
>
>
^ permalink raw reply
* Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Lars-Peter Clausen @ 2013-10-17 12:21 UTC (permalink / raw)
To: Timur Tabi
Cc: mark.rutland, alsa-devel, linux-doc, tiwai, b18965, linux-kernel,
r65073, LW, linux, b42378, Xiubo Li, oskar, grant.likely,
devicetree, ian.campbell, pawel.moll, swarren, rob.herring,
broonie, linux-arm-kernel, fabio.estevam, lgirdwood, rob, r64188,
shawn.guo, linuxppc-dev
In-Reply-To: <525FD4C7.3050806@tabi.org>
On 10/17/2013 02:15 PM, Timur Tabi wrote:
> Xiubo Li wrote:
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + sai->base = devm_ioremap_resource(&pdev->dev, res);
>
> Why not use of_iomap()?
Because it won't check for conflicting resource regions.
- Lars
^ permalink raw reply
* Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Timur Tabi @ 2013-10-17 13:22 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: mark.rutland, alsa-devel, linux-doc, tiwai, b18965, linux-kernel,
r65073, LW, linux, b42378, Xiubo Li, oskar, grant.likely,
devicetree, ian.campbell, pawel.moll, swarren, rob.herring,
broonie, linux-arm-kernel, fabio.estevam, lgirdwood, rob, r64188,
shawn.guo, linuxppc-dev
In-Reply-To: <525FD65B.3040004@metafoo.de>
Lars-Peter Clausen wrote:
>>> >>+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> >>+ sai->base = devm_ioremap_resource(&pdev->dev, res);
>> >
>> >Why not use of_iomap()?
> Because it won't check for conflicting resource regions.
Maybe I've been out of the loop for too long, but why is that a
particular problem with this driver?
^ permalink raw reply
* Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Lars-Peter Clausen @ 2013-10-17 13:33 UTC (permalink / raw)
To: Timur Tabi
Cc: mark.rutland, alsa-devel, linux-doc, tiwai, b18965, linux-kernel,
r65073, LW, linux, b42378, Xiubo Li, oskar, grant.likely,
devicetree, ian.campbell, pawel.moll, swarren, rob.herring,
broonie, linux-arm-kernel, fabio.estevam, lgirdwood, rob, r64188,
shawn.guo, linuxppc-dev
In-Reply-To: <525FE48B.7020709@tabi.org>
On 10/17/2013 03:22 PM, Timur Tabi wrote:
> Lars-Peter Clausen wrote:
>>>> >>+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>> >>+ sai->base = devm_ioremap_resource(&pdev->dev, res);
>>> >
>>> >Why not use of_iomap()?
>> Because it won't check for conflicting resource regions.
>
> Maybe I've been out of the loop for too long, but why is that a particular
> problem with this driver?
It is usually something you'd want to check in general to make sure that you
don't have multiple device that access the same iomem region at the same time.
- Lars
^ permalink raw reply
* RE: [4/4] powerpc/mpc8548: Add workaround for erratum NMG_SRIO135
From: Zhao Chenhui-B35336 @ 2013-10-17 13:36 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20131016232003.GA27543@home.buserror.net>
=0A=
OK. I will do.=0A=
=0A=
-Chenhui=0A=
=0A=
________________________________________=0A=
From: Wood Scott-B07421=0A=
Sent: Thursday, October 17, 2013 7:20=0A=
To: Zhao Chenhui-B35336=0A=
Cc: linuxppc-dev@lists.ozlabs.org=0A=
Subject: Re: [4/4] powerpc/mpc8548: Add workaround for erratum NMG_SRIO135=
=0A=
=0A=
On Tue, Mar 06, 2012 at 05:10:56PM +0800, chenhui zhao wrote:=0A=
> From: chenhui zhao <chenhui.zhao@freescale.com>=0A=
>=0A=
> Issue:=0A=
> Applications using lwarx/stwcx instructions in the core to=0A=
> compete for a software lock or semaphore with a device on=0A=
> RapidIO using read atomic set, clr, inc, or dec in a similar=0A=
> manner may falsely result in both masters seeing the lock=0A=
> as "available". This could result in data corruption as=0A=
> both masters try to modify the same piece of data protected=0A=
> by the lock.=0A=
>=0A=
> Workaround:=0A=
> Set bits 13 and 29 of CCSR offset 0x01010 (EEBPCR register=0A=
> of the ECM) during initialization and leave them set=0A=
> indefinitely. This may slightly degrade overall system=0A=
> performance.=0A=
>=0A=
> Refer to SRIO39 in MPC8548 errata document.=0A=
>=0A=
> Signed-off-by: Gong Chen <g.chen@freescale.com>=0A=
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>=0A=
> Signed-off-by: Li Yang <leoli@freescale.com>=0A=
>=0A=
> ---=0A=
> arch/powerpc/sysdev/fsl_rio.c | 44 ++++++++++++++++++++++++++++++++++++=
+++++=0A=
> 1 files changed, 44 insertions(+), 0 deletions(-)=0A=
[snip]=0A=
> @@ -358,6 +391,17 @@ int fsl_rio_setup(struct platform_device *dev)=0A=
> dev->dev.of_node->full_name);=0A=
> return -EFAULT;=0A=
> }=0A=
> +=0A=
> + /* Fix erratum NMG_SRIO135 */=0A=
> + if (fsl_svr_is(SVR_8548) || fsl_svr_is(SVR_8548_E)) {=0A=
> + rc =3D fixup_erratum_srio135(&dev->dev);=0A=
> + if (rc) {=0A=
> + dev_err(&dev->dev,=0A=
> + "Failed to fix the erratum NMG_SRIO135.");=
=0A=
> + return rc;=0A=
> + }=0A=
> + }=0A=
=0A=
This needs to be respun based on the current tree.=0A=
=0A=
-Scott=0A=
^ permalink raw reply
* Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Timur Tabi @ 2013-10-17 13:37 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: mark.rutland, alsa-devel, linux-doc, tiwai, b18965, linux-kernel,
r65073, LW, linux, b42378, Xiubo Li, oskar, grant.likely,
devicetree, ian.campbell, pawel.moll, swarren, rob.herring,
broonie, linux-arm-kernel, fabio.estevam, lgirdwood, rob, r64188,
shawn.guo, linuxppc-dev
In-Reply-To: <525FE728.90403@metafoo.de>
Lars-Peter Clausen wrote:
>> >Maybe I've been out of the loop for too long, but why is that a particular
>> >problem with this driver?
> It is usually something you'd want to check in general to make sure that you
> don't have multiple device that access the same iomem region at the same time.
I understand that, but I'm trying to figure out why of_iomap() is okay
for hundreds of other drivers, but not this one. I've used it dozens of
times myself, without ever worrying about overlapping regions.
^ permalink raw reply
* RE: [PATCH 0/3 v2] iommu/fsl: PAMU driver fixes.
From: Sethi Varun-B16395 @ 2013-10-17 13:47 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,
Bhushan Bharat-R65777
In-Reply-To: <1381922582-28724-1-git-send-email-Varun.Sethi@freescale.com>
Hi Joerg,
Please consider these patches for 3.12.
Regards
Varun
> -----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 0/3 v2] iommu/fsl: PAMU driver fixes.
>=20
> The first patch fixes a build failure, when we try to build for a
> Freescale platform without PCI support.
>=20
> The second patch enables a default DMA window for the device, once it's
> detached from a domain. In case of vfio, once device is detached from a
> guest it can be again used by the host.
>=20
> The last patch adds the maintainer entry for the Freescale PAMU driver.
>=20
> Varun Sethi (3):
> iommu/fsl: Factor out PCI specific code.
> iommu/fsl: Enable default DMA window for PCIe devices once detached
> Add maintainers entry for the Freescale PAMU driver.
>=20
> MAINTAINERS | 7 ++
> drivers/iommu/fsl_pamu.c | 43 ++++++++++---
> drivers/iommu/fsl_pamu.h | 1 +
> drivers/iommu/fsl_pamu_domain.c | 134 +++++++++++++++++++++++++--------
> ------
> 4 files changed, 128 insertions(+), 57 deletions(-)
>=20
> --
> 1.7.9.5
^ permalink raw reply
* Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Lars-Peter Clausen @ 2013-10-17 13:51 UTC (permalink / raw)
To: Timur Tabi
Cc: mark.rutland, alsa-devel, linux-doc, tiwai, b18965, linux-kernel,
r65073, LW, linux, b42378, Xiubo Li, oskar, grant.likely,
devicetree, ian.campbell, pawel.moll, swarren, rob.herring,
broonie, linux-arm-kernel, fabio.estevam, lgirdwood, rob, r64188,
shawn.guo, linuxppc-dev
In-Reply-To: <525FE815.1040300@tabi.org>
On 10/17/2013 03:37 PM, Timur Tabi wrote:
> Lars-Peter Clausen wrote:
>>> >Maybe I've been out of the loop for too long, but why is that a particular
>>> >problem with this driver?
>
>> It is usually something you'd want to check in general to make sure that you
>> don't have multiple device that access the same iomem region at the same
>> time.
>
> I understand that, but I'm trying to figure out why of_iomap() is okay for
> hundreds of other drivers, but not this one. I've used it dozens of times
> myself, without ever worrying about overlapping regions.
The driver would work fine with just of_iomap(). But the resource range
check comes basically for free and it does help to catch errors, so I'd
recommend on using it rather than not using it.
- Lars
^ permalink raw reply
* Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Mark Brown @ 2013-10-17 14:10 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: mark.rutland, alsa-devel, linux-doc, tiwai, b18965, Timur Tabi,
lgirdwood, r65073, LW, linux, b42378, Xiubo Li, oskar,
grant.likely, devicetree, ian.campbell, pawel.moll, swarren,
rob.herring, linux-arm-kernel, fabio.estevam, linux-kernel, rob,
r64188, shawn.guo, linuxppc-dev
In-Reply-To: <525FEB7A.5040406@metafoo.de>
[-- Attachment #1: Type: text/plain, Size: 710 bytes --]
On Thu, Oct 17, 2013 at 03:51:54PM +0200, Lars-Peter Clausen wrote:
> On 10/17/2013 03:37 PM, Timur Tabi wrote:
> > I understand that, but I'm trying to figure out why of_iomap() is okay for
> > hundreds of other drivers, but not this one. I've used it dozens of times
> > myself, without ever worrying about overlapping regions.
> The driver would work fine with just of_iomap(). But the resource range
> check comes basically for free and it does help to catch errors, so I'd
> recommend on using it rather than not using it.
There's also the fact that it's a devm_ function which means less error
handling code that we can break which is nice. There's probably a case
for an improved OF helper here...
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: IBM OpenPower 720 ipr driver woes
From: Robert Knight @ 2013-10-17 14:57 UTC (permalink / raw)
To: Gavin Shan; +Cc: Brian King, Wendy Xiong, linuxppc-dev
In-Reply-To: <20130607002459.GA5512@shangw.(null)>
On 06/06/2013 08:24 PM, Gavin Shan wrote:
> On Thu, Jun 06, 2013 at 08:39:45AM -0400, Robert Knight wrote:
>> On 06/06/2013 07:32 AM, Brian King wrote:
>>> On 06/05/2013 04:14 PM, Robert Knight wrote:
>>>> On 6/3/2013 11:52 PM, Gavin Shan wrote:
>>>>> On Tue, Jun 04, 2013 at 01:16:52PM +1000, Tony Breeds wrote:
>>>>>> On Mon, Jun 03, 2013 at 09:40:52PM -0400, Robert Knight wrote:
>>>>>>> On 6/3/2013 8:01 PM, Tony Breeds wrote:
>>>>>>>> On Mon, Jun 03, 2013 at 05:20:12PM -0400, Robert Knight wrote:
> .../...
>
>> Yes. I've started rebuilding the kernel and I'm up to the module
>> building part, so I'd say it is solid. Will this patch make it into
>> some version of the kernel?
>>
> The patch is being pushed to mainline or linux-next, and backported
> to stable-kernel (v3.4+)
>
>
>> What was killing me was that it would not complete boot. It now
>> does. I see:
>>
>> [ 11.934481] scsi 0:0:15:0: Resetting device
>> [ 11.934813] ipr 0001:d0:01.0: Adapter being reset as a result of
>> error recovery.
>>
>> on each boot. It does not appear to affect operation.
>>
>> Thank you and the rest of the team for your rapid and helpful responses.
>>
> Thanks,
> Gavin
>
Well, it's four months later and I'm trying to get Fedora 20 Alpha to
install on that same machine. It appears to still have the same
problem. Did that patch ever make it into the mainline?
Strangely, the kernel from the installer (using DVD image) does NOT have
the problem, only the installed system.
Regards,
Robert
^ permalink raw reply
* Re: [PATCH v5] powerpc/mpc85xx: Update the clock nodes in device tree
From: Scott Wood @ 2013-10-17 16:24 UTC (permalink / raw)
To: Tang Yuantian-B29983
Cc: Mark Rutland, Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Li Yang-Leo-R58472, devicetree@vger.kernel.org
In-Reply-To: <D07C73A334FF604B95B3CBD2A545D07B150C4600@039-SN2MPN1-013.039d.mgd.msft.net>
On Wed, 2013-10-16 at 21:08 -0500, Tang Yuantian-B29983 wrote:
> > > > That shows the dividers as being somewhere in between the PLL and the
> > MUX.
> > > > The MUX is where the divider is selected. There's nothing in the
> > > > PLL's programming interface that relates to the dividers. As such
> > > > it's simpler to model it as being part of the MUX.
> > > >
> > > > -Scott
> > > >
> > > I don't know whether it is simpler, but "modeling divider as being part
> > of the MUX"
> > > is your guess, right?
> > > If the "divider" is included in MUX, the MUX would not be called "MUX".
> >
> > It's still selecting from multiple PLLs.
> >
> > > I don't know whether "divider" module exists or not. If it exists, it
> > > should be part of PLL or between PLL and MUX. wherever it was, the
> > device tree binding is appropriate.
> >
> > The device tree binding is unnecessarily complicated.
> >
> > > The P3041RM shows exactly each PLL has 2 outputs which definitely have
> > no "divider" at all.
> >
> > That diagram is a bit weird -- one of the outputs is used as is, and the
> > other is split into 1/2 and 1/4. It doesn't really matter though; the
> > end result is the same. We're describing the programming interface, not
> > artwork choices in the manual.
> >
> > -Scott
> >
> If the device tree needs to be modified, could you give me your suggestions?
My suggestion is to have only one output per PLL node. The MUX node
would have one input per PLL. Dividers would be handled internally to
the MUX driver.
-Scott
^ permalink raw reply
* Re: [PATCH -V2 00/14] Allow PR and HV KVM to coexist in one kernel
From: Alexander Graf @ 2013-10-17 16:49 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Paul Mackerras, linuxppc-dev, kvm-ppc,
kvm@vger.kernel.org mailing list
In-Reply-To: <1381164482-31001-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On 07.10.2013, at 18:47, Aneesh Kumar K.V =
<aneesh.kumar@linux.vnet.ibm.com> wrote:
> Hi All,
>=20
> This patch series support enabling HV and PR KVM together in the same =
kernel. We
> extend machine property with new property "kvm_type". A value of "HV" =
will force HV
> KVM and "PR" PR KVM. If we don't specify kvm_type we will select the =
fastest KVM mode.
> ie, HV if that is supported otherwise PR.
Thanks, applied all to kvm-ppc-queue.
Alex
^ permalink raw reply
* Re: [PATCH -V2 06/14] kvm: powerpc: booke: Convert BOOKE to use kvmppc_ops callbacks
From: Alexander Graf @ 2013-10-17 16:50 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Paul Mackerras, linuxppc-dev, kvm-ppc,
kvm@vger.kernel.org mailing list
In-Reply-To: <1381164482-31001-7-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On 07.10.2013, at 18:47, Aneesh Kumar K.V =
<aneesh.kumar@linux.vnet.ibm.com> wrote:
> From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
>=20
> Make required changes to get BOOKE configs to build with
> the introduction of kvmppc_ops callback
>=20
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
This can not be a separate commit, as you're breaking bisectability for =
booke this way.
I've squashed this in with the previous commit.
Alex
^ permalink raw reply
* Re: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Scott Wood @ 2013-10-17 16:51 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Bhushan Bharat-R65777
In-Reply-To: <ABB05CD9C9F68C46A5CEDC7F15439259010B189E@039-SN2MPN1-021.039d.mgd.msft.net>
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 = 0xffffffff_ffffffff,
Actually, tb_cycle will be undefined because you shifted a 32-bit value
(1) by more than 31 bits. s/1/1ULL/
> 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?
-Scott
^ permalink raw reply
* Re: [PATCH 02/10][v6] powerpc/Power7: detect load/store instructions
From: Sukadev Bhattiprolu @ 2013-10-17 17:20 UTC (permalink / raw)
To: David Laight, Arnaldo Carvalho de Melo
Cc: Michael Ellerman, linux-kernel, Stephane Eranian, linuxppc-dev,
Paul Mackerras, Anshuman Khandual
In-Reply-To: <20131016152742.GB25073@us.ibm.com>
|
| How about I add this to the function header ?
|
| * Please use the table in Appendix F (opcode maps) to determine
| * events selected by this function.
Here is the updated patch with the comment.
---
>From 38d1f9ac67a7f50db593e5875a8de6a2ecbea8e0 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Date: Fri, 23 Aug 2013 18:35:02 -0700
Subject: [PATCH 6/10][v6] powerpc/Power7: detect load/store instructions
Implement instr_is_load_store_2_06() to detect whether a given instruction
is one of the fixed-point or floating-point load/store instructions in the
POWER Instruction Set Architecture v2.06.
This function will be used in a follow-on patch to save memory hierarchy
information of the load/store on a Power7 system. (Power8 systems set some
bits in the SIER to identify load/store operations and hence don't need a
similar functionality).
Based on optimized code from Michael Ellerman and comments from Tom Musta.
Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
---
Changelog[v6]
- [David Laight, Anshuman Khandual] Add a comment in function
header to help better understand which instructions are selected
by the instr_is_load_store_2_06().
- [Michael Ellerman, Tom Musta]: Optmize the implementation to
avoid for loop.
arch/powerpc/include/asm/code-patching.h | 1 +
arch/powerpc/lib/code-patching.c | 48 ++++++++++++++++++++++++++++++
2 files changed, 49 insertions(+)
diff --git a/arch/powerpc/include/asm/code-patching.h b/arch/powerpc/include/asm/code-patching.h
index a6f8c7a..9cc3ef1 100644
--- a/arch/powerpc/include/asm/code-patching.h
+++ b/arch/powerpc/include/asm/code-patching.h
@@ -34,6 +34,7 @@ int instr_is_branch_to_addr(const unsigned int *instr, unsigned long addr);
unsigned long branch_target(const unsigned int *instr);
unsigned int translate_branch(const unsigned int *dest,
const unsigned int *src);
+int instr_is_load_store_2_06(const unsigned int *instr);
static inline unsigned long ppc_function_entry(void *func)
{
diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
index 2bc9db3..84571aa 100644
--- a/arch/powerpc/lib/code-patching.c
+++ b/arch/powerpc/lib/code-patching.c
@@ -159,6 +159,54 @@ unsigned int translate_branch(const unsigned int *dest, const unsigned int *src)
return 0;
}
+/*
+ * Determine if the op code in the instruction corresponds to a load or
+ * store instruction. Ignore the vector load instructions like evlddepx,
+ * evstddepx for now.
+ *
+ * This function is valid for POWER ISA 2.06.
+ *
+ * Reference: PowerISA_V2.06B_Public.pdf, Sections 3.3.2 through 3.3.6
+ * and 4.6.2 through 4.6.4, Appendix F (Opcode Maps).
+ *
+ * Use the tables in Appendix F (Opcode Maps) to identify
+ * instructions selected by this function.
+ */
+int instr_is_load_store_2_06(const unsigned int *instr)
+{
+ unsigned int op, upper, lower;
+
+ op = instr_opcode(*instr);
+
+ if ((op >= 32 && op <= 58) || (op == 61 || op == 62))
+ return true;
+
+ if (op != 31)
+ return false;
+
+ upper = op >> 5;
+ lower = op & 0x1f;
+
+ /* Short circuit as many misses as we can */
+ if (lower < 3 || lower > 23)
+ return false;
+
+ if (lower == 3) {
+ if (upper >= 16)
+ return true;
+
+ return false;
+ }
+
+ if (lower == 7 || lower == 12)
+ return true;
+
+ if (lower >= 20) /* && lower <= 23 (implicit) */
+ return true;
+
+ return false;
+}
+
#ifdef CONFIG_CODE_PATCHING_SELFTEST
--
1.7.9.5
^ permalink raw reply related
* Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Lars-Peter Clausen @ 2013-10-17 17:43 UTC (permalink / raw)
To: Xiubo Li
Cc: mark.rutland, alsa-devel, linux-doc, tiwai, b18965, timur,
lgirdwood, r65073, LW, linux, b42378, oskar, grant.likely,
devicetree, ian.campbell, pawel.moll, swarren, rob.herring,
broonie, linux-arm-kernel, fabio.estevam, linux-kernel, rob,
r64188, shawn.guo, linuxppc-dev
In-Reply-To: <1382000477-17304-2-git-send-email-Li.Xiubo@freescale.com>
On 10/17/2013 11:01 AM, Xiubo Li wrote:
[...]
> +static int fsl_sai_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params,
> + struct snd_soc_dai *cpu_dai)
> +{
> + int ret;
> +
> + ret = fsl_sai_hw_params_tr(substream, params, cpu_dai,
> + FSL_FMT_TRANSMITTER);
> + if (ret) {
> + dev_err(cpu_dai->dev,
> + "Cannot set sai transmitter hw params: %d\n",
> + ret);
> + return ret;
> + }
> +
> + ret = fsl_sai_hw_params_tr(substream, params, cpu_dai,
> + FSL_FMT_RECEIVER);
> + if (ret) {
> + dev_err(cpu_dai->dev,
> + "Cannot set sai's receiver hw params: %d\n",
> + ret);
> + return ret;
> + }
Shouldn't, depending on the substream direction, either transmit or receiver
be configured, instead of always configuring both?
> +
> + return 0;
> +}
> +
> +static int fsl_sai_trigger(struct snd_pcm_substream *substream, int cmd,
> + struct snd_soc_dai *dai)
> +{
> + struct fsl_sai *sai = snd_soc_dai_get_drvdata(dai);
> + unsigned int tcsr, rcsr;
> +
> + tcsr = readl(sai->base + SAI_TCSR);
> + rcsr = readl(sai->base + SAI_RCSR);
> +
> + switch (cmd) {
> + case SNDRV_PCM_TRIGGER_START:
> + case SNDRV_PCM_TRIGGER_RESUME:
> + case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> + rcsr |= SAI_CSR_TERE | SAI_CSR_FRDE;
> + tcsr |= SAI_CSR_TERE | SAI_CSR_FRDE;
> + writel(rcsr, sai->base + SAI_RCSR);
> + udelay(10);
> + writel(tcsr, sai->base + SAI_TCSR);
> + break;
> +
> + case SNDRV_PCM_TRIGGER_STOP:
> + case SNDRV_PCM_TRIGGER_SUSPEND:
> + case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> + tcsr &= ~(SAI_CSR_TERE | SAI_CSR_FRDE);
> + rcsr &= ~(SAI_CSR_TERE | SAI_CSR_FRDE);
> + writel(tcsr, sai->base + SAI_TCSR);
> + udelay(10);
> + writel(rcsr, sai->base + SAI_RCSR);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
Same here, shouldn't tx and rx be started independently depending on the
substream direction?
> + return 0;
> +}
> +
> +static struct snd_soc_dai_ops fsl_sai_pcm_dai_ops = {
const
> + .set_sysclk = fsl_sai_set_dai_sysclk,
> + .set_clkdiv = fsl_sai_set_dai_clkdiv,
> + .set_fmt = fsl_sai_set_dai_fmt,
> + .set_tdm_slot = fsl_sai_set_dai_tdm_slot,
> + .hw_params = fsl_sai_hw_params,
> + .trigger = fsl_sai_trigger,
> +};
[...]
> +static const struct snd_soc_component_driver fsl_component = {
> + .name = "fsl-sai",
> +};
> +
> +static int fsl_sai_probe(struct platform_device *pdev)
> +{
[...]
> +
> + sai->dma_params_rx.addr = res->start + SAI_RDR;
> + sai->dma_params_rx.maxburst = 6;
> + index = of_property_match_string(np, "dma-names", "rx");
> + ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells", index,
> + &dma_args);
> + if (ret)
> + return ret;
> + sai->dma_params_rx.slave_id = dma_args.args[1];
> +
> + sai->dma_params_tx.addr = res->start + SAI_TDR;
> + sai->dma_params_tx.maxburst = 6;
> + index = of_property_match_string(np, "dma-names", "tx");
> + ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells", index,
> + &dma_args);
> + if (ret)
> + return ret;
> + sai->dma_params_tx.slave_id = dma_args.args[1];
The driver should not have to manually parse the dma devicetree properties,
this is something that should be handled by the dma engine driver.
> +
> + ret = snd_soc_register_component(&pdev->dev, &fsl_component,
> + &fsl_sai_dai, 1);
> + if (ret)
> + return ret;
> +
> + ret = fsl_pcm_dma_init(pdev);
> + if (ret)
> + goto out;
> +
> + platform_set_drvdata(pdev, sai);
> +
> + return 0;
> +
> +out:
> + snd_soc_unregister_component(&pdev->dev);
> + return ret;
> +}
^ permalink raw reply
* Re: [PATCH 5/7] jump_label: relax branch hinting restrictions
From: Steven Rostedt @ 2013-10-17 17:35 UTC (permalink / raw)
To: rkrcmar
Cc: linux-mips, x86, linux-doc, Heiko Carstens, sparclinux,
Paul Mackerras, H. Peter Anvin, Masami Hiramatsu, linux-s390,
Russell King, Raghavendra K T, Ingo Molnar, Andrew Jones,
Konrad Rzeszutek Wilk, Thomas Gleixner, linux-arm-kernel,
Richard Henderson, Jiri Kosina, linux-kernel, Ralf Baechle,
Rob Landley, Martin Schwidefsky, linux390, linuxppc-dev,
David S. Miller
In-Reply-To: <1382004631-25895-6-git-send-email-rkrcmar@redhat.com>
On Thu, 17 Oct 2013 12:10:28 +0200
Radim Kr=C4=8Dm=C3=A1=C5=99 <rkrcmar@redhat.com> wrote:
> We implemented the optimized branch selection in higher levels of api.
> That made static_keys very unintuitive, so this patch introduces another
> element to jump_table, carrying one bit that tells the underlying code
> which branch to optimize.
>=20
> It is now possible to select optimized branch for every jump_entry.
>=20
> Current side effect is 1/3 increase increase in space, we could:
> * use bitmasks and selectors on 2+ aligned code/struct.
> - aligning jump target is easy, but because it is not done by default
> and few bytes in .text are much worse that few kilos in .data,
> I chose not to
> - data is probably aligned by default on all current architectures,
> but programmer can force misalignment of static_key
> * optimize each architecture independently
> - I can't test everything and this patch shouldn't break anything, so
> others can contribute in the future
> * choose something worse, like packing or splitting
> * ignore
>=20
> proof: example & x86_64 disassembly: (F =3D ffffffff)
>=20
> struct static_key flexible_feature;
> noinline void jump_label_experiment(void) {
> if ( static_key_false(&flexible_feature))
> asm ("push 0xa1");
> else asm ("push 0xa0");
> if (!static_key_false(&flexible_feature))
> asm ("push 0xb0");
> else asm ("push 0xb1");
> if ( static_key_true(&flexible_feature))
> asm ("push 0xc1");
> else asm ("push 0xc0");
> if (!static_key_true(&flexible_feature))
> asm ("push 0xd0");
> else asm ("push 0xd1");
> }
>=20
> Disassembly of section .text: (push marked by "->")
>=20
> F81002000 <jump_label_experiment>:
> F81002000: e8 7b 29 75 00 callq F81754980 <__fentry__>
> F81002005: 55 push %rbp
> F81002006: 48 89 e5 mov %rsp,%rbp
> F81002009: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> F8100200e: -> ff 34 25 a0 00 00 00 pushq 0xa0
> F81002015: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> F8100201a: -> ff 34 25 b0 00 00 00 pushq 0xb0
> F81002021: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> F81002026: -> ff 34 25 c1 00 00 00 pushq 0xc1
> F8100202d: 0f 1f 00 nopl (%rax)
> F81002030: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> F81002035: -> ff 34 25 d1 00 00 00 pushq 0xd1
> F8100203c: 5d pop %rbp
> F8100203d: 0f 1f 00 nopl (%rax)
> F81002040: c3 retq
This looks exactly like what we want. I take it this is with your
patch. What was the result before the patch?
-- Steve
> F81002041: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
> F81002048: -> ff 34 25 d0 00 00 00 pushq 0xd0
> F8100204f: 5d pop %rbp
> F81002050: c3 retq
> F81002051: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
> F81002058: -> ff 34 25 c0 00 00 00 pushq 0xc0
> F8100205f: 90 nop
> F81002060: eb cb jmp F8100202d <[...]+0x2d>
> F81002062: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
> F81002068: -> ff 34 25 b1 00 00 00 pushq 0xb1
> F8100206f: 90 nop
> F81002070: eb af jmp F81002021 <[...]+0x21>
> F81002072: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
> F81002078: -> ff 34 25 a1 00 00 00 pushq 0xa1
> F8100207f: 90 nop
> F81002080: eb 93 jmp F81002015 <[...]+0x15>
> F81002082: 66 66 66 66 66 2e 0f [...]
> F81002089: 1f 84 00 00 00 00 00
>=20
> Contents of section .data: (relevant part of embedded __jump_table)
^ permalink raw reply
* RE: [PATCH v5] powerpc/mpc85xx: Update the clock nodes in device tree
From: Tang Yuantian-B29983 @ 2013-10-18 2:06 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: <1382027085.7979.774.camel@snotra.buserror.net>
PiBPbiBXZWQsIDIwMTMtMTAtMTYgYXQgMjE6MDggLTA1MDAsIFRhbmcgWXVhbnRpYW4tQjI5OTgz
IHdyb3RlOg0KPiA+ID4gPiA+IFRoYXQgc2hvd3MgdGhlIGRpdmlkZXJzIGFzIGJlaW5nIHNvbWV3
aGVyZSBpbiBiZXR3ZWVuIHRoZSBQTEwNCj4gPiA+ID4gPiBhbmQgdGhlDQo+ID4gPiBNVVguDQo+
ID4gPiA+ID4gVGhlIE1VWCBpcyB3aGVyZSB0aGUgZGl2aWRlciBpcyBzZWxlY3RlZC4gIFRoZXJl
J3Mgbm90aGluZyBpbg0KPiA+ID4gPiA+IHRoZSBQTEwncyBwcm9ncmFtbWluZyBpbnRlcmZhY2Ug
dGhhdCByZWxhdGVzIHRvIHRoZSBkaXZpZGVycy4NCj4gPiA+ID4gPiBBcyBzdWNoIGl0J3Mgc2lt
cGxlciB0byBtb2RlbCBpdCBhcyBiZWluZyBwYXJ0IG9mIHRoZSBNVVguDQo+ID4gPiA+ID4NCj4g
PiA+ID4gPiAtU2NvdHQNCj4gPiA+ID4gPg0KPiA+ID4gPiBJIGRvbid0IGtub3cgd2hldGhlciBp
dCBpcyBzaW1wbGVyLCBidXQgIm1vZGVsaW5nIGRpdmlkZXIgYXMgYmVpbmcNCj4gPiA+ID4gcGFy
dA0KPiA+ID4gb2YgdGhlIE1VWCINCj4gPiA+ID4gaXMgeW91ciBndWVzcywgcmlnaHQ/DQo+ID4g
PiA+IElmIHRoZSAiZGl2aWRlciIgaXMgaW5jbHVkZWQgaW4gTVVYLCB0aGUgTVVYIHdvdWxkIG5v
dCBiZSBjYWxsZWQNCj4gIk1VWCIuDQo+ID4gPg0KPiA+ID4gSXQncyBzdGlsbCBzZWxlY3Rpbmcg
ZnJvbSBtdWx0aXBsZSBQTExzLg0KPiA+ID4NCj4gPiA+ID4gSSBkb24ndCBrbm93IHdoZXRoZXIg
ImRpdmlkZXIiIG1vZHVsZSBleGlzdHMgb3Igbm90LiBJZiBpdCBleGlzdHMsDQo+ID4gPiA+IGl0
IHNob3VsZCBiZSBwYXJ0IG9mIFBMTCBvciBiZXR3ZWVuIFBMTCBhbmQgTVVYLiB3aGVyZXZlciBp
dCB3YXMsDQo+ID4gPiA+IHRoZQ0KPiA+ID4gZGV2aWNlIHRyZWUgYmluZGluZyBpcyBhcHByb3By
aWF0ZS4NCj4gPiA+DQo+ID4gPiBUaGUgZGV2aWNlIHRyZWUgYmluZGluZyBpcyB1bm5lY2Vzc2Fy
aWx5IGNvbXBsaWNhdGVkLg0KPiA+ID4NCj4gPiA+ID4gVGhlIFAzMDQxUk0gc2hvd3MgZXhhY3Rs
eSBlYWNoIFBMTCBoYXMgMiBvdXRwdXRzIHdoaWNoIGRlZmluaXRlbHkNCj4gPiA+ID4gaGF2ZQ0K
PiA+ID4gbm8gImRpdmlkZXIiIGF0IGFsbC4NCj4gPiA+DQo+ID4gPiBUaGF0IGRpYWdyYW0gaXMg
YSBiaXQgd2VpcmQgLS0gb25lIG9mIHRoZSBvdXRwdXRzIGlzIHVzZWQgYXMgaXMsIGFuZA0KPiA+
ID4gdGhlIG90aGVyIGlzIHNwbGl0IGludG8gMS8yIGFuZCAxLzQuICBJdCBkb2Vzbid0IHJlYWxs
eSBtYXR0ZXINCj4gPiA+IHRob3VnaDsgdGhlIGVuZCByZXN1bHQgaXMgdGhlIHNhbWUuICBXZSdy
ZSBkZXNjcmliaW5nIHRoZQ0KPiA+ID4gcHJvZ3JhbW1pbmcgaW50ZXJmYWNlLCBub3QgYXJ0d29y
ayBjaG9pY2VzIGluIHRoZSBtYW51YWwuDQo+ID4gPg0KPiA+ID4gLVNjb3R0DQo+ID4gPg0KPiA+
IElmIHRoZSBkZXZpY2UgdHJlZSBuZWVkcyB0byBiZSBtb2RpZmllZCwgY291bGQgeW91IGdpdmUg
bWUgeW91cg0KPiBzdWdnZXN0aW9ucz8NCj4gDQo+IE15IHN1Z2dlc3Rpb24gaXMgdG8gaGF2ZSBv
bmx5IG9uZSBvdXRwdXQgcGVyIFBMTCBub2RlLiAgVGhlIE1VWCBub2RlDQo+IHdvdWxkIGhhdmUg
b25lIGlucHV0IHBlciBQTEwuICBEaXZpZGVycyB3b3VsZCBiZSBoYW5kbGVkIGludGVybmFsbHkg
dG8NCj4gdGhlIE1VWCBkcml2ZXIuDQo+IA0KPiAtU2NvdHQNCj4gDQpJIGRvbid0IHRoaW5rIHlv
dXIgc3VnZ2VzdGlvbiBpcyBjb25zdHJ1Y3RpdmUuDQpZb3VyIHN1Z2dlc3Rpb24gaXMgb24gdGhl
IHByZW1pc2Ugb2YgdGhhdCB0aGUgImRpdmlkZXIiIGlzIHBhcnQgb2YgTVVYLA0KQW5kIEkgdGhp
bmsgaXQgc2hvdWxkIGJlIHBhcnQgb2YgUExMLg0KTVVYIGNhbid0IENSRUFURSBjbG9jayB3aGlj
aCBQTEwgY2FuLiBTbyBteSB0aG91Z2h0IGlzIG1vcmUgcmVhc29uYWJsZS4NCklmIHRoZSBkZXZp
Y2UgdHJlZSBkb2N1bWVudHMgbGlrZSB3aGF0IHlvdSBzYWlkLCBpdCB3b3VsZCBoYXZlIGZldyBo
ZWxwIGZvciBkcml2ZXIuDQpUaGUgcmVhc29uIGlzIG9idmlvdXMgdGhhdCB0aGUgZHJpdmVyIGlz
IHN0aWxsIGdvaW5nIHRvIGRlYWwgd2l0aCB0aGUgImRpdmlkZXIiIA0KZGV0YWlsIHdoaWNoIHZh
cmllcyBmcm9tIHBsYXRmb3JtIHRvIHBsYXRmb3JtLg0KSSB3aWxsIGRvY3VtZW50IGFzIGl0IHdh
cyB1bmxlc3MgeW91IHByb3ZlIHlvdXIgc3VnZ2VzdGlvbi4NCg0KVGhhbmtzLA0KWXVhbnRpYW4N
Cg==
^ permalink raw reply
* RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Wang Dongsheng-B40534 @ 2013-10-18 2:36 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org, Bhushan Bharat-R65777
In-Reply-To: <1382028703.7979.782.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDE4LCAyMDEzIDEyOjUyIEFNDQo+IFRvOiBXYW5n
IERvbmdzaGVuZy1CNDA1MzQNCj4gQ2M6IEJodXNoYW4gQmhhcmF0LVI2NTc3NzsgV29vZCBTY290
dC1CMDc0MjE7IGxpbnV4cHBjLQ0KPiBkZXZAbGlzdHMub3psYWJzLm9yZw0KPiBTdWJqZWN0OiBS
ZTogW1BBVENIIHY1IDQvNF0gcG93ZXJwYy84NXh4OiBhZGQgc3lzZnMgZm9yIHB3MjAgc3RhdGUg
YW5kDQo+IGFsdGl2ZWMgaWRsZQ0KPiANCj4gT24gVGh1LCAyMDEzLTEwLTE3IGF0IDAwOjUxIC0w
NTAwLCBXYW5nIERvbmdzaGVuZy1CNDA1MzQgd3JvdGU6DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBCaHVzaGFuIEJoYXJhdC1SNjU3NzcNCj4gPiA+
IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE3LCAyMDEzIDExOjIwIEFNDQo+ID4gPiBUbzogV2Fu
ZyBEb25nc2hlbmctQjQwNTM0OyBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gQ2M6IGxpbnV4cHBj
LWRldkBsaXN0cy5vemxhYnMub3JnDQo+ID4gPiBTdWJqZWN0OiBSRTogW1BBVENIIHY1IDQvNF0g
cG93ZXJwYy84NXh4OiBhZGQgc3lzZnMgZm9yIHB3MjAgc3RhdGUNCj4gPiA+IGFuZCBhbHRpdmVj
IGlkbGUNCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCj4gPiA+ID4gRnJvbTogV2FuZyBEb25nc2hlbmctQjQwNTM0DQo+ID4gPiA+IFNlbnQ6
IFRodXJzZGF5LCBPY3RvYmVyIDE3LCAyMDEzIDg6MTYgQU0NCj4gPiA+ID4gVG86IEJodXNoYW4g
QmhhcmF0LVI2NTc3NzsgV29vZCBTY290dC1CMDc0MjENCj4gPiA+ID4gQ2M6IGxpbnV4cHBjLWRl
dkBsaXN0cy5vemxhYnMub3JnDQo+ID4gPiA+IFN1YmplY3Q6IFJFOiBbUEFUQ0ggdjUgNC80XSBw
b3dlcnBjLzg1eHg6IGFkZCBzeXNmcyBmb3IgcHcyMCBzdGF0ZQ0KPiA+ID4gPiBhbmQgYWx0aXZl
YyBpZGxlDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ID4gLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBGcm9tOiBCaHVzaGFuIEJoYXJhdC1SNjU3NzcNCj4g
PiA+ID4gPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxNywgMjAxMyAxOjAxIEFNDQo+ID4gPiA+
ID4gVG86IFdhbmcgRG9uZ3NoZW5nLUI0MDUzNDsgV29vZCBTY290dC1CMDc0MjENCj4gPiA+ID4g
PiBDYzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gPiA+ID4gPiBTdWJqZWN0OiBS
RTogW1BBVENIIHY1IDQvNF0gcG93ZXJwYy84NXh4OiBhZGQgc3lzZnMgZm9yIHB3MjANCj4gPiA+
ID4gPiBzdGF0ZSBhbmQgYWx0aXZlYyBpZGxlDQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4g
PiA+DQo+ID4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ID4g
RnJvbTogV2FuZyBEb25nc2hlbmctQjQwNTM0DQo+ID4gPiA+ID4gPiBTZW50OiBUdWVzZGF5LCBP
Y3RvYmVyIDE1LCAyMDEzIDI6NTEgUE0NCj4gPiA+ID4gPiA+IFRvOiBXb29kIFNjb3R0LUIwNzQy
MQ0KPiA+ID4gPiA+ID4gQ2M6IEJodXNoYW4gQmhhcmF0LVI2NTc3NzsgbGludXhwcGMtZGV2QGxp
c3RzLm96bGFicy5vcmc7IFdhbmcNCj4gPiA+ID4gPiBEb25nc2hlbmctQjQwNTM0DQo+ID4gPiA+
ID4gPiBTdWJqZWN0OiBbUEFUQ0ggdjUgNC80XSBwb3dlcnBjLzg1eHg6IGFkZCBzeXNmcyBmb3Ig
cHcyMCBzdGF0ZQ0KPiA+ID4gPiA+ID4gYW5kDQo+ID4gPiA+ID4gYWx0aXZlYyBpZGxlDQo+ID4g
PiA+ID4gPg0KPiA+ID4gPiA+ID4gK3N0YXRpYyBzc2l6ZV90IHNob3dfcHcyMF93YWl0X3RpbWUo
c3RydWN0IGRldmljZSAqZGV2LA0KPiA+ID4gPiA+ID4gKwkJCQlzdHJ1Y3QgZGV2aWNlX2F0dHJp
YnV0ZSAqYXR0ciwgY2hhciAqYnVmKSB7DQo+ID4gPiA+ID4gPiArCXUzMiB2YWx1ZTsNCj4gPiA+
ID4gPiA+ICsJdTY0IHRiX2N5Y2xlOw0KPiA+ID4gPiA+ID4gKwlzNjQgdGltZTsNCj4gPiA+ID4g
PiA+ICsNCj4gPiA+ID4gPiA+ICsJdW5zaWduZWQgaW50IGNwdSA9IGRldi0+aWQ7DQo+ID4gPiA+
ID4gPiArDQo+ID4gPiA+ID4gPiArCWlmICghcHcyMF93dCkgew0KPiA+ID4gPiA+ID4gKwkJc21w
X2NhbGxfZnVuY3Rpb25fc2luZ2xlKGNwdSwgZG9fc2hvd19wd3JtZ3RjcjAsICZ2YWx1ZSwNCj4g
PiA+IDEpOw0KPiA+ID4gPiA+ID4gKwkJdmFsdWUgPSAodmFsdWUgJiBQV1JNR1RDUjBfUFcyMF9F
TlQpID4+DQo+ID4gPiA+ID4gPiArCQkJCQlQV1JNR1RDUjBfUFcyMF9FTlRfU0hJRlQ7DQo+ID4g
PiA+ID4gPiArDQo+ID4gPiA+ID4gPiArCQl0Yl9jeWNsZSA9ICgxIDw8IChNQVhfQklUIC0gdmFs
dWUpKSAqIDI7DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJcyB2YWx1ZSA9IDAgYW5kIHZhbHVlID0g
MSBsZWdhbD8gVGhlc2Ugd2lsbCBtYWtlIHRiX2N5Y2xlID0gMCwNCj4gPiA+ID4gPg0KPiA+ID4g
PiA+ID4gKwkJdGltZSA9IGRpdl91NjQodGJfY3ljbGUgKiAxMDAwLCB0Yl90aWNrc19wZXJfdXNl
YykgLSAxOw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQW5kIHRpbWUgPSAtMTsNCj4gPiA+ID4gPg0K
PiA+ID4gPiBQbGVhc2UgbG9vayBhdCB0aGUgZW5kIG9mIHRoZSBmdW5jdGlvbiwgOikNCj4gPiA+
ID4NCj4gPiA+ID4gInJldHVybiBzcHJpbnRmKGJ1ZiwgIiVsbHVcbiIsIHRpbWUgPiAwID8gdGlt
ZSA6IDApOyINCj4gPiA+DQo+ID4gPiBJIGtub3cgeW91IHJldHVybiAwIGlmIHZhbHVlID0gMC8x
LCBteSBxdWVzdGlvbiB3YXMgdGhhdCwgaXMgdGhpcw0KPiA+ID4gY29ycmVjdCBhcyBwZXIgc3Bl
Y2lmaWNhdGlvbj8NCj4gPiA+DQo+ID4gPiBBaGgsIGFsc28gZm9yICJ2YWx1ZSIgdXB0byA3IHlv
dSB3aWxsIHJldHVybiAwLCBubz8NCj4gPiA+DQo+ID4gSWYgdmFsdWUgPSAwLCBNQVhfQklUIC0g
dmFsdWUgPSA2Mw0KPiA+IHRiX2N5Y2xlID0gMHhmZmZmZmZmZl9mZmZmZmZmZiwNCj4gDQo+IEFj
dHVhbGx5LCB0Yl9jeWNsZSB3aWxsIGJlIHVuZGVmaW5lZCBiZWNhdXNlIHlvdSBzaGlmdGVkIGEg
MzItYml0IHZhbHVlDQo+ICgxKSBieSBtb3JlIHRoYW4gMzEgYml0cy4gIHMvMS8xVUxMLw0KPiAN
CkFjdHVhbGx5LCB3ZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyB0aGlzIHNpdHVhdGlvbiB0aGF0IGNv
dWxkIG5vdCBoYXZlIGhhcHBlbmVkLg0KU2VlICFwdzIwX3d0IGJyYW5jaCwgdGhpcyBicmFuY2gg
aXMgcmVhZCBkZWZhdWx0IHdhaXQgYml0Lg0KVGhlIGRlZmF1bHQgd2FpdCBiaXQgaXMgNTAsIHRo
ZSB0aW1lIGlzIGFib3V0IDFtcy4NClRoZSBkZWZhdWx0IHdhaXQgYml0IGNhbm5vdCBsZXNzIHRo
YW4gNTAsIG1lYW5zIHRoZSB3YWl0IGVudHJ5IHRpbWUgY2Fubm90IGdyZWF0ZXIgdGhhbiAxbXMu
DQpXZSBoYXZlIGFscmVhZHkgYmVndW4gYmVuY2htYXJrIHRlc3QsIGFuZCB3ZSBnb3QgYSBwcmVs
aW1pbmFyeSByZXN1bHRzLg0KNTUsIDU2LCA1N2JpdCBsb29rcyBnb29kLCBidXQgd2UgbmVlZCBt
b3JlIGJlbmNobWFyayB0byBnZXQgdGhlIGRlZmF1bHQgYml0Lg0KDQoJaWYgKCFwdzIwX3d0KSB7
DQoJCXNtcF9jYWxsX2Z1bmN0aW9uX3NpbmdsZShjcHUsIGRvX3Nob3dfcHdybWd0Y3IwLCAmdmFs
dWUsIDEpOw0KCQl2YWx1ZSA9ICh2YWx1ZSAmIFBXUk1HVENSMF9QVzIwX0VOVCkgPj4NCgkJCQkJ
UFdSTUdUQ1IwX1BXMjBfRU5UX1NISUZUOw0KDQoJCXRiX2N5Y2xlID0gKDEgPDwgKE1BWF9CSVQg
LSB2YWx1ZSkpICogMjsNCgkJdGltZSA9IGRpdl91NjQodGJfY3ljbGUgKiAxMDAwLCB0Yl90aWNr
c19wZXJfdXNlYykgLSAxOw0KCX0gZWxzZSB7DQoJCXRpbWUgPSBwdzIwX3d0Ow0KCX0NCg0KSWYg
aXQgY2F1c2VkIGNvbmZ1c2lvbiwgd2UgY2FuIGFkZCBhIGNvbW1lbnQuIEFzIEkgZGlzY3VzcyB3
aXRoIEJoYXJhdC4NCg0KPiA+IHRiX2N5Y2xlICogMTAwMCB3aWxsIG92ZXJmbG93LCBidXQgdGhp
cyBzaXR1YXRpb24gaXMgbm90IHBvc3NpYmxlLg0KPiA+IEJlY2F1c2UgaWYgdGhlICJ2YWx1ZSA9
IDAiIG1lYW5zIHRoaXMgZmVhdHVyZSB3aWxsIGJlICJkaXNhYmxlIi4NCj4gPiBOb3cgVGhlIGRl
ZmF1bHQgd2FpdCBiaXQgaXMgNTAoTUFYX0JJVCAtIHZhbHVlLCB2YWx1ZSA9IDEzKSwgdGhlDQo+
ID4gUFcyMC9BbHRpdmVjIElkbGUgd2FpdCBlbnRyeSB0aW1lIGlzIGFib3V0IDFtcywgdGhpcyB0
aW1lIGlzIHZlcnkgbG9uZw0KPiA+IGZvciB3YWl0IGlkbGUgdGltZSwgYW5kIGl0J3MgY2Fubm90
IGJlIGluY3JlYXNlZChtZWFucyAoTUFYX0JJVCAtDQo+ID4gdmFsdWUpIGNhbm5vdCBncmVhdGVy
IHRoYW4gNTApLg0KPiANCj4gV2h5IGNhbiBpdCBub3QgYmUgaW5jcmVhc2VkPw0KPg0Kc2VlIGFi
b3ZlLCA6KQ0KDQotZG9uZ3NoZW5nDQo+IC1TY290dA0KPiANCg0K
^ permalink raw reply
* RE: [PATCH v5 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle
From: Wang Dongsheng-B40534 @ 2013-10-18 3:02 UTC (permalink / raw)
To: Bhushan Bharat-R65777, Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D071C362B@039-SN2MPN1-013.039d.mgd.msft.net>
> -----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
>=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_cycl=
e =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_ffff=
ffff,
> > > > 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).
> > >
> > > 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 below calculation will not overflow. may be error out
> > > if value is less than 8.
> > >
> > 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 why I use the following code. :)
>=20
> I am sorry to persist but this is not about what you know, this is about
> how code is read and code does not say what you know, so add a comment at
> least and error out/warn when "value" is less than a certain number.
>=20
Sorry for the late to response the mail. If it caused confusion, we can add=
a comment.
How about the following comment?
/*
* If the "value" less than 10, this will overflow.
* From benchmark test, the default wait bit will not be set less than 10bi=
t.
* Because 10 bit corresponds to the wait entry time is 439375573401999609(=
ns),
* for wait-entry-idle time this value looks too long, and we cannot use th=
ose
* "long" time as a default wait-entry time. So overflow could not have hap=
pened
* and we use this calculation method to get wait-entry-idle time.
*/
> -Bharat
^ permalink raw reply
* RE: [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Xiubo Li-B47053 @ 2013-10-18 3:19 UTC (permalink / raw)
To: Lothar Waßmann
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, Wang Huan-B18965,
timur@tabi.org, perex@perex.cz, Guo Shawn-R65073,
linux@arm.linux.org.uk, Chen Guangyu-B42378,
linux-arm-kernel@lists.infradead.org, grant.likely@linaro.org,
devicetree@vger.kernel.org, ian.campbell@citrix.com,
pawel.moll@arm.com, swarren@wwwdotorg.org,
rob.herring@calxeda.com, broonie@kernel.org, oskar@scara.com,
Estevam Fabio-R49496, lgirdwood@gmail.com,
linux-kernel@vger.kernel.org, rob@landley.net,
Jin Zhengxiong-R64188, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20131017114208.595a4224@ipc1.ka-ro>
SGksDQoNCj4gPiArCXJlcyA9IHBsYXRmb3JtX2dldF9yZXNvdXJjZShwZGV2LCBJT1JFU09VUkNF
X01FTSwgMCk7DQo+ID4gKwlzYWktPmJhc2UgPSBkZXZtX2lvcmVtYXBfcmVzb3VyY2UoJnBkZXYt
PmRldiwgcmVzKTsNCj4gPiArCWlmIChJU19FUlIoc2FpLT5iYXNlKSkgew0KPiA+ICsJCXJldCA9
IFBUUl9FUlIoc2FpLT5iYXNlKTsNCj4gPiArCQlyZXR1cm4gcmV0Ow0KPiA+DQo+IGNvdWxkIGJl
Og0KPiAJCXJldHVybiBQVFJfRVJSKHNhaS0+YmFzZSk7DQo+DQoNClllc++8jFRoaXMgbG9va3Mg
YmV0dGVyLg0KDQogDQo+ID4gKyNkZWZpbmUgRlNMX1NBSV9ETUFCVUZfU0laRQkoMzIgKiAxMDI0
KQ0KPiA+ICsjZGVmaW5lIFRDRF9OVU1CRVIJCTQNCj4gPiArI2RlZmluZSBFRE1BX1BSSU9fSElH
SCAgICAgICAgICA2DQo+ID4gKw0KPiBzdHJhbmdlIGluZGVudGF0aW9uIHdpdGggbWl4ZWQgc3Bh
Y2VzIGFuZCB0YWJzLg0KPiANCg0KVGhpcyB3aWxsIGJlIHJldmlzZWQgaW4gdGhlIG5leHQgdmVy
c2lvbi4NCg0KDQoNCj4gPiArI2RlZmluZSBTQUlfQ1IyX01TRUxfTUNMSzMJKEJJVCgyNil8QklU
KDI3KSkNCj4gPg0KPiBzcGFjZXMgYXJvdW5kICd8Jz8NCj4gDQoNCkFuZCB0aGlzIHRvby4NCg0K
DQoNCg0KLS0NCkJSUywNClhpdWJvDQo=
^ permalink raw reply
* RE: [PATCHv1 8/8] Documentation: Add device tree bindings for Freescale VF610 sound.
From: Xiubo Li-B47053 @ 2013-10-18 3:27 UTC (permalink / raw)
To: Lucas Stach
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, Wang Huan-B18965,
timur@tabi.org, perex@perex.cz, Guo Shawn-R65073,
LW@KARO-electronics.de, linux@arm.linux.org.uk,
Chen Guangyu-B42378, oskar@scara.com, grant.likely@linaro.org,
devicetree@vger.kernel.org, ian.campbell@citrix.com,
pawel.moll@arm.com, swarren@wwwdotorg.org,
rob.herring@calxeda.com, broonie@kernel.org,
linux-arm-kernel@lists.infradead.org, Estevam Fabio-R49496,
lgirdwood@gmail.com, linux-kernel@vger.kernel.org,
rob@landley.net, Jin Zhengxiong-R64188, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1382003190.4093.38.camel@weser.hi.pengutronix.de>
SGksDQoNCg0KDQo+ID4gRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3NvdW5kL2Zz
bC1zZ3RsNTAwMC50eHQNCj4gPg0KPiA+IGRpZmYgLS1naXQgYS9Eb2N1bWVudGF0aW9uL2Rldmlj
ZXRyZWUvYmluZGluZ3Mvc291bmQvZnNsLXNndGw1MDAwLnR4dA0KPiA+IGIvRG9jdW1lbnRhdGlv
bi9kZXZpY2V0cmVlL2JpbmRpbmdzL3NvdW5kL2ZzbC1zZ3RsNTAwMC50eHQNCj4gPiBuZXcgZmls
ZSBtb2RlIDEwMDY0NA0KPiA+IGluZGV4IDAwMDAwMDAuLjQzZTM1MGYNCj4gPiAtLS0gL2Rldi9u
dWxsDQo+ID4gKysrIGIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3NvdW5kL2Zz
bC1zZ3RsNTAwMC50eHQNCj4gDQo+IFRoaXMgZG9jdW1lbnQgbmFtZSBpcyBvdmVybHkgZ2VuZXJp
YywgdGhlcmUgYXJlIG1vcmUgdGhhbiBvbmUgRlNMDQo+IHBsYXRmb3JtcyB3aXRoIFNHVEw1MDAw
IGNvZGVjcy4gUGxlYXNlIGluY2x1ZGUgdGhlIHZmNjEwIGhlcmUuDQo+IA0KDQpZZXMsIGl0IGlz
Lg0KDQpUaGlzIHdpbGwgYmUgcmVuYW1lZCB0byAiZnNsX3ZmNjEwX2F1ZGlvX3NndDE1MDAwLnR4
dCIgb3Igb3RoZXJzLg0KDQoNClRoYW5rcywNCi0tDQpCUlMsDQpYaXVibw0K
^ permalink raw reply
* RE: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
From: Xiubo Li-B47053 @ 2013-10-18 3:42 UTC (permalink / raw)
To: Mark Brown, Lars-Peter Clausen
Cc: mark.rutland@arm.com, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, tiwai@suse.de, Wang Huan-B18965,
Timur Tabi, linux-kernel@vger.kernel.org, Guo Shawn-R65073,
LW@KARO-electronics.de, linux@arm.linux.org.uk,
Chen Guangyu-B42378, oskar@scara.com, grant.likely@linaro.org,
devicetree@vger.kernel.org, ian.campbell@citrix.com,
pawel.moll@arm.com, swarren@wwwdotorg.org,
rob.herring@calxeda.com, linux-arm-kernel@lists.infradead.org,
Estevam Fabio-R49496, lgirdwood@gmail.com, rob@landley.net,
Jin Zhengxiong-R64188, shawn.guo@linaro.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20131017141003.GO2443@sirena.org.uk>
> > > I understand that, but I'm trying to figure out why of_iomap() is
> > > okay for hundreds of other drivers, but not this one. I've used it
> > > dozens of times myself, without ever worrying about overlapping
> regions.
>=20
> > The driver would work fine with just of_iomap(). But the resource
> > range check comes basically for free and it does help to catch errors,
> > so I'd recommend on using it rather than not using it.
>=20
> There's also the fact that it's a devm_ function which means less error
> handling code that we can break which is nice. There's probably a case
> for an improved OF helper here...
Using this instead of of_iomap() is because "devm_" and resource range chec=
k
as Lars and Mark said, and there are more than one SAI device here which wi=
ll
be added later, maybe the resource range check is needed.
Thanks.
--
BRS
Xiubo
^ 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