* [PATCH] fbdev/xilinxfb: Fix improper casting and tighen up probe path
From: Grant Likely @ 2009-06-12 17:57 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, benh, john.linn
From: Grant Likely <grant.likely@secretlab.ca>
The xilinxfb driver is improperly casting a physical address to a
u32, and the probe routine isn't as straight forward as it could be.
(discovered by gcc spitting out warnings on most recent change to
xilinxfb driver).
This patch fixes the cast and simplifies the probe path.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
John, can you please test and verify this fix is correct?
Thanks,
g.
drivers/video/xilinxfb.c | 59 ++++++++++++++++++----------------------------
1 files changed, 23 insertions(+), 36 deletions(-)
diff --git a/drivers/video/xilinxfb.c b/drivers/video/xilinxfb.c
index 7a868bd..b68b331 100644
--- a/drivers/video/xilinxfb.c
+++ b/drivers/video/xilinxfb.c
@@ -124,7 +124,6 @@ struct xilinxfb_drvdata {
registers */
dcr_host_t dcr_host;
- unsigned int dcr_start;
unsigned int dcr_len;
void *fb_virt; /* virt. address of the frame buffer */
@@ -325,8 +324,8 @@ static int xilinxfb_assign(struct device *dev,
drvdata->regs);
}
/* Put a banner in the log (for DEBUG) */
- dev_dbg(dev, "fb: phys=%p, virt=%p, size=%x\n",
- (void *)drvdata->fb_phys, drvdata->fb_virt, fbsize);
+ dev_dbg(dev, "fb: phys=%llx, virt=%p, size=%x\n",
+ (unsigned long long)drvdata->fb_phys, drvdata->fb_virt, fbsize);
return 0; /* success */
@@ -404,9 +403,7 @@ xilinxfb_of_probe(struct of_device *op, const struct of_device_id *match)
u32 tft_access;
struct xilinxfb_platform_data pdata;
struct resource res;
- int size, rc;
- int start = 0, len = 0;
- dcr_host_t dcr_host;
+ int size, rc, start;
struct xilinxfb_drvdata *drvdata;
/* Copy with the default pdata (not a ptr reference!) */
@@ -414,35 +411,39 @@ xilinxfb_of_probe(struct of_device *op, const struct of_device_id *match)
dev_dbg(&op->dev, "xilinxfb_of_probe(%p, %p)\n", op, match);
+ /* Allocate the driver data region */
+ drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata) {
+ dev_err(&op->dev, "Couldn't allocate device private record\n");
+ return -ENOMEM;
+ }
+
/*
* To check whether the core is connected directly to DCR or PLB
* interface and initialize the tft_access accordingly.
*/
p = (u32 *)of_get_property(op->node, "xlnx,dcr-splb-slave-if", NULL);
-
- if (p)
- tft_access = *p;
- else
- tft_access = 0; /* For backward compatibility */
+ tft_access = p ? *p : 0;
/*
* Fill the resource structure if its direct PLB interface
* otherwise fill the dcr_host structure.
*/
if (tft_access) {
+ drvdata->flags |= PLB_ACCESS_FLAG;
rc = of_address_to_resource(op->node, 0, &res);
if (rc) {
dev_err(&op->dev, "invalid address\n");
- return -ENODEV;
+ goto err;
}
-
} else {
+ res.start = 0;
start = dcr_resource_start(op->node, 0);
- len = dcr_resource_len(op->node, 0);
- dcr_host = dcr_map(op->node, start, len);
- if (!DCR_MAP_OK(dcr_host)) {
- dev_err(&op->dev, "invalid address\n");
- return -ENODEV;
+ drvdata->dcr_len = dcr_resource_len(op->node, 0);
+ drvdata->dcr_host = dcr_map(op->node, start, drvdata->len);
+ if (!DCR_MAP_OK(drvdata->dcr_host)) {
+ dev_err(&op->dev, "invalid DCR address\n");
+ goto err;
}
}
@@ -467,26 +468,12 @@ xilinxfb_of_probe(struct of_device *op, const struct of_device_id *match)
if (of_find_property(op->node, "rotate-display", NULL))
pdata.rotate_screen = 1;
- /* Allocate the driver data region */
- drvdata = kzalloc(sizeof(*drvdata), GFP_KERNEL);
- if (!drvdata) {
- dev_err(&op->dev, "Couldn't allocate device private record\n");
- return -ENOMEM;
- }
dev_set_drvdata(&op->dev, drvdata);
+ return xilinxfb_assign(&op->dev, drvdata, res.start, &pdata);
- if (tft_access)
- drvdata->flags |= PLB_ACCESS_FLAG;
-
- /* Arguments are passed based on the interface */
- if (drvdata->flags & PLB_ACCESS_FLAG) {
- return xilinxfb_assign(&op->dev, drvdata, res.start, &pdata);
- } else {
- drvdata->dcr_start = start;
- drvdata->dcr_len = len;
- drvdata->dcr_host = dcr_host;
- return xilinxfb_assign(&op->dev, drvdata, 0, &pdata);
- }
+ err:
+ kfree(drvdata);
+ return -ENODEV;
}
static int __devexit xilinxfb_of_remove(struct of_device *op)
^ permalink raw reply related
* Re: [PATCH RFC] powerpc: Implement atomic64_t for 32-bit processors
From: Kyle McMartin @ 2009-06-12 17:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <55D4E406-B6C5-471F-B7FF-86106CCC0ABF@kernel.crashing.org>
On Fri, Jun 12, 2009 at 09:04:52AM -0500, Kumar Gala wrote:
>> On UP, all the spinlock manipulation goes away and we simply disable
>> interrupts around each operation. In fact gcc eliminates the whole
>> atomic64_lock variable as well.
>>
>> Signed-off-by: Paul Mackerras <paulus@samba.org>
>> ---
>> Compile-tested only at this stage, which is why it's [RFC].
>
> any reason not to make this lib/asm generic? Seems like it isn't ppc
> specific.
>
Indeed... PA-RISC uses these for all atomics, since we have no useful
atomic insns to implement them... I'd be happy to submit a cleanup after
you merge this, if you don't have time to ahead of time.
regards, Kyle
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Dan Williams @ 2009-06-12 17:38 UTC (permalink / raw)
To: Kumar Gala
Cc: David Hawkins, Ira Snyder, Liu Dave-R63238,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, Li Yang,
Timur Tabi
In-Reply-To: <24633D89-D4EC-4C27-8B7F-3992EFE50989@kernel.crashing.org>
Kumar Gala wrote:
> On Jun 12, 2009, at 4:23 AM, Li Yang wrote:
>
>> On Thu, Jun 11, 2009 at 11:17 PM, Ira Snyder<iws@ovro.caltech.edu>
>> wrote:
>>> On Wed, Jun 10, 2009 at 09:45:26PM -0500, Kumar Gala wrote:
>>>> On Apr 27, 2009, at 3:49 PM, Dan Williams wrote:
>>>>
>>>>> On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi <timur@freescale.com>
>>>>> wrote:
>>>>>> Adding Kumar to the CC: list, since he might pick up the patch.
>>>>>>
>>>>> Acked-by: Dan Williams <dan.j.williams@intel.com>
>>>>>
>>>>> I agree with taking this through Kumar's tree.
>>>> I'm going through patches for .31.. Should I still pick this up?
>>>> Going
>>>> forward should I pick up fsldma patches?
>>>>
>>> I'm fine with that, but you should probably talk to Li Yang (added to
>>> CC). He's gotten in contact with me a few times recently.
>> I am fine with both ways for this patch as it is only related to
>> Freescale register details. But in general I think patches should go
>> through functional subsystem, as they usually would need insight of
>> the subsystem architecture. I prefer the way that the patch acked or
>> signed-off by Freescale guys and push upstream through Dan's tree as
>> most other subsystems did. Unless Dan prefers to ack the subsystem
>> architectural part of each patch and have them pushed other way.
>
> I agree w/this and just wanting to see what Dan's preference is.
I'll take fsldma patches through the dmaengine tree with Leo's
ack/sign-off. That last request was a one-off because I had nothing
else to push and the discussion was very architecture specific.
Thanks,
Dan
^ permalink raw reply
* Re: [PATCH] fsldma: use PCI Read Multiple command
From: Kumar Gala @ 2009-06-12 15:03 UTC (permalink / raw)
To: Li Yang
Cc: David Hawkins, Ira Snyder, Liu Dave-R63238, linux-kernel,
linuxppc-dev, Dan Williams, Timur Tabi
In-Reply-To: <2a27d3730906120223w9f30b7ewfd22eb328e3a23d3@mail.gmail.com>
On Jun 12, 2009, at 4:23 AM, Li Yang wrote:
> On Thu, Jun 11, 2009 at 11:17 PM, Ira Snyder<iws@ovro.caltech.edu>
> wrote:
>> On Wed, Jun 10, 2009 at 09:45:26PM -0500, Kumar Gala wrote:
>>>
>>> On Apr 27, 2009, at 3:49 PM, Dan Williams wrote:
>>>
>>>> On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi <timur@freescale.com>
>>>> wrote:
>>>>> Adding Kumar to the CC: list, since he might pick up the patch.
>>>>>
>>>>
>>>> Acked-by: Dan Williams <dan.j.williams@intel.com>
>>>>
>>>> I agree with taking this through Kumar's tree.
>>>
>>> I'm going through patches for .31.. Should I still pick this up?
>>> Going
>>> forward should I pick up fsldma patches?
>>>
>>
>> I'm fine with that, but you should probably talk to Li Yang (added to
>> CC). He's gotten in contact with me a few times recently.
>
> I am fine with both ways for this patch as it is only related to
> Freescale register details. But in general I think patches should go
> through functional subsystem, as they usually would need insight of
> the subsystem architecture. I prefer the way that the patch acked or
> signed-off by Freescale guys and push upstream through Dan's tree as
> most other subsystems did. Unless Dan prefers to ack the subsystem
> architectural part of each patch and have them pushed other way.
I agree w/this and just wanting to see what Dan's preference is.
- k
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-06-12 14:23 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <20090612141118.GK32105@elte.hu>
On Fri, 2009-06-12 at 16:11 +0200, Ingo Molnar wrote:
> > Maybe. But maybe it's representative... so far in this merge
> > window, 100% of the powerpc build and runtime breakage upstream
> > comes from stuff that didn't get into -next before.
>
> But that's axiomatic, isnt it? linux-next build-tests PowerPC as the
> first in the row of tests - so no change that was in linux-next can
> ever cause a build failure on PowerPC, right?
I'd have to check with Stephen but I think linux-next tests a whole
bunch of archs each round. Anyway, the idea is, just don't get things
upstream before the at least had a chance to go through that little bit
of integration testing .. Is it -that- hard ?
Oh and before you ask me, yes, I do the same mistakes, and I have been
caught too merging things at the last minute that ended up broken and
that could have been caught by -next... I'm just trying to advocate the
idea that we all try to improve in that area :-)
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-06-12 14:19 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <20090612140730.GJ32105@elte.hu>
> Uhm, the bug you are making a big deal of would have been found and
> fixed by Paulus a few hours after any such mail - and probably by me
> too as i do daily cross builds to Power.
>
> So yes, we had a bug, but any extra linux-next hoops would not have
> prevented it: i could still have messed up by getting lured by that
> nice piece of Power7 hardware enablement patch on the last day ;-)
>
> So the bug was my fault for being too fast-and-loose with that
> particular patch, creating a ~5-commits-hop build breakage bisection
> window on Power.
>
> Now that i'm sufficiently chastised, can we now move on please? :)
Sure we can :-) My point is, get a break before you merge upstream :-)
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-06-12 14:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <1244815574.7172.171.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2009-06-12 at 15:49 +0200, Ingo Molnar wrote:
> > * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > > On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> > > > On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> > >
> > > > To some extent, here, the issue is on Linus side and it's up to him (Hey
> > > > Linus ! still listening ?) to maybe be more proactive at giving an ack
> > > > or nack so that we can get a chance to do that final pass of ironing out
> > > > the mechanical bugs before we hit the main tree.
> > >
> > > Let me add a little bit more background to my reasoning here and why I
> > > think having this integration testing step is so valuable...
> > >
> > > It all boils down to bisection and having a bisectable tree.
> >
> > I think you are way too concentrated on this particular incident,
> > and you are generalizing it into something that is not so in
> > practice.
>
> Maybe. But maybe it's representative... so far in this merge
> window, 100% of the powerpc build and runtime breakage upstream
> comes from stuff that didn't get into -next before.
But that's axiomatic, isnt it? linux-next build-tests PowerPC as the
first in the row of tests - so no change that was in linux-next can
ever cause a build failure on PowerPC, right?
Ingo
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-06-12 14:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <1244814976.7172.164.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2009-06-12 at 15:44 +0200, Ingo Molnar wrote:
>
> > This is certainly doable for agreeable features - which is the bulk
> > - and it is being done.
> >
> > But this is a catch-22 for _controversial_ new features - which
> > perfcounters clearly was, in case you turned off your lkml
> > subscription ;-)
>
> I didn't :-) My point here is that Linus can make a decision with
> an email -before- merging so that -next gets a chance, at least
> for a couple of days, to do the integration testing once the
> controversy has been sorted by his highness.
Uhm, the bug you are making a big deal of would have been found and
fixed by Paulus a few hours after any such mail - and probably by me
too as i do daily cross builds to Power.
So yes, we had a bug, but any extra linux-next hoops would not have
prevented it: i could still have messed up by getting lured by that
nice piece of Power7 hardware enablement patch on the last day ;-)
So the bug was my fault for being too fast-and-loose with that
particular patch, creating a ~5-commits-hop build breakage bisection
window on Power.
Now that i'm sufficiently chastised, can we now move on please? :)
Ingo
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-06-12 14:06 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <20090612134940.GD32105@elte.hu>
On Fri, 2009-06-12 at 15:49 +0200, Ingo Molnar wrote:
> * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> > > On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> >
> > > To some extent, here, the issue is on Linus side and it's up to him (Hey
> > > Linus ! still listening ?) to maybe be more proactive at giving an ack
> > > or nack so that we can get a chance to do that final pass of ironing out
> > > the mechanical bugs before we hit the main tree.
> >
> > Let me add a little bit more background to my reasoning here and why I
> > think having this integration testing step is so valuable...
> >
> > It all boils down to bisection and having a bisectable tree.
>
> I think you are way too concentrated on this particular incident,
> and you are generalizing it into something that is not so in
> practice.
Maybe. But maybe it's representative... so far in this merge window,
100% of the powerpc build and runtime breakage upstream comes from stuff
that didn't get into -next before.
Some of the runtime breakage in powerpc-next comes from my own bugs,
indeed, and fortunately I caught it before I asked Linus to pull.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH RFC] powerpc: Implement atomic64_t for 32-bit processors
From: Kumar Gala @ 2009-06-12 14:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18994.17381.129339.162342@cargo.ozlabs.ibm.com>
On Jun 12, 2009, at 7:02 AM, Paul Mackerras wrote:
> 32-bit powerpc processors have no 64-bit atomic instructions, but we
> will
> need atomic64_t in order to support the perf_counter subsystem on 32-
> bit
> processors.
>
> This adds an implementation of 64-bit atomic operations using hashed
> spinlocks to provide atomicity. For each atomic operation, the
> address
> of the atomic64_t variable is hashed to an index into an array of 16
> spinlocks. That spinlock is taken (with interrupts disabled) around
> the
> operation, which can then be coded non-atomically within the lock.
>
> On UP, all the spinlock manipulation goes away and we simply disable
> interrupts around each operation. In fact gcc eliminates the whole
> atomic64_lock variable as well.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> Compile-tested only at this stage, which is why it's [RFC].
any reason not to make this lib/asm generic? Seems like it isn't ppc
specific.
- k
^ permalink raw reply
* Re: "next" branch update
From: Benjamin Herrenschmidt @ 2009-06-12 13:59 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev list
In-Reply-To: <ed82fe3e0906120654m22f38569jea21dfaf9449c34c@mail.gmail.com>
On Fri, 2009-06-12 at 08:54 -0500, Timur Tabi wrote:
> On Fri, Jun 12, 2009 at 2:29 AM, Benjamin
> Herrenschmidt<benh@kernel.crashing.org> wrote:
> > I pushed the following commits, along with merging Linus tree in today.
>
> Is there a reason you keep ignoring my patch?
Other than I hate you ? just kidding :-)
> [PATCH 1/2 v9] powerpc: introduce macro spin_event_timeout()
>
> There is PowerPC code in the ALSA tree that depends on my patch, so
> that code will break if you don't push my patch upstream.
I know, and you may have noticed I haven't sent a pull request to Linus
yet... I was planning on scrubbing patchwork once more today and got
sidetracked with fixing the breakage that went into mainline already
while I was not looking :-)
I haven't closed powerpc-next, I know I'm late, but don't worry, your
patch is on my todo list.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/6] rapidio: add common mapping APIs for RapidIO memory access
From: Kumar Gala @ 2009-06-12 13:58 UTC (permalink / raw)
To: Li Yang; +Cc: Zhang Wei, netdev, linux-kernel, davem, linuxppc-dev, akpm
In-Reply-To: <2a27d3730906120627l112030b3wa11ea5aa3fcb1087@mail.gmail.com>
On Jun 12, 2009, at 8:27 AM, Li Yang wrote:
> On Thu, Jun 11, 2009 at 9:32 PM, Kumar
> Gala<galak@kernel.crashing.org> wrote:
>>
>> On Jun 11, 2009, at 4:47 AM, Li Yang-R58472 wrote:
>>
>>>> On May 12, 2009, at 3:35 AM, Li Yang wrote:
>>>>
>>>>> Add the mapping functions used to support direct IO memory
>>>>> access of
>>>>> rapidIO.
>>>>>
>>>>> Signed-off-by: Zhang Wei <zw@zh-kernel.org>
>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>>
>>>> Use inbnd/outbnd instead of inb/outb which make one think of
>>>> byte level io accessors.
>>>>
>>>> As I look at this I don't think this is the correct API. I
>>>> think we should be using the DMA mapping API to hide these
>>>> details. The concept of mapping like this seems to be more a
>>>> function of FSL's Address translation/mapping unit (ATMU) than
>>>> anything specific to the RIO bus standard.
>>>
>>> This is a separate RIO block level ATMU. Although it looks like the
>>> system level ATMU, system ATMU doesn't have the knowledge of rapidIO
>>> target device ID. The mapping need to be dynamic, as it's easy to
>>> have
>>> more RIO devices than the outbound windows.
>>
>> I understand that. What I'm saying is the RIO block level ATMU is a
>> Freescale specific detail and not part of any standard RIO bus
>> programming
>> model. We have mapping APIs that we can connect to for this via
>> the DMA API
>> layer.
>
> Ok, I see your point now. Do you mean dma_map_*() for DMA API layer?
> But in my understanding the current dma_map_*() APIs are preparing
> local memory for device to access which is similar to the inbound
> case. Is it suitable to also use them for mapping device's space for
> CPU access? Can you give an example of using this API for Address
> Translation and Mapping purpose?
Yes, I meant the dma_map_*() API. Any system with a true IOMMU uses
the dma_map_ layer as the way to do address translation.
- k
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-06-12 13:56 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <20090612134428.GC32105@elte.hu>
On Fri, 2009-06-12 at 15:44 +0200, Ingo Molnar wrote:
> This is certainly doable for agreeable features - which is the bulk
> - and it is being done.
>
> But this is a catch-22 for _controversial_ new features - which
> perfcounters clearly was, in case you turned off your lkml
> subscription ;-)
I didn't :-) My point here is that Linus can make a decision with an
email -before- merging so that -next gets a chance, at least for a
couple of days, to do the integration testing once the controversy has
been sorted by his highness.
> And if you hit that build breakage during bisection you can do:
>
> git cherry-pick e14112d
Right, I can, you can, but can random tester who wants to track down
what his problem is ? I'm not sure...
> Also, you seem to brush off the notion that far more bugs slip
> through linux-next than get caught by it.
Less than without linux-next. We aren't perfect and no process will
solve everything. But this could have been easily avoided.
> So if you think linux-next matters in terms of _regression_ testing,
> the numbers dont seem to support that notion. This particular
> incident does support that notion though, granted - but it's taken
> out of context IMHO:
>
> In terms of test coverage, at least for our trees, less than 1% of
> the bugs we handle get reported in a linux-next context - and most
> of the bugs that get reported (against say the scheduler tree) are
> related to rare architectures.
But most obvious bugs will have been caught way before that, which
leaves the hard to catch ones or the configuration-specific ones. Those
will pass linux-next, I agree. But that isn't my point and that isn't
what linux-next will catch. What is will catch is that kind of really
simple mechanical problems, such as build breakage for other archs.
If perfcounters had been 1 or 2 days in -next before being merged, we
would have avoided that problem and made everybody's bisecting life
easier.
> In fact, i checked, there were _zero_ x86 bugs reported against
> linux-next and solved against it between v2.6.30-rc1 and v2.6.30:
No but Stephen caught a bunch of mechanical compile fails due to
integration problems.
> git log --grep=next -i v2.6.30-rc1..v2.6.30 arch/x86/
>
> Doing it over the full cycle shows one commit altogether - a Xen
> build failure. In fact, i just checked the whole stabilization cycle
> for the whole kernel (v2.6.30-rc1..v2.6.30-final), and there were
> only 5 linux-next originated patches, most of them build failures.
>
> I did this by looking at all occurances of 'next', in all commit
> logs:
>
> git log --grep=next -i v2.6.30-rc1..v2.6.30
>
> and then manually checking the context of all 'next' matches and
> counting the linux-next related commits.
>
> So lets be generous and say that because some people dont put the
> bug report originator into the changelog it was four times as many,
> 20 - but that's still dwarved by the sheer amount of post-rc1
> changes: thousands of changes and hundreds of regressions.
>
> linux-next is mostly useful (to me at least) not for the
> cross-builds it does, but in terms of mapping out upcoming conflicts
> - which also drives early detection of problematic patches and
> problematic conflicts.
Yes, it does. The problem is that it helps -you- that way, but won't
help -us- vs. that kind of mechanical problems unless -you- also play
the game and get your stuff in there for a little while before merging
it :-)
Cheers,
Ben.
^ permalink raw reply
* Re: "next" branch update
From: Timur Tabi @ 2009-06-12 13:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1244791784.7172.69.camel@pasglop>
On Fri, Jun 12, 2009 at 2:29 AM, Benjamin
Herrenschmidt<benh@kernel.crashing.org> wrote:
> I pushed the following commits, along with merging Linus tree in today.
Is there a reason you keep ignoring my patch?
[PATCH 1/2 v9] powerpc: introduce macro spin_event_timeout()
There is PowerPC code in the ALSA tree that depends on my patch, so
that code will break if you don't push my patch upstream.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-06-12 13:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <1244813397.7172.156.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
>
> > To some extent, here, the issue is on Linus side and it's up to him (Hey
> > Linus ! still listening ?) to maybe be more proactive at giving an ack
> > or nack so that we can get a chance to do that final pass of ironing out
> > the mechanical bugs before we hit the main tree.
>
> Let me add a little bit more background to my reasoning here and why I
> think having this integration testing step is so valuable...
>
> It all boils down to bisection and having a bisectable tree.
I think you are way too concentrated on this particular incident,
and you are generalizing it into something that is not so in
practice.
Even in this particular case, there's just 3 other commit points in
the Git tree between commit 8a1ca8c (the breakage on PowerPC) and
e14112d (the fix). We'll have up to 10,000 commits.
I bisect on an almost daily basis, and i'm not seeing unreasonable
problems.
Ingo
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-06-12 13:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <1244812224.7172.146.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > linux-next should not be second-guessing maintainers and should
> > not act as an "approval forum" for controversial features,
> > increasing the (already quite substantial) pressure on
> > maintainers to apply more crap.
>
> I agree here. That's not the point. The idea is that for things
> that -are- approved by their respective maintainers, to get some
> integration testing and ironing of those mechanical bugs so that
> by the time they hit mainstream, they don't break bisection among
> others.
This is certainly doable for agreeable features - which is the bulk
- and it is being done.
But this is a catch-22 for _controversial_ new features - which
perfcounters clearly was, in case you turned off your lkml
subscription ;-)
And if you hit that build breakage during bisection you can do:
git cherry-pick e14112d
Also, you seem to brush off the notion that far more bugs slip
through linux-next than get caught by it.
So if you think linux-next matters in terms of _regression_ testing,
the numbers dont seem to support that notion. This particular
incident does support that notion though, granted - but it's taken
out of context IMHO:
In terms of test coverage, at least for our trees, less than 1% of
the bugs we handle get reported in a linux-next context - and most
of the bugs that get reported (against say the scheduler tree) are
related to rare architectures.
In fact, i checked, there were _zero_ x86 bugs reported against
linux-next and solved against it between v2.6.30-rc1 and v2.6.30:
git log --grep=next -i v2.6.30-rc1..v2.6.30 arch/x86/
Doing it over the full cycle shows one commit altogether - a Xen
build failure. In fact, i just checked the whole stabilization cycle
for the whole kernel (v2.6.30-rc1..v2.6.30-final), and there were
only 5 linux-next originated patches, most of them build failures.
I did this by looking at all occurances of 'next', in all commit
logs:
git log --grep=next -i v2.6.30-rc1..v2.6.30
and then manually checking the context of all 'next' matches and
counting the linux-next related commits.
So lets be generous and say that because some people dont put the
bug report originator into the changelog it was four times as many,
20 - but that's still dwarved by the sheer amount of post-rc1
changes: thousands of changes and hundreds of regressions.
linux-next is mostly useful (to me at least) not for the
cross-builds it does, but in terms of mapping out upcoming conflicts
- which also drives early detection of problematic patches and
problematic conflicts.
Ingo
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-06-12 13:29 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <1244812224.7172.146.camel@pasglop>
On Fri, 2009-06-12 at 23:10 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> To some extent, here, the issue is on Linus side and it's up to him (Hey
> Linus ! still listening ?) to maybe be more proactive at giving an ack
> or nack so that we can get a chance to do that final pass of ironing out
> the mechanical bugs before we hit the main tree.
Let me add a little bit more background to my reasoning here and why I
think having this integration testing step is so valuable...
It all boils down to bisection and having a bisectable tree.
Yes, I hate bisecting and I'm sure you are the same. It's a major PITA
and in most cases, I'm better off tracking down the actual bug and then
finding how it came into being.
However, what the ability to have a reasonably bisectable tree buys us
is all those users, testers, good wills, etc... people who do not have
the knowledge, skill, familiarity with the code etc... to track the bug
down, to be able to still find out what precise patch brought that pesky
regression that doesn't happen on anybody else machine, and thus brings
us some useful material to work with when we cannot reproduce the exact
same setup on our own machines.
Yes, I and I'm sure you can deal with a bisection breakage caused by a
minor screweup like the one we are talking about. But our testers often
can't and will just give up.
It has -nothing- to do with whether the patches are controversial or
not, it is purely about trying to make sure that things going into linus
tree had at least a few days of churning by the various involved parties
to try to get closer to the graal of a fully bisectable tree.
At least that's how I see it.
Now, we may disagree and I'm happy to discuss that more around a beer at
next KS, and to some extent, what is done is done, and if we screwed up
with -next vs. perfmon, then so be it and let's learn from our mistakes,
but I believe it makes a lot of sense to have that staging area that
helps us making sure that within a merge window with gazillion things
being merged pretty much at once, we keep this ability for our users and
testers to track down which individual patch broke something.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/6] rapidio: add common mapping APIs for RapidIO memory access
From: Li Yang @ 2009-06-12 13:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: Zhang Wei, netdev, linux-kernel, davem, linuxppc-dev, akpm
In-Reply-To: <5D8775BD-9973-4DE8-B442-91FB15F86ACC@kernel.crashing.org>
On Thu, Jun 11, 2009 at 9:32 PM, Kumar Gala<galak@kernel.crashing.org> wrot=
e:
>
> On Jun 11, 2009, at 4:47 AM, Li Yang-R58472 wrote:
>
>>> On May 12, 2009, at 3:35 AM, Li Yang wrote:
>>>
>>>> Add the mapping functions used to support direct IO memory access of
>>>> rapidIO.
>>>>
>>>> Signed-off-by: Zhang Wei <zw@zh-kernel.org>
>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>
>>> Use inbnd/outbnd instead of inb/outb which make one think of
>>> byte level io accessors.
>>>
>>> As I look at this I don't think this is the correct API. =C2=A0I
>>> think we should be using the DMA mapping API to hide these
>>> details. =C2=A0The concept of mapping like this seems to be more a
>>> function of FSL's Address translation/mapping unit (ATMU) than
>>> anything specific to the RIO bus standard.
>>
>> This is a separate RIO block level ATMU. =C2=A0Although it looks like th=
e
>> system level ATMU, system ATMU doesn't have the knowledge of rapidIO
>> target device ID. =C2=A0The mapping need to be dynamic, as it's easy to =
have
>> more RIO devices than the outbound windows.
>
> I understand that. =C2=A0What I'm saying is the RIO block level ATMU is a
> Freescale specific detail and not part of any standard RIO bus programmin=
g
> model. =C2=A0We have mapping APIs that we can connect to for this via the=
DMA API
> layer.
Ok, I see your point now. Do you mean dma_map_*() for DMA API layer?
But in my understanding the current dma_map_*() APIs are preparing
local memory for device to access which is similar to the inbound
case. Is it suitable to also use them for mapping device's space for
CPU access? Can you give an example of using this API for Address
Translation and Mapping purpose?
- Leo
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-06-12 13:10 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <20090612125335.GH31845@elte.hu>
On Fri, 2009-06-12 at 14:53 +0200, Ingo Molnar wrote:
> * Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> linux-next has integration testing so that interactions between
> maintainer trees are mapped and that architectures that otherwise
> few people use get build-tested too (well beyond their practical
> relevance, i have to add) - but there's little critical review done
> in linux-next. Nor should it be the forum for that, it simply
> contains way too much stuff and has a weird history format with
> daily rebases that makes review hard and expensive in that form.
I think you are mixing several issues. One is integration testing, one
is the problem of remote architecture of subsystems testing...
> linux-next should not be second-guessing maintainers and should not
> act as an "approval forum" for controversial features, increasing
> the (already quite substantial) pressure on maintainers to apply
> more crap.
I agree here. That's not the point. The idea is that for things that
-are- approved by their respective maintainers, to get some integration
testing and ironing of those mechanical bugs so that by the time they
hit mainstream, they don't break bisection among others.
Yes, next is -not- the place to debate controversial features. That's
not, I believe, why it was initiated (I may be wrong, Stephen will
correct me if I am), but the way I see things is that stuff that is
meant to be merged gets a chance to get some of that integration testing
against all the other stuff that is also meant to be merged to limit the
amount of clash and problems once we hit Linus tree.
> And that is true even if it's a new feature that i happen to support
> - as in this case - it sure would have been handy to have more
> perfcounters test coverage, every little bit of extra testing helps.
That doesn't invalidate my point. We are not talking about whether
perfcounters is worth merging or not, testing more or not, but strictly,
imho, about getting a chance (a couple of days at least) to do that
integration testing and catch the simple issues like the one that
triggered my initial rant -before- they hit mainline.
To some extent, here, the issue is on Linus side and it's up to him (Hey
Linus ! still listening ?) to maybe be more proactive at giving an ack
or nack so that we can get a chance to do that final pass of ironing out
the mechanical bugs before we hit the main tree.
Cheers,
Ben.
> If linux-next wants to do that then it should be renamed to
> something else and not called linux-next.
>
> Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-06-12 12:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <1244799197.7172.106.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > Ah - thanks. The bug was caused by me being a bit too optimistic
> > in applying the shiny-new Power7 support patches on the last
> > day. (nice CPU btw.)
>
> In that case paulus tells me it's actually Peter screwing up
> moving something from the powerpc code to generic :-)
Yes, but i committed it and it's my task to make sure that the thing
works as a whole so it's my fault still :)
> .../...
>
> > Such bugs happen, and they are easy enough to fix. What matters
> > arent the 1-2 short-lived bugs that do happen when a new
> > combination of trees is created, but the long-lived combination
> > bugs and conflicts.
>
> I'm not saying -next would fix world hunger ... but in this case
> we have two sets of issues, perfctr and the init ordering change
> which both got merged totally bypassing -next... We should at
> least -try- to follow the process we've defined, don't you think ?
You are trying to define a process that does not exist in that form
and which never existed in that form.
It was never true that new code _MUST_ go via linux-next - and i
hope it will never be true.
linux-next has integration testing so that interactions between
maintainer trees are mapped and that architectures that otherwise
few people use get build-tested too (well beyond their practical
relevance, i have to add) - but there's little critical review done
in linux-next. Nor should it be the forum for that, it simply
contains way too much stuff and has a weird history format with
daily rebases that makes review hard and expensive in that form.
linux-next should not be second-guessing maintainers and should not
act as an "approval forum" for controversial features, increasing
the (already quite substantial) pressure on maintainers to apply
more crap.
And that is true even if it's a new feature that i happen to support
- as in this case - it sure would have been handy to have more
perfcounters test coverage, every little bit of extra testing helps.
If linux-next wants to do that then it should be renamed to
something else and not called linux-next.
Ingo
^ permalink raw reply
* [PATCH RFC] powerpc: Implement atomic64_t for 32-bit processors
From: Paul Mackerras @ 2009-06-12 12:02 UTC (permalink / raw)
To: benh, linuxppc-dev
32-bit powerpc processors have no 64-bit atomic instructions, but we wi=
ll
need atomic64_t in order to support the perf_counter subsystem on 32-bi=
t
processors.
This adds an implementation of 64-bit atomic operations using hashed
spinlocks to provide atomicity. For each atomic operation, the address=
of the atomic64_t variable is hashed to an index into an array of 16
spinlocks. That spinlock is taken (with interrupts disabled) around th=
e
operation, which can then be coded non-atomically within the lock.
On UP, all the spinlock manipulation goes away and we simply disable
interrupts around each operation. In fact gcc eliminates the whole
atomic64_lock variable as well.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
Compile-tested only at this stage, which is why it's [RFC].
arch/powerpc/include/asm/atomic.h | 29 ++++++
arch/powerpc/lib/Makefile | 2 +-
arch/powerpc/lib/atomic64_32.c | 173 +++++++++++++++++++++++++++++=
++++++++
3 files changed, 203 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/lib/atomic64_32.c
diff --git a/arch/powerpc/include/asm/atomic.h b/arch/powerpc/include/a=
sm/atomic.h
index b401950..45356d6 100644
--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -470,6 +470,35 @@ static __inline__ int atomic64_add_unless(atomic64=
_t *v, long a, long u)
=20
#define atomic64_inc_not_zero(v) atomic64_add_unless((v), 1, 0)
=20
+#else /* not __powerpc64__ */
+
+typedef struct {
+=09long long counter;
+} atomic64_t;
+
+#define ATOMIC64_INIT(i)=09{ (i) }
+
+extern long long atomic64_read(const atomic64_t *v);
+extern void atomic64_set(atomic64_t *v, long long i);
+extern void atomic64_add(long long a, atomic64_t *v);
+extern long long atomic64_add_return(long long a, atomic64_t *v);
+extern void atomic64_sub(long long a, atomic64_t *v);
+extern long long atomic64_sub_return(long long a, atomic64_t *v);
+extern long long atomic64_dec_if_positive(atomic64_t *v);
+extern long long atomic64_cmpxchg(atomic64_t *v, long long o, long lon=
g n);
+extern long long atomic64_xchg(atomic64_t *v, long long new);
+extern int atomic64_add_unless(atomic64_t *v, long long a, long long u=
);
+
+#define atomic64_add_negative(a, v)=09(atomic64_add_return((a), (v)) <=
0)
+#define atomic64_inc(v)=09=09=09(atomic64_add(1LL, (v))
+#define atomic64_inc_return(v)=09=09(atomic64_add_return(1LL, (v))
+#define atomic64_inc_and_test(v) =09(atomic64_inc_return(v) =3D=3D 0)
+#define atomic64_sub_and_test(a, v)=09(atomic64_sub_return((a), (v)) =3D=
=3D 0)
+#define atomic64_dec(v)=09=09=09(atomic64_sub(1LL, (v))
+#define atomic64_dec_return(v)=09=09(atomic64_sub_return(1LL, (v))
+#define atomic64_dec_and_test(v)=09(atomic64_dec_return((v)) =3D=3D 0)=
+#define atomic64_inc_not_zero(v) =09atomic64_add_unless((v), 1, 0)
+
#endif /* __powerpc64__ */
=20
#include <asm-generic/atomic.h>
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 29b742b..1537f13 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -11,7 +11,7 @@ CFLAGS_REMOVE_feature-fixups.o =3D -pg
=20
obj-y=09=09=09:=3D string.o alloc.o \
=09=09=09 checksum_$(CONFIG_WORD_SIZE).o
-obj-$(CONFIG_PPC32)=09+=3D div64.o copy_32.o crtsavres.o
+obj-$(CONFIG_PPC32)=09+=3D div64.o copy_32.o crtsavres.o atomic64_32.o=
obj-$(CONFIG_HAS_IOMEM)=09+=3D devres.o
=20
obj-$(CONFIG_PPC64)=09+=3D copypage_64.o copyuser_64.o \
diff --git a/arch/powerpc/lib/atomic64_32.c b/arch/powerpc/lib/atomic64=
_32.c
new file mode 100644
index 0000000..4c24b8a
--- /dev/null
+++ b/arch/powerpc/lib/atomic64_32.c
@@ -0,0 +1,173 @@
+/*
+ * Implementation of 64-bit atomics on 32-bit PowerPC processors.
+ *
+ * Copyright =A9 2009 Paul Mackerras, IBM Corp. <paulus@au1.ibm.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include <linux/types.h>
+#include <linux/cache.h>
+#include <linux/spinlock.h>
+#include <linux/init.h>
+#include <asm/atomic.h>
+
+/*
+ * We use a hashed array of spinlocks to provide exclusive access
+ * to each atomic64_t variable. Since this is expected to used on
+ * systems with at most 4 processors, we use a relatively small
+ * array of 16 spinlocks.
+ */
+#define NR_LOCKS=0916
+
+/*
+ * Ensure each lock is in a separate cacheline on SMP.
+ */
+static union {
+=09spinlock_t lock;
+=09char pad[L1_CACHE_BYTES];
+} atomic64_lock[NR_LOCKS] __cacheline_aligned_in_smp;
+
+static inline spinlock_t *lock_addr(const atomic64_t *v)
+{
+=09unsigned long addr =3D (unsigned long) v;
+
+=09addr >>=3D L1_CACHE_SHIFT;
+=09addr ^=3D (addr >> 8) ^ (addr >> 16);
+=09return &atomic64_lock[addr & (NR_LOCKS - 1)].lock;
+}
+
+long long atomic64_read(const atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+void atomic64_set(atomic64_t *v, long long i)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+
+=09spin_lock_irqsave(lock, flags);
+=09v->counter =3D i;
+=09spin_unlock_irqrestore(lock, flags);
+}
+
+void atomic64_add(long long a, atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+
+=09spin_lock_irqsave(lock, flags);
+=09v->counter +=3D a;
+=09spin_unlock_irqrestore(lock, flags);
+}
+
+long long atomic64_add_return(long long a, atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter +=3D a;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+void atomic64_sub(long long a, atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+
+=09spin_lock_irqsave(lock, flags);
+=09v->counter -=3D a;
+=09spin_unlock_irqrestore(lock, flags);
+}
+
+long long atomic64_sub_return(long long a, atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter -=3D a;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+long long atomic64_dec_if_positive(atomic64_t *v)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter - 1;
+=09if (val >=3D 0)
+=09=09v->counter =3D val;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+long long atomic64_cmpxchg(atomic64_t *v, long long o, long long n)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter;
+=09if (val =3D=3D o)
+=09=09v->counter =3D n;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+long long atomic64_xchg(atomic64_t *v, long long new)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09long long val;
+
+=09spin_lock_irqsave(lock, flags);
+=09val =3D v->counter;
+=09v->counter =3D new;
+=09spin_unlock_irqrestore(lock, flags);
+=09return val;
+}
+
+int atomic64_add_unless(atomic64_t *v, long long a, long long u)
+{
+=09unsigned long flags;
+=09spinlock_t *lock =3D lock_addr(v);
+=09int ret =3D 1;
+
+=09spin_lock_irqsave(lock, flags);
+=09if (v->counter !=3D u) {
+=09=09v->counter +=3D a;
+=09=09ret =3D 0;
+=09}
+=09spin_unlock_irqrestore(lock, flags);
+=09return ret;
+}
+
+static int init_atomic64_lock(void)
+{
+=09int i;
+
+=09for (i =3D 0; i < NR_LOCKS; ++i)
+=09=09spin_lock_init(&atomic64_lock[i].lock);
+=09return 0;
+}
+
+pure_initcall(init_atomic64_lock);
--=20
1.6.0.4
^ permalink raw reply related
* [PATCH] powerpc: Add compiler memory barrier to mtmsr macro
From: Paul Mackerras @ 2009-06-12 12:00 UTC (permalink / raw)
To: benh, linuxppc-dev
On 32-bit non-Book E, local_irq_restore() turns into just mtmsr(),
which doesn't currently have a compiler memory barrier. This means
that accesses to memory inside a local_irq_save/restore section,
or a spin_lock_irqsave/spin_unlock_irqrestore section on UP, can
be reordered by the compiler to occur outside that section.
To fix this, this adds a compiler memory barrier to mtmsr for both
32-bit and 64-bit. Having a compiler memory barrier in mtmsr makes
sense because it will almost always be changing something about the
context in which memory accesses are done, so in general we don't want
memory accesses getting moved from one side of an mtmsr to the other.
With the barrier in mtmsr(), some of the explicit barriers in
hw_irq.h are now redundant, so this removes them.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/include/asm/hw_irq.h | 5 ++---
arch/powerpc/include/asm/reg.h | 4 ++--
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/hw_irq.h b/arch/powerpc/include/asm/hw_irq.h
index 20a44d0..7eada1a 100644
--- a/arch/powerpc/include/asm/hw_irq.h
+++ b/arch/powerpc/include/asm/hw_irq.h
@@ -80,7 +80,7 @@ static inline void local_irq_disable(void)
__asm__ __volatile__("wrteei 0": : :"memory");
#else
unsigned long msr;
- __asm__ __volatile__("": : :"memory");
+
msr = mfmsr();
SET_MSR_EE(msr & ~MSR_EE);
#endif
@@ -92,7 +92,7 @@ static inline void local_irq_enable(void)
__asm__ __volatile__("wrteei 1": : :"memory");
#else
unsigned long msr;
- __asm__ __volatile__("": : :"memory");
+
msr = mfmsr();
SET_MSR_EE(msr | MSR_EE);
#endif
@@ -108,7 +108,6 @@ static inline void local_irq_save_ptr(unsigned long *flags)
#else
SET_MSR_EE(msr & ~MSR_EE);
#endif
- __asm__ __volatile__("": : :"memory");
}
#define local_save_flags(flags) ((flags) = mfmsr())
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index fb359b0..a3c28e4 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -745,11 +745,11 @@
asm volatile("mfmsr %0" : "=r" (rval)); rval;})
#ifdef CONFIG_PPC64
#define __mtmsrd(v, l) asm volatile("mtmsrd %0," __stringify(l) \
- : : "r" (v))
+ : : "r" (v) : "memory")
#define mtmsrd(v) __mtmsrd((v), 0)
#define mtmsr(v) mtmsrd(v)
#else
-#define mtmsr(v) asm volatile("mtmsr %0" : : "r" (v))
+#define mtmsr(v) asm volatile("mtmsr %0" : : "r" (v) : "memory")
#endif
#define mfspr(rn) ({unsigned long rval; \
--
1.6.0.4
^ permalink raw reply related
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-06-12 9:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Peter Zijlstra, ppc-dev, linux-kernel,
linux-next, paulus, Linus
In-Reply-To: <1244768406.7172.1.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Fri, 2009-06-12 at 10:24 +1000, Stephen Rothwell wrote:
>
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Fri, 12 Jun 2009 10:14:22 +1000
> > Subject: [PATCH] perfcounters: remove powerpc definitions of perf_counter_do_pending
> >
> > Commit 925d519ab82b6dd7aca9420d809ee83819c08db2 ("perf_counter:
> > unify and fix delayed counter wakeup") added global definitions.
> >
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Ah - thanks. The bug was caused by me being a bit too optimistic in
applying the shiny-new Power7 support patches on the last day. (nice
CPU btw.)
> Linus, please apply. BTW, This is _EXACTLY_ why this should have
> been in -next for a few days before being merged :-(
Not really: for example current upstream is build-broken on x86 due
to an integration artifact via the kmemleak tree - despite it having
been in linux-next for months.
Paulus was building and booting powerpc on a daily basis and i ran
cross-builds as well.
Such bugs happen, and they are easy enough to fix. What matters
arent the 1-2 short-lived bugs that do happen when a new combination
of trees is created, but the long-lived combination bugs and
conflicts.
Ingo
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Benjamin Herrenschmidt @ 2009-06-12 9:57 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Stephen Rothwell, ppc-dev, linux-kernel, linux-next, paulus,
Ingo Molnar, Linus
In-Reply-To: <1244799786.6691.1133.camel@laptop>
On Fri, 2009-06-12 at 11:43 +0200, Peter Zijlstra wrote:
> On Fri, 2009-06-12 at 19:33 +1000, Benjamin Herrenschmidt wrote:
> > We should at least -try- to follow the
> > process we've defined, don't you think ?
>
> So you're saying -next should include whole new subsystems even though
> its not clear they will be merged?
Maybe yes. And if there's some debate as to whether it should be merged
or not, maybe Linus should make the decision, let -next carry it for a
few days to iron out those problems, and -then- merge it.
> That'll invariably create the opposite case where a tree doesn't get
> pulled and breaks bits due to its absence.
>
> -next does a great job of sorting the existing subsystem trees, but I
> don't think its Stephens job to decide if things will get merged.
No, it's not, but then, maybe Linus could play the game and -tell- us
whether he intend to merge or not at least a few days in advance :-)
> Therefore when things are in limbo (there was no definite ACK from Linus
> on perf counters) both inclusion and exclusion from -next can lead to
> trouble.
Well, Linus did ACK by merging :-) So he should have been able to give
that ack a few days in advance too..
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: origin tree build failure
From: Ingo Molnar @ 2009-06-12 9:55 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Stephen Rothwell, ppc-dev, linux-kernel, linux-next, paulus,
Linus
In-Reply-To: <1244799786.6691.1133.camel@laptop>
* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> On Fri, 2009-06-12 at 19:33 +1000, Benjamin Herrenschmidt wrote:
> > We should at least -try- to follow the
> > process we've defined, don't you think ?
>
> So you're saying -next should include whole new subsystems even
> though its not clear they will be merged?
>
> That'll invariably create the opposite case where a tree doesn't
> get pulled and breaks bits due to its absence.
>
> -next does a great job of sorting the existing subsystem trees,
> but I don't think its Stephens job to decide if things will get
> merged.
>
> Therefore when things are in limbo (there was no definite ACK from
> Linus on perf counters) both inclusion and exclusion from -next
> can lead to trouble.
Precisely. linux-next is for the uncontroversial stuff from existing
subsystems. Sometimes for features pushed by or approved by existing
subsystem maintainers. But it is not for controversial stuff - Linus
is the upstream maintainer, not Stephen.
We had a real mess with perfmon3 which was included into linux-next
in a rouge way without Cc:-ing the affected maintainers and against
the maintainers. There was a repeat incident recently as well, where
a tree was included into linux-next without the approval (and
without the Cc:) of affected maintainers. linux-next needs to be
more careful about adding trees.
All in one, we did the same with perfcounters that we expected of
perfmonv3. No double standard.
Nor is there any real issue here. The bug was my fault, it was
trivial to fix, it affects a small subset of testers and it is
already upstream, applied on the same day perfcounters were pulled.
Ingo
^ 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