* Re: Linuxppc-dev Digest, Vol 37, Issue 84
From: lakshminarayana babu @ 2007-09-13 4:31 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <mailman.2011.1189652741.2970.linuxppc-dev@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 20183 bytes --]
i am new to the linux.....can you tell me how to access the pci
configuration space using ioremap function...but it is implicit function
declaration...
On 9/13/07, linuxppc-dev-request@ozlabs.org <linuxppc-dev-request@ozlabs.org>
wrote:
>
> Send Linuxppc-dev mailing list submissions to
> linuxppc-dev@ozlabs.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> or, via email, send a message with subject or body 'help' to
> linuxppc-dev-request@ozlabs.org
>
> You can reach the person managing the list at
> linuxppc-dev-owner@ozlabs.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Linuxppc-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: [PATCH 15/15] Add DEFINE_SPUFS_ATTRIBUTE() (Michael Ellerman)
> 2. Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
> DS port (Segher Boessenkool)
> 3. Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
> DS port (Segher Boessenkool)
> 4. Re: [PATCH 1/5] Add Freescale DMA and DMA channel to
> Documentation/powerpc/booting-without-of.txt file.
> (Segher Boessenkool)
> 5. Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
> DS port (Segher Boessenkool)
> 6. Re: [PATCH v4] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
> DS port (Segher Boessenkool)
> 7. Re: [PATCH] [POWERPC] DTS cleanup (Segher Boessenkool)
> 8. Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS
> port (Segher Boessenkool)
> 9. Re: [PATCH] [RFC][POWERPC] Merge 32 and 64 bit
> pci_process_bridge_OF_ranges() instances (Segher Boessenkool)
> 10. Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS
> port (Segher Boessenkool)
> 11. Re: [PATCH] [POWERPC] DTS cleanup (Kumar Gala)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 13 Sep 2007 12:05:41 +1000
> From: Michael Ellerman <michael@ellerman.id.au>
> Subject: Re: [PATCH 15/15] Add DEFINE_SPUFS_ATTRIBUTE()
> To: Arnd Bergmann <arnd@arndb.de>
> Cc: linuxppc-dev@ozlabs.org, Jeremy Kerr <jk@ozlabs.org>,
> linux-kernel@vger.kernel.org
> Message-ID: <1189649141.19087.13.camel@concordia.ozlabs.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
> On Wed, 2007-09-12 at 10:47 +0200, Arnd Bergmann wrote:
> > On Wednesday 12 September 2007, Michael Ellerman wrote:
> > > On Wed, 2007-09-12 at 17:43 +1000, Michael Ellerman wrote:
> > > > This patch adds DEFINE_SPUFS_ATTRIBUTE(), a wraper around
> > > > DEFINE_SIMPLE_ATTRIBUTE which does the specified locking for the get
> > > > routine for us.
> > > >
> > > > Unfortunately we need two get routines (a locked and unlocked
> version) to
> > > > support the coredump code. This patch hides one of those (the locked
> version)
> > > > inside the macro foo.
> >
> > >
> > > jk said:
> > > > "Good god man!"
> > >
> > > Yeah, I'm a bit lukewarm on this one. But the diffstat is nice, 50%
> code
> > > reduction ain't bad :)
> >
> > Have you looked at the change in object code size? I would expect the
> > object code to actually become bigger. I also think that it hurts
> > readability rather than help it.
>
> Yeah I did, it's smaller actually:
>
> text data bss dec hex filename
> 44898 17804 120 62822 f566 spufs-before.o
> 44886 17804 120 62810 f55a spufs-after.o
>
> > Maybe a better solution is to change the core dump code to not
> > require the mutex to be held in the first place. By the time
> > we get to call the get functions, it should already be in
> > saved state and no longer be able to get scheduled, so we might
> > not actually need all the extra tricks with avoiding the
> > mutex to be taken again.
>
> Well that'd be nice, but I don't see anywhere that that happens. AFAICT
> the acquire we do in the first coredump callback is the first the SPU
> contexts know about their PPE process dying. And spufs is still live, so
> I think we definitely need to grab the mutex, or we might race with
> userspace accessing spufs files.
>
> cheers
>
> --
> Michael Ellerman
> OzLabs, IBM Australia Development Lab
>
> wwweb: http://michael.ellerman.id.au
> phone: +61 2 6212 1183 (tie line 70 21183)
>
> We do not inherit the earth from our ancestors,
> we borrow it from our children. - S.M.A.R.T Person
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 189 bytes
> Desc: This is a digitally signed message part
> Url :
> http://ozlabs.org/pipermail/linuxppc-dev/attachments/20070913/d7914b17/attachment-0001.pgp
>
> ------------------------------
>
> Message: 2
> Date: Wed, 12 Sep 2007 15:36:55 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
> DS port
> To: Kumar Gala <galak@kernel.crashing.org>
> Cc: linuxppc-dev@ozlabs.org
> Message-ID: <a58bb9a05680c3befc4d3588992caed0@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> Looks a lot better, thanks!
>
> Some minor nits and suggestions...
>
> > +/ {
> > + model = "fsl,MPC8572DS";
> > + compatible = "fsl,MPC8572DS", "fsl,MPC85xxDS";
>
> We don't want "xx" compatible entries; especially here it makes
> no sense at all. If the board is compatible to some other (older)
> board, just name that board explicitly.
>
> > + PowerPC,8572@0 {
>
> Maybe it would be good to use "PowerPC,e500" instead -- it would
> make it easier to probe for the actual CPU type, that way. Not
> that Linux uses the name/compatible here at all ;-)
>
> > + soc8572@ffe00000 {
>
> You should put an interrupt-parent in here, so you can get rid of
> it in all the children.
>
>
> And then there's the pci_bridge thing we're discussing on IRC, of
> course -- basically, get rid of the pci_bridge pseudo-node, and
> move the interrupt-map for the south-bridge devices into the
> south-bridge node.
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 12 Sep 2007 16:00:38 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
> DS port
> To: David Gibson <david@gibson.dropbear.id.au>
> Cc: linuxppc-dev@ozlabs.org
> Message-ID: <44b4b3a133980aeb6c596aad71612e6c@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> >>>> + uli1575@0 {
> >>>> + reg = <0 0 0 0 0>;
> >>>
> >>> This looks kind of bogus...
> >>
> >> Its a PCIe to PCI bridge that is transparent.
> >
> > Right.... if it has no control registers, I think it should just lack
> > 'reg', not define a zero-length register block.
>
> "reg" for PCI config registers has length 0 always, it's defined that
> way in the PCI binding.
>
> But if this thing is transparent, it doesn't have PCI config regs.
>
> >>>> + #size-cells = <2>;
> >>>> + #address-cells = <3>;
> >>>> + ranges = <02000000 0 80000000
> >>>> + 02000000 0 80000000
> >>>> + 0 20000000
> >>>> + 01000000 0 00000000
> >>>> + 01000000 0 00000000
> >>>> + 0 00100000>;
> >
> > And if truly transparent, it should perhaps have just ranges;
> > indicating that child addresses are identity mapped to parent
> > addresses.
>
> If truly transparent, the node should just not be there at all!
>
> >>>> + pci_bridge@0 {
> >>>
> >>> Ok.. why is pci_bridge nested within uli1575 - with the matching reg
> >>> and ranges, it looks like they ought to be one device. Also if this
> >>> is a PCI<->PCI bridge, I believe it shold have device_type = "pci".
> >>
> >> We've been using this as it stands for a while. If there are some
> >> changes here that make sense I'm willing to make them.
> >
> > Right, at present I don't see why you couldn't just ditch the
> > pci_bridge node, and drop its contents straight into the uli1575 node.
>
> Yeah. The preferred name for PCI-to-PCI bridge nodes is simply "pci",
> btw.
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 13 Sep 2007 04:09:29 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH 1/5] Add Freescale DMA and DMA channel to
> Documentation/powerpc/booting-without-of.txt file.
> To: Scott Wood <scottwood@freescale.com>
> Cc: linuxppc-dev@ozlabs.org, Zhang Wei-r63237
> <Wei.Zhang@freescale.com>, paulus@samba.org, David Gibson
> <david@gibson.dropbear.id.au>
> Message-ID: <fd81b53021e39a13ea65c0a0319aab77@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> >> I have a strange issue here. If I rename 'fsl,dma' to
> >> 'fsl,mpc8540-dma',
> >> the 'fsl,mpc8540-dma-channel' will be also regarded as DMA device not
> >> DMA channel.
> >
> > What tree are you using? Commit
> > 804ace8881d211ac448082e871dd312132393049
> > in Paul's git tree should have fixed that.
>
> Strange, I don't see that commit -- maybe gitweb is broken, or
> maybe the patch was superseded, or maybe it just disappeared?
> It's still shown in patchworks with this commit id fwiw.
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 5
> Date: Wed, 12 Sep 2007 16:10:09 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
> DS port
> To: Kumar Gala <galak@kernel.crashing.org>
> Cc: linuxppc-dev@ozlabs.org, David Gibson
> <david@gibson.dropbear.id.au>
> Message-ID: <cbff3b332b53f61721a8e14472347b98@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> >>> + i8259: interrupt-controller@20 {
> >>> + reg = <1 20 2
> >>> + 1 a0 2
> >>> + 1 4d0 2>;
> >>> + clock-frequency = <0>;
> >>
> >> Hrm.. what is clock-frequency for on an i8259? I see that other 8259
> >> descriptions have this as well, so it's not a problem with this patch
> >> specifically.
> >
> > Its a copy-paste thing so I don't know.
>
> If your bootwrapper doesn't fill in this value, you should get rid
> of this property -- better to have no value than to have the wrong
> value, esp. since it's probably unused anyway.
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 13 Sep 2007 00:22:58 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH v4] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
> DS port
> To: Kumar Gala <galak@kernel.crashing.org>
> Cc: linuxppc-dev@ozlabs.org
> Message-ID: <13038b1ac10f19f2e1fdbd0c1323c1e7@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> > + soc8572@ffe00000 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + device_type = "soc";
> > + ranges = <00000000 ffe00000 00100000>;
> > + reg = <ffe00000 00001000>; // CCSRBAR & soc regs,
> remove once parse
> > code for immrbase fixed
>
> Hrm, if you remove it here, where else are you going to describe
> the SoC control register block (whatever it is called -- is that
> IMMR?)
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 13 Sep 2007 00:10:38 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH] [POWERPC] DTS cleanup
> To: Kumar Gala <galak@kernel.crashing.org>
> Cc: linuxppc-dev@ozlabs.org
> Message-ID: <919c9b76c3e6e45af6e3fb887611a681@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> > * 32-bit in cpu node -- doesn't exist in any spec and not used by
> > kernel
>
> Yeah.
>
> > * built-in for non-standard buses (ISA, PCI)
>
> "built-in" is some weird CHRP property, so yes we don't need it
> or want it.
>
> > * Removed #interrupt-cells in places they don't need to be set
>
> Great :-)
>
> > * Fixed ranges on lite5200*
>
> This has a problem still:
>
> > model = "fsl,mpc5200";
> > compatible = "mpc5200";
> > revision = ""; // from bootloader
> > - #interrupt-cells = <3>;
> > device_type = "soc";
> > - ranges = <0 f0000000 f0010000>;
> > - reg = <f0000000 00010000>;
> > + ranges = <0 f0000000 0000c000>;
> > + reg = <f0000000 0000c000>;
>
> That makes "reg" and "ranges" identify an identical address range,
> which means no subnode can claim any address in that range, so the
> "ranges" property should go. Alternatively, the "reg" might be
> claiming too big a space.
>
> Which is it?
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 8
> Date: Wed, 12 Sep 2007 15:20:14 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS
> port
> To: Scott Wood <scottwood@freescale.com>
> Cc: Olof Johansson <olof@lixom.net>, linuxppc-dev@ozlabs.org
> Message-ID: <41e2e527c0f0dfceedf2ffe6cdf34816@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> >>> well the ifdefs are orthogonal. We don't have a way of knowing
> >>> primary from the device tree today.
> >>
> >> How about something like "fsl,primary-phb" in the bus device node? I
> >> don't
> >> know, maybe it's already been discussed and turned down for some
> >> reason.
> >
> > It's more of a Linux issue than anything to do with the hardware.
>
> Yeah, many machines actually have multiple "primary PHBs", and
> Linux cannot really deal with that. It's probably best to handle
> this from platform code.
>
> >> Or would it be sufficient to check children of that device node to see
> >> if the ULi is on that bus?
> >
> > Or more generally, see if an isa node is somewhere in that subtree.
>
> And if there is no ISA node, find any other legacy device (non-native
> ATA controllers, ...), etc.
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 9
> Date: Wed, 12 Sep 2007 16:51:25 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH] [RFC][POWERPC] Merge 32 and 64 bit
> pci_process_bridge_OF_ranges() instances
> To: Arnd Bergmann <arnd@arndb.de>
> Cc: linuxppc-dev@ozlabs.org
> Message-ID: <4cd6407b936b2ce65c11092883e7b8d5@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> >>>> +struct ranges_pci {
> >>>> + unsigned int pci_space;
> >>>> + u64 pci_addr;
> >>>> + phys_addr_t phys_addr;
> >>>> + u64 size;
> >>>> +} __attribute__((packed));
> >>>> +
> >>>
> >>> This structure definition uses unaligned members because of the
> >>> 'packed' attribute. Is that really what you intended?
> >>>
> >> yes, exactly, because I'm mapping this struct on ranges extracted from
> >> the dts instead of juggling with ranges[foo] offsets.
> >
> > I see. It does however look wrong to me, because you are using a
> > hardcoded
> > phys_addr_t type. This breaks when phys_addr has a different size from
> > what
> > you expect, e.g. when booting a pure 32 bit kernel on a machine that
> > has
> > a 64 bit physical address space.
>
> More generally, you can even have a different size for the "phys_addr"
> for different nodes in the same device tree.
>
> You really should look at the #address-cells in this node's parent,
> and translate that all the way up to the root node to get a CPU
> address.
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 10
> Date: Wed, 12 Sep 2007 15:20:25 +0200
> From: Segher Boessenkool <segher@kernel.crashing.org>
> Subject: Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS
> port
> To: Kumar Gala <galak@kernel.crashing.org>
> Cc: linuxppc-dev@ozlabs.org
> Message-ID: <6b92503d73565f8add983e64ad5d5d39@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
> >>> + l2-cache-controller@20000 {
> >>> + compatible = "fsl,8572-l2-cache-controller";
> >>> + reg = <20000 1000>;
> >>> + cache-line-size = <20>; // 32 bytes
> >>> + cache-size = <80000>; // L2, 512K
> >>> + interrupt-parent = <&mpic>;
> >>> + interrupts = <10 2>;
> >>> + };
> >>
> >> Should this node be referenced by an l2-cache property in the cpu
> >> node?
> >
> > No, its a front side cache.
>
> What is a "front side cache"? What exactly does it cache? If it's
> a cache for one CPU only, that fact should be shown in the device
> tree somehow.
>
> >>> + device_type = "pci";
> >>> + #interrupt-cells = <1>;
> >>> + #size-cells = <2>;
> >>> + #address-cells = <3>;
> >>> + reg = <8000 1000>;
> >>> + bus-range = <0 ff>;
> >>> + ranges = <02000000 0 80000000 80000000 0 20000000
> >>> + 01000000 0 00000000 ffc00000 0
> 00010000>;
> >>
> >> No prefetchable mem space?
> >
> > we haven't normally provided prefetch on 85xx/86xx.. will deal with
> > this later.
>
> If you don't set up prefetchable memory regions on the PCI from
> the firmware, this code is fine, sure. It would be a good plan
> to do map all BARs that say they are prefetchable in some
> prefetchable PCI window, it gives a nice speed boost, even when
> the kernel accesses it as simple non-cacheable space: the PCI
> bridges in between can streamline loads from these areas.
>
> In any case, the device tree should be in synch with how the
> firmware set up the PCI hardware, and it seems that's what you
> have now, so all is fine.
>
>
> Segher
>
>
>
> ------------------------------
>
> Message: 11
> Date: Wed, 12 Sep 2007 22:08:33 -0500
> From: Kumar Gala <galak@kernel.crashing.org>
> Subject: Re: [PATCH] [POWERPC] DTS cleanup
> To: Segher Boessenkool <segher@kernel.crashing.org>
> Cc: linuxppc-dev@ozlabs.org
> Message-ID: <8FFFBF2E-8255-40FB-836D-AB5B19222DD9@kernel.crashing.org>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>
> On Sep 12, 2007, at 5:10 PM, Segher Boessenkool wrote:
>
> >> * 32-bit in cpu node -- doesn't exist in any spec and not used by
> >> kernel
> >
> > Yeah.
> >
> >> * built-in for non-standard buses (ISA, PCI)
> >
> > "built-in" is some weird CHRP property, so yes we don't need it
> > or want it.
>
> Do you suggest we get ride of it from ISA nodes as well?
>
> >
> >> * Removed #interrupt-cells in places they don't need to be set
> >
> > Great :-)
> >
> >> * Fixed ranges on lite5200*
> >
> > This has a problem still:
> >
> >> model = "fsl,mpc5200";
> >> compatible = "mpc5200";
> >> revision = ""; // from bootloader
> >> - #interrupt-cells = <3>;
> >> device_type = "soc";
> >> - ranges = <0 f0000000 f0010000>;
> >> - reg = <f0000000 00010000>;
> >> + ranges = <0 f0000000 0000c000>;
> >> + reg = <f0000000 0000c000>;
> >
> > That makes "reg" and "ranges" identify an identical address range,
> > which means no subnode can claim any address in that range, so the
> > "ranges" property should go. Alternatively, the "reg" might be
> > claiming too big a space.
> >
> > Which is it?
>
> Yeah, I think it should be 0x100 for the 'soc' regs on 52xx so I'll
> set regs to that.
>
> - k
>
>
> ------------------------------
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
> End of Linuxppc-dev Digest, Vol 37, Issue 84
> ********************************************
>
[-- Attachment #2: Type: text/html, Size: 33549 bytes --]
^ permalink raw reply
* [PATCH] Allow sysfs_remove_group() to be called on non-added groups
From: Michael Ellerman @ 2007-09-13 4:25 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linuxppc-dev, linux-kernel
It would be nice to be able to do:
for_each_thing(thing) {
error = sysfs_create_group(&thing->kobj, attrs);
if (error) {
for_each_thing(thing)
sysfs_remove_group(&thing->kobj, attrs);
return error;
}
}
But there's a BUG_ON() in sysfs_remove_group() which hits if the attributes
were never added.
As discussed here ...
http://ozlabs.org/pipermail/cbe-oss-dev/2007-July/002774.html
.. we should just return in that case instead of BUG'ing.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
fs/sysfs/group.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index f318b73..a256775 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -73,7 +73,8 @@ void sysfs_remove_group(struct kobject * kobj,
if (grp->name) {
sd = sysfs_get_dirent(dir_sd, grp->name);
- BUG_ON(!sd);
+ if (!sd)
+ return;
} else
sd = sysfs_get(dir_sd);
--
1.5.1.3.g7a33b
^ permalink raw reply related
* Re: 2.6.23-rc3 boot hang on MPC8641D
From: Kumar Gala @ 2007-09-13 4:25 UTC (permalink / raw)
To: sivaji; +Cc: linuxppc-dev
In-Reply-To: <12648489.post@talk.nabble.com>
On Sep 12, 2007, at 11:18 PM, sivaji wrote:
>
> Hi,
> I am try to boot the 2.6.23-rc3 kernel to my custom board
> based on
> 8641D Processor. After uncompressing the kernel it was hang. I got the
> following messages.
>
> Uncompressing Kernel Image ... OK
> Booting using flat device tree at 0x600000.
>
> Then i tried to debug with GDB. In my source path i given
> the command
> ${CROSS_COMPILE}gdb vmlinux, I got GDB Prompt after i tried to set the
> breakpoint at start_kernel. I got follwing messages
>
> gdb) b start_kernel
> Cannot access memory at address 0xc02b44ec
how are you connecting gdb to the board?
do you have a JTAG debugger connected to the board?
- k
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: David Gibson @ 2007-09-13 4:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <39A1A44F-CD73-4CC1-89DE-608A1041AAF7@kernel.crashing.org>
On Wed, Sep 12, 2007 at 10:28:24PM -0500, Kumar Gala wrote:
[snip]
> >> + soc8572@ffe00000 {
> >
> > You should put an interrupt-parent in here, so you can get rid of
> > it in all the children.
>
> Are interrupt-parent's inherited by child nodes?
Strictly speaking, a node's default interrupt-parent is its physical
parent. And a node without interrupt-map identity maps all interrupts
to *its* parent. So the interrupt is notionally wired from the child
to its parent and so forth up the bus tree until it reaches a node
with a specified interrupt-parent or interrupt-map.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* 2.6.23-rc3 boot hang on MPC8641D
From: sivaji @ 2007-09-13 4:18 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am try to boot the 2.6.23-rc3 kernel to my custom board based on
8641D Processor. After uncompressing the kernel it was hang. I got the
following messages.
Uncompressing Kernel Image ... OK
Booting using flat device tree at 0x600000.
Then i tried to debug with GDB. In my source path i given the command
${CROSS_COMPILE}gdb vmlinux, I got GDB Prompt after i tried to set the
breakpoint at start_kernel. I got follwing messages
gdb) b start_kernel
Cannot access memory at address 0xc02b44ec
Processor Information:
8641D processor and the silicon revision is 2.0.
Part : MPC8641D
Revision: 2.0
e600 Core Revision: 2.2
DeviceMarking: B
Processor Version Register Value: 0x8004_0202
System Version Register Value: 0x8090_0120
I don't know how to proceed. Please tell the way how to start kernel
debug in this situation.
By
Sivaji
--
View this message in context: http://www.nabble.com/2.6.23-rc3-boot-hang-on-MPC8641D-tf4433508.html#a12648489
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/2][RESEND] ehea: propagate physical port state
From: Jeff Garzik @ 2007-09-13 4:14 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
In-Reply-To: <200709071230.18395.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> Introduces a module parameter to decide whether the physical
> port link state is propagated to the network stack or not.
> It makes sense not to take the physical port state into account
> on machines with more logical partitions that communicate
> with each other. This is always possible no matter what the physical
> port state is. Thus eHEA can be considered as a switch there.
>
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
applied 1-2
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-13 3:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <cbff3b332b53f61721a8e14472347b98@kernel.crashing.org>
On Sep 12, 2007, at 9:10 AM, Segher Boessenkool wrote:
>>>> + i8259: interrupt-controller@20 {
>>>> + reg = <1 20 2
>>>> + 1 a0 2
>>>> + 1 4d0 2>;
>>>> + clock-frequency = <0>;
>>>
>>> Hrm.. what is clock-frequency for on an i8259? I see that other
>>> 8259
>>> descriptions have this as well, so it's not a problem with this
>>> patch
>>> specifically.
>>
>> Its a copy-paste thing so I don't know.
>
> If your bootwrapper doesn't fill in this value, you should get rid
> of this property -- better to have no value than to have the wrong
> value, esp. since it's probably unused anyway.
I'm going to kill this since I can't find it spec'd anywhere.
- k
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-13 3:28 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <a58bb9a05680c3befc4d3588992caed0@kernel.crashing.org>
On Sep 12, 2007, at 8:36 AM, Segher Boessenkool wrote:
> Looks a lot better, thanks!
>
> Some minor nits and suggestions...
>
>> +/ {
>> + model = "fsl,MPC8572DS";
>> + compatible = "fsl,MPC8572DS", "fsl,MPC85xxDS";
>
> We don't want "xx" compatible entries; especially here it makes
> no sense at all. If the board is compatible to some other (older)
> board, just name that board explicitly.
removed.
>
>> + PowerPC,8572@0 {
>
> Maybe it would be good to use "PowerPC,e500" instead -- it would
> make it easier to probe for the actual CPU type, that way. Not
> that Linux uses the name/compatible here at all ;-)
I thought about this, not sure what the best solution is.
>> + soc8572@ffe00000 {
>
> You should put an interrupt-parent in here, so you can get rid of
> it in all the children.
Are interrupt-parent's inherited by child nodes?
> And then there's the pci_bridge thing we're discussing on IRC, of
> course -- basically, get rid of the pci_bridge pseudo-node, and
> move the interrupt-map for the south-bridge devices into the
> south-bridge node.
Leaving the interrupt-map in the PHB because that works and moving it
down has issues.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-13 3:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <6b92503d73565f8add983e64ad5d5d39@kernel.crashing.org>
On Sep 12, 2007, at 8:20 AM, Segher Boessenkool wrote:
>>>> + l2-cache-controller@20000 {
>>>> + compatible = "fsl,8572-l2-cache-controller";
>>>> + reg = <20000 1000>;
>>>> + cache-line-size = <20>; // 32 bytes
>>>> + cache-size = <80000>; // L2, 512K
>>>> + interrupt-parent = <&mpic>;
>>>> + interrupts = <10 2>;
>>>> + };
>>>
>>> Should this node be referenced by an l2-cache property in the cpu
>>> node?
>>
>> No, its a front side cache.
>
> What is a "front side cache"? What exactly does it cache? If it's
> a cache for one CPU only, that fact should be shown in the device
> tree somehow.
Its in front of the memory controllers. Its not specific to a given
CPU.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] DTS cleanup
From: Kumar Gala @ 2007-09-13 3:08 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <919c9b76c3e6e45af6e3fb887611a681@kernel.crashing.org>
On Sep 12, 2007, at 5:10 PM, Segher Boessenkool wrote:
>> * 32-bit in cpu node -- doesn't exist in any spec and not used by
>> kernel
>
> Yeah.
>
>> * built-in for non-standard buses (ISA, PCI)
>
> "built-in" is some weird CHRP property, so yes we don't need it
> or want it.
Do you suggest we get ride of it from ISA nodes as well?
>
>> * Removed #interrupt-cells in places they don't need to be set
>
> Great :-)
>
>> * Fixed ranges on lite5200*
>
> This has a problem still:
>
>> model = "fsl,mpc5200";
>> compatible = "mpc5200";
>> revision = ""; // from bootloader
>> - #interrupt-cells = <3>;
>> device_type = "soc";
>> - ranges = <0 f0000000 f0010000>;
>> - reg = <f0000000 00010000>;
>> + ranges = <0 f0000000 0000c000>;
>> + reg = <f0000000 0000c000>;
>
> That makes "reg" and "ranges" identify an identical address range,
> which means no subnode can claim any address in that range, so the
> "ranges" property should go. Alternatively, the "reg" might be
> claiming too big a space.
>
> Which is it?
Yeah, I think it should be 0x100 for the 'soc' regs on 52xx so I'll
set regs to that.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Segher Boessenkool @ 2007-09-12 13:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1DE5CB62-9EF1-42BA-93F3-CE15DD94F5DD@kernel.crashing.org>
>>> + l2-cache-controller@20000 {
>>> + compatible = "fsl,8572-l2-cache-controller";
>>> + reg = <20000 1000>;
>>> + cache-line-size = <20>; // 32 bytes
>>> + cache-size = <80000>; // L2, 512K
>>> + interrupt-parent = <&mpic>;
>>> + interrupts = <10 2>;
>>> + };
>>
>> Should this node be referenced by an l2-cache property in the cpu
>> node?
>
> No, its a front side cache.
What is a "front side cache"? What exactly does it cache? If it's
a cache for one CPU only, that fact should be shown in the device
tree somehow.
>>> + device_type = "pci";
>>> + #interrupt-cells = <1>;
>>> + #size-cells = <2>;
>>> + #address-cells = <3>;
>>> + reg = <8000 1000>;
>>> + bus-range = <0 ff>;
>>> + ranges = <02000000 0 80000000 80000000 0 20000000
>>> + 01000000 0 00000000 ffc00000 0 00010000>;
>>
>> No prefetchable mem space?
>
> we haven't normally provided prefetch on 85xx/86xx.. will deal with
> this later.
If you don't set up prefetchable memory regions on the PCI from
the firmware, this code is fine, sure. It would be a good plan
to do map all BARs that say they are prefetchable in some
prefetchable PCI window, it gives a nice speed boost, even when
the kernel accesses it as simple non-cacheable space: the PCI
bridges in between can streamline loads from these areas.
In any case, the device tree should be in synch with how the
firmware set up the PCI hardware, and it seems that's what you
have now, so all is fine.
Segher
^ permalink raw reply
* Re: [PATCH] [RFC][POWERPC] Merge 32 and 64 bit pci_process_bridge_OF_ranges() instances
From: Segher Boessenkool @ 2007-09-12 14:51 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200709121013.51500.arnd@arndb.de>
>>>> +struct ranges_pci {
>>>> + unsigned int pci_space;
>>>> + u64 pci_addr;
>>>> + phys_addr_t phys_addr;
>>>> + u64 size;
>>>> +} __attribute__((packed));
>>>> +
>>>
>>> This structure definition uses unaligned members because of the
>>> 'packed' attribute. Is that really what you intended?
>>>
>> yes, exactly, because I'm mapping this struct on ranges extracted from
>> the dts instead of juggling with ranges[foo] offsets.
>
> I see. It does however look wrong to me, because you are using a
> hardcoded
> phys_addr_t type. This breaks when phys_addr has a different size from
> what
> you expect, e.g. when booting a pure 32 bit kernel on a machine that
> has
> a 64 bit physical address space.
More generally, you can even have a different size for the "phys_addr"
for different nodes in the same device tree.
You really should look at the #address-cells in this node's parent,
and translate that all the way up to the root node to get a CPU
address.
Segher
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Segher Boessenkool @ 2007-09-12 13:20 UTC (permalink / raw)
To: Scott Wood; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <46E6CE9A.8080402@freescale.com>
>>> well the ifdefs are orthogonal. We don't have a way of knowing
>>> primary from the device tree today.
>>
>> How about something like "fsl,primary-phb" in the bus device node? I
>> don't
>> know, maybe it's already been discussed and turned down for some
>> reason.
>
> It's more of a Linux issue than anything to do with the hardware.
Yeah, many machines actually have multiple "primary PHBs", and
Linux cannot really deal with that. It's probably best to handle
this from platform code.
>> Or would it be sufficient to check children of that device node to see
>> if the ULi is on that bus?
>
> Or more generally, see if an isa node is somewhere in that subtree.
And if there is no ISA node, find any other legacy device (non-native
ATA controllers, ...), etc.
Segher
^ permalink raw reply
* Re: [PATCH] [POWERPC] DTS cleanup
From: Segher Boessenkool @ 2007-09-12 22:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0709121154120.19816@blarg.am.freescale.net>
> * 32-bit in cpu node -- doesn't exist in any spec and not used by
> kernel
Yeah.
> * built-in for non-standard buses (ISA, PCI)
"built-in" is some weird CHRP property, so yes we don't need it
or want it.
> * Removed #interrupt-cells in places they don't need to be set
Great :-)
> * Fixed ranges on lite5200*
This has a problem still:
> model = "fsl,mpc5200";
> compatible = "mpc5200";
> revision = ""; // from bootloader
> - #interrupt-cells = <3>;
> device_type = "soc";
> - ranges = <0 f0000000 f0010000>;
> - reg = <f0000000 00010000>;
> + ranges = <0 f0000000 0000c000>;
> + reg = <f0000000 0000c000>;
That makes "reg" and "ranges" identify an identical address range,
which means no subnode can claim any address in that range, so the
"ranges" property should go. Alternatively, the "reg" might be
claiming too big a space.
Which is it?
Segher
^ permalink raw reply
* Re: [PATCH v4] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Segher Boessenkool @ 2007-09-12 22:22 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0709121119160.19430@blarg.am.freescale.net>
> + soc8572@ffe00000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + device_type = "soc";
> + ranges = <00000000 ffe00000 00100000>;
> + reg = <ffe00000 00001000>; // CCSRBAR & soc regs, remove once parse
> code for immrbase fixed
Hrm, if you remove it here, where else are you going to describe
the SoC control register block (whatever it is called -- is that
IMMR?)
Segher
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Segher Boessenkool @ 2007-09-12 13:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0709111436290.14121@blarg.am.freescale.net>
Looks a lot better, thanks!
Some minor nits and suggestions...
> +/ {
> + model = "fsl,MPC8572DS";
> + compatible = "fsl,MPC8572DS", "fsl,MPC85xxDS";
We don't want "xx" compatible entries; especially here it makes
no sense at all. If the board is compatible to some other (older)
board, just name that board explicitly.
> + PowerPC,8572@0 {
Maybe it would be good to use "PowerPC,e500" instead -- it would
make it easier to probe for the actual CPU type, that way. Not
that Linux uses the name/compatible here at all ;-)
> + soc8572@ffe00000 {
You should put an interrupt-parent in here, so you can get rid of
it in all the children.
And then there's the pci_bridge thing we're discussing on IRC, of
course -- basically, get rid of the pci_bridge pseudo-node, and
move the interrupt-map for the south-bridge devices into the
south-bridge node.
Segher
^ permalink raw reply
* Re: [PATCH 1/5] Add Freescale DMA and DMA channel to Documentation/powerpc/booting-without-of.txt file.
From: Segher Boessenkool @ 2007-09-13 2:09 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Zhang Wei-r63237, paulus, David Gibson
In-Reply-To: <20070912151938.GA15561@ld0162-tx32.am.freescale.net>
>> I have a strange issue here. If I rename 'fsl,dma' to
>> 'fsl,mpc8540-dma',
>> the 'fsl,mpc8540-dma-channel' will be also regarded as DMA device not
>> DMA channel.
>
> What tree are you using? Commit
> 804ace8881d211ac448082e871dd312132393049
> in Paul's git tree should have fixed that.
Strange, I don't see that commit -- maybe gitweb is broken, or
maybe the patch was superseded, or maybe it just disappeared?
It's still shown in patchworks with this commit id fwiw.
Segher
^ permalink raw reply
* Re: [PATCH 15/15] Add DEFINE_SPUFS_ATTRIBUTE()
From: Michael Ellerman @ 2007-09-13 2:05 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Jeremy Kerr, linux-kernel
In-Reply-To: <200709121047.05471.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 2021 bytes --]
On Wed, 2007-09-12 at 10:47 +0200, Arnd Bergmann wrote:
> On Wednesday 12 September 2007, Michael Ellerman wrote:
> > On Wed, 2007-09-12 at 17:43 +1000, Michael Ellerman wrote:
> > > This patch adds DEFINE_SPUFS_ATTRIBUTE(), a wraper around
> > > DEFINE_SIMPLE_ATTRIBUTE which does the specified locking for the get
> > > routine for us.
> > >
> > > Unfortunately we need two get routines (a locked and unlocked version) to
> > > support the coredump code. This patch hides one of those (the locked version)
> > > inside the macro foo.
>
> >
> > jk said:
> > > "Good god man!"
> >
> > Yeah, I'm a bit lukewarm on this one. But the diffstat is nice, 50% code
> > reduction ain't bad :)
>
> Have you looked at the change in object code size? I would expect the
> object code to actually become bigger. I also think that it hurts
> readability rather than help it.
Yeah I did, it's smaller actually:
text data bss dec hex filename
44898 17804 120 62822 f566 spufs-before.o
44886 17804 120 62810 f55a spufs-after.o
> Maybe a better solution is to change the core dump code to not
> require the mutex to be held in the first place. By the time
> we get to call the get functions, it should already be in
> saved state and no longer be able to get scheduled, so we might
> not actually need all the extra tricks with avoiding the
> mutex to be taken again.
Well that'd be nice, but I don't see anywhere that that happens. AFAICT
the acquire we do in the first coredump callback is the first the SPU
contexts know about their PPE process dying. And spufs is still live, so
I think we definitely need to grab the mutex, or we might race with
userspace accessing spufs files.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix CPM1 uart console
From: Kumar Gala @ 2007-09-12 22:57 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: Linuxppc-embedded
In-Reply-To: <46D5A715.7090802@scram.de>
On Aug 29, 2007, at 12:04 PM, Jochen Friedrich wrote:
> The powerpc version of commproc.c doesn't export cpm_dpram_phys due to
> a typo. The ppc version of cpm_dpram_addr returns a usable virtual
> address
> mapped to a physical address at the same location. cpm_dpram_phys
> returns
> complete garbage as it tries to calculate an offset based on an
> otherwise
> unused virtual adress returned by ioremap.
>
> This patch fixes the typo for powerpc and removes the unnecessary
> ioremap
> and corresponding virtual address for ppc.
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> ---
> arch/powerpc/sysdev/commproc.c | 2 +-
> arch/ppc/8xx_io/commproc.c | 4 +---
> 2 files changed, 2 insertions(+), 4 deletions(-)
> diff --git a/arch/powerpc/sysdev/commproc.c b/arch/powerpc/sysdev/
> commproc.c
> index 4f67b89..dd5417a 100644
> --- a/arch/powerpc/sysdev/commproc.c
> +++ b/arch/powerpc/sysdev/commproc.c
> @@ -395,4 +395,4 @@ uint cpm_dpram_phys(u8* addr)
> {
> return (dpram_pbase + (uint)(addr - dpram_vbase));
> }
> -EXPORT_SYMBOL(cpm_dpram_addr);
> +EXPORT_SYMBOL(cpm_dpram_phys);
> diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
> index 7088428..593b939 100644
> --- a/arch/ppc/8xx_io/commproc.c
> +++ b/arch/ppc/8xx_io/commproc.c
> @@ -379,14 +379,12 @@ static rh_block_t cpm_boot_dpmem_rh_block[16];
> static rh_info_t cpm_dpmem_info;
>
> #define CPM_DPMEM_ALIGNMENT 8
> -static u8* dpram_vbase;
> static uint dpram_pbase;
>
> void m8xx_cpm_dpinit(void)
> {
> spin_lock_init(&cpm_dpmem_lock);
>
> - dpram_vbase = immr_map_size(im_cpm.cp_dpmem, CPM_DATAONLY_BASE +
> CPM_DATAONLY_SIZE);
> dpram_pbase = (uint)&((immap_t *)IMAP_ADDR)->im_cpm.cp_dpmem;
>
> /* Initialize the info header */
> @@ -465,6 +463,6 @@ EXPORT_SYMBOL(cpm_dpram_addr);
>
> uint cpm_dpram_phys(u8* addr)
> {
> - return (dpram_pbase + (uint)(addr - dpram_vbase));
> + return (uint)addr;
this doesn't seem quite right.
> }
> EXPORT_SYMBOL(cpm_dpram_phys);
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: 7448 pll registers
From: Kumar Gala @ 2007-09-12 22:57 UTC (permalink / raw)
To: Leisner, Martin; +Cc: Linuxppc-embedded
In-Reply-To: <556445368AFA1C438794ABDA8901891C066B5BD4@USA0300MS03.na.xerox.net>
On Sep 5, 2007, at 4:24 PM, Leisner, Martin wrote:
> I'm going to get DFS into the 7448 (it looks like I'm going to take a
> different
> tactic then I see in 2.6.20.16 -- it hinges on powermac, and I don't
> know if it
> even compiles).
>
> In include/asm-powerpc, its missing definitions for HID1/{PC4,PC5}.
>
> bash2 :2 mleisner@linuxcom-01 05:18:58; rcsdiff -u reg.h
> ===================================================================
> RCS file: reg.h,v
> retrieving revision 1.1
> diff -u -r1.1 reg.h
> --- reg.h 2007/09/05 20:45:36 1.1
> +++ reg.h 2007/09/05 20:46:56
> @@ -253,6 +253,8 @@
> #define HID1_PC1 (1<<15) /* 7450 PLL_CFG[1] */
> #define HID1_PC2 (1<<14) /* 7450 PLL_CFG[2] */
> #define HID1_PC3 (1<<13) /* 7450 PLL_CFG[3] */
> +#define HID1_PC4 (1<<12) /* ???? PLL_CFG[4] */
7455 for PLL_CFG[4]
> +#define HID1_PC5 (1<<17) /* 7448 specific bit --
> PLL_CFG[5] */
> #define HID1_SYNCBE (1<<11) /* 7450 ABE for sync, eieio */
> #define HID1_ABE (1<<10) /* 7450 Address Broadcast
> Enable
> */
> #define HID1_PS (1<<16) /* 750FX PLL selection
> */
>
>
> PC4 seems "generic", PC5 is a "MPC7448 specific bit"
>
> I'm not sure what HID1_PS means ( 750FX PLL selection ), its the same
> bit as
> HID1_PC0.
Do you want this patch in the kernel? If so we'll need a signed-off-by.
- k
^ permalink raw reply
* Re: Problems with mii-bitbang.c on MPC8270
From: Scott Wood @ 2007-09-12 22:30 UTC (permalink / raw)
To: Esben Haabendal; +Cc: LinuxPPC-dev
In-Reply-To: <fa1a16f246925e0db38eb3a52e51934e@127.0.0.1>
Esben Haabendal wrote:
> Also, fs_enet_mdio_bb_exit does not work, as shown in the log below.
> Not that I need it, but I guess it should be working when it is there.
I think this is a generic PHY issue, addressed by this patch:
http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042342.html
-Scott
^ permalink raw reply
* frequency scaling for 7448
From: Leisner, Martin @ 2007-09-12 20:23 UTC (permalink / raw)
To: Linuxppc-embedded
I've written a frequency scaling module for a 7448 which plugs into the
linux governors.
I plugged in into 2.6.20.16 on a taiga board.
I have a good handle on how arch/i386/kernel/cpu/cpufreq handles
cpufreq, its not clear how
it should be done in the powerpc -- there's some frequency scaling stuff
in powermac/, but its not
useful for taiga board (I like the ToDO -- needs a big cleanup).
What I'm seeing on the taiga board:
1) when I enter nap, the ethernet seems to be VERY lethagic,
unless I spin the processor...
2) /2 works fine, /4 causes the ethernet/disk to break...
I'm very open to suggestions...it also appears cpufreq can be a module
on SOME architectures...
marty
^ permalink raw reply
* Re: [PATCH 02/12] IB/ehca: Add 1 is not longer needed because of firmware interface change
From: Roland Dreier @ 2007-09-12 20:21 UTC (permalink / raw)
To: Joachim Fenkes
Cc: LKML, OF-EWG, LinuxPPC-Dev, Christoph Raisch, OF-General,
Stefan Roscher
In-Reply-To: <200709111529.07935.fenkes@de.ibm.com>
What happens if someone runs the new driver with older firmware? Or
what if someone upgrades the firmware without updating the driver?
- R.
^ permalink raw reply
* Re: [PATCH] [POWERPC] ucc_geth: fix compilation
From: Timur Tabi @ 2007-09-12 19:48 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linuxppc-dev
In-Reply-To: <20070912112456.GA15556@localhost.localdomain>
Anton Vorontsov wrote:
> This patch is against paulus/powerpc.git or galak/powerpc.git tree.
> Both affected.
Acked-by: Timur Tabi <timur@freescale.com>
This is an important fix. Without it, 836x and 832x won't build.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [NEWBIE] Interrupt-problem mpc5200
From: Grant Likely @ 2007-09-12 19:29 UTC (permalink / raw)
To: S. Fricke; +Cc: linuxppc-dev
In-Reply-To: <20070912183038.GA5682@sfrouter>
On 9/12/07, S. Fricke <silvio.fricke@googlemail.com> wrote:
> Hello,
>
> > > I have looked up "kernel/irq/manage.c". "-ENOSYS" is returned on function
> > > "setup_irq" because the used irq(MPC52xx_IRQ2) is the same as no_irq_chip.
> > >
> > > THE MPC52xx_IRQ2 is a excerpt from "include/ppc/mpc52xx.h" (per copy
> > > paste), but mpc52xx is (now) a powerpc-arch. What is the desired value for
> > > IRQ-2 on a mpc5200b?
> >
> > The irq number you pass into request_irq is a system-wide irq number;
> > it doesn't necessarily map directly onto the MPC52xx irq number.
> > Typically, you'd have a node for your device in the device tree which
> > has a phandle back to the interrupt node and you would use
> > irq_of_parse_and_map() to map it back to a system-wide irq number.
>
> The IRQ-pin-2 belongs to "PIN-configuration-nodes" described in
> "booting-without-of.txt"? Than, what is the QE for my MPC5200B?
>
> Can u give me an example with a single IRQ of a configuration-node for a
> dts?
myreallycooldevice@0 {
interrupts = <1 2 3>;
interrupt-parent = <&mpc5200_pic>;
};
The interrupts property matches the size of the #interrupt-cells
property in the interrupt controller node. For the 5200-intc, each
interrupt is described by 3 cells; l1, l2 and sense which is a
reflection of the interrupt controller architecture. For IRQ0, l1=0,
l2=0; IRQ1, l1=1, l2=1; IRQ2, l1=1 and l2=2; IRQ3, l1=1, l2=3 Sense is
described in mpc52xx-device-tree-bindings.txt
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ 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