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...<br><br><div><span class="gmail_quote">On 9/13/07, <b class="gmail_sendername">
<a href="mailto:linuxppc-dev-request@ozlabs.org">linuxppc-dev-request@ozlabs.org</a></b> <<a href="mailto:linuxppc-dev-request@ozlabs.org">linuxppc-dev-request@ozlabs.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Send Linuxppc-dev mailing list submissions to<br> <a href="mailto:linuxppc-dev@ozlabs.org">linuxppc-dev@ozlabs.org</a><br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> <a href="https://ozlabs.org/mailman/listinfo/linuxppc-dev">
https://ozlabs.org/mailman/listinfo/linuxppc-dev</a><br>or, via email, send a message with subject or body 'help' to<br> <a href="mailto:linuxppc-dev-request@ozlabs.org">linuxppc-dev-request@ozlabs.org</a><br>
<br>You can reach the person managing the list at<br> <a href="mailto:linuxppc-dev-owner@ozlabs.org">linuxppc-dev-owner@ozlabs.org</a><br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Linuxppc-dev digest..."
<br><br><br>Today's Topics:<br><br> 1. Re: [PATCH 15/15] Add DEFINE_SPUFS_ATTRIBUTE() (Michael Ellerman)<br> 2. Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572<br> DS port (Segher Boessenkool)<br>
3. Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572<br> DS port (Segher Boessenkool)<br> 4. Re: [PATCH 1/5] Add Freescale DMA and DMA channel to<br> Documentation/powerpc/booting-without-of.txt
file.<br> (Segher Boessenkool)<br> 5. Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572<br> DS port (Segher Boessenkool)<br> 6. Re: [PATCH v4] [POWERPC] 85xx: Add basic Uniprocessor MPC8572<br> DS port (Segher Boessenkool)
<br> 7. Re: [PATCH] [POWERPC] DTS cleanup (Segher Boessenkool)<br> 8. Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS<br> port (Segher Boessenkool)<br> 9. Re: [PATCH] [RFC][POWERPC] Merge 32 and 64 bit
<br> pci_process_bridge_OF_ranges() instances (Segher Boessenkool)<br> 10. Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS<br> port (Segher Boessenkool)<br> 11. Re: [PATCH] [POWERPC] DTS cleanup (Kumar Gala)
<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Thu, 13 Sep 2007 12:05:41 +1000<br>From: Michael Ellerman <<a href="mailto:michael@ellerman.id.au">michael@ellerman.id.au
</a>><br>Subject: Re: [PATCH 15/15] Add DEFINE_SPUFS_ATTRIBUTE()<br>To: Arnd Bergmann <<a href="mailto:arnd@arndb.de">arnd@arndb.de</a>><br>Cc: <a href="mailto:linuxppc-dev@ozlabs.org">linuxppc-dev@ozlabs.org</a>
, Jeremy Kerr <<a href="mailto:jk@ozlabs.org">jk@ozlabs.org</a>>,<br> <a href="mailto:linux-kernel@vger.kernel.org">linux-kernel@vger.kernel.org</a><br>Message-ID: <<a href="mailto:1189649141.19087.13.camel@concordia.ozlabs.ibm.com">
1189649141.19087.13.camel@concordia.ozlabs.ibm.com</a>><br>Content-Type: text/plain; charset="us-ascii"<br><br>On Wed, 2007-09-12 at 10:47 +0200, Arnd Bergmann wrote:<br>> On Wednesday 12 September 2007, Michael Ellerman wrote:
<br>> > On Wed, 2007-09-12 at 17:43 +1000, Michael Ellerman wrote:<br>> > > This patch adds DEFINE_SPUFS_ATTRIBUTE(), a wraper around<br>> > > DEFINE_SIMPLE_ATTRIBUTE which does the specified locking for the get
<br>> > > routine for us.<br>> > ><br>> > > Unfortunately we need two get routines (a locked and unlocked version) to<br>> > > support the coredump code. This patch hides one of those (the locked version)
<br>> > > inside the macro foo.<br>><br>> ><br>> > jk said:<br>> > > "Good god man!"<br>> ><br>> > Yeah, I'm a bit lukewarm on this one. But the diffstat is nice, 50% code
<br>> > reduction ain't bad :)<br>><br>> Have you looked at the change in object code size? I would expect the<br>> object code to actually become bigger. I also think that it hurts<br>> readability rather than help it.
<br><br>Yeah I did, it's smaller actually:<br><br> text data bss dec hex filename<br> 44898 17804 120 62822 f566 spufs-before.o<br> 44886 17804 120 62810 f55a spufs-after.o<br>
<br>> Maybe a better solution is to change the core dump code to not<br>> require the mutex to be held in the first place. By the time<br>> we get to call the get functions, it should already be in<br>> saved state and no longer be able to get scheduled, so we might
<br>> not actually need all the extra tricks with avoiding the<br>> mutex to be taken again.<br><br>Well that'd be nice, but I don't see anywhere that that happens. AFAICT<br>the acquire we do in the first coredump callback is the first the SPU
<br>contexts know about their PPE process dying. And spufs is still live, so<br>I think we definitely need to grab the mutex, or we might race with<br>userspace accessing spufs files.<br><br>cheers<br><br>--<br>Michael Ellerman
<br>OzLabs, IBM Australia Development Lab<br><br>wwweb: <a href="http://michael.ellerman.id.au">http://michael.ellerman.id.au</a><br>phone: +61 2 6212 1183 (tie line 70 21183)<br><br>We do not inherit the earth from our ancestors,
<br>we borrow it from our children. - S.M.A.R.T Person<br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: not available<br>Type: application/pgp-signature<br>Size: 189 bytes<br>Desc: This is a digitally signed message part
<br>Url : <a href="http://ozlabs.org/pipermail/linuxppc-dev/attachments/20070913/d7914b17/attachment-0001.pgp">http://ozlabs.org/pipermail/linuxppc-dev/attachments/20070913/d7914b17/attachment-0001.pgp</a><br><br>------------------------------
<br><br>Message: 2<br>Date: Wed, 12 Sep 2007 15:36:55 +0200<br>From: Segher Boessenkool <<a href="mailto:segher@kernel.crashing.org">segher@kernel.crashing.org</a>><br>Subject: Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
<br> DS port<br>To: Kumar Gala <<a href="mailto:galak@kernel.crashing.org">galak@kernel.crashing.org</a>><br>Cc: <a href="mailto:linuxppc-dev@ozlabs.org">linuxppc-dev@ozlabs.org</a><br>Message-ID: <<a href="mailto:a58bb9a05680c3befc4d3588992caed0@kernel.crashing.org">
a58bb9a05680c3befc4d3588992caed0@kernel.crashing.org</a>><br>Content-Type: text/plain; charset=US-ASCII; format=flowed<br><br>Looks a lot better, thanks!<br><br>Some minor nits and suggestions...<br><br>> +/ {<br>> + model = "fsl,MPC8572DS";
<br>> + compatible = "fsl,MPC8572DS", "fsl,MPC85xxDS";<br><br>We don't want "xx" compatible entries; especially here it makes<br>no sense at all. If the board is compatible to some other (older)
<br>board, just name that board explicitly.<br><br>> + PowerPC,8572@0 {<br><br>Maybe it would be good to use "PowerPC,e500" instead -- it would<br>make it easier to probe for the actual CPU type, that way. Not
<br>that Linux uses the name/compatible here at all ;-)<br><br>> + soc8572@ffe00000 {<br><br>You should put an interrupt-parent in here, so you can get rid of<br>it in all the children.<br><br><br>And then there's the pci_bridge thing we're discussing on IRC, of
<br>course -- basically, get rid of the pci_bridge pseudo-node, and<br>move the interrupt-map for the south-bridge devices into the<br>south-bridge node.<br><br><br>Segher<br><br><br><br>------------------------------<br>
<br>Message: 3<br>Date: Wed, 12 Sep 2007 16:00:38 +0200<br>From: Segher Boessenkool <<a href="mailto:segher@kernel.crashing.org">segher@kernel.crashing.org</a>><br>Subject: Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572
<br> DS port<br>To: David Gibson <<a href="mailto:david@gibson.dropbear.id.au">david@gibson.dropbear.id.au</a>><br>Cc: <a href="mailto:linuxppc-dev@ozlabs.org">linuxppc-dev@ozlabs.org</a><br>Message-ID: <<a href="mailto:44b4b3a133980aeb6c596aad71612e6c@kernel.crashing.org">
44b4b3a133980aeb6c596aad71612e6c@kernel.crashing.org</a>><br>Content-Type: text/plain; charset=US-ASCII; format=flowed<br><br>>>>> + uli1575@0 {<br>>>>> + reg = <0 0 0 0 0>;
<br>>>><br>>>> This looks kind of bogus...<br>>><br>>> Its a PCIe to PCI bridge that is transparent.<br>><br>> Right.... if it has no control registers, I think it should just lack<br>> 'reg', not define a zero-length register block.
<br><br>"reg" for PCI config registers has length 0 always, it's defined that<br>way in the PCI binding.<br><br>But if this thing is transparent, it doesn't have PCI config regs.<br><br>>>>> + #size-cells = <2>;
<br>>>>> + #address-cells = <3>;<br>>>>> + ranges = <02000000 0 80000000<br>>>>> + 02000000 0 80000000<br>>>>> + 0 20000000
<br>>>>> + 01000000 0 00000000<br>>>>> + 01000000 0 00000000<br>>>>> + 0 00100000>;<br>><br>> And if truly transparent, it should perhaps have just ranges;
<br>> indicating that child addresses are identity mapped to parent<br>> addresses.<br><br>If truly transparent, the node should just not be there at all!<br><br>>>>> + pci_bridge@0 {<br>
>>><br>>>> Ok.. why is pci_bridge nested within uli1575 - with the matching reg<br>>>> and ranges, it looks like they ought to be one device. Also if this<br>>>> is a PCI<->PCI bridge, I believe it shold have device_type = "pci".
<br>>><br>>> We've been using this as it stands for a while. If there are some<br>>> changes here that make sense I'm willing to make them.<br>><br>> Right, at present I don't see why you couldn't just ditch the
<br>> pci_bridge node, and drop its contents straight into the uli1575 node.<br><br>Yeah. The preferred name for PCI-to-PCI bridge nodes is simply "pci",<br>btw.<br><br><br>Segher<br><br><br><br>------------------------------
<br><br>Message: 4<br>Date: Thu, 13 Sep 2007 04:09:29 +0200<br>From: Segher Boessenkool <<a href="mailto:segher@kernel.crashing.org">segher@kernel.crashing.org</a>><br>Subject: Re: [PATCH 1/5] Add Freescale DMA and DMA channel to
<br> Documentation/powerpc/booting-without-of.txt file.<br>To: Scott Wood <<a href="mailto:scottwood@freescale.com">scottwood@freescale.com</a>><br>Cc: <a href="mailto:linuxppc-dev@ozlabs.org">linuxppc-dev@ozlabs.org
</a>, Zhang Wei-r63237<br> <<a href="mailto:Wei.Zhang@freescale.com">Wei.Zhang@freescale.com</a>>, <a href="mailto:paulus@samba.org">paulus@samba.org</a>, David Gibson<br> <<a href="mailto:david@gibson.dropbear.id.au">
david@gibson.dropbear.id.au</a>><br>Message-ID: <<a href="mailto:fd81b53021e39a13ea65c0a0319aab77@kernel.crashing.org">fd81b53021e39a13ea65c0a0319aab77@kernel.crashing.org</a>><br>Content-Type: text/plain; charset=US-ASCII; format=flowed
<br><br>>> I have a strange issue here. If I rename 'fsl,dma' to<br>>> 'fsl,mpc8540-dma',<br>>> the 'fsl,mpc8540-dma-channel' will be also regarded as DMA device not<br>>> DMA channel.
<br>><br>> What tree are you using? Commit<br>> 804ace8881d211ac448082e871dd312132393049<br>> in Paul's git tree should have fixed that.<br><br>Strange, I don't see that commit -- maybe gitweb is broken, or
<br>maybe the patch was superseded, or maybe it just disappeared?<br>It's still shown in patchworks with this commit id fwiw.<br><br><br>Segher<br><br><br><br>------------------------------<br><br>Message: 5<br>Date: Wed, 12 Sep 2007 16:10:09 +0200
<br>From: Segher Boessenkool <<a href="mailto:segher@kernel.crashing.org">segher@kernel.crashing.org</a>><br>Subject: Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572<br> DS port<br>To: Kumar Gala <
<a href="mailto:galak@kernel.crashing.org">galak@kernel.crashing.org</a>><br>Cc: <a href="mailto:linuxppc-dev@ozlabs.org">linuxppc-dev@ozlabs.org</a>, David Gibson<br> <<a href="mailto:david@gibson.dropbear.id.au">
david@gibson.dropbear.id.au</a>><br>Message-ID: <<a href="mailto:cbff3b332b53f61721a8e14472347b98@kernel.crashing.org">cbff3b332b53f61721a8e14472347b98@kernel.crashing.org</a>><br>Content-Type: text/plain; charset=US-ASCII; format=flowed
<br><br>>>> + i8259: interrupt-controller@20 {<br>>>> + reg = <1 20 2<br>>>> + 1 a0 2
<br>>>> + 1 4d0 2>;<br>>>> + clock-frequency = <0>;<br>>><br>>> Hrm.. what is clock-frequency for on an i8259? I see that other 8259
<br>>> descriptions have this as well, so it's not a problem with this patch<br>>> specifically.<br>><br>> Its a copy-paste thing so I don't know.<br><br>If your bootwrapper doesn't fill in this value, you should get rid
<br>of this property -- better to have no value than to have the wrong<br>value, esp. since it's probably unused anyway.<br><br><br>Segher<br><br><br><br>------------------------------<br><br>Message: 6<br>Date: Thu, 13 Sep 2007 00:22:58 +0200
<br>From: Segher Boessenkool <<a href="mailto:segher@kernel.crashing.org">segher@kernel.crashing.org</a>><br>Subject: Re: [PATCH v4] [POWERPC] 85xx: Add basic Uniprocessor MPC8572<br> DS port<br>To: Kumar Gala <
<a href="mailto:galak@kernel.crashing.org">galak@kernel.crashing.org</a>><br>Cc: <a href="mailto:linuxppc-dev@ozlabs.org">linuxppc-dev@ozlabs.org</a><br>Message-ID: <<a href="mailto:13038b1ac10f19f2e1fdbd0c1323c1e7@kernel.crashing.org">
13038b1ac10f19f2e1fdbd0c1323c1e7@kernel.crashing.org</a>><br>Content-Type: text/plain; charset=US-ASCII; format=flowed<br><br>> + soc8572@ffe00000 {<br>> + #address-cells = <1>;<br>> + #size-cells = <1>;
<br>> + device_type = "soc";<br>> + ranges = <00000000 ffe00000 00100000>;<br>> + reg = <ffe00000 00001000>; // CCSRBAR & soc regs, remove once parse
<br>> code for immrbase fixed<br><br>Hrm, if you remove it here, where else are you going to describe<br>the SoC control register block (whatever it is called -- is that<br>IMMR?)<br><br><br>Segher<br><br><br><br>------------------------------
<br><br>Message: 7<br>Date: Thu, 13 Sep 2007 00:10:38 +0200<br>From: Segher Boessenkool <<a href="mailto:segher@kernel.crashing.org">segher@kernel.crashing.org</a>><br>Subject: Re: [PATCH] [POWERPC] DTS cleanup<br>To: Kumar Gala <
<a href="mailto:galak@kernel.crashing.org">galak@kernel.crashing.org</a>><br>Cc: <a href="mailto:linuxppc-dev@ozlabs.org">linuxppc-dev@ozlabs.org</a><br>Message-ID: <<a href="mailto:919c9b76c3e6e45af6e3fb887611a681@kernel.crashing.org">
919c9b76c3e6e45af6e3fb887611a681@kernel.crashing.org</a>><br>Content-Type: text/plain; charset=US-ASCII; format=flowed<br><br>> * 32-bit in cpu node -- doesn't exist in any spec and not used by<br>> kernel<br>
<br>Yeah.<br><br>> * built-in for non-standard buses (ISA, PCI)<br><br>"built-in" is some weird CHRP property, so yes we don't need it<br>or want it.<br><br>> * Removed #interrupt-cells in places they don't need to be set
<br><br>Great :-)<br><br>> * Fixed ranges on lite5200*<br><br>This has a problem still:<br><br>> model = "fsl,mpc5200";<br>> compatible = "mpc5200";<br>> revision = ""; // from bootloader
<br>> - #interrupt-cells = <3>;<br>> device_type = "soc";<br>> - ranges = <0 f0000000 f0010000>;<br>> - reg = <f0000000 00010000>;<br>
> + ranges = <0 f0000000 0000c000>;<br>> + reg = <f0000000 0000c000>;<br><br>That makes "reg" and "ranges" identify an identical address range,<br>which means no subnode can claim any address in that range, so the
<br>"ranges" property should go. Alternatively, the "reg" might be<br>claiming too big a space.<br><br>Which is it?<br><br><br>Segher<br><br><br><br>------------------------------<br><br>Message: 8<br>
Date: Wed, 12 Sep 2007 15:20:14 +0200<br>From: Segher Boessenkool <<a href="mailto:segher@kernel.crashing.org">segher@kernel.crashing.org</a>><br>Subject: Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS
<br> port<br>To: Scott Wood <<a href="mailto:scottwood@freescale.com">scottwood@freescale.com</a>><br>Cc: Olof Johansson <<a href="mailto:olof@lixom.net">olof@lixom.net</a>>, <a href="mailto:linuxppc-dev@ozlabs.org">
linuxppc-dev@ozlabs.org</a><br>Message-ID: <<a href="mailto:41e2e527c0f0dfceedf2ffe6cdf34816@kernel.crashing.org">41e2e527c0f0dfceedf2ffe6cdf34816@kernel.crashing.org</a>><br>Content-Type: text/plain; charset=US-ASCII; format=flowed
<br><br>>>> well the ifdefs are orthogonal. We don't have a way of knowing<br>>>> primary from the device tree today.<br>>><br>>> How about something like "fsl,primary-phb" in the bus device node? I
<br>>> don't<br>>> know, maybe it's already been discussed and turned down for some<br>>> reason.<br>><br>> It's more of a Linux issue than anything to do with the hardware.<br><br>Yeah, many machines actually have multiple "primary PHBs", and
<br>Linux cannot really deal with that. It's probably best to handle<br>this from platform code.<br><br>>> Or would it be sufficient to check children of that device node to see<br>>> if the ULi is on that bus?
<br>><br>> Or more generally, see if an isa node is somewhere in that subtree.<br><br>And if there is no ISA node, find any other legacy device (non-native<br>ATA controllers, ...), etc.<br><br><br>Segher<br><br><br>
<br>------------------------------<br><br>Message: 9<br>Date: Wed, 12 Sep 2007 16:51:25 +0200<br>From: Segher Boessenkool <<a href="mailto:segher@kernel.crashing.org">segher@kernel.crashing.org</a>><br>Subject: Re: [PATCH] [RFC][POWERPC] Merge 32 and 64 bit
<br> pci_process_bridge_OF_ranges() instances<br>To: Arnd Bergmann <<a href="mailto:arnd@arndb.de">arnd@arndb.de</a>><br>Cc: <a href="mailto:linuxppc-dev@ozlabs.org">linuxppc-dev@ozlabs.org</a><br>Message-ID: <
<a href="mailto:4cd6407b936b2ce65c11092883e7b8d5@kernel.crashing.org">4cd6407b936b2ce65c11092883e7b8d5@kernel.crashing.org</a>><br>Content-Type: text/plain; charset=US-ASCII; format=flowed<br><br>>>>> +struct ranges_pci {
<br>>>>> + unsigned int pci_space;<br>>>>> + u64 pci_addr;<br>>>>> + phys_addr_t phys_addr;<br>>>>> + u64 size;<br>>>>> +} __attribute__((packed));<br>>>>> +
<br>>>><br>>>> This structure definition uses unaligned members because of the<br>>>> 'packed' attribute. Is that really what you intended?<br>>>><br>>> yes, exactly, because I'm mapping this struct on ranges extracted from
<br>>> the dts instead of juggling with ranges[foo] offsets.<br>><br>> I see. It does however look wrong to me, because you are using a<br>> hardcoded<br>> phys_addr_t type. This breaks when phys_addr has a different size from
<br>> what<br>> you expect, e.g. when booting a pure 32 bit kernel on a machine that<br>> has<br>> a 64 bit physical address space.<br><br>More generally, you can even have a different size for the "phys_addr"
<br>for different nodes in the same device tree.<br><br>You really should look at the #address-cells in this node's parent,<br>and translate that all the way up to the root node to get a CPU<br>address.<br><br><br>Segher
<br><br><br><br>------------------------------<br><br>Message: 10<br>Date: Wed, 12 Sep 2007 15:20:25 +0200<br>From: Segher Boessenkool <<a href="mailto:segher@kernel.crashing.org">segher@kernel.crashing.org</a>><br>
Subject: Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS<br> port<br>To: Kumar Gala <<a href="mailto:galak@kernel.crashing.org">galak@kernel.crashing.org</a>><br>Cc: <a href="mailto:linuxppc-dev@ozlabs.org">
linuxppc-dev@ozlabs.org</a><br>Message-ID: <<a href="mailto:6b92503d73565f8add983e64ad5d5d39@kernel.crashing.org">6b92503d73565f8add983e64ad5d5d39@kernel.crashing.org</a>><br>Content-Type: text/plain; charset=US-ASCII; format=flowed
<br><br>>>> + l2-cache-controller@20000 {<br>>>> + compatible = "fsl,8572-l2-cache-controller";<br>>>> + reg = <20000 1000>;<br>>>> + cache-line-size = <20>; // 32 bytes
<br>>>> + cache-size = <80000>; // L2, 512K<br>>>> + interrupt-parent = <&mpic>;<br>>>> + interrupts = <10 2>;<br>>>> + };
<br>>><br>>> Should this node be referenced by an l2-cache property in the cpu<br>>> node?<br>><br>> No, its a front side cache.<br><br>What is a "front side cache"? What exactly does it cache? If it's
<br>a cache for one CPU only, that fact should be shown in the device<br>tree somehow.<br><br>>>> + device_type = "pci";<br>>>> + #interrupt-cells = <1>;
<br>>>> + #size-cells = <2>;<br>>>> + #address-cells = <3>;<br>>>> + reg = <8000 1000>;<br>>>> + bus-range = <0 ff>;
<br>>>> + ranges = <02000000 0 80000000 80000000 0 20000000<br>>>> + 01000000 0 00000000 ffc00000 0 00010000>;<br>>><br>>> No prefetchable mem space?
<br>><br>> we haven't normally provided prefetch on 85xx/86xx.. will deal with<br>> this later.<br><br>If you don't set up prefetchable memory regions on the PCI from<br>the firmware, this code is fine, sure. It would be a good plan
<br>to do map all BARs that say they are prefetchable in some<br>prefetchable PCI window, it gives a nice speed boost, even when<br>the kernel accesses it as simple non-cacheable space: the PCI<br>bridges in between can streamline loads from these areas.
<br><br>In any case, the device tree should be in synch with how the<br>firmware set up the PCI hardware, and it seems that's what you<br>have now, so all is fine.<br><br><br>Segher<br><br><br><br>------------------------------
<br><br>Message: 11<br>Date: Wed, 12 Sep 2007 22:08:33 -0500<br>From: Kumar Gala <<a href="mailto:galak@kernel.crashing.org">galak@kernel.crashing.org</a>><br>Subject: Re: [PATCH] [POWERPC] DTS cleanup<br>To: Segher Boessenkool <
<a href="mailto:segher@kernel.crashing.org">segher@kernel.crashing.org</a>><br>Cc: <a href="mailto:linuxppc-dev@ozlabs.org">linuxppc-dev@ozlabs.org</a><br>Message-ID: <<a href="mailto:8FFFBF2E-8255-40FB-836D-AB5B19222DD9@kernel.crashing.org">
8FFFBF2E-8255-40FB-836D-AB5B19222DD9@kernel.crashing.org</a>><br>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed<br><br><br>On Sep 12, 2007, at 5:10 PM, Segher Boessenkool wrote:<br><br>>> * 32-bit in cpu node -- doesn't exist in any spec and not used by
<br>>> kernel<br>><br>> Yeah.<br>><br>>> * built-in for non-standard buses (ISA, PCI)<br>><br>> "built-in" is some weird CHRP property, so yes we don't need it<br>> or want it.<br>
<br>Do you suggest we get ride of it from ISA nodes as well?<br><br>><br>>> * Removed #interrupt-cells in places they don't need to be set<br>><br>> Great :-)<br>><br>>> * Fixed ranges on lite5200*
<br>><br>> This has a problem still:<br>><br>>> model = "fsl,mpc5200";<br>>> compatible = "mpc5200";<br>>> revision = ""; // from bootloader
<br>>> - #interrupt-cells = <3>;<br>>> device_type = "soc";<br>>> - ranges = <0 f0000000 f0010000>;<br>>> - reg = <f0000000 00010000>;
<br>>> + ranges = <0 f0000000 0000c000>;<br>>> + reg = <f0000000 0000c000>;<br>><br>> That makes "reg" and "ranges" identify an identical address range,
<br>> which means no subnode can claim any address in that range, so the<br>> "ranges" property should go. Alternatively, the "reg" might be<br>> claiming too big a space.<br>><br>> Which is it?
<br><br>Yeah, I think it should be 0x100 for the 'soc' regs on 52xx so I'll<br>set regs to that.<br><br>- k<br><br><br>------------------------------<br><br>_______________________________________________<br>Linuxppc-dev mailing list
<br><a href="mailto:Linuxppc-dev@ozlabs.org">Linuxppc-dev@ozlabs.org</a><br><a href="https://ozlabs.org/mailman/listinfo/linuxppc-dev">https://ozlabs.org/mailman/listinfo/linuxppc-dev</a><br><br>End of Linuxppc-dev Digest, Vol 37, Issue 84
<br>********************************************<br></blockquote></div><br>