* Re: [PATCH 05/33] block: Add bio_list_peek()
From: Benjamin Herrenschmidt @ 2009-06-15 1:39 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Jens Axboe, linuxppc-dev, cbe-oss-dev
In-Reply-To: <1244644748-24211-6-git-send-email-Geert.Uytterhoeven@sonycom.com>
On Wed, 2009-06-10 at 16:38 +0200, Geert Uytterhoeven wrote:
> Introduce bio_list_peek(), to obtain a pointer to the first bio on the bio_list
> without actually removing it from the list. This is needed when you want to
> serialize based on the list being empty or not.
Leaving that one (and the next one) out for now until Jens Ack them.
Cheers,
Ben.
> Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
> Cc: Jens Axboe <axboe@kernel.dk>
> ---
> include/linux/bio.h | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/bio.h b/include/linux/bio.h
> index 7b214fd..618bb7d 100644
> --- a/include/linux/bio.h
> +++ b/include/linux/bio.h
> @@ -590,6 +590,11 @@ static inline void bio_list_merge_head(struct bio_list *bl,
> bl->head = bl2->head;
> }
>
> +static inline struct bio *bio_list_peek(struct bio_list *bl)
> +{
> + return bl->head;
> +}
> +
> static inline struct bio *bio_list_pop(struct bio_list *bl)
> {
> struct bio *bio = bl->head;
^ permalink raw reply
* Re: [OOPS] hugetlbfs tests with 2.6.30-rc8-git1
From: Stephen Rothwell @ 2009-06-15 1:38 UTC (permalink / raw)
To: michael; +Cc: Mel Gorman, linuxppc-dev
In-Reply-To: <1245027396.7705.23.camel@concordia>
[-- Attachment #1: Type: text/plain, Size: 416 bytes --]
Hi Michael,
On Mon, 15 Jun 2009 10:56:36 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
>
> Rather than "-git7" can you tell us the actual SHA, I don't know what
> git7 is.
$ cat tools/get_gitid
#!/bin/sh
wget -q -O - http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-$1.id
--
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: [OOPS] hugetlbfs tests with 2.6.30-rc8-git1
From: Michael Ellerman @ 2009-06-15 0:56 UTC (permalink / raw)
To: Sachin Sant; +Cc: Mel Gorman, linuxppc-dev
In-Reply-To: <4A34E12B.4010000@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 965 bytes --]
On Sun, 2009-06-14 at 17:08 +0530, Sachin Sant wrote:
> Benjamin Herrenschmidt wrote:
> > On Fri, 2009-06-05 at 16:59 +0530, Sachin Sant wrote:
> >
> >> While executing Hugetlbfs tests against 2.6.30-rc8-git1 on a
> >> Power 6 box observed the following OOPS message.
> I was able to recreate this with 2.6.30-git7.
Hi Sachin,
Rather than "-git7" can you tell us the actual SHA, I don't know what
git7 is.
> Here is the supporting data.
>
> cpu 0x1: Vector: 300 (Data Access) at [c0000000fe9b3220]
> pc: c00000000003d620: .hpte_need_flush+0x1bc/0x2d8
> lr: c00000000003d4d0: .hpte_need_flush+0x6c/0x2d8
> sp: c0000000fe9b34a0
> msr: 8000000000009032
> dar: c0000000283b0d78
This address looks pretty innocuous, but I notice you have
DEBUG_PAGEALLOC=y, so presumably that's why it's triggering.
I can't see from the snippet of disassembly you posted where in the C
code we are, can you work it out?
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Fix invalid construct in our CPU selection Kconfig
From: Benjamin Herrenschmidt @ 2009-06-15 0:45 UTC (permalink / raw)
To: linuxppc-dev
commit 5b7c3c918c9c26c50d220b2b50359208cb5a1dbe introduced an invalid
construct in our CPU selection. This caused warnings, though it still
appeared to do the right thing.
This fixes it properly by having separate formal definitions of
PPC_BOOK3S_32 and PPC_BOOK3S_64 and one statement defining
PPC_BOOK3S based on the two above.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/platforms/Kconfig.cputype | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- linux-work.orig/arch/powerpc/platforms/Kconfig.cputype 2009-06-15 10:39:54.000000000 +1000
+++ linux-work/arch/powerpc/platforms/Kconfig.cputype 2009-06-15 10:41:48.000000000 +1000
@@ -21,7 +21,7 @@ choice
If unsure, select 52xx/6xx/7xx/74xx/82xx/83xx/86xx.
-config PPC_BOOK3S
+config PPC_BOOK3S_32
bool "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx"
select PPC_FPU
@@ -57,11 +57,14 @@ config E200
endchoice
-config PPC_BOOK3S
- default y
+config PPC_BOOK3S_64
+ def_bool y
depends on PPC64
select PPC_FPU
+config PPC_BOOK3S
+ def_bool y
+ depends on PPC_BOOK3S_32 || PPC_BOOK3S_64
config POWER4_ONLY
bool "Optimize for POWER4"
^ permalink raw reply
* Re: [PATCH 2/2] uio: add an of_genirq driver
From: Hans J. Koch @ 2009-06-14 23:50 UTC (permalink / raw)
To: Wolfram Sang
Cc: devicetree-discuss, Hans J. Koch, linux-kernel, linuxppc-dev,
Greg KH
In-Reply-To: <20090614234643.GA17791@pengutronix.de>
On Mon, Jun 15, 2009 at 01:46:43AM +0200, Wolfram Sang wrote:
>
> > driver. A user _has_ to setup irq, if there is none, he still has to set
> > irq=UIO_IRQ_NONE. For that matter, 'not specified' and 'not found' is both
> > the same bad thing.
>
> Hmm, what should I do?
>
> A typical interrupts-property in a device-tree is specified as:
>
> interrupts = <&irq_controller_node irq_number irq_sense>;
>
> Something like UIO_IRQ_NONE does not fit into this scheme, even more as it is
> Linux-specific and device trees need to be OS independant.
>
> I'm pretty sure the correct way to state that you don't need an interrupt in
> the device-tree is to simply not specify the above interrupt property.
>
> Well, yes, that means you can't distinguish between 'forgotten' and
> 'intentionally left out'. I wonder if it is really that bad? If something does
> not work (= one is missing interrupts), the first place to look at is the
> device tree. If one does not see an interrupt-property, voila, problem solved.
>
> (Note that with my latest suggestion, a _wrong_ interrupt is handled the same
> way as with platform_data. request_irq() should equally fail if the
> return-value from irq_of_parse_and_map() is simply forwarded.)
I agree. And assuming Alan is right, forget what I said about IRQ 0 being a
valid interrupt number.
Thanks,
Hans
>
> --
> Pengutronix e.K. | Wolfram Sang |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 2/2] uio: add an of_genirq driver
From: Wolfram Sang @ 2009-06-14 23:46 UTC (permalink / raw)
To: Hans J. Koch; +Cc: devicetree-discuss, Greg KH, linux-kernel, linuxppc-dev
In-Reply-To: <20090614230135.GI3639@local>
[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]
> driver. A user _has_ to setup irq, if there is none, he still has to set
> irq=UIO_IRQ_NONE. For that matter, 'not specified' and 'not found' is both
> the same bad thing.
Hmm, what should I do?
A typical interrupts-property in a device-tree is specified as:
interrupts = <&irq_controller_node irq_number irq_sense>;
Something like UIO_IRQ_NONE does not fit into this scheme, even more as it is
Linux-specific and device trees need to be OS independant.
I'm pretty sure the correct way to state that you don't need an interrupt in
the device-tree is to simply not specify the above interrupt property.
Well, yes, that means you can't distinguish between 'forgotten' and
'intentionally left out'. I wonder if it is really that bad? If something does
not work (= one is missing interrupts), the first place to look at is the
device tree. If one does not see an interrupt-property, voila, problem solved.
(Note that with my latest suggestion, a _wrong_ interrupt is handled the same
way as with platform_data. request_irq() should equally fail if the
return-value from irq_of_parse_and_map() is simply forwarded.)
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] uio: add an of_genirq driver
From: Hans J. Koch @ 2009-06-14 23:45 UTC (permalink / raw)
To: Alan Cox
Cc: devicetree-discuss, Hans J. Koch, linux-kernel, linuxppc-dev,
Greg KH
In-Reply-To: <20090615001207.1829e7b5@lxorguk.ukuu.org.uk>
On Mon, Jun 15, 2009 at 12:12:07AM +0100, Alan Cox wrote:
> > > + if (!uioinfo->irq)
> > > + uioinfo->irq = UIO_IRQ_NONE;
> >
> > Please don't do this. It's inconsistent if all other UIO drivers require
> > people to use UIO_IRQ_NONE and you also allow zero. UIO_IRQ_NONE was
> > introduced because 0 may be a legal interrupt number on some platforms.
>
> Zero is not a valid IRQ number in the kernel (except in arch specific
> depths). IRQ numbers are also *unsigned* so -1 isn't a safe definition.
The above uioinfo->irq is a signed long.
>
> Zero means no IRQ. If any old UIO code is assuming otherwise it wants
> fixing.
It doesn't. It won't complain about IRQ 0 and will pass it on to
request_irq, which will probably fail if it is as you say.
I did it that way because I saw IRQ 0 in /proc/interrupts on every PC...
>
> It is the job of the platform to map a physical IRQ 0 to some other
> representation if it exists outside of arch specific code.
Funny.
> This was
> decided some years ago and a large part of the kernel simply doesn't
> support any notion of a real IRQ 0.
Can you tell me the reason for that decision or point me to some ml archive?
Thanks,
Hans
>
> Alan
^ permalink raw reply
* Re: [PATCH 2/2] uio: add an of_genirq driver
From: Alan Cox @ 2009-06-14 23:12 UTC (permalink / raw)
To: Hans J. Koch
Cc: devicetree-discuss, Hans J. Koch, linux-kernel, linuxppc-dev,
Greg KH
In-Reply-To: <20090614122136.GD3639@local>
> > + if (!uioinfo->irq)
> > + uioinfo->irq = UIO_IRQ_NONE;
>
> Please don't do this. It's inconsistent if all other UIO drivers require
> people to use UIO_IRQ_NONE and you also allow zero. UIO_IRQ_NONE was
> introduced because 0 may be a legal interrupt number on some platforms.
Zero is not a valid IRQ number in the kernel (except in arch specific
depths). IRQ numbers are also *unsigned* so -1 isn't a safe definition.
Zero means no IRQ. If any old UIO code is assuming otherwise it wants
fixing.
It is the job of the platform to map a physical IRQ 0 to some other
representation if it exists outside of arch specific code. This was
decided some years ago and a large part of the kernel simply doesn't
support any notion of a real IRQ 0.
Alan
^ permalink raw reply
* Re: [PATCH 2/2] uio: add an of_genirq driver
From: Hans J. Koch @ 2009-06-14 23:01 UTC (permalink / raw)
To: Wolfram Sang
Cc: devicetree-discuss, Hans J. Koch, linux-kernel, linuxppc-dev,
Greg KH
In-Reply-To: <20090614220022.GB24323@pengutronix.de>
On Mon, Jun 15, 2009 at 12:00:22AM +0200, Wolfram Sang wrote:
> > > For x86 it's not defined at all. But as this code is for the PowerPC,
> >
> > No, it isn't. What makes you say that? The Kconfig entry doesn't depend
> > on PowerPC. I compiled it on x86...
>
> It depends on OF. You could compile on x86? Have to check that...
Ooops, forget it. It cannot be selected on x86. I was a bit distracted when
I wrote that, sorry.
>
> > > where using NO_IRQ seems still to be OK.
> >
> > No. uio_pdrv_genirq can be used on all platforms, and not all platforms have
> > NO_IRQ. NO_IRQ can be used in platform specific code only.
>
> Well, the wrapper uses irq_of_parse_and_map(). So far, it returns NO_IRQ if an
> IRQ was not specified (or not found). I could check if there was an
> interrupt-property at all, so I can distinguish between 'not specified' and
> 'not found'. Then, UIO_IRQ_NONE would only be used, if there was none
> specified. Otherwise it will always be the result from irq_of_parse_and_map(),
> whatever that is (even NO_IRQ). Is this what you have in mind?
I would find it better if probe() failed if no irq is specified, printing a
message that tells the user to setup his data correctly before loading the
driver. A user _has_ to setup irq, if there is none, he still has to set
irq=UIO_IRQ_NONE. For that matter, 'not specified' and 'not found' is both
the same bad thing.
Thanks,
Hans
>
> Regards,
>
> Wolfram
>
> --
> Pengutronix e.K. | Wolfram Sang |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 2/2] uio: add an of_genirq driver
From: Wolfram Sang @ 2009-06-14 22:00 UTC (permalink / raw)
To: Hans J. Koch; +Cc: devicetree-discuss, Greg KH, linux-kernel, linuxppc-dev
In-Reply-To: <20090614203444.GH3639@local>
[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]
> > For x86 it's not defined at all. But as this code is for the PowerPC,
>
> No, it isn't. What makes you say that? The Kconfig entry doesn't depend
> on PowerPC. I compiled it on x86...
It depends on OF. You could compile on x86? Have to check that...
> > where using NO_IRQ seems still to be OK.
>
> No. uio_pdrv_genirq can be used on all platforms, and not all platforms have
> NO_IRQ. NO_IRQ can be used in platform specific code only.
Well, the wrapper uses irq_of_parse_and_map(). So far, it returns NO_IRQ if an
IRQ was not specified (or not found). I could check if there was an
interrupt-property at all, so I can distinguish between 'not specified' and
'not found'. Then, UIO_IRQ_NONE would only be used, if there was none
specified. Otherwise it will always be the result from irq_of_parse_and_map(),
whatever that is (even NO_IRQ). Is this what you have in mind?
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] uio: add an of_genirq driver
From: Wolfram Sang @ 2009-06-14 21:46 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, Hans J. Koch, linux-kernel, devicetree-discuss
In-Reply-To: <20090614192707.GA11003@suse.de>
[-- Attachment #1: Type: text/plain, Size: 1107 bytes --]
On Sun, Jun 14, 2009 at 12:27:07PM -0700, Greg KH wrote:
> On Sun, Jun 14, 2009 at 09:05:33PM +0200, Wolfram Sang wrote:
> > Well, I assume that issues regarding checkpatch do not have the highest
> > priority (especially while the merge-window is open), which is understandable.
>
> Hm, the "merge-window" for new stuff like these patches is pretty much
> already closed, as you didn't send them _before_ the merge window opened
> up. You need to get them to us sooner, so we can test stuff out in the
> -next tree for a while before we can merge them.
Seems you got me wrong here :)
As I stated in the introduction ("PATCH [0/2]"), this patch series is _not_
meant for the current merge-window. I just happened to be done with it now.
With the above sentence I just wanted to give a hint, why there was not a reply
to my checkpatch-mail (as Hans seemed to be concerned about that there was
none).
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] uio: add an of_genirq driver
From: Hans J. Koch @ 2009-06-14 20:34 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: devicetree-discuss, Hans J. Koch, linux-kernel, linuxppc-dev,
Greg KH
In-Reply-To: <4A355155.4020500@grandegger.com>
On Sun, Jun 14, 2009 at 09:36:53PM +0200, Wolfgang Grandegger wrote:
> >>>> if (uioinfo->irq == NO_IRQ)
> >>>> uioinfo->irq = UIO_IRQ_NONE;
> >>> Sorry for my ignorance, but what is NO_IRQ? If I do
>
> It's 0 on PowerPC but ARM seems still to use -1.
Using 0 is simply wrong, especially if people do something like
if (!irq)
return -ERROR;
IRQ number 0 _is_ a valid irq. Maybe not on all platforms, but in generic
code (like UIO) you have to assume it is.
>
> http://lxr.linux.no/linux+v2.6.30/arch/powerpc/include/asm/irq.h#L29
>
> For x86 it's not defined at all. But as this code is for the PowerPC,
No, it isn't. What makes you say that? The Kconfig entry doesn't depend
on PowerPC. I compiled it on x86...
> where using NO_IRQ seems still to be OK.
No. uio_pdrv_genirq can be used on all platforms, and not all platforms have
NO_IRQ. NO_IRQ can be used in platform specific code only.
Anyway, if someone fills in an invalid irq in his platform data, he deserves
to crash. No need for that test. UIO docs state that irq is a _required_
element. If you forget to set it, it will probably be 0. On most platforms,
register_irq will fail with that, and you'll notice. If you silently
replace it with UIO_IRQ_NONE, you simply cover up wrong code.
Thanks,
Hans
>
> Wolfgang.
^ permalink raw reply
* Re: [PATCH 2/2] uio: add an of_genirq driver
From: Greg KH @ 2009-06-14 19:27 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, Hans J. Koch, linux-kernel, devicetree-discuss
In-Reply-To: <20090614190533.GA7387@pengutronix.de>
On Sun, Jun 14, 2009 at 09:05:33PM +0200, Wolfram Sang wrote:
> Well, I assume that issues regarding checkpatch do not have the highest
> priority (especially while the merge-window is open), which is understandable.
Hm, the "merge-window" for new stuff like these patches is pretty much
already closed, as you didn't send them _before_ the merge window opened
up. You need to get them to us sooner, so we can test stuff out in the
-next tree for a while before we can merge them.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 2/2] uio: add an of_genirq driver
From: Wolfgang Grandegger @ 2009-06-14 19:36 UTC (permalink / raw)
To: Hans J. Koch; +Cc: devicetree-discuss, Greg KH, linux-kernel, linuxppc-dev
In-Reply-To: <20090614192359.GG3639@local>
Hans J. Koch wrote:
> On Sun, Jun 14, 2009 at 09:05:33PM +0200, Wolfram Sang wrote:
>>> Anyway, 0 is a valid IRQ number, so it cannot be used as "no irq".
>> May I point you to this thread?
>>
>> http://lkml.org/lkml/2005/11/21/221
>
> Linus is just plain wrong in this 4 year old mail.
See also this related thread.
http://groups.google.com/group/rtc-linux/browse_thread/thread/9816648d5a8a1c9e/9968968188b5ab5a?lnk=gst&q=rx8025#9968968188b5ab5a
>
>> (The issue comes up once in a while as some archs still use NO_IRQ, some with
>> 0 some with -1)
>>
>>>> if (uioinfo->irq == NO_IRQ)
>>>> uioinfo->irq = UIO_IRQ_NONE;
>>> Sorry for my ignorance, but what is NO_IRQ? If I do
It's 0 on PowerPC but ARM seems still to use -1.
http://lxr.linux.no/linux+v2.6.30/arch/powerpc/include/asm/irq.h#L29
For x86 it's not defined at all. But as this code is for the PowerPC,
where using NO_IRQ seems still to be OK.
Wolfgang.
^ permalink raw reply
* Re: [PATCH 2/2] uio: add an of_genirq driver
From: Hans J. Koch @ 2009-06-14 19:23 UTC (permalink / raw)
To: Wolfram Sang
Cc: devicetree-discuss, Hans J. Koch, linux-kernel, linuxppc-dev,
Greg KH
In-Reply-To: <20090614190533.GA7387@pengutronix.de>
On Sun, Jun 14, 2009 at 09:05:33PM +0200, Wolfram Sang wrote:
>
> > Anyway, 0 is a valid IRQ number, so it cannot be used as "no irq".
>
> May I point you to this thread?
>
> http://lkml.org/lkml/2005/11/21/221
Linus is just plain wrong in this 4 year old mail.
>
> (The issue comes up once in a while as some archs still use NO_IRQ, some with
> 0 some with -1)
>
> > > if (uioinfo->irq == NO_IRQ)
> > > uioinfo->irq = UIO_IRQ_NONE;
> >
> > Sorry for my ignorance, but what is NO_IRQ? If I do a
> >
> > grep -r NO_IRQ include/
> >
> > I get nothing.
>
> Try a 'cd arch' before that :)
no such luck in arch/x86/ ...
>
> > Well, you claim it's a false positive. So far, you did not get any responses,
> > AFAICS. I tend to agree with you, but I'd like to avoid patches that don't
> > pass checkpatch.pl, whatever the reason. Either the false positive gets
> > confirmed and fixed, or you should fix your patch.
>
> Well, I assume that issues regarding checkpatch do not have the highest
> priority (especially while the merge-window is open), which is understandable.
> Fixing this bug (I take any bets that this is one ;)) might not be so trivial,
> as modifying $Attributes can easily have lots of side-effects.
>
> Now, all this does not matter much, as the objections Grant raised are valid
> and there might be a totally different outcome to bind devices to UIO. But at
> least, we have some code to discuss...
OK, I'm looking forward to your next version.
Thanks,
Hans
>
> Regards,
>
> Wolfram
>
> --
> Pengutronix e.K. | Wolfram Sang |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 2/2] uio: add an of_genirq driver
From: Wolfram Sang @ 2009-06-14 19:05 UTC (permalink / raw)
To: Hans J. Koch; +Cc: linuxppc-dev, devicetree-discuss, linux-kernel, Greg KH
In-Reply-To: <20090614183357.GE3639@local>
[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]
> Anyway, 0 is a valid IRQ number, so it cannot be used as "no irq".
May I point you to this thread?
http://lkml.org/lkml/2005/11/21/221
(The issue comes up once in a while as some archs still use NO_IRQ, some with
0 some with -1)
> > if (uioinfo->irq == NO_IRQ)
> > uioinfo->irq = UIO_IRQ_NONE;
>
> Sorry for my ignorance, but what is NO_IRQ? If I do a
>
> grep -r NO_IRQ include/
>
> I get nothing.
Try a 'cd arch' before that :)
> Well, you claim it's a false positive. So far, you did not get any responses,
> AFAICS. I tend to agree with you, but I'd like to avoid patches that don't
> pass checkpatch.pl, whatever the reason. Either the false positive gets
> confirmed and fixed, or you should fix your patch.
Well, I assume that issues regarding checkpatch do not have the highest
priority (especially while the merge-window is open), which is understandable.
Fixing this bug (I take any bets that this is one ;)) might not be so trivial,
as modifying $Attributes can easily have lots of side-effects.
Now, all this does not matter much, as the objections Grant raised are valid
and there might be a totally different outcome to bind devices to UIO. But at
least, we have some code to discuss...
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] uio: add an of_genirq driver
From: Hans J. Koch @ 2009-06-14 18:33 UTC (permalink / raw)
To: Wolfram Sang
Cc: devicetree-discuss, Hans J. Koch, linux-kernel, linuxppc-dev,
Greg KH
In-Reply-To: <20090614171406.GA1010@pengutronix.de>
On Sun, Jun 14, 2009 at 07:14:06PM +0200, Wolfram Sang wrote:
> Hello Hans,
>
> > > + uioinfo->irq = irq_of_parse_and_map(op->node, 0);
> > > + if (!uioinfo->irq)
> > > + uioinfo->irq = UIO_IRQ_NONE;
> >
> > Please don't do this. It's inconsistent if all other UIO drivers require
> > people to use UIO_IRQ_NONE and you also allow zero. UIO_IRQ_NONE was
> > introduced because 0 may be a legal interrupt number on some platforms.
>
> Yes, well, the '0' vs. 'NO_IRQ' thing is still not fully sorted out AFAIK.
A "cat /proc/interrupts" on any common x86 PC shows you that IRQ 0 is used
there. OK, it's unlikely someone wants to write a UIO driver for that one,
but that might be different on other platforms.
Anyway, 0 is a valid IRQ number, so it cannot be used as "no irq".
> But you are possibly right here, as long as irq_of_parse_and_map does return
> NO_IRQ, I should explicitly check for it, like this:
>
> if (uioinfo->irq == NO_IRQ)
> uioinfo->irq = UIO_IRQ_NONE;
Sorry for my ignorance, but what is NO_IRQ? If I do a
grep -r NO_IRQ include/
I get nothing.
>
> > > +/* Match table for of_platform binding */
> > > +static const struct of_device_id __devinitconst uio_of_genirq_match[] = {
> >
> > checkpatch.pl complains about that. Please check.
>
> Did that, it is a false positive. See here:
>
> http://lkml.indiana.edu/hypermail/linux/kernel/0906.1/02780.html
Well, you claim it's a false positive. So far, you did not get any responses,
AFAICS. I tend to agree with you, but I'd like to avoid patches that don't
pass checkpatch.pl, whatever the reason. Either the false positive gets
confirmed and fixed, or you should fix your patch.
Thanks,
Hans
>
> Regards,
>
> Wolfram
>
> --
> Pengutronix e.K. | Wolfram Sang |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 2/2] uio: add an of_genirq driver
From: Wolfram Sang @ 2009-06-14 17:14 UTC (permalink / raw)
To: Hans J. Koch; +Cc: linuxppc-dev, devicetree-discuss, linux-kernel, Greg KH
In-Reply-To: <20090614122136.GD3639@local>
[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]
Hello Hans,
> > + uioinfo->irq = irq_of_parse_and_map(op->node, 0);
> > + if (!uioinfo->irq)
> > + uioinfo->irq = UIO_IRQ_NONE;
>
> Please don't do this. It's inconsistent if all other UIO drivers require
> people to use UIO_IRQ_NONE and you also allow zero. UIO_IRQ_NONE was
> introduced because 0 may be a legal interrupt number on some platforms.
Yes, well, the '0' vs. 'NO_IRQ' thing is still not fully sorted out AFAIK. But
you are possibly right here, as long as irq_of_parse_and_map does return
NO_IRQ, I should explicitly check for it, like this:
if (uioinfo->irq == NO_IRQ)
uioinfo->irq = UIO_IRQ_NONE;
> > +/* Match table for of_platform binding */
> > +static const struct of_device_id __devinitconst uio_of_genirq_match[] = {
>
> checkpatch.pl complains about that. Please check.
Did that, it is a false positive. See here:
http://lkml.indiana.edu/hypermail/linux/kernel/0906.1/02780.html
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] uio: add an of_genirq driver
From: Grant Likely @ 2009-06-14 14:40 UTC (permalink / raw)
To: Wolfram Sang
Cc: devicetree-discuss, Hans J. Koch, linux-kernel, linuxppc-dev,
Greg KH
In-Reply-To: <1244765062-14144-3-git-send-email-w.sang@pengutronix.de>
On Thu, Jun 11, 2009 at 6:04 PM, Wolfram Sang<w.sang@pengutronix.de> wrote:
> Picking up the now exported generic probe function from the
> platform-variant of this driver, this patch adds an of-version. Also add
> the binding documentation.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Hans J. Koch <hjk@linutronix.de>
> Cc: Greg KH <gregkh@suse.de>
> ---
>
> In probe, I put the resources-array on the stack to simplify the code. If=
this
> is considered too huge for the stack (140 byte for a 32-bit system at the
> moment), I can also post a version using kzalloc.
>
> =A0Documentation/powerpc/dts-bindings/uio-generic.txt | =A0 16 +++
> =A0drivers/uio/Kconfig =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0| =A0 =A06 +
> =A0drivers/uio/Makefile =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 | =A0 =A01 +
> =A0drivers/uio/uio_of_genirq.c =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0| =A0 98 ++++++++++++++++++++
> =A04 files changed, 121 insertions(+), 0 deletions(-)
> =A0create mode 100644 Documentation/powerpc/dts-bindings/uio-generic.txt
> =A0create mode 100644 drivers/uio/uio_of_genirq.c
>
> diff --git a/Documentation/powerpc/dts-bindings/uio-generic.txt b/Documen=
tation/powerpc/dts-bindings/uio-generic.txt
> new file mode 100644
> index 0000000..8ad9861
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/uio-generic.txt
> @@ -0,0 +1,16 @@
> +UIO for custom devices
> +
> +A device which will be mapped using the UIO subsystem.
> +
> +Properties:
> + - compatible : should contain the specific model used, followed by
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"generic-uio".
> + - reg : address range(s) of the device (up to MAX_UIO_MAPS)
> + - interrupts : interrupt of the device
> +
> +Example:
> + =A0 =A0 =A0 =A0c64fpga@0 {
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0compatible =3D "ptx,c64fpga001", "generi=
c-uio";
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reg =3D <0x0 0x10000>;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0interrupts =3D <0 0 3>;
> + =A0 =A0 =A0 =A0};
Hmmm, I'm not happy about this. The device tree describes the
hardware, not the way Linux uses the hardware. UIO definitely falls
into the category of Linux implementation detail.
This should be approached from the other way around. Either the
generic-uio of_platform driver should contain an explicit list of
devices to be handled by UIO, or the OF infrastructure should be
modified to allow things like force binding of_devices to of_drivers
at runtime.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Esben Haabendal @ 2009-06-14 14:04 UTC (permalink / raw)
To: Ben Dooks; +Cc: linuxppc-dev, linux-i2c
In-Reply-To: <20090614131605.GK20446@fluff.org.uk>
Ben Dooks wrote:
> is there a new version of this patch available?
>
>
I will catch up on it ASAP.
/Esben
^ permalink raw reply
* Re: [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg
From: Ben Dooks @ 2009-06-14 13:16 UTC (permalink / raw)
To: Esben Haabendal; +Cc: linuxppc-dev, linux-i2c
In-Reply-To: <4A124202.4010201@doredevelopment.dk>
is there a new version of this patch available?
--
Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
^ permalink raw reply
* Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation
From: Avi Kivity @ 2009-06-14 13:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, Linus Torvalds, linux-kernel, linuxppc-dev
In-Reply-To: <18996.60235.178618.531664@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Avi Kivity writes:
>
>
>> An alternative implementation using 64-bit cmpxchg will recover most of
>> the costs of hashed spinlocks. I assume most serious 32-bit
>> architectures have them?
>>
>
> Have a 64-bit cmpxchg, you mean? x86 is the only one I know of, and
> it already has an atomic64_t implementation using cmpxchg8b (or
> whatever it's called).
>
Yes (and it is cmpxchg8b). I'm surprised powerpc doesn't have DCAS support.
> My thinking is that the 32-bit non-x86 architectures will be mostly
> UP, so the overhead is just an interrupt enable/restore. Those that
> are SMP I would expect to be small SMP -- mostly just 2 cpus and maybe
> a few 4-way systems.
>
The new Nehalems provide 8 logical threads in a single socket. All
those threads share a cache, and they have cmpxchg8b anyway, so this
won't matter.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 1/2] uio/pdrv_genirq: Refactor probe routine to expose a generic part
From: Hans J. Koch @ 2009-06-14 12:15 UTC (permalink / raw)
To: Wolfram Sang
Cc: devicetree-discuss, Hans J. Koch, linux-kernel, linuxppc-dev,
Greg KH
In-Reply-To: <1244765062-14144-2-git-send-email-w.sang@pengutronix.de>
On Fri, Jun 12, 2009 at 02:04:21AM +0200, Wolfram Sang wrote:
> This patch refactors the probe routine, so that an of-version of a similiar
> driver can pick it up later.
Looks good to me.
Signed-off-by: Hans J. Koch <hjk@linutronix.de>
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Hans J. Koch <hjk@linutronix.de>
> Cc: Greg KH <gregkh@suse.de>
> ---
> drivers/uio/uio_pdrv_genirq.c | 60 ++++++++++++++++++++------------------
> include/linux/uio_pdrv_genirq.h | 13 ++++++++
> 2 files changed, 45 insertions(+), 28 deletions(-)
> create mode 100644 include/linux/uio_pdrv_genirq.h
>
> diff --git a/drivers/uio/uio_pdrv_genirq.c b/drivers/uio/uio_pdrv_genirq.c
> index 3f06818..8f8a0f9 100644
> --- a/drivers/uio/uio_pdrv_genirq.c
> +++ b/drivers/uio/uio_pdrv_genirq.c
> @@ -20,15 +20,10 @@
> #include <linux/bitops.h>
> #include <linux/interrupt.h>
> #include <linux/stringify.h>
> +#include <linux/uio_pdrv_genirq.h>
>
> #define DRIVER_NAME "uio_pdrv_genirq"
>
> -struct uio_pdrv_genirq_platdata {
> - struct uio_info *uioinfo;
> - spinlock_t lock;
> - unsigned long flags;
> -};
> -
> static irqreturn_t uio_pdrv_genirq_handler(int irq, struct uio_info *dev_info)
> {
> struct uio_pdrv_genirq_platdata *priv = dev_info->priv;
> @@ -68,29 +63,18 @@ static int uio_pdrv_genirq_irqcontrol(struct uio_info *dev_info, s32 irq_on)
> return 0;
> }
>
> -static int uio_pdrv_genirq_probe(struct platform_device *pdev)
> +int __uio_pdrv_genirq_probe(struct device *dev, struct uio_info *uioinfo,
> + struct resource *resources, unsigned int num_resources)
> {
> - struct uio_info *uioinfo = pdev->dev.platform_data;
> struct uio_pdrv_genirq_platdata *priv;
> struct uio_mem *uiomem;
> - int ret = -EINVAL;
> - int i;
> -
> - if (!uioinfo || !uioinfo->name || !uioinfo->version) {
> - dev_err(&pdev->dev, "missing platform_data\n");
> - goto bad0;
> - }
> -
> - if (uioinfo->handler || uioinfo->irqcontrol ||
> - uioinfo->irq_flags & IRQF_SHARED) {
> - dev_err(&pdev->dev, "interrupt configuration error\n");
> - goto bad0;
> - }
> + unsigned int i;
> + int ret;
>
> priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> if (!priv) {
> ret = -ENOMEM;
> - dev_err(&pdev->dev, "unable to kmalloc\n");
> + dev_err(dev, "unable to kmalloc\n");
> goto bad0;
> }
>
> @@ -100,14 +84,14 @@ static int uio_pdrv_genirq_probe(struct platform_device *pdev)
>
> uiomem = &uioinfo->mem[0];
>
> - for (i = 0; i < pdev->num_resources; ++i) {
> - struct resource *r = &pdev->resource[i];
> + for (i = 0; i < num_resources; ++i) {
> + struct resource *r = resources + i;
>
> if (r->flags != IORESOURCE_MEM)
> continue;
>
> if (uiomem >= &uioinfo->mem[MAX_UIO_MAPS]) {
> - dev_warn(&pdev->dev, "device has more than "
> + dev_warn(dev, "device has more than "
> __stringify(MAX_UIO_MAPS)
> " I/O memory resources.\n");
> break;
> @@ -138,19 +122,39 @@ static int uio_pdrv_genirq_probe(struct platform_device *pdev)
> uioinfo->irqcontrol = uio_pdrv_genirq_irqcontrol;
> uioinfo->priv = priv;
>
> - ret = uio_register_device(&pdev->dev, priv->uioinfo);
> + ret = uio_register_device(dev, priv->uioinfo);
> if (ret) {
> - dev_err(&pdev->dev, "unable to register uio device\n");
> + dev_err(dev, "unable to register uio device\n");
> goto bad1;
> }
>
> - platform_set_drvdata(pdev, priv);
> + dev_set_drvdata(dev, priv);
> return 0;
> bad1:
> kfree(priv);
> bad0:
> return ret;
> }
> +EXPORT_SYMBOL_GPL(__uio_pdrv_genirq_probe);
> +
> +static int uio_pdrv_genirq_probe(struct platform_device *pdev)
> +{
> + struct uio_info *uioinfo = pdev->dev.platform_data;
> +
> + if (!uioinfo || !uioinfo->name || !uioinfo->version) {
> + dev_err(&pdev->dev, "missing platform_data\n");
> + return -EINVAL;
> + }
> +
> + if (uioinfo->handler || uioinfo->irqcontrol ||
> + uioinfo->irq_flags & IRQF_SHARED) {
> + dev_err(&pdev->dev, "interrupt configuration error\n");
> + return -EINVAL;
> + }
> +
> + return __uio_pdrv_genirq_probe(&pdev->dev, uioinfo, pdev->resource,
> + pdev->num_resources);
> +}
>
> static int uio_pdrv_genirq_remove(struct platform_device *pdev)
> {
> diff --git a/include/linux/uio_pdrv_genirq.h b/include/linux/uio_pdrv_genirq.h
> new file mode 100644
> index 0000000..a410390
> --- /dev/null
> +++ b/include/linux/uio_pdrv_genirq.h
> @@ -0,0 +1,13 @@
> +#ifndef _LINUX_UIO_PDRV_GENIRQ_H
> +#define _LINUX_UIO_PDRV_GENIRQ_H
> +
> +struct uio_pdrv_genirq_platdata {
> + struct uio_info *uioinfo;
> + spinlock_t lock;
> + unsigned long flags;
> +};
> +
> +extern int __uio_pdrv_genirq_probe(struct device *dev, struct uio_info *uioinfo,
> + struct resource *resources, unsigned int num_resources);
> +
> +#endif
> --
> 1.6.3.1
^ permalink raw reply
* Re: [PATCH 2/2] uio: add an of_genirq driver
From: Hans J. Koch @ 2009-06-14 12:21 UTC (permalink / raw)
To: Wolfram Sang
Cc: devicetree-discuss, Hans J. Koch, linux-kernel, linuxppc-dev,
Greg KH
In-Reply-To: <1244765062-14144-3-git-send-email-w.sang@pengutronix.de>
On Fri, Jun 12, 2009 at 02:04:22AM +0200, Wolfram Sang wrote:
> Picking up the now exported generic probe function from the
> platform-variant of this driver, this patch adds an of-version. Also add
> the binding documentation.
Some minor problems, see below.
>
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Hans J. Koch <hjk@linutronix.de>
> Cc: Greg KH <gregkh@suse.de>
> ---
>
> In probe, I put the resources-array on the stack to simplify the code. If this
> is considered too huge for the stack (140 byte for a 32-bit system at the
> moment), I can also post a version using kzalloc.
>
> Documentation/powerpc/dts-bindings/uio-generic.txt | 16 +++
> drivers/uio/Kconfig | 6 +
> drivers/uio/Makefile | 1 +
> drivers/uio/uio_of_genirq.c | 98 ++++++++++++++++++++
> 4 files changed, 121 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/uio-generic.txt
> create mode 100644 drivers/uio/uio_of_genirq.c
>
> diff --git a/Documentation/powerpc/dts-bindings/uio-generic.txt b/Documentation/powerpc/dts-bindings/uio-generic.txt
> new file mode 100644
> index 0000000..8ad9861
> --- /dev/null
> +++ b/Documentation/powerpc/dts-bindings/uio-generic.txt
> @@ -0,0 +1,16 @@
> +UIO for custom devices
> +
> +A device which will be mapped using the UIO subsystem.
> +
> +Properties:
> + - compatible : should contain the specific model used, followed by
> + "generic-uio".
> + - reg : address range(s) of the device (up to MAX_UIO_MAPS)
> + - interrupts : interrupt of the device
> +
> +Example:
> + c64fpga@0 {
> + compatible = "ptx,c64fpga001", "generic-uio";
> + reg = <0x0 0x10000>;
> + interrupts = <0 0 3>;
> + };
> diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig
> index 7f86534..18efe38 100644
> --- a/drivers/uio/Kconfig
> +++ b/drivers/uio/Kconfig
> @@ -46,6 +46,12 @@ config UIO_PDRV_GENIRQ
>
> If you don't know what to do here, say N.
>
> +config UIO_OF_GENIRQ
> + tristate "Userspace I/O OF driver with generic IRQ handling"
> + depends on UIO_PDRV_GENIRQ && OF
> + help
> + OF wrapper for the above platform driver.
> +
> config UIO_SMX
> tristate "SMX cryptengine UIO interface"
> default n
> diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> index 5c2586d..089fd56 100644
> --- a/drivers/uio/Makefile
> +++ b/drivers/uio/Makefile
> @@ -2,6 +2,7 @@ obj-$(CONFIG_UIO) += uio.o
> obj-$(CONFIG_UIO_CIF) += uio_cif.o
> obj-$(CONFIG_UIO_PDRV) += uio_pdrv.o
> obj-$(CONFIG_UIO_PDRV_GENIRQ) += uio_pdrv_genirq.o
> +obj-$(CONFIG_UIO_OF_GENIRQ) += uio_of_genirq.o
> obj-$(CONFIG_UIO_SMX) += uio_smx.o
> obj-$(CONFIG_UIO_AEC) += uio_aec.o
> obj-$(CONFIG_UIO_SERCOS3) += uio_sercos3.o
> diff --git a/drivers/uio/uio_of_genirq.c b/drivers/uio/uio_of_genirq.c
> new file mode 100644
> index 0000000..254ec5b
> --- /dev/null
> +++ b/drivers/uio/uio_of_genirq.c
> @@ -0,0 +1,98 @@
> +/*
> + * OF wrapper to make use of the uio_pdrv_genirq-driver.
> + *
> + * Copyright (C) 2009 Wolfram Sang, Pengutronix
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published by
> + * the Free Software Foundation.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/uio_driver.h>
> +#include <linux/of_device.h>
> +#include <linux/of_platform.h>
> +#include <linux/uio_pdrv_genirq.h>
> +
> +#define OF_DRIVER_VERSION "1"
> +
> +static __devinit int uio_of_genirq_probe(struct of_device *op,
> + const struct of_device_id *match)
> +{
> + struct uio_info *uioinfo;
> + struct resource resources[MAX_UIO_MAPS];
> + int i, ret;
> +
> + uioinfo = kzalloc(sizeof(*uioinfo), GFP_KERNEL);
> + if (!uioinfo)
> + return -ENOMEM;
> +
> + uioinfo->name = op->node->name;
> + uioinfo->version = OF_DRIVER_VERSION;
> + uioinfo->irq = irq_of_parse_and_map(op->node, 0);
> + if (!uioinfo->irq)
> + uioinfo->irq = UIO_IRQ_NONE;
Please don't do this. It's inconsistent if all other UIO drivers require
people to use UIO_IRQ_NONE and you also allow zero. UIO_IRQ_NONE was
introduced because 0 may be a legal interrupt number on some platforms.
> +
> + for (i = 0; i < MAX_UIO_MAPS; ++i)
> + if (of_address_to_resource(op->node, i, &resources[i]))
> + break;
> +
> + ret = __uio_pdrv_genirq_probe(&op->dev, uioinfo, &resources, i);
> + if (ret)
> + goto err_cleanup;
> +
> + return 0;
> +
> +err_cleanup:
> + if (uioinfo->irq != UIO_IRQ_NONE)
> + irq_dispose_mapping(uioinfo->irq);
> +
> + kfree(uioinfo);
> + return ret;
> +}
> +
> +static __devexit int uio_of_genirq_remove(struct of_device *op)
> +{
> + struct uio_pdrv_genirq_platdata *priv = dev_get_drvdata(&op->dev);
> +
> + uio_unregister_device(priv->uioinfo);
> +
> + if (priv->uioinfo->irq != UIO_IRQ_NONE)
> + irq_dispose_mapping(priv->uioinfo->irq);
> +
> + kfree(priv->uioinfo);
> + kfree(priv);
> + return 0;
> +}
> +
> +/* Match table for of_platform binding */
> +static const struct of_device_id __devinitconst uio_of_genirq_match[] = {
checkpatch.pl complains about that. Please check.
> + { .compatible = "generic-uio", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, uio_of_genirq_match);
> +
> +static struct of_platform_driver uio_of_genirq_driver = {
> + .owner = THIS_MODULE,
> + .name = "uio-of-genirq",
> + .match_table = uio_of_genirq_match,
> + .probe = uio_of_genirq_probe,
> + .remove = __devexit_p(uio_of_genirq_remove),
> +};
> +
> +static inline int __init uio_of_genirq_init(void)
> +{
> + return of_register_platform_driver(&uio_of_genirq_driver);
> +}
> +module_init(uio_of_genirq_init);
> +
> +static inline void __exit uio_of_genirq_exit(void)
> +{
> + of_unregister_platform_driver(&uio_of_genirq_driver);
> +}
> +module_exit(uio_of_genirq_exit);
> +
> +MODULE_AUTHOR("Wolfram Sang");
> +MODULE_DESCRIPTION("Userspace I/O OF driver with generic IRQ handling");
> +MODULE_LICENSE("GPL v2");
> --
> 1.6.3.1
^ permalink raw reply
* Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation
From: Paul Mackerras @ 2009-06-14 12:21 UTC (permalink / raw)
To: Avi Kivity; +Cc: akpm, Linus Torvalds, linux-kernel, linuxppc-dev
In-Reply-To: <4A34E4A5.3040306@redhat.com>
Avi Kivity writes:
> An alternative implementation using 64-bit cmpxchg will recover most of
> the costs of hashed spinlocks. I assume most serious 32-bit
> architectures have them?
Have a 64-bit cmpxchg, you mean? x86 is the only one I know of, and
it already has an atomic64_t implementation using cmpxchg8b (or
whatever it's called).
My thinking is that the 32-bit non-x86 architectures will be mostly
UP, so the overhead is just an interrupt enable/restore. Those that
are SMP I would expect to be small SMP -- mostly just 2 cpus and maybe
a few 4-way systems.
Paul.
^ 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