* Re: [LTP] mmapstress03 weirdness? (fwd)
From: Segher Boessenkool @ 2009-09-21 16:10 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux/PPC Development, Linux Kernel Development,
Linux Test Project
In-Reply-To: <alpine.LRH.2.00.0909211539520.16077@vixen.sonytel.be>
> if (mmap((caddr_t)(1UL << (POINTER_SIZE - 1)) - pagesize,
> (size_t)((1UL << (POINTER_SIZE - 1)) - pagesize),
> PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_FIXED|
> MAP_SHARED, 0, 0)
> != (caddr_t)-1)
> With 32-bit userland, this boils down to:
>
> | mmap addr 0x7fff0000 size 0x7fff0000
> | mmap returned 0x7fff0000
>
> i.e. mmap() succeeds,
Yes, on a powerpc64 kernel, every 32-bit userspace process has 4GB
available (well, except the lowest few pages). The process text sits
normally at 1M and the shared libs around 256M.
> but (1) the test expects it to fail, so the test returns
> TFAIL,
That's a bug in the test then.
> but (2) ltp-pan still reports that the tests passed?
Sounds like another bug.
> In addition, sometimes mmapstress03 fails due to SEGV. I created a
> small test
> program that just does the above mmap(), and depending on the
> distro and what
> else I print later it crashes with a SEGV, too. Probably this
> happens because
> the mmap() did succeed, and corrupted some existing mappings,
It probably killed the stack, which sits all the way up near 4G.
> JFYI, with 64-bit userland, this boils down to:
>
> | mmap addr 0x7fffffffffff0000 size 0x7fffffffffff0000
> | mmap returned 0xffffffffffffffff
>
> i.e. mmap() fails as expected, and the test succeeds.
It tries to map space that is reserved for the kernel (c000...)
> Does all of this sound OK?
Seems to me everything works fine, except the tests themselves.
Segher
^ permalink raw reply
* MPC8536 PCI rescan to discover FPGA
From: Felix Radensky @ 2009-09-21 15:35 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org list
Hi,
On a custom MPC8536 board running linux-2.6.31,
I'd like to load FPGA code from linux and then rescan
PCI-E bus to discover FPGA device. Is that possible ?
When linux boots FPGA is not loaded, so initial PCI
scan does not detect it.
I've tried playing with /sys/bus/pci/rescan and
/sys/bus/pci/devices/.../rescan
but didn't have much success.
Thanks.
Felix.
^ permalink raw reply
* High load average but low cpu (xenomai can be the explanation?)
From: dibacco @ 2009-09-21 15:13 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I have an MPC880 @133MHz. If I look into the load (with uptime) I get
values around 3.0 but my CPU is always under 5 percent (top). How could I
explain this? I'm using linux 2.6.19 with xenomai but no xenomai application is
running at all. I have a cramfs on a nor flash. What could be the problem? If I
kill the process I developed the average load goes down.
Thank you,
Adi
^ permalink raw reply
* RE: [PATCH] USB: Add support for Xilinx USB host controller
From: Julie Zhu @ 2009-09-21 14:41 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-usb, gregkh, linuxppc-dev, John Linn
In-Reply-To: <fa686aa40909210714j428aa524qacc7a83f40db411b@mail.gmail.com>
Thanks, Grant and Ben,
> > Add bus glue driver for Xilinx USB host controller. The controller can
> be
> > configured as HS only or HS/FS hybrid. The driver uses the device tree
> file
> > to configure the driver according to the setting in the hardware system=
.
> >
> > This driver has been tested with usbtest using the NET2280 PCI card.
> >
> > Signed-off-by: Julie Zhu <julie.zhu@xilinx.com>
> =
> As Ben said, this is nice tight code. Two comments below.
> =
> > +/**
> > + * ehci_xilinx_port_handed_over - hand the port out if failed to enabl=
e
> it
> > + * @hcd: =A0 =A0 =A0 Pointer to the usb_hcd device to which the host
> controller bound
> > + * @portnum:Port number to which the device is attached.
> > + *
> > + * This function is used as a place to tell the user that the Xilinx
> USB host
> > + * controller does support LS devices. And in an HS only configuration=
,
> it
> > + * does not support FS devices neither. It is hoped that this can help=
> a
> =
> s/neither/either
> =
> [...]
> > +static struct of_device_id ehci_hcd_xilinx_of_match[] =3D {
> > + =A0 =A0 =A0 {
> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 .compatible =3D "usb-ehci",
> > + =A0 =A0 =A0 },
> =
> This looks wrong. Since this driver only works with Xilinx USB
> controllers,
> it should be binding against "xlnx,xps-usb-host-1.00.a", and the meaning
> of
> that binding needs to be documented in Documentation/powerpc/dts-bindings=
.
> =
I have changed the compatible to "xlnx,xps-usb-host-1.00.a", thanks for cat=
ching this.
Where should I put the binding for Xilinx USB host controller? usb-ehci.txt=
or xilinx.txt?
Thanks,
Julie.
> Having this driver bind against the generic "usb-ehci" will cause
> conflicts
> with the ehci-ppc-of driver.
> =
> Cheers,
> g.
> =
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* [LTP] mmapstress03 weirdness? (fwd)
From: Geert Uytterhoeven @ 2009-09-21 13:40 UTC (permalink / raw)
To: Linux/PPC Development, Linux Kernel Development; +Cc: Linux Test Project
---------- Forwarded message ----------
Date: Wed, 16 Sep 2009 18:37:12 +0200 (CEST)
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
To: Linux Test Project <Ltp-list@lists.sourceforge.net>
Subject: [LTP] mmapstress03 weirdness?
On ppc64, with 32-bit userland, I get:
| Running tests.......
| <<<test_start>>>
| tag=mmapstress03 stime=1253117251
| cmdline="mmapstress03"
| contacts=""
| analysis=exit
| <<<test_output>>>
| incrementing stop
| : errno = 0: really large mmap didn't fail
| mmapstress03 1 TFAIL : Test failed
^^^^^^^^^^^^^^^^^^^^^
| <<<execution_status>>>
| initiation_status="ok"
| duration=0 termination_type=exited termination_id=0 corefile=no
| cutime=0 cstime=0
| <<<test_end>>>
| INFO: ltp-pan reported all tests PASS
^^^^
The core part of this test is:
/* Ask for a ridiculously large mmap region at a high address */
if (mmap((caddr_t)(1UL << (POINTER_SIZE - 1)) - pagesize,
(size_t)((1UL << (POINTER_SIZE - 1)) - pagesize),
PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_FIXED|MAP_SHARED, 0, 0)
!= (caddr_t)-1)
{
ERROR("really large mmap didn't fail");
anyfail();
}
if (errno != ENOMEM && errno != EINVAL) {
ERROR("really large mmap didn't set errno = ENOMEM nor EINVAL");
anyfail();
}
With 32-bit userland, this boils down to:
| mmap addr 0x7fff0000 size 0x7fff0000
| mmap returned 0x7fff0000
i.e. mmap() succeeds, but (1) the test expects it to fail, so the test returns
TFAIL, but (2) ltp-pan still reports that the tests passed?
In addition, sometimes mmapstress03 fails due to SEGV. I created a small test
program that just does the above mmap(), and depending on the distro and what
else I print later it crashes with a SEGV, too. Probably this happens because
the mmap() did succeed, and corrupted some existing mappings, cfr. the notes
for MAP_FIXED:
MAP_FIXED
Don’t interpret addr as a hint: place the mapping at exactly
that address. addr must be a multiple of the page size. If the
memory region specified by addr and len overlaps pages of any
existing mapping(s), then the overlapped part of the existing
mapping(s) will be discarded. If the specified address cannot
be used, mmap() will fail. Because requiring a fixed address
for a mapping is less portable, the use of this option is dis‐
couraged.
JFYI, with 64-bit userland, this boils down to:
| mmap addr 0x7fffffffffff0000 size 0x7fffffffffff0000
| mmap returned 0xffffffffffffffff
i.e. mmap() fails as expected, and the test succeeds.
Does all of this sound OK?
Thanks for your comments!
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH] USB: Add support for Xilinx USB host controller
From: Grant Likely @ 2009-09-21 14:46 UTC (permalink / raw)
To: Julie Zhu; +Cc: linux-usb, gregkh, linuxppc-dev, John Linn
In-Reply-To: <20090921144131.1C1A31078051@mail56-sin.bigfish.com>
On Mon, Sep 21, 2009 at 7:41 AM, Julie Zhu <julie.zhu@xilinx.com> wrote:
> I have changed the compatible to "xlnx,xps-usb-host-1.00.a", thanks for catching this.
>
> Where should I put the binding for Xilinx USB host controller? usb-ehci.txt or xilinx.txt?
Probably xilinx.txt.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] sbc8548: fixup of PCI-e related DTS fields
From: Paul Gortmaker @ 2009-09-21 14:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <8549256E-05F8-4990-866F-EB73C048E462@kernel.crashing.org>
The PCI-e addressing was originally patterned of the MPC8548CDS
which has PCI1, PCI2, and PCI-e. Since this board only has
PCI1 and PCI-e, it makes more sense to be similar to the MPC8568MDS
board. This does that by cutting the PCI/PCI-e I/O sizes from
16MB to 8MB and pulling the PCI-e I/O range back to 0xe280_0000
(the hole where PCI2 I/O would have been).
This also fixes a typo where an extra zero made an 8MB range a 128MB
range, removes the hole left by PCI2 from the aliases, and sets the
clocks to match the oscillators that are actually on the board.
With accompanying u-boot updates, PCI-e has been validated with
both a sky2 card (1148:9e00) and an e1000 card (8086:108b).
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
v2: cosmetic; fix leading zeros on 0x00800000 for better readability
arch/powerpc/boot/dts/sbc8548.dts | 17 ++++++++---------
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/boot/dts/sbc8548.dts b/arch/powerpc/boot/dts/sbc8548.dts
index 9eefe00..94a3322 100644
--- a/arch/powerpc/boot/dts/sbc8548.dts
+++ b/arch/powerpc/boot/dts/sbc8548.dts
@@ -26,8 +26,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
- /* pci1 doesn't have a corresponding physical connector */
- pci2 = &pci2;
+ pci1 = &pci1;
};
cpus {
@@ -381,7 +380,7 @@
bus-range = <0 0>;
ranges = <0x02000000 0x0 0x80000000 0x80000000 0x0 0x10000000
0x01000000 0x0 0x00000000 0xe2000000 0x0 0x00800000>;
- clock-frequency = <66666666>;
+ clock-frequency = <66000000>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
@@ -390,7 +389,7 @@
device_type = "pci";
};
- pci2: pcie@e000a000 {
+ pci1: pcie@e000a000 {
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
@@ -403,9 +402,9 @@
interrupt-parent = <&mpic>;
interrupts = <0x1a 0x2>;
bus-range = <0x0 0xff>;
- ranges = <0x02000000 0x0 0xa0000000 0xa0000000 0x0 0x20000000
- 0x01000000 0x0 0x00000000 0xe3000000 0x0 0x08000000>;
- clock-frequency = <33333333>;
+ ranges = <0x02000000 0x0 0xa0000000 0xa0000000 0x0 0x10000000
+ 0x01000000 0x0 0x00000000 0xe2800000 0x0 0x08000000>;
+ clock-frequency = <33000000>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
@@ -419,11 +418,11 @@
device_type = "pci";
ranges = <0x02000000 0x0 0xa0000000
0x02000000 0x0 0xa0000000
- 0x0 0x20000000
+ 0x0 0x10000000
0x01000000 0x0 0x00000000
0x01000000 0x0 0x00000000
- 0x0 0x08000000>;
+ 0x0 0x00800000>;
};
};
};
--
1.6.4.1
^ permalink raw reply related
* Re: PPC_4xx synopsy USB driver
From: Stefan Roese @ 2009-09-21 14:24 UTC (permalink / raw)
To: Cote, Sylvain; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <579B119545DAEF4689C8FBEEFEC5793F01FA07D05186@ATLMBX.verint.corp.verintsystems.com>
On Monday 21 September 2009 15:44:30 Cote, Sylvain wrote:
> > Looks good so far. I suspect that the only thing missing for your 405EX
> > custom
> > board is the following line in the arch/powerpc/sysdev/Makefile:
> >
> > obj-$(CONFIG_KILAUEA) += amcc-usbotg.o
>
> I have created a new platform (platform using 405ex). I have missed this
> one for my new platform. Do you know if there is a compilation switch
> that could be more generic (like CONFIG_40x) for the usbotg?
Yes, it would probably make sense to just use
obj-$(CONFIG_USB_DWC_OTG) += amcc-usbotg.o
here. I'll change this soon.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: [PATCH] USB: Add support for Xilinx USB host controller
From: Grant Likely @ 2009-09-21 14:14 UTC (permalink / raw)
To: Julie Zhu; +Cc: linux-usb, gregkh, juliez, linuxppc-dev, john.linn
In-Reply-To: <20090915221050.0DA0F2C005E@mail34-va3.bigfish.com>
On Tue, Sep 15, 2009 at 3:10 PM, Julie Zhu <julie.zhu@xilinx.com> wrote:
> Add bus glue driver for Xilinx USB host controller. The controller can be
> configured as HS only or HS/FS hybrid. The driver uses the device tree fi=
le
> to configure the driver according to the setting in the hardware system.
>
> This driver has been tested with usbtest using the NET2280 PCI card.
>
> Signed-off-by: Julie Zhu <julie.zhu@xilinx.com>
As Ben said, this is nice tight code. Two comments below.
> +/**
> + * ehci_xilinx_port_handed_over - hand the port out if failed to enable =
it
> + * @hcd: =A0 =A0 =A0 Pointer to the usb_hcd device to which the host con=
troller bound
> + * @portnum:Port number to which the device is attached.
> + *
> + * This function is used as a place to tell the user that the Xilinx USB=
host
> + * controller does support LS devices. And in an HS only configuration, =
it
> + * does not support FS devices neither. It is hoped that this can help a
s/neither/either
[...]
> +static struct of_device_id ehci_hcd_xilinx_of_match[] =3D {
> + =A0 =A0 =A0 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 .compatible =3D "usb-ehci",
> + =A0 =A0 =A0 },
This looks wrong. Since this driver only works with Xilinx USB controllers=
,
it should be binding against "xlnx,xps-usb-host-1.00.a", and the meaning of
that binding needs to be documented in Documentation/powerpc/dts-bindings.
Having this driver bind against the generic "usb-ehci" will cause conflicts
with the ehci-ppc-of driver.
Cheers,
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: PPC_4xx synopsy USB driver
From: Cote, Sylvain @ 2009-09-21 13:44 UTC (permalink / raw)
To: Stefan Roese, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <200909210713.29238.sr@denx.de>
Hi Stefan,
On Friday 18 September 2009 17:50:24 Cote, Sylvain wrote:
> USB gadget support --> y
> Maximum VBUS power usage =3D 500
> Synopsys DWC OTG controller
> Synopsys DWC OTG internal DMA mode --> y
> USB gadget --> M
> gadget zero --> M
> Ethernet Gadget --> M
> RNDIS support --> y
>=20
> Any help will be appreciated
> Looks good so far. I suspect that the only thing missing for your 405EX=20
> custom=20
> board is the following line in the arch/powerpc/sysdev/Makefile:
> obj-$(CONFIG_KILAUEA) +=3D amcc-usbotg.o
I have created a new platform (platform using 405ex). I have missed this o=
ne for my new platform. Do you know if there is a compilation switch that =
could be more generic (like CONFIG_40x) for the usbotg?
> to enable the device-tree to platform-device driver wrapper for the USB-
> OTG=20
> resources.
Thanks you,
Your help has been appreciated.
Sylvain
This electronic message may contain proprietary and confidential informat=
ion of Verint Systems Inc., its affiliates and/or subsidiaries.
The information is intended to be for the use of the individual(s) or
entity(ies) named above. If you are not the intended recipient (or autho=
rized to receive this e-mail for the intended recipient), you may not use=
, copy, disclose or distribute to anyone this message or any information =
contained in this message. If you have received this electronic message =
in error, please notify us by replying to this e-mail.
=0D
^ permalink raw reply
* Re: [PATCH] perf_counter/powerpc: Fix compilation after perf_counter_overflow change
From: Paul Mackerras @ 2009-09-21 11:19 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Peter Zijlstra, linux-kernel, Markus Metzger, linuxppc-dev
In-Reply-To: <20090921071127.GA24467@elte.hu>
Ingo Molnar writes:
> Paul, you might also want to test the perfcounter bits of -tip on
> PowerPC a bit more frequently - this patch was there for 5 days before i
> sent it to Linus.
Yes, I'll try to do that in future.
I hope I didn't come across as blaming anyone for anything - that
wasn't my intention at all.
> Cross-builds didnt catch it as perfcounters isnt enabled by default in
> any of the powerpc defconfigs:
I'll get that fixed too.
Paul.
^ permalink raw reply
* Re: [PATCH] USB: Add support for Xilinx USB host controller
From: Benjamin Herrenschmidt @ 2009-09-21 10:23 UTC (permalink / raw)
To: Julie Zhu; +Cc: linux-usb, gregkh, juliez, linuxppc-dev, john.linn
In-Reply-To: <20090915221050.0DA0F2C005E@mail34-va3.bigfish.com>
On Tue, 2009-09-15 at 16:10 -0600, Julie Zhu wrote:
> Add bus glue driver for Xilinx USB host controller. The controller can be
> configured as HS only or HS/FS hybrid. The driver uses the device tree file
> to configure the driver according to the setting in the hardware system.
>
> This driver has been tested with usbtest using the NET2280 PCI card.
>
> Signed-off-by: Julie Zhu <julie.zhu@xilinx.com>
Hi !
First, this is a very clean piece of code, thanks.
Just a few minor nits:
> static int ehci_xilinx_port_handed_over(struct usb_hcd *hcd, int portnum)
> +{
> + dev_warn(hcd->self.controller, "port %d cannot be enabled\n", portnum);
> + if (hcd->has_tt) {
> + dev_warn(hcd->self.controller,
> + "Maybe you have connected an LS device?\n");
> +
> + dev_warn(hcd->self.controller,
> + "We do not support LS devices\n");
> + } else {
> + dev_warn(hcd->self.controller,
> + "Maybe your device is not an HS device?\n");
> + dev_warn(hcd->self.controller,
> + "The USB host controller does not support FS or "
> + "LS devices\n");
> + dev_warn(hcd->self.controller,
> + "You can reconfigure the host controller to have "
> + "FS support\n");
> + }
> +
> + return 0;
> +}
I'm not sure the final users would know what "FS", "LS" or "HS" mean
here, it might be worth being a -tad- more verbose :-)
.../...
> +
> +/**
> + * ehci_hcd_xilinx_of_remove - shutdown hcd and release resources
> + * @op: pointer to of_device structure that is to be removed
> + *
> + * Remove the hcd structure, and release resources that has been requested
> + * during probe.
> + */
> +static int ehci_hcd_xilinx_of_remove(struct of_device *op)
> +{
> + struct usb_hcd *hcd = dev_get_drvdata(&op->dev);
> + dev_set_drvdata(&op->dev, NULL);
> +
> + dev_dbg(&op->dev, "stopping XILINX-OF USB Controller\n");
> +
> + usb_remove_hcd(hcd);
> +
> + iounmap(hcd->regs);
> + irq_dispose_mapping(hcd->irq);
You don't need to dispose of the irq mapping, and in fact, it could be
harmful if the interrupt is shared, as we don't refcount the mapping
users. Just remove the line above. The mapping doesn't really use
resources (well, it depends on your PIC but even then, it's minor) so
it's better, once a HW IRQ number has been associated to a linux IRQ
number, to keep that association for the lifetime of the kernel.
Cheers,
Ben.
^ permalink raw reply
* Re: Linux booting issue on powerpc 440x5
From: Benjamin Herrenschmidt @ 2009-09-21 9:52 UTC (permalink / raw)
To: Sumesh Kaana; +Cc: linuxppc-dev
In-Reply-To: <BLU124-W15B59AFF88DB52C03BD481B4E00@phx.gbl>
On Fri, 2009-09-18 at 09:31 +0000, Sumesh Kaana wrote:
>
>
> Hi,
>
>
> I am trying to boot linux kernel (2.6.30) on PPC440x5 processor in a
> custom built board. I am using simple ppc platform.
>
>
> I have a small bootloader which will only copy the
> simpleImage.myboard.bin to 0x400000 location of my SRAM from the
> flash.
>
>
> SRAM is only 16MB and bootloader creates one and only TLB of 16MB
>
The 440 kernel is meant to be run from memory physical address 0 in main
memory. It's not capable of relocating itself there, so I wouldn't be
surprised that this is the source of your problem.
Ben.
> I am getting "Kernel access of bad area, sig: 11 [#1]" while kernel is
> booting.
>
>
> kernel crashes in different places, for different compilation
>
>
> Bellow given are 2 dumps of kernel crash
>
>
> In DUMP1, in back trace, execution flow is shown like,
>
>
> Start_kernel() --> sort_main_extable() --> sort_extable(). and sort
> extable calls some functions whose name is not mentioned.
>
>
> Why is it not able to get the name of the function.?
>
>
> i went through the 'objdump' of the kernel, I don't know whether it
> can help me somehow, it looked like this
>
>
> --
> c018c730: 48 00 71 9d bl c01938cc <sort_main_extable>
> c018c734: 48 00 3e 3d bl c0190570 <trap_init>
> --
> c01938e8: 4b f7 10 f1 bl c01049d8 <sort_extable>
> c01938ec: 80 01 00 14 lwz r0,20(r1)
> --
> c01049fc: 48 00 8d 99 bl c010d794 <sort>
> c0104a00: 80 01 00 14 lwz r0,20(r1)
> --
> c016b99c: 42 6f 6f 74 bc+ 18,4*cr3+so,c0172910
> <kallsyms_token_index+0x7400>
> --
>
>
> Could this be problem with "kallsyms"..? Because sort_extable() calls
> sort() which is an exported function defined in linux-2.6.30\lib
> \sort.c
>
>
> when i checked 'objdump' of the kernel, i could see the usage of a
> preserved opcode of ppc440x5 (code: eciwx).
>
>
> I tried compiling the kernel with "kallsyms" disabled, that also did
> not work.
>
>
> In DUMP2, backtrace is not able to identify the name of 'caller' of
> unflatten_device_tree(). The caller is mentioned as "[00000000]
> (null)"
>
>
> Could this be a stack problem, like stack pointer getting corrupted.?
>
>
> At last, could this be a hardware problem(expecting to be memory
> problem)..?
>
>
> Can you tell me if i am missing something.?
>
>
> thanks,
> Shyju. N
>
>
>
>
> -------------------------DUMP 1------------------------------------
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> bootmemarch: exit
> <7>Top of RAM: 0x1000000, Total RAM: 0x1000000
> Zone PFN ranges:
> DMA 0x00000000 -> 0x00001000
> Normal 0x00001000 -> 0x00001000
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0x00000000 -> 0x00001000
> MMU: Allocated 1088 bytes of context maps for 255 contexts
> Built 1 zonelists in Zone order, mobility grouping off. Total pages:
> 4064
> Kernel command line: console=ttyS0 root=/dev/ram
> Unable to handle kernel paging request for data at address 0x00021000
> Faulting instruction address: 0xc010a7c4
> Oops: Kernel access of bad area, sig: 11 [#1]
> PREEMPT PowerPC 44x Platform
> Modules linked in:
> NIP: c010a7c4 LR: c010dc50 CTR: 00000000
> REGS: c01bfeb0 TRAP: 0300 Not tainted (2.6.30)
> MSR: 00021000 <ME,CE> CR: 24000044 XER: 00000000
> DEAR: 00021000, ESR: 00000000
> TASK = c01a94b8[0] 'swapper' THREAD: c01be000
> GPR00: 00001180 c01bff60 c01a94b8 00021000 00000025 00000008 c0104968
> 00000000
> GPR08: 2f72616d c0110000 c0155938 c01a0000 22000024 00000000 fffff104
> 00000000
> GPR16: 00000000 00000000 00000000 00000000 fffffff8 000008b8 c010d758
> c0104968
> GPR24: 00001198 00001190 c018a001 c01c5498 000008c0 00001188 00021000
> c01c42f0
> NIP [c010a7c4] strchr+0x0/0x3c
> LR [c010dc50] match_token+0x138/0x228
> Call Trace:
> [c01bff60] [c016b99c] 0xc016b99c (unreliable)
> [c01bffa0] [c0104a00] sort_extable+0x28/0x38
> [c01bffb0] [c01938ec] sort_main_extable+0x20/0x30
> [c01bffc0] [c018c734] start_kernel+0x140/0x288
> [c01bfff0] [c0000200] skpinv+0x190/0x1cc
> Instruction dump:
> 7ca903a6 88040000 38a5ffff 38840001 2f800000 98090000 39290001
> 419e0010
> 4200ffe4 98a90000 4e800020 4e800020 <88030000> 5484063e 7f802000
> 4d9e0020
> ---[ end trace 31fd0ba7d8756001 ]---
> Kernel panic - not syncing: Attempted to kill the idle task!
> Call Trace:
> [c01bfd90] [c0005d5c] show_stack+0x4c/0x16c (unreliable)
> [c01bfdd0] [c002f17c] panic+0xa0/0x168
> [c01bfe20] [c0032eb8] do_exit+0x61c/0x638
> [c01bfe60] [c000b60c] kernel_bad_stack+0x0/0x4c
> [c01bfe90] [c000f310] bad_page_fault+0x90/0xd8
> [c01bfea0] [c000e184] handle_page_fault+0x7c/0x80
> [c01bff60] [c016b99c] 0xc016b99c
> [c01bffa0] [c0104a00] sort_extable+0x28/0x38
> [c01bffb0] [c01938ec] sort_main_extable+0x20/0x30
> [c01bffc0] [c018c734] start_kernel+0x140/0x288
> [c01bfff0] [c0000200] skpinv+0x190/0x1cc
> Rebooting in 180 seconds..
> -------------------------------------------------------------------
>
>
> -------------------------DUMP 2------------------------------------
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> <1>Unable to handle kernel paging request for data at address
> 0x40ee8053
> Faulting instruction address: 0xc018ff44
> Oops: Kernel access of bad area, sig: 11 [#1]
> PREEMPT PowerPC 44x Platform
> Modules linked in:
> NIP: c018ff44 LR: c018ff20 CTR: 00000000
> REGS: c01bfe10 TRAP: 0300 Not tainted (2.6.30)
> MSR: 00021000 <ME,CE> CR: 44088024 XER: 00000000
> DEAR: 40ee8053, ESR: 00800000
> TASK = c01a94b8[0] 'swapper' THREAD: c01be000
> GPR00: c0ffea58 c01bfec0 c01a94b8 c0ffea6e c04eb3aa 00000003 c0ffea74
> 00000000
> GPR08: 00000000 40ee802f c04eb3a0 c01bfec8 24082022 00000000 fffff104
> 00000000
> GPR16: 00000000 c016cfe8 c016cfd8 c0170cbc c01bfec8 c0ffea24 c04eb3a4
> c04eb3a0
> GPR24: 00000008 c01bff8c c04eb33c c0ffea2c 00000007 c01bff88 c0ffe984
> c0ffea6d
> NIP [c018ff44] unflatten_dt_node+0x158/0x520
> LR [c018ff20] unflatten_dt_node+0x134/0x520
> Call Trace:
> [c01bff20] [c019023c] unflatten_dt_node+0x450/0x520
> [c01bff80] [c01903b4] unflatten_device_tree+0xa8/0x13c
> [c01bffb0] [00000000] (null)
> Instruction dump:
> 7f85e378 7ec4b378 4be81b55 81390000 381b002c 93690000 90190000
> 4192001c
> 813e0028 93db001c 2f890000 419e03b4 <93690024> 937e0028 387b0034
> 3abb0014
> ---[ end trace 31fd0ba7d8756001 ]---
> Kernel panic - not syncing: Attempted to kill the idle task!
> Call Trace:
> [c01bfcf0] [c0005d5c] show_stack+0x4c/0x16c (unreliable)
> [c01bfd30] [c002f17c] panic+0xa0/0x168
> [c01bfd80] [c0032eb8] do_exit+0x61c/0x638
> [c01bfdc0] [c000b60c] kernel_bad_stack+0x0/0x4c
> [c01bfdf0] [c000f310] bad_page_fault+0x90/0xd8
> [c01bfe00] [c000e184] handle_page_fault+0x7c/0x80
> [c01bfec0] [00000000] (null)
> [c01bff20] [c019023c] unflatten_dt_node+0x450/0x520
> [c01bff80] [c01903b4] unflatten_device_tree+0xa8/0x13c
> [c01bffb0] [00000000] (null)
> -------------------------------------------------------------------
>
>
>
>
>
>
>
>
> ______________________________________________________________________
> Let us find your next place for you! Need a place to rent, buy or
> share?
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] sbc8548: fixup of PCI-e related DTS fields
From: Segher Boessenkool @ 2009-09-21 9:34 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <1253494142-26821-1-git-send-email-paul.gortmaker@windriver.com>
> - 0x0 0x08000000>;
> + 0x0 0x0800000>;
You might want to write that as 0x00800000, otherwise people
will think it says 128M still :-)
Segher
^ permalink raw reply
* Re: [PATCH] perf_counter/powerpc: Fix compilation after perf_counter_overflow change
From: Ingo Molnar @ 2009-09-21 7:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Peter Zijlstra, linux-kernel, Markus Metzger, linuxppc-dev
In-Reply-To: <19127.8400.376239.586120@drongo.ozlabs.ibm.com>
* Paul Mackerras <paulus@samba.org> wrote:
> Commit 5622f295 ("x86, perf_counter, bts: Optimize BTS overflow
> handling") removed the regs field from struct perf_sample_data and
> added a regs parameter to perf_counter_overflow(). This breaks the
> build on powerpc as reported by Sachin Sant:
>
> arch/powerpc/kernel/perf_counter.c: In function 'record_and_restart':
> arch/powerpc/kernel/perf_counter.c:1165: error: unknown field 'regs' specified in initializer
> cc1: warnings being treated as errors
> arch/powerpc/kernel/perf_counter.c:1165: error: initialization makes integer from pointer without a cast
> arch/powerpc/kernel/perf_counter.c:1173: error: too few arguments to function 'perf_counter_overflow'
> make[1]: *** [arch/powerpc/kernel/perf_counter.o] Error 1
> make: *** [arch/powerpc/kernel] Error 2
>
> This adjusts arch/powerpc/kernel/perf_counter.c to correspond with the
> new struct perf_sample_data and perf_counter_overflow().
>
> Reported-by: Sachin Sant <sachinp@in.ibm.com>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
Applied, thanks Paul.
> ---
>
> I missed this problem when the "x86, perf_counter, bts: Optimize BTS
> overflow handling" patch was posted because the headline made it seem
> entirely x86-specific, and the changes to struct perf_sample_data and
> perf_counter_overflow() were not mentioned in the changelog.
>
> Markus, please take care in future to mention it in the changelog if
> your patches touch definitions used by other architectures. If you
> could go so far as to use grep a bit more and fix up other
> architectures' callsites for the things you're changing, that would be
> very much appreciated. Thanks.
Yes, that should be done in general - still, nothing beats actual
testing.
Paul, you might also want to test the perfcounter bits of -tip on
PowerPC a bit more frequently - this patch was there for 5 days before i
sent it to Linus.
Cross-builds didnt catch it as perfcounters isnt enabled by default in
any of the powerpc defconfigs:
phoenix:~/linux/linux> grep -w CONFIG_PERF_COUNTERS arch/powerpc/configs/*
arch/powerpc/configs/adder875_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/c2k_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/ep8248e_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/ep88xc_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/linkstation_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mgcoge_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mgsuvd_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mpc7448_hpc2_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mpc8272_ads_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mpc83xx_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mpc85xx_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mpc85xx_smp_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mpc866_ads_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mpc86xx_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/mpc885_ads_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/pq2fads_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/prpmc2800_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/ps3_defconfig:# CONFIG_PERF_COUNTERS is not set
arch/powerpc/configs/storcenter_defconfig:# CONFIG_PERF_COUNTERS is not set
There's not that many PowerPC users so all extra testing help would be
much welcome. Also, enabling them in the powerpc defconfigs would be
helpful as well.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH] perf_counter/powerpc: Fix compilation after perf_counter_overflow change
From: Ingo Molnar @ 2009-09-21 7:45 UTC (permalink / raw)
To: Heiko Carstens
Cc: Peter Zijlstra, linux-kernel@vger.kernel.org, Metzger, Markus T,
linuxppc-dev@ozlabs.org, Paul Mackerras, David S. Miller
In-Reply-To: <20090921073848.GA4649@osiris.boeblingen.de.ibm.com>
* Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> On Mon, Sep 21, 2009 at 09:30:43AM +0200, Ingo Molnar wrote:
> >
> > * Metzger, Markus T <markus.t.metzger@intel.com> wrote:
> >
> > > >-----Original Message-----
> > > >From: Paul Mackerras [mailto:paulus@samba.org]
> > > >Sent: Monday, September 21, 2009 8:45 AM
> > >
> > >
> > > >Markus, please take care in future to mention it in the changelog if
> > > >your patches touch definitions used by other architectures. If you
> > > >could go so far as to use grep a bit more and fix up other
> > > >architectures' callsites for the things you're changing, that would be
> > > >very much appreciated. Thanks.
> > >
> > > I'm sorry I missed that.
> > >
> > > There's one more place in arch/sparc/.
> > > The below patch should fix it, but I have no means to test it.
> >
> > You also missed a third thing:
> >
> > +static inline int
> > +perf_output_begin(struct perf_output_handle *handle, struct perf_counter *c,
> > + unsigned int size, int nmi, int sample) { }
> >
> > an 'int' function returning void ...
> >
> > Plus all the !PERF_COUNTERS branch of empty inlines is pointless - these
> > facilities are used by perfcounters code only. I fixed that too.
>
> Hi Ingo,
>
> did you fix all of these warnings for !PERF_COUNTERS?
>
> include/linux/perf_counter.h: In function 'perf_output_begin':
> include/linux/perf_counter.h:854: warning: no return statement in function returning non-void
> include/linux/perf_counter.h: At top level:
> include/linux/perf_counter.h:863: warning: 'struct perf_sample_data' declared inside parameter list
> include/linux/perf_counter.h:863: warning: its scope is only this definition or declaration, which is probably not what you want
> include/linux/perf_counter.h:868: warning: 'struct perf_sample_data' declared inside parameter list
Yes. The full commit is below.
Ingo
---------------->
>From cd74c86bdf705f824d494a2bbda393d1d562b40a Mon Sep 17 00:00:00 2001
From: Paul Mackerras <paulus@samba.org>
Date: Mon, 21 Sep 2009 16:44:32 +1000
Subject: [PATCH] perf_counter, powerpc, sparc: Fix compilation after perf_counter_overflow() change
Commit 5622f295 ("x86, perf_counter, bts: Optimize BTS overflow
handling") removed the regs field from struct perf_sample_data and
added a regs parameter to perf_counter_overflow(). This breaks the
build on powerpc (and Sparc) as reported by Sachin Sant:
arch/powerpc/kernel/perf_counter.c: In function 'record_and_restart':
arch/powerpc/kernel/perf_counter.c:1165: error: unknown field 'regs' specified in initializer
This adjusts arch/powerpc/kernel/perf_counter.c to correspond with the
new struct perf_sample_data and perf_counter_overflow().
[ v2: also fix Sparc, Markus Metzger <markus.t.metzger@intel.com> ]
Reported-by: Sachin Sant <sachinp@in.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Cc: Markus Metzger <markus.t.metzger@intel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: benh@kernel.crashing.org
Cc: linuxppc-dev@ozlabs.org
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <19127.8400.376239.586120@drongo.ozlabs.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/powerpc/kernel/perf_counter.c | 3 +--
arch/sparc/kernel/perf_counter.c | 3 +--
include/linux/perf_counter.h | 17 -----------------
3 files changed, 2 insertions(+), 21 deletions(-)
diff --git a/arch/powerpc/kernel/perf_counter.c b/arch/powerpc/kernel/perf_counter.c
index 7ceefaf..5ccf9bc 100644
--- a/arch/powerpc/kernel/perf_counter.c
+++ b/arch/powerpc/kernel/perf_counter.c
@@ -1162,7 +1162,6 @@ static void record_and_restart(struct perf_counter *counter, unsigned long val,
*/
if (record) {
struct perf_sample_data data = {
- .regs = regs,
.addr = 0,
.period = counter->hw.last_period,
};
@@ -1170,7 +1169,7 @@ static void record_and_restart(struct perf_counter *counter, unsigned long val,
if (counter->attr.sample_type & PERF_SAMPLE_ADDR)
perf_get_data_addr(regs, &data.addr);
- if (perf_counter_overflow(counter, nmi, &data)) {
+ if (perf_counter_overflow(counter, nmi, &data, regs)) {
/*
* Interrupts are coming too fast - throttle them
* by setting the counter to 0, so it will be
diff --git a/arch/sparc/kernel/perf_counter.c b/arch/sparc/kernel/perf_counter.c
index 09de403..b1265ce 100644
--- a/arch/sparc/kernel/perf_counter.c
+++ b/arch/sparc/kernel/perf_counter.c
@@ -493,7 +493,6 @@ static int __kprobes perf_counter_nmi_handler(struct notifier_block *self,
regs = args->regs;
- data.regs = regs;
data.addr = 0;
cpuc = &__get_cpu_var(cpu_hw_counters);
@@ -513,7 +512,7 @@ static int __kprobes perf_counter_nmi_handler(struct notifier_block *self,
if (!sparc_perf_counter_set_period(counter, hwc, idx))
continue;
- if (perf_counter_overflow(counter, 1, &data))
+ if (perf_counter_overflow(counter, 1, &data, regs))
sparc_pmu_disable_counter(hwc, idx);
}
diff --git a/include/linux/perf_counter.h b/include/linux/perf_counter.h
index bd34100..740caad 100644
--- a/include/linux/perf_counter.h
+++ b/include/linux/perf_counter.h
@@ -849,23 +849,6 @@ static inline void perf_counter_comm(struct task_struct *tsk) { }
static inline void perf_counter_fork(struct task_struct *tsk) { }
static inline void perf_counter_init(void) { }
-static inline int
-perf_output_begin(struct perf_output_handle *handle, struct perf_counter *c,
- unsigned int size, int nmi, int sample) { }
-static inline void perf_output_end(struct perf_output_handle *handle) { }
-static inline void
-perf_output_copy(struct perf_output_handle *handle,
- const void *buf, unsigned int len) { }
-static inline void
-perf_output_sample(struct perf_output_handle *handle,
- struct perf_event_header *header,
- struct perf_sample_data *data,
- struct perf_counter *counter) { }
-static inline void
-perf_prepare_sample(struct perf_event_header *header,
- struct perf_sample_data *data,
- struct perf_counter *counter,
- struct pt_regs *regs) { }
#endif
#define perf_output_put(handle, x) \
^ permalink raw reply related
* Re: [PATCH] perf_counter/powerpc: Fix compilation after perf_counter_overflow change
From: Heiko Carstens @ 2009-09-21 7:38 UTC (permalink / raw)
To: Ingo Molnar
Cc: Peter Zijlstra, linux-kernel@vger.kernel.org, Metzger, Markus T,
linuxppc-dev@ozlabs.org, Paul Mackerras, David S. Miller
In-Reply-To: <20090921073043.GB24467@elte.hu>
On Mon, Sep 21, 2009 at 09:30:43AM +0200, Ingo Molnar wrote:
>
> * Metzger, Markus T <markus.t.metzger@intel.com> wrote:
>
> > >-----Original Message-----
> > >From: Paul Mackerras [mailto:paulus@samba.org]
> > >Sent: Monday, September 21, 2009 8:45 AM
> >
> >
> > >Markus, please take care in future to mention it in the changelog if
> > >your patches touch definitions used by other architectures. If you
> > >could go so far as to use grep a bit more and fix up other
> > >architectures' callsites for the things you're changing, that would be
> > >very much appreciated. Thanks.
> >
> > I'm sorry I missed that.
> >
> > There's one more place in arch/sparc/.
> > The below patch should fix it, but I have no means to test it.
>
> You also missed a third thing:
>
> +static inline int
> +perf_output_begin(struct perf_output_handle *handle, struct perf_counter *c,
> + unsigned int size, int nmi, int sample) { }
>
> an 'int' function returning void ...
>
> Plus all the !PERF_COUNTERS branch of empty inlines is pointless - these
> facilities are used by perfcounters code only. I fixed that too.
Hi Ingo,
did you fix all of these warnings for !PERF_COUNTERS?
include/linux/perf_counter.h: In function 'perf_output_begin':
include/linux/perf_counter.h:854: warning: no return statement in function returning non-void
include/linux/perf_counter.h: At top level:
include/linux/perf_counter.h:863: warning: 'struct perf_sample_data' declared inside parameter list
include/linux/perf_counter.h:863: warning: its scope is only this definition or declaration, which is probably not what you want
include/linux/perf_counter.h:868: warning: 'struct perf_sample_data' declared inside parameter list
^ permalink raw reply
* Re: [PATCH] perf_counter/powerpc: Fix compilation after perf_counter_overflow change
From: Ingo Molnar @ 2009-09-21 7:30 UTC (permalink / raw)
To: Metzger, Markus T, David S. Miller
Cc: Peter Zijlstra, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77EC69BA5E0@irsmsx504.ger.corp.intel.com>
* Metzger, Markus T <markus.t.metzger@intel.com> wrote:
> >-----Original Message-----
> >From: Paul Mackerras [mailto:paulus@samba.org]
> >Sent: Monday, September 21, 2009 8:45 AM
>
>
> >Markus, please take care in future to mention it in the changelog if
> >your patches touch definitions used by other architectures. If you
> >could go so far as to use grep a bit more and fix up other
> >architectures' callsites for the things you're changing, that would be
> >very much appreciated. Thanks.
>
> I'm sorry I missed that.
>
> There's one more place in arch/sparc/.
> The below patch should fix it, but I have no means to test it.
You also missed a third thing:
+static inline int
+perf_output_begin(struct perf_output_handle *handle, struct perf_counter *c,
+ unsigned int size, int nmi, int sample) { }
an 'int' function returning void ...
Plus all the !PERF_COUNTERS branch of empty inlines is pointless - these
facilities are used by perfcounters code only. I fixed that too.
>
> Index: b/arch/sparc/kernel/perf_counter.c
> ===================================================================
> --- a/arch/sparc/kernel/perf_counter.c
> +++ b/arch/sparc/kernel/perf_counter.c
> @@ -493,7 +493,6 @@ static int __kprobes perf_counter_nmi_ha
>
> regs = args->regs;
>
> - data.regs = regs;
> data.addr = 0;
>
> cpuc = &__get_cpu_var(cpu_hw_counters);
> @@ -513,7 +512,7 @@ static int __kprobes perf_counter_nmi_ha
> if (!sparc_perf_counter_set_period(counter, hwc, idx))
> continue;
>
> - if (perf_counter_overflow(counter, 1, &data))
> + if (perf_counter_overflow(counter, 1, &data, regs))
> sparc_pmu_disable_counter(hwc, idx);
> }
Looks correct to me and i've also done a Sparc cross build with the fix
in place and it builds fine besides the unrelated build error pasted
below. I've added it to the other fix and if David acks it will send it
to Linus later today.
Thanks,
Ingo
/home/mingo/tip/drivers/video/console/vgacon.c: In function 'vgacon_startup':
/home/mingo/tip/drivers/video/console/vgacon.c:516: warning: passing argument 1 of 'scr_readw' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:517: warning: passing argument 1 of 'scr_readw' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:518: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:519: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:520: warning: passing argument 1 of 'scr_readw' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:520: warning: passing argument 1 of 'scr_readw' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:521: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:522: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:525: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:526: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:527: warning: passing argument 1 of 'scr_readw' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:527: warning: passing argument 1 of 'scr_readw' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:528: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:529: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:532: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c:533: warning: passing argument 2 of 'scr_writew' discards qualifiers from pointer target type
/home/mingo/tip/drivers/video/console/vgacon.c: In function 'vgacon_do_font_op':
/home/mingo/tip/drivers/video/console/vgacon.c:1126: error: implicit declaration of function 'vga_writeb'
/home/mingo/tip/drivers/video/console/vgacon.c:1129: error: implicit declaration of function 'vga_readb'
make[4]: *** [drivers/video/console/vgacon.o] Error 1
make[3]: *** [drivers/video/console] Error 2
make[2]: *** [drivers/video] Error 2
make[2]: *** Waiting for unfinished jobs....
^ permalink raw reply
* RE: [PATCH] perf_counter/powerpc: Fix compilation after perf_counter_overflow change
From: Metzger, Markus T @ 2009-09-21 7:12 UTC (permalink / raw)
To: Paul Mackerras, Ingo Molnar, Peter Zijlstra, davem@davemloft.net
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org
In-Reply-To: <19127.8400.376239.586120@drongo.ozlabs.ibm.com>
>-----Original Message-----
>From: Paul Mackerras [mailto:paulus@samba.org]
>Sent: Monday, September 21, 2009 8:45 AM
>Markus, please take care in future to mention it in the changelog if
>your patches touch definitions used by other architectures. If you
>could go so far as to use grep a bit more and fix up other
>architectures' callsites for the things you're changing, that would be
>very much appreciated. Thanks.
I'm sorry I missed that.
There's one more place in arch/sparc/.
The below patch should fix it, but I have no means to test it.
Index: b/arch/sparc/kernel/perf_counter.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- a/arch/sparc/kernel/perf_counter.c
+++ b/arch/sparc/kernel/perf_counter.c
@@ -493,7 +493,6 @@ static int __kprobes perf_counter_nmi_ha
=20
regs =3D args->regs;
=20
- data.regs =3D regs;
data.addr =3D 0;
=20
cpuc =3D &__get_cpu_var(cpu_hw_counters);
@@ -513,7 +512,7 @@ static int __kprobes perf_counter_nmi_ha
if (!sparc_perf_counter_set_period(counter, hwc, idx))
continue;
=20
- if (perf_counter_overflow(counter, 1, &data))
+ if (perf_counter_overflow(counter, 1, &data, regs))
sparc_pmu_disable_counter(hwc, idx);
}
thanks and regards,
markus.
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply
* [PATCH] perf_counter/powerpc: Fix compilation after perf_counter_overflow change
From: Paul Mackerras @ 2009-09-21 6:44 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra; +Cc: Markus Metzger, linux-kernel, linuxppc-dev
Commit 5622f295 ("x86, perf_counter, bts: Optimize BTS overflow
handling") removed the regs field from struct perf_sample_data and
added a regs parameter to perf_counter_overflow(). This breaks the
build on powerpc as reported by Sachin Sant:
arch/powerpc/kernel/perf_counter.c: In function 'record_and_restart':
arch/powerpc/kernel/perf_counter.c:1165: error: unknown field 'regs' specified in initializer
cc1: warnings being treated as errors
arch/powerpc/kernel/perf_counter.c:1165: error: initialization makes integer from pointer without a cast
arch/powerpc/kernel/perf_counter.c:1173: error: too few arguments to function 'perf_counter_overflow'
make[1]: *** [arch/powerpc/kernel/perf_counter.o] Error 1
make: *** [arch/powerpc/kernel] Error 2
This adjusts arch/powerpc/kernel/perf_counter.c to correspond with the
new struct perf_sample_data and perf_counter_overflow().
Reported-by: Sachin Sant <sachinp@in.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
I missed this problem when the "x86, perf_counter, bts: Optimize BTS
overflow handling" patch was posted because the headline made it seem
entirely x86-specific, and the changes to struct perf_sample_data and
perf_counter_overflow() were not mentioned in the changelog.
Markus, please take care in future to mention it in the changelog if
your patches touch definitions used by other architectures. If you
could go so far as to use grep a bit more and fix up other
architectures' callsites for the things you're changing, that would be
very much appreciated. Thanks.
diff --git a/arch/powerpc/kernel/perf_counter.c b/arch/powerpc/kernel/perf_counter.c
index 7ceefaf..5ccf9bc 100644
--- a/arch/powerpc/kernel/perf_counter.c
+++ b/arch/powerpc/kernel/perf_counter.c
@@ -1162,7 +1162,6 @@ static void record_and_restart(struct perf_counter *counter, unsigned long val,
*/
if (record) {
struct perf_sample_data data = {
- .regs = regs,
.addr = 0,
.period = counter->hw.last_period,
};
@@ -1170,7 +1169,7 @@ static void record_and_restart(struct perf_counter *counter, unsigned long val,
if (counter->attr.sample_type & PERF_SAMPLE_ADDR)
perf_get_data_addr(regs, &data.addr);
- if (perf_counter_overflow(counter, nmi, &data)) {
+ if (perf_counter_overflow(counter, nmi, &data, regs)) {
/*
* Interrupts are coming too fast - throttle them
* by setting the counter to 0, so it will be
^ permalink raw reply related
* 2.6.31-git10 : perf counters build failure on powerpc
From: Sachin Sant @ 2009-09-21 5:21 UTC (permalink / raw)
To: Linux/PPC Development; +Cc: Ingo Molnar, Paul Mackerras
Latest 31 git(2.6.31-git10 : ebc79c4f8da0f92efa968e0328f32334a2ce80cf)
fails to build on powerpc with following error
arch/powerpc/kernel/perf_counter.c: In function 'record_and_restart':
arch/powerpc/kernel/perf_counter.c:1165: error: unknown field 'regs' specified in initializer
cc1: warnings being treated as errors
arch/powerpc/kernel/perf_counter.c:1165: error: initialization makes integer from pointer without a cast
arch/powerpc/kernel/perf_counter.c:1173: error: too few arguments to function 'perf_counter_overflow'
make[1]: *** [arch/powerpc/kernel/perf_counter.o] Error 1
make: *** [arch/powerpc/kernel] Error 2
Thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: Change archdata dma_data to a union
From: Benjamin Herrenschmidt @ 2009-09-21 5:21 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <1251930200-4796-2-git-send-email-beckyb@kernel.crashing.org>
On Wed, 2009-09-02 at 17:23 -0500, Becky Bruce wrote:
> Sometimes this is used to hold a simple offset, and sometimes
> it is used to hold a pointer. This patch changes it to a union containing
> void * and dma_addr_t. get/set accessors are also provided, because it was
> getting a bit ugly to get to the actual data.
Looks good, but please respin the two patches with the comment I
suggested added :-)
Cheers,
Ben.
> Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
> ---
> arch/powerpc/include/asm/device.h | 11 ++++++++++-
> arch/powerpc/include/asm/dma-mapping.h | 10 ++++++++--
> arch/powerpc/include/asm/iommu.h | 10 ++++++++++
> arch/powerpc/kernel/dma-iommu.c | 16 ++++++++--------
> arch/powerpc/kernel/pci-common.c | 2 +-
> arch/powerpc/kernel/vio.c | 2 +-
> arch/powerpc/platforms/cell/beat_iommu.c | 2 +-
> arch/powerpc/platforms/cell/iommu.c | 9 +++------
> arch/powerpc/platforms/iseries/iommu.c | 2 +-
> arch/powerpc/platforms/pasemi/iommu.c | 2 +-
> arch/powerpc/platforms/pseries/iommu.c | 8 ++++----
> arch/powerpc/sysdev/dart_iommu.c | 2 +-
> 12 files changed, 49 insertions(+), 27 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/device.h b/arch/powerpc/include/asm/device.h
> index 67fcd7f..07ca8b5 100644
> --- a/arch/powerpc/include/asm/device.h
> +++ b/arch/powerpc/include/asm/device.h
> @@ -15,7 +15,16 @@ struct dev_archdata {
>
> /* DMA operations on that device */
> struct dma_map_ops *dma_ops;
> - void *dma_data;
> +
> + /*
> + * When an iommu is in use, dma_data is used as a ptr to the base of the
> + * iommu_table. Otherwise, it is a simple numerical offset.
> + */
> + union {
> + dma_addr_t dma_offset;
> + void *iommu_table_base;
> + } dma_data;
> +
> #ifdef CONFIG_SWIOTLB
> dma_addr_t max_direct_dma_addr;
> #endif
> diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
> index eef4db1..e9f4fe9 100644
> --- a/arch/powerpc/include/asm/dma-mapping.h
> +++ b/arch/powerpc/include/asm/dma-mapping.h
> @@ -89,14 +89,20 @@ static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
> dev->archdata.dma_ops = ops;
> }
>
> -static inline unsigned long get_dma_offset(struct device *dev)
> +static inline dma_addr_t get_dma_offset(struct device *dev)
> {
> if (dev)
> - return (unsigned long)dev->archdata.dma_data;
> + return dev->archdata.dma_data.dma_offset;
>
> return PCI_DRAM_OFFSET;
> }
>
> +static inline void set_dma_offset(struct device *dev, dma_addr_t off)
> +{
> + if (dev)
> + dev->archdata.dma_data.dma_offset = off;
> +}
> +
> /* this will be removed soon */
> #define flush_write_buffers()
>
> diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
> index 7464c0d..edfc980 100644
> --- a/arch/powerpc/include/asm/iommu.h
> +++ b/arch/powerpc/include/asm/iommu.h
> @@ -70,6 +70,16 @@ struct iommu_table {
>
> struct scatterlist;
>
> +static inline void set_iommu_table_base(struct device *dev, void *base)
> +{
> + dev->archdata.dma_data.iommu_table_base = base;
> +}
> +
> +static inline void *get_iommu_table_base(struct device *dev)
> +{
> + return dev->archdata.dma_data.iommu_table_base;
> +}
> +
> /* Frees table for an individual device node */
> extern void iommu_free_table(struct iommu_table *tbl, const char *node_name);
>
> diff --git a/arch/powerpc/kernel/dma-iommu.c b/arch/powerpc/kernel/dma-iommu.c
> index 87ddb3f..37771a5 100644
> --- a/arch/powerpc/kernel/dma-iommu.c
> +++ b/arch/powerpc/kernel/dma-iommu.c
> @@ -18,7 +18,7 @@
> static void *dma_iommu_alloc_coherent(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t flag)
> {
> - return iommu_alloc_coherent(dev, dev->archdata.dma_data, size,
> + return iommu_alloc_coherent(dev, get_iommu_table_base(dev), size,
> dma_handle, device_to_mask(dev), flag,
> dev_to_node(dev));
> }
> @@ -26,7 +26,7 @@ static void *dma_iommu_alloc_coherent(struct device *dev, size_t size,
> static void dma_iommu_free_coherent(struct device *dev, size_t size,
> void *vaddr, dma_addr_t dma_handle)
> {
> - iommu_free_coherent(dev->archdata.dma_data, size, vaddr, dma_handle);
> + iommu_free_coherent(get_iommu_table_base(dev), size, vaddr, dma_handle);
> }
>
> /* Creates TCEs for a user provided buffer. The user buffer must be
> @@ -39,8 +39,8 @@ static dma_addr_t dma_iommu_map_page(struct device *dev, struct page *page,
> enum dma_data_direction direction,
> struct dma_attrs *attrs)
> {
> - return iommu_map_page(dev, dev->archdata.dma_data, page, offset, size,
> - device_to_mask(dev), direction, attrs);
> + return iommu_map_page(dev, get_iommu_table_base(dev), page, offset,
> + size, device_to_mask(dev), direction, attrs);
> }
>
>
> @@ -48,7 +48,7 @@ static void dma_iommu_unmap_page(struct device *dev, dma_addr_t dma_handle,
> size_t size, enum dma_data_direction direction,
> struct dma_attrs *attrs)
> {
> - iommu_unmap_page(dev->archdata.dma_data, dma_handle, size, direction,
> + iommu_unmap_page(get_iommu_table_base(dev), dma_handle, size, direction,
> attrs);
> }
>
> @@ -57,7 +57,7 @@ static int dma_iommu_map_sg(struct device *dev, struct scatterlist *sglist,
> int nelems, enum dma_data_direction direction,
> struct dma_attrs *attrs)
> {
> - return iommu_map_sg(dev, dev->archdata.dma_data, sglist, nelems,
> + return iommu_map_sg(dev, get_iommu_table_base(dev), sglist, nelems,
> device_to_mask(dev), direction, attrs);
> }
>
> @@ -65,14 +65,14 @@ static void dma_iommu_unmap_sg(struct device *dev, struct scatterlist *sglist,
> int nelems, enum dma_data_direction direction,
> struct dma_attrs *attrs)
> {
> - iommu_unmap_sg(dev->archdata.dma_data, sglist, nelems, direction,
> + iommu_unmap_sg(get_iommu_table_base(dev), sglist, nelems, direction,
> attrs);
> }
>
> /* We support DMA to/from any memory page via the iommu */
> static int dma_iommu_dma_supported(struct device *dev, u64 mask)
> {
> - struct iommu_table *tbl = dev->archdata.dma_data;
> + struct iommu_table *tbl = get_iommu_table_base(dev);
>
> if (!tbl || tbl->it_offset > mask) {
> printk(KERN_INFO
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> index e9f4840..bb8209e 100644
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -1117,7 +1117,7 @@ void __devinit pcibios_setup_bus_devices(struct pci_bus *bus)
>
> /* Hook up default DMA ops */
> sd->dma_ops = pci_dma_ops;
> - sd->dma_data = (void *)PCI_DRAM_OFFSET;
> + set_dma_offset(&dev->dev, PCI_DRAM_OFFSET);
>
> /* Additional platform DMA/iommu setup */
> if (ppc_md.pci_dma_dev_setup)
> diff --git a/arch/powerpc/kernel/vio.c b/arch/powerpc/kernel/vio.c
> index bc7b41e..8d9275f 100644
> --- a/arch/powerpc/kernel/vio.c
> +++ b/arch/powerpc/kernel/vio.c
> @@ -1233,7 +1233,7 @@ struct vio_dev *vio_register_device_node(struct device_node *of_node)
> vio_cmo_set_dma_ops(viodev);
> else
> viodev->dev.archdata.dma_ops = &dma_iommu_ops;
> - viodev->dev.archdata.dma_data = vio_build_iommu_table(viodev);
> + set_iommu_table_base(&viodev->dev, vio_build_iommu_table(viodev));
> set_dev_node(&viodev->dev, of_node_to_nid(of_node));
>
> /* init generic 'struct device' fields: */
> diff --git a/arch/powerpc/platforms/cell/beat_iommu.c b/arch/powerpc/platforms/cell/beat_iommu.c
> index 93b0efd..39d361c 100644
> --- a/arch/powerpc/platforms/cell/beat_iommu.c
> +++ b/arch/powerpc/platforms/cell/beat_iommu.c
> @@ -77,7 +77,7 @@ static void __init celleb_init_direct_mapping(void)
> static void celleb_dma_dev_setup(struct device *dev)
> {
> dev->archdata.dma_ops = get_pci_dma_ops();
> - dev->archdata.dma_data = (void *)celleb_dma_direct_offset;
> + set_dma_offset(dev, celleb_dma_direct_offset);
> }
>
> static void celleb_pci_dma_dev_setup(struct pci_dev *pdev)
> diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
> index 416db17..ca5bfdf 100644
> --- a/arch/powerpc/platforms/cell/iommu.c
> +++ b/arch/powerpc/platforms/cell/iommu.c
> @@ -657,15 +657,13 @@ static void cell_dma_dev_setup_fixed(struct device *dev);
>
> static void cell_dma_dev_setup(struct device *dev)
> {
> - struct dev_archdata *archdata = &dev->archdata;
> -
> /* Order is important here, these are not mutually exclusive */
> if (get_dma_ops(dev) == &dma_iommu_fixed_ops)
> cell_dma_dev_setup_fixed(dev);
> else if (get_pci_dma_ops() == &dma_iommu_ops)
> - archdata->dma_data = cell_get_iommu_table(dev);
> + set_iommu_table_base(dev, cell_get_iommu_table(dev));
> else if (get_pci_dma_ops() == &dma_direct_ops)
> - archdata->dma_data = (void *)cell_dma_direct_offset;
> + set_dma_offset(dev, cell_dma_direct_offset);
> else
> BUG();
> }
> @@ -973,11 +971,10 @@ static int dma_set_mask_and_switch(struct device *dev, u64 dma_mask)
>
> static void cell_dma_dev_setup_fixed(struct device *dev)
> {
> - struct dev_archdata *archdata = &dev->archdata;
> u64 addr;
>
> addr = cell_iommu_get_fixed_address(dev) + dma_iommu_fixed_base;
> - archdata->dma_data = (void *)addr;
> + set_dma_offset(dev, addr);
>
> dev_dbg(dev, "iommu: fixed addr = %llx\n", addr);
> }
> diff --git a/arch/powerpc/platforms/iseries/iommu.c b/arch/powerpc/platforms/iseries/iommu.c
> index 6c1e101..9d53cb4 100644
> --- a/arch/powerpc/platforms/iseries/iommu.c
> +++ b/arch/powerpc/platforms/iseries/iommu.c
> @@ -193,7 +193,7 @@ static void pci_dma_dev_setup_iseries(struct pci_dev *pdev)
> pdn->iommu_table = iommu_init_table(tbl, -1);
> else
> kfree(tbl);
> - pdev->dev.archdata.dma_data = pdn->iommu_table;
> + set_iommu_table_base(&pdev->dev, pdn->iommu_table);
> }
> #else
> #define pci_dma_dev_setup_iseries NULL
> diff --git a/arch/powerpc/platforms/pasemi/iommu.c b/arch/powerpc/platforms/pasemi/iommu.c
> index a0ff03a..7b1d608 100644
> --- a/arch/powerpc/platforms/pasemi/iommu.c
> +++ b/arch/powerpc/platforms/pasemi/iommu.c
> @@ -189,7 +189,7 @@ static void pci_dma_dev_setup_pasemi(struct pci_dev *dev)
> }
> #endif
>
> - dev->dev.archdata.dma_data = &iommu_table_iobmap;
> + set_iommu_table_base(&dev->dev, &iommu_table_iobmap);
> }
>
> static void pci_dma_bus_setup_null(struct pci_bus *b) { }
> diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
> index 661c8e0..1a0000a 100644
> --- a/arch/powerpc/platforms/pseries/iommu.c
> +++ b/arch/powerpc/platforms/pseries/iommu.c
> @@ -482,7 +482,7 @@ static void pci_dma_dev_setup_pSeries(struct pci_dev *dev)
> phb->node);
> iommu_table_setparms(phb, dn, tbl);
> PCI_DN(dn)->iommu_table = iommu_init_table(tbl, phb->node);
> - dev->dev.archdata.dma_data = PCI_DN(dn)->iommu_table;
> + set_iommu_table_base(&dev->dev, PCI_DN(dn)->iommu_table);
> return;
> }
>
> @@ -494,7 +494,7 @@ static void pci_dma_dev_setup_pSeries(struct pci_dev *dev)
> dn = dn->parent;
>
> if (dn && PCI_DN(dn))
> - dev->dev.archdata.dma_data = PCI_DN(dn)->iommu_table;
> + set_iommu_table_base(&dev->dev, PCI_DN(dn)->iommu_table);
> else
> printk(KERN_WARNING "iommu: Device %s has no iommu table\n",
> pci_name(dev));
> @@ -538,7 +538,7 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_dev *dev)
> */
> if (dma_window == NULL || pdn->parent == NULL) {
> pr_debug(" no dma window for device, linking to parent\n");
> - dev->dev.archdata.dma_data = PCI_DN(pdn)->iommu_table;
> + set_iommu_table_base(&dev->dev, PCI_DN(pdn)->iommu_table);
> return;
> }
>
> @@ -554,7 +554,7 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_dev *dev)
> pr_debug(" found DMA window, table: %p\n", pci->iommu_table);
> }
>
> - dev->dev.archdata.dma_data = pci->iommu_table;
> + set_iommu_table_base(&dev->dev, pci->iommu_table);
> }
> #else /* CONFIG_PCI */
> #define pci_dma_bus_setup_pSeries NULL
> diff --git a/arch/powerpc/sysdev/dart_iommu.c b/arch/powerpc/sysdev/dart_iommu.c
> index 89639ec..ae3c4db 100644
> --- a/arch/powerpc/sysdev/dart_iommu.c
> +++ b/arch/powerpc/sysdev/dart_iommu.c
> @@ -297,7 +297,7 @@ static void pci_dma_dev_setup_dart(struct pci_dev *dev)
> /* We only have one iommu table on the mac for now, which makes
> * things simple. Setup all PCI devices to point to this table
> */
> - dev->dev.archdata.dma_data = &iommu_table_dart;
> + set_iommu_table_base(&dev->dev, &iommu_table_dart);
> }
>
> static void pci_dma_bus_setup_dart(struct pci_bus *bus)
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: rename get_dma_direct_offset get_dma_offset
From: Benjamin Herrenschmidt @ 2009-09-21 5:19 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc-dev
In-Reply-To: <1251930200-4796-1-git-send-email-beckyb@kernel.crashing.org>
On Wed, 2009-09-02 at 17:23 -0500, Becky Bruce wrote:
> #ifdef CONFIG_NOT_COHERENT_CACHE
> /*
> @@ -90,6 +89,14 @@ static inline void set_dma_ops(struct device *dev, struct dma_map_ops *ops)
> dev->archdata.dma_ops = ops;
> }
>
> +static inline unsigned long get_dma_offset(struct device *dev)
> +{
> + if (dev)
> + return (unsigned long)dev->archdata.dma_data;
> +
> + return PCI_DRAM_OFFSET;
> +}
My main objection here is that this makes it look "too" generic ... it
only works for direct and swiotlb, not iommu. Maybe not a big deal but
I think at least there should be a comment explaining what it is and
when it can be used in the header.
Cheers,
Ben.
^ permalink raw reply
* Re: PPC_4xx synopsy USB driver
From: Stefan Roese @ 2009-09-21 5:13 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Cote, Sylvain
In-Reply-To: <579B119545DAEF4689C8FBEEFEC5793F01FA07D04F37@ATLMBX.verint.corp.verintsystems.com>
Hi Sylvain,
On Friday 18 September 2009 17:50:24 Cote, Sylvain wrote:
> USB gadget support --> y
> Maximum VBUS power usage = 500
> Synopsys DWC OTG controller
> Synopsys DWC OTG internal DMA mode --> y
> USB gadget --> M
> gadget zero --> M
> Ethernet Gadget --> M
> RNDIS support --> y
>
> Any help will be appreciated
Looks good so far. I suspect that the only thing missing for your 405EX custom
board is the following line in the arch/powerpc/sysdev/Makefile:
obj-$(CONFIG_KILAUEA) += amcc-usbotg.o
to enable the device-tree to platform-device driver wrapper for the USB-OTG
resources.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* [PATCH] sbc8548: fixup of PCI-e related DTS fields
From: Paul Gortmaker @ 2009-09-21 0:49 UTC (permalink / raw)
To: linuxppc-dev
The PCI-e addressing was originally patterned of the MPC8548CDS
which has PCI1, PCI2, and PCI-e. Since this board only has
PCI1 and PCI-e, it makes more sense to be similar to the MPC8568MDS
board. This does that by cutting the PCI/PCI-e I/O sizes from
16MB to 8MB and pulling the PCI-e I/O range back to 0xe280_0000
(the hole where PCI2 I/O would have been).
This also fixes a typo where an extra zero made an 8MB range a 128MB
range, removes the hole left by PCI2 from the aliases, and sets the
clocks to match the oscillators that are actually on the board.
With accompanying u-boot updates, PCI-e has been validated with
both a sky2 card (1148:9e00) and an e1000 card (8086:108b).
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
arch/powerpc/boot/dts/sbc8548.dts | 17 ++++++++---------
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/boot/dts/sbc8548.dts b/arch/powerpc/boot/dts/sbc8548.dts
index 9eefe00..a5bb015 100644
--- a/arch/powerpc/boot/dts/sbc8548.dts
+++ b/arch/powerpc/boot/dts/sbc8548.dts
@@ -26,8 +26,7 @@
serial0 = &serial0;
serial1 = &serial1;
pci0 = &pci0;
- /* pci1 doesn't have a corresponding physical connector */
- pci2 = &pci2;
+ pci1 = &pci1;
};
cpus {
@@ -381,7 +380,7 @@
bus-range = <0 0>;
ranges = <0x02000000 0x0 0x80000000 0x80000000 0x0 0x10000000
0x01000000 0x0 0x00000000 0xe2000000 0x0 0x00800000>;
- clock-frequency = <66666666>;
+ clock-frequency = <66000000>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
@@ -390,7 +389,7 @@
device_type = "pci";
};
- pci2: pcie@e000a000 {
+ pci1: pcie@e000a000 {
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
@@ -403,9 +402,9 @@
interrupt-parent = <&mpic>;
interrupts = <0x1a 0x2>;
bus-range = <0x0 0xff>;
- ranges = <0x02000000 0x0 0xa0000000 0xa0000000 0x0 0x20000000
- 0x01000000 0x0 0x00000000 0xe3000000 0x0 0x08000000>;
- clock-frequency = <33333333>;
+ ranges = <0x02000000 0x0 0xa0000000 0xa0000000 0x0 0x10000000
+ 0x01000000 0x0 0x00000000 0xe2800000 0x0 0x08000000>;
+ clock-frequency = <33000000>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
@@ -419,11 +418,11 @@
device_type = "pci";
ranges = <0x02000000 0x0 0xa0000000
0x02000000 0x0 0xa0000000
- 0x0 0x20000000
+ 0x0 0x10000000
0x01000000 0x0 0x00000000
0x01000000 0x0 0x00000000
- 0x0 0x08000000>;
+ 0x0 0x0800000>;
};
};
};
--
1.6.4.1
^ permalink raw reply related
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