* [PATCH 1/2] jump_label: Allow jump labels to be used in assembly
From: Anton Blanchard @ 2015-01-06 10:20 UTC (permalink / raw)
To: benh, paulus, mpe, mmarek, akpm, jbaron, peterz, liuj97, mingo,
mgorman
Cc: linuxppc-dev, linux-kernel, linux-kbuild
To use jump labels in assembly we need the HAVE_JUMP_LABEL define,
so we select a fallback version if the toolchain does not support
them.
Modify linux/jump_label.h so it can be included by assembly files.
We also need to add -DCC_HAVE_ASM_GOTO to KBUILD_AFLAGS.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Makefile | 1 +
include/linux/jump_label.h | 21 +++++++++++++++++----
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index ef748e1..7b83c3f 100644
--- a/Makefile
+++ b/Makefile
@@ -774,6 +774,7 @@ KBUILD_ARFLAGS := $(call ar-option,D)
# check for 'asm goto'
ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC)), y)
KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
+ KBUILD_AFLAGS += -DCC_HAVE_ASM_GOTO
endif
include $(srctree)/scripts/Makefile.extrawarn
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 98f923b6..f4de473 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -45,6 +45,12 @@
* same as using STATIC_KEY_INIT_FALSE.
*/
+#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
+# define HAVE_JUMP_LABEL
+#endif
+
+#ifndef __ASSEMBLY__
+
#include <linux/types.h>
#include <linux/compiler.h>
#include <linux/bug.h>
@@ -55,7 +61,7 @@ extern bool static_key_initialized;
"%s used before call to jump_label_init", \
__func__)
-#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
+#ifdef HAVE_JUMP_LABEL
struct static_key {
atomic_t enabled;
@@ -66,13 +72,18 @@ struct static_key {
#endif
};
-# include <asm/jump_label.h>
-# define HAVE_JUMP_LABEL
#else
struct static_key {
atomic_t enabled;
};
-#endif /* CC_HAVE_ASM_GOTO && CONFIG_JUMP_LABEL */
+#endif /* HAVE_JUMP_LABEL */
+#endif /* __ASSEMBLY__ */
+
+#ifdef HAVE_JUMP_LABEL
+#include <asm/jump_label.h>
+#endif
+
+#ifndef __ASSEMBLY__
enum jump_label_type {
JUMP_LABEL_DISABLE = 0,
@@ -203,3 +214,5 @@ static inline bool static_key_enabled(struct static_key *key)
}
#endif /* _LINUX_JUMP_LABEL_H */
+
+#endif /* __ASSEMBLY__ */
--
2.1.0
^ permalink raw reply related
* [PATCH 2/2] powerpc: Include linux/jump_label.h to get HAVE_JUMP_LABEL define
From: Anton Blanchard @ 2015-01-06 10:20 UTC (permalink / raw)
To: benh, paulus, mpe, mmarek, akpm, jbaron, peterz, liuj97, mingo,
mgorman
Cc: linuxppc-dev, linux-kernel, linux-kbuild
In-Reply-To: <1420539628-17875-1-git-send-email-anton@samba.org>
Commit 1bc9e47aa8e4 ("powerpc/jump_label: Use HAVE_JUMP_LABEL")
converted uses of CONFIG_JUMP_LABEL to HAVE_JUMP_LABEL in
some assembly files.
HAVE_JUMP_LABEL is defined in linux/jump_label.h, so we need to
include this or we always get the non jump label fallback code.
Fixes: 1bc9e47aa8e4 ("powerpc/jump_label: Use HAVE_JUMP_LABEL")
Signed-off-by: Anton Blanchard <anton@samba.org>
---
arch/powerpc/platforms/pseries/hvCall.S | 2 +-
arch/powerpc/platforms/pseries/lpar.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/hvCall.S b/arch/powerpc/platforms/pseries/hvCall.S
index ccd53f9..74b5b8e 100644
--- a/arch/powerpc/platforms/pseries/hvCall.S
+++ b/arch/powerpc/platforms/pseries/hvCall.S
@@ -7,12 +7,12 @@
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*/
+#include <linux/jump_label.h>
#include <asm/hvcall.h>
#include <asm/processor.h>
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
#include <asm/ptrace.h>
-#include <asm/jump_label.h>
.section ".text"
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index 469751d..14ac1ad 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -27,6 +27,7 @@
#include <linux/console.h>
#include <linux/export.h>
#include <linux/static_key.h>
+#include <linux/jump_label.h>
#include <asm/processor.h>
#include <asm/mmu.h>
#include <asm/page.h>
--
2.1.0
^ permalink raw reply related
* [PATCH 1/3] powerpc: ipic: Fix mcp status helper functions
From: esben.haabendal @ 2015-01-06 11:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: Esben Haabendal, linuxppc-dev, linux-kernel
From: Esben Haabendal <eha@deif.com>
Read and write the SERSR (System Error Status Register) instead of the
SERMR (System Error Mask Register), to actually get and clear the status
bits.
Signed-off-by: Esben Haabendal <eha@deif.com>
---
arch/powerpc/sysdev/ipic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
index b287337..2e41a73 100644
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -843,12 +843,12 @@ void ipic_disable_mcp(enum ipic_mcp_irq mcp_irq)
u32 ipic_get_mcp_status(void)
{
- return ipic_read(primary_ipic->regs, IPIC_SERMR);
+ return ipic_read(primary_ipic->regs, IPIC_SERSR);
}
void ipic_clear_mcp_status(u32 mask)
{
- ipic_write(primary_ipic->regs, IPIC_SERMR, mask);
+ ipic_write(primary_ipic->regs, IPIC_SERSR, mask);
}
/* Return an interrupt vector or NO_IRQ if no interrupt is pending. */
--
2.1.4
^ permalink raw reply related
* [PATCH 2/3] powerpc: Add machine_check cpu function for e300c3 cpus
From: esben.haabendal @ 2015-01-06 11:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: Esben Haabendal, linuxppc-dev, linux-kernel
In-Reply-To: <1420543620-20658-1-git-send-email-esben.haabendal@gmail.com>
From: Esben Haabendal <eha@deif.com>
Signed-off-by: Esben Haabendal <eha@deif.com>
---
arch/powerpc/kernel/cputable.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 8084059..f337666 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1133,6 +1133,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.icache_bsize = 32,
.dcache_bsize = 32,
.cpu_setup = __setup_cpu_603,
+ .machine_check = machine_check_generic,
.num_pmcs = 4,
.oprofile_cpu_type = "ppc/e300",
.oprofile_type = PPC_OPROFILE_FSL_EMB,
--
2.1.4
^ permalink raw reply related
* [PATCH 3/3] powerpc: Add .gitignore entry for built DTB files
From: esben.haabendal @ 2015-01-06 11:27 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: Esben Haabendal, linuxppc-dev, linux-kernel
In-Reply-To: <1420543620-20658-1-git-send-email-esben.haabendal@gmail.com>
From: Esben Haabendal <eha@deif.com>
Signed-off-by: Esben Haabendal <eha@deif.com>
---
arch/powerpc/boot/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
index d61c035..38e6492 100644
--- a/arch/powerpc/boot/.gitignore
+++ b/arch/powerpc/boot/.gitignore
@@ -29,6 +29,7 @@ zImage.*lds
zImage.miboot
zImage.pmac
zImage.pseries
+*.dtb
zconf.h
zlib.h
zutil.h
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 1/2] mmc: host: arasan: Add addition of-arasan quirks and add IOMMU support.
From: Suman Tripathi @ 2015-01-06 11:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree@vger.kernel.org, Jon Masters, anton, linux-mmc, chris,
patches, Don Dutile, linuxppc-dev, linux-arm-kernel
In-Reply-To: <3866536.C6OiUcuGCr@wuerfel>
Hi Arnd,
On Monday 15 December 2014 22:31:06 Suman Tripathi wrote:
> @@ -162,6 +206,16 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
> goto clk_dis_ahb;
> }
>
> +#if defined(CONFIG_IOMMU_SUPPORT)
> + sdhci_arasan->domain = iommu_domain_alloc(&amba_bustype);
> + if (!sdhci_arasan->domain) {
> + dev_err(&pdev->dev, "Unable to allocate iommu domain\n");
> + return PTR_ERR(sdhci_arasan->domain);
> + }
> +
> + iommu_attach_device(sdhci_arasan->domain, &pdev->dev);
> +#endif
> +
>
Device drivers should never care about the implementation details
of the iommu. Please change the code to use the regular dma_map_*
interfaces that will work both with and without IOMMU.
After refer to iommu binding , there is a service that allows "Remap
address space to allow devices to access physical memory ranges that
they otherwise wouldn't be capable of accessing." eg : 32-bit to 64
bit DMA .
So do we have any existing driver that uses this service ? Just asking
for suggestions.
On Tue, Dec 16, 2014 at 2:57 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Monday 15 December 2014 22:31:06 Suman Tripathi wrote:
>> @@ -162,6 +206,16 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
>> goto clk_dis_ahb;
>> }
>>
>> +#if defined(CONFIG_IOMMU_SUPPORT)
>> + sdhci_arasan->domain = iommu_domain_alloc(&amba_bustype);
>> + if (!sdhci_arasan->domain) {
>> + dev_err(&pdev->dev, "Unable to allocate iommu domain\n");
>> + return PTR_ERR(sdhci_arasan->domain);
>> + }
>> +
>> + iommu_attach_device(sdhci_arasan->domain, &pdev->dev);
>> +#endif
>> +
>>
>
> Device drivers should never care about the implementation details
> of the iommu. Please change the code to use the regular dma_map_*
> interfaces that will work both with and without IOMMU.
>
> Arnd
--
Thanks,
with regards,
Suman Tripathi
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and contains information
that is confidential and proprietary to Applied Micro Circuits Corporation or its subsidiaries.
It is to be used solely for the purpose of furthering the parties' business relationship.
All unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message.
^ permalink raw reply
* Re: [PATCH v3 2/2] powerpc/8xx: use _PAGE_RO instead of _PAGE_RW
From: Joakim Tjernlund @ 2015-01-06 13:05 UTC (permalink / raw)
To: christophe.leroy@c-s.fr
Cc: linux-kernel@vger.kernel.org, paulus@samba.org,
scottwood@freescale.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <54AB88C2.7040901@c-s.fr>
On Tue, 2015-01-06 at 08:03 +0100, leroy christophe wrote:
> Le 05/01/2015 19:12, Joakim Tjernlund a =E9crit :
> > On Mon, 2014-12-22 at 11:14 +0100, Christophe Leroy wrote:
> > > On powerpc 8xx, in TLB entries, 0x400 bit is set to 1 for read-only p=
ages
> > > and is set to 0 for RW pages. So we should use _PAGE_RO instead of _P=
AGE_RW
> > >=20
> > > Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> > Hi Christophe, been meaning to look over all you recent 8xx MMU/TLB pat=
ches
> > but got so little time :(
> >=20
> > This is very cool (not sure if there will be a performance gain) but .=
.
> I think every saved cycle is worth it.
> Before I did any modification:
> * ITLBMiss was 28 instructions.
> * DTLBMiss was 32 instructions.
> Now, (No MODULES, no CPU6, no CPU15):
> * ITLBMiss is 15 instructions
> * DTLBMiss is 24 instructions
I only meant this patch, sorry for not being explicit about that.
> > >=20
> > >=20
> > > diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h b/arch/powerpc/=
include/asm/pgtable-ppc32.h
> > > index caf094a..b4e0c3b 100644
> > > --- a/arch/powerpc/include/asm/pgtable-ppc32.h
> > > +++ b/arch/powerpc/include/asm/pgtable-ppc32.h
> > > @@ -178,9 +178,10 @@ static inline unsigned long pte_update(pte_t *p,
> > > andc %1,%0,%5\n\
> > > or %1,%1,%6\n\
> > > /* 0x200 =3D=3D Extended encoding, bit 22 */ \
> > > - /* Bit 22 has to be 1 if neither _PAGE_USER nor _PAGE_RW are =
set */ \
> > > + /* Bit 22 has to be 1 when _PAGE_USER is unset and _PAGE_RO i=
s set */ \
> > > rlwimi %1,%1,32-2,0x200\n /* get _PAGE_USER */ \
> > > - rlwinm %3,%1,32-1,0x200\n /* get _PAGE_RW */ \
> > > + rlwinm %3,%1,32-1,0x200\n /* get _PAGE_RO */ \
> > > + xori %3,%3,0x200\n \
> > > or %1,%3,%1\n\
> > > xori %1,%1,0x200\n"
> > > " stwcx. %1,0,%4\n\
> > ... here I expected to loose the existing xori insn instead of adding o=
ne?
> >=20
> >=20
> Well, I could have xored the PAGE_USER bit instead, but in that case, it
> is not anymore an 'or' but an 'and' that has to be performed between the
> bits, and then all other bits must be set to 1, or the result of the 'and=
' shall be inserted using 'rlwimi'. So it would be more modifications than =
just adding an xori, and not less instructions.
>=20
I see, thanks
Jocke=
^ permalink raw reply
* RE: [PATCH 05/11] powerpc/8xx: Optimise access to swapper_pg_dir
From: David Laight @ 2015-01-06 12:08 UTC (permalink / raw)
To: 'Joakim Tjernlund', christophe.leroy@c-s.fr
Cc: scottwood@freescale.com, linuxppc-dev@lists.ozlabs.org,
paulus@samba.org, linux-kernel@vger.kernel.org
In-Reply-To: <1420482826.25047.26.camel@transmode.se>
PiBPbiBUdWUsIDIwMTQtMTItMTYgYXQgMTY6MDMgKzAxMDAsIENocmlzdG9waGUgTGVyb3kgd3Jv
dGU6DQo+ID4gQWxsIGFjY2Vzc2VkIHRvIFBHRCBlbnRyaWVzIGFyZSBkb25lIHZpYSAwKHIxMSku
DQo+ID4gQnkgdXNpbmcgbG93ZXIgcGFydCBvZiBzd2FwcGVyX3BnX2RpciBhcyBsb2FkIGluZGV4
IHRvIHIxMSwgd2UgY2FuIHJlbW92ZSB0aGUNCj4gPiBvcmkgaW5zdHJ1Y3Rpb24uDQo+ID4NCj4g
PiBTaWduZWQtb2ZmLWJ5OiBDaHJpc3RvcGhlIExlcm95IDxjaHJpc3RvcGhlLmxlcm95QGMtcy5m
cj4NCj4gDQo+IE5pY2UgOikNCj4gQWNrZWQtYnk6IEpvYWtpbSBUamVybmx1bmQgPGpvYWtpbS50
amVybmx1bmRAdHJhbnNtb2RlLnNlPg0KPiANCj4gPg0KPiA+IC0tLQ0KPiA+ICBhcmNoL3Bvd2Vy
cGMva2VybmVsL2hlYWRfOHh4LlMgfCAyMiArKysrKysrKysrLS0tLS0tLS0tLS0tDQo+ID4gIDEg
ZmlsZSBjaGFuZ2VkLCAxMCBpbnNlcnRpb25zKCspLCAxMiBkZWxldGlvbnMoLSkNCj4gPg0KPiA+
IGRpZmYgLS1naXQgYS9hcmNoL3Bvd2VycGMva2VybmVsL2hlYWRfOHh4LlMgYi9hcmNoL3Bvd2Vy
cGMva2VybmVsL2hlYWRfOHh4LlMNCj4gPiBpbmRleCBhZTA1ZjI4Li5hYTQ1MjI1IDEwMDY0NA0K
PiA+IC0tLSBhL2FyY2gvcG93ZXJwYy9rZXJuZWwvaGVhZF84eHguUw0KPiA+ICsrKyBiL2FyY2gv
cG93ZXJwYy9rZXJuZWwvaGVhZF84eHguUw0KPiA+IEBAIC0zMjIsMTMgKzMyMiwxMiBAQCBJbnN0
cnVjdGlvblRMQk1pc3M6DQo+ID4gICAgICAgICBtZnNwciAgIHIxMSwgU1BSTl9NX1RXLyogR2V0
IGxldmVsIDEgdGFibGUgYmFzZSBhZGRyZXNzICovDQo+ID4gICNpZmRlZiBDT05GSUdfTU9EVUxF
Uw0KPiA+ICAgICAgICAgYmVxICAgICAzZg0KPiA+IC0gICAgICAgbGlzICAgICByMTEsIChzd2Fw
cGVyX3BnX2Rpci1QQUdFX09GRlNFVClAaA0KPiA+IC0gICAgICAgb3JpICAgICByMTEsIHIxMSwg
KHN3YXBwZXJfcGdfZGlyLVBBR0VfT0ZGU0VUKUBsDQo+ID4gKyAgICAgICBsaXMgICAgIHIxMSwg
KHN3YXBwZXJfcGdfZGlyLVBBR0VfT0ZGU0VUKUBoYQ0KPiA+ICAzOg0KPiA+ICAjZW5kaWYNCj4g
PiAgICAgICAgIC8qIEluc2VydCBsZXZlbCAxIGluZGV4ICovDQo+ID4gICAgICAgICBybHdpbWkg
IHIxMSwgcjEwLCAzMiAtICgoUEFHRV9TSElGVCAtIDIpIDw8IDEpLCAoUEFHRV9TSElGVCAtIDIp
IDw8IDEsIDI5DQo+ID4gLSAgICAgICBsd3ogICAgIHIxMSwgMChyMTEpLyogR2V0IHRoZSBsZXZl
bCAxIGVudHJ5ICovDQo+ID4gKyAgICAgICBsd3ogICAgIHIxMSwgKHN3YXBwZXJfcGdfZGlyLVBB
R0VfT0ZGU0VUKUBsKHIxMSkvKiBHZXQgdGhlIGxldmVsIDEgZW50cnkgKi8NCj4gPg0KDQpPbiB0
aGUgZmFjZSBvZiBpdCB0aGF0IGZyYWdtZW50IGRvZXNuJ3QgbG9vayByaWdodCB3aGVuIENPTkZJ
R19NT0RVTEVTIGlzIHVuZGVmaW5lZC4NCg0KCURhdmlkDQoNCg==
^ permalink raw reply
* Re: [PATCH v6 1/4] tools/perf: support parsing parameterized events
From: Arnaldo Carvalho de Melo @ 2015-01-06 13:26 UTC (permalink / raw)
To: Jiri Olsa
Cc: peterz, linux-kernel, Paul Mackerras, dev, Sukadev Bhattiprolu,
linuxppc-dev
In-Reply-To: <20150106094220.GB19868@krava.brq.redhat.com>
Em Tue, Jan 06, 2015 at 10:42:20AM +0100, Jiri Olsa escreveu:
> On Tue, Dec 23, 2014 at 11:58:50AM -0800, Sukadev Bhattiprolu wrote:
> > From a24b480ff54381a7e092597864cf615162afdd60 Mon Sep 17 00:00:00 2001
> > From: Cody P Schafer <cody@linux.vnet.ibm.com>
> > Date: Wed, 24 Sep 2014 12:27:15 -0700
> > Subject: [PATCH 1/4] tools/perf: support parsing parameterized events
> >
> > Enable event specification like:
> >
> > pmu/event_name,param1=0x1,param2=0x4/
> >
> > Assuming that
> >
> > /sys/bus/event_source/devices/pmu/events/event_name
> >
> > Contains something like
> >
> > param2=?,bar=1,param1=?
> >
> > Changelog[v6]:
> > [Jiri Olsa] Add a check to make sure that sysfs entries with
> > parameters exactly match '=?'.
> >
> > Changelog[v4]:
> > [Jiri Olsa] Merge to recent perf-core and fix a small conflict.
> >
> > Changelog[v3]:
> > [Jiri Olsa] If the sysfs event file specifies 'param=val', make the
> > usage 'hv_24x7/event,param=123/' rather than 'hv_24x7/event,val=123/'.
>
> Acked-by: Jiri Olsa <jolsa@kernel.org>
>
> I'm ok with whole patchset, with some nits for patch 2
> that I've already sent out..
>
> Would you mind sending v7 so we avoid confusion for Arnaldo
> what to pick up?
Yes, please, I'm trying to pick up what has accumulated over the
holidays,
- Arnaldo
^ permalink raw reply
* Re: [PATCH 05/11] powerpc/8xx: Optimise access to swapper_pg_dir
From: leroy christophe @ 2015-01-06 13:27 UTC (permalink / raw)
To: David Laight, 'Joakim Tjernlund'
Cc: scottwood@freescale.com, linuxppc-dev@lists.ozlabs.org,
paulus@samba.org, linux-kernel@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CAC1765@AcuExch.aculab.com>
Le 06/01/2015 13:08, David Laight a écrit :
>> On Tue, 2014-12-16 at 16:03 +0100, Christophe Leroy wrote:
>>> All accessed to PGD entries are done via 0(r11).
>>> By using lower part of swapper_pg_dir as load index to r11, we can remove the
>>> ori instruction.
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>> Nice :)
>> Acked-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
>>
>>> ---
>>> arch/powerpc/kernel/head_8xx.S | 22 ++++++++++------------
>>> 1 file changed, 10 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
>>> index ae05f28..aa45225 100644
>>> --- a/arch/powerpc/kernel/head_8xx.S
>>> +++ b/arch/powerpc/kernel/head_8xx.S
>>> @@ -322,13 +322,12 @@ InstructionTLBMiss:
>>> mfspr r11, SPRN_M_TW/* Get level 1 table base address */
>>> #ifdef CONFIG_MODULES
>>> beq 3f
>>> - lis r11, (swapper_pg_dir-PAGE_OFFSET)@h
>>> - ori r11, r11, (swapper_pg_dir-PAGE_OFFSET)@l
>>> + lis r11, (swapper_pg_dir-PAGE_OFFSET)@ha
>>> 3:
>>> #endif
>>> /* Insert level 1 index */
>>> rlwimi r11, r10, 32 - ((PAGE_SHIFT - 2) << 1), (PAGE_SHIFT - 2) << 1, 29
>>> - lwz r11, 0(r11)/* Get the level 1 entry */
>>> + lwz r11, (swapper_pg_dir-PAGE_OFFSET)@l(r11)/* Get the level 1 entry */
>>>
> On the face of it that fragment doesn't look right when CONFIG_MODULES is undefined.
>
> David
>
I'm not sure I understand what you mean.
The other part of the patch adds the following:
+ li r5, (swapper_pg_dir-PAGE_OFFSET)@l
+ sub r4, r4, r5
r4 is the value put into SPRN_M_TW, so I don't see what may be wrong.
Christophe
^ permalink raw reply
* Re: [PATCH 1/2] mmc: host: arasan: Add addition of-arasan quirks and add IOMMU support.
From: Arnd Bergmann @ 2015-01-06 13:55 UTC (permalink / raw)
To: linux-arm-kernel
Cc: devicetree@vger.kernel.org, Suman Tripathi, Jon Masters, anton,
linux-mmc, chris, patches, Don Dutile, linuxppc-dev
In-Reply-To: <CAOHikRCV7RaxJz-A_s6g++ueg3CDe9Jrqcog1Lc2_+KXR9QqnQ@mail.gmail.com>
On Tuesday 06 January 2015 17:10:29 Suman Tripathi wrote:
> Hi Arnd,
> > On Monday 15 December 2014 22:31:06 Suman Tripathi wrote:
> > > @@ -162,6 +206,16 @@ static int sdhci_arasan_probe(struct
> > > platform_device *pdev)> > >
> > > goto clk_dis_ahb;
> > >
> > > }
> > >
> > > +#if defined(CONFIG_IOMMU_SUPPORT)
> > > + sdhci_arasan->domain = iommu_domain_alloc(&amba_bustype);
> > > + if (!sdhci_arasan->domain) {
> > > + dev_err(&pdev->dev, "Unable to allocate iommu
> > > domain\n");
> > > + return PTR_ERR(sdhci_arasan->domain);
> > > + }
> > > +
> > > + iommu_attach_device(sdhci_arasan->domain, &pdev->dev);
> > > +#endif
> > > +
> >
> > Device drivers should never care about the implementation details
> > of the iommu. Please change the code to use the regular dma_map_*
> > interfaces that will work both with and without IOMMU.
>
> After refer to iommu binding , there is a service that allows "Remap
> address space to allow devices to access physical memory ranges that
> they otherwise wouldn't be capable of accessing." eg : 32-bit to 64
> bit DMA .
>
> So do we have any existing driver that uses this service ? Just asking
> for suggestions.
The interface is completely transparent to device drivers, it is
implemented as a separate 'struct dma_map_ops' that is normally
architecture independent, and that handles all sorts of DMA remapping
issues for the driver, including
- address space limits
- offsets between CPU and device addresses for the same memory
- cache flushes
- bus-level synchronization
On arm32, we currently support six sets of dma_map_ops including
two for IOMMU (coherent and noncoherent). On arm64, we currently
always use swiotlb, which solves your problem by copying memory to
bounce buffers. This is rather inefficient, and a new implementation
is being worked on, based on the arm32 implementation to support
IOMMUs in a generic way.
Arnd
^ permalink raw reply
* RE: [PATCH 05/11] powerpc/8xx: Optimise access to swapper_pg_dir
From: David Laight @ 2015-01-06 14:41 UTC (permalink / raw)
To: 'leroy christophe', 'Joakim Tjernlund'
Cc: scottwood@freescale.com, linuxppc-dev@lists.ozlabs.org,
paulus@samba.org, linux-kernel@vger.kernel.org
In-Reply-To: <54ABE2CA.8030608@c-s.fr>
From: leroy christophe
> Le 06/01/2015 13:08, David Laight a =E9crit :
> >> On Tue, 2014-12-16 at 16:03 +0100, Christophe Leroy wrote:
> >>> All accessed to PGD entries are done via 0(r11).
> >>> By using lower part of swapper_pg_dir as load index to r11, we can re=
move the
> >>> ori instruction.
> >>>
> >>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> >> Nice :)
> >> Acked-by: Joakim Tjernlund <joakim.tjernlund@transmode.se>
> >>
> >>> ---
> >>> arch/powerpc/kernel/head_8xx.S | 22 ++++++++++------------
> >>> 1 file changed, 10 insertions(+), 12 deletions(-)
> >>>
> >>> diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/hea=
d_8xx.S
> >>> index ae05f28..aa45225 100644
> >>> --- a/arch/powerpc/kernel/head_8xx.S
> >>> +++ b/arch/powerpc/kernel/head_8xx.S
> >>> @@ -322,13 +322,12 @@ InstructionTLBMiss:
> >>> mfspr r11, SPRN_M_TW/* Get level 1 table base address */
> >>> #ifdef CONFIG_MODULES
> >>> beq 3f
> >>> - lis r11, (swapper_pg_dir-PAGE_OFFSET)@h
> >>> - ori r11, r11, (swapper_pg_dir-PAGE_OFFSET)@l
> >>> + lis r11, (swapper_pg_dir-PAGE_OFFSET)@ha
> >>> 3:
> >>> #endif
> >>> /* Insert level 1 index */
> >>> rlwimi r11, r10, 32 - ((PAGE_SHIFT - 2) << 1), (PAGE_SHIFT =
- 2) << 1, 29
> >>> - lwz r11, 0(r11)/* Get the level 1 entry */
> >>> + lwz r11, (swapper_pg_dir-PAGE_OFFSET)@l(r11)/* Get the le=
vel 1 entry */
> >>>
> > On the face of it that fragment doesn't look right when CONFIG_MODULES =
is undefined.
> >
> > David
> >
> I'm not sure I understand what you mean.
>=20
> The other part of the patch adds the following:
> + li r5, (swapper_pg_dir-PAGE_OFFSET)@l
> + sub r4, r4, r5
>=20
> r4 is the value put into SPRN_M_TW, so I don't see what may be wrong.
Ok, but it is completely non-obvious.
You probably need to change some comments somewhere about what is held
in SPRN_M_TW - since it is no longer the L1 base address, but that value
offset by some 'random' amount.
David
^ permalink raw reply
* Re: [PATCH 1/2] jump_label: Allow jump labels to be used in assembly
From: Jason Baron @ 2015-01-06 15:46 UTC (permalink / raw)
To: Anton Blanchard, benh@kernel.crashing.org, paulus@samba.org,
mpe@ellerman.id.au, mmarek@suse.cz, akpm@linux-foundation.org,
peterz@infradead.org, liuj97@gmail.com, mingo@kernel.org,
mgorman@suse.de, rostedt
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-kbuild@vger.kernel.org
In-Reply-To: <1420539628-17875-1-git-send-email-anton@samba.org>
On 01/06/2015 05:20 AM, Anton Blanchard wrote:
> To use jump labels in assembly we need the HAVE_JUMP_LABEL define,
> so we select a fallback version if the toolchain does not support
> them.
>
> Modify linux/jump_label.h so it can be included by assembly files.
> We also need to add -DCC_HAVE_ASM_GOTO to KBUILD_AFLAGS.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
(adding Steven)
Acked-by: Jason Baron <jbaron@akamai.com>
The jump label stuff often gets picked up by Steve, but I guess this
could go through the powerpc tree as well...
Thanks,
-Jason
^ permalink raw reply
* Re: Build regressions/improvements in v3.19-rc3
From: Mathieu Poirier @ 2015-01-06 16:00 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev@lists.ozlabs.org, Pratik Patel,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Linux-sh list
In-Reply-To: <CAMuHMdXXw_GiaDrtwmBSExwyYQe2t2io5j3V0fCawAc64-tXrA@mail.gmail.com>
On 6 January 2015 at 02:39, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, Jan 6, 2015 at 10:36 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> JFYI, when comparing v3.19-rc3[1] to v3.19-rc2[3], the summaries are:
>> - build errors: +64/-9
>
> + /home/kisskb/slave/src/arch/arm/mm/dma-mapping.c: error:
> 'VM_ARM_DMA_CONSISTENT' undeclared (first use in this function): =>
> 1200:4, 1281:29, 1410:4
> + /home/kisskb/slave/src/arch/arm/mm/dma-mapping.c: error:
> 'atomic_pool' undeclared (first use in this function): => 1264:31
> + /home/kisskb/slave/src/arch/arm/mm/dma-mapping.c: error: implicit
> declaration of function '__in_atomic_pool'
> [-Werror=implicit-function-declaration]: => 1274:2
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
> 'L_PTE_MT_BUFFERABLE' undeclared here (not in a function): => 81:10
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
> 'L_PTE_MT_DEV_CACHED' undeclared here (not in a function): => 117:10
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
> 'L_PTE_MT_DEV_NONSHARED' undeclared here (not in a function): =>
> 108:10
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
> 'L_PTE_MT_DEV_SHARED' undeclared here (not in a function): => 103:10
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
> 'L_PTE_MT_DEV_WC' undeclared here (not in a function): => 113:10
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_MT_MASK'
> undeclared here (not in a function): => 76:11
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
> 'L_PTE_MT_MINICACHE' undeclared here (not in a function): => 94:10
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
> 'L_PTE_MT_UNCACHED' undeclared here (not in a function): => 77:10
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
> 'L_PTE_MT_WRITEALLOC' undeclared here (not in a function): => 99:10
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
> 'L_PTE_MT_WRITEBACK' undeclared here (not in a function): => 89:10
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
> 'L_PTE_MT_WRITETHROUGH' undeclared here (not in a function): => 85:10
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_RDONLY'
> undeclared here (not in a function): => 61:11
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_SHARED'
> undeclared here (not in a function): => 71:11
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_USER'
> undeclared here (not in a function): => 56:11
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'L_PTE_XN'
> undeclared here (not in a function): => 66:11
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
> 'PMD_SECT_AP_READ' undeclared here (not in a function): => 153:13
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
> 'PMD_SECT_AP_WRITE' undeclared here (not in a function): => 153:32
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'PMD_SECT_S'
> undeclared here (not in a function): => 175:11
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'PMD_SECT_XN'
> undeclared here (not in a function): => 170:11
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'PMD_SIZE'
> undeclared (first use in this function): => 279:22
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'PTRS_PER_PGD'
> undeclared (first use in this function): => 319:23
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'PTRS_PER_PMD'
> undeclared (first use in this function): => 278:18
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'PTRS_PER_PTE'
> undeclared (first use in this function): => 266:18
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: 'SECTION_SIZE'
> undeclared (first use in this function): => 285:7
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error:
> 'USER_PGTABLES_CEILING' undeclared (first use in this function): =>
> 223:13, 311:23
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: (near
> initialization for 'section_bits[0].mask'): => 153:3
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: (near
> initialization for 'section_bits[1].mask'): => 157:3
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: (near
> initialization for 'section_bits[1].val'): => 158:3
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: (near
> initialization for 'section_bits[2].mask'): => 161:3
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: (near
> initialization for 'section_bits[2].val'): => 162:3
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: (near
> initialization for 'section_bits[3].mask'): => 165:3
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: (near
> initialization for 'section_bits[3].val'): => 166:3
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: (near
> initialization for 'section_bits[4].mask'): => 170:3
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: (near
> initialization for 'section_bits[4].val'): => 171:3
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: (near
> initialization for 'section_bits[5].mask'): => 175:3
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: (near
> initialization for 'section_bits[5].val'): => 176:3
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: implicit
> declaration of function 'pmd_large'
> [-Werror=implicit-function-declaration]: => 280:3
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: implicit
> declaration of function 'pmd_none'
> [-Werror=implicit-function-declaration]: => 280:3
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: implicit
> declaration of function 'pmd_present'
> [-Werror=implicit-function-declaration]: => 280:3
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: implicit
> declaration of function 'pte_offset_kernel'
> [-Werror=implicit-function-declaration]: => 262:2
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: initializer
> element is not constant: => 158:3, 162:3, 176:3, 170:3, 157:3, 175:3,
> 161:3, 153:3, 171:3, 165:3, 166:3
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: invalid operands
> to binary * (have 'unsigned int' and 'const struct prot_bits *'): =>
> 279:20
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: invalid operands
> to binary / (have 'const struct prot_bits *' and 'long unsigned int'):
> => 311:45
> + /home/kisskb/slave/src/arch/arm/mm/dump.c: error: invalid operands
> to binary | (have 'const struct prot_bits *' and 'const struct
> prot_bits *'): => 165:30, 153:30, 166:30, 157:30, 161:30
> + /home/kisskb/slave/src/arch/arm/mm/init.c: error: 'SECTION_SIZE'
> undeclared (first use in this function): => 733:2
> + /home/kisskb/slave/src/arch/arm/mm/init.c: error: 'pmdval_t'
> undeclared here (not in a function): => 633:12
> + /home/kisskb/slave/src/arch/arm/mm/init.c: error: expected
> declaration specifiers or '...' before 'pmdval_t': => 678:7, 677:55
> + /home/kisskb/slave/src/arch/arm/mm/init.c: error: implicit
> declaration of function 'section_update'
> [-Werror=implicit-function-declaration]: => 733:2
> + /home/kisskb/slave/src/arch/arm/mm/init.c: error: unknown type
> name 'pmdval_t': => 625:2, 623:2, 624:2
>
> arm-randconfig (CONFIG_ARM_PTDUMP is broken?)
>
> + /home/kisskb/slave/src/drivers/coresight/coresight-etb10.c: error:
> implicit declaration of function 'of_get_coresight_platform_data'
> [-Werror=implicit-function-declaration]: => 430:3
> + /home/kisskb/slave/src/drivers/coresight/coresight-funnel.c:
> error: implicit declaration of function
> 'of_get_coresight_platform_data'
> [-Werror=implicit-function-declaration]: => 189:3
> + /home/kisskb/slave/src/drivers/coresight/coresight-replicator.c:
> error: implicit declaration of function
> 'of_get_coresight_platform_data'
> [-Werror=implicit-function-declaration]: => 72:3
> + /home/kisskb/slave/src/drivers/coresight/coresight-tmc.c: error:
> implicit declaration of function 'of_get_coresight_platform_data'
> [-Werror=implicit-function-declaration]: => 625:3
> + /home/kisskb/slave/src/drivers/coresight/coresight-tpiu.c: error:
> implicit declaration of function 'of_get_coresight_platform_data'
> [-Werror=implicit-function-declaration]: => 131:3
Thanks for pointing this out - I will investigate.
>
> arm-randconfig
>
> + /home/kisskb/slave/src/arch/sh/mm/cache-sh4.c: error:
> 'cached_to_uncached' undeclared (first use in this function): =>
> 99:17
> + /home/kisskb/slave/src/arch/sh/mm/cache-sh4.c: error: implicit
> declaration of function 'cpu_context'
> [-Werror=implicit-function-declaration]: => 192:2
>
> sh-randconfig
>
> + /home/kisskb/slave/src/kernel/bounds.c: error: -mcall-aixdesc must
> be big endian: => 1:0
> + /home/kisskb/slave/src/scripts/mod/devicetable-offsets.c: error:
> -mcall-aixdesc must be big endian: => 1:0
> + /home/kisskb/slave/src/scripts/mod/empty.c: error: -mcall-aixdesc
> must be big endian: => 1:0
> + <stdin>: error: -mcall-aixdesc must be big endian: => 1:0
>
> powerpc-randconfig
>
>> [1] http://kisskb.ellerman.id.au/kisskb/head/8277/ (255 out of 262 configs)
>> [3] http://kisskb.ellerman.id.au/kisskb/head/8257/ (all 262 configs)
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* RE: PROBLEM: USB isochronous urb leak on EHCI driver
From: Michael Tessier @ 2015-01-06 16:40 UTC (permalink / raw)
To: Alan Stern; +Cc: linuxppc-dev@lists.ozlabs.org, linux-usb@vger.kernel.org
In-Reply-To: <Pine.LNX.4.44L0.1501051045470.1485-100000@iolanthe.rowland.org>
> > > > Hi,
> > > >=20
> > > > I am dealing with a USB EHCI driver bug. Here is the info:
> > > >=20
> > > > My configuration:
> > > > -----------------
> > > >=20
> > > > Host: Freescale i.MX512 with ARM Cortex A8 (USB 2.0 host=20
> > > > controller) Linux kernel: 2.6.31, using EHCI USB driver
> > >
> > > As mentioned by other people, the age of that kernel makes any bug re=
port completely irrelevant. It's hard to count the number of non-trivial c=
hanges that have > been made to the isochronous code in ehci-hcd since 2.6=
.31, but there have been quite a few.
> > >
> > > > Hub: 4-PORT USB 1.1 HUB (Texas Instruments PN: tusb2046b)
> > > > Devices: 4 USB 1.1 audio codecs (Texas Instruments PN: pcm2901)
> > > >=20
> > > > Note: each codec is being used in R/W access, so with 4 codecs, I=20
> > > > have
> > > > 4 playback and 4 capture streams.
> > > >=20
> > > > My problem:
> > > > -----------
> > > >=20
> > > > I have usb urb leaks when connecting more than 1 codec to the USB=20
> > > > 1.1 Hub.
> > >
> > > What do you mean by "urb leak"? Normally, people use the word "leak"=
=20
> > > to refer to memory that is dynamically allocated and never deallocate=
d, but you seem to mean something else.
> >=20
> > You are right. What I mean by leak is the following: At application=20
> > level, all my calls to "Read" or "Write" operation to the codec driver=
=20
> > will return with the correct amount of bytes read/written, with a=20
> > "choppy" sound. Then when looking at lower levels:
> >=20
> > snd_pcm_oss_write (pcm_oss.c) -> OK
> > snd_pcm_lib_write (pcm_lib.c) -> OK
> > usb_submit_urb (urb.c) -> FAIL with 3 codecs
> >=20
> > The "FAIL" here indicates that the total amount of bytes transferred=20
> > does not correspond to what was expected. And indeed the sound is=20
> > "choppy" when using more than a certain amount of bandwidth. However=20
> > this amount of bandwidth is higher when connecting only 1 codec with=20
> > different settings (48khz-stereo 16-bits instead of 32 khz-mono=20
> > 16-bits).So at some point it looks like the bug is in the scheduler, on=
ly with several isochronous links.
>=20
> Agreed.
>=20
> > > The amount of bandwidth available is usually not as much of an issue=
=20
> > > as the ability of the scheduling alogorithm to divide the bandwidth a=
mong the streams. The algorithm is not very smart and it often runs into a=
wall even when lots of physical bandwidth is still available.
> >=20
> > That is interresting, however, I have an older kernel running an OHCI=20
> > driver which is able to handle 4 codecs. Same usb hardware (codecs and=
=20
> > hub), but older kernel on a different CPU, with much less power. This=20
> > makes me believe that there's a solution to make it work...
>=20
> Of course there is: Install an OHCI host controller and use it to drive y=
our codecs. It should work fine.
>=20
> The periodic scheduling algorithm for OHCI is very different from the alg=
orithm for EHCI.
According to your knowledge, how much time would you think it takes to
change the EHCI driver with an OHCI one? And can you tell if the OHCI drive=
r
will work on my hardware given that the Host controller of the i.MX512 is
a USB2.0 host controller? (OHCI was implemented for USB 1.x from what I
understand) I tried to do so several days ago with the built-in configurato=
r
(I am using "ltib"), but the configurator does not allow selecting the
OHCI driver; I tried manually but it turned into compiler errors...
>=20
> > > How does your hardware connect the host controller to a full-speed=20
> > > device? Is there an internal hub (Intel motherboards have used this=
=20
> > > approach)? Is there a companion USB-1.1 controller (older motherboar=
ds from Intel and other companys have used this approach)? Does the EHCI c=
ontroller have a built-in Transaction Translator (some SOC systems use this=
approach)?
> >=20
> > The CPU is a Freescale i.MX512, with 3 USB 2.0 Host controllers. My=20
> > hub is connected to the main CPU board with a standard USB cable, so=20
> > it's easy to swap my 4-port hub from a USB 1.1 to a USB 2.0. My codecs=
=20
> > are always the same: USB 1.1 Texas Instruments PN# pcm2901. I don't=20
> > believe there's a built-in Transaction Translator. How can I check that=
?
>=20
> You can tell by seeing what shows up in the "lsusb -t" output when you pl=
ug in the USB-1.1 hub. If the hub's parent is the EHCI controller then the=
re must be a built-in TT.
>=20
> Also, if you enable CONFIG_USB_DEBUG in your kernel then the dmesg log fo=
r boot-up should say whether or not the controller has a built-in TT.
>=20
> > > > Question:
> > > > ---------
> > > >=20
> > > > Before attempting to upgrade to an earlier kernel driver (this is
> > >
> > > "upgrade to an earlier kernel driver" is a contradiction in terms. =20
> > > Moving to an earlier driver would be a _downgrade_.
> >=20
> > Sorry, I meant to say "newer"...
> >=20
> > > > a fairly big amount of work), I would really like to know if this=20
> > > > problem would still be in the 3.x kernels. Has anyone seen that=20
> > > > issue in 3.x kernels?
> > >
> > > It depends a lot on the system hardware. Many people are using USB=20
> > > audio in 3.x kernels with no problem. On the other hand, some people=
have reported a bug (quite different from yours) so recently that the patc=
h to fix it has not yet been merged.
> >=20
> > I understand. However, if one could test the following with a 3.x kerne=
l:
> > - CPU with USB 2.0 Host controller (using EHCI-hcd driver)
> > - 4-port USB 1.1 Hub
> > - 4x USB codecs (configured at 32khz-mono, 16-bits audio)
> >=20
> > Then try to stream audio on each of the 4 codecs at the same time=20
> > (this includes one Read and one Write stream on each codec, so total of=
4 "Read"
> > and 4 "Write" streams. Then listen to the output...
>=20
> The result is likely to depend on what other USB hardware is attached.
>=20
> > If sound is ok when using only 1 codec and becomes choppy when adding=20
> > a second codec, then it means that this issue is still in the 3.x=20
> > kernel. This answer will tell me if it is worth working on using a newe=
r kernel or not.
> > I have to say that I'm not a linux expert, so I see the migration to a=
=20
> > newer kernel as a quite big amount of work...
>=20
> Why don't you try this yourself? It's easy to do; borrow a regular PC wi=
th a USB-2 host controller, boot it from a Live-CD version of Linux, plug i=
n your hub with the codecs, and see what happens.
Good point. I'll try that for sure. This will at least let me know if this
issue has been corrected in the latest kernel.
Michael Tessier
^ permalink raw reply
* RE: PROBLEM: USB isochronous urb leak on EHCI driver
From: Alan Stern @ 2015-01-06 16:48 UTC (permalink / raw)
To: Michael Tessier; +Cc: linuxppc-dev@lists.ozlabs.org, linux-usb@vger.kernel.org
In-Reply-To: <66A26A9AA227D947AF088537F041526E2009B9@VSVR-EX10-MB1.pocatec.com>
On Tue, 6 Jan 2015, Michael Tessier wrote:
> > > That is interresting, however, I have an older kernel running an OHCI
> > > driver which is able to handle 4 codecs. Same usb hardware (codecs and
> > > hub), but older kernel on a different CPU, with much less power. This
> > > makes me believe that there's a solution to make it work...
> >
> > Of course there is: Install an OHCI host controller and use it to drive your codecs. It should work fine.
> >
> > The periodic scheduling algorithm for OHCI is very different from the algorithm for EHCI.
>
> According to your knowledge, how much time would you think it takes to
> change the EHCI driver with an OHCI one?
I don't understand the question.
> And can you tell if the OHCI driver
> will work on my hardware given that the Host controller of the i.MX512 is
> a USB2.0 host controller? (OHCI was implemented for USB 1.x from what I
> understand)
The OHCI driver works with OHCI hardware and the EHCI driver works with
EHCI hardware. OHCI is USB-1.1 and EHCI is USB-2. They are not
interchangeable.
> I tried to do so several days ago with the built-in configurator
> (I am using "ltib"), but the configurator does not allow selecting the
> OHCI driver; I tried manually but it turned into compiler errors...
It looks like the configurator is smart; it won't let you select the
wrong driver for your hardware.
Alan Stern
^ permalink raw reply
* RE: PROBLEM: USB isochronous urb leak on EHCI driver
From: Michael Tessier @ 2015-01-06 16:50 UTC (permalink / raw)
To: Fabio Estevam
Cc: linuxppc-dev@lists.ozlabs.org, Alan Stern,
linux-usb@vger.kernel.org
In-Reply-To: <CAOMZO5DESCa3BOYwv0rAkoWLgTYwDdrYkNbr_jjW30s9UfR5RA@mail.gmail.com>
DQo+ID4gSWYgc291bmQgaXMgb2sgd2hlbiB1c2luZyBvbmx5IDEgY29kZWMgYW5kIGJlY29tZXMg
Y2hvcHB5IHdoZW4gYWRkaW5nIA0KPiA+IGEgc2Vjb25kIGNvZGVjLCB0aGVuIGl0IG1lYW5zIHRo
YXQgdGhpcyBpc3N1ZSBpcyBzdGlsbCBpbiB0aGUgMy54IA0KPiA+IGtlcm5lbC4gVGhpcyBhbnN3
ZXIgd2lsbCB0ZWxsIG1lIGlmIGl0IGlzIHdvcnRoIHdvcmtpbmcgb24gdXNpbmcgYSBuZXdlciBr
ZXJuZWwgb3Igbm90Lg0KPiA+IEkgaGF2ZSB0byBzYXkgdGhhdCBJJ20gbm90IGEgbGludXggZXhw
ZXJ0LCBzbyBJIHNlZSB0aGUgbWlncmF0aW9uIHRvIGEgDQo+ID4gbmV3ZXIga2VybmVsIGFzIGEg
cXVpdGUgYmlnIGFtb3VudCBvZiB3b3JrLi4uDQo+DQo+IFdlIGhhdmUgc3VwcG9ydCBmb3IgbXg1
MSBvbiB0aGUgbGF0ZXN0IGtlcm5lbC4gQWxsIHlvdSBuZWVkIHRvIGRvIGlzIHRvIGRlc2NyaWJl
IHlvdXIgaGFyZHdhcmUgb24gYSBkZXZpY2UgdHJlZSBmaWxlLiBZb3UgY2FuIHJlZmVyIHRvIGFy
Y2gvYXJtL2Jvb3QvZHRzL2lteDUxLWJhYmJhZ2UuZHRzIGFzIGFuIGV4YW1wbGUuDQo+DQo+IFNo
b3VsZCBiZSBzaW1wbGUgZm9yIHlvdSB0byBtYWtlIHN1Y2ggdGVzdCB3aXRoIHRoZSBsYXRlc3Qg
a2VybmVsLg0KDQpJJ2xsIHRyeSB0byBkbyBzby4gTXkgbWFpbiBjb25jZXJuIGlzIHRoYXQgZXZl
biBpZiBpdCBoYXMgYmVlbiBjb3JyZWN0ZWQNCmluIHRoZSBsYXN0IGtlcm5lbCwgSSdtIG5vdCBm
cmVlIHRvIGp1c3QgdXNlIHRoZSBsYXN0IGtlcm5lbDsgb3VyIGN1c3RvbWVycw0KYWxyZWFkeSBo
YXZlIHVuaXRzIGluIHRoZWlyIGhhbmRzLCBhbmQgdGhleSBib3VnaHQgdXMgYSAiRm9ybSBGaXQg
JiBGdW5jdGlvbiINCnBsYXR0Zm9ybS4gV2UgaGF2ZSBhIGh1Z2UgYnVuY2ggb2YgZG9jdW1lbnRh
dGlvbiBjb21pbmcgd2l0aCBlYWNoIGRlbGl2ZXJhYmxlDQoocGFydCBvZiBhbiBJU08gcHJvY2Vz
cywgZm9sbG93aW5nIElFRUUgc29mdHdhcmUgc3RhbmRhcmRzKS4gU28gZm9yIHRoZQ0KY29tcGFu
eSwgbWlncmF0aW5nIHRvIHRoZSBsYXRlc3Qga2VybmVsIGlzIHRoZSBsYXN0IHJlc29ydCBiZWNh
dXNlIG9mIHRoZQ0KYW1vdW50IG9mIHdvcmsgaXQgd291bGQgcmVxdWlyZS4gVGhhbmtzIGZvciB0
aGUgaWRlYSwgSSdsbCBsZXQgeW91IGtub3cuDQoNCk1pY2hhZWwgVGVzc2llcg0K
^ permalink raw reply
* RE: PROBLEM: USB isochronous urb leak on EHCI driver
From: Michael Tessier @ 2015-01-06 17:38 UTC (permalink / raw)
To: Alan Stern; +Cc: linuxppc-dev@lists.ozlabs.org, linux-usb@vger.kernel.org
In-Reply-To: <Pine.LNX.4.44L0.1501061144320.1602-100000@iolanthe.rowland.org>
> > > > That is interresting, however, I have an older kernel running an=20
> > > > OHCI driver which is able to handle 4 codecs. Same usb hardware=20
> > > > (codecs and hub), but older kernel on a different CPU, with much=20
> > > > less power. This makes me believe that there's a solution to make i=
t work...
> > >=20
> > > Of course there is: Install an OHCI host controller and use it to dri=
ve your codecs. It should work fine.
What do you mean by that? The host controller is embedded in the i.MX CPU..=
.
Changing the CPU is not really an option to me. Unless I am missing
something?
> > >=20
> > > The periodic scheduling algorithm for OHCI is very different from the=
algorithm for EHCI.
> >=20
> > According to your knowledge, how much time would you think it takes to=
=20
> > change the EHCI driver with an OHCI one?
>
> I don't understand the question.
>
> > And can you tell if the OHCI driver
> > will work on my hardware given that the Host controller of the i.MX512=
=20
> > is a USB2.0 host controller? (OHCI was implemented for USB 1.x from=20
> > what I
> > understand)
>
> The OHCI driver works with OHCI hardware and the EHCI driver works with E=
HCI hardware. OHCI is USB-1.1 and EHCI is USB-2. They are not interchange=
able.
That was what I thought first...
>
> > I tried to do so several days ago with the built-in configurator (I am=
=20
> > using "ltib"), but the configurator does not allow selecting the OHCI=20
> > driver; I tried manually but it turned into compiler errors...
>
> It looks like the configurator is smart; it won't let you select the wron=
g driver for your hardware.
>
> Alan Stern
^ permalink raw reply
* [PATCH] coresight: Fixing wrong #ifdef/#endif placement
From: mathieu.poirier @ 2015-01-06 17:54 UTC (permalink / raw)
To: geert
Cc: mathieu.poirier, linux-sh, pratikp, linux-kernel, linuxppc-dev,
linux-arm-kernel
From: Mathieu Poirier <mathieu.poirier@linaro.org>
Fixing problem reported by:
https://lkml.org/lkml/2015/1/6/86
The #ifdef/#endif is wrong and prevents the stub of function
of_get_coresight_platform_data() from being visible when
CONFIG_OF is not defined.
Moving CONFIG_OF condition out of CONFIG_CORESIGHT, making
them both independent.
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
---
include/linux/coresight.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/coresight.h b/include/linux/coresight.h
index 5d3c54311f7a..4404033ee879 100644
--- a/include/linux/coresight.h
+++ b/include/linux/coresight.h
@@ -239,10 +239,6 @@ extern void coresight_disable(struct coresight_device *csdev);
extern int coresight_is_bit_set(u32 val, int position, int value);
extern int coresight_timeout(void __iomem *addr, u32 offset,
int position, int value);
-#ifdef CONFIG_OF
-extern struct coresight_platform_data *of_get_coresight_platform_data(
- struct device *dev, struct device_node *node);
-#endif
#else
static inline struct coresight_device *
coresight_register(struct coresight_desc *desc) { return NULL; }
@@ -254,10 +250,14 @@ static inline int coresight_is_bit_set(u32 val, int position, int value)
{ return 0; }
static inline int coresight_timeout(void __iomem *addr, u32 offset,
int position, int value) { return 1; }
+#endif
+
#ifdef CONFIG_OF
+extern struct coresight_platform_data *of_get_coresight_platform_data(
+ struct device *dev, struct device_node *node);
+#else
static inline struct coresight_platform_data *of_get_coresight_platform_data(
struct device *dev, struct device_node *node) { return NULL; }
#endif
-#endif
#endif
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/2] jump_label: Allow jump labels to be used in assembly
From: Steven Rostedt @ 2015-01-06 17:48 UTC (permalink / raw)
To: Anton Blanchard
Cc: mmarek, linux-kbuild, peterz, linux-kernel, jbaron, paulus,
mgorman, akpm, linuxppc-dev, mingo, liuj97
In-Reply-To: <1420539628-17875-1-git-send-email-anton@samba.org>
On Tue, Jan 06, 2015 at 09:20:27PM +1100, Anton Blanchard wrote:
> To use jump labels in assembly we need the HAVE_JUMP_LABEL define,
> so we select a fallback version if the toolchain does not support
> them.
>
> Modify linux/jump_label.h so it can be included by assembly files.
> We also need to add -DCC_HAVE_ASM_GOTO to KBUILD_AFLAGS.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
> Makefile | 1 +
> include/linux/jump_label.h | 21 +++++++++++++++++----
> 2 files changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index ef748e1..7b83c3f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -774,6 +774,7 @@ KBUILD_ARFLAGS := $(call ar-option,D)
> # check for 'asm goto'
> ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC)), y)
> KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
> + KBUILD_AFLAGS += -DCC_HAVE_ASM_GOTO
> endif
>
> include $(srctree)/scripts/Makefile.extrawarn
> diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
> index 98f923b6..f4de473 100644
> --- a/include/linux/jump_label.h
> +++ b/include/linux/jump_label.h
> @@ -45,6 +45,12 @@
> * same as using STATIC_KEY_INIT_FALSE.
> */
>
> +#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
> +# define HAVE_JUMP_LABEL
> +#endif
> +
> +#ifndef __ASSEMBLY__
> +
> #include <linux/types.h>
> #include <linux/compiler.h>
> #include <linux/bug.h>
> @@ -55,7 +61,7 @@ extern bool static_key_initialized;
> "%s used before call to jump_label_init", \
> __func__)
>
> -#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
> +#ifdef HAVE_JUMP_LABEL
>
> struct static_key {
> atomic_t enabled;
> @@ -66,13 +72,18 @@ struct static_key {
> #endif
> };
>
> -# include <asm/jump_label.h>
> -# define HAVE_JUMP_LABEL
> #else
> struct static_key {
> atomic_t enabled;
> };
> -#endif /* CC_HAVE_ASM_GOTO && CONFIG_JUMP_LABEL */
> +#endif /* HAVE_JUMP_LABEL */
> +#endif /* __ASSEMBLY__ */
> +
> +#ifdef HAVE_JUMP_LABEL
> +#include <asm/jump_label.h>
> +#endif
Have you tested this on other archs? Because just looking at x86, it doesn't
seem that asm/jump_label.h can handle being called in assembly.
-- Steve
> +
> +#ifndef __ASSEMBLY__
>
> enum jump_label_type {
> JUMP_LABEL_DISABLE = 0,
> @@ -203,3 +214,5 @@ static inline bool static_key_enabled(struct static_key *key)
> }
>
> #endif /* _LINUX_JUMP_LABEL_H */
> +
> +#endif /* __ASSEMBLY__ */
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* RE: PROBLEM: USB isochronous urb leak on EHCI driver
From: Alan Stern @ 2015-01-06 18:22 UTC (permalink / raw)
To: Michael Tessier; +Cc: linuxppc-dev@lists.ozlabs.org, linux-usb@vger.kernel.org
In-Reply-To: <66A26A9AA227D947AF088537F041526E2009E5@VSVR-EX10-MB1.pocatec.com>
On Tue, 6 Jan 2015, Michael Tessier wrote:
> > > > > That is interresting, however, I have an older kernel running an
> > > > > OHCI driver which is able to handle 4 codecs. Same usb hardware
> > > > > (codecs and hub), but older kernel on a different CPU, with much
> > > > > less power. This makes me believe that there's a solution to make it work...
> > > >
> > > > Of course there is: Install an OHCI host controller and use it to drive your codecs. It should work fine.
>
> What do you mean by that? The host controller is embedded in the i.MX CPU...
> Changing the CPU is not really an option to me. Unless I am missing
> something?
I didn't realize you were talking about an i.MX-based system. On a
computer with a free PCI slot, it's easy to add an OHCI controller.
iMX isn't as accomodating.
If there's no way to add an extra USB controller to your system then
the only choice is to upgrade the driver software.
Alan Stern
^ permalink raw reply
* Re: [PATCH] [v3] power/fsl: add MDIO dt binding for FMan
From: Scott Wood @ 2015-01-07 0:28 UTC (permalink / raw)
To: Xie Shaohui-B21989
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
Medve Emilian-EMMEDVE1
In-Reply-To: <DM2PR0301MB08640979E5088618D1395CFAE2580@DM2PR0301MB0864.namprd03.prod.outlook.com>
On Mon, 2015-01-05 at 05:21 -0600, Xie Shaohui-B21989 wrote:
> Hello Scott,
>
> Is this v3 OK?
>
> Best Regards,
> Shaohui Xie
> > -----Original Message-----
> > From: shh.xie@gmail.com [mailto:shh.xie@gmail.com]
> > Sent: Tuesday, December 23, 2014 3:58 PM
> > To: linuxppc-dev@lists.ozlabs.org; devicetree@vger.kernel.org; Wood Scott-B07421
> > Cc: Medve Emilian-EMMEDVE1; Xie Shaohui-B21989
> > Subject: [PATCH] [v3] power/fsl: add MDIO dt binding for FMan
> >
> > From: Shaohui Xie <Shaohui.Xie@freescale.com>
> >
> > This binding is for FMan MDIO, it covers FMan v2 & FMan v3.
> >
> > Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> > ---
> > changes in v3:
> > rephrase the 'Definition' of property 'bus-frequency', don't include the
> > property in example.
> >
> > changes in v2:
> > addressed comments from Scott in V1.
> >
> > .../devicetree/bindings/powerpc/fsl/fman.txt | 69 ++++++++++++++++++++++
> > 1 file changed, 69 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > index edeea16..737aa4c 100644
> > --- a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> > @@ -7,6 +7,7 @@ CONTENTS
> > - FMan MURAM Node
> > - FMan dTSEC/XGEC/mEMAC Node
> > - FMan IEEE 1588 Node
> > + - FMan MDIO Node
> > - Example
> >
> > =============================================================================
> > @@ -357,6 +358,69 @@ ptp-timer@fe000 {
> > };
> >
> > =============================================================================
> > +FMan MDIO Node
> > +
> > +DESCRIPTION
> > +
> > +The MDIO is a bus to which the PHY devices are connected.
> > +
> > +PROPERTIES
> > +
> > +- compatible
> > + Usage: required
> > + Value type: <stringlist>
> > + Definition: A standard property.
> > + Must include "fsl,fman-mdio" for 1 Gb/s MDIO from FMan v2.
> > + Must include "fsl,fman-xmdio" for 10 Gb/s MDIO from FMan v2.
> > + Must include "fsl,fman-memac-mdio" for 1/10 Gb/s MDIO from
> > + FMan v3.
> > +
> > +- reg
> > + Usage: required
> > + Value type: <prop-encoded-array>
> > + Definition: A standard property.
> > +
> > +- bus-frequency
> > + Usage: optional
> > + Value type: <u32>
> > + Definition: Specifies the external MDIO bus clock speed to
> > + be used, if different from the standard 2.5 MHz.
> > + This may be due to the standard speed being unsupported (e.g.
> > + due to a hardware problem), or to advertise that all relevant
> > + components in the system support a faster speed.
> > +
> > +- interrupts
> > + Usage: optional
> > + Value type: <prop-encoded-array>
> > + Definition: Event interrupt of external MDIO controller.
> > + 1 Gb/s MDIO and 10 Gb/s MDIO has one interrupt respectively.
I'm confused by "respectively" here. Does fsl,fman-memac-mdio have two
interrupts (one for 1 Gb/s and one for 10 Gb/s)? If there's only (at
most) one interrupt per MDIO controller then just delete this line.
What interrupt is used for internal MDIO? Does "optional" mean it's
used if and only if external MDIO is used, or is it optional even with
external MDIO? I see it's not present in the example -- do we not have
a real example that has the interrupt?
-Scott
^ permalink raw reply
* Re: [PATCH v3 2/2] powerpc/8xx: use _PAGE_RO instead of _PAGE_RW
From: Scott Wood @ 2015-01-07 1:21 UTC (permalink / raw)
To: leroy christophe
Cc: linux-kernel@vger.kernel.org, paulus@samba.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <54AB88C2.7040901@c-s.fr>
On Tue, 2015-01-06 at 08:03 +0100, leroy christophe wrote:
> Le 05/01/2015 19:12, Joakim Tjernlund a écrit :
> > On Mon, 2014-12-22 at 11:14 +0100, Christophe Leroy wrote:
> >> On powerpc 8xx, in TLB entries, 0x400 bit is set to 1 for read-only pages
> >> and is set to 0 for RW pages. So we should use _PAGE_RO instead of _PAGE_RW
> >>
> >> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> > Hi Christophe, been meaning to look over all you recent 8xx MMU/TLB patches
> > but got so little time :(
> >
> > This is very cool (not sure if there will be a performance gain) but ..
> I think every saved cycle is worth it.
> Before I did any modification:
> * ITLBMiss was 28 instructions.
> * DTLBMiss was 32 instructions.
> Now, (No MODULES, no CPU6, no CPU15):
> * ITLBMiss is 15 instructions
> * DTLBMiss is 24 instructions
> >>
> >>
> >> diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h b/arch/powerpc/include/asm/pgtable-ppc32.h
> >> index caf094a..b4e0c3b 100644
> >> --- a/arch/powerpc/include/asm/pgtable-ppc32.h
> >> +++ b/arch/powerpc/include/asm/pgtable-ppc32.h
> >> @@ -178,9 +178,10 @@ static inline unsigned long pte_update(pte_t *p,
> >> andc %1,%0,%5\n\
> >> or %1,%1,%6\n\
> >> /* 0x200 == Extended encoding, bit 22 */ \
> >> - /* Bit 22 has to be 1 if neither _PAGE_USER nor _PAGE_RW are set */ \
> >> + /* Bit 22 has to be 1 when _PAGE_USER is unset and _PAGE_RO is set */ \
> >> rlwimi %1,%1,32-2,0x200\n /* get _PAGE_USER */ \
> >> - rlwinm %3,%1,32-1,0x200\n /* get _PAGE_RW */ \
> >> + rlwinm %3,%1,32-1,0x200\n /* get _PAGE_RO */ \
> >> + xori %3,%3,0x200\n \
> >> or %1,%3,%1\n\
> >> xori %1,%1,0x200\n"
> >> " stwcx. %1,0,%4\n\
> > ... here I expected to loose the existing xori insn instead of adding one?
> >
> >
> Well, I could have xored the PAGE_USER bit instead, but in that case, it
> is not anymore an 'or' but an 'and' that has to be performed between the
> bits, and then all other bits must be set to 1, or the result of the
> 'and' shall be inserted using 'rlwimi'. So it would be more
> modifications than just adding an xori, and not less instructions.
How about "andc %3,%3,%1; rlwimi %1,%3,0,0x200" instead of the "xori,
or, xori" sequence?
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/8xx: reduce pressure on TLB due to context switches
From: Scott Wood @ 2015-01-07 2:52 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <20150105151453.E32BD1A4CF3@localhost.localdomain>
On Mon, 2015-01-05 at 16:14 +0100, Christophe Leroy wrote:
> + }
> + __clear_bit(id, stale_map[cpu]);
> +
> + }
Whitespace
> +
> + /* Flush the TLB for all contexts */
> + _tlbil_all();
Can you put a comment in here pointing out that for this to work on SMP,
it needs to be a global invalidation, or at least some indication on
this function that it's not SMP-safe? I realize there's no SMP 8xx, and
this is only called in place of steal_context_up(), but in case others
think of reusing this elsewhere[1]...
-Scott
[1] It might be helpful on e500 derivatives in virtualized environments
where invalidate-by-PID is expensive, depending on how often stealing
happens there.
^ permalink raw reply
* Re: [RFC] PPC: MPIC: necessary readback after EOI?
From: Scott Wood @ 2015-01-07 2:56 UTC (permalink / raw)
To: Andreas Mohr; +Cc: linuxppc-dev, Purcareata Bogdan, linux-kernel
In-Reply-To: <20150105184322.GA30255@rhlx01.hs-esslingen.de>
On Mon, 2015-01-05 at 19:43 +0100, Andreas Mohr wrote:
> [CC related ppl]
>
> On Mon, Jan 05, 2015 at 12:10:54PM -0600, Scott Wood wrote:
> > On Mon, 2015-01-05 at 18:46 +0100, Andreas Mohr wrote:
> > > Hi,
> > >
> > > > I was curious why the mpic_cpu_read(MPIC_INFO(CPU_WHOAMI)) was there in
> > > > the first place and if it's still needed. If it's still required, I
> > > > guess a better approach is to eliminate the call only if the kernel is
> > > > running on the KVM guest side, where the MPIC is emulated and no longer
> > > > requires a readback.
> > >
> > > "Why not?"
> > >
> > > A mechanism being "emulated"/"virtual" or not
> > > may not necessarily be much of a distinction (if at all!).
> > > The readback might be required
> > > to properly fulfill all requirements
> > > of a full state change protocol specification,
> > > which might easily be the case for both RS(*) and virtual hardware.
> > > And especially for virtual hardware
> > > such a "readback" event
> > > might be an extremely important "end of transaction" marker
> > > which may often be needed for freeing of temporary resources etc.
> >
> > I'm not convinced that it's required in real silicon (though there are
> > many MPIC implementations which have their own quirks...), and I'm 100%
> > sure that it's not required in the QEMU/KVM implementation of MPIC.
> >
> > It would have been nice if a code comment explained why it was doing the
> > readback... I don't see any particular need to wait for EOI completion
> > here (unlike when masking).
>
> Hmm, yeah.
>
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/history/history.git
> git checkout v2.6.11
> git blame ./ppc64/kernel/mpic.c
> git show 378193eb
> [PATCH] ppc64: Rewrite the openpic driver
>
> +/* Send an EOI */
> +static inline void mpic_eoi(struct mpic *mpic)
> +{
> + mpic_cpu_write(MPIC_CPU_EOI, 0);
> + (void)mpic_cpu_read(MPIC_CPU_WHOAMI);
> +}
>
>
> -static void openpic_eoi(void)
> -{
> - DECL_THIS_CPU;
> -
> - CHECK_THIS_CPU;
> - openpic_write(&OpenPIC->THIS_CPU.EOI, 0);
> - /* Handle PCI write posting */
> - (void)openpic_read(&OpenPIC->THIS_CPU.EOI);
> -}
>
>
> So, this does seem to be about PCI posted writes after all.
> Which begs the question whether all PIC hardware is connected via PCI bus,
> which... is not the case for emulated hardware at least, I'd think.
>
> And it's somewhat unfortunate
> that the comment in fact was removed in that commit
> (perhaps reinstate this comment in all of the various mpic.c life forms?).
But even for PCI, why do we need to wait for this write to complete?
Back in the arch/ppc days ppc_md.get_irq() was called in a loop, so it
would make sense that we'd need the next IRQ to be ready by the time
it's called again, but now that there's no get_irq() loop we shouldn't
need to wait.
-Scott
^ 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