* Re: [PATCH v5 1/5] powerpc/85xx: implement hardware timebase sync
From: Zhao Chenhui @ 2012-06-07 4:07 UTC (permalink / raw)
To: Scott Wood; +Cc: Matthew McClintock, linuxppc-dev, linux-kernel
In-Reply-To: <4FCFA0C8.9090800@freescale.com>
On Wed, Jun 06, 2012 at 01:26:16PM -0500, Scott Wood wrote:
> On 06/06/2012 04:31 AM, Zhao Chenhui wrote:
> > On Tue, Jun 05, 2012 at 11:07:41AM -0500, Scott Wood wrote:
> >> On 06/05/2012 04:08 AM, Zhao Chenhui wrote:
> >>> On Fri, Jun 01, 2012 at 10:40:00AM -0500, Scott Wood wrote:
> >>>> I know you say this is for dual-core chips only, but it would be nice if
> >>>> you'd write this in a way that doesn't assume that (even if the
> >>>> corenet-specific timebase freezing comes later).
> >>>
> >>> At this point, I have not thought about how to implement the cornet-specific timebase freezing.
> >>
> >> I wasn't asking you to. I was asking you to not have logic that breaks
> >> with more than 2 CPUs.
> >
> > These routines only called in the dual-core case.
>
> Come on, you know we have chips with more than two cores. Why design
> such a limitation into it, just because you're not personally interested
> in supporting anything but e500v2?
>
> Is it so hard to make it work for an arbitrary number of cores?
>
> >>> If do not set them, it may make KEXEC fail on other platforms.
> >>
> >> What platforms?
> >
> > Such as P4080, P3041, etc.
>
> So we need to wait for corenet timebase sync before we stop causing
> problems in virtualization, simulators, etc. if a kernel has kexec or
> cpu hotplug enabled (whether used or not)?
>
> Can you at least make sure we're actually in a kexec/hotplug scenario at
> runtime?
>
> Or just implement corenet timebase sync -- it's not that different.
>
> -Scott
We also work on the corenet timebase sync. Our plan is first the dual-core case,
then the case of more than 2 cores. We will submit the corenet timebase sync patch soon.
-Chenhui
^ permalink raw reply
* Re: [PATCH v5 4/5] fsl_pmc: Add API to enable device as wakeup event source
From: Li Yang @ 2012-06-07 4:10 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472,
linux-kernel@vger.kernel.org, Zhao Chenhui-B35336
In-Reply-To: <4FCFA17F.3050207@freescale.com>
On Thu, Jun 7, 2012 at 2:29 AM, Scott Wood <scottwood@freescale.com> wrote:
> On 06/05/2012 11:06 PM, Li Yang wrote:
>> On Wed, Jun 6, 2012 at 2:05 AM, Scott Wood <scottwood@freescale.com> wro=
te:
>>> You ignored "what about devices other than ethernet".
>>
>> No, I haven't. =C2=A0Other devices are so at least for now.
>
> I don't understand that last sentence. =C2=A0Other devices are what?
Probably I misunderstood your question "what about devices other than
ethernet". Did you mean how would other devices other than ethernet
know how to set it?
Other wakeup capable devices can call the API when it is up and
running. It will be the pmc driver's responsibility to find out if
that specific device can be configured as a wakeup source for the SoC.
Leo
^ permalink raw reply
* Re: [PATCH] powerpc: Optimise the 64bit optimised __clear_user
From: Michael Neuling @ 2012-06-07 6:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: michael, paulus, Anton Blanchard, olof, linuxppc-dev
In-Reply-To: <1339017602.7150.174.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Wed, 2012-06-06 at 18:40 +0200, Segher Boessenkool wrote:
> > > +err1; dcbz r0,r3
> >
> > There is no such instruction, you probably meant "dcbz 0,r3"?
>
> This reminds me... what would happen if we changed all our
>
> #define r0 0
> #define r1 1
>
> etc... to:
>
> #define r0 %r0
> #define r1 %r1
>
> ?
>
> I'm thinking it might help catch that sort of nasties (and some of them
> can be really nasty, such as inverting mfspr/mtspr arguments, or vs ori,
> etc... ). I'm sure we'd have a problem with a few macros & inline
> constructs but nothing we can't fix..
One problem with this is when we construct the instructions, like using
anything from ppc-opcode.h. eg. using PPC_POPCNTB would need to go from:
PPC_POPCNTB(r3,r3)
to:
PPC_POPCNTB(3,3)
Which is less readable IMHO.
Mikey
^ permalink raw reply
* Re: [PATCH] powerpc: Optimise the 64bit optimised __clear_user
From: Michael Ellerman @ 2012-06-07 6:07 UTC (permalink / raw)
To: Michael Neuling; +Cc: paulus, Anton Blanchard, olof, linuxppc-dev
In-Reply-To: <4725.1339049104@neuling.org>
On Thu, 2012-06-07 at 16:05 +1000, Michael Neuling wrote:
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > On Wed, 2012-06-06 at 18:40 +0200, Segher Boessenkool wrote:
> > > > +err1; dcbz r0,r3
> > >
> > > There is no such instruction, you probably meant "dcbz 0,r3"?
> >
> > This reminds me... what would happen if we changed all our
> >
> > #define r0 0
> > #define r1 1
> >
> > etc... to:
> >
> > #define r0 %r0
> > #define r1 %r1
> >
> > ?
> >
> > I'm thinking it might help catch that sort of nasties (and some of them
> > can be really nasty, such as inverting mfspr/mtspr arguments, or vs ori,
> > etc... ). I'm sure we'd have a problem with a few macros & inline
> > constructs but nothing we can't fix..
>
> One problem with this is when we construct the instructions, like using
> anything from ppc-opcode.h. eg. using PPC_POPCNTB would need to go from:
> PPC_POPCNTB(r3,r3)
> to:
> PPC_POPCNTB(3,3)
#define R(x) x
#define PPC_POPCNTB(R(3), R(3))
??
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Optimise the 64bit optimised __clear_user
From: Michael Neuling @ 2012-06-07 6:12 UTC (permalink / raw)
To: Michael Ellerman; +Cc: paulus, Anton Blanchard, olof, linuxppc-dev
In-Reply-To: <1339049235.2215.2.camel@concordia>
Michael Ellerman <michael@ellerman.id.au> wrote:
> On Thu, 2012-06-07 at 16:05 +1000, Michael Neuling wrote:
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > > On Wed, 2012-06-06 at 18:40 +0200, Segher Boessenkool wrote:
> > > > > +err1; dcbz r0,r3
> > > >
> > > > There is no such instruction, you probably meant "dcbz 0,r3"?
> > >
> > > This reminds me... what would happen if we changed all our
> > >
> > > #define r0 0
> > > #define r1 1
> > >
> > > etc... to:
> > >
> > > #define r0 %r0
> > > #define r1 %r1
> > >
> > > ?
> > >
> > > I'm thinking it might help catch that sort of nasties (and some of them
> > > can be really nasty, such as inverting mfspr/mtspr arguments, or vs ori,
> > > etc... ). I'm sure we'd have a problem with a few macros & inline
> > > constructs but nothing we can't fix..
> >
> > One problem with this is when we construct the instructions, like using
> > anything from ppc-opcode.h. eg. using PPC_POPCNTB would need to go from:
> > PPC_POPCNTB(r3,r3)
> > to:
> > PPC_POPCNTB(3,3)
>
> #define R(x) x
#define R(x) (x)
> #define PPC_POPCNTB(R(3), R(3))
Maybe, looks pretty gross but you're the maintainer! :-)
Mikey
^ permalink raw reply
* Re: [PATCH] powerpc: Optimise the 64bit optimised __clear_user
From: Michael Ellerman @ 2012-06-07 6:18 UTC (permalink / raw)
To: Michael Neuling; +Cc: paulus, Anton Blanchard, olof, linuxppc-dev
In-Reply-To: <5626.1339049529@neuling.org>
On Thu, 2012-06-07 at 16:12 +1000, Michael Neuling wrote:
> Michael Ellerman <michael@ellerman.id.au> wrote:
>
> > On Thu, 2012-06-07 at 16:05 +1000, Michael Neuling wrote:
> > > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > >
> > > > On Wed, 2012-06-06 at 18:40 +0200, Segher Boessenkool wrote:
> > > > > > +err1; dcbz r0,r3
> > > > >
> > > > > There is no such instruction, you probably meant "dcbz 0,r3"?
> > > >
> > > > This reminds me... what would happen if we changed all our
> > > >
> > > > #define r0 0
> > > > #define r1 1
> > > >
> > > > etc... to:
> > > >
> > > > #define r0 %r0
> > > > #define r1 %r1
> > > >
> > > > ?
> > > >
> > > > I'm thinking it might help catch that sort of nasties (and some of them
> > > > can be really nasty, such as inverting mfspr/mtspr arguments, or vs ori,
> > > > etc... ). I'm sure we'd have a problem with a few macros & inline
> > > > constructs but nothing we can't fix..
> > >
> > > One problem with this is when we construct the instructions, like using
> > > anything from ppc-opcode.h. eg. using PPC_POPCNTB would need to go from:
> > > PPC_POPCNTB(r3,r3)
> > > to:
> > > PPC_POPCNTB(3,3)
> >
> > #define R(x) x
>
> #define R(x) (x)
>
> > #define PPC_POPCNTB(R(3), R(3))
>
> Maybe, looks pretty gross but you're the maintainer! :-)
No I am not!
I agree it's fairly gross. But I'll take gross and correct over ungross
and buggy.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Optimise the 64bit optimised __clear_user
From: Benjamin Herrenschmidt @ 2012-06-07 6:39 UTC (permalink / raw)
To: Michael Neuling; +Cc: michael, paulus, Anton Blanchard, olof, linuxppc-dev
In-Reply-To: <4725.1339049104@neuling.org>
On Thu, 2012-06-07 at 16:05 +1000, Michael Neuling wrote:
> One problem with this is when we construct the instructions, like using
> anything from ppc-opcode.h. eg. using PPC_POPCNTB would need to go from:
> PPC_POPCNTB(r3,r3)
> to:
> PPC_POPCNTB(3,3)
> Which is less readable IMHO.
Yes, I know. Not much to do about this, but it might still be worth it,
how much time wasted due to mixing up or with ori in asm somewhere ?
One option would be to #define R3 (or _r3) for use in those macros so
we still have something nicer than just "3"... oh well.
Cheers,
Ben.
^ permalink raw reply
* [v2][PATCH 1/1] ppc64: fix missing to check all bits of _TIF_USER_WORK_MASK in preempt
From: Tiejun Chen @ 2012-06-07 6:56 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In entry_64.S version of ret_from_except_lite, you'll notice that
in the !preempt case, after we've checked MSR_PR we test for any
TIF flag in _TIF_USER_WORK_MASK to decide whether to go to do_work
or not. However, in the preempt case, we do a convoluted trick to
test SIGPENDING only if PR was set and always test NEED_RESCHED ...
but we forget to test any other bit of _TIF_USER_WORK_MASK !!! So
that means that with preempt, we completely fail to test for things
like single step, syscall tracing, etc...
This should be fixed as the following path:
- Test PR. If not set, go to resume_kernel, else continue.
- If go resume_kernel, to do that original do_work.
- If else, then always test for _TIF_USER_WORK_MASK to decide to do
that original user_work, else restore directly.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
v2:
* reorganize the original do_work/user_work
arch/powerpc/kernel/entry_64.S | 97 ++++++++++++++++-----------------------
1 files changed, 40 insertions(+), 57 deletions(-)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index ed1718f..5971c85 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -558,27 +558,54 @@ _GLOBAL(ret_from_except_lite)
mtmsrd r10,1 /* Update machine state */
#endif /* CONFIG_PPC_BOOK3E */
-#ifdef CONFIG_PREEMPT
clrrdi r9,r1,THREAD_SHIFT /* current_thread_info() */
- li r0,_TIF_NEED_RESCHED /* bits to check */
ld r3,_MSR(r1)
ld r4,TI_FLAGS(r9)
- /* Move MSR_PR bit in r3 to _TIF_SIGPENDING position in r0 */
- rlwimi r0,r3,32+TIF_SIGPENDING-MSR_PR_LG,_TIF_SIGPENDING
- and. r0,r4,r0 /* check NEED_RESCHED and maybe SIGPENDING */
- bne do_work
-
-#else /* !CONFIG_PREEMPT */
- ld r3,_MSR(r1) /* Returning to user mode? */
andi. r3,r3,MSR_PR
- beq restore /* if not, just restore regs and return */
+ beq resume_kernel
/* Check current_thread_info()->flags */
+ andi. r0,r4,_TIF_USER_WORK_MASK
+ beq restore
+
+ andi. r0,r4,_TIF_NEED_RESCHED
+ beq 1f
+ bl .restore_interrupts
+ bl .schedule
+ b .ret_from_except_lite
+
+1: bl .save_nvgprs
+ bl .restore_interrupts
+ addi r3,r1,STACK_FRAME_OVERHEAD
+ bl .do_notify_resume
+ b .ret_from_except
+
+resume_kernel:
+#ifdef CONFIG_PREEMPT
+ /* Check if we need to preempt */
+ andi. r0,r4,_TIF_NEED_RESCHED
+ beq+ restore
+ /* Check that preempt_count() == 0 and interrupts are enabled */
+ lwz r8,TI_PREEMPT(r9)
+ cmpwi cr1,r8,0
+ ld r0,SOFTE(r1)
+ cmpdi r0,0
+ crandc eq,cr1*4+eq,eq
+ bne restore
+
+ /*
+ * Here we are preempting the current task. We want to make
+ * sure we are soft-disabled first
+ */
+ SOFT_DISABLE_INTS(r3,r4)
+1: bl .preempt_schedule_irq
+
+ /* Re-test flags and eventually loop */
clrrdi r9,r1,THREAD_SHIFT
ld r4,TI_FLAGS(r9)
- andi. r0,r4,_TIF_USER_WORK_MASK
- bne do_work
-#endif /* !CONFIG_PREEMPT */
+ andi. r0,r4,_TIF_NEED_RESCHED
+ bne 1b
+#endif /* CONFIG_PREEMPT */
.globl fast_exc_return_irq
fast_exc_return_irq:
@@ -759,50 +786,6 @@ restore_check_irq_replay:
#endif /* CONFIG_PPC_BOOK3E */
1: b .ret_from_except /* What else to do here ? */
-
-
-3:
-do_work:
-#ifdef CONFIG_PREEMPT
- andi. r0,r3,MSR_PR /* Returning to user mode? */
- bne user_work
- /* Check that preempt_count() == 0 and interrupts are enabled */
- lwz r8,TI_PREEMPT(r9)
- cmpwi cr1,r8,0
- ld r0,SOFTE(r1)
- cmpdi r0,0
- crandc eq,cr1*4+eq,eq
- bne restore
-
- /*
- * Here we are preempting the current task. We want to make
- * sure we are soft-disabled first
- */
- SOFT_DISABLE_INTS(r3,r4)
-1: bl .preempt_schedule_irq
-
- /* Re-test flags and eventually loop */
- clrrdi r9,r1,THREAD_SHIFT
- ld r4,TI_FLAGS(r9)
- andi. r0,r4,_TIF_NEED_RESCHED
- bne 1b
- b restore
-
-user_work:
-#endif /* CONFIG_PREEMPT */
-
- andi. r0,r4,_TIF_NEED_RESCHED
- beq 1f
- bl .restore_interrupts
- bl .schedule
- b .ret_from_except_lite
-
-1: bl .save_nvgprs
- bl .restore_interrupts
- addi r3,r1,STACK_FRAME_OVERHEAD
- bl .do_notify_resume
- b .ret_from_except
-
unrecov_restore:
addi r3,r1,STACK_FRAME_OVERHEAD
bl .unrecoverable_exception
--
1.5.6
^ permalink raw reply related
* RE: [PATCH] powerpc: Optimise the 64bit optimised __clear_user
From: David Laight @ 2012-06-07 8:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Michael Neuling
Cc: michael, olof, linuxppc-dev, paulus, Anton Blanchard
In-Reply-To: <1339051173.24838.10.camel@pasglop>
=20
> -----Original Message-----
> From: Linuxppc-dev=20
> [mailto:linuxppc-dev-bounces+david.laight=3Daculab.com@lists.ozl
abs.org] On Behalf Of Benjamin Herrenschmidt
> Sent: 07 June 2012 07:40
> To: Michael Neuling
> Cc: michael@ellerman.id.au; paulus@samba.org; Anton=20
> Blanchard; olof@lixom.net; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH] powerpc: Optimise the 64bit optimised=20
> __clear_user
>=20
> On Thu, 2012-06-07 at 16:05 +1000, Michael Neuling wrote:
>=20
> > One problem with this is when we construct the=20
> instructions, like using
> > anything from ppc-opcode.h. eg. using PPC_POPCNTB would=20
> need to go from:
> > PPC_POPCNTB(r3,r3)=20
> > to:
> > PPC_POPCNTB(3,3)=20
> > Which is less readable IMHO.
>=20
> Yes, I know. Not much to do about this, but it might still be=20
> worth it,
> how much time wasted due to mixing up or with ori in asm somewhere ?
>=20
> One option would be to #define R3 (or _r3) for use in those macros so
> we still have something nicer than just "3"... oh well.
You then need to catch all the other bugs where a register
is being used instead of a constant.
Time to make the assembler require %r0 (etc)
David
^ permalink raw reply
* Re: [PATCH] PPC: PCI: Fix pcibios_io_space_offset() so it works for 32-bit ptr/64-bit rsrcs
From: Benjamin Herrenschmidt @ 2012-06-07 9:30 UTC (permalink / raw)
To: Ben Collins; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <16AB27C3-8709-4A7C-AFFE-42A0B658AC1D@servergy.com>
On Wed, 2012-06-06 at 19:35 -0400, Ben Collins wrote:
>
> pci_bus 0000:00: root bus resource [io 0xffbed000-0xffbfcfff] (bus
> address [0x100000000-0x10000ffff])
>
> Without the fix that I sent, it ends up looking like:
>
> pci_bus 0000:00: root bus resource [io 0xffbed000-0xffbfcfff] (bus
> address [0x0000-0xffff])
>
> And that's when some devices fail to be assigned valid bar 0's and the
> kernel complains because of it.
Note that oddly, the second range of bus addresses looks -more- correct
than the first one...
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2 0/2] Add pcibios_device_change_notifier
From: Hiroo Matsumoto @ 2012-06-07 12:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Bjorn Helgaas, linux-pci, linuxppc-dev, jbarnes, Kenji Kaneshige
In-Reply-To: <1338960416.7150.160.camel@pasglop>
I apologize for my late reply.
> On Wed, 2012-05-23 at 11:33 +0900, Hiroo Matsumoto wrote:
>> This patchset is for PCI hotplug.
>>
>>
>> pcibios_setup_bus_devices which sets DMA and IRQs of PCI device is called
>> only when boot. DMA setting in probe for PCI driver, like dma_set_mask,
>> does not work on powerpc platform. So it is need to set DMA and IRQs of
>> PCI device when hotplug.
>>
>> 1. Moving pcibios_setup_bus_devices code to pcibios_device_change_notifier
>> which is registered to bus notifier in pcibios_init.
>> 2. Removing caller and callee of pcibios_setup_bus_devices bus notifier
>> works instead of pcibios_setup_bus_devices.
>> 3. Using this bus notifier for microblaze because microblaze/PCI is similer
>> with powerpc/PCI.
>
> This makes me a bit nervous (that doesn't mean it's not right, but
> we need some careful auditing & testing here, which I won't be
> able to do until I'm back from leave). Mostly due to the change in when
> we do the work.
>
> pcibios_fixup_bus() used to be called early on in the initial scan pass.
>
> Your code causes the code to be called -much- later when registering the
> device with the device model. Are we 100% certain nothing will happen in
> between that might rely on the stuff being setup already ? It might well
> be ok, but I want us to triple check that.
>
> Now, if we are ok to do the setup that late (basically right before the
> driver probe() routine gets called), would it make sense to simplify
> things even further ... and do it from pcibios_enable_device() ? Thus
> avoiding the notifier business completely or is that pushing it too
> far ?
>
As you said, there are times between pcibios_fixup_bus and device_add.
I'm agree with you.
But it is difficult for me to verify these by myself.
Can I ask for your help?
I will wait that you are back from leave.
> Also you seem to add:
>
> + /* Setup OF node pointer in the device */
> + dev->dev.of_node = pci_device_to_OF_node(dev);
>
> This shouldn't be needed anymore, the device node should be setup by the
> core nowadays. Is this just a remnant of you rebasing an old patch or do
> you have a good reason to add this statement ?
No, I don't have a good reason to add this statement.
I just tried to make this code be same with pcibios_setup_bus_devices.
Thanks for your review and comment.
>
> Cheers,
> Ben.
>
>
>
>
Regards.
Hiroo MATSUMOTO
^ permalink raw reply
* Re: [PATCH v3 1/2] powerpc/PCI: move DMA & IRQ init to device_add() notification path
From: Hiroo Matsumoto @ 2012-06-07 12:58 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Michal Simek, microblaze-uclinux, Kenji Kaneshige, Jesse Larrew,
jbarnes, Dominik Brodowski, linux-pci, linuxppc-dev
In-Reply-To: <CAErSpo6W28r4f5pJmZr=ofUAaffiUtOqgXWeabGpr+DmKw+Z+g@mail.gmail.com>
Thanks for your rapid modification about function name and comments.
As Ben said, I want to check that my patch does not cause problems.
I have no complain about my patch being in 3.6 branch (or lately).
I appreciate your time and effort.
Regards.
Hiroo MATSUMOTO
> On Thu, May 24, 2012 at 9:00 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>> On Wed, 2012-05-23 at 16:37 -0600, Bjorn Helgaas wrote:
>>> From: Hiroo Matsumoto <matsumoto.hiroo@jp.fujitsu.com>
>>>
>>> PowerPC initialized DMA and IRQ information in the pci_scan_child_bus()
>>> -> pcibios_fixup_bus() path. Some hotplug drivers use that path, but
>>> others don't, e.g., pciehp, so sometimes hot-added devices are only
>>> partly initialized.
>>>
>>> This patch moves that initialization from pcibios_fixup_bus() to a new
>>> pci_bus_notify() called in the pci_bus_add_device() -> device_add() path.
>>> That means the initialization happens the same way for all PCI devices,
>>> whether they are present at boot or hot-added later.
>>>
>>> Note that powerpc was the only user of pci_fixup_cardbus(), which was
>>> used to do this same setup for cardbus devices. That's no longer
>>> needed because this setup will now be done in the same device_add()
>>> notification path as all other PCI devices.
>> Hrm. That will require a good deal of testing... Unfortunately I'm out
>> for a few weeks getting some surgery and then recovering...
>>
>> Our PCI code has ancient roots and I wouldn't be surprised if that
>> change breaks subtle assumptions made here or there, we'd need to test
>> at least on a good range of macs and ibm hotplug stuff.
>
> OK. Are you worried about cardbus in particular?
>
> This is headed for the 3.6, not 3.5, so we should have plenty of time.
> As soon as everything for the current merge window gets merged and
> -next is ready for the next batch, I'll put this in there.
>
>>> Typical failure of a hot-added e1000e device prior to this change:
>>>
>>> # echo 1 > /sys/bus/pci/slots/1/power
>>> <snip>
>>> e1000e 0000:03:00.0: enabling device (0000 -> 0002)
>>> e1000e 0000:03:00.0: No usable DMA configuration, aborting
>>> e1000e: probe of 0000:03:00.0 failed with error -5
>>>
>>> Successful initialization after this change:
>>>
>>> # echo 1 > /sys/bus/pci/slots/1/power
>>> <snip>
>>> e1000e 0000:03:00.0: enabling device (0000 -> 0002)
>>> irq: irq 6 on host /soc@ffe00000/msi@41600 mapped to virtual irq 27
>>> e1000e 0000:03:00.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:15:17:bf:c0:c9
>>> e1000e 0000:03:00.0: eth0: Intel(R) PRO/1000 Network Connection
>>> e1000e 0000:03:00.0: eth0: MAC: 1, PHY: 4, PBA No: D50861-003
>>>
>>> [bhelgaas: changelog, notifier name, registration can be __init]
>>> CC: Dominik Brodowski <linux@dominikbrodowski.net>
>>> Signed-off-by: Hiroo MATSUMOTO <matsumoto.hiroo@jp.fujitsu.com>
>>> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>>> ---
>>> arch/powerpc/include/asm/pci.h | 2 -
>>> arch/powerpc/kernel/pci-common.c | 87 ++++++++++++++--------------
>>> arch/powerpc/kernel/pci_32.c | 2 +
>>> arch/powerpc/kernel/pci_64.c | 2 +
>>> arch/powerpc/kernel/pci_of_scan.c | 1
>>> arch/powerpc/platforms/pseries/pci_dlpar.c | 1
>>> drivers/pci/pci.c | 5 --
>>> drivers/pcmcia/cardbus.c | 3 -
>>> include/linux/pci.h | 3 -
>>> 9 files changed, 49 insertions(+), 57 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
>>> index 6653f27..d6a36a4 100644
>>> --- a/arch/powerpc/include/asm/pci.h
>>> +++ b/arch/powerpc/include/asm/pci.h
>>> @@ -183,10 +183,10 @@ extern void pci_resource_to_user(const struct pci_dev *dev, int bar,
>>> resource_size_t *start, resource_size_t *end);
>>>
>>> extern resource_size_t pcibios_io_space_offset(struct pci_controller *hose);
>>> -extern void pcibios_setup_bus_devices(struct pci_bus *bus);
>>> extern void pcibios_setup_bus_self(struct pci_bus *bus);
>>> extern void pcibios_setup_phb_io_space(struct pci_controller *hose);
>>> extern void pcibios_scan_phb(struct pci_controller *hose);
>>> +extern void pcibios_setup_bus_notifier(void);
>>>
>>> #endif /* __KERNEL__ */
>>> #endif /* __ASM_POWERPC_PCI_H */
>>> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
>>> index 7320f36..41b39ba 100644
>>> --- a/arch/powerpc/kernel/pci-common.c
>>> +++ b/arch/powerpc/kernel/pci-common.c
>>> @@ -1009,40 +1009,6 @@ void __devinit pcibios_setup_bus_self(struct pci_bus *bus)
>>> ppc_md.pci_dma_bus_setup(bus);
>>> }
>>>
>>> -void __devinit pcibios_setup_bus_devices(struct pci_bus *bus)
>>> -{
>>> - struct pci_dev *dev;
>>> -
>>> - pr_debug("PCI: Fixup bus devices %d (%s)\n",
>>> - bus->number, bus->self ? pci_name(bus->self) : "PHB");
>>> -
>>> - list_for_each_entry(dev, &bus->devices, bus_list) {
>>> - /* Cardbus can call us to add new devices to a bus, so ignore
>>> - * those who are already fully discovered
>>> - */
>>> - if (dev->is_added)
>>> - continue;
>>> -
>>> - /* Fixup NUMA node as it may not be setup yet by the generic
>>> - * code and is needed by the DMA init
>>> - */
>>> - set_dev_node(&dev->dev, pcibus_to_node(dev->bus));
>>> -
>>> - /* Hook up default DMA ops */
>>> - set_dma_ops(&dev->dev, pci_dma_ops);
>>> - set_dma_offset(&dev->dev, PCI_DRAM_OFFSET);
>>> -
>>> - /* Additional platform DMA/iommu setup */
>>> - if (ppc_md.pci_dma_dev_setup)
>>> - ppc_md.pci_dma_dev_setup(dev);
>>> -
>>> - /* Read default IRQs and fixup if necessary */
>>> - pci_read_irq_line(dev);
>>> - if (ppc_md.pci_irq_fixup)
>>> - ppc_md.pci_irq_fixup(dev);
>>> - }
>>> -}
>>> -
>>> void pcibios_set_master(struct pci_dev *dev)
>>> {
>>> /* No special bus mastering setup handling */
>>> @@ -1059,19 +1025,9 @@ void __devinit pcibios_fixup_bus(struct pci_bus *bus)
>>>
>>> /* Now fixup the bus bus */
>>> pcibios_setup_bus_self(bus);
>>> -
>>> - /* Now fixup devices on that bus */
>>> - pcibios_setup_bus_devices(bus);
>>> }
>>> EXPORT_SYMBOL(pcibios_fixup_bus);
>>>
>>> -void __devinit pci_fixup_cardbus(struct pci_bus *bus)
>>> -{
>>> - /* Now fixup devices on that bus */
>>> - pcibios_setup_bus_devices(bus);
>>> -}
>>> -
>>> -
>>> static int skip_isa_ioresource_align(struct pci_dev *dev)
>>> {
>>> if (pci_has_flag(PCI_CAN_SKIP_ISA_ALIGN) &&
>>> @@ -1685,6 +1641,49 @@ void __devinit pcibios_scan_phb(struct pci_controller *hose)
>>> }
>>> }
>>>
>>> +static int pci_bus_notify(struct notifier_block *nb, unsigned long action,
>>> + void *data)
>>> +{
>>> + struct pci_dev *dev = to_pci_dev(data);
>>> +
>>> + switch (action) {
>>> + case BUS_NOTIFY_ADD_DEVICE:
>>> + /* Setup OF node pointer in the device */
>>> + dev->dev.of_node = pci_device_to_OF_node(dev);
>>> +
>>> + /* Fixup NUMA node as it may not be setup yet by the generic
>>> + * code and is needed by the DMA init
>>> + */
>>> + set_dev_node(&dev->dev, pcibus_to_node(dev->bus));
>>> +
>>> + /* Hook up default DMA ops */
>>> + set_dma_ops(&dev->dev, pci_dma_ops);
>>> + set_dma_offset(&dev->dev, PCI_DRAM_OFFSET);
>>> +
>>> + /* Additional platform DMA/iommu setup */
>>> + if (ppc_md.pci_dma_dev_setup)
>>> + ppc_md.pci_dma_dev_setup(dev);
>>> +
>>> + /* Read default IRQs and fixup if necessary */
>>> + pci_read_irq_line(dev);
>>> + if (ppc_md.pci_irq_fixup)
>>> + ppc_md.pci_irq_fixup(dev);
>>> +
>>> + break;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static struct notifier_block device_nb = {
>>> + .notifier_call = pci_bus_notify,
>>> +};
>>> +
>>> +void __init pcibios_setup_bus_notifier(void)
>>> +{
>>> + bus_register_notifier(&pci_bus_type, &device_nb);
>>> +}
>>> +
>>> static void fixup_hide_host_resource_fsl(struct pci_dev *dev)
>>> {
>>> int i, class = dev->class >> 8;
>>> diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
>>> index 4b06ec5..640cc35 100644
>>> --- a/arch/powerpc/kernel/pci_32.c
>>> +++ b/arch/powerpc/kernel/pci_32.c
>>> @@ -231,6 +231,8 @@ static int __init pcibios_init(void)
>>>
>>> printk(KERN_INFO "PCI: Probing PCI hardware\n");
>>>
>>> + pcibios_setup_bus_notifier();
>>> +
>>> if (pci_has_flag(PCI_REASSIGN_ALL_BUS))
>>> pci_assign_all_buses = 1;
>>>
>>> diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
>>> index 4ff190f..8b212d3 100644
>>> --- a/arch/powerpc/kernel/pci_64.c
>>> +++ b/arch/powerpc/kernel/pci_64.c
>>> @@ -48,6 +48,8 @@ static int __init pcibios_init(void)
>>>
>>> printk(KERN_INFO "PCI: Probing PCI hardware\n");
>>>
>>> + pcibios_setup_bus_notifier();
>>> +
>>> /* For now, override phys_mem_access_prot. If we need it,g
>>> * later, we may move that initialization to each ppc_md
>>> */
>>> diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
>>> index ae5ea5e..eb09eca 100644
>>> --- a/arch/powerpc/kernel/pci_of_scan.c
>>> +++ b/arch/powerpc/kernel/pci_of_scan.c
>>> @@ -333,7 +333,6 @@ static void __devinit __of_scan_bus(struct device_node *node,
>>> */
>>> if (!rescan_existing)
>>> pcibios_setup_bus_self(bus);
>>> - pcibios_setup_bus_devices(bus);
>>>
>>> /* Now scan child busses */
>>> list_for_each_entry(dev, &bus->devices, bus_list) {
>>> diff --git a/arch/powerpc/platforms/pseries/pci_dlpar.c b/arch/powerpc/platforms/pseries/pci_dlpar.c
>>> index 3ccebc8..0b1b6b3 100644
>>> --- a/arch/powerpc/platforms/pseries/pci_dlpar.c
>>> +++ b/arch/powerpc/platforms/pseries/pci_dlpar.c
>>> @@ -120,7 +120,6 @@ void pcibios_add_pci_devices(struct pci_bus * bus)
>>> num = pci_scan_slot(bus, PCI_DEVFN(slotno, 0));
>>> if (!num)
>>> return;
>>> - pcibios_setup_bus_devices(bus);
>>> max = bus->busn_res.start;
>>> for (pass=0; pass < 2; pass++)
>>> list_for_each_entry(dev, &bus->devices, bus_list) {
>>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>>> index 15d442a..43e0a4f 100644
>>> --- a/drivers/pci/pci.c
>>> +++ b/drivers/pci/pci.c
>>> @@ -3789,11 +3789,6 @@ int __attribute__ ((weak)) pci_ext_cfg_avail(struct pci_dev *dev)
>>> return 1;
>>> }
>>>
>>> -void __weak pci_fixup_cardbus(struct pci_bus *bus)
>>> -{
>>> -}
>>> -EXPORT_SYMBOL(pci_fixup_cardbus);
>>> -
>>> static int __init pci_setup(char *str)
>>> {
>>> while (str) {
>>> diff --git a/drivers/pcmcia/cardbus.c b/drivers/pcmcia/cardbus.c
>>> index 24caeaf..a980691 100644
>>> --- a/drivers/pcmcia/cardbus.c
>>> +++ b/drivers/pcmcia/cardbus.c
>>> @@ -71,7 +71,6 @@ int __ref cb_alloc(struct pcmcia_socket *s)
>>> unsigned int max, pass;
>>>
>>> s->functions = pci_scan_slot(bus, PCI_DEVFN(0, 0));
>>> - pci_fixup_cardbus(bus);
>>>
>>> max = bus->busn_res.start;
>>> for (pass = 0; pass < 2; pass++)
>>> @@ -85,7 +84,6 @@ int __ref cb_alloc(struct pcmcia_socket *s)
>>> */
>>> pci_bus_size_bridges(bus);
>>> pci_bus_assign_resources(bus);
>>> - cardbus_config_irq_and_cls(bus, s->pci_irq);
>>>
>>> /* socket specific tune function */
>>> if (s->tune_bridge)
>>> @@ -93,6 +91,7 @@ int __ref cb_alloc(struct pcmcia_socket *s)
>>>
>>> pci_enable_bridges(bus);
>>> pci_bus_add_devices(bus);
>>> + cardbus_config_irq_and_cls(bus, s->pci_irq);
>>>
>>> return 0;
>>> }
>>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>>> index a0e2d7f..3924c02 100644
>>> --- a/include/linux/pci.h
>>> +++ b/include/linux/pci.h
>>> @@ -651,9 +651,6 @@ resource_size_t pcibios_align_resource(void *, const struct resource *,
>>> resource_size_t);
>>> void pcibios_update_irq(struct pci_dev *, int irq);
>>>
>>> -/* Weak but can be overriden by arch */
>>> -void pci_fixup_cardbus(struct pci_bus *);
>>> -
>>> /* Generic PCI functions used internally */
>>>
>>> void pcibios_resource_to_bus(struct pci_dev *dev, struct pci_bus_region *region,
>>
>
>
^ permalink raw reply
* Re: [PATCH] PPC: PCI: Fix pcibios_io_space_offset() so it works for 32-bit ptr/64-bit rsrcs
From: Ben Collins @ 2012-06-07 15:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <1339061428.24838.24.camel@pasglop>
On Jun 7, 2012, at 5:30 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2012-06-06 at 19:35 -0400, Ben Collins wrote:
>>=20
>> pci_bus 0000:00: root bus resource [io 0xffbed000-0xffbfcfff] (bus
>> address [0x100000000-0x10000ffff])
>>=20
>> Without the fix that I sent, it ends up looking like:
>>=20
>> pci_bus 0000:00: root bus resource [io 0xffbed000-0xffbfcfff] (bus
>> address [0x0000-0xffff])
>>=20
>> And that's when some devices fail to be assigned valid bar 0's and =
the
>> kernel complains because of it.
>=20
> Note that oddly, the second range of bus addresses looks -more- =
correct
> than the first one...
Except that the first one is exactly the same bus address as my bare =
metal system:
pci_bus 0000:00: root bus resource [io 0xffbeb000-0xffbfafff] (bus =
address [0x100000000-0x10000ffff])
I only have one PCIe RAID card on the bare metal system. Not surprising =
I never noticed the problem on it directly.
> Cheers,
> Ben.
>=20
>=20
--
Ben Collins
Servergy, Inc.
(757) 243-7557
CONFIDENTIALITY NOTICE: This communication contains privileged and/or =
confidential information; and should be maintained with the strictest =
confidence. It is intended solely for the use of the person or entity in =
which it is addressed. If you are not the intended recipient, you are =
STRICTLY PROHIBITED from disclosing, copying, distributing or using any =
of this information. If you received this communication in error, please =
contact the sender immediately and destroy the material in its entirety, =
whether electronic or hard copy.
^ permalink raw reply
* unable to use X-fi pci-e sounbdboard on ppc64 ydl_powerstation
From: acrux @ 2012-06-07 17:16 UTC (permalink / raw)
To: linuxppc-dev
Unable to use X-fi pci-e sounbdboard on YDL Powerstation.
here other info:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5521
tia,
--nico
^ permalink raw reply
* Re: [PATCH] powerpc: Optimise the 64bit optimised __clear_user
From: Scott Wood @ 2012-06-07 17:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: mikey, michael, Anton Blanchard, olof, linuxppc-dev
In-Reply-To: <20120607030423.GA30053@drongo>
On 06/06/2012 10:04 PM, Paul Mackerras wrote:
> On Wed, Jun 06, 2012 at 06:40:54PM +0200, Segher Boessenkool wrote:
>>> +err1; dcbz r0,r3
>>
>> There is no such instruction, you probably meant "dcbz 0,r3"?
>
> There certainly is such an instruction, though it doesn't do exactly
> what a naive reader might expect. Using 0 rather than r0 or %r0
> improves readability but makes no difference to the assembler or the
> cpu.
The assembler can't tell that you used r0 rather than 0, because that's
handled by the preprocessor, but it seems like a bug (or at least lax
error checking) that it accepts %r0 there, and that objdump decodes it
as "dcbz r0,r3" rather than "dcbz 0,r3".
It's also odd that objdump produces output containing "r3" (not %r3)
when the assembler won't directly accept it.
-Scott
^ permalink raw reply
* Re: [PATCH v2 0/2] Add pcibios_device_change_notifier
From: Benjamin Herrenschmidt @ 2012-06-07 21:31 UTC (permalink / raw)
To: Hiroo Matsumoto
Cc: Bjorn Helgaas, linux-pci, linuxppc-dev, jbarnes, Kenji Kaneshige
In-Reply-To: <4FD0A257.4070506@jp.fujitsu.com>
On Thu, 2012-06-07 at 21:45 +0900, Hiroo Matsumoto wrote:
>
> > Also you seem to add:
> >
> > + /* Setup OF node pointer in the device */
> > + dev->dev.of_node = pci_device_to_OF_node(dev);
> >
> > This shouldn't be needed anymore, the device node should be setup by the
> > core nowadays. Is this just a remnant of you rebasing an old patch or do
> > you have a good reason to add this statement ?
>
> No, I don't have a good reason to add this statement.
> I just tried to make this code be same with pcibios_setup_bus_devices.
> Thanks for your review and comment.
Unless I'm mistaken, this statement was removed from
pcibios_setup_bus_devices() recently so I'd say it's a leftover from
your patch having been originally done on top of an older kernel.
I won't be back for another week or so but I'll see if I can get things
tested in the meantime.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] PPC: PCI: Fix pcibios_io_space_offset() so it works for 32-bit ptr/64-bit rsrcs
From: Benjamin Herrenschmidt @ 2012-06-07 21:32 UTC (permalink / raw)
To: Ben Collins; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <489B8149-6E40-48B3-880F-EF8BE72E94BF@servergy.com>
On Thu, 2012-06-07 at 11:38 -0400, Ben Collins wrote:
> > Note that oddly, the second range of bus addresses looks -more-
> correct
> > than the first one...
>
> Except that the first one is exactly the same bus address as my bare
> metal system:
>
> pci_bus 0000:00: root bus resource [io 0xffbeb000-0xffbfafff] (bus
> address [0x100000000-0x10000ffff])
>
> I only have one PCIe RAID card on the bare metal system. Not
> surprising I never noticed the problem on it directly.
Can you show me the device-tree node for that PCI host bridge ?
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc: Fix sldi to take literal not register name
From: Michael Neuling @ 2012-06-07 23:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Michael Ellerman, Anton Blanchard, olof, linuxppc-dev
In-Reply-To: <1339049882.2215.10.camel@concordia>
Fix sldi to take literal not register name.
Was introduced by:
commit 19ccb76a1938ab364a412253daec64613acbf3df
Author: Paul Mackerras <paulus@samba.org>
Date: Sat Jul 23 17:42:46 2011 +1000
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
I got sick off the bike-shedding in a vacuum and started doing the
conversion. Found this as a result.
I'll post the full conversion at some point, but this fix is useful
now.
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index a84aafc..969caeb 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -810,7 +810,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
lwz r3,VCORE_NAPPING_THREADS(r5)
lwz r4,VCPU_PTID(r9)
li r0,1
- sldi r0,r0,r4
+ sldi r0,r0,4
andc. r3,r3,r0 /* no sense IPI'ing ourselves */
beq 43f
mulli r4,r4,PACA_SIZE /* get paca for thread 0 */
^ permalink raw reply related
* Re: [PATCH] powerpc: Fix sldi to take literal not register name
From: Benjamin Herrenschmidt @ 2012-06-08 0:19 UTC (permalink / raw)
To: Michael Neuling
Cc: Michael Ellerman, Paul Mackerras, Anton Blanchard, olof,
linuxppc-dev
In-Reply-To: <9666.1339113149@neuling.org>
On Fri, 2012-06-08 at 09:52 +1000, Michael Neuling wrote:
> Fix sldi to take literal not register name.
>
> Was introduced by:
> commit 19ccb76a1938ab364a412253daec64613acbf3df
> Author: Paul Mackerras <paulus@samba.org>
> Date: Sat Jul 23 17:42:46 2011 +1000
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> I got sick off the bike-shedding in a vacuum and started doing the
> conversion. Found this as a result.
>
> I'll post the full conversion at some point, but this fix is useful
> now.
Euh... except that:
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index a84aafc..969caeb 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -810,7 +810,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
> lwz r3,VCORE_NAPPING_THREADS(r5)
> lwz r4,VCPU_PTID(r9)
> li r0,1
> - sldi r0,r0,r4
> + sldi r0,r0,4
Isn't the right fix s/sldi/sld and keep r4 ?
IE. I think Paul meant to shift 1 by the TID not shift 1 by 4
Cheers,
Ben.
> andc. r3,r3,r0 /* no sense IPI'ing ourselves */
> beq 43f
> mulli r4,r4,PACA_SIZE /* get paca for thread 0 */
^ permalink raw reply
* Re: [PATCH] powerpc: Optimise the 64bit optimised __clear_user
From: Benjamin Herrenschmidt @ 2012-06-08 0:51 UTC (permalink / raw)
To: Scott Wood
Cc: mikey, michael, Paul Mackerras, Anton Blanchard, olof,
linuxppc-dev
In-Reply-To: <4FD0EA08.7040903@freescale.com>
On Thu, 2012-06-07 at 12:51 -0500, Scott Wood wrote:
>
> The assembler can't tell that you used r0 rather than 0, because
> that's
> handled by the preprocessor, but it seems like a bug (or at least lax
> error checking) that it accepts %r0 there, and that objdump decodes it
> as "dcbz r0,r3" rather than "dcbz 0,r3".
Well, this is the domain of bike shed painting :-) the syntax of the
instruction is:
dcbz RA,RB
Now, of course, like other RA,RB pairs it has the semantic that
if RA = 0 then b <- 0
else b <- (RA)
EA <- b + (RB)
If we were to be pendantic and our assembly could also enforce the use
of % for registers, I suppose it would make sense to require 0 rather
than %0 for those "RA" forms to make it absolutely clear that we are
talking about 0 and not r0 in this specific case, I agree, but in the
current shape of the asm, I don't think that's something to expect.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] Disable /dev/port interface on powerpc systems
From: Michael Ellerman @ 2012-06-08 2:00 UTC (permalink / raw)
To: Haren Myneni; +Cc: linuxppc-dev, anton
In-Reply-To: <1332577383.19329.5.camel@hbabu-laptop>
On Sat, 2012-03-24 at 01:23 -0700, Haren Myneni wrote:
> Ben, Here it is the updated patch based on your suggestions. Please let
> me know if it has any issues.
>
This breaks the i386 defconfig build with:
drivers/char/mem.c:903:3: error: implicit declaration of function
'arch_has_dev_port' [-Werror=implicit-function-declaration]
I think because that file includes <asm/io.h> directly, not via
include/linux/io.h, so your stub is never seen.
cheers
^ permalink raw reply
* Re: [PATCH 5/5] powerpc: iommu: Implement IOMMU pools to improve multiqueue adapter performance
From: Michael Ellerman @ 2012-06-08 2:43 UTC (permalink / raw)
To: Anton Blanchard; +Cc: olof, paulus, linuxppc-dev
In-Reply-To: <20120604154519.48ea1aa9@kryten>
On Mon, 2012-06-04 at 15:45 +1000, Anton Blanchard wrote:
> At the moment all queues in a multiqueue adapter will serialise
> against the IOMMU table lock. This is proving to be a big issue,
> especially with 10Gbit ethernet.
..
> +
> struct iommu_table {
> unsigned long it_busno; /* Bus number this table belongs to */
> unsigned long it_size; /* Size of iommu table in entries */
> @@ -61,10 +71,10 @@ struct iommu_table {
> unsigned long it_index; /* which iommu table this is */
> unsigned long it_type; /* type: PCI or Virtual Bus */
> unsigned long it_blocksize; /* Entries in each block (cacheline) */
> - unsigned long it_hint; /* Hint for next alloc */
> - unsigned long it_largehint; /* Hint for large allocs */
> - unsigned long it_halfpoint; /* Breaking point for small/large allocs */
> - spinlock_t it_lock; /* Protects it_map */
> + unsigned long poolsize;
> + unsigned long nr_pools;
> + struct iommu_pool large_pool;
> + struct iommu_pool pools[IOMMU_NR_POOLS];
> unsigned long *it_map; /* A simple allocation bitmap for now */
> };
>
Breaks the cell code with:
arch/powerpc/platforms/cell/iommu.c:521:15: error: 'struct iommu_table' has no member named 'it_hint'
cheers
^ permalink raw reply
* [PATCH powerpc] fix Section mismatch warnings in prom_init.c
From: Li Zhong @ 2012-06-08 3:44 UTC (permalink / raw)
To: LKML; +Cc: Paul Mackerras, PowerPC email list
This patches tries to fix a couple of Section mismatch warnings like
following one:
WARNING: arch/powerpc/kernel/built-in.o(.text+0x2923c): Section mismatch
in reference from the function .prom_query_opal() to the
function .init.text:.call_prom()
The function .prom_query_opal() references
the function __init .call_prom().
This is often because .prom_query_opal lacks a __init
annotation or the annotation of .call_prom is wrong.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/kernel/prom_init.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c
b/arch/powerpc/kernel/prom_init.c
index 1b488e5..0794a30 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -1312,7 +1312,7 @@ static struct opal_secondary_data {
extern char opal_secondary_entry;
-static void prom_query_opal(void)
+static void __init prom_query_opal(void)
{
long rc;
@@ -1436,7 +1436,7 @@ static void __init prom_opal_hold_cpus(void)
prom_debug("prom_opal_hold_cpus: end...\n");
}
-static void prom_opal_takeover(void)
+static void __init prom_opal_takeover(void)
{
struct opal_secondary_data *data = &RELOC(opal_secondary_data);
struct opal_takeover_args *args = &data->args;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 5/5] powerpc: iommu: Implement IOMMU pools to improve multiqueue adapter performance
From: Anton Blanchard @ 2012-06-08 4:02 UTC (permalink / raw)
To: Michael Ellerman; +Cc: olof, paulus, linuxppc-dev
In-Reply-To: <1339123423.3330.5.camel@concordia>
Hi,
> Breaks the cell code with:
>
> arch/powerpc/platforms/cell/iommu.c:521:15: error: 'struct
> iommu_table' has no member named 'it_hint'
Yuck, I'll spin a fix. There's no need for the code to bump the hint.
Anton
^ permalink raw reply
* Re: [PATCH 5/5] powerpc: iommu: Implement IOMMU pools to improve multiqueue adapter performance
From: Michael Ellerman @ 2012-06-08 4:03 UTC (permalink / raw)
To: Anton Blanchard; +Cc: olof, paulus, linuxppc-dev
In-Reply-To: <20120608140204.49f475e8@kryten>
Anton Blanchard <anton@samba.org> wrote:
>
>Hi,
>
>> Breaks the cell code with:
>>
>> arch/powerpc/platforms/cell/iommu.c:521:15: error: 'struct
>> iommu_table' has no member named 'it_hint'
>
>Yuck, I'll spin a fix. There's no need for the code to bump the hint.
OK, I can fix it up.
Cheers
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
^ 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