* Re: mpc880 linux-2.6.32 slow running processes
From: Joakim Tjernlund @ 2011-01-10 16:55 UTC (permalink / raw)
To: Rafael Beims; +Cc: michael, linuxppc-dev, scottwood, RFeany
In-Reply-To: <AANLkTi=cAswFh1cFCU=nomd6yg5Ux9jK0x9h9s7f2571@mail.gmail.com>
Rafael Beims <rbeims@gmail.com> wrote on 2011/01/10 17:35:38:
> >
> > Once you have tested it and it works, please send a patch to remove the 8xx workaround.
> > Make sure Scott is cc:ed
> >
> >
>
> I tested linux-2.6.33 on my ppc880 board today, and even without the
> slowdown.patch applied, the board runs processes with good
> performance.
> It really seems that the problem is solved from linux-2.6.33 on.
>
> I'm not sure what you mean by sending a patch to remove the
> workaround. The only thing that I did in the 2.6.32 version was to
> apply the slowdown.patch attached in the message from Michael.
>
> Could you clarify please?
Yes, this part in arch/powerpc/mm/pgtable.c:
#ifdef CONFIG_8xx
/* On 8xx, cache control instructions (particularly
* "dcbst" from flush_dcache_icache) fault as write
* operation if there is an unpopulated TLB entry
* for the address in question. To workaround that,
* we invalidate the TLB here, thus avoiding dcbst
* misbehaviour.
*/
/* 8xx doesn't care about PID, size or ind args */
_tlbil_va(addr, 0, 0, 0);
#endif /* CONFIG_8xx */
Should be removed in >= 2.6.33 kernels.
My 8xx TLB work fixes this problem more efficiently.
Jocke
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: Rafael Beims @ 2011-01-10 16:35 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: michael, linuxppc-dev, scottwood, RFeany
In-Reply-To: <OFBA8894F8.FF5AA75D-ONC1257812.00773DA9-C1257812.00776196@transmode.se>
>
> Once you have tested it and it works, please send a patch to remove the 8xx workaround.
> Make sure Scott is cc:ed
>
>
I tested linux-2.6.33 on my ppc880 board today, and even without the
slowdown.patch applied, the board runs processes with good
performance.
It really seems that the problem is solved from linux-2.6.33 on.
I'm not sure what you mean by sending a patch to remove the
workaround. The only thing that I did in the 2.6.32 version was to
apply the slowdown.patch attached in the message from Michael.
Could you clarify please?
Thanks for all the help so far,
Rafael
^ permalink raw reply
* Re: [PATCH] USB: Fix USB Kconfig dependency problem on 85xx/QoirQ platforms
From: Kumar Gala @ 2011-01-10 16:22 UTC (permalink / raw)
To: Xulei Lei-B33228; +Cc: Greg KH, linux-usb, linuxppc-dev
In-Reply-To: <1294654017-32568-1-git-send-email-B33228@freescale.com>
On Jan 10, 2011, at 4:06 AM, Xulei wrote:
> For FSL PPC SoCs USB_ARCH_HAS_EHCI currently on depends on PPC_83xx.
> However that excludes support for USB on 85xx & QorIQ devices. Use
> FSL_SOC insted which will get us 83xx, 85xx, QorIQ, and 5xxx which all
> have the same USB IP on them.
>
> Signed-off-by: Xulei <B33228@freescale.com>
> Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
> ---
> drivers/usb/Kconfig | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index 6a58cb1..d513d3a 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -57,7 +57,7 @@ config USB_ARCH_HAS_OHCI
> # some non-PCI hcds implement EHCI
> config USB_ARCH_HAS_EHCI
> boolean
> - default y if PPC_83xx
> + default y if FSL_SOC
> default y if SOC_AU1200
> default y if ARCH_IXP4XX
> default y if ARCH_W90X900
> --
> 1.7.0.4
This really should have been CC'd to the USB list & maintainer.
- k
^ permalink raw reply
* Re: PCI woes with 2.6.37
From: Gary Thomas @ 2011-01-10 14:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linux PPC Development
In-Reply-To: <4D28617A.8020606@mlbassoc.com>
On 01/08/2011 06:07 AM, Gary Thomas wrote:
> On 01/08/2011 12:33 AM, Benjamin Herrenschmidt wrote:
>> On Fri, 2011-01-07 at 16:06 -0700, Gary Thomas wrote:
>>> I just tried porting my target (MPC8347) from 2.6.28 (remember
>>> that one?) to 2.6.37. Recently I tried this with 2.6.32 without
>>> a lot of success, so I thought I'd try the latest :-) The changes
>>> are very simple, pretty much just the addition of my 8347 based
>>> platform DTS.
>>>
>>> Sadly, it fails even worse than it did on 2.6.32.
>>>
>>> For some reason, although everything seems to report that the
>>> PCI bus is alive, MEM access fails completely. If I try to
>>> access various PCI devices via their memory space (I only have
>>> memory peripherals so I can't test IO space access), I get
>>> what I assume are BUS timeouts - all 0xFFFFFFFF
>>>
>>> My PCI bus is defined in DTS like this:
>>
>>> ranges =<0x02000000 0x0 0xC0000000 0xC0000000 0x0 0x20000000
>>
>> What are the #address-cells and #size-cells properties of the parent of
>> the PCI controller node ?
>>
>> PCI has 3 cells, so that accounts for the first 3 numbers of each of
>> these. That leaves only 3 numbers, so either you have #address-cells = 1
>> and #size-cells = 2 or the other way around.
>>
>> The first sounds the most plausible and would mean that you are mapping
>> c0000000 CPU space to c0000000 PCI space and the window is 512M long.
>>
>> Now of course, one needs to double check that the HW is configured that
>> way (I suppose fsl_pci.c does the configuration based on the "ranges"
>> property but I don't know for sure).
>>
>> So far nothing strikes me as totally odd.
>>
>>> 0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
>>
>> This looks reasonable too with the same assumption as above.
>>
>>> PCI: Probing PCI hardware
>>> PCI: Scanning PHB /pci@ff008500
>>> PCI: PHB IO resource = 0000000000000000-00000000000FF FFf [100]
>>> PCI: PHB MEM resource 0 = 00000000c0000000-00000000dFF FFfff [200]
>>
>> Did you edit those by hand ? :-) They look correct tho as far as I can
>> tell.
>
> Sorry, I did a little editing of the dump below (to make it more readable,
> no content changes) and "find & replace" went wild on me :-( It should
> have read:
> PCI: PHB MEM resource 0 = 00000000c0000000-00000000dfffffff [200]
>
>>
>>
>>> PCI: PHB MEM offset = 0000000000000000
>>> PCI: PHB IO offset = 00000000
>>
>> And that too.
>>
>>> probe mode: 0
>>> PCI:0000:00:0b.0 Resource 0 0000000000001000-0000000000001007 [40101] fixup...
>>> PCI:0000:00:0b.0 0000000000001000-0000000000001007
>>> PCI:0000:00:0b.0 Resource 1 0000000000001008-000000000000100b [40101] fixup...
>>> PCI:0000:00:0b.0 0000000000001008-000000000000100b
>>> PCI:0000:00:0b.0 Resource 2 0000000000001010-0000000000001017 [40101] fixup...
>>> PCI:0000:00:0b.0 0000000000001010-0000000000001017
>>> PCI:0000:00:0b.0 Resource 3 0000000000001018-000000000000101b [40101] fixup...
>>> PCI:0000:00:0b.0 0000000000001018-000000000000101b
>>> PCI:0000:00:0b.0 Resource 4 0000000000001020-000000000000102f [40101] fixup...
>>> PCI:0000:00:0b.0 0000000000001020-000000000000102f
>>> PCI:0000:00:0b.0 Resource 5 0000000000100000-00000000001001ff [40200] fixup...
>>> PCI:0000:00:0b.0 0000000000100000-00000000001001ff
>>> PCI:0000:00:0b.0 Resource 6 0000000000000000-000000000007FF FF [4e200] is unassigned
>>> PCI:0000:00:0c.0 Resource 0 0000000004000000-0000000007FF FFff [40200] fixup...
>>> PCI:0000:00:0c.0 0000000004000000-0000000007FF FFff
>>> PCI: Fixup bus devices 0 (PHB)
>>> PCI: Try to map irq for 0000:00:0b.0...
>>> Got one, spec 2 cells (0x00000016 0x00000008...) on /soc8349@ff000000/pic@700
>>> Mapped to linux irq 22
>>> PCI: Try to map irq for 0000:00:0c.0...
>>> Got one, spec 2 cells (0x00000013 0x00000008...) on /soc8349@ff000000/pic@700
>>> Mapped to linux irq 19
>>> PCI: Allocating bus resources for 0000:00...
>>> PCI: PHB (bus 0) bridge rsrc 0: 0000000000000000-00000000000FF FFf [0x100], parent c03b5740 (PCI IO)
>>> PCI: PHB (bus 0) bridge rsrc 1: 00000000c0000000-00000000dFF FFfff [0x200], parent c03b5724 (PCI mem)
>>> PCI: Allocating 0000:00:0b.0: Resource 0: 0000000000001000..0000000000001007 [40101]
>>> PCI: Allocating 0000:00:0b.0: Resource 1: 0000000000001008..000000000000100b [40101]
>>> PCI: Allocating 0000:00:0b.0: Resource 2: 0000000000001010..0000000000001017 [40101]
>>> PCI: Allocating 0000:00:0b.0: Resource 3: 0000000000001018..000000000000101b [40101]
>>> PCI: Allocating 0000:00:0b.0: Resource 4: 0000000000001020..000000000000102f [40101]
>>> PCI: Allocating 0000:00:0b.0: Resource 5: 0000000000100000..00000000001001ff [40200]
>>> PCI: Cannot allocate resource region 5 of device 0000:00:0b.0, will remap
>>> PCI: Allocating 0000:00:0c.0: Resource 0: 0000000004000000..0000000007FF FFff [40200]
>>
>> That's huge, is this your "Coral" framebuffer ? It's clearly using a
>> different address scheme which won't fit, so the kernel decides to remap
>> it, so far so good.
>
> Indeed, the frame buffer takes 4MB
>
>>
>>> PCI: Cannot allocate resource region 0 of device 0000:00:0c.0, will remap
>>> Reserving legacy ranges for domain 0000
>>> Candidate legacy IO: [io 0x0000-0x0fff]
>>> hose mem offset: 0000000000000000
>>> hose mem res: [mem 0xc0000000-0xdFF FFfff]
>>> Local memory hole: [mem 0xc0000000-0xc01FF FFf]
>>
>> Now I can't grep the above string, what is it ? What is this "memory
>> hole" ? It covers a good part of your PCI mapping ...
>>
>>> PCI: Assigning unassigned resources...
>>> pci 0000:00:0c.0: BAR 0: assigned [mem 0xc4000000-0xc7FF FFff]
>>> pci 0000:00:0c.0: BAR 0: set to [mem 0xc4000000-0xc7FF FFff] (PCI address [0xc4000000-0xc7FF FFff])
>>
>> So you fb looks like it has now landed at c4000000, which doesn't strike
>> me as wrong nor strange so far...
>>
>>> pci 0000:00:0b.0: BAR 6: assigned [mem 0xc0200000-0xc027FF FF pref]
>>> pci 0000:00:0b.0: BAR 5: assigned [mem 0xc0280000-0xc02801ff]
>>> pci 0000:00:0b.0: BAR 5: set to [mem 0xc0280000-0xc02801ff] (PCI address [0xc0280000-0xc02801ff])
>>> ...
>>> Coral-P FB [1024x768x24] at 0xc4000000..0xc7FF FFff [0xd1100000]
>>
>> I suspect 0xd1100000 is the result of ioremap ?
>>
>>> D1100000: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
>>> D1100010: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
>>> D1100020: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
>>> D1100030: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
>>> D1100040: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
>>> D1100050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
>>> D1100060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
>>> D1100070: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
>>> ...
>>> scsi0 : sata_sil
>>> scsi1 : sata_sil
>>> ata1: SATA max UDMA/100 mmio m512@0xc0280000 tf 0xc0280080 irq 22
>>> ata2: SATA max UDMA/100 mmio m512@0xc0280000 tf 0xc02800c0 irq 22
>>> ata1: failed to resume link (SControl FFFFFFFF)
>>> ata1: SATA link down (SStatus FFFFFFFF SControl FFFFFFFF)
>>> ata2: failed to resume link (SControl FFFFFFFF)
>>> ata2: SATA link down (SStatus FFFFFFFF SControl FFFFFFFF)
>>>
>>> Things of note:
>>> * The 'local memory hole' is a space I have to steal from the PCI
>>> address space so that the Coral-P gets mapped to something other
>>> than PCI memory address 0x0 (relative). This device is dirt stupid
>>> (previously discussed) and refuses to work at 0x0
>>> * The dump after the Coral-P FB line is what it sees in it's memory
>>> space. It _should_ look something like this:
>>> C4140600: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 |................|
>>> C4140610: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 |................|
>>> C4140620: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 |................|
>>> C4140630: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 |................|
>>> C4140640: FF FF FF 00 FF FF FF 00 FF FD FF 00 FF FD FF 00 |................|
>>> C4140650: FF FD FF 00 FF FD FF 00 FF FD FF 00 FF FD FF 00 |................|
>>> Notice how byte 3 of every longword is 0x00?
>>> * The SATA device driver is failing along similar lines.
>>>
>>> Any ideas what I'm doing wrong? or what I can look at?
>>
>> I can't see anything obviously wrong in what you've pasted there, but I
>> am not familiar with fsl PCI or SoC's, so it's possible that there's
>> something there going on ... We'll have to wait for somebody from FSL to
>> have a look, unless you can find something in the doco.
>
> The curious thing is that this exact same setup works perfectly
> in 2.6.28 and near perfectly in 2.6.32. Unless something else
> changed in the PCI handling between 2.6.32 and 2.6.37, I would
> hope it work work there as well.
>
> I'll keep looking for differences between those two system versions.
I found the problem - a change I had in <2.6.32 that I hadn't
pushed forward. It seems to be related to how I have the PCI
controller setup (in RedBoot). Because of this, using these
settings in my DTS make things work properly:
ranges = <0x02000000 0x0 0x00000000 0xC0000000 0x0 0x20000000
0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
Instead of
ranges = <0x02000000 0x0 0xC0000000 0xC0000000 0x0 0x20000000
0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
Sorry for the noise (wild goose chase), but discussing it did help
me to work out some PCI issues in general.
Now that this is working, I'm trying to move to the next problem.
The system works fine, but only to a point. In this [embedded]
system, I have an SIL SATA controller on the PCI bus. On 2.6.28,
this device is rock solid. On 2.6.32 and now 2.6.37, I have issues.
Operations work on the device (connected to a SSD), but after some
arbitrary time, an operation will fail, causing the PCI bus (and
indeed the whole system) to hang. I've tried to peek in using a
BDI and once it hangs, even the BDI can't access the CPU any more.
I'm pretty lost on this one - it will execute hundreds of SATA operations
properly and then die. Turning on SATA/SCSI traces, I can see the
final operation be issued and there seems to be no substantive difference
between this operation and the previous ones that all worked. In fact
if I reset and rerun the same program, it _will_ fail but never on
the same operation :-(
Any ideas what could cause this failure? I have a similar system
that uses a different SATA controller that I'm going to try. Maybe
it's something peculiar to the SIL device as opposed to generic PCI
operations.
Thanks for any feedback
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* [PATCH] USB: Fix USB Kconfig dependency problem on 85xx/QoirQ platforms
From: Xulei @ 2011-01-10 10:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Xulei, Kumar Gala
For FSL PPC SoCs USB_ARCH_HAS_EHCI currently on depends on PPC_83xx.
However that excludes support for USB on 85xx & QorIQ devices. Use
FSL_SOC insted which will get us 83xx, 85xx, QorIQ, and 5xxx which all
have the same USB IP on them.
Signed-off-by: Xulei <B33228@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
drivers/usb/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 6a58cb1..d513d3a 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -57,7 +57,7 @@ config USB_ARCH_HAS_OHCI
# some non-PCI hcds implement EHCI
config USB_ARCH_HAS_EHCI
boolean
- default y if PPC_83xx
+ default y if FSL_SOC
default y if SOC_AU1200
default y if ARCH_IXP4XX
default y if ARCH_W90X900
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH #upstream-fixes] pata_mpc52xx: inherit from ata_bmdma_port_ops
From: Roman Fietze @ 2011-01-10 7:26 UTC (permalink / raw)
To: Tejun Heo; +Cc: linux-ide, Jeff Garzik, linuxppc-dev, Sergei Shtylyov
In-Reply-To: <20110109224820.GB26607@mtj.dyndns.org>
Hello Tejun,
On Sunday, 09.January.2011 23:48:20 Tejun Heo wrote:
> Fix it.
I can confirm that, it's fixed.
Thank's a lot. Should have looked into it, that was really a simple
fix.
Roman
--
Roman Fietze Telemotive AG Buero Muehlhausen
Breitwiesen 73347 Muehlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply
* gianfar: incorrect TCP checksum when timestamps are enabled
From: Alex Dubov @ 2011-01-10 6:22 UTC (permalink / raw)
To: linuxppc-dev
Greetings.=0A=0AI'm working on MPC8548 based board (I started with 2.6.37-r=
c7, now upgraded=0Ato post release 2.6.37 git head).=0A=0AIt so appears, th=
at when tcp timestamps are enabled (default setting)=0ATCP checksums of out=
going SYN packets are calculated incorrectly. This=0Acauses remote machines=
to reject such packets, effectively preventing any=0Auseful network use. T=
he problem is reproducible every time.=0A=0AOther protocols appear to work =
reliably (UDP/DHCP do work).=0A=0AIf tcp timestamps are disabled, checksums=
are calculated correctly.=0A=0ANetdev guys tend to think that the problem =
is with hardware checksum=0Aoffloading, the theory I'm going to test now.=
=0A=0A=0A=0A
^ permalink raw reply
* [PATCH #upstream-fixes] pata_mpc52xx: inherit from ata_bmdma_port_ops
From: Tejun Heo @ 2011-01-09 22:48 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide, linuxppc-dev, Sergei Shtylyov, Roman Fietze
In-Reply-To: <4D21FA4D.3030506@mvista.com>
pata_mpc52xx supports BMDMA but inherits ata_sff_port_ops which
triggers BUG_ON() when a DMA command is issued. Fix it.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Roman Fietze <roman.fietze@telemotive.de>
Cc: Sergei Shtylyov <sshtylyov@mvista.com>
Cc: stable@kernel.org
---
drivers/ata/pata_mpc52xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ata/pata_mpc52xx.c b/drivers/ata/pata_mpc52xx.c
index 8cc536e..d7d8026 100644
--- a/drivers/ata/pata_mpc52xx.c
+++ b/drivers/ata/pata_mpc52xx.c
@@ -610,7 +610,7 @@ static struct scsi_host_template mpc52xx_ata_sht = {
};
static struct ata_port_operations mpc52xx_ata_port_ops = {
- .inherits = &ata_sff_port_ops,
+ .inherits = &ata_bmdma_port_ops,
.sff_dev_select = mpc52xx_ata_dev_select,
.set_piomode = mpc52xx_ata_set_piomode,
.set_dmamode = mpc52xx_ata_set_dmamode,
^ permalink raw reply related
* [PATCH 1/2] powerpc/boot/dts: Install dts from the right directory
From: Ben Hutchings @ 2011-01-09 0:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras; +Cc: linuxppc-dev
The dts-installed variable is initialised using a wildcard path that
will be expanded relative to the build directory. Use the existing
variable dtstree to generate an absolute wildcard path that will work
when building in a separate directory.
Reported-by: Gerhard Pircher <gerhard_pircher@gmx.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Tested-by: Gerhard Pircher <gerhard_pircher@gmx.net> [against 2.6.32]
---
arch/powerpc/boot/Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 96deec6..8917816 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -368,7 +368,7 @@ INSTALL :=3D install
extra-installed :=3D $(patsubst $(obj)/%, $(DESTDIR)$(WRAPPER_OBJDIR)/%, =
$(extra-y))
hostprogs-installed :=3D $(patsubst %, $(DESTDIR)$(WRAPPER_BINDIR)/%, $(ho=
stprogs-y))
wrapper-installed :=3D $(DESTDIR)$(WRAPPER_BINDIR)/wrapper
-dts-installed :=3D $(patsubst $(obj)/dts/%, $(DESTDIR)$(WRAPPER_DTSDIR)/%=
, $(wildcard $(obj)/dts/*.dts))
+dts-installed :=3D $(patsubst $(dtstree)/%, $(DESTDIR)$(WRAPPER_DTSDIR)/%=
, $(wildcard $(dtstree)/*.dts))
=20
all-installed :=3D $(extra-installed) $(hostprogs-installed) $(wrapper-in=
stalled) $(dts-installed)
=20
--=20
1.7.2.3
^ permalink raw reply related
* [PATCH 2/2] powerpc/boot/Makefile: Use $(src) and $(obj) as per makefiles.txt
From: Ben Hutchings @ 2011-01-09 0:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1294532641.3283.70.camel@localhost>
$(src) and $(obj) are normally the same, but are supposed to be used
for paths under $(srctree) and $(objtree) respectively.
Also use $(dtstree) and $(wrapper) as appropriate.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
This is totally untested, so please review carefully!
Ben.
arch/powerpc/boot/Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 8917816..bd7abba 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -33,7 +33,7 @@ ifeq ($(call cc-option-yn, -fstack-protector),y)
BOOTCFLAGS +=3D -fno-stack-protector
endif
=20
-BOOTCFLAGS +=3D -I$(obj) -I$(srctree)/$(obj)
+BOOTCFLAGS +=3D -I$(obj) -I$(srctree)/$(src)
=20
DTC_FLAGS ?=3D -p 1024
=20
@@ -399,10 +399,10 @@ $(extra-installed) : $(DESTDIR)$(WRAPPER_OBJDIR)/% : =
$(obj)/% | $(DESTDIR)$(WRAP
$(hostprogs-installed) : $(DESTDIR)$(WRAPPER_BINDIR)/% : $(obj)/% | $(DES=
TDIR)$(WRAPPER_BINDIR)
$(call cmd,install_exe)
=20
-$(dts-installed) : $(DESTDIR)$(WRAPPER_DTSDIR)/% : $(srctree)/$(obj)/dts/%=
| $(DESTDIR)$(WRAPPER_DTSDIR)
+$(dts-installed) : $(DESTDIR)$(WRAPPER_DTSDIR)/% : $(dtstree)/% | $(DESTDI=
R)$(WRAPPER_DTSDIR)
$(call cmd,install_dts)
=20
-$(wrapper-installed): $(DESTDIR)$(WRAPPER_BINDIR) $(srctree)/$(obj)/wrappe=
r | $(DESTDIR)$(WRAPPER_BINDIR)
+$(wrapper-installed): $(DESTDIR)$(WRAPPER_BINDIR) $(wrapper) | $(DESTDIR)$=
(WRAPPER_BINDIR)
$(call cmd,install_wrapper)
=20
$(obj)/bootwrapper_install: $(all-installed)
--=20
1.7.2.3
^ permalink raw reply related
* Re: mpc880 linux-2.6.32 slow running processes
From: Joakim Tjernlund @ 2011-01-08 21:43 UTC (permalink / raw)
To: Rafael Beims; +Cc: michael, linuxppc-dev, scottwood, RFeany
In-Reply-To: <AANLkTinbdEc2kTVHZp3b31V6sFSqOfquUidb5BZYdgEX@mail.gmail.com>
Rafael Beims <rbeims@gmail.com> wrote on 2011/01/07 11:00:56:
>
> On Thu, Jan 6, 2011 at 2:52 PM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
>
> >
> > The 8xx tlbil_va should not be needed in recent 2.6 after I fixed t=
he 8xx TLB code
> > to workaround the dcbst bug there instead. See
> > http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;=
a=3Dcommitdiff;h=3D0a2ab51ffb8dfdf51402dcfb446629648c96bc78;hp=3D60e071=
fee994ff98c37d03a4a7c5a3f8b1e3b8e5
> >
> > Not sure what release it went into though.
> >
> > =A0Jocke
>
> I saw that the commit you mention did make it in the 2.6.33 version. =
I
> will try to boot it here and see if the problem is also solved in thi=
s
> version.
Once you have tested it and it works, please send a patch to remove the=
8xx workaround.
Make sure Scott is cc:ed=
^ permalink raw reply
* [PATCH] powerpc/mpc8xxx_gpio: simplify searching for 'fsl, qoriq-gpio' compatiable
From: Anatolij Gustschin @ 2011-01-08 15:51 UTC (permalink / raw)
To: linuxppc-dev
Commit da3ed89e7ce272ebcc918487e2a28736ca0dd6bb added
'fsl,qoriq-gpio' compatiable searching in the old way
using for_each_compatible_node(). But the driver have
previously been changed to use a struct of_device_id
compatible list passed to for_each_matching_node().
Add 'fsl,qoriq-gpio' compatiable to the existing
compatible list instead of adding another
for_each_compatible_node() loop.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
arch/powerpc/sysdev/mpc8xxx_gpio.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/mpc8xxx_gpio.c b/arch/powerpc/sysdev/mpc8xxx_gpio.c
index c48cd81..0c2a91a 100644
--- a/arch/powerpc/sysdev/mpc8xxx_gpio.c
+++ b/arch/powerpc/sysdev/mpc8xxx_gpio.c
@@ -310,6 +310,7 @@ static struct of_device_id mpc8xxx_gpio_ids[] __initdata = {
{ .compatible = "fsl,mpc8572-gpio", },
{ .compatible = "fsl,mpc8610-gpio", },
{ .compatible = "fsl,mpc5121-gpio", .data = mpc512x_irq_set_type, },
+ { .compatible = "fsl,qoriq-gpio", },
{}
};
@@ -389,9 +390,6 @@ static int __init mpc8xxx_add_gpiochips(void)
for_each_matching_node(np, mpc8xxx_gpio_ids)
mpc8xxx_add_controller(np);
- for_each_compatible_node(np, NULL, "fsl,qoriq-gpio")
- mpc8xxx_add_controller(np);
-
return 0;
}
arch_initcall(mpc8xxx_add_gpiochips);
--
1.7.1
^ permalink raw reply related
* Re: PCI woes with 2.6.37
From: Gary Thomas @ 2011-01-08 13:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Linux PPC Development
In-Reply-To: <1294472036.17779.253.camel@pasglop>
On 01/08/2011 12:33 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2011-01-07 at 16:06 -0700, Gary Thomas wrote:
>> I just tried porting my target (MPC8347) from 2.6.28 (remember
>> that one?) to 2.6.37. Recently I tried this with 2.6.32 without
>> a lot of success, so I thought I'd try the latest :-) The changes
>> are very simple, pretty much just the addition of my 8347 based
>> platform DTS.
>>
>> Sadly, it fails even worse than it did on 2.6.32.
>>
>> For some reason, although everything seems to report that the
>> PCI bus is alive, MEM access fails completely. If I try to
>> access various PCI devices via their memory space (I only have
>> memory peripherals so I can't test IO space access), I get
>> what I assume are BUS timeouts - all 0xFFFFFFFF
>>
>> My PCI bus is defined in DTS like this:
>
>> ranges =<0x02000000 0x0 0xC0000000 0xC0000000 0x0 0x20000000
>
> What are the #address-cells and #size-cells properties of the parent of
> the PCI controller node ?
>
> PCI has 3 cells, so that accounts for the first 3 numbers of each of
> these. That leaves only 3 numbers, so either you have #address-cells = 1
> and #size-cells = 2 or the other way around.
>
> The first sounds the most plausible and would mean that you are mapping
> c0000000 CPU space to c0000000 PCI space and the window is 512M long.
>
> Now of course, one needs to double check that the HW is configured that
> way (I suppose fsl_pci.c does the configuration based on the "ranges"
> property but I don't know for sure).
>
> So far nothing strikes me as totally odd.
>
>> 0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
>
> This looks reasonable too with the same assumption as above.
>
>> PCI: Probing PCI hardware
>> PCI: Scanning PHB /pci@ff008500
>> PCI: PHB IO resource = 0000000000000000-00000000000FF FFf [100]
>> PCI: PHB MEM resource 0 = 00000000c0000000-00000000dFF FFfff [200]
>
> Did you edit those by hand ? :-) They look correct tho as far as I can
> tell.
Sorry, I did a little editing of the dump below (to make it more readable,
no content changes) and "find & replace" went wild on me :-( It should
have read:
PCI: PHB MEM resource 0 = 00000000c0000000-00000000dfffffff [200]
>
>
>> PCI: PHB MEM offset = 0000000000000000
>> PCI: PHB IO offset = 00000000
>
> And that too.
>
>> probe mode: 0
>> PCI:0000:00:0b.0 Resource 0 0000000000001000-0000000000001007 [40101] fixup...
>> PCI:0000:00:0b.0 0000000000001000-0000000000001007
>> PCI:0000:00:0b.0 Resource 1 0000000000001008-000000000000100b [40101] fixup...
>> PCI:0000:00:0b.0 0000000000001008-000000000000100b
>> PCI:0000:00:0b.0 Resource 2 0000000000001010-0000000000001017 [40101] fixup...
>> PCI:0000:00:0b.0 0000000000001010-0000000000001017
>> PCI:0000:00:0b.0 Resource 3 0000000000001018-000000000000101b [40101] fixup...
>> PCI:0000:00:0b.0 0000000000001018-000000000000101b
>> PCI:0000:00:0b.0 Resource 4 0000000000001020-000000000000102f [40101] fixup...
>> PCI:0000:00:0b.0 0000000000001020-000000000000102f
>> PCI:0000:00:0b.0 Resource 5 0000000000100000-00000000001001ff [40200] fixup...
>> PCI:0000:00:0b.0 0000000000100000-00000000001001ff
>> PCI:0000:00:0b.0 Resource 6 0000000000000000-000000000007FF FF [4e200] is unassigned
>> PCI:0000:00:0c.0 Resource 0 0000000004000000-0000000007FF FFff [40200] fixup...
>> PCI:0000:00:0c.0 0000000004000000-0000000007FF FFff
>> PCI: Fixup bus devices 0 (PHB)
>> PCI: Try to map irq for 0000:00:0b.0...
>> Got one, spec 2 cells (0x00000016 0x00000008...) on /soc8349@ff000000/pic@700
>> Mapped to linux irq 22
>> PCI: Try to map irq for 0000:00:0c.0...
>> Got one, spec 2 cells (0x00000013 0x00000008...) on /soc8349@ff000000/pic@700
>> Mapped to linux irq 19
>> PCI: Allocating bus resources for 0000:00...
>> PCI: PHB (bus 0) bridge rsrc 0: 0000000000000000-00000000000FF FFf [0x100], parent c03b5740 (PCI IO)
>> PCI: PHB (bus 0) bridge rsrc 1: 00000000c0000000-00000000dFF FFfff [0x200], parent c03b5724 (PCI mem)
>> PCI: Allocating 0000:00:0b.0: Resource 0: 0000000000001000..0000000000001007 [40101]
>> PCI: Allocating 0000:00:0b.0: Resource 1: 0000000000001008..000000000000100b [40101]
>> PCI: Allocating 0000:00:0b.0: Resource 2: 0000000000001010..0000000000001017 [40101]
>> PCI: Allocating 0000:00:0b.0: Resource 3: 0000000000001018..000000000000101b [40101]
>> PCI: Allocating 0000:00:0b.0: Resource 4: 0000000000001020..000000000000102f [40101]
>> PCI: Allocating 0000:00:0b.0: Resource 5: 0000000000100000..00000000001001ff [40200]
>> PCI: Cannot allocate resource region 5 of device 0000:00:0b.0, will remap
>> PCI: Allocating 0000:00:0c.0: Resource 0: 0000000004000000..0000000007FF FFff [40200]
>
> That's huge, is this your "Coral" framebuffer ? It's clearly using a
> different address scheme which won't fit, so the kernel decides to remap
> it, so far so good.
Indeed, the frame buffer takes 4MB
>
>> PCI: Cannot allocate resource region 0 of device 0000:00:0c.0, will remap
>> Reserving legacy ranges for domain 0000
>> Candidate legacy IO: [io 0x0000-0x0fff]
>> hose mem offset: 0000000000000000
>> hose mem res: [mem 0xc0000000-0xdFF FFfff]
>> Local memory hole: [mem 0xc0000000-0xc01FF FFf]
>
> Now I can't grep the above string, what is it ? What is this "memory
> hole" ? It covers a good part of your PCI mapping ...
>
>> PCI: Assigning unassigned resources...
>> pci 0000:00:0c.0: BAR 0: assigned [mem 0xc4000000-0xc7FF FFff]
>> pci 0000:00:0c.0: BAR 0: set to [mem 0xc4000000-0xc7FF FFff] (PCI address [0xc4000000-0xc7FF FFff])
>
> So you fb looks like it has now landed at c4000000, which doesn't strike
> me as wrong nor strange so far...
>
>> pci 0000:00:0b.0: BAR 6: assigned [mem 0xc0200000-0xc027FF FF pref]
>> pci 0000:00:0b.0: BAR 5: assigned [mem 0xc0280000-0xc02801ff]
>> pci 0000:00:0b.0: BAR 5: set to [mem 0xc0280000-0xc02801ff] (PCI address [0xc0280000-0xc02801ff])
>> ...
>> Coral-P FB [1024x768x24] at 0xc4000000..0xc7FF FFff [0xd1100000]
>
> I suspect 0xd1100000 is the result of ioremap ?
>
>> D1100000: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
>> D1100010: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
>> D1100020: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
>> D1100030: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
>> D1100040: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
>> D1100050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
>> D1100060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
>> D1100070: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
>> ...
>> scsi0 : sata_sil
>> scsi1 : sata_sil
>> ata1: SATA max UDMA/100 mmio m512@0xc0280000 tf 0xc0280080 irq 22
>> ata2: SATA max UDMA/100 mmio m512@0xc0280000 tf 0xc02800c0 irq 22
>> ata1: failed to resume link (SControl FFFFFFFF)
>> ata1: SATA link down (SStatus FFFFFFFF SControl FFFFFFFF)
>> ata2: failed to resume link (SControl FFFFFFFF)
>> ata2: SATA link down (SStatus FFFFFFFF SControl FFFFFFFF)
>>
>> Things of note:
>> * The 'local memory hole' is a space I have to steal from the PCI
>> address space so that the Coral-P gets mapped to something other
>> than PCI memory address 0x0 (relative). This device is dirt stupid
>> (previously discussed) and refuses to work at 0x0
>> * The dump after the Coral-P FB line is what it sees in it's memory
>> space. It _should_ look something like this:
>> C4140600: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 |................|
>> C4140610: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 |................|
>> C4140620: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 |................|
>> C4140630: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 |................|
>> C4140640: FF FF FF 00 FF FF FF 00 FF FD FF 00 FF FD FF 00 |................|
>> C4140650: FF FD FF 00 FF FD FF 00 FF FD FF 00 FF FD FF 00 |................|
>> Notice how byte 3 of every longword is 0x00?
>> * The SATA device driver is failing along similar lines.
>>
>> Any ideas what I'm doing wrong? or what I can look at?
>
> I can't see anything obviously wrong in what you've pasted there, but I
> am not familiar with fsl PCI or SoC's, so it's possible that there's
> something there going on ... We'll have to wait for somebody from FSL to
> have a look, unless you can find something in the doco.
The curious thing is that this exact same setup works perfectly
in 2.6.28 and near perfectly in 2.6.32. Unless something else
changed in the PCI handling between 2.6.32 and 2.6.37, I would
hope it work work there as well.
I'll keep looking for differences between those two system versions.
Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: PCI woes with 2.6.37
From: Benjamin Herrenschmidt @ 2011-01-08 7:33 UTC (permalink / raw)
To: Gary Thomas; +Cc: Linux PPC Development
In-Reply-To: <4D279C90.8000006@mlbassoc.com>
On Fri, 2011-01-07 at 16:06 -0700, Gary Thomas wrote:
> I just tried porting my target (MPC8347) from 2.6.28 (remember
> that one?) to 2.6.37. Recently I tried this with 2.6.32 without
> a lot of success, so I thought I'd try the latest :-) The changes
> are very simple, pretty much just the addition of my 8347 based
> platform DTS.
>
> Sadly, it fails even worse than it did on 2.6.32.
>
> For some reason, although everything seems to report that the
> PCI bus is alive, MEM access fails completely. If I try to
> access various PCI devices via their memory space (I only have
> memory peripherals so I can't test IO space access), I get
> what I assume are BUS timeouts - all 0xFFFFFFFF
>
> My PCI bus is defined in DTS like this:
> ranges = <0x02000000 0x0 0xC0000000 0xC0000000 0x0 0x20000000
What are the #address-cells and #size-cells properties of the parent of
the PCI controller node ?
PCI has 3 cells, so that accounts for the first 3 numbers of each of
these. That leaves only 3 numbers, so either you have #address-cells = 1
and #size-cells = 2 or the other way around.
The first sounds the most plausible and would mean that you are mapping
c0000000 CPU space to c0000000 PCI space and the window is 512M long.
Now of course, one needs to double check that the HW is configured that
way (I suppose fsl_pci.c does the configuration based on the "ranges"
property but I don't know for sure).
So far nothing strikes me as totally odd.
> 0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
This looks reasonable too with the same assumption as above.
> PCI: Probing PCI hardware
> PCI: Scanning PHB /pci@ff008500
> PCI: PHB IO resource = 0000000000000000-00000000000FF FFf [100]
> PCI: PHB MEM resource 0 = 00000000c0000000-00000000dFF FFfff [200]
Did you edit those by hand ? :-) They look correct tho as far as I can
tell.
> PCI: PHB MEM offset = 0000000000000000
> PCI: PHB IO offset = 00000000
And that too.
> probe mode: 0
> PCI:0000:00:0b.0 Resource 0 0000000000001000-0000000000001007 [40101] fixup...
> PCI:0000:00:0b.0 0000000000001000-0000000000001007
> PCI:0000:00:0b.0 Resource 1 0000000000001008-000000000000100b [40101] fixup...
> PCI:0000:00:0b.0 0000000000001008-000000000000100b
> PCI:0000:00:0b.0 Resource 2 0000000000001010-0000000000001017 [40101] fixup...
> PCI:0000:00:0b.0 0000000000001010-0000000000001017
> PCI:0000:00:0b.0 Resource 3 0000000000001018-000000000000101b [40101] fixup...
> PCI:0000:00:0b.0 0000000000001018-000000000000101b
> PCI:0000:00:0b.0 Resource 4 0000000000001020-000000000000102f [40101] fixup...
> PCI:0000:00:0b.0 0000000000001020-000000000000102f
> PCI:0000:00:0b.0 Resource 5 0000000000100000-00000000001001ff [40200] fixup...
> PCI:0000:00:0b.0 0000000000100000-00000000001001ff
> PCI:0000:00:0b.0 Resource 6 0000000000000000-000000000007FF FF [4e200] is unassigned
> PCI:0000:00:0c.0 Resource 0 0000000004000000-0000000007FF FFff [40200] fixup...
> PCI:0000:00:0c.0 0000000004000000-0000000007FF FFff
> PCI: Fixup bus devices 0 (PHB)
> PCI: Try to map irq for 0000:00:0b.0...
> Got one, spec 2 cells (0x00000016 0x00000008...) on /soc8349@ff000000/pic@700
> Mapped to linux irq 22
> PCI: Try to map irq for 0000:00:0c.0...
> Got one, spec 2 cells (0x00000013 0x00000008...) on /soc8349@ff000000/pic@700
> Mapped to linux irq 19
> PCI: Allocating bus resources for 0000:00...
> PCI: PHB (bus 0) bridge rsrc 0: 0000000000000000-00000000000FF FFf [0x100], parent c03b5740 (PCI IO)
> PCI: PHB (bus 0) bridge rsrc 1: 00000000c0000000-00000000dFF FFfff [0x200], parent c03b5724 (PCI mem)
> PCI: Allocating 0000:00:0b.0: Resource 0: 0000000000001000..0000000000001007 [40101]
> PCI: Allocating 0000:00:0b.0: Resource 1: 0000000000001008..000000000000100b [40101]
> PCI: Allocating 0000:00:0b.0: Resource 2: 0000000000001010..0000000000001017 [40101]
> PCI: Allocating 0000:00:0b.0: Resource 3: 0000000000001018..000000000000101b [40101]
> PCI: Allocating 0000:00:0b.0: Resource 4: 0000000000001020..000000000000102f [40101]
> PCI: Allocating 0000:00:0b.0: Resource 5: 0000000000100000..00000000001001ff [40200]
> PCI: Cannot allocate resource region 5 of device 0000:00:0b.0, will remap
> PCI: Allocating 0000:00:0c.0: Resource 0: 0000000004000000..0000000007FF FFff [40200]
That's huge, is this your "Coral" framebuffer ? It's clearly using a
different address scheme which won't fit, so the kernel decides to remap
it, so far so good.
> PCI: Cannot allocate resource region 0 of device 0000:00:0c.0, will remap
> Reserving legacy ranges for domain 0000
> Candidate legacy IO: [io 0x0000-0x0fff]
> hose mem offset: 0000000000000000
> hose mem res: [mem 0xc0000000-0xdFF FFfff]
> Local memory hole: [mem 0xc0000000-0xc01FF FFf]
Now I can't grep the above string, what is it ? What is this "memory
hole" ? It covers a good part of your PCI mapping ...
> PCI: Assigning unassigned resources...
> pci 0000:00:0c.0: BAR 0: assigned [mem 0xc4000000-0xc7FF FFff]
> pci 0000:00:0c.0: BAR 0: set to [mem 0xc4000000-0xc7FF FFff] (PCI address [0xc4000000-0xc7FF FFff])
So you fb looks like it has now landed at c4000000, which doesn't strike
me as wrong nor strange so far...
> pci 0000:00:0b.0: BAR 6: assigned [mem 0xc0200000-0xc027FF FF pref]
> pci 0000:00:0b.0: BAR 5: assigned [mem 0xc0280000-0xc02801ff]
> pci 0000:00:0b.0: BAR 5: set to [mem 0xc0280000-0xc02801ff] (PCI address [0xc0280000-0xc02801ff])
> ...
> Coral-P FB [1024x768x24] at 0xc4000000..0xc7FF FFff [0xd1100000]
I suspect 0xd1100000 is the result of ioremap ?
> D1100000: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
> D1100010: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
> D1100020: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
> D1100030: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
> D1100040: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
> D1100050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
> D1100060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
> D1100070: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
> ...
> scsi0 : sata_sil
> scsi1 : sata_sil
> ata1: SATA max UDMA/100 mmio m512@0xc0280000 tf 0xc0280080 irq 22
> ata2: SATA max UDMA/100 mmio m512@0xc0280000 tf 0xc02800c0 irq 22
> ata1: failed to resume link (SControl FFFFFFFF)
> ata1: SATA link down (SStatus FFFFFFFF SControl FFFFFFFF)
> ata2: failed to resume link (SControl FFFFFFFF)
> ata2: SATA link down (SStatus FFFFFFFF SControl FFFFFFFF)
>
> Things of note:
> * The 'local memory hole' is a space I have to steal from the PCI
> address space so that the Coral-P gets mapped to something other
> than PCI memory address 0x0 (relative). This device is dirt stupid
> (previously discussed) and refuses to work at 0x0
> * The dump after the Coral-P FB line is what it sees in it's memory
> space. It _should_ look something like this:
> C4140600: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 |................|
> C4140610: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 |................|
> C4140620: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 |................|
> C4140630: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 |................|
> C4140640: FF FF FF 00 FF FF FF 00 FF FD FF 00 FF FD FF 00 |................|
> C4140650: FF FD FF 00 FF FD FF 00 FF FD FF 00 FF FD FF 00 |................|
> Notice how byte 3 of every longword is 0x00?
> * The SATA device driver is failing along similar lines.
>
> Any ideas what I'm doing wrong? or what I can look at?
I can't see anything obviously wrong in what you've pasted there, but I
am not familiar with fsl PCI or SoC's, so it's possible that there's
something there going on ... We'll have to wait for somebody from FSL to
have a look, unless you can find something in the doco.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] ppc: update dynamic dma support
From: Nishanth Aravamudan @ 2011-01-08 2:53 UTC (permalink / raw)
To: sonnyrao, miltonm, Benjamin Herrenschmidt, Paul Mackerras,
Grant Likely, Anton Blanchard, linuxppc-dev
In-Reply-To: <20101211000744.GA12355@us.ibm.com>
On 10.12.2010 [16:07:44 -0800], Nishanth Aravamudan wrote:
> On 09.12.2010 [11:09:20 -0800], Nishanth Aravamudan wrote:
> > On 26.10.2010 [20:35:17 -0700], Nishanth Aravamudan wrote:
> > > If firmware allows us to map all of a partition's memory for DMA on a
> > > particular bridge, create a 1:1 mapping of that memory. Add hooks for
> > > dealing with hotplug events. Dyanmic DMA windows can use larger than the
> > > default page size, and we use the largest one possible.
> > >
> > > Not-yet-signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> > >
> > > ---
> > >
> > > I've tested this briefly on a machine with suitable firmware/hardware.
> > > Things seem to work well, but I want to do more exhaustive I/O testing
> > > before asking for upstream merging. I would really appreciate any
> > > feedback on the updated approach.
> > >
> > > Specific questions:
> > >
> > > Ben, did I hook into the dma_set_mask() platform callback as you
> > > expected? Anything I can do better or which perhaps might lead to
> > > gotchas later?
> > >
> > > I've added a disable_ddw option, but perhaps it would be better to
> > > just disable the feature if iommu=force?
> >
> > So for the final version, I probably should document this option in
> > kernel-parameters.txt w/ the patch, right?
>
> Here's an updated version. Ben, think you can pick this up to your tree?
Hi Ben,
I have a small follow-on patch that tidies up the code a bit and deals
with an error condition on dlpar remove of ddw slots. I'm putting it
below as a follow-on patch, but I can roll it into the v3 patch and post
a v4 if you'd prefer?
Thanks,
Nish
pseries: ddw cleanups
Use symbolic constants to access RTAS responses.
Disable reconfig notifier's clearing of TCEs and removal of DMA window.
This is handled by firmware currently. If the kernel were to do it, we'd
need a new callback action before the isolation of the slot in question,
or else we'd always get permission errors (firmware revokes the window
automatically).
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
diff --git a/arch/powerpc/include/asm/ppc-pci.h b/arch/powerpc/include/asm/ppc-pci.h
index 43268f1..c17adf7 100644
--- a/arch/powerpc/include/asm/ppc-pci.h
+++ b/arch/powerpc/include/asm/ppc-pci.h
@@ -47,6 +47,20 @@ extern int rtas_setup_phb(struct pci_controller *phb);
extern unsigned long pci_probe_only;
+/* Dynamic DMA Window support */
+struct ddw_query_response {
+ u32 windows_available;
+ u32 largest_available_block;
+ u32 page_size;
+ u32 migration_capable;
+};
+
+struct ddw_create_response {
+ u32 liobn;
+ u32 addr_hi;
+ u32 addr_lo;
+};
+
/* ---- EEH internal-use-only related routines ---- */
#ifdef CONFIG_EEH
diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
index 4ba2338..b6f73c6 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -323,7 +323,7 @@ static int tce_clearrange_multi_pSeriesLP(unsigned long start_pfn,
dma_offset = next + be64_to_cpu(maprange->dma_base);
rc = plpar_tce_stuff((u64)be32_to_cpu(maprange->liobn),
- (u64)dma_offset,
+ dma_offset,
0, limit);
num_tce -= limit;
} while (num_tce > 0 && !rc);
@@ -383,7 +383,7 @@ static int tce_setrange_multi_pSeriesLP(unsigned long start_pfn,
}
rc = plpar_tce_put_indirect(liobn,
- (u64)dma_offset,
+ dma_offset,
(u64)virt_to_abs(tcep),
limit);
@@ -731,7 +731,8 @@ static u64 dupe_ddw_if_kexec(struct pci_dev *dev, struct device_node *pdn)
return dma_addr;
}
-static int query_ddw(struct pci_dev *dev, const u32 *ddr_avail, u32 *query)
+static int query_ddw(struct pci_dev *dev, const u32 *ddr_avail,
+ struct ddw_query_response *query)
{
struct device_node *dn;
struct pci_dn *pcidn;
@@ -751,7 +752,7 @@ static int query_ddw(struct pci_dev *dev, const u32 *ddr_avail, u32 *query)
if (pcidn->eeh_pe_config_addr)
cfg_addr = pcidn->eeh_pe_config_addr;
buid = pcidn->phb->buid;
- ret = rtas_call(ddr_avail[0], 3, 5, query,
+ ret = rtas_call(ddr_avail[0], 3, 5, (u32 *)query,
cfg_addr, BUID_HI(buid), BUID_LO(buid));
dev_info(&dev->dev, "ibm,query-pe-dma-windows(%x) %x %x %x"
" returned %d\n", ddr_avail[0], cfg_addr, BUID_HI(buid),
@@ -759,7 +760,9 @@ static int query_ddw(struct pci_dev *dev, const u32 *ddr_avail, u32 *query)
return ret;
}
-static int create_ddw(struct pci_dev *dev, const u32 *ddr_avail, u32 *create, int page_shift, int window_shift)
+static int create_ddw(struct pci_dev *dev, const u32 *ddr_avail,
+ struct ddw_create_response *create, int page_shift,
+ int window_shift)
{
struct device_node *dn;
struct pci_dn *pcidn;
@@ -782,14 +785,14 @@ static int create_ddw(struct pci_dev *dev, const u32 *ddr_avail, u32 *create, in
do {
/* extra outputs are LIOBN and dma-addr (hi, lo) */
- ret = rtas_call(ddr_avail[1], 5, 4, &create[0], cfg_addr,
+ ret = rtas_call(ddr_avail[1], 5, 4, (u32 *)create, cfg_addr,
BUID_HI(buid), BUID_LO(buid), page_shift, window_shift);
} while(rtas_busy_delay(ret));
dev_info(&dev->dev,
"ibm,create-pe-dma-window(%x) %x %x %x %x %x returned %d "
"(liobn = 0x%x starting addr = %x %x)\n", ddr_avail[1],
cfg_addr, BUID_HI(buid), BUID_LO(buid), page_shift,
- window_shift, ret, create[0], create[1], create[2]);
+ window_shift, ret, create->liobn, create->addr_hi, create->addr_lo);
return ret;
}
@@ -808,7 +811,8 @@ static int create_ddw(struct pci_dev *dev, const u32 *ddr_avail, u32 *create, in
static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
{
int len, ret;
- u32 query[4], create[3];
+ struct ddw_query_response query;
+ struct ddw_create_response create;
int page_shift;
u64 dma_addr, max_addr;
struct device_node *dn;
@@ -846,11 +850,11 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
* of page sizes: supported and supported for migrate-dma.
*/
dn = pci_device_to_OF_node(dev);
- ret = query_ddw(dev, ddr_avail, &query[0]);
+ ret = query_ddw(dev, ddr_avail, &query);
if (ret != 0)
goto out_unlock;
- if (!query[0]) {
+ if (query.windows_available == 0) {
/*
* no additional windows are available for this device.
* We might be able to reallocate the existing window,
@@ -859,23 +863,23 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
dev_dbg(&dev->dev, "no free dynamic windows");
goto out_unlock;
}
- if (query[2] & 4) {
+ if (query.page_size & 4) {
page_shift = 24; /* 16MB */
- } else if (query[2] & 2) {
+ } else if (query.page_size & 2) {
page_shift = 16; /* 64kB */
- } else if (query[2] & 1) {
+ } else if (query.page_size & 1) {
page_shift = 12; /* 4kB */
} else {
dev_dbg(&dev->dev, "no supported direct page size in mask %x",
- query[2]);
+ query.page_size);
goto out_unlock;
}
/* 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[1] < (max_addr >> page_shift)) {
+ if (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[1],
+ "%llu-sized pages\n", max_addr, query.largest_available_block,
1ULL << page_shift);
goto out_unlock;
}
@@ -894,19 +898,17 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
goto out_free_prop;
}
- ret = create_ddw(dev, ddr_avail, &create[0], page_shift, len);
+ ret = create_ddw(dev, ddr_avail, &create, page_shift, len);
if (ret != 0)
goto out_free_prop;
- *ddwprop = (struct dynamic_dma_window_prop) {
- .liobn = cpu_to_be32(create[0]),
- .dma_base = cpu_to_be64(((u64)create[1] << 32) + (u64)create[2]),
- .tce_shift = cpu_to_be32(page_shift),
- .window_shift = cpu_to_be32(len)
- };
+ ddwprop->liobn = cpu_to_be32(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);
dev_dbg(&dev->dev, "created tce table LIOBN 0x%x for %s\n",
- create[0], dn->full_name);
+ create.liobn, dn->full_name);
window = kzalloc(sizeof(*window), GFP_KERNEL);
if (!window)
@@ -933,7 +935,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
list_add(&window->list, &direct_window_list);
spin_unlock(&direct_window_list_lock);
- dma_addr = of_read_number(&create[1], 2);
+ dma_addr = of_read_number(&create.addr_hi, 2);
set_dma_offset(&dev->dev, dma_addr);
goto out_unlock;
@@ -1118,7 +1120,15 @@ static int iommu_reconfig_notifier(struct notifier_block *nb, unsigned long acti
}
spin_unlock(&direct_window_list_lock);
- remove_ddw(np);
+ /*
+ * Because the notifier runs after isolation of the
+ * slot, we are guaranteed any DMA window has already
+ * been revoked and the TCEs have been marked invalid,
+ * so we don't need a call to remove_ddw(np). However,
+ * if an additional notifier action is added before the
+ * isolate call, we should update this code for
+ * completeness with such a call.
+ */
break;
default:
err = NOTIFY_DONE;
--
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center
^ permalink raw reply related
* PCI woes with 2.6.37
From: Gary Thomas @ 2011-01-07 23:06 UTC (permalink / raw)
To: Linux PPC Development
I just tried porting my target (MPC8347) from 2.6.28 (remember
that one?) to 2.6.37. Recently I tried this with 2.6.32 without
a lot of success, so I thought I'd try the latest :-) The changes
are very simple, pretty much just the addition of my 8347 based
platform DTS.
Sadly, it fails even worse than it did on 2.6.32.
For some reason, although everything seems to report that the
PCI bus is alive, MEM access fails completely. If I try to
access various PCI devices via their memory space (I only have
memory peripherals so I can't test IO space access), I get
what I assume are BUS timeouts - all 0xFFFFFFFF
My PCI bus is defined in DTS like this:
pci0: pci@ff008500 {
cell-index = <1>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
/* IDSEL 0x0B (SIL SATA) */
0x5800 0x0 0x0 0x1 &ipic 0x16 8
0x5800 0x0 0x0 0x2 &ipic 0x16 8
0x5800 0x0 0x0 0x3 &ipic 0x16 8
0x5800 0x0 0x0 0x4 &ipic 0x16 8
/* IDSEL 0x0C (Fujitsu Coral-P) */
0x6000 0x0 0x0 0x1 &ipic 0x13 8
0x6000 0x0 0x0 0x2 &ipic 0x13 8
0x6000 0x0 0x0 0x3 &ipic 0x13 8
0x6000 0x0 0x0 0x4 &ipic 0x13 8
>;
interrupt-parent = <&ipic>;
interrupts = <0x13 0x8
0x14 0x8>;
bus-range = <0 0>;
ranges = <0x02000000 0x0 0xC0000000 0xC0000000 0x0 0x20000000
0x01000000 0x0 0x00000000 0xB8000000 0x0 0x00100000>;
clock-frequency = <33333333>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
reg = <0xff008500 0x100 /* Internal registers */
0xff008300 0x8>; /* Config Space registers */
compatible = "fsl,mpc8349-pci";
device_type = "pci";
};
When I boot, I get these messages indicating that the PCI bus is found,
mapped, scanned, etc:
PCI: Probing PCI hardware
PCI: Scanning PHB /pci@ff008500
PCI: PHB IO resource = 0000000000000000-00000000000FF FFf [100]
PCI: PHB MEM resource 0 = 00000000c0000000-00000000dFF FFfff [200]
PCI: PHB MEM offset = 0000000000000000
PCI: PHB IO offset = 00000000
probe mode: 0
PCI:0000:00:0b.0 Resource 0 0000000000001000-0000000000001007 [40101] fixup...
PCI:0000:00:0b.0 0000000000001000-0000000000001007
PCI:0000:00:0b.0 Resource 1 0000000000001008-000000000000100b [40101] fixup...
PCI:0000:00:0b.0 0000000000001008-000000000000100b
PCI:0000:00:0b.0 Resource 2 0000000000001010-0000000000001017 [40101] fixup...
PCI:0000:00:0b.0 0000000000001010-0000000000001017
PCI:0000:00:0b.0 Resource 3 0000000000001018-000000000000101b [40101] fixup...
PCI:0000:00:0b.0 0000000000001018-000000000000101b
PCI:0000:00:0b.0 Resource 4 0000000000001020-000000000000102f [40101] fixup...
PCI:0000:00:0b.0 0000000000001020-000000000000102f
PCI:0000:00:0b.0 Resource 5 0000000000100000-00000000001001ff [40200] fixup...
PCI:0000:00:0b.0 0000000000100000-00000000001001ff
PCI:0000:00:0b.0 Resource 6 0000000000000000-000000000007FF FF [4e200] is unassigned
PCI:0000:00:0c.0 Resource 0 0000000004000000-0000000007FF FFff [40200] fixup...
PCI:0000:00:0c.0 0000000004000000-0000000007FF FFff
PCI: Fixup bus devices 0 (PHB)
PCI: Try to map irq for 0000:00:0b.0...
Got one, spec 2 cells (0x00000016 0x00000008...) on /soc8349@ff000000/pic@700
Mapped to linux irq 22
PCI: Try to map irq for 0000:00:0c.0...
Got one, spec 2 cells (0x00000013 0x00000008...) on /soc8349@ff000000/pic@700
Mapped to linux irq 19
PCI: Allocating bus resources for 0000:00...
PCI: PHB (bus 0) bridge rsrc 0: 0000000000000000-00000000000FF FFf [0x100], parent c03b5740 (PCI IO)
PCI: PHB (bus 0) bridge rsrc 1: 00000000c0000000-00000000dFF FFfff [0x200], parent c03b5724 (PCI mem)
PCI: Allocating 0000:00:0b.0: Resource 0: 0000000000001000..0000000000001007 [40101]
PCI: Allocating 0000:00:0b.0: Resource 1: 0000000000001008..000000000000100b [40101]
PCI: Allocating 0000:00:0b.0: Resource 2: 0000000000001010..0000000000001017 [40101]
PCI: Allocating 0000:00:0b.0: Resource 3: 0000000000001018..000000000000101b [40101]
PCI: Allocating 0000:00:0b.0: Resource 4: 0000000000001020..000000000000102f [40101]
PCI: Allocating 0000:00:0b.0: Resource 5: 0000000000100000..00000000001001ff [40200]
PCI: Cannot allocate resource region 5 of device 0000:00:0b.0, will remap
PCI: Allocating 0000:00:0c.0: Resource 0: 0000000004000000..0000000007FF FFff [40200]
PCI: Cannot allocate resource region 0 of device 0000:00:0c.0, will remap
Reserving legacy ranges for domain 0000
Candidate legacy IO: [io 0x0000-0x0fff]
hose mem offset: 0000000000000000
hose mem res: [mem 0xc0000000-0xdFF FFfff]
Local memory hole: [mem 0xc0000000-0xc01FF FFf]
PCI: Assigning unassigned resources...
pci 0000:00:0c.0: BAR 0: assigned [mem 0xc4000000-0xc7FF FFff]
pci 0000:00:0c.0: BAR 0: set to [mem 0xc4000000-0xc7FF FFff] (PCI address [0xc4000000-0xc7FF FFff])
pci 0000:00:0b.0: BAR 6: assigned [mem 0xc0200000-0xc027FF FF pref]
pci 0000:00:0b.0: BAR 5: assigned [mem 0xc0280000-0xc02801ff]
pci 0000:00:0b.0: BAR 5: set to [mem 0xc0280000-0xc02801ff] (PCI address [0xc0280000-0xc02801ff])
...
Coral-P FB [1024x768x24] at 0xc4000000..0xc7FF FFff [0xd1100000]
D1100000: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
D1100010: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
D1100020: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
D1100030: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
D1100040: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
D1100050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
D1100060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
D1100070: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF |................|
...
scsi0 : sata_sil
scsi1 : sata_sil
ata1: SATA max UDMA/100 mmio m512@0xc0280000 tf 0xc0280080 irq 22
ata2: SATA max UDMA/100 mmio m512@0xc0280000 tf 0xc02800c0 irq 22
ata1: failed to resume link (SControl FFFFFFFF)
ata1: SATA link down (SStatus FFFFFFFF SControl FFFFFFFF)
ata2: failed to resume link (SControl FFFFFFFF)
ata2: SATA link down (SStatus FFFFFFFF SControl FFFFFFFF)
Things of note:
* The 'local memory hole' is a space I have to steal from the PCI
address space so that the Coral-P gets mapped to something other
than PCI memory address 0x0 (relative). This device is dirt stupid
(previously discussed) and refuses to work at 0x0
* The dump after the Coral-P FB line is what it sees in it's memory
space. It _should_ look something like this:
C4140600: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 |................|
C4140610: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 |................|
C4140620: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 |................|
C4140630: FF FF FF 00 FF FF FF 00 FF FF FF 00 FF FF FF 00 |................|
C4140640: FF FF FF 00 FF FF FF 00 FF FD FF 00 FF FD FF 00 |................|
C4140650: FF FD FF 00 FF FD FF 00 FF FD FF 00 FF FD FF 00 |................|
Notice how byte 3 of every longword is 0x00?
* The SATA device driver is failing along similar lines.
Any ideas what I'm doing wrong? or what I can look at?
Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Scott Wood @ 2011-01-07 20:57 UTC (permalink / raw)
To: Blanchard, Hollis; +Cc: Inge, Meador, devicetree-discuss, linuxppc-dev
In-Reply-To: <DD7A9A95166BF4418C4C1EB2033B6EE2038FA90D@na3-mail.mgc.mentorg.com>
On Fri, 7 Jan 2011 12:30:52 -0800
"Blanchard, Hollis" <Hollis_Blanchard@mentor.com> wrote:
> On 01/07/2011 08:44 AM, Grant Likely wrote:
> > On Fri, Jan 7, 2011 at 9:00 AM, Blanchard, Hollis
> > <Hollis_Blanchard@mentor.com> wrote:
> >> On 01/07/2011 07:48 AM, Grant Likely wrote:
> >>> Actually, for a while now the kernel has been moving towards userspace
> >>> being responsible for device identification. That's what udev is for.
> >>> The kernel udev looks at the available information when a device is
> >>> registered/bound, and it creates useful symlinks to the dynamically
> >>> assigned major/minor devices. The rest of userspace doesn't need to
> >>> know about it; it can simply use the symlinks in /dev, but it is
> >>> appropriate to let udev figure out the correct naming.
> >> Can you point out an example of how this is done for Open Firmware
> >> devices currently?
> > Nope, because while it has been a theoretical concern, in practice the
> > issue hasn't come up on any of the hardware I've worked on or I've
> > seen patches for.
> That is still this case here: it's a theoretical concern. Don't forget:
> we're talking about eight registers in the MPIC. There is no bus, no
> hotplug, nothing. Really, the only requirement is that somehow we can
> match the names used in the hardware documentation.
It's a practical concern on other devices, and we need to solve that.
Once that happens, the same infrastructure should be usable to deal
with this as well -- though really, it's a separate issue from what
goes in the device tree.
The established mechanism for "match the names used in the hardware
documentation" is aliases.
In this particular case, if you want userspace to just see timers 0-7,
have the kernel driver look for the standard aliases to determine which
block is which, and expose it to userspace in the manner of your
choosing.
> > Mostly this is because the device tree
> > representations are internally self consistent;
> > dependencies/connections are explicitly expressed with phandles or
> > full paths which eliminates any need for enumeration in all the cases
> > I've had to deal with.
> The device tree on every platform contains devices which must be
> referenced by userspace. That is the problem we're trying to solve --
> let's not get distracted by theoretical principles of enumeration.
>
> The closest analogy might be serial devices, which unlike ethernet
> devices don't have other distinguishing information for udev to
> interpret. To my surprise, when I reverse the order of the serial nodes
> in the device tree, the ttyS0/S1 ordering reverses too. This is exactly
> the problem we were trying to avoid... but it seems nobody has solved it
> anywhere. :(
What if you plug in a PCI serial card? Or USB? What if you're under a
hypervisor and you have a variety of virtual serial/console/etc.
objects that don't have any meaningful enumeration order?
As Grant suggested, udev should be made aware of device-tree aliases --
which would be the distinguishing information udev needs.
In the absence of aliases or other good information, perhaps the udev
rule could fall back on heuristics such as bus type and address to at
least reduce unpredictability.
-Scott
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Blanchard, Hollis @ 2011-01-07 20:30 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, Inge, Meador, devicetree-discuss, linuxppc-dev
In-Reply-To: <AANLkTikY8z3V-opZ6K3j28QfyBV_p8jEAhxOKywjX27T@mail.gmail.com>
On 01/07/2011 08:44 AM, Grant Likely wrote:
> On Fri, Jan 7, 2011 at 9:00 AM, Blanchard, Hollis
> <Hollis_Blanchard@mentor.com> wrote:
>> On 01/07/2011 07:48 AM, Grant Likely wrote:
>>> Actually, for a while now the kernel has been moving towards =
userspace
>>> being responsible for device identification. That's what udev is =
for.
>>> The kernel udev looks at the available information when a device =
is
>>> registered/bound, and it creates useful symlinks to the dynamically
>>> assigned major/minor devices. The rest of userspace doesn't need to
>>> know about it; it can simply use the symlinks in /dev, but it is
>>> appropriate to let udev figure out the correct naming.
>> Can you point out an example of how this is done for Open Firmware
>> devices currently?
> Nope, because while it has been a theoretical concern, in practice the
> issue hasn't come up on any of the hardware I've worked on or I've
> seen patches for.
That is still this case here: it's a theoretical concern. Don't forget:=20
we're talking about eight registers in the MPIC. There is no bus, no=20
hotplug, nothing. Really, the only requirement is that somehow we can=20
match the names used in the hardware documentation.
> Mostly this is because the device tree
> representations are internally self consistent;
> dependencies/connections are explicitly expressed with phandles or
> full paths which eliminates any need for enumeration in all the cases
> I've had to deal with.
The device tree on every platform contains devices which must be=20
referenced by userspace. That is the problem we're trying to solve --=20
let's not get distracted by theoretical principles of enumeration.
The closest analogy might be serial devices, which unlike ethernet=20
devices don't have other distinguishing information for udev to=20
interpret. To my surprise, when I reverse the order of the serial nodes=20
in the device tree, the ttyS0/S1 ordering reverses too. This is exactly=20
the problem we were trying to avoid... but it seems nobody has solved it =
anywhere. :(
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* Re: [PATCH] of/device: Don't register disabled devices
From: Grant Likely @ 2011-01-07 17:23 UTC (permalink / raw)
To: David Gibson, Blanchard, Hollis, devicetree-discuss, linuxppc-dev,
linux-kernel, Scott Wood, Benjamin Herrenschmidt, Saxena, Deepak
In-Reply-To: <20110105233535.GB8846@yookeroo>
On Thu, Jan 06, 2011 at 10:35:35AM +1100, David Gibson wrote:
> On Wed, Jan 05, 2011 at 02:53:27PM -0800, Blanchard, Hollis wrote:
> > On 01/03/2011 03:01 PM, Grant Likely wrote:
> > > Device nodes with the property status="disabled" are not usable and so
> > > don't register them when parsing the device tree for devices.
> > >
> > This is great and all, but a fair amount of driver code explicitly
> > searches the tree, rather than registering a probe function. That's why
> > our earlier patches in this area were more comprehensive.
As your patch set shows, the total set isn't unmanageable, and the
preference for new code is to use the device model infrastructure if
at all possible.
> >
> > What are your thoughts on handling those cases?
>
> One by one. Trying to handle the explicit searches automagically is
> just asking for trouble.
Just as David says, the special cases are... well... special.
Anything making decisions about registering devices needs to follow
the status!="okay" rules.
g.
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Grant Likely @ 2011-01-07 16:44 UTC (permalink / raw)
To: Blanchard, Hollis
Cc: Scott Wood, Inge, Meador, devicetree-discuss, linuxppc-dev
In-Reply-To: <DD7A9A95166BF4418C4C1EB2033B6EE2038FA900@na3-mail.mgc.mentorg.com>
On Fri, Jan 7, 2011 at 9:00 AM, Blanchard, Hollis
<Hollis_Blanchard@mentor.com> wrote:
> On 01/07/2011 07:48 AM, Grant Likely wrote:
>> Actually, for a while now the kernel has been moving towards userspace
>> being responsible for device identification. =A0That's what udev is for.
>> =A0 The kernel udev looks at the available information when a device is
>> registered/bound, and it creates useful symlinks to the dynamically
>> assigned major/minor devices. =A0The rest of userspace doesn't need to
>> know about it; it can simply use the symlinks in /dev, but it is
>> appropriate to let udev figure out the correct naming.
> Can you point out an example of how this is done for Open Firmware
> devices currently?
Nope, because while it has been a theoretical concern, in practice the
issue hasn't come up on any of the hardware I've worked on or I've
seen patches for. Mostly this is because the device tree
representations are internally self consistent;
dependencies/connections are explicitly expressed with phandles or
full paths which eliminates any need for enumeration in all the cases
I've had to deal with.
What I can point at is that almost all Linux character, block, and
network devices are assigned major/minor numbers in a first-come
first-served basis. This of course causes problems for userspace
applications who need a stable handle to a specific device. Device
renaming turned out to be horribly complex, which is why for character
and block devices the whole problem was punted out into userspace for
udev to handle with symlinks. Network device unfortunately don't
appear in /dev, so they are stuck with device renaming until some form
of network device name aliasing is created.
As Scott also says, I know from experience that trying to maintain
enumeration in the device tree nodes themselves, and getting device
drivers to request specific numbers is painful, complex and fragile.
If I could go back in time I would never have attempted it on the
mpc5200 psc (serial) devices.
> In particular, how are the udev rules supposed to
> operate? They get a device path, use that to find additional information
> in /proc/device-tree (hope that's mounted), and then what? Do we
> hardcode the block addresses in the rules, for example @1400 and @2400?
You can do that; but from the little bit I know about your use case,
user-space visible references would be better explicitly expressed in
the aliases node. It isn't currently, but matching aliases can easily
be added to the device's UEVENT property in /sys. That is probably
the approach I would investigate for getting instance information out
to udev so it can create useful symlinks to the /dev device files.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Blanchard, Hollis @ 2011-01-07 16:00 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, Inge, Meador, devicetree-discuss, linuxppc-dev
In-Reply-To: <AANLkTikROM4MtmLYEK_6ndRzbDJ3xjMM5iSPzDhpRWLy@mail.gmail.com>
On 01/07/2011 07:48 AM, Grant Likely wrote:
> Actually, for a while now the kernel has been moving towards userspace
> being responsible for device identification. That's what udev is for.
> The kernel udev looks at the available information when a device is
> registered/bound, and it creates useful symlinks to the dynamically
> assigned major/minor devices. The rest of userspace doesn't need to
> know about it; it can simply use the symlinks in /dev, but it is
> appropriate to let udev figure out the correct naming.
Can you point out an example of how this is done for Open Firmware=20
devices currently? In particular, how are the udev rules supposed to=20
operate? They get a device path, use that to find additional information =
in /proc/device-tree (hope that's mounted), and then what? Do we=20
hardcode the block addresses in the rules, for example @1400 and @2400?
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Grant Likely @ 2011-01-07 15:48 UTC (permalink / raw)
To: Blanchard, Hollis
Cc: Scott Wood, Inge, Meador, devicetree-discuss, linuxppc-dev
In-Reply-To: <DD7A9A95166BF4418C4C1EB2033B6EE2038FA8FD@na3-mail.mgc.mentorg.com>
On Thu, Jan 6, 2011 at 2:52 PM, Blanchard, Hollis
<Hollis_Blanchard@mentor.com> wrote:
> On 01/05/2011 03:07 PM, Scott Wood wrote:
>> On Wed, 5 Jan 2011 14:49:40 -0800
>> "Blanchard, Hollis"<Hollis_Blanchard@mentor.com> =A0wrote:
>>
>>> On 01/05/2011 02:09 PM, Scott Wood wrote:
>>>> On Wed, 5 Jan 2011 15:58:55 -0600
>>>> Meador Inge<meador_inge@mentor.com> =A0 wrote:
>>>>
>>>>> We need some sort of mapping between a message register and a message
>>>>> register number so that the message registers can be referenced throu=
gh
>>>>> some sort of API (e.g. 'mpic_msgr_read(0)'). =A0One way to do that wo=
uld
>>>>> be by putting an order on the registers. =A0Maybe there is a better w=
ay,
>>>>> though ...
>>>> A message register is uniquely identified by a reference to the device
>>>> tree node, plus a 0-3 index into that node's message registers.
>>> Really what we're talking about is software configuration, not hardware
>>> description.
>> Part of that software configuration involves identifying the hardware
>> being referenced.
>>
>>> We've gone back and forth on representing this information
>>> in the device tree, and most recently decided against it. Outside the
>>> kernel, a device node reference isn't really practical.
>> Global enumeration isn't much fun either. =A0For something like this
>> where it's very unlikely that additional MPIC message units will be
>> added to the system dynamically, it's managable, but it's not a good
>> habit to get into. =A0Look at the pain that's been caused by such
>> assumptions in the i2c subsystem, in kernel interrupt management, etc.
>>
>> A reference to a node is just a pointer to a software message driver
>> object, which can be obtained from looking up an alias. =A0It's a little
>> less simple than just using a number, but it's not impractical. It also
>> provides a natural place to put a layer of indirection in the code that
>> isolates the upper-layer protocol from the details of what sort of
>> message transport it is using.
>>
>> Now, if you don't care about this, and want to just use numbers in your
>> application, go ahead. =A0But I don't think that such an assumption
>> should go into the device tree binding. =A0Have the software number the
>> message register banks in increasing physical address order, or based
>> on numbered aliases similar to how U-Boot enumerates ethernet nodes, or
>> something similar.
> Using physical addresses doesn't solve the enumeration problem either,
> but I think it's beside the point: userspace must refer to the device.
> There is a rich history of userspace *not* walking /proc/device-tree in
> order to refer to a physical device. Are you suggesting this case is
> special?
Actually, for a while now the kernel has been moving towards userspace
being responsible for device identification. That's what udev is for.
The kernel udev looks at the available information when a device is
registered/bound, and it creates useful symlinks to the dynamically
assigned major/minor devices. The rest of userspace doesn't need to
know about it; it can simply use the symlinks in /dev, but it is
appropriate to let udev figure out the correct naming.
Also, if you want to do global enumeration of devices, the accepted
way to do so is to use properties in the /aliases node in the form:
'<type><number> =3D "/path/to/device/node";'
g.
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: Rafael Beims @ 2011-01-07 10:00 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: michael, linuxppc-dev, scottwood, RFeany
In-Reply-To: <OFB0350E05.07B070EF-ONC1257810.005CAF17-C1257810.005CAF19@transmode.se>
On Thu, Jan 6, 2011 at 2:52 PM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
>
> The 8xx tlbil_va should not be needed in recent 2.6 after I fixed the 8xx=
TLB code
> to workaround the dcbst bug there instead. See
> http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dco=
mmitdiff;h=3D0a2ab51ffb8dfdf51402dcfb446629648c96bc78;hp=3D60e071fee994ff98=
c37d03a4a7c5a3f8b1e3b8e5
>
> Not sure what release it went into though.
>
> =A0Jocke
I saw that the commit you mention did make it in the 2.6.33 version. I
will try to boot it here and see if the problem is also solved in this
version.
Rafael
^ permalink raw reply
* [PATCH] powerpc: add support for multiple 85xx RapidIO development boards
From: Alex Dubov @ 2011-01-07 8:27 UTC (permalink / raw)
To: linuxppc-dev
Many RapidIO development boards do not require any board/vendor specific=0A=
tweaking at kernel start, and can rely on the flattened device tree for=0Aa=
ll their hardware configuration needs.=0A=0AThis patch adds support for "ge=
neric,mpc85xx-riodev" compatible boards=0Awith PCI disabled by default and =
RapidIO enabled. It will also try to=0Aread a "vendor" property from the ro=
ot of device tree to provide a possibly=0Auseful bit of information in the =
/proc/cpuinfo.=0A=0ASigned-off-by: Alex Dubov <oakad@yahoo.com>=0A---=0A ar=
ch/powerpc/configs/85xx/mpc85xx_riodev_defconfig | 82 ++++++++++++++=0A a=
rch/powerpc/platforms/85xx/Kconfig | 9 ++=0A arch/powerpc=
/platforms/85xx/Makefile | 1 +=0A arch/powerpc/platforms/8=
5xx/mpc85xx_riodev.c | 116 ++++++++++++++++++++=0A 4 files changed, =
208 insertions(+), 0 deletions(-)=0A create mode 100644 arch/powerpc/config=
s/85xx/mpc85xx_riodev_defconfig=0A create mode 100644 arch/powerpc/platform=
s/85xx/mpc85xx_riodev.c=0A=0Adiff --git a/arch/powerpc/configs/85xx/mpc85xx=
_riodev_defconfig b/arch/powerpc/configs/85xx/mpc85xx_riodev_defconfig=0Ane=
w file mode 100644=0Aindex 0000000..5d0596e=0A--- /dev/null=0A+++ b/arch/po=
werpc/configs/85xx/mpc85xx_riodev_defconfig=0A@@ -0,0 +1,82 @@=0A+CONFIG_PP=
C_85xx=3Dy=0A+CONFIG_EXPERIMENTAL=3Dy=0A+CONFIG_SYSVIPC=3Dy=0A+CONFIG_LOG_B=
UF_SHIFT=3D14=0A+CONFIG_BLK_DEV_INITRD=3Dy=0A+# CONFIG_CC_OPTIMIZE_FOR_SIZE=
is not set=0A+CONFIG_EMBEDDED=3Dy=0A+CONFIG_MODULES=3Dy=0A+CONFIG_MODULE_U=
NLOAD=3Dy=0A+# CONFIG_BLK_DEV_BSG is not set=0A+CONFIG_MPC85xx_RIODEV=3Dy=
=0A+CONFIG_HIGHMEM=3Dy=0A+CONFIG_NO_HZ=3Dy=0A+CONFIG_HIGH_RES_TIMERS=3Dy=0A=
+CONFIG_BINFMT_MISC=3Dy=0A+CONFIG_MATH_EMULATION=3Dy=0A+CONFIG_SPARSE_IRQ=
=3Dy=0A+# CONFIG_SECCOMP is not set=0A+CONFIG_PCI=3Dn=0A+CONFIG_PCIEPORTBUS=
=3Dn=0A+# CONFIG_PCIEASPM is not set=0A+CONFIG_NET=3Dy=0A+CONFIG_PACKET=3Dy=
=0A+CONFIG_UNIX=3Dy=0A+CONFIG_XFRM_USER=3Dy=0A+CONFIG_INET=3Dy=0A+CONFIG_IP=
_MULTICAST=3Dy=0A+CONFIG_IP_PNP=3Dy=0A+CONFIG_IP_PNP_DHCP=3Dy=0A+CONFIG_IP_=
PNP_BOOTP=3Dy=0A+CONFIG_SYN_COOKIES=3Dy=0A+# CONFIG_INET_LRO is not set=0A+=
# CONFIG_IPV6 is not set=0A+CONFIG_UEVENT_HELPER_PATH=3D"/sbin/hotplug"=0A+=
# CONFIG_FW_LOADER is not set=0A+CONFIG_MTD=3Dy=0A+CONFIG_MTD_PARTITIONS=3D=
y=0A+CONFIG_MTD_OF_PARTS=3Dy=0A+CONFIG_MTD_CHAR=3Dy=0A+CONFIG_MTD_BLKDEVS=
=3Dy=0A+CONFIG_MTD_CFI=3Dy=0A+CONFIG_MTD_CFI_AMDSTD=3Dy=0A+CONFIG_MTD_PHYSM=
AP_OF=3Dy=0A+CONFIG_MTD_NAND_ECC_SMC=3Dy=0A+CONFIG_MTD_NAND=3Dy=0A+CONFIG_M=
TD_NAND_FSL_UPM=3Dy=0A+CONFIG_PROC_DEVICETREE=3Dy=0A+CONFIG_BLK_DEV_LOOP=3D=
y=0A+CONFIG_BLK_DEV_RAM=3Dy=0A+CONFIG_BLK_DEV_RAM_SIZE=3D32768=0A+CONFIG_NE=
TDEVICES=3Dy=0A+CONFIG_NET_ETHERNET=3Dy=0A+CONFIG_MII=3Dy=0A+CONFIG_GIANFAR=
=3Dy=0A+# CONFIG_INPUT_MOUSEDEV is not set=0A+# CONFIG_INPUT_KEYBOARD is no=
t set=0A+# CONFIG_INPUT_MOUSE is not set=0A+# CONFIG_SERIO is not set=0A+# =
CONFIG_VT is not set=0A+CONFIG_SERIAL_8250=3Dy=0A+CONFIG_SERIAL_8250_CONSOL=
E=3Dy=0A+# CONFIG_HW_RANDOM is not set=0A+CONFIG_I2C=3Dy=0A+CONFIG_I2C_CHAR=
DEV=3Dy=0A+CONFIG_I2C_MPC=3Dy=0A+CONFIG_VIDEO_OUTPUT_CONTROL=3Dy=0A+# CONFI=
G_USB_SUPPORT is not set=0A+CONFIG_INOTIFY=3Dy=0A+CONFIG_PROC_KCORE=3Dy=0A+=
CONFIG_TMPFS=3Dy=0A+CONFIG_JFFS2_FS=3Dy=0A+CONFIG_NFS_FS=3Dy=0A+CONFIG_ROOT=
_NFS=3Dy=0A+CONFIG_PARTITION_ADVANCED=3Dy=0A+# CONFIG_MSDOS_PARTITION is no=
t set=0A+CONFIG_DEBUG_KERNEL=3Dy=0A+CONFIG_DETECT_HUNG_TASK=3Dy=0A+CONFIG_D=
EBUG_MUTEXES=3Dy=0A+# CONFIG_DEBUG_BUGVERBOSE is not set=0A+# CONFIG_RCU_CP=
U_STALL_DETECTOR is not set=0A+CONFIG_SYSCTL_SYSCALL_CHECK=3Dy=0A+# CONFIG_=
CRYPTO_ANSI_CPRNG is not set=0Adiff --git a/arch/powerpc/platforms/85xx/Kco=
nfig b/arch/powerpc/platforms/85xx/Kconfig=0Aindex b6976e1..be48db0 100644=
=0A--- a/arch/powerpc/platforms/85xx/Kconfig=0A+++ b/arch/powerpc/platforms=
/85xx/Kconfig=0A@@ -97,6 +97,15 @@ config XES_MPC85xx=0A =09 Manufacturer:=
Extreme Engineering Solutions, Inc.=0A =09 URL: <http://www.xes-inc.com/>=
=0A =0A+config MPC85xx_RIODEV=0A+=09bool "Generic MPC85xx board with serial=
RapidIO"=0A+=09select DEFAULT_UIMAGE=0A+=09select HAS_RAPIDIO=0A+=09help=
=0A+=09 This option enables support for one of many RapidIO development=0A=
+=09 boards, which do not need any vendor specific kernel tweaks and=0A+=
=09 fully rely on flattened device tree for the hardware configuration.=0A=
+=0A config STX_GP3=0A =09bool "Silicon Turnkey Express GP3"=0A =09help=0Ad=
iff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/8=
5xx/Makefile=0Aindex dd70db7..228f0f9 100644=0A--- a/arch/powerpc/platforms=
/85xx/Makefile=0A+++ b/arch/powerpc/platforms/85xx/Makefile=0A@@ -14,6 +14,=
7 @@ obj-$(CONFIG_P1022_DS) +=3D p1022_ds.o=0A obj-$(CONFIG_P3041_DS) =
+=3D p3041_ds.o corenet_ds.o=0A obj-$(CONFIG_P4080_DS) +=3D p4080_ds.o =
corenet_ds.o=0A obj-$(CONFIG_P5020_DS) +=3D p5020_ds.o corenet_ds.o=0A+o=
bj-$(CONFIG_MPC85xx_RIODEV) +=3D mpc85xx_riodev.o=0A obj-$(CONFIG_STX_GP3)=
=09 +=3D stx_gp3.o=0A obj-$(CONFIG_TQM85xx)=09 +=3D tqm85xx.o=0A obj-$(CO=
NFIG_SBC8560) +=3D sbc8560.o=0Adiff --git a/arch/powerpc/platforms/85xx=
/mpc85xx_riodev.c b/arch/powerpc/platforms/85xx/mpc85xx_riodev.c=0Anew file=
mode 100644=0Aindex 0000000..415f22b=0A--- /dev/null=0A+++ b/arch/powerpc/=
platforms/85xx/mpc85xx_riodev.c=0A@@ -0,0 +1,116 @@=0A+/*=0A+ * Based on tq=
m85xx.c and other similar files.=0A+ *=0A+ * Copyright (c) 2011 Alex Dubov =
<oakad@yahoo.com>=0A+ *=0A+ * This program is free software; you can redist=
ribute it and/or modify it=0A+ * under the terms of the GNU General Pub=
lic License as published by the=0A+ * Free Software Foundation; either ver=
sion 2 of the License, or (at your=0A+ * option) any later version.=0A+ */=
=0A+=0A+#include <linux/seq_file.h>=0A+#include <linux/of_platform.h>=0A+=
=0A+#include <asm/machdep.h>=0A+#include <asm/mpic.h>=0A+#include <asm/udbg=
.h>=0A+=0A+#include <sysdev/fsl_soc.h>=0A+=0A+static void __init mpc85xx_ri=
odev_pic_init(void)=0A+{=0A+=09struct mpic *mpic;=0A+=09struct resource r;=
=0A+=09struct device_node *np;=0A+=0A+=09np =3D of_find_node_by_type(NULL, =
"open-pic");=0A+=09if (!np) {=0A+=09=09printk(KERN_ERR "Could not find open=
-pic node\n");=0A+=09=09return;=0A+=09}=0A+=0A+=09if (of_address_to_resourc=
e(np, 0, &r)) {=0A+=09=09printk(KERN_ERR "Could not map mpic register space=
\n");=0A+=09=09of_node_put(np);=0A+=09=09return;=0A+=09}=0A+=0A+=09mpic =3D=
mpic_alloc(np, r.start,=0A+=09=09=09MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC=
_BIG_ENDIAN,=0A+=09=09=090, 256, " OpenPIC ");=0A+=09BUG_ON(mpic =3D=3D NU=
LL);=0A+=09of_node_put(np);=0A+=0A+=09mpic_init(mpic);=0A+}=0A+=0A+/*=0A+ *=
Setup the architecture=0A+ */=0A+static void __init mpc85xx_riodev_setup_a=
rch(void)=0A+{=0A+}=0A+=0A+static void mpc85xx_riodev_show_cpuinfo(struct s=
eq_file *m)=0A+{=0A+=09struct device_node *root =3D NULL;=0A+=09const char =
*vendor_str =3D NULL;=0A+=09uint pvid, svid, phid1;=0A+=0A+=09pvid =3D mfsp=
r(SPRN_PVR);=0A+=09svid =3D mfspr(SPRN_SVR);=0A+=0A+=09root =3D of_find_nod=
e_by_path("/");=0A+=09if (root) {=0A+=09=09vendor_str =3D of_get_property(r=
oot, "vendor", NULL);=0A+=09=09of_node_put(root);=0A+=09}=0A+=0A+=09if (!ve=
ndor_str)=0A+=09=09vendor_str =3D "generic";=0A+=0A+=09seq_printf(m, "vendo=
r\t\t: %s\n", vendor_str);=0A+=09seq_printf(m, "PVR\t\t: 0x%x\n", pvid);=0A=
+=09seq_printf(m, "SVR\t\t: 0x%x\n", svid);=0A+=0A+=09/* Display cpu Pll se=
tting */=0A+=09phid1 =3D mfspr(SPRN_HID1);=0A+=09seq_printf(m, "PLL setting=
\t: 0x%x\n", ((phid1 >> 24) & 0x3f));=0A+}=0A+=0A+static struct of_device_i=
d __initdata of_bus_ids[] =3D {=0A+=09{ .compatible =3D "simple-bus", },=0A=
+=09{ .compatible =3D "gianfar", },=0A+=09{},=0A+};=0A+=0A+static int __ini=
t declare_of_platform_devices(void)=0A+{=0A+=09of_platform_bus_probe(NULL, =
of_bus_ids, NULL);=0A+=0A+=09return 0;=0A+}=0A+machine_device_initcall(mpc8=
5xx_riodev, declare_of_platform_devices);=0A+=0A+/*=0A+ * Called very early=
, device-tree isn't unflattened=0A+ */=0A+static int __init mpc85xx_riodev_=
probe(void)=0A+{=0A+=09unsigned long root =3D of_get_flat_dt_root();=0A+=0A=
+=09return of_flat_dt_is_compatible(root, "generic,mpc85xx-riodev");=0A+}=
=0A+=0A+define_machine(mpc85xx_riodev) {=0A+=09.name=09=09=09=3D "MPC85xx w=
/ SRIO",=0A+=09.probe=09=09=09=3D mpc85xx_riodev_probe,=0A+=09.setup_arch=
=09=09=3D mpc85xx_riodev_setup_arch,=0A+=09.init_IRQ=09=09=3D mpc85xx_riode=
v_pic_init,=0A+=09.show_cpuinfo=09=09=3D mpc85xx_riodev_show_cpuinfo,=0A+=
=09.get_irq=09=09=3D mpic_get_irq,=0A+=09.restart=09=09=3D fsl_rstcr_restar=
t,=0A+=09.calibrate_decr=09=09=3D generic_calibrate_decr,=0A+=09.progress=
=09=09=3D udbg_progress,=0A+};=0A-- =0A1.7.3.2=0A=0A=0A=0A=0A
^ permalink raw reply
* [PATCH 8/8] powerpc/kdump: Disable ftrace during kexec
From: Anton Blanchard @ 2011-01-07 4:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110107145255.72cf30ba@kryten>
We should disable ftrace during kexec, some of the tracers are very invasive
and we do not want them going off while doing the low level work of swapping
one kernel out for another. This mirrors what we do on x86.
Even though we cannot return from a kexec on powerpc (since we do not implement
CONFIG_KEXEC_JUMP), add the restore code in case we do one day.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/kernel/machine_kexec.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/machine_kexec.c 2011-01-07 12:51:56.222461754 +1100
+++ powerpc.git/arch/powerpc/kernel/machine_kexec.c 2011-01-07 12:52:02.012644243 +1100
@@ -15,6 +15,7 @@
#include <linux/memblock.h>
#include <linux/of.h>
#include <linux/irq.h>
+#include <linux/ftrace.h>
#include <asm/machdep.h>
#include <asm/prom.h>
@@ -82,8 +83,14 @@ void arch_crash_save_vmcoreinfo(void)
*/
void machine_kexec(struct kimage *image)
{
+ int save_ftrace_enabled;
+
+ save_ftrace_enabled = __ftrace_enabled_save();
+
default_machine_kexec(image);
+ __ftrace_enabled_restore(save_ftrace_enabled);
+
/* Fall back to normal restart if we're still alive. */
machine_restart(NULL);
for(;;);
^ 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