* Re: [PATCH] powerpc: add cascade support to xilinx intc controller
From: Benjamin Herrenschmidt @ 2009-08-27 4:15 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, john.linn
In-Reply-To: <20090825060848.3913.60710.stgit@localhost.localdomain>
On Tue, 2009-08-25 at 00:08 -0600, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> This patch allows the Xilinx intc interrupt controller to be cascaded
> instead of being the master irqhost. Useful when attaching an FPGA
> to an SoC that has its own interrupt controller.
Something doesn't look quite right ...
> /*
> + * Cascaded Xilinx interrupt controller
> + */
> +static void xilinx_intc_cascade(unsigned int virq, struct irq_desc *desc)
> +{
> + struct irq_host *cascade_irqhost = get_irq_data(virq);
> + void *regs = cascade_irqhost->host_data;
> + unsigned int cascade_virq;
> +
> + pr_debug("%s(virq=%i) irq_host=%p\n", __func__, virq, cascade_irqhost);
> + cascade_virq = irq_linear_revmap(cascade_irqhost,
> + in_be32(regs + XINTC_IVR));
> + if (cascade_virq)
> + generic_handle_irq(cascade_virq);
> +}
The cascade handler generally has to be part of the -host- controller or
the platform code (we should try maybe to invent a way to make that
more transparent but today it's not) because it may need to do special
things to ack the interrupt on the host controller.
For example, if I have an MPIC based setup with a cascaded xilinx FPGA,
I want to use something that does the EOI right on the MPIC. In fact,
it's -almost- like what we need to do for a cascade, is to find a way to
stick a get_irq() function pointer somewhere in the irq-desc for the
cascaded interrupt, and have in the -host- a generic cascade handler.
Also, you seem to be trying to do the revmap of the child interrupt
using the parent host.. .that doesn't make sense. Each PIC has it's own
revmap and the child PIC uses it's own revmap as well.
The rest of the code seems to entertain a similar confusion...
Cheers,
Ben.
> +/**
> + * xilinx_intc_cascade_setup - Add a xilinx intc device as a cascaded controller
> + * @cascade_node: device node for xilinx intc controller.
> + */
> +int xilinx_intc_cascade_setup(struct device_node *cascade_node)
> +{
> + struct irq_host *cascade_irqhost;
> + int cascade_virq;
> +
> + if (!cascade_node) {
> + pr_err("%s(): cannot find xilinx intc node\n", __func__);
> + return -ENODEV;
> + }
> +
> + /* Make sure this is a xilinx intc device */
> + if (!of_match_node(xilinx_intc_match, cascade_node)) {
> + pr_err("%s(): %s is not compatible\n",
> + __func__, cascade_node->name);
> + return -EINVAL;
> + }
> +
> + /* Map a VIRQ for the cascaded handler */
> + cascade_virq = irq_of_parse_and_map(cascade_node, 0);
> + if (!cascade_virq) {
> + pr_err("%s(): error mapping cascade interrupt\n", __func__);
> + return -ENODEV;
> + }
> +
> + /* Set up the irqhost and register it */
> + cascade_irqhost = xilinx_intc_init(cascade_node);
> + set_irq_data(cascade_virq, cascade_irqhost);
> + set_irq_chained_handler(cascade_virq, xilinx_intc_cascade);
> +
> + pr_debug("%s(): cascading virq %i to irq_host %p\n",
> + __func__, cascade_virq, cascade_irqhost);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(xilinx_intc_cascade_setup);
> +
> +/*
> * Initialize master Xilinx interrupt controller
> */
> void __init xilinx_intc_init_tree(void)
^ permalink raw reply
* Re: [RFC] Clock binding
From: Benjamin Herrenschmidt @ 2009-08-27 4:09 UTC (permalink / raw)
To: devicetree-discuss; +Cc: Mitch Bradley, linuxppc-dev list
In-Reply-To: <1250569288.19007.15.camel@pasglop>
On Tue, 2009-08-18 at 14:21 +1000, Benjamin Herrenschmidt wrote:
> So here's a followup to my discussion about the clock API.
Really nobody has a comment here ? :-) Not even Mitch ?
Cheers,
Ben.
> I'm cooking up a patch that replace our current primitive implementation
> in arch/powerpc/kernel/clock.c with something along the lines of what I
> described. However, I want a bit more churn here on the device-tree
> related bits.
>
> So, basically, the goal here is to define a binding so that we can link
> a device clock inputs to a clock provider clock outputs.
>
> In general, in a system, there's actually 3 "names" involved. The clock
> provider output name, the clock signal name, and the clock input name on
> the device. However, I want to avoid involving the clock signal name as
> it's a "global" name and it will just end up being a mess if we start
> exposing that.
>
> So basically, it boils down to a device having some clock inputs,
> referenced by names, that need to be linked to another node which is a
> clock provider, which has outputs, references either by number or names,
> see discussion below.
>
> First, why names, and not numbers ? IE. It's the OF "tradition" for
> resources to just be an array, like interrupts, or address ranges in
> "reg" properties, and one has to know what the Nth interrupt correspond
> too.
>
> My answer here is that maybe the tradition but it's crap :-) Names are
> much better in the long run, besides it makes it easier to represent if
> not all inputs have been wired. Also, to some extent, things like PCI do
> encode a "name" with "reg" or "assigned-addresses" properties as part of
> the config space offset in the top part of the address, and that has
> proved very useful.
>
> Thus I think using names is the way to go, and we should even generalize
> that and add a new "interrupt-names" property to name the members of an
> "interrupts" :-)
>
> So back to the subject at hand. That leaves us with having to populate
> the driver with some kind of map (I call it clock-map). Ideally, if
> everything is named, which is the best approach imho, that map would
> bind a list of:
>
> - clock input name
> - clock provider phandle
> - clock output name on provider
>
> However, it's a bit nasty to mix strings and numbers (phandles) in a
> single property. It's possible, but would likely lead to the phandle not
> being aligned and tools such as lsprop to fail miserably to display
> those properties in any kind of readable form.
>
> My earlier emails proposed an approach like this:
>
> - clock input names go into a "clock-names" property
> (which I suggest naming instead "clock-input-names" btw)
>
> - the map goes into a "clock-map" property and for each input
> provides a phandle and a one cell numerical ID that identifies
> the clock on the source.
>
> However, I really dislike that numerical clock ID. Magic numbers suck.
> It should be a string. But I don't want to add a 3rd property in there.
>
> Hence my idea below. It's not perfect but it's the less sucky i've come
> up with so far. And then we can do some small refinements.
>
> * Device has:
>
> - "clock-input-names" as above
> - "clock-map" contains list of phandle,index
>
> * Clock source has:
>
> - "clock-output-names" list of strings
>
> The "index" in the clock map thus would reference the
> "clock-output-names" array in the clock provider. That means that the
> "magic number" here is entirely local to a given device-tree, doesn't
> leak into driver code, which continues using names.
>
> In addition, we can even have some smooth "upgrade" path from existing
> "clock-frequency" properties by assuming that if "clock-output-names" is
> absent, but "clock-frequency" exist, then index 0 references a fixed
> frequency clock source without a driver. This could be generally handy
> anyway to represent crystals of fixed bus clocks without having to write
> a clock source driver for them.
>
> Any comments ?
>
> I'll post a patch, maybe later today, implementing the above (I may or
> may not have time to also convert the existing 512x code to it, we'll
> see).
>
> Cheers,
> Ben.
>
>
>
>
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
* Re: Extending virtio_console to support multiple ports
From: Benjamin Herrenschmidt @ 2009-08-27 4:07 UTC (permalink / raw)
To: Amit Shah
Cc: kvm, linuxppc-dev, linux-kernel, miltonm, qemu-devel, borntraeger,
brueckner, virtualization, alan
In-Reply-To: <20090826154552.GA31910@amit-x200.redhat.com>
On Wed, 2009-08-26 at 21:15 +0530, Amit Shah wrote:
>
> > - Convert hvc's usage of spinlocks to mutexes. I've no idea how this
> > will play out; I'm no expert here. But I did try doing this and so far
> > it all looks OK. No lockups, lockdep warnings, nothing. I have full
> > debugging enabled. But this doesn't mean it's right.
>
> So just to test this further I added the capability to have more than
> one hvc console spawn from virtio_console, created two consoles and did
> a 'cat' of a file in each of the virtio-consoles. It's been running for
> half an hour now without any badness. No spew in debug logs too.
>
> I also checked the code in hvc_console.c that takes the spin_locks.
> Nothing there that runs from (or needs to run from) interrupt context.
> So the change to mutexes does seem reasonable. Also, the spinlock code
> was added really long back -- git blame shows Linus' first git commit
> introduced them in the git history, so it's pure legacy baggage.
Two things here:
- First you seem to have completely missed the fact that hvc_poll() can
be called from interrupt time :-) Look at hvc_irq.c which is used by
some backends. Maybe that can be "fixed" by deferring to a work queue,
though it's nice to have the keyboard input have somewhat of a higher
priority than anything else here.
So unless that's fixed, or I missed something, that's a big NACK for
now.
- Then, are we certain that there's no case where the tty layer will
call us with some lock held or in an atomic context ? To be honest, I've
totally lost track of the locking rules in tty land lately so it might
well be ok, but something to verify.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Invoke kdump for system reset exception
From: Benjamin Herrenschmidt @ 2009-08-27 3:54 UTC (permalink / raw)
To: mohan; +Cc: linuxppc-dev, kamalesh
In-Reply-To: <20090824031244.GA3590@in.ibm.com>
On Mon, 2009-08-24 at 08:42 +0530, M. Mohan Kumar wrote:
> Invoke kdump for system reset exception
>
> Dump restart operation from HMC raises system reset exception
> (0x100) and xmon is invoked(even if kdump kernel is loaded). User has to
> exit from xmon by saying 'Don't recover' to invoke kdump. Modify this
> behaviour so that xmon will return immediately for system reset
> exception and kdump kernel will be invoked (if its loaded). If kdump
> kernel is not loaded, proceed with xmon
Hi Mohan !
This is not right. The way things -should- already work is that xmon
will only kick in if it's been enabled (aka initialized). This happens
normally if either:
- CONFIG_XMON_DEFAULT is set, which forces enable it at boot. This
should not be set on distro kernels
- The command line says xmon=early or xmon=on, in which case xmon will
be enabled during early boot (and in the case of xmon=early, you'll drop
into it early during boot, for example to get a chance to set some
breakpoints).
So on a normal distro kernel, where CONFIG_XMON_DEFAULT should not be
set (if it is, they need to fix it), xmon will not be initialized, and a
System Reset exception should trigger a kdump. If it doesn't, then
there's a bug elsewhere, but the fix isn't to modify xmon.
Cheers,
Ben.
> Signed-off-by: M. Mohan Kumar <mohan@in.ibm.com>
> ---
> arch/powerpc/xmon/xmon.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index e1f33a8..6847334 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -23,6 +23,7 @@
> #include <linux/interrupt.h>
> #include <linux/irq.h>
> #include <linux/bug.h>
> +#include <linux/kexec.h>
>
> #include <asm/ptrace.h>
> #include <asm/string.h>
> @@ -348,6 +349,14 @@ static int xmon_core(struct pt_regs *regs, int fromipi)
> unsigned long timeout;
> #endif
>
> + /*
> + * If the exception is 0x100 and if kexec crash image is loaded,
> + * continue with kexec_crash
> + */
> + if (kexec_should_crash(current) && kexec_crash_image &&
> + regs->trap == 0x100)
> + return 0;
> +
> local_irq_save(flags);
>
> bp = in_breakpoint_table(regs->nip, &offset);
^ permalink raw reply
* Re: [v2 PATCH 2/2]: pseries: Implement Pseries Processor Idle idle module.
From: Benjamin Herrenschmidt @ 2009-08-27 3:44 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Gautham R Shenoy, linux-kernel, Paul Mackerras, arun, Ingo Molnar,
linuxppc-dev, Balbir Singh
In-Reply-To: <1251286038.1329.1.camel@twins>
On Wed, 2009-08-26 at 13:27 +0200, Peter Zijlstra wrote:
> On Wed, 2009-08-26 at 16:40 +0530, Arun R Bharadwaj wrote:
> > +void (*pm_idle)(void);
> > +EXPORT_SYMBOL_GPL(pm_idle);
>
> Seriously.. this caused plenty problems over on x86 and you're doing the
> exact same dumb thing?
I already said I didn't want this export.
First thing first: We already have a ppc_md.power_save() callback,
filled by the platform. which implements the "low level" part of idle on
powerpc (ie, the actual putting of the CPU into some kind of wait state)
and is called by our idle loop.
We -also- have a higher level ppc_md.idle_loop() which allows the
platform to completely override the idle loop, though we rarely do it (I
think only iSeries does it nowadays).
So I see no need to -add- another callback here. I'm not entirely sure
what the cpuidle framework does, it's no obvious from Arun commit
messages I must say, but it doesn't look like the right approach for
integration. In fact, pSeries already have a choice between different
powersave models depending on what kind of hypervisor is there.
So Arun, please try to fit nicely within the existing interfaces, or if
you want to add a new one, please justify very precisely what design
decisions lead you to that.
Finally, there's also a problem with your first patch 1/2: You are
setting a Kconfig flag unconditionally indicating that the arch supports
some idle wait function, but you only implement it somewhere in
arch/powerpc/platform/pseries, so you'll break the build of any other
platform. You also prevent another platform to implement a different one
and be built in the same kernel.
For such generic callbacks, if it's justified (and only if it is), you
can add a ppc_md. hook for the platform to fill, and you need to cater
for platforms that don't.
Cheers,
Ben.
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-08-27 3:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here are a couple of last minute patches for 2.6.31. One is a regression fix
(afaik) where a PS3 driver gets incorrectly loaded on other platforms and
crashes, along with a PS3 defconfig update.
The following changes since commit f415c413f458837bd0c27086b79aca889f9435e4:
Linus Torvalds (1):
Merge git://git.kernel.org/.../davem/net-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Geert Uytterhoeven (1):
powerpc/ps3: Add missing check for PS3 to rtc-ps3 platform device registration
Geoff Levand (1):
powerpc/ps3: Update ps3_defconfig
arch/powerpc/configs/ps3_defconfig | 211 +++++++++++++-----------------------
arch/powerpc/platforms/ps3/time.c | 4 +
2 files changed, 79 insertions(+), 136 deletions(-)
^ permalink raw reply
* Re: [PATCH -v2 0/7] powerpc: use asm-generic/dma-mapping-common.h
From: Benjamin Herrenschmidt @ 2009-08-27 3:17 UTC (permalink / raw)
To: Ingo Molnar; +Cc: FUJITA Tomonori, linuxppc-dev, linux-kernel, galak
In-Reply-To: <1251342735.20467.2.camel@pasglop>
On Thu, 2009-08-27 at 13:12 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-08-13 at 10:55 +0200, Ingo Molnar wrote:
>
> > Ok! We could also stage it a bit (one or two weeks) in a separate
> > branch and allow a rebase, should you find any bugs during testing?
>
> Allright so after various delays and sidetracking on my side, the
> patches have been in my -test branch for long enough, I'm happy for them
> to go in either way now.
>
> I'm going to take them out of powerpc test for now and not put them in
> my -next right away until I'm sure I have the right source to pull, at
> which point I can just put from tip iommu.
IE. I think I was not clear :-)
I mean, I plan to pull tip/iommu into powerpc-next and then apply the
patches, but I want just your final word that this is a
"stable" (non-rebase) branch and from Fujita that the patches are still
good and haven't changed from those currently on patchwork.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH -v2 0/7] powerpc: use asm-generic/dma-mapping-common.h
From: Benjamin Herrenschmidt @ 2009-08-27 3:12 UTC (permalink / raw)
To: Ingo Molnar; +Cc: FUJITA Tomonori, linuxppc-dev, linux-kernel, galak
In-Reply-To: <20090813085505.GA10671@elte.hu>
On Thu, 2009-08-13 at 10:55 +0200, Ingo Molnar wrote:
> Ok! We could also stage it a bit (one or two weeks) in a separate
> branch and allow a rebase, should you find any bugs during testing?
Allright so after various delays and sidetracking on my side, the
patches have been in my -test branch for long enough, I'm happy for them
to go in either way now.
I'm going to take them out of powerpc test for now and not put them in
my -next right away until I'm sure I have the right source to pull, at
which point I can just put from tip iommu.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Change archdata dma_data type to dma_addr_t
From: Michael Ellerman @ 2009-08-27 0:24 UTC (permalink / raw)
To: Becky Bruce; +Cc: Christoph Hellwig, linuxppc-dev
In-Reply-To: <E3F20841-FB04-44EF-8DAA-91F51873C0A6@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1998 bytes --]
On Wed, 2009-08-26 at 15:20 -0500, Becky Bruce wrote:
> On Aug 26, 2009, at 9:08 AM, Michael Ellerman wrote:
>
> > On Wed, 2009-08-26 at 22:29 +1000, Benjamin Herrenschmidt wrote:
> >> On Mon, 2009-08-24 at 21:48 +0200, Christoph Hellwig wrote:
> >>> On Mon, Aug 24, 2009 at 11:17:14AM -0500, Becky Bruce wrote:
> >>>> Previously, this was specified as a void *, but that's not
> >>>> large enough on 32-bit systems with 36-bit physical
> >>>> addressing support. Change the type to dma_addr_t so it
> >>>> will scale based on the size of a dma address.
> >>>
> >>> This looks extreml ugly to me. It seems like the typical use is to
> >>> store a pointer to a structure. So what about making the direct
> >>> dma case follow that general scheme instead?
> >>>
> >>> E.g. declare a
> >>>
> >>> struct direct_dma_data {
> >>> dma_addr_t direct_dma_offset;
> >>> };
> >>>
> >>> and have one normal instace of it, and one per weird cell device.
> >>
> >> Right, but we want to avoid a structure for the classic case of 32-
> >> bit
> >> systems with no iommu...
> >>
> >> I wouldn't mind doing a union here.
> >
> > That might be best, the patch as it stands is a horrible mess of
> > casts.
>
> Let's be fair - the code before was a horrible mess of casts, I've
> just moved them :)
Yeah true. Though I think we end up with more casts because there were
more call sites using it as a pointer originally. But yeah it's not
pretty either way.
> > Stashing a dma_addr_t into a void * is sort of gross, but storing a
> > pointer to some struct (a void *) in a dma_addr_t is _really_ gross :)
>
> Both are revolting (and storing a dma_addr_t into a void * is really
> gross when the void * is smaller than the dma_addr_t!!). A union
> might not be a bad idea, though. I'll look at doing that instead.
Cool. That is how we're using it, sometimes it points to something
sometimes it's a dma_addr_t, so I think a union will work.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: PPC driver - generic bus width
From: Stephen Rothwell @ 2009-08-27 0:04 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, Alemao, linux-kernel
In-Reply-To: <1251296565.7492.7.camel@concordia>
[-- Attachment #1: Type: text/plain, Size: 781 bytes --]
On Thu, 27 Aug 2009 00:22:45 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
>
> > struct device_info_t {
> > void (*read)();
> > void (*write)();
These are not prototypes because there is no parameter list (use "void" for empty).
> > };
> >
> > static int __devinit device_probe()
This isn't a prototype either.
> > cc1: warnings being treated as errors
> > drivers/dev_test.c:37: warning: function declaration isn't a prototype
> > drivers/dev_test.c:38: warning: function declaration isn't a prototype
> > drivers/dev_test.c: In function 'device_probe':
> > drivers/dev_test.c:113: warning: assignment from incompatible pointer
> > type
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Change archdata dma_data type to dma_addr_t
From: Becky Bruce @ 2009-08-26 20:20 UTC (permalink / raw)
To: michael; +Cc: Christoph Hellwig, linuxppc-dev
In-Reply-To: <1251295725.7492.5.camel@concordia>
On Aug 26, 2009, at 9:08 AM, Michael Ellerman wrote:
> On Wed, 2009-08-26 at 22:29 +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2009-08-24 at 21:48 +0200, Christoph Hellwig wrote:
>>> On Mon, Aug 24, 2009 at 11:17:14AM -0500, Becky Bruce wrote:
>>>> Previously, this was specified as a void *, but that's not
>>>> large enough on 32-bit systems with 36-bit physical
>>>> addressing support. Change the type to dma_addr_t so it
>>>> will scale based on the size of a dma address.
>>>
>>> This looks extreml ugly to me. It seems like the typical use is to
>>> store a pointer to a structure. So what about making the direct
>>> dma case follow that general scheme instead?
>>>
>>> E.g. declare a
>>>
>>> struct direct_dma_data {
>>> dma_addr_t direct_dma_offset;
>>> };
>>>
>>> and have one normal instace of it, and one per weird cell device.
>>
>> Right, but we want to avoid a structure for the classic case of 32-
>> bit
>> systems with no iommu...
>>
>> I wouldn't mind doing a union here.
>
> That might be best, the patch as it stands is a horrible mess of
> casts.
Let's be fair - the code before was a horrible mess of casts, I've
just moved them :)
>
> Stashing a dma_addr_t into a void * is sort of gross, but storing a
> pointer to some struct (a void *) in a dma_addr_t is _really_ gross :)
Both are revolting (and storing a dma_addr_t into a void * is really
gross when the void * is smaller than the dma_addr_t!!). A union
might not be a bad idea, though. I'll look at doing that instead.
-Becky
^ permalink raw reply
* Re: Can't write value into memory ?(E500 V2)
From: Scott Wood @ 2009-08-26 19:20 UTC (permalink / raw)
To: wilbur.chan; +Cc: linuxppc-dev
In-Reply-To: <e997b7420908260739u49fb4b36j9eb148782829547b@mail.gmail.com>
On Wed, Aug 26, 2009 at 10:39:24PM +0800, wilbur.chan wrote:
> In an assemblely code , I invalided all the TLB entries except for
> the entry we are executed in.
>
> After that , I setuped a 1:1 TLB entry mapping of 1GB .
What is it you're trying to do?
> At last , I wrote value 30 into the physical address 0x0400,0000 (also
> the virtual address because of my 1:1 mapping).
>
> However, it seemed failed to store the value '30' at address
> 0x400,0000. The following is my code:
>
> //code start
>
> // setup a 1:1 mapping of 1GB
> ...
"..." is not code. :-)
> //store '30' into address 0x0400,0000
>
> li r23, 30
> lis r22, 0x400
> ori r22,r22,0x0
> stb r23,0(r22)
>
>
> //check if we successfully store value at 0x400,0000
>
> lis r22, 0x400
> ori r22,r22,0x0
> lwz r23,0(r22)
> cmpw r23, 30
The values should not be equal, since you wrote a byte and read back a
word.
Furthermore, you are storing the constant 30, but are comparing r23 with
the register r30 (I never liked that aspect of ppc asm syntax -- too
error prone). If you want to compare with the constant 30, use "cmpwi".
> beq print_equal
>
> 1: b 1b
>
> print_equal:
> ...
> //code end
>
> I found that, print_equal was not called ,the whole code seemed to
> enter an infinite loop.
That's because you have an infinite loop in your code, right after "beq
print_equal".
-Scott
^ permalink raw reply
* Re: [PATCH V2 3/3] powerpc/pci: Merge ppc32 and ppc64 versions of phb_scan()
From: Grant Likely @ 2009-08-26 17:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, sfr
In-Reply-To: <E575F71A-166A-4933-8612-1F0E88A426C5@kernel.crashing.org>
On Wed, Aug 26, 2009 at 7:29 AM, Kumar Gala<galak@kernel.crashing.org> wrot=
e:
>
> On Aug 26, 2009, at 1:07 AM, Grant Likely wrote:
>
>> +/**
>> + * pci_scan_phb - Given a pci_controller, setup and scan the PCI bus
>> + * @hose: Pointer to the PCI host controller instance structure
>> + * @data: value to use for sysdata pointer. =A0ppc32 and ppc64 differ h=
ere
>> + *
>> + * Note: the 'data' pointer is a temporary measure. =A0As 32 and 64 bit
>> + * pci code gets merged, this parameter should become unnecessary becau=
se
>> + * both will use the same value.
>> + */
>> +void __devinit pcibios_scan_phb(struct pci_controller *hose, void *data=
)
>> +{
>> +
>
> Just a nit, but why not data -> sysdata since that's what we using it as.
okay.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Extending virtio_console to support multiple ports
From: Amit Shah @ 2009-08-26 15:45 UTC (permalink / raw)
To: qemu-devel, kvm, virtualization
Cc: borntraeger, linux-kernel, miltonm, linuxppc-dev, brueckner, alan
In-Reply-To: <20090826112718.GA11117@amit-x200.redhat.com>
[cc'ing some people who have made some commits in hvc_console.c]
On (Wed) Aug 26 2009 [16:57:18], Amit Shah wrote:
> On (Tue) Aug 25 2009 [11:47:20], Amit Shah wrote:
> >
> > Hello all,
> >
> > Here is a new iteration of the patch series that implements a
> > transport for guest and host communications.
> >
> > The code has been updated to reuse the virtio-console device instead
> > of creating a new virtio-serial device.
>
> And the problem now is that hvc calls the put_chars function with
> spinlocks held and we now allocate pages in send_buf(), called from
> put_chars.
>
> A few solutions:
[snip]
> - Convert hvc's usage of spinlocks to mutexes. I've no idea how this
> will play out; I'm no expert here. But I did try doing this and so far
> it all looks OK. No lockups, lockdep warnings, nothing. I have full
> debugging enabled. But this doesn't mean it's right.
So just to test this further I added the capability to have more than
one hvc console spawn from virtio_console, created two consoles and did
a 'cat' of a file in each of the virtio-consoles. It's been running for
half an hour now without any badness. No spew in debug logs too.
I also checked the code in hvc_console.c that takes the spin_locks.
Nothing there that runs from (or needs to run from) interrupt context.
So the change to mutexes does seem reasonable. Also, the spinlock code
was added really long back -- git blame shows Linus' first git commit
introduced them in the git history, so it's pure legacy baggage.
Also found a bug: hvc_resize() wants to be called with a lock held
(hp->lock) but virtio_console just calls it directly.
Anyway I'm wondering whether all those locks are needed.
Amit
diff --git a/drivers/char/hvc_console.c b/drivers/char/hvc_console.c
index d97779e..51078a3 100644
--- a/drivers/char/hvc_console.c
+++ b/drivers/char/hvc_console.c
@@ -35,7 +35,7 @@
#include <linux/tty.h>
#include <linux/tty_flip.h>
#include <linux/sched.h>
-#include <linux/spinlock.h>
+#include <linux/mutex.h>
#include <linux/delay.h>
#include <linux/freezer.h>
@@ -81,7 +81,7 @@ static LIST_HEAD(hvc_structs);
* Protect the list of hvc_struct instances from inserts and removals during
* list traversal.
*/
-static DEFINE_SPINLOCK(hvc_structs_lock);
+static DEFINE_MUTEX(hvc_structs_lock);
/*
* This value is used to assign a tty->index value to a hvc_struct based
@@ -98,23 +98,22 @@ static int last_hvc = -1;
static struct hvc_struct *hvc_get_by_index(int index)
{
struct hvc_struct *hp;
- unsigned long flags;
- spin_lock(&hvc_structs_lock);
+ mutex_lock(&hvc_structs_lock);
list_for_each_entry(hp, &hvc_structs, next) {
- spin_lock_irqsave(&hp->lock, flags);
+ mutex_lock(&hp->lock);
if (hp->index == index) {
kref_get(&hp->kref);
- spin_unlock_irqrestore(&hp->lock, flags);
- spin_unlock(&hvc_structs_lock);
+ mutex_unlock(&hp->lock);
+ mutex_unlock(&hvc_structs_lock);
return hp;
}
- spin_unlock_irqrestore(&hp->lock, flags);
+ mutex_unlock(&hp->lock);
}
hp = NULL;
- spin_unlock(&hvc_structs_lock);
+ mutex_unlock(&hvc_structs_lock);
return hp;
}
@@ -228,15 +227,14 @@ console_initcall(hvc_console_init);
static void destroy_hvc_struct(struct kref *kref)
{
struct hvc_struct *hp = container_of(kref, struct hvc_struct, kref);
- unsigned long flags;
- spin_lock(&hvc_structs_lock);
+ mutex_lock(&hvc_structs_lock);
- spin_lock_irqsave(&hp->lock, flags);
+ mutex_lock(&hp->lock);
list_del(&(hp->next));
- spin_unlock_irqrestore(&hp->lock, flags);
+ mutex_unlock(&hp->lock);
- spin_unlock(&hvc_structs_lock);
+ mutex_unlock(&hvc_structs_lock);
kfree(hp);
}
@@ -302,17 +300,16 @@ static void hvc_unthrottle(struct tty_struct *tty)
static int hvc_open(struct tty_struct *tty, struct file * filp)
{
struct hvc_struct *hp;
- unsigned long flags;
int rc = 0;
/* Auto increments kref reference if found. */
if (!(hp = hvc_get_by_index(tty->index)))
return -ENODEV;
- spin_lock_irqsave(&hp->lock, flags);
+ mutex_lock(&hp->lock);
/* Check and then increment for fast path open. */
if (hp->count++ > 0) {
- spin_unlock_irqrestore(&hp->lock, flags);
+ mutex_unlock(&hp->lock);
hvc_kick();
return 0;
} /* else count == 0 */
@@ -321,7 +318,7 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
hp->tty = tty;
- spin_unlock_irqrestore(&hp->lock, flags);
+ mutex_unlock(&hp->lock);
if (hp->ops->notifier_add)
rc = hp->ops->notifier_add(hp, hp->data);
@@ -333,9 +330,9 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
* tty fields and return the kref reference.
*/
if (rc) {
- spin_lock_irqsave(&hp->lock, flags);
+ mutex_lock(&hp->lock);
hp->tty = NULL;
- spin_unlock_irqrestore(&hp->lock, flags);
+ mutex_unlock(&hp->lock);
tty->driver_data = NULL;
kref_put(&hp->kref, destroy_hvc_struct);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -349,7 +346,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
static void hvc_close(struct tty_struct *tty, struct file * filp)
{
struct hvc_struct *hp;
- unsigned long flags;
if (tty_hung_up_p(filp))
return;
@@ -363,12 +359,12 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
return;
hp = tty->driver_data;
- spin_lock_irqsave(&hp->lock, flags);
+ mutex_lock(&hp->lock);
if (--hp->count == 0) {
/* We are done with the tty pointer now. */
hp->tty = NULL;
- spin_unlock_irqrestore(&hp->lock, flags);
+ mutex_unlock(&hp->lock);
if (hp->ops->notifier_del)
hp->ops->notifier_del(hp, hp->data);
@@ -386,7 +382,7 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
if (hp->count < 0)
printk(KERN_ERR "hvc_close %X: oops, count is %d\n",
hp->vtermno, hp->count);
- spin_unlock_irqrestore(&hp->lock, flags);
+ mutex_unlock(&hp->lock);
}
kref_put(&hp->kref, destroy_hvc_struct);
@@ -395,7 +391,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
static void hvc_hangup(struct tty_struct *tty)
{
struct hvc_struct *hp = tty->driver_data;
- unsigned long flags;
int temp_open_count;
if (!hp)
@@ -404,7 +399,7 @@ static void hvc_hangup(struct tty_struct *tty)
/* cancel pending tty resize work */
cancel_work_sync(&hp->tty_resize);
- spin_lock_irqsave(&hp->lock, flags);
+ mutex_lock(&hp->lock);
/*
* The N_TTY line discipline has problems such that in a close vs
@@ -412,7 +407,7 @@ static void hvc_hangup(struct tty_struct *tty)
* that from happening for now.
*/
if (hp->count <= 0) {
- spin_unlock_irqrestore(&hp->lock, flags);
+ mutex_unlock(&hp->lock);
return;
}
@@ -421,7 +416,7 @@ static void hvc_hangup(struct tty_struct *tty)
hp->n_outbuf = 0;
hp->tty = NULL;
- spin_unlock_irqrestore(&hp->lock, flags);
+ mutex_unlock(&hp->lock);
if (hp->ops->notifier_hangup)
hp->ops->notifier_hangup(hp, hp->data);
@@ -462,7 +457,6 @@ static int hvc_push(struct hvc_struct *hp)
static int hvc_write(struct tty_struct *tty, const unsigned char *buf, int count)
{
struct hvc_struct *hp = tty->driver_data;
- unsigned long flags;
int rsize, written = 0;
/* This write was probably executed during a tty close. */
@@ -472,7 +466,7 @@ static int hvc_write(struct tty_struct *tty, const unsigned char *buf, int count
if (hp->count <= 0)
return -EIO;
- spin_lock_irqsave(&hp->lock, flags);
+ mutex_lock(&hp->lock);
/* Push pending writes */
if (hp->n_outbuf > 0)
@@ -488,7 +482,7 @@ static int hvc_write(struct tty_struct *tty, const unsigned char *buf, int count
written += rsize;
hvc_push(hp);
}
- spin_unlock_irqrestore(&hp->lock, flags);
+ mutex_unlock(&hp->lock);
/*
* Racy, but harmless, kick thread if there is still pending data.
@@ -511,7 +505,6 @@ static int hvc_write(struct tty_struct *tty, const unsigned char *buf, int count
static void hvc_set_winsz(struct work_struct *work)
{
struct hvc_struct *hp;
- unsigned long hvc_flags;
struct tty_struct *tty;
struct winsize ws;
@@ -519,14 +512,14 @@ static void hvc_set_winsz(struct work_struct *work)
if (!hp)
return;
- spin_lock_irqsave(&hp->lock, hvc_flags);
+ mutex_lock(&hp->lock);
if (!hp->tty) {
- spin_unlock_irqrestore(&hp->lock, hvc_flags);
+ mutex_unlock(&hp->lock);
return;
}
ws = hp->ws;
tty = tty_kref_get(hp->tty);
- spin_unlock_irqrestore(&hp->lock, hvc_flags);
+ mutex_unlock(&hp->lock);
tty_do_resize(tty, &ws);
tty_kref_put(tty);
@@ -576,11 +569,10 @@ int hvc_poll(struct hvc_struct *hp)
struct tty_struct *tty;
int i, n, poll_mask = 0;
char buf[N_INBUF] __ALIGNED__;
- unsigned long flags;
int read_total = 0;
int written_total = 0;
- spin_lock_irqsave(&hp->lock, flags);
+ mutex_lock(&hp->lock);
/* Push pending writes */
if (hp->n_outbuf > 0)
@@ -622,9 +614,9 @@ int hvc_poll(struct hvc_struct *hp)
if (n <= 0) {
/* Hangup the tty when disconnected from host */
if (n == -EPIPE) {
- spin_unlock_irqrestore(&hp->lock, flags);
+ mutex_unlock(&hp->lock);
tty_hangup(tty);
- spin_lock_irqsave(&hp->lock, flags);
+ mutex_lock(&hp->lock);
} else if ( n == -EAGAIN ) {
/*
* Some back-ends can only ensure a certain min
@@ -665,7 +657,7 @@ int hvc_poll(struct hvc_struct *hp)
tty_wakeup(tty);
}
bail:
- spin_unlock_irqrestore(&hp->lock, flags);
+ mutex_unlock(&hp->lock);
if (read_total) {
/* Activity is occurring, so reset the polling backoff value to
@@ -714,11 +706,11 @@ static int khvcd(void *unused)
try_to_freeze();
wmb();
if (!cpus_are_in_xmon()) {
- spin_lock(&hvc_structs_lock);
+ mutex_lock(&hvc_structs_lock);
list_for_each_entry(hp, &hvc_structs, next) {
poll_mask |= hvc_poll(hp);
}
- spin_unlock(&hvc_structs_lock);
+ mutex_unlock(&hvc_structs_lock);
} else
poll_mask |= HVC_POLL_READ;
if (hvc_kicked)
@@ -777,8 +769,8 @@ struct hvc_struct __devinit *hvc_alloc(uint32_t vtermno, int data,
kref_init(&hp->kref);
INIT_WORK(&hp->tty_resize, hvc_set_winsz);
- spin_lock_init(&hp->lock);
- spin_lock(&hvc_structs_lock);
+ mutex_init(&hp->lock);
+ mutex_lock(&hvc_structs_lock);
/*
* find index to use:
@@ -796,7 +788,7 @@ struct hvc_struct __devinit *hvc_alloc(uint32_t vtermno, int data,
hp->index = i;
list_add_tail(&(hp->next), &hvc_structs);
- spin_unlock(&hvc_structs_lock);
+ mutex_unlock(&hvc_structs_lock);
return hp;
}
@@ -804,10 +796,9 @@ EXPORT_SYMBOL_GPL(hvc_alloc);
int hvc_remove(struct hvc_struct *hp)
{
- unsigned long flags;
struct tty_struct *tty;
- spin_lock_irqsave(&hp->lock, flags);
+ mutex_lock(&hp->lock);
tty = hp->tty;
if (hp->index < MAX_NR_HVC_CONSOLES)
@@ -815,7 +806,7 @@ int hvc_remove(struct hvc_struct *hp)
/* Don't whack hp->irq because tty_hangup() will need to free the irq. */
- spin_unlock_irqrestore(&hp->lock, flags);
+ mutex_unlock(&hp->lock);
/*
* We 'put' the instance that was grabbed when the kref instance
diff --git a/drivers/char/hvc_console.h b/drivers/char/hvc_console.h
index 3c85d78..3c086f8 100644
--- a/drivers/char/hvc_console.h
+++ b/drivers/char/hvc_console.h
@@ -45,7 +45,7 @@
#define HVC_ALLOC_TTY_ADAPTERS 8
struct hvc_struct {
- spinlock_t lock;
+ struct mutex lock;
int index;
struct tty_struct *tty;
int count;
^ permalink raw reply related
* Re: [ewg] [PATCH] IB/ehca: Construct MAD redirect replies from request MAD
From: Hal Rosenstock @ 2009-08-26 15:15 UTC (permalink / raw)
To: Joachim Fenkes
Cc: Hal Rosenstock, LKML, OF-EWG, Jason Gunthorpe, LinuxPPC-Dev,
Christoph Raisch, OF-General, Stefan Roscher
In-Reply-To: <200908261337.56128.fenkes@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 5297 bytes --]
On 8/26/09, Joachim Fenkes <fenkes@de.ibm.com> wrote:
>
> The old code used a lot of hardcoded values, which might not be valid in
> all
> environments (especially routed fabrics or partitioned subnets). Copy as
> much information as possible from the incoming request to prevent that.
>
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
> ---
>
> Hal, Jason -- here's the change I promised. Looks okay to you?
> Roland -- if Hal and Jason don't object, please queue this up for the next
> kernel. Thanks!
Thanks for doing this. It looks sane to me. The only issue I recall that
appears to be remaining is a better setting of ClassPortInfo:RespTimeValue
rather than hardcoding. Perhaps using the value from PortInfo is the way to
go (ideally it would be that value from the port to which the the requester
is being redirected to but that might not be so easy to get from this port
(I guess that could be SA Get PortInfoRecord for that port but that is a
larger change and it likely to be same as local port issuing the redirect
response).
-- Hal
Regards,
> Joachim
>
> drivers/infiniband/hw/ehca/ehca_sqp.c | 47
> ++++++++++++++++++++++++++++----
> 1 files changed, 41 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/infiniband/hw/ehca/ehca_sqp.c
> b/drivers/infiniband/hw/ehca/ehca_sqp.c
> index c568b28..8c1213f 100644
> --- a/drivers/infiniband/hw/ehca/ehca_sqp.c
> +++ b/drivers/infiniband/hw/ehca/ehca_sqp.c
> @@ -125,14 +125,30 @@ struct ib_perf {
> u8 data[192];
> } __attribute__ ((packed));
>
> +/* TC/SL/FL packed into 32 bits, as in ClassPortInfo */
> +struct tcslfl {
> + u32 tc:8;
> + u32 sl:4;
> + u32 fl:20;
> +} __attribute__ ((packed));
> +
> +/* IP Version/TC/FL packed into 32 bits, as in GRH */
> +struct vertcfl {
> + u32 ver:4;
> + u32 tc:8;
> + u32 fl:20;
> +} __attribute__ ((packed));
>
> static int ehca_process_perf(struct ib_device *ibdev, u8 port_num,
> + struct ib_wc *in_wc, struct ib_grh *in_grh,
> struct ib_mad *in_mad, struct ib_mad *out_mad)
> {
> struct ib_perf *in_perf = (struct ib_perf *)in_mad;
> struct ib_perf *out_perf = (struct ib_perf *)out_mad;
> struct ib_class_port_info *poi =
> (struct ib_class_port_info *)out_perf->data;
> + struct tcslfl *tcslfl =
> + (struct tcslfl *)&poi->redirect_tcslfl;
> struct ehca_shca *shca =
> container_of(ibdev, struct ehca_shca, ib_device);
> struct ehca_sport *sport = &shca->sport[port_num - 1];
> @@ -158,10 +174,29 @@ static int ehca_process_perf(struct ib_device *ibdev,
> u8 port_num,
> poi->base_version = 1;
> poi->class_version = 1;
> poi->resp_time_value = 18;
> - poi->redirect_lid = sport->saved_attr.lid;
> - poi->redirect_qp = sport->pma_qp_nr;
> +
> + /* copy local routing information from WC where applicable
> */
> + tcslfl->sl = in_wc->sl;
> + poi->redirect_lid =
> + sport->saved_attr.lid | in_wc->dlid_path_bits;
> + poi->redirect_qp = sport->pma_qp_nr;
> poi->redirect_qkey = IB_QP1_QKEY;
> - poi->redirect_pkey = IB_DEFAULT_PKEY_FULL;
> +
> + ehca_query_pkey(ibdev, port_num, in_wc->pkey_index,
> + &poi->redirect_pkey);
> +
> + /* if request was globally routed, copy route info */
> + if (in_grh) {
> + struct vertcfl *vertcfl =
> + (struct vertcfl
> *)&in_grh->version_tclass_flow;
> + memcpy(poi->redirect_gid, in_grh->dgid.raw,
> + sizeof(poi->redirect_gid));
> + tcslfl->tc = vertcfl->tc;
> + tcslfl->fl = vertcfl->fl;
> + } else
> + /* else only fill in default GID */
> + ehca_query_gid(ibdev, port_num, 0,
> + (union ib_gid *)&poi->redirect_gid);
>
> ehca_dbg(ibdev, "ehca_pma_lid=%x ehca_pma_qp=%x",
> sport->saved_attr.lid, sport->pma_qp_nr);
> @@ -183,8 +218,7 @@ perf_reply:
>
> int ehca_process_mad(struct ib_device *ibdev, int mad_flags, u8 port_num,
> struct ib_wc *in_wc, struct ib_grh *in_grh,
> - struct ib_mad *in_mad,
> - struct ib_mad *out_mad)
> + struct ib_mad *in_mad, struct ib_mad *out_mad)
> {
> int ret;
>
> @@ -196,7 +230,8 @@ int ehca_process_mad(struct ib_device *ibdev, int
> mad_flags, u8 port_num,
> return IB_MAD_RESULT_SUCCESS;
>
> ehca_dbg(ibdev, "port_num=%x src_qp=%x", port_num, in_wc->src_qp);
> - ret = ehca_process_perf(ibdev, port_num, in_mad, out_mad);
> + ret = ehca_process_perf(ibdev, port_num, in_wc, in_grh,
> + in_mad, out_mad);
>
> return ret;
> }
> --
> 1.6.0.4
>
>
> _______________________________________________
> ewg mailing list
> ewg@lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
>
[-- Attachment #2: Type: text/html, Size: 7065 bytes --]
^ permalink raw reply
* Can't write value into memory ?(E500 V2)
From: wilbur.chan @ 2009-08-26 14:39 UTC (permalink / raw)
To: linuxppc-dev
In an assemblely code , I invalided all the TLB entries except for
the entry we are executed in.
After that , I setuped a 1:1 TLB entry mapping of 1GB .
At last , I wrote value 30 into the physical address 0x0400,0000 (also
the virtual address because of my 1:1 mapping).
However, it seemed failed to store the value '30' at address
0x400,0000. The following is my code:
//code start
// setup a 1:1 mapping of 1GB
...
//store '30' into address 0x0400,0000
li r23, 30
lis r22, 0x400
ori r22,r22,0x0
stb r23,0(r22)
//check if we successfully store value at 0x400,0000
lis r22, 0x400
ori r22,r22,0x0
lwz r23,0(r22)
cmpw r23, 30
beq print_equal
1: b 1b
print_equal:
...
//code end
I found that, print_equal was not called ,the whole code seemed to
enter an infinite loop.
Can anyone plz tell me why this happended?
Thanks in advance.
regards,
wilbur
^ permalink raw reply
* Re: PPC driver - generic bus width
From: Michael Ellerman @ 2009-08-26 14:22 UTC (permalink / raw)
To: Alemao; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <d970ff420908260625q2d34bc10p62241218f022b5c2@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]
On Wed, 2009-08-26 at 10:25 -0300, Alemao wrote:
> Hi all,
>
> Im trying to develop a driver for my device, and its data bus can be 8, 16
> or 32 bits. This information is passed through the device tree source.
> My code is like this:
>
> struct device_info_t {
> void (*read)();
> void (*write)();
> };
>
> static int __devinit device_probe()
> {
> prop = of_get_property(ofdev->node, "bus-width", &size);
>
> device->bus_width = *prop;
>
> switch (device->bus_width) {
> case 8:
> device->read = in_8;
> device->write = out_8;
> break;
> case 16:
> device->read = in_be16;
> device->write = out_be16;
> break;
> case 32:
> device->read = in_be32;
> device->write = out_be32;
> break;
> default:
> break;
> }
> }
>
> Can someone point me some driver that is doing something similar to the
> ideia shown above?
>
> Or what Im doing wrong in my code? Cause Im getting erros (warnings) like:
>
> cc1: warnings being treated as errors
> drivers/dev_test.c:37: warning: function declaration isn't a prototype
> drivers/dev_test.c:38: warning: function declaration isn't a prototype
> drivers/dev_test.c: In function 'device_probe':
> drivers/dev_test.c:113: warning: assignment from incompatible pointer
> type
I'm not sure about the first two, you don't seem to have pasted all the
source, and you haven't given the line numbers.
The 3rd is probably because the prototype for in_8 etc. doesn't match
your structure.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Change archdata dma_data type to dma_addr_t
From: Michael Ellerman @ 2009-08-26 14:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Christoph Hellwig
In-Reply-To: <1251289790.1379.71.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
On Wed, 2009-08-26 at 22:29 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2009-08-24 at 21:48 +0200, Christoph Hellwig wrote:
> > On Mon, Aug 24, 2009 at 11:17:14AM -0500, Becky Bruce wrote:
> > > Previously, this was specified as a void *, but that's not
> > > large enough on 32-bit systems with 36-bit physical
> > > addressing support. Change the type to dma_addr_t so it
> > > will scale based on the size of a dma address.
> >
> > This looks extreml ugly to me. It seems like the typical use is to
> > store a pointer to a structure. So what about making the direct
> > dma case follow that general scheme instead?
> >
> > E.g. declare a
> >
> > struct direct_dma_data {
> > dma_addr_t direct_dma_offset;
> > };
> >
> > and have one normal instace of it, and one per weird cell device.
>
> Right, but we want to avoid a structure for the classic case of 32-bit
> systems with no iommu...
>
> I wouldn't mind doing a union here.
That might be best, the patch as it stands is a horrible mess of casts.
Stashing a dma_addr_t into a void * is sort of gross, but storing a
pointer to some struct (a void *) in a dma_addr_t is _really_ gross :)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* PPC driver - generic bus width
From: Alemao @ 2009-08-26 13:25 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev, linuxppc-embedded
Hi all,
Im trying to develop a driver for my device, and its data bus can be 8, 16
or 32 bits. This information is passed through the device tree source.
My code is like this:
struct device_info_t {
void (*read)();
void (*write)();
};
static int __devinit device_probe()
{
prop = of_get_property(ofdev->node, "bus-width", &size);
device->bus_width = *prop;
switch (device->bus_width) {
case 8:
device->read = in_8;
device->write = out_8;
break;
case 16:
device->read = in_be16;
device->write = out_be16;
break;
case 32:
device->read = in_be32;
device->write = out_be32;
break;
default:
break;
}
}
Can someone point me some driver that is doing something similar to the
ideia shown above?
Or what Im doing wrong in my code? Cause Im getting erros (warnings) like:
cc1: warnings being treated as errors
drivers/dev_test.c:37: warning: function declaration isn't a prototype
drivers/dev_test.c:38: warning: function declaration isn't a prototype
drivers/dev_test.c: In function 'device_probe':
drivers/dev_test.c:113: warning: assignment from incompatible pointer
type
PS: Im using a MPC8349, linux kernel 2.6.26
Cheers,
--
Alemao
^ permalink raw reply
* Re: [PATCH V2 3/3] powerpc/pci: Merge ppc32 and ppc64 versions of phb_scan()
From: Kumar Gala @ 2009-08-26 13:29 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, sfr
In-Reply-To: <20090826060716.30936.40578.stgit@localhost.localdomain>
On Aug 26, 2009, at 1:07 AM, Grant Likely wrote:
> +/**
> + * pci_scan_phb - Given a pci_controller, setup and scan the PCI bus
> + * @hose: Pointer to the PCI host controller instance structure
> + * @data: value to use for sysdata pointer. ppc32 and ppc64 differ
> here
> + *
> + * Note: the 'data' pointer is a temporary measure. As 32 and 64 bit
> + * pci code gets merged, this parameter should become unnecessary
> because
> + * both will use the same value.
> + */
> +void __devinit pcibios_scan_phb(struct pci_controller *hose, void
> *data)
> +{
> +
Just a nit, but why not data -> sysdata since that's what we using it
as.
- k
^ permalink raw reply
* Re: [PATCH V2 2/3] powerpc/pci: move pci_64.c device tree scanning code into pci-common.c
From: Kumar Gala @ 2009-08-26 13:24 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, sfr
In-Reply-To: <20090826060708.30936.54239.stgit@localhost.localdomain>
On Aug 26, 2009, at 1:07 AM, Grant Likely wrote:
> From: Grant Likely <grant.likely@secretlab.ca>
>
> The PCI device tree scanning code in pci_64.c is some useful
> functionality.
> It allows PCI devices to be described in the device tree instead of
> being
> probed for, which in turn allows pci devices to use all of the
> device tree
> facilities to describe complex PCI bus architectures like GPIO and IRQ
> routing (perhaps not a common situation for desktop or server systems,
> but useful for embedded systems with on-board PCI devices).
>
> This patch moves the device tree scanning into pci-common.c so it is
> available for 32-bit powerpc machines too.
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> arch/powerpc/include/asm/pci-bridge.h | 5
> arch/powerpc/include/asm/pci.h | 5
> arch/powerpc/kernel/Makefile | 2
> arch/powerpc/kernel/pci-common.c | 1
> arch/powerpc/kernel/pci_64.c | 289
> ---------------------------
> arch/powerpc/kernel/pci_of_scan.c | 358 ++++++++++++++++++++++++
> +++++++++
> 6 files changed, 364 insertions(+), 296 deletions(-)
> create mode 100644 arch/powerpc/kernel/pci_of_scan.c
>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Change archdata dma_data type to dma_addr_t
From: Benjamin Herrenschmidt @ 2009-08-26 12:29 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20090824194800.GA13503@lst.de>
On Mon, 2009-08-24 at 21:48 +0200, Christoph Hellwig wrote:
> On Mon, Aug 24, 2009 at 11:17:14AM -0500, Becky Bruce wrote:
> > Previously, this was specified as a void *, but that's not
> > large enough on 32-bit systems with 36-bit physical
> > addressing support. Change the type to dma_addr_t so it
> > will scale based on the size of a dma address.
>
> This looks extreml ugly to me. It seems like the typical use is to
> store a pointer to a structure. So what about making the direct
> dma case follow that general scheme instead?
>
> E.g. declare a
>
> struct direct_dma_data {
> dma_addr_t direct_dma_offset;
> };
>
> and have one normal instace of it, and one per weird cell device.
Right, but we want to avoid a structure for the classic case of 32-bit
systems with no iommu...
I wouldn't mind doing a union here.
The other option is to have a global somewhere that we make that point
to or something like that but it's probably even more ugly.
Cheers,
Ben.
^ permalink raw reply
* Re: [v2 PATCH 2/2]: pseries: Implement Pseries Processor Idle idle module.
From: Peter Zijlstra @ 2009-08-26 11:37 UTC (permalink / raw)
To: arun
Cc: Gautham R Shenoy, Pallipadi, Venkatesh, linux-kernel,
Paul Mackerras, Ingo Molnar, linuxppc-dev, Balbir Singh
In-Reply-To: <20090826113217.GA14758@linux.vnet.ibm.com>
On Wed, 2009-08-26 at 17:02 +0530, Arun R Bharadwaj wrote:
> * Peter Zijlstra <a.p.zijlstra@chello.nl> [2009-08-26 13:27:18]:
>
> > On Wed, 2009-08-26 at 16:40 +0530, Arun R Bharadwaj wrote:
> > > +void (*pm_idle)(void);
> > > +EXPORT_SYMBOL_GPL(pm_idle);
> >
> > Seriously.. this caused plenty problems over on x86 and you're doing the
> > exact same dumb thing?
> >
>
> Hi Peter,
>
> Cpuidle assumes pm_idle to be the default idle power management
> function. So i should either do this, or change the stuff in cpuidle.c
> so that it is more abstract.
I would much prefer the latter, I've been telling the x86 power folks to
fix this like forever, but they never seem to get around to it.
They even tried adding a second such unmanaged function pointer for
play-dead, instead of integrating everything into a single management
interface.
^ permalink raw reply
* [PATCH] IB/ehca: Construct MAD redirect replies from request MAD
From: Joachim Fenkes @ 2009-08-26 11:37 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG,
Jason Gunthorpe, Hal Rosenstock
Cc: Stefan Roscher, Christoph Raisch
The old code used a lot of hardcoded values, which might not be valid in all
environments (especially routed fabrics or partitioned subnets). Copy as
much information as possible from the incoming request to prevent that.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
Hal, Jason -- here's the change I promised. Looks okay to you?
Roland -- if Hal and Jason don't object, please queue this up for the next
kernel. Thanks!
Regards,
Joachim
drivers/infiniband/hw/ehca/ehca_sqp.c | 47 ++++++++++++++++++++++++++++----
1 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_sqp.c b/drivers/infiniband/hw/ehca/ehca_sqp.c
index c568b28..8c1213f 100644
--- a/drivers/infiniband/hw/ehca/ehca_sqp.c
+++ b/drivers/infiniband/hw/ehca/ehca_sqp.c
@@ -125,14 +125,30 @@ struct ib_perf {
u8 data[192];
} __attribute__ ((packed));
+/* TC/SL/FL packed into 32 bits, as in ClassPortInfo */
+struct tcslfl {
+ u32 tc:8;
+ u32 sl:4;
+ u32 fl:20;
+} __attribute__ ((packed));
+
+/* IP Version/TC/FL packed into 32 bits, as in GRH */
+struct vertcfl {
+ u32 ver:4;
+ u32 tc:8;
+ u32 fl:20;
+} __attribute__ ((packed));
static int ehca_process_perf(struct ib_device *ibdev, u8 port_num,
+ struct ib_wc *in_wc, struct ib_grh *in_grh,
struct ib_mad *in_mad, struct ib_mad *out_mad)
{
struct ib_perf *in_perf = (struct ib_perf *)in_mad;
struct ib_perf *out_perf = (struct ib_perf *)out_mad;
struct ib_class_port_info *poi =
(struct ib_class_port_info *)out_perf->data;
+ struct tcslfl *tcslfl =
+ (struct tcslfl *)&poi->redirect_tcslfl;
struct ehca_shca *shca =
container_of(ibdev, struct ehca_shca, ib_device);
struct ehca_sport *sport = &shca->sport[port_num - 1];
@@ -158,10 +174,29 @@ static int ehca_process_perf(struct ib_device *ibdev, u8 port_num,
poi->base_version = 1;
poi->class_version = 1;
poi->resp_time_value = 18;
- poi->redirect_lid = sport->saved_attr.lid;
- poi->redirect_qp = sport->pma_qp_nr;
+
+ /* copy local routing information from WC where applicable */
+ tcslfl->sl = in_wc->sl;
+ poi->redirect_lid =
+ sport->saved_attr.lid | in_wc->dlid_path_bits;
+ poi->redirect_qp = sport->pma_qp_nr;
poi->redirect_qkey = IB_QP1_QKEY;
- poi->redirect_pkey = IB_DEFAULT_PKEY_FULL;
+
+ ehca_query_pkey(ibdev, port_num, in_wc->pkey_index,
+ &poi->redirect_pkey);
+
+ /* if request was globally routed, copy route info */
+ if (in_grh) {
+ struct vertcfl *vertcfl =
+ (struct vertcfl *)&in_grh->version_tclass_flow;
+ memcpy(poi->redirect_gid, in_grh->dgid.raw,
+ sizeof(poi->redirect_gid));
+ tcslfl->tc = vertcfl->tc;
+ tcslfl->fl = vertcfl->fl;
+ } else
+ /* else only fill in default GID */
+ ehca_query_gid(ibdev, port_num, 0,
+ (union ib_gid *)&poi->redirect_gid);
ehca_dbg(ibdev, "ehca_pma_lid=%x ehca_pma_qp=%x",
sport->saved_attr.lid, sport->pma_qp_nr);
@@ -183,8 +218,7 @@ perf_reply:
int ehca_process_mad(struct ib_device *ibdev, int mad_flags, u8 port_num,
struct ib_wc *in_wc, struct ib_grh *in_grh,
- struct ib_mad *in_mad,
- struct ib_mad *out_mad)
+ struct ib_mad *in_mad, struct ib_mad *out_mad)
{
int ret;
@@ -196,7 +230,8 @@ int ehca_process_mad(struct ib_device *ibdev, int mad_flags, u8 port_num,
return IB_MAD_RESULT_SUCCESS;
ehca_dbg(ibdev, "port_num=%x src_qp=%x", port_num, in_wc->src_qp);
- ret = ehca_process_perf(ibdev, port_num, in_mad, out_mad);
+ ret = ehca_process_perf(ibdev, port_num, in_wc, in_grh,
+ in_mad, out_mad);
return ret;
}
--
1.6.0.4
^ permalink raw reply related
* Re: [v2 PATCH 2/2]: pseries: Implement Pseries Processor Idle idle module.
From: Peter Zijlstra @ 2009-08-26 11:27 UTC (permalink / raw)
To: arun
Cc: Gautham R Shenoy, linux-kernel, Paul Mackerras, Ingo Molnar,
linuxppc-dev, Balbir Singh
In-Reply-To: <20090826111003.GC29759@linux.vnet.ibm.com>
On Wed, 2009-08-26 at 16:40 +0530, Arun R Bharadwaj wrote:
> +void (*pm_idle)(void);
> +EXPORT_SYMBOL_GPL(pm_idle);
Seriously.. this caused plenty problems over on x86 and you're doing the
exact same dumb thing?
^ 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