* Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
From: Stephen Rothwell @ 2008-08-06 7:42 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus, miltonm
In-Reply-To: <fa686aa40808052334m2946298aw453afce8b47e6bf7@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 930 bytes --]
Hi Grant,
On Wed, 6 Aug 2008 00:34:04 -0600 "Grant Likely" <grant.likely@secretlab.ca> wrote:
>
> On Wed, Aug 6, 2008 at 12:14 AM, Michael Ellerman
> <michael@ellerman.id.au> wrote:
> > On Wed, 2008-08-06 at 00:02 -0600, Grant Likely wrote:
> >> From: Grant Likely <grant.likely@secretlab.ca>
> >>
> >> of_lookup_stdout() is useful for figuring out what device to use as output
> >> for early boot progress messages. It returns the node pointed to by the
> >> linux,stdout-path property in the chosen node.
> >
> > Nice. You don't feel like converting all the places that currently do it
> > by hand to use this do you :)
>
> Yep, I'll do this. :-)
Could you also send an email to Dave Miller to see if he has any objections
to this function being generic (since the Sparc guys share this code).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
From: David Miller @ 2008-08-06 7:44 UTC (permalink / raw)
To: sfr; +Cc: linuxppc-dev, paulus, miltonm
In-Reply-To: <20080806174233.3da5daea.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 6 Aug 2008 17:42:33 +1000
> Hi Grant,
>
> On Wed, 6 Aug 2008 00:34:04 -0600 "Grant Likely" <grant.likely@secretlab.ca> wrote:
> >
> > On Wed, Aug 6, 2008 at 12:14 AM, Michael Ellerman
> > <michael@ellerman.id.au> wrote:
> > > On Wed, 2008-08-06 at 00:02 -0600, Grant Likely wrote:
> > >> From: Grant Likely <grant.likely@secretlab.ca>
> > >>
> > >> of_lookup_stdout() is useful for figuring out what device to use as output
> > >> for early boot progress messages. It returns the node pointed to by the
> > >> linux,stdout-path property in the chosen node.
> > >
> > > Nice. You don't feel like converting all the places that currently do it
> > > by hand to use this do you :)
> >
> > Yep, I'll do this. :-)
>
> Could you also send an email to Dave Miller to see if he has any objections
> to this function being generic (since the Sparc guys share this code).
I already voiced my concerns.
^ permalink raw reply
* Re: [PATCH 4/6] powerpc: add USB peripheral support to MPC8272ADS
From: Stephen Rothwell @ 2008-08-06 7:48 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1218006285-27138-4-git-send-email-leoli@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 598 bytes --]
Hi Li,
On Wed, 6 Aug 2008 15:04:43 +0800 Li Yang <leoli@freescale.com> wrote:
>
> @@ -150,6 +169,12 @@ static void __init mpc8272_ads_setup_arch(void)
> clrbits32(&bcsr[3], BCSR3_FETHIEN2);
> setbits32(&bcsr[3], BCSR3_FETH2_RST);
>
> + /* Enabling USB support in BCSR */
> + np = of_find_compatible_node(NULL, NULL, "fsl,qe_udc");
> + if (np != NULL) {
of_node_put(np);
> + clrbits32(&bcsr[3], BCSR3_USB_EN);
> + clrbits32(&bcsr[3], BCSR3_USB_HI_SPEED);
> + }
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 5/6] powerpc: add USB peripheral support to MPC836xMDS
From: Stephen Rothwell @ 2008-08-06 7:50 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1218006285-27138-5-git-send-email-leoli@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
Hi Li,
On Wed, 6 Aug 2008 15:04:44 +0800 Li Yang <leoli@freescale.com> wrote:
>
> @@ -93,6 +93,12 @@ static void __init mpc836x_mds_setup_arch(void)
>
> for (np = NULL; (np = of_find_node_by_name(np, "ucc")) != NULL;)
> par_io_of_config(np);
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,qe_udc");
> + if (np) {
> + par_io_of_config(np);
> + qe_usb_clock_set(np);
of_node_put(np);
> + }
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
From: Stephen Rothwell @ 2008-08-06 7:57 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus, miltonm
In-Reply-To: <20080806174233.3da5daea.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 377 bytes --]
On Wed, 6 Aug 2008 17:42:33 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Could you also send an email to Dave Miller to see if he has any objections
> to this function being generic (since the Sparc guys share this code).
So I should read ahead :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: inline assembly & r0 SOS
From: Andreas Schwab @ 2008-08-06 8:49 UTC (permalink / raw)
To: Kevin Diggs; +Cc: linuxppc-dev, Jeremy Kerr
In-Reply-To: <48990D0F.6050909@hypersurf.com>
Kevin Diggs <kevdig@hypersurf.com> writes:
> Jeremy Kerr wrote:
>> Hi Kevin,
>>
>>
>>> /*
>>> * Turn r3 (range) into a rotate count for the selected
>>>range. * 0 -> 23, 1 -> 31
>>> */
>>> __asm__ __volatile__ ( "slwi %0,%0,3\n"
>>> "addi %0,%0,23\n"
>>> "rlwnm %0,%1,%0,30,31\n":
>>> "=r"(ret):
>>> "r"(config),"0"(range)
>>> );
>>
>>
>> Wouldn't this be much simpler in plain C?
>>
> I just knew someone was gonna try to rain on my rlwnm'in fun parade!
> Wonder if the C code can be made to compile down to 3 instructions?
This will do:
unsigned int get_PLL_range(unsigned int range, unsigned int config)
{
range = range * 8 + 23;
return ((config << range) | (config >> (32 - range))) & 3;
}
The special pattern ((a << n) | (a >> (32 - n))) is recognized by gcc as
a rotate operation.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
From: Mel Gorman @ 2008-08-06 9:02 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-mm, libhugetlbfs-devel, linux-kernel, linuxppc-dev, abh,
ebmunson, Andrew Morton
In-Reply-To: <1217958805.10907.45.camel@nimitz>
On (05/08/08 10:53), Dave Hansen didst pronounce:
> On Tue, 2008-08-05 at 17:28 +0100, Mel Gorman wrote:
> > Ok sure, you could do direct inserts for MAP_PRIVATE as conceptually it
> > suits this patch. However, I don't see what you gain. By reusing hugetlbfs,
> > we get things like proper reservations which we can do for MAP_PRIVATE these
> > days. Again, we could call that sort of thing directly if the reservation
> > layer was split out separate from hugetlbfs but I still don't see the gain
> > for all that churn.
> >
> > What am I missing?
>
> This is good for getting us incremental functionality. It is probably
> the smallest amount of code to get it functional.
>
I'm not keen on the idea of introducing another specialised path just for
stacks. Testing coverage is tricky enough as it is and problems still slip
through occasionally. Maybe going through hugetlbfs is less than ideal,
but at least it is a shared path.
> My concern is that we're going down a path that all large page usage
> should be through the one and only filesystem. Once we establish that
> dependency, it is going to be awfully hard to undo it;
Not much harder than it is to write any alternative in the first place
:/
> just think of all
> of the inherent behavior in hugetlbfs. So, we better be sure that the
> filesystem really is the way to go, especially if we're going to start
> having other areas of the kernel depend on it internally.
>
So far, it is working out as a decent model. It is able to track reservations
and deal with the differences between SHARED and PRIVATE without massive
difficulties. While we could add another specialised path to directly insert
the pages into pagetables for private mappings, I find it hard to justify
adding more test coverage problems. There might be minimal gains to be had
in lock granularity but that's about it.
> That said, this particular patch doesn't appear *too* bound to hugetlb
> itself. But, some of its limitations *do* come from the filesystem,
> like its inability to handle VM_GROWS...
>
The lack of VM_GROWSX is an issue, but on its own it does not justify
the amount of churn necessary to support direct pagetable insertions for
MAP_ANONYMOUS|MAP_PRIVATE. I think we'd need another case or two that would
really benefit from direct insertions to pagetables instead of hugetlbfs so
that the path would get adequately tested.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* RE: Kconfig debug help
From: Geert Uytterhoeven @ 2008-08-06 9:46 UTC (permalink / raw)
To: John Linn; +Cc: linuxppc-dev
In-Reply-To: <20080805225045.436FA68005D@mail2-dub.bigfish.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1776 bytes --]
On Tue, 5 Aug 2008, John Linn wrote:
> Thanks Josh, I just came to the conclusion it was busted somehow in the
> mainline after repeating it there.
It was fixed in mainline by
commit 22127f246dc37ed5bea0915f7860002ba6d87da7
Author: Sam Ravnborg <sam@ravnborg.org>
Date: Mon Aug 4 22:18:07 2008 +0200
kconfig: always write out .config
Always write out .config also in the case where config
did not change.
This fixes: http://bugzilla.kernel.org/show_bug.cgi?id=11230
> > -----Original Message-----
> > From: Josh Boyer [mailto:jwboyer@gmail.com] On Behalf Of Josh Boyer
> > Sent: Tuesday, August 05, 2008 4:49 PM
> > To: John Linn
> > Cc: linuxppc-dev@ozlabs.org
> > Subject: Re: Kconfig debug help
> >
> > On Tue, 2008-08-05 at 15:37 -0600, John Linn wrote:
> > > I'm trying to debug some Kconfig problems and am looking for a way
> to
> > > get more debug output.
> > >
> > >
> > >
> > > I have used KBUILD_VERBOSE=1 on the command line and it didn't help
> > > much.
> > >
> > >
> > >
> > > I'm seeing an issue with creating a new defconfig file for a board.
> I
> > > get the .config created, then copy it to a defconfig, and then it
> > > doesn't do anything when I run make with the defconfig file.
> >
> > Yeah, I hit that myself this weekend. It's a bug in the Kconfig area.
> > It's 1/2 fixed in the latest Linus and powerpc trees.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Techsoft 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 293-0376800-10 GEBA-BE-BB
^ permalink raw reply
* Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
From: Paul Mackerras @ 2008-08-06 10:21 UTC (permalink / raw)
To: David Miller; +Cc: miltonm, linuxppc-dev
In-Reply-To: <20080805.233205.201125898.davem@davemloft.net>
David Miller writes:
> On sparc platforms this is obtained differently. We obtain the 32-bit
> instance value of "/chosen/stdout" and convert that into a prom device
> node path using "instance-to-path".
That's actually exactly what we do too, the linux,stdout-path property
is just a cache of the result of that process. The difference is that
we have to do it early on while we still have OF around, while you can
do it later.
Paul.
^ permalink raw reply
* Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
From: David Miller @ 2008-08-06 10:52 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, miltonm
In-Reply-To: <18585.31504.836857.829592@cargo.ozlabs.ibm.com>
From: Paul Mackerras <paulus@samba.org>
Date: Wed, 6 Aug 2008 20:21:04 +1000
> David Miller writes:
>
> > On sparc platforms this is obtained differently. We obtain the 32-bit
> > instance value of "/chosen/stdout" and convert that into a prom device
> > node path using "instance-to-path".
>
> That's actually exactly what we do too, the linux,stdout-path property
> is just a cache of the result of that process. The difference is that
> we have to do it early on while we still have OF around, while you can
> do it later.
I do it right when I build the in-kernel OBP tree. Then I cache
these results in:
extern struct device_node *of_console_device;
extern char *of_console_path;
extern char *of_console_options;
which are declared in asm/prom.h
I could compute it even earlier and just store a phandle instead
of a device_node pointer.
^ permalink raw reply
* Two processes accessing the same mapped physical memory
From: Misbah khan @ 2008-08-06 11:17 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
In my driver i have mapped the SDRAM memory to user space using mmap.
Application can directly access to this physical memory but how can i ensure
that no other process will write to this memory location as long as my
application is having the access to this memory (unlees it unmaps)
For testing this i have written a simul driver which also maps the same
memory of SDRAM and a test application to access it when i run the two
application (actual and test ) ,both of them were accessing the memory and
writing and reading to it.
What is the mechanism to lock this memory (SDRAM in my case )so that no
other process should access it unless and until my process unmaps it or gets
killed.
--- Misbah <><
--
View this message in context: http://www.nabble.com/Two-processes-accessing-the-same-mapped-physical-memory-tp18849083p18849083.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Please pull 'for-2.6.27' branch of 4xx tree
From: Josh Boyer @ 2008-08-06 12:03 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi Paul,
Please grab the tree below. It contains some fixes for the PIKA Warp
board, and some much needed defconfig updates for .27.
josh
The following changes since commit 2e1e9212ed8c532c6b324de77d3cafef5d2bc846:
Linus Torvalds (1):
Merge git://git.kernel.org/.../lethal/sh-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/powerpc-4xx.git for-2.6.27
Josh Boyer (1):
powerpc/4xx: Update defconfig files for 2.6.27-rc1
Sean MacLennan (3):
powerpc/4xx: Cleanup Warp for i2c driver changes.
powerpc/44x: Warp DTS changes for board updates
powerpc/44x: Incorrect NOR offset in Warp DTS
Valentine Barshak (1):
powerpc/44x: Adjust warp-nand resource end address
arch/powerpc/boot/dts/warp.dts | 22 ++-
arch/powerpc/configs/40x/ep405_defconfig | 207 +++++++++----
arch/powerpc/configs/40x/kilauea_defconfig | 196 +++++++++----
arch/powerpc/configs/40x/makalu_defconfig | 196 +++++++++----
arch/powerpc/configs/40x/walnut_defconfig | 203 +++++++++----
arch/powerpc/configs/44x/bamboo_defconfig | 206 +++++++++----
arch/powerpc/configs/44x/canyonlands_defconfig | 116 +++++---
arch/powerpc/configs/44x/ebony_defconfig | 207 +++++++++----
arch/powerpc/configs/44x/katmai_defconfig | 259 ++++++++++++-----
arch/powerpc/configs/44x/rainier_defconfig | 207 +++++++++----
arch/powerpc/configs/44x/sam440ep_defconfig | 109 ++++++--
arch/powerpc/configs/44x/sequoia_defconfig | 207 +++++++++----
arch/powerpc/configs/44x/taishan_defconfig | 208 +++++++++----
arch/powerpc/configs/44x/virtex5_defconfig | 100 +++++--
arch/powerpc/configs/44x/warp_defconfig | 232 +++++++++++-----
arch/powerpc/configs/ppc40x_defconfig | 374 +++++++++++++++++++-----
arch/powerpc/configs/ppc44x_defconfig | 375 ++++++++++++++++++++++--
arch/powerpc/platforms/44x/warp-nand.c | 2 +-
arch/powerpc/platforms/44x/warp.c | 25 +-
19 files changed, 2540 insertions(+), 911 deletions(-)
^ permalink raw reply
* Re: [PATCH 5/6] powerpc: add USB peripheral support to MPC836xMDS
From: Anton Vorontsov @ 2008-08-06 12:07 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev
In-Reply-To: <1218006285-27138-5-git-send-email-leoli@freescale.com>
Hello Li,
On Wed, Aug 06, 2008 at 03:04:44PM +0800, Li Yang wrote:
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc836x_mds.dts | 15 ++++++-
> arch/powerpc/platforms/83xx/mpc836x_mds.c | 19 ++++++++-
> arch/powerpc/platforms/83xx/mpc83xx.h | 1 +
> arch/powerpc/platforms/83xx/usb.c | 67 +++++++++++++++++++++++++++++
> 4 files changed, 100 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts b/arch/powerpc/boot/dts/mpc836x_mds.dts
> index a3b76a7..596377b 100644
> --- a/arch/powerpc/boot/dts/mpc836x_mds.dts
> +++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
> @@ -235,6 +235,17 @@
> 0 2 1 0 1 0>; /* MDC */
> };
>
> + pio_usb: usb_pin@01 {
> + pio-map = <
> + /* port pin dir open_drain assignment has_irq */
> + 1 2 1 0 3 0 /* USBOE */
> + 1 3 1 0 3 0 /* USBTP */
> + 1 8 1 0 1 0 /* USBTN */
> + 1 10 2 0 3 0 /* USBRXD */
> + 1 9 2 1 3 0 /* USBRP */
> + 1 11 2 1 3 0>; /* USBRN */
> + };
> +
> };
> };
>
> @@ -280,11 +291,13 @@
> };
>
> usb@6c0 {
> - compatible = "qe_udc";
> + compatible = "fsl,qe_udc";
You might want to reuse existing bindings as described in
Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt.
> reg = <0x6c0 0x40 0x8b00 0x100>;
> interrupts = <11>;
> interrupt-parent = <&qeic>;
> mode = "slave";
I'd suggest to rename this to "peripheral" as we use for fsl dual-role
usb controller.
> + usb-clock = <21>;
> + pio-handle = <&pio_usb>;
Can we not introduce new pio maps? The pio setup should be done
by the firmware, or at least fixed up via the board file, as in
arch/powerpc/platforms/83xx/mpc832x_rdb.c.
[...]
> +#ifdef CONFIG_QUICC_ENGINE
> +/* QE USB_CLOCK configure functions */
> +int qe_usb_clock_set(struct device_node *np)
We already have this function, in arch/powerpc/sysdev/qe_lib/usb.c
It does not parse any of properties though, driver should do this.
> +{
> + u32 tmpreg = 0;
> + struct qe_mux *qemux = NULL;
> + const int *clock;
> +
> + qemux = &qe_immr->qmx;
> +
> + clock = of_get_property(np, "usb-clock", NULL);
> + if (!clock)
> + return -EINVAL;
> +
> + /* CLK21 -> USBCLK on MPC8360-PB*/
> + tmpreg = in_be32(&qemux->cmxgcr) & ~QE_CMXGCR_USBCS;
> + switch (*clock) {
> + case 21:
> + tmpreg |= 0x8;
> + out_be32(&qemux->cmxgcr, tmpreg);
> + par_io_config_pin(2, 20, 2, 0, 1, 0); /* PC20 for CLK21 */
No, pio config is very board-specific. This should be done by the
firmware (ideally) or by the board file.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* RE: [PATCH]: [MPC5200] Add ATA DMA support
From: Daniel Schnell @ 2008-08-06 11:58 UTC (permalink / raw)
To: Tim Yamin, linuxppc-dev
In-Reply-To: <792f5f410806170128k7e435743x9892b559bd32b157@mail.gmail.com>
Hi,
Tim Yamin wrote:
> This patch adds MDMA/UDMA support (using BestComm for DMA) on the
> MPC5200 platform.=20
>=20
> Based heavily on previous work by Freescale (Bernard Kuhn, John
> Rigby) and Domen Puncer.=20
>=20
> Using a SanDisk Extreme IV CF card I get read speeds of approximately
> 26.70 MB/sec.=20
>=20
> The BestComm ATA task priority was changed to maximum in
> bestcomm_priv.h; this fixes a deadlock issue I was experiencing when
> heavy DMA was occuring on both the ATA and Ethernet BestComm tasks,
> e.g. when downloading a large file over a LAN to disk. =20
>=20
> There's also what I believe to be a hardware bug if you have high
> levels of BestComm ATA DMA activity along with heavy LocalPlus Bus
> activity; the address bus seems to sometimes get corrupted with ATA
> commands while the LocalPlus Bus operation is still active (i.e. Chip
> Select is asserted). =20
>=20
> I've asked Freescale about this but have not received a reply yet --
> if anybody from Freescale has any ideas please contact me; I can
> supply some analyzer traces if needed. Therefore, for now, do not
> enable DMA if you need reliable LocalPlus Bus unless you do a fixup
> in your driver as follows: =20
>=20
> Locking example:
>=20
> while (test_and_set_bit(0, &pata_mpc52xx_ata_dma_lock) !=3D 0)
> {
> struct bcom_task_2 *tsk =3D pata_mpc52xx_ata_dma_task;
>=20
> if(bcom_buffer_done_2(tsk))
> return 1;
> }
>=20
> return 0;
>=20
> (Save the return value to `flags`)
>=20
> Unlocking example:
>=20
> if(flags =3D=3D 0)
> clear_bit(0, &pata_mpc52xx_ata_dma_lock);
>=20
> Comments and testing would of course be very welcome.
>=20
> Thanks,
>=20
> Signed-off-by: Tim Yamin <plasm@roo.me.uk>
Sorry for testing this patch so late, but I get these if I apply your
patch to 2.6.24.7 and use it with my Sandisk Extreme IV 4GB card:
...
[ 0.999514] ata: MPC52xx IDE/ATA libata driver
[ 1.006666] scsi0 : mpc52xx_ata
[ 1.010969] ata1: PATA max UDMA/33 ata_regs 0xf0003a00 irq 135
[ 1.168588] ata1.00: CFA: SanDisk SDCFX3-4096, HDX 4.31, max MWDMA2
[ 1.175156] ata1.00: 8027712 sectors, multi 0: LBA
[ 1.181098] ata1.00: configured for MWDMA2
[ 1.196589] scsi 0:0:0:0: Direct-Access ATA SanDisk SDCFX3-4
HDX PQ: 0 ANSI: 5
[ 1.206949] sd 0:0:0:0: [sda] 8027712 512-byte hardware sectors (4110
MB)
[ 1.214281] sd 0:0:0:0: [sda] Write Protect is off
[ 1.219803] sd 0:0:0:0: [sda] Write cache: disabled, read cache:
enabled, doesn't support DPO or FUA
[ 1.230407] sd 0:0:0:0: [sda] 8027712 512-byte hardware sectors (4110
MB)
[ 1.237678] sd 0:0:0:0: [sda] Write Protect is off
[ 1.243129] sd 0:0:0:0: [sda] Write cache: disabled, read cache:
enabled, doesn't support DPO or FUA
[ 1.252684] sda:<3>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0
action 0x2 frozen
[ 31.260361] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0
dma 4096 in
[ 31.260377] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[ 31.275689] ata1.00: status: { DRDY }
[ 31.279545] ata1: soft resetting link
[ 31.435535] ata1.00: configured for MWDMA2
[ 31.439933] ata1: EH complete
[ 61.443060] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
frozen
[ 61.450451] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0
dma 4096 in
[ 61.450467] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[ 61.465777] ata1.00: status: { DRDY }
[ 61.469632] ata1: soft resetting link
[ 61.625541] ata1.00: configured for MWDMA2
[ 61.629938] ata1: EH complete
...
[ 363.394140] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
frozen
[ 363.401534] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0
dma 4096 in
[ 363.401550] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[ 363.416889] ata1.00: status: { DRDY }
[ 363.420717] ata1: soft resetting link
[ 363.576538] ata1.00: configured for MWDMA1
[ 363.580927] sd 0:0:0:0: [sda] Result: hostbyte=3D0x00 =
driverbyte=3D0x08
[ 363.587499] sd 0:0:0:0: [sda] Sense Key : 0xb [current] [descriptor]
[ 363.594157] Descriptor sense data with sense descriptors (in hex):
[ 363.600593] 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 363.607248] 00 00 00 00
[ 363.610615] sd 0:0:0:0: [sda] ASC=3D0x0 ASCQ=3D0x0
[ 363.615334] end_request: I/O error, dev sda, sector 0
[ 363.620600] Buffer I/O error on device sda, logical block 0
[ 363.626475] unable to read partition table
[ 363.631014] ata1: EH complete
[ 363.635081] sd 0:0:0:0: [sda] Attached SCSI removable disk
And if I boot via NFS, the kernel can continue to boot after that point.
With a non-DMA card everything is fine.
Best regards,
Daniel.
^ permalink raw reply
* Re: [PATCH]: [MPC5200] Add ATA DMA support
From: Tim Yamin @ 2008-08-06 12:18 UTC (permalink / raw)
To: Daniel Schnell; +Cc: linuxppc-dev
In-Reply-To: <DD39B5C3F4963040ADC9768BE7E430CB03202EDF@is-hdq-exchange.marel.net>
On Wed, Aug 6, 2008 at 12:58 PM, Daniel Schnell
<daniel.schnell@marel.com> wrote:
> Hi,
>
> Sorry for testing this patch so late, but I get these if I apply your
> patch to 2.6.24.7 and use it with my Sandisk Extreme IV 4GB card:
Hi,
What board are you using? DMA requires a few more signals to be routed
through correctly to the CF card slot so maybe that's your problem...
Tim
^ permalink raw reply
* Re: Quick question about dts
From: Matt Sealey @ 2008-08-06 12:22 UTC (permalink / raw)
To: Marco Stornelli; +Cc: M. Warner Losh, linuxppc-embedded
In-Reply-To: <489802B3.805@coritel.it>
Marco Stornelli wrote:
> M. Warner Losh ha scritto:
>> I have a .dts file that works with 2.6.18 (MV Pro 5.0). I encode it
>> directly into the kernel image. However, when I try to use it with my
>> 2.6.23, 2.6.24 or 2.6.25 kernel trees, it doesn't work at all. In the
>> MV Pro 5.0 kernel, I hacked the startup sequence to store a pointer to
>> this blob in r3 so that it is moved in. I've done something similar
>> in -current (for reasons that are too complicated to really explain
>> well, we can't do this via the normal boot loader mechanisms). The
>> dtc complains that the interrupt-controller property is obsolete on
>> the chosen device.
>>
>> Does any documentation exist for how dts has evolved? I'd like to
>> forward port what I have without examining the .dts files from both
>> versions and guessing...
>>
>
> Check out the kernel documentation booting-without-of.txt of your version.
Better yet, go get the ePAPR specification from Power.org?
It's easier to read :)
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* unconditional link object arch/powerpc/lib/crtsavres.o breaks module build
From: Olaf Hering @ 2008-08-06 12:23 UTC (permalink / raw)
To: sam, linux-kernel; +Cc: linuxppc-dev
Sam,
please have a look at bug 11143.
http://bugzilla.kernel.org/show_bug.cgi?id=11143
arch/powerpc/lib/crtsavres.o is added inconditionally to the linker
flags, but there is no rule to actually create the object file.
This breaks building external modules on 32bit powerpc since 2.6.26.
Thanks,
Olaf
^ permalink raw reply
* dtc update for in-kernel version
From: Josh Boyer @ 2008-08-06 12:43 UTC (permalink / raw)
To: dwg, paulus; +Cc: linuxppc-dev
So we asked about this a while ago and I haven't seen anything yet, but
is there going to be an update to the version of DTC that is in the
kernel tree? 1.2 is out now, would be a good idea to update soon.
josh
^ permalink raw reply
* [PATCH]: Remove bogons from the iSeries console
From: Alan Cox @ 2008-08-06 13:06 UTC (permalink / raw)
To: torvalds, devilbis, boutcher, linuxppc-dev
The iSeries driver calls into the n_tty ldisc code directly for some
bizarre reason. I previously tagged this with a query but this actually
does need fixing as n_tty methods when you have a different ldisc set are
not a good thing to call.
In n_tty mode this change should have no effect, the core tty layer has
always called the ldisc ioctl method *anyway* and will call the one for
the right ldisc.
Signed-off-by: Alan Cox <alan@redhat.com>
---
drivers/char/viocons.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/char/viocons.c b/drivers/char/viocons.c
index 65fb848..f48892b 100644
--- a/drivers/char/viocons.c
+++ b/drivers/char/viocons.c
@@ -705,10 +705,6 @@ static int viotty_ioctl(struct tty_struct *tty, struct file *file,
case KDSKBLED:
return 0;
}
- /* FIXME: WTF is this being called for ??? */
- lock_kernel();
- ret = n_tty_ioctl(tty, file, cmd, arg);
- unlock_kernel();
return ret;
}
^ permalink raw reply related
* RE: [PATCH]: [MPC5200] Add ATA DMA support
From: Daniel Schnell @ 2008-08-06 13:26 UTC (permalink / raw)
To: Tim Yamin; +Cc: linuxppc-dev
In-Reply-To: <792f5f410808060518r5e2c0124i2cfef450e264f012@mail.gmail.com>
Tim Yamin wrote:
> On Wed, Aug 6, 2008 at 12:58 PM, Daniel Schnell
> <daniel.schnell@marel.com> wrote:=20
>> Hi,
>>=20
>> Sorry for testing this patch so late, but I get these if I apply your
>> patch to 2.6.24.7 and use it with my Sandisk Extreme IV 4GB card:
>=20
> Hi,
>=20
> What board are you using? DMA requires a few more signals to be
> routed through correctly to the CF card slot so maybe that's your
> problem... =20
>=20
Hi,
We are using our own MPC5200B based board. Can you be a bit more
specific about which signals have to be routed ?
Best regards,
Daniel Schnell.
^ permalink raw reply
* Re: dtc update for in-kernel version
From: Kumar Gala @ 2008-08-06 13:29 UTC (permalink / raw)
To: jwboyer; +Cc: linuxppc-dev, paulus, dwg
In-Reply-To: <1218026580.2328.69.camel@localhost.localdomain>
On Aug 6, 2008, at 7:43 AM, Josh Boyer wrote:
> So we asked about this a while ago and I haven't seen anything yet,
> but
> is there going to be an update to the version of DTC that is in the
> kernel tree? 1.2 is out now, would be a good idea to update soon.
is there any reason to update to 1.2 for 2.6.27?
- k
^ permalink raw reply
* [PATCH 0/2 V3] powerpc - Make the irq reverse mapping tree lockless
From: Sebastien Dugue @ 2008-08-06 13:30 UTC (permalink / raw)
To: linuxppc-dev
Cc: dwalker, tinytim, linux-rt-users, linux-kernel, rostedt,
jean-pierre.dion, sebastien.dugue, paulus, gilles.carry, tglx
Hi ,
here is V3 for the powerpc IRQ radix tree reverse mapping rework.
V2 -> V3: from comments by Benjamin Herrenschmidt and Daniel Walker
- Move the initialization of the radix tree back into irq_late_init() and
insert pre-existing irqs into the tree at that time.
- One whitespace cleanup.
V1 -> V2: from comments by Michael Ellerman
- Initialize the XICS radix tree in xics code and only for that irq_host
rather than doing it for all the hosts in the powerpc irq generic code
(although the hosts list only contain one entry at the moment).
- Add a comment in irq_radix_revmap_lookup() stating why it is safe to
perform a lookup even if the radix tree has not been initialized yet.
The goal of this patchset is to simplify the locking constraints on the radix
tree used for IRQ reverse mapping on the pSeries machines and provide lockless
access to this tree.
This also solves the following BUG under preempt-rt:
BUG: sleeping function called from invalid context swapper(1) at kernel/rtmutex.c:739
in_atomic():1 [00000002], irqs_disabled():1
Call Trace:
[c0000001e20f3340] [c000000000010370] .show_stack+0x70/0x1bc (unreliable)
[c0000001e20f33f0] [c000000000049380] .__might_sleep+0x11c/0x138
[c0000001e20f3470] [c0000000002a2f64] .__rt_spin_lock+0x3c/0x98
[c0000001e20f34f0] [c0000000000c3f20] .kmem_cache_alloc+0x68/0x184
[c0000001e20f3590] [c000000000193f3c] .radix_tree_node_alloc+0xf0/0x144
[c0000001e20f3630] [c000000000195190] .radix_tree_insert+0x18c/0x2fc
[c0000001e20f36f0] [c00000000000c710] .irq_radix_revmap+0x1a4/0x1e4
[c0000001e20f37b0] [c00000000003b3f0] .xics_startup+0x30/0x54
[c0000001e20f3840] [c00000000008b864] .setup_irq+0x26c/0x370
[c0000001e20f38f0] [c00000000008ba68] .request_irq+0x100/0x158
[c0000001e20f39a0] [c0000000001ee9c0] .hvc_open+0xb4/0x148
[c0000001e20f3a40] [c0000000001d72ec] .tty_open+0x200/0x368
[c0000001e20f3af0] [c0000000000ce928] .chrdev_open+0x1f4/0x25c
[c0000001e20f3ba0] [c0000000000c8bf0] .__dentry_open+0x188/0x2c8
[c0000001e20f3c50] [c0000000000c8dec] .do_filp_open+0x50/0x70
[c0000001e20f3d70] [c0000000000c8e8c] .do_sys_open+0x80/0x148
[c0000001e20f3e20] [c00000000000928c] .init_post+0x4c/0x100
[c0000001e20f3ea0] [c0000000003c0e0c] .kernel_init+0x428/0x478
[c0000001e20f3f90] [c000000000027448] .kernel_thread+0x4c/0x68
The root cause of this bug lies in the fact that the XICS interrupt
controller uses a radix tree for its reverse irq mapping and that we cannot
allocate the tree nodes (even GFP_ATOMIC) with preemption disabled.
In fact, we have 2 nested preemption disabling when we want to allocate
a new node:
- setup_irq() does a spin_lock_irqsave() before calling xics_startup() which
then calls irq_radix_revmap() to insert a new node in the tree
- irq_radix_revmap() also does a spin_lock_irqsave() (in irq_radix_wrlock())
before the radix_tree_insert()
Also, if an IRQ gets registered before the tree is initialized (namely the
IPI), it will be inserted into the tree in interrupt context once the tree
have been initialized, hence the need for a spin_lock_irqsave() in the
insertion path.
This serie is split into 2 patches:
- The first patch splits irq_radix_revmap() into its 2 components: one
for lookup and one for insertion into the radix tree and moves the
insertion of pre-existing irq into the tree at irq_late_init() time.
- The second patch makes the radix tree fully lockless on the
lookup side.
Here is the diffstat for the whole patchset:
arch/powerpc/include/asm/irq.h | 19 ++++-
arch/powerpc/kernel/irq.c | 148 ++++++++++++++------------------
arch/powerpc/platforms/pseries/xics.c | 11 +--
3 files changed, 85 insertions(+), 93 deletions(-)
Thanks,
Sebastien.
^ permalink raw reply
* [PATCH 1/2] powerpc - Separate the irq radix tree insertion and lookup
From: Sebastien Dugue @ 2008-08-06 13:30 UTC (permalink / raw)
To: linuxppc-dev
Cc: dwalker, tinytim, linux-rt-users, linux-kernel, rostedt,
jean-pierre.dion, sebastien.dugue, paulus, gilles.carry, tglx
In-Reply-To: <1218029429-21114-1-git-send-email-sebastien.dugue@bull.net>
irq_radix_revmap() currently serves 2 purposes, irq mapping lookup
and insertion which happen in interrupt and process context respectively.
Separate the function into its 2 components, one for lookup only and one
for insertion only.
Fix the only user of the revmap tree (XICS) to use the new functions.
Also, move the insertion into the radix tree of those irqs that were
requested before it was initialized at said tree initialization.
Mutual exclusion between the tree initialization and readers/writers is
handled via an atomic variable (revmap_trees_allocated) set when the tree
has been initialized and checked before any reader or writer access just
like we used to check for tree.gfp_mask != 0 before.
Signed-off-by: Sebastien Dugue <sebastien.dugue@bull.net>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/include/asm/irq.h | 18 ++++++-
arch/powerpc/kernel/irq.c | 76 ++++++++++++++++++++++++---------
arch/powerpc/platforms/pseries/xics.c | 11 ++---
3 files changed, 74 insertions(+), 31 deletions(-)
diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
index a372f76..0a51376 100644
--- a/arch/powerpc/include/asm/irq.h
+++ b/arch/powerpc/include/asm/irq.h
@@ -236,15 +236,27 @@ extern unsigned int irq_find_mapping(struct irq_host *host,
extern unsigned int irq_create_direct_mapping(struct irq_host *host);
/**
- * irq_radix_revmap - Find a linux virq from a hw irq number.
+ * irq_radix_revmap_insert - Insert a hw irq to linux virq number mapping.
+ * @host: host owning this hardware interrupt
+ * @virq: linux irq number
+ * @hwirq: hardware irq number in that host space
+ *
+ * This is for use by irq controllers that use a radix tree reverse
+ * mapping for fast lookup.
+ */
+extern void irq_radix_revmap_insert(struct irq_host *host, unsigned int virq,
+ irq_hw_number_t hwirq);
+
+/**
+ * irq_radix_revmap_lookup - Find a linux virq from a hw irq number.
* @host: host owning this hardware interrupt
* @hwirq: hardware irq number in that host space
*
* This is a fast path, for use by irq controller code that uses radix tree
* revmaps
*/
-extern unsigned int irq_radix_revmap(struct irq_host *host,
- irq_hw_number_t hwirq);
+extern unsigned int irq_radix_revmap_lookup(struct irq_host *host,
+ irq_hw_number_t hwirq);
/**
* irq_linear_revmap - Find a linux virq from a hw irq number.
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index d972dec..dc8663a 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -441,6 +441,7 @@ static LIST_HEAD(irq_hosts);
static DEFINE_SPINLOCK(irq_big_lock);
static DEFINE_PER_CPU(unsigned int, irq_radix_reader);
static unsigned int irq_radix_writer;
+static atomic_t revmap_trees_allocated = ATOMIC_INIT(0);
struct irq_map_entry irq_map[NR_IRQS];
static unsigned int irq_virq_count = NR_IRQS;
static struct irq_host *irq_default_host;
@@ -822,7 +823,7 @@ void irq_dispose_mapping(unsigned int virq)
break;
case IRQ_HOST_MAP_TREE:
/* Check if radix tree allocated yet */
- if (host->revmap_data.tree.gfp_mask == 0)
+ if (atomic_read(&revmap_trees_allocated) == 0)
break;
irq_radix_wrlock(&flags);
radix_tree_delete(&host->revmap_data.tree, hwirq);
@@ -875,43 +876,55 @@ unsigned int irq_find_mapping(struct irq_host *host,
EXPORT_SYMBOL_GPL(irq_find_mapping);
-unsigned int irq_radix_revmap(struct irq_host *host,
- irq_hw_number_t hwirq)
+unsigned int irq_radix_revmap_lookup(struct irq_host *host,
+ irq_hw_number_t hwirq)
{
- struct radix_tree_root *tree;
struct irq_map_entry *ptr;
- unsigned int virq;
+ unsigned int virq = NO_IRQ;
unsigned long flags;
WARN_ON(host->revmap_type != IRQ_HOST_MAP_TREE);
- /* Check if the radix tree exist yet. We test the value of
- * the gfp_mask for that. Sneaky but saves another int in the
- * structure. If not, we fallback to slow mode
+ /*
+ * Check if the radix tree exist yet.
+ * If not, we fallback to slow mode
*/
- tree = &host->revmap_data.tree;
- if (tree->gfp_mask == 0)
+ if (atomic_read(&revmap_trees_allocated) == 0)
return irq_find_mapping(host, hwirq);
/* Now try to resolve */
irq_radix_rdlock(&flags);
- ptr = radix_tree_lookup(tree, hwirq);
+ ptr = radix_tree_lookup(&host->revmap_data.tree, hwirq);
irq_radix_rdunlock(flags);
/* Found it, return */
- if (ptr) {
+ if (ptr)
virq = ptr - irq_map;
- return virq;
- }
- /* If not there, try to insert it */
- virq = irq_find_mapping(host, hwirq);
+ return virq;
+}
+
+void irq_radix_revmap_insert(struct irq_host *host, unsigned int virq,
+ irq_hw_number_t hwirq)
+{
+ unsigned long flags;
+
+ WARN_ON(host->revmap_type != IRQ_HOST_MAP_TREE);
+
+ /*
+ * Check if the radix tree exist yet.
+ * If not, then the irq will be inserted into the tree when it gets
+ * initialized.
+ */
+ if (atomic_read(&revmap_trees_allocated) == 0)
+ return;
+
if (virq != NO_IRQ) {
irq_radix_wrlock(&flags);
- radix_tree_insert(tree, hwirq, &irq_map[virq]);
+ radix_tree_insert(&host->revmap_data.tree, hwirq,
+ &irq_map[virq]);
irq_radix_wrunlock(flags);
}
- return virq;
}
unsigned int irq_linear_revmap(struct irq_host *host,
@@ -1020,14 +1033,35 @@ void irq_early_init(void)
static int irq_late_init(void)
{
struct irq_host *h;
- unsigned long flags;
+ unsigned int i;
- irq_radix_wrlock(&flags);
+ /*
+ * No mutual exclusion with respect to accessors of the tree is needed
+ * here as the synchronization is done via the atomic variable
+ * revmap_trees_allocated.
+ */
list_for_each_entry(h, &irq_hosts, link) {
if (h->revmap_type == IRQ_HOST_MAP_TREE)
INIT_RADIX_TREE(&h->revmap_data.tree, GFP_ATOMIC);
}
- irq_radix_wrunlock(flags);
+
+ /*
+ * Insert the reverse mapping for those interrupts already present
+ * in irq_map[].
+ */
+ for (i = 0; i < irq_virq_count; i++) {
+ if (irq_map[i].host &&
+ (irq_map[i].host->revmap_type == IRQ_HOST_MAP_TREE))
+ radix_tree_insert(&irq_map[i].host->revmap_data.tree,
+ irq_map[i].hwirq, &irq_map[i]);
+ }
+
+ /*
+ * Make sure the radix trees inits are visible before setting
+ * the flag
+ */
+ smp_mb();
+ atomic_set(&revmap_trees_allocated, 1);
return 0;
}
diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
index 0fc830f..6b1a005 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -310,12 +310,6 @@ static void xics_mask_irq(unsigned int virq)
static unsigned int xics_startup(unsigned int virq)
{
- unsigned int irq;
-
- /* force a reverse mapping of the interrupt so it gets in the cache */
- irq = (unsigned int)irq_map[virq].hwirq;
- irq_radix_revmap(xics_host, irq);
-
/* unmask it */
xics_unmask_irq(virq);
return 0;
@@ -346,7 +340,7 @@ static inline unsigned int xics_remap_irq(unsigned int vec)
if (vec == XICS_IRQ_SPURIOUS)
return NO_IRQ;
- irq = irq_radix_revmap(xics_host, vec);
+ irq = irq_radix_revmap_lookup(xics_host, vec);
if (likely(irq != NO_IRQ))
return irq;
@@ -530,6 +524,9 @@ static int xics_host_map(struct irq_host *h, unsigned int virq,
{
pr_debug("xics: map virq %d, hwirq 0x%lx\n", virq, hw);
+ /* Insert the interrupt mapping into the radix tree for fast lookup */
+ irq_radix_revmap_insert(xics_host, virq, hw);
+
get_irq_desc(virq)->status |= IRQ_LEVEL;
set_irq_chip_and_handler(virq, xics_irq_chip, handle_fasteoi_irq);
return 0;
--
1.5.5.1
^ permalink raw reply related
* [PATCH 2/2] powerpc - Make the irq reverse mapping radix tree lockless
From: Sebastien Dugue @ 2008-08-06 13:30 UTC (permalink / raw)
To: linuxppc-dev
Cc: dwalker, tinytim, linux-rt-users, linux-kernel, rostedt,
jean-pierre.dion, sebastien.dugue, paulus, gilles.carry, tglx
In-Reply-To: <1218029429-21114-1-git-send-email-sebastien.dugue@bull.net>
The radix trees used by interrupt controllers for their irq reverse mapping
(currently only the XICS found on pSeries) have a complex locking scheme
dating back to before the advent of the lockless radix tree.
Take advantage of this and of the fact that the items of the tree are
pointers to a static array (irq_map) elements which can never go under us
to simplify the locking.
Concurrency between readers and writers is handled by the intrinsic
properties of the lockless radix tree. Concurrency between writers is handled
with a spinlock added to the irq_host structure.
Signed-off-by: Sebastien Dugue <sebastien.dugue@bull.net>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/include/asm/irq.h | 1 +
arch/powerpc/kernel/irq.c | 74 ++++++----------------------------------
2 files changed, 12 insertions(+), 63 deletions(-)
diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
index 0a51376..72fd036 100644
--- a/arch/powerpc/include/asm/irq.h
+++ b/arch/powerpc/include/asm/irq.h
@@ -119,6 +119,7 @@ struct irq_host {
} linear;
struct radix_tree_root tree;
} revmap_data;
+ spinlock_t tree_lock;
struct irq_host_ops *ops;
void *host_data;
irq_hw_number_t inval_irq;
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index dc8663a..7a19103 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -439,8 +439,6 @@ void do_softirq(void)
static LIST_HEAD(irq_hosts);
static DEFINE_SPINLOCK(irq_big_lock);
-static DEFINE_PER_CPU(unsigned int, irq_radix_reader);
-static unsigned int irq_radix_writer;
static atomic_t revmap_trees_allocated = ATOMIC_INIT(0);
struct irq_map_entry irq_map[NR_IRQS];
static unsigned int irq_virq_count = NR_IRQS;
@@ -584,57 +582,6 @@ void irq_set_virq_count(unsigned int count)
irq_virq_count = count;
}
-/* radix tree not lockless safe ! we use a brlock-type mecanism
- * for now, until we can use a lockless radix tree
- */
-static void irq_radix_wrlock(unsigned long *flags)
-{
- unsigned int cpu, ok;
-
- spin_lock_irqsave(&irq_big_lock, *flags);
- irq_radix_writer = 1;
- smp_mb();
- do {
- barrier();
- ok = 1;
- for_each_possible_cpu(cpu) {
- if (per_cpu(irq_radix_reader, cpu)) {
- ok = 0;
- break;
- }
- }
- if (!ok)
- cpu_relax();
- } while(!ok);
-}
-
-static void irq_radix_wrunlock(unsigned long flags)
-{
- smp_wmb();
- irq_radix_writer = 0;
- spin_unlock_irqrestore(&irq_big_lock, flags);
-}
-
-static void irq_radix_rdlock(unsigned long *flags)
-{
- local_irq_save(*flags);
- __get_cpu_var(irq_radix_reader) = 1;
- smp_mb();
- if (likely(irq_radix_writer == 0))
- return;
- __get_cpu_var(irq_radix_reader) = 0;
- smp_wmb();
- spin_lock(&irq_big_lock);
- __get_cpu_var(irq_radix_reader) = 1;
- spin_unlock(&irq_big_lock);
-}
-
-static void irq_radix_rdunlock(unsigned long flags)
-{
- __get_cpu_var(irq_radix_reader) = 0;
- local_irq_restore(flags);
-}
-
static int irq_setup_virq(struct irq_host *host, unsigned int virq,
irq_hw_number_t hwirq)
{
@@ -789,7 +736,6 @@ void irq_dispose_mapping(unsigned int virq)
{
struct irq_host *host;
irq_hw_number_t hwirq;
- unsigned long flags;
if (virq == NO_IRQ)
return;
@@ -825,9 +771,9 @@ void irq_dispose_mapping(unsigned int virq)
/* Check if radix tree allocated yet */
if (atomic_read(&revmap_trees_allocated) == 0)
break;
- irq_radix_wrlock(&flags);
+ spin_lock(&host->tree_lock);
radix_tree_delete(&host->revmap_data.tree, hwirq);
- irq_radix_wrunlock(flags);
+ spin_unlock(&host->tree_lock);
break;
}
@@ -881,7 +827,6 @@ unsigned int irq_radix_revmap_lookup(struct irq_host *host,
{
struct irq_map_entry *ptr;
unsigned int virq = NO_IRQ;
- unsigned long flags;
WARN_ON(host->revmap_type != IRQ_HOST_MAP_TREE);
@@ -893,9 +838,11 @@ unsigned int irq_radix_revmap_lookup(struct irq_host *host,
return irq_find_mapping(host, hwirq);
/* Now try to resolve */
- irq_radix_rdlock(&flags);
+ /*
+ * No rcu_read_lock(ing) needed, the ptr returned can't go under us
+ * as it's referencing an entry in the static irq_map table.
+ */
ptr = radix_tree_lookup(&host->revmap_data.tree, hwirq);
- irq_radix_rdunlock(flags);
/* Found it, return */
if (ptr)
@@ -907,7 +854,6 @@ unsigned int irq_radix_revmap_lookup(struct irq_host *host,
void irq_radix_revmap_insert(struct irq_host *host, unsigned int virq,
irq_hw_number_t hwirq)
{
- unsigned long flags;
WARN_ON(host->revmap_type != IRQ_HOST_MAP_TREE);
@@ -920,10 +866,10 @@ void irq_radix_revmap_insert(struct irq_host *host, unsigned int virq,
return;
if (virq != NO_IRQ) {
- irq_radix_wrlock(&flags);
+ spin_lock(&host->tree_lock);
radix_tree_insert(&host->revmap_data.tree, hwirq,
&irq_map[virq]);
- irq_radix_wrunlock(flags);
+ spin_unlock(&host->tree_lock);
}
}
@@ -1041,8 +987,10 @@ static int irq_late_init(void)
* revmap_trees_allocated.
*/
list_for_each_entry(h, &irq_hosts, link) {
- if (h->revmap_type == IRQ_HOST_MAP_TREE)
+ if (h->revmap_type == IRQ_HOST_MAP_TREE) {
INIT_RADIX_TREE(&h->revmap_data.tree, GFP_ATOMIC);
+ spin_lock_init(&h->tree_lock);
+ }
}
/*
--
1.5.5.1
^ permalink raw reply related
* Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
From: Grant Likely @ 2008-08-06 13:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: devicetree-discuss, miltonm, linuxppc-dev, David Miller
In-Reply-To: <18585.31504.836857.829592@cargo.ozlabs.ibm.com>
On Wed, Aug 6, 2008 at 4:21 AM, Paul Mackerras <paulus@samba.org> wrote:
> David Miller writes:
>
>> On sparc platforms this is obtained differently. We obtain the 32-bit
>> instance value of "/chosen/stdout" and convert that into a prom device
>> node path using "instance-to-path".
>
> That's actually exactly what we do too, the linux,stdout-path property
> is just a cache of the result of that process. The difference is that
> we have to do it early on while we still have OF around, while you can
> do it later.
It's not what we do with flattened device trees blobs though. In the
flattened tree we're not using a /chosen/stdout property, just the
linux,stdout-path one.
The question that remains is; should there be? Should the dt blobs
use /chosen/stdout also? (I'm not familiar enough with real OF to
know the answer. I'm assuming that an instance value is not the same
as a phandle).
g.
>
> Paul.
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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