* Re: dtc: Assume properties preced subnodes in the flattened tree
From: Jon Loeliger @ 2007-09-07 13:41 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070904004303.GC20549@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> With kernel commit eff2ebd207af9f501af0ef667a7d14befcb36c1b, we
> clarified that in the flattened tree format, a particular nodes
> properties are required to precede its subdnodes.
>
> At present however, both dtc and libfdt will process trees which don't
> meet this condition. This patch simplifies the code for
> fdt_get_property() based on assuming that constraint. dtc continues
> to be able to handle such an invalid tree - on the grounds that it's
> useful for dtc to be able to correct such a broken tree - but this
> patch adds a warning when this condition is not met while reading a
> flattened tree.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: Document and implement an improved flash device binding
From: Segher Boessenkool @ 2007-09-07 13:58 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070907010449.GL26079@localhost.localdomain>
>>>> Let's have bank-width optional instead, it's more natural
>>>> that way for the common case of just one chip. Or, you can
>>>> say that either is optional.
>>>
>>> No, I'm disinclined to do that since bank-width is the primary bit of
>>> information that the driver needs.
>>
>> Bzzzzt. That's not what the device tree is about; it should
>> describe the hardware, it shouldn't be just a config file for
>> the current Linux drivers.
>
> Yes, yes, so you've said many times.
Glad you noticed :-)
> But where there are multiple ways of encoding exactly the same
> information, I don't see that we can't use driver convenience as a
> deciding factor.
But a driver that supports interleaving needs _both_ those pieces
of information, and a driver that doesn't needs the device-width
only.
Sure, the current MTD driver will use some heuristics to guess
the device width, but an interface via which it can get it from
the device tree will have to be added anyway.
Segher
^ permalink raw reply
* Re: [RFC/PATCH 2/2] Generic clockevents and no-idle-HZ for PowerPC
From: Johannes Berg @ 2007-09-07 14:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18144.4702.673658.336384@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 371 bytes --]
On Fri, 2007-09-07 at 00:44 +1000, Paul Mackerras wrote:
> This creates a clockevent for the PowerPC decrementer and registers it
> with the generic clock/timer system, and implements the dynamic ticks
> (no idle HZ) option for PowerPC.
I tried both patches applied and with/without CONFIG_NOHZ but my quad G5
won't boot. Anybody else have more luck?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH v2] powerpc: Add workaround for MPICs with broken register reads
From: Milton Miller @ 2007-09-07 14:11 UTC (permalink / raw)
To: Olof Johansson; +Cc: paulus, linuxppc-dev
In-Reply-To: <20070907092143.GB32102@lixom.net>
On Sep 7, 2007, at 4:21 AM, Olof Johansson wrote:
> Some versions of PWRficient 1682M have an interrupt controller in which
> the first register in each pair for interrupt sources doesn't always
> read with the right polarity/sense values.
>
> To work around this, keep a software copy of the register instead.
> Since
> it's not modified from the mpic itself, it's a feasible solution.
> Still,
> keep it under a config option to avoid wasting memory on other
> platforms.
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
>
>
> diff --git a/arch/powerpc/platforms/Kconfig
> b/arch/powerpc/platforms/Kconfig
> index 041df77..f2e7049 100644
> --- a/arch/powerpc/platforms/Kconfig
> +++ b/arch/powerpc/platforms/Kconfig
> @@ -137,6 +137,18 @@ config MPIC_U3_HT_IRQS
> depends on PPC_MAPLE
> default y
>
> +config MPIC_BROKEN_REGREAD
> + bool "MPIC workaround for broken register reads"
> + depends on MPIC
> + help
> + Say Y here to enable a MPIC driver workaround for some chips that
> + have a bug that causes some interrupt source information to not
> + read back properly. It is safe to use on other chips as well, but
> + enabling it uses about 8KB of memory to keep copies of the register
> + contents in software.
> +
> + Say N if you are unsure.
> +
>
I'm sorry, I didn't mean to imply it should be asked / selectable, just
that the help should be provided. I won't object to leaving it except
that it asks the average user unnecessary questions. In other words,
drop the question after bool.
milton
^ permalink raw reply
* Re: [PATCH 06/10] bootwrapper: Move strncmp() from flatdevtree_env.h to string.S/string.h.
From: Scott Wood @ 2007-09-07 14:24 UTC (permalink / raw)
To: galak, linuxppc-dev
In-Reply-To: <20070907005131.GF26079@localhost.localdomain>
On Fri, Sep 07, 2007 at 10:51:31AM +1000, David Gibson wrote:
> On Wed, Sep 05, 2007 at 02:21:14PM -0500, Scott Wood wrote:
> > It will be needed for PlanetCore firmware support.
> >
> > Signed-off-by: Scott Wood <scottwood@freescale.com>
>
> I still have a patch that already does this, plus strchr() as well,
> pending...
Sure, and I noted last time that this patch should be dropped if yours is
merged. I kept it in the patchset because it's needed to make later
patches build and work.
-Scott
^ permalink raw reply
* Re: Document and implement an improved flash device binding for powerpc (v5)
From: Segher Boessenkool @ 2007-09-07 14:25 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20070907032353.GA3082@localhost.localdomain>
> This patch replaces the binding for flash chips in
> booting-without-of.txt with an clarified and improved version. It
> also makes drivers/mtd/maps/physmap_of.c recognize this new binding.
> Finally it revises the Ebony device tree source to use the new binding
> as an example.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
Thanks for doing this work David!
> + /* First look for RedBoot table or partitions on the command
> + * line, these take precedence over device tree information */
Any specific reason you chose this order? Just curious...
> + .data = (void *)"jedec_probe",
Hrm, this cast is only getting rid of the const-ness of the
string literal -- maybe .data should be declared const, or
does the majority of users want it writable?
Segher
^ permalink raw reply
* Re: [PATCH 10/10] bootwrapper: Add fsl_get_immr() and 8xx/pq2 clock functions.
From: Scott Wood @ 2007-09-07 14:26 UTC (permalink / raw)
To: galak, linuxppc-dev
In-Reply-To: <20070907005357.GI26079@localhost.localdomain>
On Fri, Sep 07, 2007 at 10:53:57AM +1000, David Gibson wrote:
> Uh... doesn't this need to go in the series *before* the patch that
> uses fsl_get_immr() for the pq2 code..?
Oops, yes.
-Scott
^ permalink raw reply
* Re: Document and implement an improved flash device binding for powerpc (v5)
From: Josh Boyer @ 2007-09-07 14:28 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <2fcd14e175d5a215cd8d602ac74fce21@kernel.crashing.org>
On Fri, 7 Sep 2007 16:25:10 +0200
Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > This patch replaces the binding for flash chips in
> > booting-without-of.txt with an clarified and improved version. It
> > also makes drivers/mtd/maps/physmap_of.c recognize this new binding.
> > Finally it revises the Ebony device tree source to use the new binding
> > as an example.
> >
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
>
> Thanks for doing this work David!
Indeed. This looks good to me as well. Once it gets in a tree
somewhere I'll get Walnut switched over.
josh
^ permalink raw reply
* Re: [PATCH 1/5] Add Freescale DMA and DMA channel to Documentation/powerpc/booting-without-of.txt file.
From: Segher Boessenkool @ 2007-09-07 14:43 UTC (permalink / raw)
To: Zhang Wei; +Cc: linuxppc-dev, paulus
In-Reply-To: <1189162437484-git-send-email-wei.zhang@freescale.com>
> + l) Freescale DMA
> + - compatible : Should be "fsl,dma".
Please choose some more specific name. "fsl,mpc8540-dma" would
be a reasonable choice perhaps.
> + - reg : Offset and length of DMA general status register.
> + - ranges : Should be defined as specified in 1) to describe the
> + DMA controller channels.
> +
> + Example:
> + dma@21000 {
> + reg = <21300 4>;
Those don't agree. It's probably best to describe the whole
DMA controller register block in this node. Why do you need
subnodes for the channels at all?
Segher
^ permalink raw reply
* futex priority based wakeup
From: Benedict, Michael @ 2007-09-07 15:02 UTC (permalink / raw)
To: linuxppc-embedded
I recently upgraded to 2.6.22 to get the priority based futex wakeup
behavior. However, when I run a simple program (see below), based on
either a pthread_mutex_t or a sem_t, it seems that threads are woken up
in FIFO order. I am using glibc 2.3.6 with NPTL and TLS, based off
crossdev-0.43. Could someone help me get priority-based wakeup or point
me to a better place to get this question answered?
Thank you,
Michael
Code:
pthread_mutex_t mymutex =3D PTHREAD_MUTEX_INITIALIZER;
void *important(void *ign)
{
sleep(1);
printf("important waiting for mutex\n");
if(pthread_mutex_lock(&mymutex)) {
perror("sem_wait");
exit(1);
} else {
printf("important got mutex!\n");
pthread_mutex_unlock(&mymutex);
}
return NULL;
}
void *unimportant(void *ign)
{
printf("unimportant waiting for mutex\n");
if(pthread_mutex_lock(&mymutex)) {
perror("sem_wait");
exit(1);
} else {
printf("unimportant got mutex!\n");
pthread_mutex_unlock(&mymutex);
}
return NULL;
}
int main()
{
struct sched_param p;
pthread_attr_t attr;
pthread_t i, u;
pthread_mutex_lock(&mymutex);
p.__sched_priority =3D sched_get_priority_min(SCHED_FIFO);
if(-1 =3D=3D p.__sched_priority) {
perror("sched_get_priority_min");
return 1;
}
pthread_attr_init(&attr);
pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
pthread_attr_setschedparam(&attr, &p);
pthread_create(&u, &attr, unimportant, NULL);
p.__sched_priority =3D sched_get_priority_max(SCHED_FIFO);
pthread_attr_setschedparam(&attr, &p);
pthread_create(&i, &attr, important, NULL);
sleep(5);
printf("main unlocking mutex\n");
pthread_mutex_unlock(&mymutex);
pthread_join(u, NULL);
pthread_join(i, NULL);
return 0;
}
Which produces:
unimportant waiting for mutex
important waiting for mutex
main unlocking mutex
unimportant got mutex!
important got mutex!
^ permalink raw reply
* Re: Flash paritioning and JFFS2
From: Mirek23 @ 2007-09-07 15:23 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1187885337.5160.55.camel@louie>
Hi Michael,
>The partition information probably should go in a file that you create
>for your board located at "drivers/mtd/maps/<your_file>.c"
Thank you very much for your answer. I went through the links you
suggested.
I got a main concept how to setup the kernel to deal with Flash and JFFS2
but I do not know in which file
should be hardcoded the partition table and what should be its name. I have
the Flash memory which is CFI
compliant (Intel NOR Flash TE28F640 J3C120) so I presume that for it is a
default driver?
Do I have to create a specific file for it in drivers/mtd/maps/ ?
Best Regards
Mirek
--
View this message in context: http://www.nabble.com/Flash-paritioning-and-JFFS2-tf4317566.html#a12557406
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/5] Add Freescale DMA and DMA channel to Documentation/powerpc/booting-without-of.txt file.
From: Scott Wood @ 2007-09-07 15:31 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, paulus
In-Reply-To: <3b29878a7d3d1b14f84b5d3b182cdb98@kernel.crashing.org>
On Fri, Sep 07, 2007 at 04:43:35PM +0200, Segher Boessenkool wrote:
> Those don't agree. It's probably best to describe the whole
> DMA controller register block in this node. Why do you need
> subnodes for the channels at all?
The channels have separate registers and sometimes separate interrupts --
it's simpler to bind to a channel at a time than to parse a list of reg
blocks and interrupts. It's also more flexible in case a new chip comes
out with more/fewer channels, or if certain channels are not general
purpose.
-Scott
^ permalink raw reply
* Re: Flash paritioning and JFFS2
From: Michael Brian Willis @ 2007-09-07 15:55 UTC (permalink / raw)
To: Mirek23; +Cc: linuxppc-embedded
In-Reply-To: <12557406.post@talk.nabble.com>
On Fri, 2007-09-07 at 08:23 -0700, Mirek23 wrote:
> I have the Flash memory which is CFI
> compliant (Intel NOR Flash TE28F640 J3C120) so I presume that for it is a
> default driver?
If the flash is CFI compliant, then a default driver will probably
work.
When the kernel boots up are you able to see a message saying that it
found your flash? You might have to play around with the kernel
configuration to get it to properly recognize your flash.
> Do I have to create a specific file for it in drivers/mtd/maps/ ?
Yes, at least this is the way I did it. For example, I used
drivers/mtd/maps/tqm85xx.c as a starting point for my board specific
file. (I am using the DENX kernel).
Regards,
Michael Willis
Applied Research Labs - University of Texas
^ permalink raw reply
* Re: [PATCH 5/5] Add DMA engine driver for Freescale MPC85xx processors.
From: Randy Dunlap @ 2007-09-07 15:58 UTC (permalink / raw)
To: Zhang Wei; +Cc: shannon.nelson, linux-kernel, linuxppc-dev, paulus
In-Reply-To: <11891624582950-git-send-email-wei.zhang@freescale.com>
On Fri, 7 Sep 2007 18:54:18 +0800 Zhang Wei wrote:
> Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
> Signed-off-by: Ebony Zhu <ebony.zhu@freescale.com>
> ---
> drivers/dma/Kconfig | 8 +
> drivers/dma/Makefile | 1 +
> drivers/dma/fsldma.c | 995 ++++++++++++++++++++++++++++++++++++++++++++++++++
> drivers/dma/fsldma.h | 188 ++++++++++
> 4 files changed, 1192 insertions(+), 0 deletions(-)
> create mode 100644 drivers/dma/fsldma.c
> create mode 100644 drivers/dma/fsldma.h
>
> --- /dev/null
> +++ b/drivers/dma/fsldma.c
> @@ -0,0 +1,995 @@
Thanks for using kernel-doc notation. However, ...
> +/**
> + * fsl_dma_alloc_descriptor - Allocate descriptor from channel's DMA pool.
Function parameters need to be listed & described here.
See Documentation/kernel-doc-nano-HOWTO.txt or other source files
for examples.
(Applies to all documented function interfaces here.)
> + *
> + * Return - The descriptor allocated. NULL for failed.
> + */
> +static struct fsl_desc_sw *fsl_dma_alloc_descriptor(
> + struct fsl_dma_chan *fsl_chan,
> + gfp_t flags)
> +{
...
> +}
> +/**
> + * fsl_chan_xfer_ld_queue -- Transfer the link descriptors in channel
> + * ld_queue.
The function's "short description" (unfortunately) must be on only one
line. E.g.:
* fsl_chan_xfer_ld_queue - Transfer link descriptors in channel ld_queue.
> + */
> +static void fsl_chan_xfer_ld_queue(struct fsl_dma_chan *fsl_chan)
> +{
...
> +}
> diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
> new file mode 100644
> index 0000000..05be9ed
> --- /dev/null
> +++ b/drivers/dma/fsldma.h
> @@ -0,0 +1,188 @@
> +struct fsl_dma_chan_regs {
> + __mix32 mr; /* 0x00 - Mode Register */
> + __mix32 sr; /* 0x04 - Status Register */
> + __mix64 cdar; /* 0x08 - Cureent descriptor address register */
Current
> + __mix64 sar; /* 0x10 - Source Address Register */
> + __mix64 dar; /* 0x18 - Destination Address Register */
> + __mix32 bcr; /* 0x20 - Byte Count Register */
> + __mix64 ndar; /* 0x24 - Next Descriptor Address Register */
> +};
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* RE: [PATCH 5/5] Add DMA engine driver for Freescale MPC85xx processors.
From: Nelson, Shannon @ 2007-09-07 16:00 UTC (permalink / raw)
To: Zhang Wei, paulus; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <11891624582950-git-send-email-wei.zhang@freescale.com>
>From: Zhang Wei [mailto:wei.zhang@freescale.com]=20
>Sent: Friday, September 07, 2007 3:54 AM
>To: paulus@samba.org; Nelson, Shannon
>Cc: linux-kernel@vger.kernel.org; linuxppc-dev@ozlabs.org;=20
>galak@kernel.crashing.org; Zhang Wei; Ebony Zhu
>Subject: [PATCH 5/5] Add DMA engine driver for Freescale=20
>MPC85xx processors.
>
>The driver implements DMA engine API for Freescale MPC85xx DMA
>controller, which could be used for MEM<-->MEM, IO_ADDR<-->MEM
>and IO_ADDR<-->IO_ADDR data transfer.
>The driver supports the Basic mode of Freescale MPC85xx DMA controller.
>The MPC85xx processors supported include MPC8540/60, MPC8555, MPC8548,
>MPC8641 and so on.
>The support for MPC83xx(MPC8349, MPC8360) is experimental.
>
>Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
>Signed-off-by: Ebony Zhu <ebony.zhu@freescale.com>
>---
> drivers/dma/Kconfig | 8 +
> drivers/dma/Makefile | 1 +
> drivers/dma/fsldma.c | 995=20
>++++++++++++++++++++++++++++++++++++++++++++++++++
> drivers/dma/fsldma.h | 188 ++++++++++
> 4 files changed, 1192 insertions(+), 0 deletions(-)
> create mode 100644 drivers/dma/fsldma.c
> create mode 100644 drivers/dma/fsldma.h
>
>diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>index 8f670da..a99e925 100644
>--- a/drivers/dma/Kconfig
>+++ b/drivers/dma/Kconfig
>@@ -40,4 +40,12 @@ config INTEL_IOP_ADMA
> ---help---
> Enable support for the Intel(R) IOP Series RAID engines.
>=20
>+config FSL_DMA
>+ bool "Freescale MPC85xx/MPC83xx DMA support"
>+ depends on DMA_ENGINE && PPC
>+ ---help---
>+ Enable support for the Freescale DMA engine. Now, it support
>+ MPC8560/40, MPC8555, MPC8548 and MPC8641 processors.
>+ The MPC8349, MPC8360 support is experimental.
>+
> endmenu
If this is experimental, perhaps you should mark the depends line as
such
depends on on DMA_ENGINE && PPC && EXPERIMENTAL
[...]
>+static int fsl_dma_self_test(struct fsl_dma_chan *fsl_chan)
>+{
>+ struct dma_chan *chan;
>+ int err =3D 0;
>+ dma_addr_t addr;
>+ dma_cookie_t cookie;
>+ u8 *src, *dest;
>+ int i;
>+ size_t test_size;
>+ struct dma_async_tx_descriptor *tx1, *tx2, *tx3;
>+ struct fsl_dma_device *fdev;
>+
>+ BUG_ON(!fsl_chan);
>+
>+ fdev =3D fsl_chan->device;
>+ test_size =3D 4096;
>+
>+ src =3D kmalloc(test_size * 2, GFP_KERNEL);
>+ if (!src) {
>+ dev_err(fdev->dev,
>+ "selftest: Can not alloc memory=20
>for test!\n");
>+ err =3D -ENOMEM;
>+ goto out;
>+ }
>+
>+ dest =3D src + test_size;
>+
>+ for (i =3D 0; i < test_size; i++)
>+ src[i] =3D (u8) i;
>+
>+ chan =3D &fsl_chan->common;
>+
>+ if (fsl_dma_alloc_chan_resources(chan) < 1) {
>+ dev_err(fdev->dev,
>+ "selftest: Can not alloc=20
>resources for DMA\n");
>+ err =3D -ENODEV;
>+ goto out;
>+ }
>+
>+ /* TX 1 */
>+ tx1 =3D fsl_dma_prep_memcpy(chan, test_size / 2, 0);
>+ async_tx_ack(tx1);
>+ addr =3D dma_map_single(chan->device->dev, src, test_size / 2,
>+ DMA_TO_DEVICE);
>+ fsl_dma_set_src(addr, tx1, 0);
>+ addr =3D dma_map_single(chan->device->dev, dest, test_size / 2,
>+ =09
>DMA_FROM_DEVICE);
>+ fsl_dma_set_dest(addr, tx1, 0);
>+
>+ cookie =3D fsl_dma_tx_submit(tx1);
>+ fsl_dma_memcpy_issue_pending(chan);
>+
>+ while (fsl_dma_is_complete(chan, cookie, NULL, NULL)
>+ !=3D DMA_SUCCESS);
Is this guaranteed to finish? If there's something wrong and the DMA
never completes, you've now hung this thread. This is why the ioat_dma
engine does an msleep() and then checks once for completion. You might
think about this...
>+
>+ /* Test free and re-alloc channel resources */
>+ fsl_dma_free_chan_resources(chan);
>+
>+ if (fsl_dma_alloc_chan_resources(chan) < 1) {
>+ dev_err(fdev->dev,
>+ "selftest: Can not alloc=20
>resources for DMA\n");
>+ err =3D -ENODEV;
>+ goto out;
>+ }
>+
>+ /* Continue to test
>+ * TX 2
>+ */
>+ tx2 =3D fsl_dma_prep_memcpy(chan, test_size / 4, 0);
>+ async_tx_ack(tx2);
>+ addr =3D dma_map_single(chan->device->dev, src + test_size / 2,
>+ test_size / 4, DMA_TO_DEVICE);
>+ fsl_dma_set_src(addr, tx2, 0);
>+ addr =3D dma_map_single(chan->device->dev, dest + test_size / 2,
>+ test_size / 4, DMA_FROM_DEVICE);
>+ fsl_dma_set_dest(addr, tx2, 0);
>+
>+ /* TX 3 */
>+ tx3 =3D fsl_dma_prep_memcpy(chan, test_size / 4, 0);
>+ async_tx_ack(tx3);
>+ addr =3D dma_map_single(chan->device->dev, src +=20
>test_size * 3 / 4,
>+ test_size / 4, DMA_TO_DEVICE);
>+ fsl_dma_set_src(addr, tx3, 0);
>+ addr =3D dma_map_single(chan->device->dev, dest +=20
>test_size * 3 / 4,
>+ test_size / 4, DMA_FROM_DEVICE);
>+ fsl_dma_set_dest(addr, tx3, 0);
>+
>+ /* Test exchanging the prepared tx sort */
>+ cookie =3D fsl_dma_tx_submit(tx3);
>+ cookie =3D fsl_dma_tx_submit(tx2);
>+
>+ fsl_dma_memcpy_issue_pending(chan);
>+ while (fsl_dma_is_complete(chan, cookie, NULL, NULL)
>+ !=3D DMA_SUCCESS);
Again, is it possible to hang your thread here?
[...]
sln
--
=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=3D=3D=3D
Mr. Shannon Nelson LAN Access Division, Intel Corp.
Shannon.Nelson@intel.com I don't speak for Intel
(503) 712-7659 Parents can't afford to be squeamish.
^ permalink raw reply
* Re: [PATCH 1/5] Add Freescale DMA and DMA channel to Documentation/powerpc/booting-without-of.txt file.
From: Segher Boessenkool @ 2007-09-07 16:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20070907153116.GA15770@ld0162-tx32.am.freescale.net>
>> Those don't agree. It's probably best to describe the whole
>> DMA controller register block in this node. Why do you need
>> subnodes for the channels at all?
>
> The channels have separate registers and sometimes separate interrupts
> --
> it's simpler to bind to a channel at a time than to parse a list of reg
> blocks and interrupts. It's also more flexible in case a new chip
> comes
> out with more/fewer channels, or if certain channels are not general
> purpose.
I don't see this as more flexible, but no problem, it will work
for sure.
The "reg" vs. textual unit address issue needs to be solved though.
Segher
^ permalink raw reply
* RE: futex priority based wakeup
From: Ilya Lipovsky @ 2007-09-07 16:41 UTC (permalink / raw)
To: 'Benedict, Michael', linuxppc-embedded
In-Reply-To: <BAF8B1E0BB28024A90895E746A3B610D1C2BCD@twx-exch01.twacs.local>
Looks like it is a libc issue. Apparently, GNU libc supports priority
futexes only in version 2.5 and higher.
-----Original Message-----
From: linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.org
[mailto:linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.org] On Behalf
Of Benedict, Michael
Sent: Friday, September 07, 2007 11:02 AM
To: linuxppc-embedded@ozlabs.org
Subject: futex priority based wakeup
I recently upgraded to 2.6.22 to get the priority based futex wakeup
behavior. However, when I run a simple program (see below), based on
either a pthread_mutex_t or a sem_t, it seems that threads are woken up
in FIFO order. I am using glibc 2.3.6 with NPTL and TLS, based off
crossdev-0.43. Could someone help me get priority-based wakeup or point
me to a better place to get this question answered?
Thank you,
Michael
Code:
pthread_mutex_t mymutex = PTHREAD_MUTEX_INITIALIZER;
void *important(void *ign)
{
sleep(1);
printf("important waiting for mutex\n");
if(pthread_mutex_lock(&mymutex)) {
perror("sem_wait");
exit(1);
} else {
printf("important got mutex!\n");
pthread_mutex_unlock(&mymutex);
}
return NULL;
}
void *unimportant(void *ign)
{
printf("unimportant waiting for mutex\n");
if(pthread_mutex_lock(&mymutex)) {
perror("sem_wait");
exit(1);
} else {
printf("unimportant got mutex!\n");
pthread_mutex_unlock(&mymutex);
}
return NULL;
}
int main()
{
struct sched_param p;
pthread_attr_t attr;
pthread_t i, u;
pthread_mutex_lock(&mymutex);
p.__sched_priority = sched_get_priority_min(SCHED_FIFO);
if(-1 == p.__sched_priority) {
perror("sched_get_priority_min");
return 1;
}
pthread_attr_init(&attr);
pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
pthread_attr_setschedparam(&attr, &p);
pthread_create(&u, &attr, unimportant, NULL);
p.__sched_priority = sched_get_priority_max(SCHED_FIFO);
pthread_attr_setschedparam(&attr, &p);
pthread_create(&i, &attr, important, NULL);
sleep(5);
printf("main unlocking mutex\n");
pthread_mutex_unlock(&mymutex);
pthread_join(u, NULL);
pthread_join(i, NULL);
return 0;
}
Which produces:
unimportant waiting for mutex
important waiting for mutex
main unlocking mutex
unimportant got mutex!
important got mutex!
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [GIT PULL] FireWire fix
From: Stefan Richter @ 2007-09-07 17:04 UTC (permalink / raw)
To: Linus Torvalds
Cc: Kristian Høgsberg, linuxppc-dev, Andrew Morton,
linux1394-devel, linux-kernel
Linus, please pull from the for-linus branch at
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git for-linus
to receive a fix of the laptop-refuses-to-suspend kind. Or simply apply
the patch from this mail.
There is still an old underlying oddness though which I ask the PPC
folks to investigate and possibly fix post 2.6.23: On iBook G3 and
older PowerBooks, the onboard FireWire controller's pci_dev
current_state remains PCI_UNKNOWN long after initialization. Sounds like
a bug in platform code to me.
Stat, log, diff:
drivers/firewire/fw-ohci.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
commit 5511142870046a7bed947d51ec9b320856ee120a
Author: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date: Thu Sep 6 09:50:30 2007 +0200
firewire: fw-ohci: ignore failure of pci_set_power_state (fix suspend regression)
Fixes (papers over) "Sleep problems with kernels >= 2.6.21 on powerpc",
http://lkml.org/lkml/2007/8/25/155. The issue is that the FireWire
controller's pci_dev.current_state of iBook G3 and presumably older
PowerBooks is still in PCI_UNKNOWN instead of PCI_D0 when the firewire
driver's .suspend method is called.
Like it was suggested earlier in http://lkml.org/lkml/2006/10/24/13, we
do not fail .suspend anymore if pci_set_power_state failed.
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
diff --git a/drivers/firewire/fw-ohci.c b/drivers/firewire/fw-ohci.c
index 7e427b4..e14c1ca 100644
--- a/drivers/firewire/fw-ohci.c
+++ b/drivers/firewire/fw-ohci.c
@@ -1945,10 +1945,8 @@ static int pci_suspend(struct pci_dev *pdev, pm_message_t state)
return err;
}
err = pci_set_power_state(pdev, pci_choose_state(pdev, state));
- if (err) {
- fw_error("pci_set_power_state failed\n");
- return err;
- }
+ if (err)
+ fw_error("pci_set_power_state failed with %d\n", err);
return 0;
}
--
Stefan Richter
-=====-=-=== =--= --===
http://arcgraph.de/sr/
^ permalink raw reply related
* RE: futex priority based wakeup
From: Ilya Lipovsky @ 2007-09-07 17:16 UTC (permalink / raw)
To: 'Benedict, Michael', linuxppc-embedded
In-Reply-To: <000901c7f16d$fbbc9d40$3a0d10ac@Radstone.Local>
...Or maybe I am wrong :). Could you put fflush(stdout) after each printf,
just to be completely certain that it misbehaves?
-----Original Message-----
From: linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.org
[mailto:linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.org] On Behalf
Of Ilya Lipovsky
Sent: Friday, September 07, 2007 12:41 PM
To: 'Benedict, Michael'; linuxppc-embedded@ozlabs.org
Subject: RE: futex priority based wakeup
Looks like it is a libc issue. Apparently, GNU libc supports priority
futexes only in version 2.5 and higher.
-----Original Message-----
From: linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.org
[mailto:linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.org] On Behalf
Of Benedict, Michael
Sent: Friday, September 07, 2007 11:02 AM
To: linuxppc-embedded@ozlabs.org
Subject: futex priority based wakeup
I recently upgraded to 2.6.22 to get the priority based futex wakeup
behavior. However, when I run a simple program (see below), based on
either a pthread_mutex_t or a sem_t, it seems that threads are woken up
in FIFO order. I am using glibc 2.3.6 with NPTL and TLS, based off
crossdev-0.43. Could someone help me get priority-based wakeup or point
me to a better place to get this question answered?
Thank you,
Michael
Code:
pthread_mutex_t mymutex = PTHREAD_MUTEX_INITIALIZER;
void *important(void *ign)
{
sleep(1);
printf("important waiting for mutex\n");
if(pthread_mutex_lock(&mymutex)) {
perror("sem_wait");
exit(1);
} else {
printf("important got mutex!\n");
pthread_mutex_unlock(&mymutex);
}
return NULL;
}
void *unimportant(void *ign)
{
printf("unimportant waiting for mutex\n");
if(pthread_mutex_lock(&mymutex)) {
perror("sem_wait");
exit(1);
} else {
printf("unimportant got mutex!\n");
pthread_mutex_unlock(&mymutex);
}
return NULL;
}
int main()
{
struct sched_param p;
pthread_attr_t attr;
pthread_t i, u;
pthread_mutex_lock(&mymutex);
p.__sched_priority = sched_get_priority_min(SCHED_FIFO);
if(-1 == p.__sched_priority) {
perror("sched_get_priority_min");
return 1;
}
pthread_attr_init(&attr);
pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
pthread_attr_setschedparam(&attr, &p);
pthread_create(&u, &attr, unimportant, NULL);
p.__sched_priority = sched_get_priority_max(SCHED_FIFO);
pthread_attr_setschedparam(&attr, &p);
pthread_create(&i, &attr, important, NULL);
sleep(5);
printf("main unlocking mutex\n");
pthread_mutex_unlock(&mymutex);
pthread_join(u, NULL);
pthread_join(i, NULL);
return 0;
}
Which produces:
unimportant waiting for mutex
important waiting for mutex
main unlocking mutex
unimportant got mutex!
important got mutex!
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: futex priority based wakeup
From: Benedict, Michael @ 2007-09-07 17:24 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000a01c7f172$e5a5e9d0$3a0d10ac@Radstone.Local>
Thank you for the help!
Same result with fflush :(.
Are you maybe wrong because you have tested 2.5 and it doesn't work? Or
just uncertain?
The only thing I have read that mentions glibc version is the work Ingo
did against 2.4 glibc and in the 2.6.16-mm1 patches...
http://people.redhat.com/mingo/PI-futex-patches/. I can not detrmine
how this relates to the 2.6.22 priority based futex wakeup commit.
I am currently fighting crosstool-0.43 to build a newer glibc and I will
share results if/when I get that to work.
-Michael
Ilya Lipovsky wrote:
> ...Or maybe I am wrong :). Could you put fflush(stdout) after
> each printf,
> just to be completely certain that it misbehaves?
>=20
> -----Original Message-----
> From: linuxppc-embedded-bounces+lipovsky=3Dcs.bu.edu@ozlabs.org
> [mailto:linuxppc-embedded-bounces+lipovsky=3Dcs.bu.edu@ozlabs.or g] On
> Behalf Of Ilya Lipovsky Sent: Friday, September 07, 2007 12:41 PM
> To: 'Benedict, Michael'; linuxppc-embedded@ozlabs.org
> Subject: RE: futex priority based wakeup
>=20
> Looks like it is a libc issue. Apparently, GNU libc supports priority
> futexes only in version 2.5 and higher.
>=20
> -----Original Message-----
> From: linuxppc-embedded-bounces+lipovsky=3Dcs.bu.edu@ozlabs.org
> [mailto:linuxppc-embedded-bounces+lipovsky=3Dcs.bu.edu@ozlabs.or g] On
> Behalf Of Benedict, Michael Sent: Friday, September 07, 2007 11:02 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: futex priority based wakeup
>=20
> I recently upgraded to 2.6.22 to get the priority based futex wakeup
> behavior. However, when I run a simple program (see below), based on
> either a pthread_mutex_t or a sem_t, it seems that threads
> are woken up
> in FIFO order. I am using glibc 2.3.6 with NPTL and TLS, based off
> crossdev-0.43. Could someone help me get priority-based
> wakeup or point
> me to a better place to get this question answered? Thank you,
> Michael
>=20
> Code:
>=20
> pthread_mutex_t mymutex =3D PTHREAD_MUTEX_INITIALIZER;
>=20
> void *important(void *ign)
> {
> sleep(1);
> printf("important waiting for mutex\n");
> if(pthread_mutex_lock(&mymutex)) {
> perror("sem_wait");
> exit(1);
> } else {
> printf("important got mutex!\n");
> pthread_mutex_unlock(&mymutex);
> }
>=20
> return NULL;
> }
>=20
>=20
> void *unimportant(void *ign)
> {
> printf("unimportant waiting for mutex\n");
> if(pthread_mutex_lock(&mymutex)) {
> perror("sem_wait");
> exit(1);
> } else {
> printf("unimportant got mutex!\n");
> pthread_mutex_unlock(&mymutex);
> }
>=20
> return NULL;
> }
>=20
> int main()
> {
> struct sched_param p;
> pthread_attr_t attr;
> pthread_t i, u;
>=20
> pthread_mutex_lock(&mymutex);
>=20
> p.__sched_priority =3D sched_get_priority_min(SCHED_FIFO);
> if(-1 =3D=3D p.__sched_priority) {
> perror("sched_get_priority_min");
> return 1;
> }
> pthread_attr_init(&attr);
> pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
> pthread_attr_setschedparam(&attr, &p);
> pthread_create(&u, &attr, unimportant, NULL);
>=20
> p.__sched_priority =3D sched_get_priority_max(SCHED_FIFO);
> pthread_attr_setschedparam(&attr, &p);
> pthread_create(&i, &attr, important, NULL);
>=20
> sleep(5);
> printf("main unlocking mutex\n");
> pthread_mutex_unlock(&mymutex);
>=20
> pthread_join(u, NULL);
> pthread_join(i, NULL);
>=20
> return 0;
> }
>=20
> Which produces:
> unimportant waiting for mutex
> important waiting for mutex
> main unlocking mutex
> unimportant got mutex!
> important got mutex!
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: futex priority based wakeup
From: Ilya Lipovsky @ 2007-09-07 17:45 UTC (permalink / raw)
To: 'Benedict, Michael', linuxppc-embedded
In-Reply-To: <BAF8B1E0BB28024A90895E746A3B610D1C2BD7@twx-exch01.twacs.local>
Yes, I am uncertain. If it isn't a major headache, I think you can try the
newest version (I think it's 2.6.1) and see if you get some resolution.
Your code looks correct to me, so if the kernel developers did their job
correctly, the only potentially weak link is glibc.
I think pthread priority inheritance is an independent concept, but you
shouldn't care since you explicitly set priorities.
My kernel is 2.6.21, so I am of no help here, unfortunately.
By the way, kudos to you for making crosstool compile glibc with NPTL
support, I had issues getting there (I have 2.4 with NPTL, but it is
natively installed)! How did you manage to get around the intermediate's
compiler's lack of "__thread" support issue?
Please do share the outcome!!
-Ilya
-----Original Message-----
From: linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.org
[mailto:linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.org] On Behalf
Of Benedict, Michael
Sent: Friday, September 07, 2007 1:25 PM
To: linuxppc-embedded@ozlabs.org
Subject: RE: futex priority based wakeup
Thank you for the help!
Same result with fflush :(.
Are you maybe wrong because you have tested 2.5 and it doesn't work? Or
just uncertain?
The only thing I have read that mentions glibc version is the work Ingo
did against 2.4 glibc and in the 2.6.16-mm1 patches...
http://people.redhat.com/mingo/PI-futex-patches/. I can not detrmine
how this relates to the 2.6.22 priority based futex wakeup commit.
I am currently fighting crosstool-0.43 to build a newer glibc and I will
share results if/when I get that to work.
-Michael
Ilya Lipovsky wrote:
> ...Or maybe I am wrong :). Could you put fflush(stdout) after
> each printf,
> just to be completely certain that it misbehaves?
>
> -----Original Message-----
> From: linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.org
> [mailto:linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.or g] On
> Behalf Of Ilya Lipovsky Sent: Friday, September 07, 2007 12:41 PM
> To: 'Benedict, Michael'; linuxppc-embedded@ozlabs.org
> Subject: RE: futex priority based wakeup
>
> Looks like it is a libc issue. Apparently, GNU libc supports priority
> futexes only in version 2.5 and higher.
>
> -----Original Message-----
> From: linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.org
> [mailto:linuxppc-embedded-bounces+lipovsky=cs.bu.edu@ozlabs.or g] On
> Behalf Of Benedict, Michael Sent: Friday, September 07, 2007 11:02 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: futex priority based wakeup
>
> I recently upgraded to 2.6.22 to get the priority based futex wakeup
> behavior. However, when I run a simple program (see below), based on
> either a pthread_mutex_t or a sem_t, it seems that threads
> are woken up
> in FIFO order. I am using glibc 2.3.6 with NPTL and TLS, based off
> crossdev-0.43. Could someone help me get priority-based
> wakeup or point
> me to a better place to get this question answered? Thank you,
> Michael
>
> Code:
>
> pthread_mutex_t mymutex = PTHREAD_MUTEX_INITIALIZER;
>
> void *important(void *ign)
> {
> sleep(1);
> printf("important waiting for mutex\n");
> if(pthread_mutex_lock(&mymutex)) {
> perror("sem_wait");
> exit(1);
> } else {
> printf("important got mutex!\n");
> pthread_mutex_unlock(&mymutex);
> }
>
> return NULL;
> }
>
>
> void *unimportant(void *ign)
> {
> printf("unimportant waiting for mutex\n");
> if(pthread_mutex_lock(&mymutex)) {
> perror("sem_wait");
> exit(1);
> } else {
> printf("unimportant got mutex!\n");
> pthread_mutex_unlock(&mymutex);
> }
>
> return NULL;
> }
>
> int main()
> {
> struct sched_param p;
> pthread_attr_t attr;
> pthread_t i, u;
>
> pthread_mutex_lock(&mymutex);
>
> p.__sched_priority = sched_get_priority_min(SCHED_FIFO);
> if(-1 == p.__sched_priority) {
> perror("sched_get_priority_min");
> return 1;
> }
> pthread_attr_init(&attr);
> pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
> pthread_attr_setschedparam(&attr, &p);
> pthread_create(&u, &attr, unimportant, NULL);
>
> p.__sched_priority = sched_get_priority_max(SCHED_FIFO);
> pthread_attr_setschedparam(&attr, &p);
> pthread_create(&i, &attr, important, NULL);
>
> sleep(5);
> printf("main unlocking mutex\n");
> pthread_mutex_unlock(&mymutex);
>
> pthread_join(u, NULL);
> pthread_join(i, NULL);
>
> return 0;
> }
>
> Which produces:
> unimportant waiting for mutex
> important waiting for mutex
> main unlocking mutex
> unimportant got mutex!
> important got mutex!
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: futex priority based wakeup
From: Benedict, Michael @ 2007-09-07 17:54 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000e01c7f177$05ab1990$3a0d10ac@Radstone.Local>
I am trying to build 2.6.1 as we speak.
I don't think I said priority inheritance? If I did, sorry, must have
been confused.
As far as crosstool-0.43 and NTPL... I hate to be anti-climactic, but I
didn't really have any issues. I build with
gcc-3.4.5-glibc-2.3.6-nptl.dat, which contained:
BINUTILS_DIR=3Dbinutils-2.15
GCC_DIR=3Dgcc-3.4.5
GLIBC_DIR=3Dglibc-2.3.6
LINUX_DIR=3Dlinux-2.6.15.4
LINUX_SANITIZED_HEADER_DIR=3Dlinux-libc-headers-2.6.12.0
GLIBCTHREADS_FILENAME=3Dglibc-linuxthreads-2.3.6
GLIBC_EXTRA_CONFIG=3D"$GLIBC_EXTRA_CONFIG --with-tls --with-__thread
--enable-kernel=3D2.4.18"
GLIBC_ADDON_OPTIONS=3D"=3Dnptl =3Dnptlonly"
I will continue with updates as they happen.
Thank you again,
Michael
Ilya Lipovsky wrote:
> Yes, I am uncertain. If it isn't a major headache, I think
> you can try the
> newest version (I think it's 2.6.1) and see if you get some
> resolution.=20
>=20
> Your code looks correct to me, so if the kernel developers
> did their job
> correctly, the only potentially weak link is glibc.
>=20
> I think pthread priority inheritance is an independent
> concept, but you
> shouldn't care since you explicitly set priorities.
>=20
> My kernel is 2.6.21, so I am of no help here, unfortunately.
>=20
> By the way, kudos to you for making crosstool compile glibc with NPTL
> support, I had issues getting there (I have 2.4 with NPTL, but it is
> natively installed)! How did you manage to get around the
> intermediate's compiler's lack of "__thread" support issue?
>=20
> Please do share the outcome!!
>=20
> -Ilya
>=20
> -----Original Message-----
> From: linuxppc-embedded-bounces+lipovsky=3Dcs.bu.edu@ozlabs.org
> [mailto:linuxppc-embedded-bounces+lipovsky=3Dcs.bu.edu@ozlabs.or g] On
> Behalf Of Benedict, Michael Sent: Friday, September 07, 2007 1:25 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: RE: futex priority based wakeup
>=20
> Thank you for the help!
>=20
> Same result with fflush :(.
>=20
> Are you maybe wrong because you have tested 2.5 and it
> doesn't work? Or
> just uncertain?
>=20
> The only thing I have read that mentions glibc version is the
> work Ingo
> did against 2.4 glibc and in the 2.6.16-mm1 patches...
> http://people.redhat.com/mingo/PI-futex-patches/. I can not detrmine
> how this relates to the 2.6.22 priority based futex wakeup commit.
>=20
> I am currently fighting crosstool-0.43 to build a newer glibc
> and I will
> share results if/when I get that to work.
> -Michael
>=20
> Ilya Lipovsky wrote:
>> ...Or maybe I am wrong :). Could you put fflush(stdout) after
>> each printf,
>> just to be completely certain that it misbehaves?
>>=20
>> -----Original Message-----
>> From: linuxppc-embedded-bounces+lipovsky=3Dcs.bu.edu@ozlabs.org
>> [mailto:linuxppc-embedded-bounces+lipovsky=3Dcs.bu.edu@ozlabs.or g] =
On
>> Behalf Of Ilya Lipovsky Sent: Friday, September 07, 2007 12:41 PM
>> To: 'Benedict, Michael'; linuxppc-embedded@ozlabs.org
>> Subject: RE: futex priority based wakeup
>>=20
>> Looks like it is a libc issue. Apparently, GNU libc supports priority
>> futexes only in version 2.5 and higher.
>>=20
>> -----Original Message-----
>> From: linuxppc-embedded-bounces+lipovsky=3Dcs.bu.edu@ozlabs.org
>> [mailto:linuxppc-embedded-bounces+lipovsky=3Dcs.bu.edu@ozlabs.or g] =
On
>> Behalf Of Benedict, Michael Sent: Friday, September 07, 2007 11:02 AM
>> To: linuxppc-embedded@ozlabs.org
>> Subject: futex priority based wakeup
>>=20
>> I recently upgraded to 2.6.22 to get the priority based futex wakeup
>> behavior. However, when I run a simple program (see below), based on
>> either a pthread_mutex_t or a sem_t, it seems that threads
>> are woken up
>> in FIFO order. I am using glibc 2.3.6 with NPTL and TLS, based off
>> crossdev-0.43. Could someone help me get priority-based
>> wakeup or point
>> me to a better place to get this question answered? Thank you,
>> Michael=20
>>=20
>> Code:
>>=20
>> pthread_mutex_t mymutex =3D PTHREAD_MUTEX_INITIALIZER;
>>=20
>> void *important(void *ign)
>> {
>> sleep(1);
>> printf("important waiting for mutex\n");
>> if(pthread_mutex_lock(&mymutex)) {
>> perror("sem_wait");
>> exit(1);
>> } else {
>> printf("important got mutex!\n");
>> pthread_mutex_unlock(&mymutex);
>> }
>>=20
>> return NULL;
>> }
>>=20
>>=20
>> void *unimportant(void *ign)
>> {
>> printf("unimportant waiting for mutex\n");
>> if(pthread_mutex_lock(&mymutex)) {
>> perror("sem_wait");
>> exit(1);
>> } else {
>> printf("unimportant got mutex!\n");
>> pthread_mutex_unlock(&mymutex);
>> }
>>=20
>> return NULL;
>> }
>>=20
>> int main()
>> {
>> struct sched_param p;
>> pthread_attr_t attr;
>> pthread_t i, u;
>>=20
>> pthread_mutex_lock(&mymutex);
>>=20
>> p.__sched_priority =3D sched_get_priority_min(SCHED_FIFO);
>> if(-1 =3D=3D p.__sched_priority) {
>> perror("sched_get_priority_min");
>> return 1;
>> }
>> pthread_attr_init(&attr);
>> pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
>> pthread_attr_setschedparam(&attr, &p);
>> pthread_create(&u, &attr, unimportant, NULL);
>>=20
>> p.__sched_priority =3D sched_get_priority_max(SCHED_FIFO);
>> pthread_attr_setschedparam(&attr, &p);
>> pthread_create(&i, &attr, important, NULL);
>>=20
>> sleep(5);
>> printf("main unlocking mutex\n");
>> pthread_mutex_unlock(&mymutex);
>>=20
>> pthread_join(u, NULL);
>> pthread_join(i, NULL);
>>=20
>> return 0;
>> }
>>=20
>> Which produces:
>> unimportant waiting for mutex
>> important waiting for mutex
>> main unlocking mutex
>> unimportant got mutex!
>> important got mutex!
>>=20
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>=20
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH v2] powerpc: Add workaround for MPICs with broken register reads
From: Olof Johansson @ 2007-09-07 19:12 UTC (permalink / raw)
To: Milton Miller; +Cc: paulus, linuxppc-dev
In-Reply-To: <326829233f0e99b0e0404241f5faaa7a@bga.com>
On Fri, Sep 07, 2007 at 09:11:52AM -0500, Milton Miller wrote:
> I'm sorry, I didn't mean to imply it should be asked / selectable, just
> that the help should be provided. I won't object to leaving it except
> that it asks the average user unnecessary questions. In other words, drop
> the question after bool.
Sigh. Why is it always that the simple patches/changes require 3 respins? It's
a valid point though, posting v3.
-Olof
^ permalink raw reply
* [PATCH v3] powerpc: Add workaround for MPICs with broken register reads
From: Olof Johansson @ 2007-09-07 19:13 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, miltonm
In-Reply-To: <20070907092143.GB32102@lixom.net>
Some versions of PWRficient 1682M have an interrupt controller in which
the first register in each pair for interrupt sources doesn't always
read with the right polarity/sense values.
To work around this, keep a software copy of the register instead. Since
it's not modified from the mpic itself, it's a feasible solution. Still,
keep it under a config option to avoid wasting memory on other platforms.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 041df77..22a8fa9 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -137,6 +137,16 @@ config MPIC_U3_HT_IRQS
depends on PPC_MAPLE
default y
+config MPIC_BROKEN_REGREAD
+ bool
+ depends on MPIC
+ help
+ This option enables a MPIC driver workaround for some chips
+ that have a bug that causes some interrupt source information
+ to not read back properly. It is safe to use on other chips as
+ well, but enabling it uses about 8KB of memory to keep copies
+ of the register contents in software.
+
config IBMVIO
depends on PPC_PSERIES || PPC_ISERIES
bool
diff --git a/arch/powerpc/platforms/pasemi/Kconfig b/arch/powerpc/platforms/pasemi/Kconfig
index 95cd90f..117d90a 100644
--- a/arch/powerpc/platforms/pasemi/Kconfig
+++ b/arch/powerpc/platforms/pasemi/Kconfig
@@ -5,6 +5,7 @@ config PPC_PASEMI
select MPIC
select PPC_UDBG_16550
select PPC_NATIVE
+ select MPIC_BROKEN_REGREAD
help
This option enables support for PA Semi's PWRficient line
of SoC processors, including PA6T-1682M
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 74c64c0..c0fe063 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -228,8 +228,13 @@ static inline u32 _mpic_irq_read(struct mpic *mpic, unsigned int src_no, unsigne
unsigned int isu = src_no >> mpic->isu_shift;
unsigned int idx = src_no & mpic->isu_mask;
- return _mpic_read(mpic->reg_type, &mpic->isus[isu],
- reg + (idx * MPIC_INFO(IRQ_STRIDE)));
+#ifdef CONFIG_MPIC_BROKEN_REGREAD
+ if (reg == 0)
+ return mpic->isu_reg0_shadow[idx];
+ else
+#endif
+ return _mpic_read(mpic->reg_type, &mpic->isus[isu],
+ reg + (idx * MPIC_INFO(IRQ_STRIDE)));
}
static inline void _mpic_irq_write(struct mpic *mpic, unsigned int src_no,
@@ -240,6 +245,11 @@ static inline void _mpic_irq_write(struct mpic *mpic, unsigned int src_no,
_mpic_write(mpic->reg_type, &mpic->isus[isu],
reg + (idx * MPIC_INFO(IRQ_STRIDE)), value);
+
+#ifdef CONFIG_MPIC_BROKEN_REGREAD
+ if (reg == 0)
+ mpic->isu_reg0_shadow[idx] = value;
+#endif
}
#define mpic_read(b,r) _mpic_read(mpic->reg_type,&(b),(r))
diff --git a/include/asm-powerpc/mpic.h b/include/asm-powerpc/mpic.h
index 262db6b..c877fa7 100644
--- a/include/asm-powerpc/mpic.h
+++ b/include/asm-powerpc/mpic.h
@@ -309,6 +309,10 @@ struct mpic
unsigned long *hwirq_bitmap;
#endif
+#ifdef CONFIG_MPIC_BROKEN_REGREAD
+ u32 isu_reg0_shadow[MPIC_MAX_IRQ_SOURCES];
+#endif
+
/* link */
struct mpic *next;
^ permalink raw reply related
* Re: [RFC/PATCH 2/2] Generic clockevents and no-idle-HZ for PowerPC
From: Olof Johansson @ 2007-09-07 19:16 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1189173891.28781.162.camel@johannes.berg>
On Fri, Sep 07, 2007 at 04:04:51PM +0200, Johannes Berg wrote:
> On Fri, 2007-09-07 at 00:44 +1000, Paul Mackerras wrote:
> > This creates a clockevent for the PowerPC decrementer and registers it
> > with the generic clock/timer system, and implements the dynamic ticks
> > (no idle HZ) option for PowerPC.
>
> I tried both patches applied and with/without CONFIG_NOHZ but my quad G5
> won't boot. Anybody else have more luck?
Did you try with the two changes I suggested? Patch below.
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 1353d73..c863b07 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -554,6 +554,7 @@ void timer_interrupt(struct pt_regs * regs)
u64 tb_next_jiffy;
struct clock_event_device *evt = &per_cpu(decrementers, cpu);
+ set_dec(DECREMENTER_MAX);
#ifdef CONFIG_PPC32
if (atomic_read(&ppc_n_lost_interrupts) != 0)
do_IRQ(regs);
@@ -931,8 +932,6 @@ void __init time_init(void)
/* Register the clocksource */
clocksource_init();
-
- set_dec(DECREMENTER_MAX);
}
^ 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