Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
On Wednesday 16 January 2008, Josh Boyer wrote: > On Wed, 16 Jan 2008 20:53:59 +1100 > > Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote: > > > With the removal the the "rgmii-interface" device_type property from > > > the dts files, the newemac driver needs an update to only rely on > > > compatible property. > > > > > > Signed-off-by: Stefan Roese <[EMAIL PROTECTED]> > > > > I need to test if it works on CAB, can't change the DT on those. I'll > > let you know tomorrow. > > This should be fine on CAB. The rgmii node has: > > compatible = "ibm,rgmii-axon", "ibm,rgmii" > > so the match should still catch on the latter. How about this patch? Ben, if you think this is ok then we should make sure that it goes in in this merge-window, since the other dts patch relies on it. Thanks. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/6] PS3: gelic: gelic updates for 2.6.25
Hi Jeff, The patch set I posted on Dec 13 2007 (except v2 of #6) have been reviewed on the ML and seems to have no more outstanding comments/requests. http://marc.info/?l=linux-netdev&m=119754603814092 Is it OK to apply for 2.6.25? If OK, I'll ask Paul to merge this set into the powerpc tree with my wireless patch because the dependent patch set will go into the tree. best regards -- Masakazu MOKUNO ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH powerpc] Fake NUMA emulation for PowerPC (Take 3)
* Michael Ellerman <[EMAIL PROTECTED]> [2008-01-30 00:04:58]: > Why do you check !p after assigning to nid? I assume it's because we > might have reached the end of the command line, ie. p == NULL, but we're > still adding memory to the last node? If so it's a it's a little subtle > and deserves a comment I think. > The reason that we check for !p after assigning node id is that, in case we create fake NUMA nodes, we want nid to be the fake numa node id and not the real node id or in the non NUMA case, node id 0. The if (!p) checks to see if we do have more arguments to parse. > Otherwise this looks pretty good. > Thanks! > 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 -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc64 vecemu compile failure
On Wed, Jan 30, 2008 at 01:03:37AM +0100, maximilian attems wrote: > on latest git since driver subsys merge on powerpc64: > > arch/powerpc/kernel/built-in.o: In function `fphalf': > vecemu.c:(.toc+0x1360): undefined reference to `devices_subsys' > make[3]: *** [.tmp_vmlinux1] Error 1 See the patches posted on lkml for this already. thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc64 vecemu compile failure
On Wed, Jan 30, 2008 at 12:39:25PM +1100, Michael Ellerman wrote: > > On Tue, 2008-01-29 at 18:56 -0600, Olof Johansson wrote: > > Hi, > > > > On Wed, Jan 30, 2008 at 01:03:37AM +0100, maximilian attems wrote: > > > on latest git since driver subsys merge on powerpc64: > > > > > > arch/powerpc/kernel/built-in.o: In function `fphalf': > > > vecemu.c:(.toc+0x1360): undefined reference to `devices_subsys' > > > make[3]: *** [.tmp_vmlinux1] Error 1 > > > It's a known problem, fixed by: > > > > http://patchwork.ozlabs.org/linuxppc/patch?id=16491 > > But begs the question, why is the linker lying to use about vecemu.c > using devices_subsys? Yes, that is a good question. fphalf isn't near it either. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] hide kernel only code in asm-powerpc/elf.h
On Fri, 2008-01-25 at 19:08 +0100, Olaf Hering wrote: > stuff inside CONFIG_* should not be exported via make headers-install > > Signed-off-by: Olaf Hering <[EMAIL PROTECTED]> > > --- > include/asm-powerpc/elf.h |2 ++ > 1 file changed, 2 insertions(+) Thanks Olaf, I noticed that once but forgot to fix it. 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 signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc64 vecemu compile failure
On Tue, 2008-01-29 at 18:56 -0600, Olof Johansson wrote: > Hi, > > On Wed, Jan 30, 2008 at 01:03:37AM +0100, maximilian attems wrote: > > on latest git since driver subsys merge on powerpc64: > > > > arch/powerpc/kernel/built-in.o: In function `fphalf': > > vecemu.c:(.toc+0x1360): undefined reference to `devices_subsys' > > make[3]: *** [.tmp_vmlinux1] Error 1 > It's a known problem, fixed by: > > http://patchwork.ozlabs.org/linuxppc/patch?id=16491 But begs the question, why is the linker lying to use about vecemu.c using devices_subsys? 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 signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [-mm PATCH] updates for hotplug memory remove
> > Have you ever tested hotadd(probe) of the removed memory? > > Yes. I did. In my touch testing, I was able to remove memory and add > it back to the system without any issues. Oh, really!? > But again, I didn't force > the system to use that memory :( Ah..OK. > > > I'm afraid there are some differences of the status between pre hot-add > > section and the removed section by this patch. I think the mem_section of > > removed memory should be invalidated at least. > > I think its a generic issue. Nothing specific for ppc64. Isn't it ? Right. Currently, our machine doesn't have real physical remove feature yet. (only add). So, I think testing is not enough around physical removing. Probably, your box will be first one which can remove physical memory with Linux. It is good for testing. If you notice anything, please let me know. :-) Bye. -- Yasunori Goto ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 8/8] Cell IOMMU fixed mapping support
On Wed, Jan 30, 2008 at 01:54:01AM +0100, Arnd Bergmann wrote: > I don't see how it should be possible here to reuse the 2-4GB range > for anything else. Right, that was obvious after Ben's reply as well. Michael's description made me think the linear mapping was at bus address 2G when it wasn't. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc64 vecemu compile failure
Hi, On Wed, Jan 30, 2008 at 01:03:37AM +0100, maximilian attems wrote: > on latest git since driver subsys merge on powerpc64: > > arch/powerpc/kernel/built-in.o: In function `fphalf': > vecemu.c:(.toc+0x1360): undefined reference to `devices_subsys' > make[3]: *** [.tmp_vmlinux1] Error 1 It's a known problem, fixed by: http://patchwork.ozlabs.org/linuxppc/patch?id=16491 -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 8/8] Cell IOMMU fixed mapping support
On Tuesday 29 January 2008, Olof Johansson wrote: > > > > Shouldn't the fixed mapping be between 4G and 8G (and the offset for 1G > > > is at 5G), to account for the MMIO range at 2-4G? > > > > I don't think so, ie. it works setup like that, but I'm not entirely > > sure why. Presumably the 2-4GB for MMIO is only for cycles heading out > > of the CPU. > > Ben denied that being so yesterday. :-) > > If that's the case, then you can stick the dynamic range there for >32GB > configs, since it's still addressable with 32 bits. > For addresses going from the CPU to the bus, RAM is occupying everything from zero to SIZE_OF_RAM, while PCI MMIO starts at LARGE_NUMBER+2GB. As seen from the PCI bus, DMA addresses for RAM range from zero to 2GB, while the MMIO space is between 2GB and 4GB. The 64 bit space for the linear mapping is between EVEN_LARGER_NUMBER and EVEN_LARGER_NUMBER+SIZE_OF_RAM. The bridge chip remaps EVEN_LARGER_NUMBER to zero when going into the IOMMU, so that the IOMMU can fit both SIZE_OF_RAM and the dynamic DMA window into the 32GB bus address range. I don't see how it should be possible here to reuse the 2-4GB range for anything else. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [-mm PATCH] updates for hotplug memory remove
On Tue, 2008-01-29 at 14:18 +0900, Yasunori Goto wrote:
> Hello. Badari-san.
>
> Is your patch for notification the event of removing to firmware, right?
Correct.
>
> Have you ever tested hotadd(probe) of the removed memory?
Yes. I did. In my touch testing, I was able to remove memory and add
it back to the system without any issues. But again, I didn't force
the system to use that memory :(
> I'm afraid there are some differences of the status between pre hot-add
> section and the removed section by this patch. I think the mem_section of
> removed memory should be invalidated at least.
I think its a generic issue. Nothing specific for ppc64. Isn't it ?
Thanks,
Badari
>
> But anyway, this is a great first step for physical memory remove.
>
> Thanks.
>
>
> > On Mon, 2008-01-28 at 16:31 -0800, Badari Pulavarty wrote:
> >
> >
> > > 2) Can you replace the following patch with this ?
> > >
> > > add-remove_memory-for-ppc64-2.patch
> > >
> > > I found that, I do need arch-specific hooks to get the memory remove
> > > working on ppc64 LPAR. Earlier, I tried to make remove_memory() arch
> > > neutral, but we do need arch specific hooks.
> > >
> > > Thanks,
> > > Badari
> >
> > Andrew,
> >
> > Here is the patch which provides arch-specific code to complete memory
> > remove on ppc64 LPAR. So far, it works fine in my testing - but waiting
> > for ppc-experts for review and completeness.
> >
> > FYI.
> >
> > Thanks,
> > Badari
> >
> > For memory remove, we need to clean up htab mappings for the
> > section of the memory we are removing.
> >
> > This patch implements support for removing htab bolted mappings
> > for ppc64 lpar. Other sub-archs, may need to implement similar
> > functionality for the hotplug memory remove to work.
> >
> > Signed-off-by: Badari Pulavarty <[EMAIL PROTECTED]>
> > ---
> > arch/powerpc/mm/hash_utils_64.c | 23 +++
> > arch/powerpc/mm/mem.c |4 +++-
> > arch/powerpc/platforms/pseries/lpar.c | 15 +++
> > include/asm-powerpc/machdep.h |2 ++
> > include/asm-powerpc/sparsemem.h |1 +
> > 5 files changed, 44 insertions(+), 1 deletion(-)
> >
> > Index: linux-2.6.24-rc8/arch/powerpc/mm/hash_utils_64.c
> > ===
> > --- linux-2.6.24-rc8.orig/arch/powerpc/mm/hash_utils_64.c 2008-01-25
> > 08:04:32.0 -0800
> > +++ linux-2.6.24-rc8/arch/powerpc/mm/hash_utils_64.c2008-01-28
> > 11:45:40.0 -0800
> > @@ -191,6 +191,24 @@ int htab_bolt_mapping(unsigned long vsta
> > return ret < 0 ? ret : 0;
> > }
> >
> > +static void htab_remove_mapping(unsigned long vstart, unsigned long vend,
> > + int psize, int ssize)
> > +{
> > + unsigned long vaddr;
> > + unsigned int step, shift;
> > +
> > + shift = mmu_psize_defs[psize].shift;
> > + step = 1 << shift;
> > +
> > + if (!ppc_md.hpte_removebolted) {
> > + printk("Sub-arch doesn't implement hpte_removebolted\n");
> > + return;
> > + }
> > +
> > + for (vaddr = vstart; vaddr < vend; vaddr += step)
> > + ppc_md.hpte_removebolted(vaddr, psize, ssize);
> > +}
> > +
> > static int __init htab_dt_scan_seg_sizes(unsigned long node,
> > const char *uname, int depth,
> > void *data)
> > @@ -436,6 +454,11 @@ void create_section_mapping(unsigned lon
> > _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX,
> > mmu_linear_psize, mmu_kernel_ssize));
> > }
> > +
> > +void remove_section_mapping(unsigned long start, unsigned long end)
> > +{
> > + htab_remove_mapping(start, end, mmu_linear_psize, mmu_kernel_ssize);
> > +}
> > #endif /* CONFIG_MEMORY_HOTPLUG */
> >
> > static inline void make_bl(unsigned int *insn_addr, void *func)
> > Index: linux-2.6.24-rc8/include/asm-powerpc/sparsemem.h
> > ===
> > --- linux-2.6.24-rc8.orig/include/asm-powerpc/sparsemem.h 2008-01-15
> > 20:22:48.0 -0800
> > +++ linux-2.6.24-rc8/include/asm-powerpc/sparsemem.h2008-01-25
> > 08:18:11.0 -0800
> > @@ -20,6 +20,7 @@
> >
> > #ifdef CONFIG_MEMORY_HOTPLUG
> > extern void create_section_mapping(unsigned long start, unsigned long end);
> > +extern void remove_section_mapping(unsigned long start, unsigned long end);
> > #ifdef CONFIG_NUMA
> > extern int hot_add_scn_to_nid(unsigned long scn_addr);
> > #else
> > Index: linux-2.6.24-rc8/arch/powerpc/mm/mem.c
> > ===
> > --- linux-2.6.24-rc8.orig/arch/powerpc/mm/mem.c 2008-01-25
> > 08:16:37.0 -0800
> > +++ linux-2.6.24-rc8/arch/powerpc/mm/mem.c 2008-01-25 08:20:33.0
> > -0800
> > @@ -156,7 +156,9 @@ int remove_memory(u64 start, u64 size)
> > ret = offline_pages(start_pfn, end_pfn, 120
ppc64 vecemu compile failure
on latest git since driver subsys merge on powerpc64: arch/powerpc/kernel/built-in.o: In function `fphalf': vecemu.c:(.toc+0x1360): undefined reference to `devices_subsys' make[3]: *** [.tmp_vmlinux1] Error 1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 8/8] Cell IOMMU fixed mapping support
This patch adds support for setting up a fixed IOMMU mapping on certain
cell machines. For 64-bit devices this avoids the performance overhead of
mapping and unmapping pages at runtime. 32-bit devices are unable to use
the fixed mapping.
The fixed mapping is established at boot, and maps all of physical memory
1:1 into device space at some offset. On machines with < 30 GB of memory
we setup the fixed mapping immediately above the normal IOMMU window.
For example a machine with 4GB of memory would end up with the normal
IOMMU window from 0-2GB and the fixed mapping window from 2GB to 6GB. In
this case a 64-bit device wishing to DMA to 1GB would be told to DMA to
3GB, plus any offset required by firmware. The firmware offset is encoded
in the "dma-ranges" property.
On machines with 30GB or more of memory, we are unable to place the fixed
mapping above the normal IOMMU window as we would run out of address space.
Instead we move the normal IOMMU window to coincide with the hash page
table, this region does not need to be part of the fixed mapping as no
device should ever be DMA'ing to it. We then setup the fixed mapping
from 0 to 32GB.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iommu.c | 269 ++-
1 files changed, 267 insertions(+), 2 deletions(-)
Updated to include a description in the file.
diff --git a/arch/powerpc/platforms/cell/iommu.c
b/arch/powerpc/platforms/cell/iommu.c
index 3baade1..68274a0 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -1,7 +1,7 @@
/*
* IOMMU implementation for Cell Broadband Processor Architecture
*
- * (C) Copyright IBM Corporation 2006
+ * (C) Copyright IBM Corporation 2006-2008
*
* Author: Jeremy Kerr <[EMAIL PROTECTED]>
*
@@ -523,6 +523,9 @@ static struct cbe_iommu *cell_iommu_for_node(int nid)
static unsigned long cell_dma_direct_offset;
+static unsigned long dma_iommu_fixed_base;
+struct dma_mapping_ops dma_iommu_fixed_ops;
+
static void cell_dma_dev_setup_iommu(struct device *dev)
{
struct iommu_window *window;
@@ -545,11 +548,16 @@ static void cell_dma_dev_setup_iommu(struct device *dev)
archdata->dma_data = &window->table;
}
+static void cell_dma_dev_setup_static(struct device *dev);
+
static void cell_dma_dev_setup(struct device *dev)
{
struct dev_archdata *archdata = &dev->archdata;
- if (get_pci_dma_ops() == &dma_iommu_ops)
+ /* Order is important here, these are not mutually exclusive */
+ if (get_dma_ops(dev) == &dma_iommu_fixed_ops)
+ cell_dma_dev_setup_static(dev);
+ else if (get_pci_dma_ops() == &dma_iommu_ops)
cell_dma_dev_setup_iommu(dev);
else if (get_pci_dma_ops() == &dma_direct_ops)
archdata->dma_data = (void *)cell_dma_direct_offset;
@@ -752,6 +760,260 @@ static int __init cell_iommu_init_disabled(void)
return 0;
}
+/*
+ * Fixed IOMMU mapping support
+ *
+ * This code adds support for setting up a fixed IOMMU mapping on certain
+ * cell machines. For 64-bit devices this avoids the performance overhead of
+ * mapping and unmapping pages at runtime. 32-bit devices are unable to use
+ * the fixed mapping.
+ *
+ * The fixed mapping is established at boot, and maps all of physical memory
+ * 1:1 into device space at some offset. On machines with < 30 GB of memory
+ * we setup the fixed mapping immediately above the normal IOMMU window.
+ *
+ * For example a machine with 4GB of memory would end up with the normal
+ * IOMMU window from 0-2GB and the fixed mapping window from 2GB to 6GB. In
+ * this case a 64-bit device wishing to DMA to 1GB would be told to DMA to
+ * 3GB, plus any offset required by firmware. The firmware offset is encoded
+ * in the "dma-ranges" property.
+ *
+ * On machines with 30GB or more of memory, we are unable to place the fixed
+ * mapping above the normal IOMMU window as we would run out of address space.
+ * Instead we move the normal IOMMU window to coincide with the hash page
+ * table, this region does not need to be part of the fixed mapping as no
+ * device should ever be DMA'ing to it. We then setup the fixed mapping
+ * from 0 to 32GB.
+ */
+
+static u64 cell_iommu_get_fixed_address(struct device *dev)
+{
+ u64 cpu_addr, size, best_size, pci_addr = OF_BAD_ADDR;
+ struct device_node *tmp, *np;
+ const u32 *ranges = NULL;
+ int i, len, best;
+
+ np = dev->archdata.of_node;
+ of_node_get(np);
+ ranges = of_get_property(np, "dma-ranges", &len);
+ while (!ranges && np) {
+ tmp = of_get_parent(np);
+ of_node_put(np);
+ np = tmp;
+ ranges = of_get_property(np, "dma-ranges", &len);
+ }
+
+ if (!ranges) {
+ dev_dbg(dev, "iommu: no dma-ranges found\n");
+ goto out;
+ }
+
+ len /= sizeof(u32);
+
+ /*
Re: [PATCH 8/8] Cell IOMMU fixed mapping support
On Tue, 2008-01-29 at 15:36 -0600, Olof Johansson wrote: > On Wed, Jan 30, 2008 at 08:18:15AM +1100, Benjamin Herrenschmidt wrote: > > > > On Wed, 2008-01-30 at 02:13 +1100, Michael Ellerman wrote: > > > On Tue, 2008-01-29 at 09:15 -0600, Olof Johansson wrote: > > > > On Wed, Jan 30, 2008 at 01:14:03AM +1100, Michael Ellerman wrote: > > > > > > > > > For example a machine with 4GB of memory would end up with the normal > > > > > IOMMU window from 0-2GB and the fixed mapping window from 2GB to 6GB. > > > > > In > > > > > this case a 64-bit device wishing to DMA to 1GB would be told to DMA > > > > > to > > > > > 3GB, plus any offset required by firmware. The firmware offset is > > > > > encoded > > > > > in the "dma-ranges" property. > > > > > > > > Shouldn't the fixed mapping be between 4G and 8G (and the offset for 1G > > > > is at 5G), to account for the MMIO range at 2-4G? > > > > > > I don't think so, ie. it works setup like that, but I'm not entirely > > > sure why. Presumably the 2-4GB for MMIO is only for cycles heading out > > > of the CPU. > > > > No no no... it's because on the PCI segment, it's all offset up > > remember ? > > > > Basically, the PCI host bridge on these has 2 interesting windows for > > us: > > > > 02G -> This goes up to memory @0 (via a couple of > >layers) > > > > 0x80*0xF* -> This goes untranslated to the PLB5 which > >drops the top bits and does some other > >manipulations, which allows to access, among > >others the full 32GB of the cell inbound > >range. > > > > The MMIO region of 2...4G is on the PCI (outbound from the Cell is yet > > another range of addresses with different constraints but that ends up > > generating cycles between 2 and 4G on the PCI segment). > > > > If we had set the direct mapped region so that it uses 2G...N on PCI, we > > would indeed be toast. But instead, the addresses for direct DMA that we > > hand out to devices are in the 0x80* region and go hit the cell > > directly, they never match MMIO. > > Yeah, ok. That makes more sense. Thanks for the clarification. Right, that's the firmware offset I mentioned in the changelog - 2am is not a good time to think about these things. > Michael, btw, I wonder if it would make sense to duplicate the patch > description at the top of the file as well, since it'll be lost in the > change log for people who don't go back and read history, and having > the intentions documented in the file could be a good idea. Yeah that probably makes sense. I've got most of the fixed mapping code in a block, so I'll put a comment above that section. New patch coming. 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 signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 8/8] Cell IOMMU fixed mapping support
On Wed, Jan 30, 2008 at 08:18:15AM +1100, Benjamin Herrenschmidt wrote: > > On Wed, 2008-01-30 at 02:13 +1100, Michael Ellerman wrote: > > On Tue, 2008-01-29 at 09:15 -0600, Olof Johansson wrote: > > > On Wed, Jan 30, 2008 at 01:14:03AM +1100, Michael Ellerman wrote: > > > > > > > For example a machine with 4GB of memory would end up with the normal > > > > IOMMU window from 0-2GB and the fixed mapping window from 2GB to 6GB. In > > > > this case a 64-bit device wishing to DMA to 1GB would be told to DMA to > > > > 3GB, plus any offset required by firmware. The firmware offset is > > > > encoded > > > > in the "dma-ranges" property. > > > > > > Shouldn't the fixed mapping be between 4G and 8G (and the offset for 1G > > > is at 5G), to account for the MMIO range at 2-4G? > > > > I don't think so, ie. it works setup like that, but I'm not entirely > > sure why. Presumably the 2-4GB for MMIO is only for cycles heading out > > of the CPU. > > No no no... it's because on the PCI segment, it's all offset up > remember ? > > Basically, the PCI host bridge on these has 2 interesting windows for > us: > > 02G -> This goes up to memory @0 (via a couple of >layers) > > 0x80*0xF* -> This goes untranslated to the PLB5 which > drops the top bits and does some other >manipulations, which allows to access, among >others the full 32GB of the cell inbound >range. > > The MMIO region of 2...4G is on the PCI (outbound from the Cell is yet > another range of addresses with different constraints but that ends up > generating cycles between 2 and 4G on the PCI segment). > > If we had set the direct mapped region so that it uses 2G...N on PCI, we > would indeed be toast. But instead, the addresses for direct DMA that we > hand out to devices are in the 0x80* region and go hit the cell > directly, they never match MMIO. Yeah, ok. That makes more sense. Thanks for the clarification. Michael, btw, I wonder if it would make sense to duplicate the patch description at the top of the file as well, since it'll be lost in the change log for people who don't go back and read history, and having the intentions documented in the file could be a good idea. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 8/8] Cell IOMMU fixed mapping support
On Wed, 2008-01-30 at 02:13 +1100, Michael Ellerman wrote: > On Tue, 2008-01-29 at 09:15 -0600, Olof Johansson wrote: > > On Wed, Jan 30, 2008 at 01:14:03AM +1100, Michael Ellerman wrote: > > > > > For example a machine with 4GB of memory would end up with the normal > > > IOMMU window from 0-2GB and the fixed mapping window from 2GB to 6GB. In > > > this case a 64-bit device wishing to DMA to 1GB would be told to DMA to > > > 3GB, plus any offset required by firmware. The firmware offset is encoded > > > in the "dma-ranges" property. > > > > Shouldn't the fixed mapping be between 4G and 8G (and the offset for 1G > > is at 5G), to account for the MMIO range at 2-4G? > > I don't think so, ie. it works setup like that, but I'm not entirely > sure why. Presumably the 2-4GB for MMIO is only for cycles heading out > of the CPU. No no no... it's because on the PCI segment, it's all offset up remember ? Basically, the PCI host bridge on these has 2 interesting windows for us: 02G -> This goes up to memory @0 (via a couple of layers) 0x80*0xF* -> This goes untranslated to the PLB5 which drops the top bits and does some other manipulations, which allows to access, among others the full 32GB of the cell inbound range. The MMIO region of 2...4G is on the PCI (outbound from the Cell is yet another range of addresses with different constraints but that ends up generating cycles between 2 and 4G on the PCI segment). If we had set the direct mapped region so that it uses 2G...N on PCI, we would indeed be toast. But instead, the addresses for direct DMA that we hand out to devices are in the 0x80* region and go hit the cell directly, they never match MMIO. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PATCH[1/1] 8xx: Add clock-frequency to .dts brg entries
On Tue, 2008-01-29 at 10:26 -0600, Scott Wood wrote: > On Mon, Jan 28, 2008 at 11:55:20PM +, Bryan O'Donoghue wrote: > > You mean that arch/powerpc/boot/mpc8xx.c mpc8xx_set_clocks is supposed > > to be adding this field ? > > Yes. Or u-boot, if you're not using the bootwrapper/cuImage. Indeed - I have some patches to send to the u-boot mailing list to cover manipulation of the "fsl,cpm-brg" "clock-frequency" entry. The previously sent patch will allow Linux to print stuff out the UART will the default brgclk - from a uImage and is the field that a future u-boot patchset would want to manipulate in order to tell Linux about the brgclk it should have. I should be a bit clearer about that... > > > I see arch/powerpc/boot/wrapper.a has a reference to the function but - > > and this time I've checked all documentation - there's no mention of how > > to use this library at all... it _looks_ to me like this isn't being > > linked in any way. > > > > It for sure is nowhere in the uImage - and I've taken the preferred > > route of making a uImage with .dtb - genreated from adder875-uboot.dts > > In that case, u-boot needs to add that property. See above. > > dtc -O -o adder875-uboot.dtb arch/powerpc/boot/dts/adder875-uboot.dtb > > You'll want to use the -p option to add some extra space for u-boot to > use. Interesting - the u-boot end of this patch is something I'm still messing about with ... but, the addition of the default brgclk to the Linux dts is a useful addition - and AFAICT will be needed to allow a bootloader to manipulate the dts so that Linux will get the right brgclk. > > cpm_uart depends on "fsl,cpm-brg" and a field called "clock-frequency" > > > > as I understand it that's > > > > fsl,cpm-brg > > |_clock-frequency > > > > whereas mpc8xx_set_clocks seems to add > > > > /soc/cpm/brg > > |_clock-frequency > > The fsl,cpm-brg refers to the compatible property, not the node name. Indeed and the get_brgclk does a find_compatible() lookup of some sort... so I think that means this is the right field to add to allow a bootloader to manipulate the brgclk ... it's what the other stuff in u-boot for the mpc8xxx stuff does, so it follows to do the same thing for 8xx too. > > mpc866ads.dts - also has a "fsl,cpm-brg" => clock-frequency entry in > > > > linux/arch/powerpc/boot/dts/mpc866ads.dts - and to me this looks like > > the correct approach for get_brgfreq to function properly... > > And it's zero, meaning that you still need u-boot or the bootwrapper to > fill in the correct value. Indeed - I'm hoping I won't have too much trouble getting those patches applied... ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] 82xx: MGCOGE support
On Tue, Jan 29, 2008 at 01:24:54PM -0600, Scott Wood wrote: > On Tue, Jan 29, 2008 at 11:22:55AM +0100, Heiko Schocher wrote: > > + *pram_base = res.start; > > First of all, use out_be32() rather than direct dereferencing. Err, I meant out_be16() of course. :-P -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] 82xx: MGCOGE support
Scott Wood wrote: >> +// Temporary -- will go away once kernel uses ranges for >> get_immrbase(). >> +reg = <0xf000 0x00053000>; > > The patch to use ranges for get_immrbase() just went in, so we can drop this > now. Most excellent. Time for YARDS -- Yet Another Rounds of DTS Scrubbing. jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] 82xx: MGCOGE support
On Tue, Jan 29, 2008 at 11:22:55AM +0100, Heiko Schocher wrote:
> To get the serial console on the SMC2 working, the
> following patch is needed:
>
> Fixing serial console on a SMC on MPC82xx based
> board and using CONFIG_PPC_CPM_NEW_BINDING
No, what's needed is for the device tree to be correct (see my comments on
that patch).
> + u16 __iomem *pram_base;
> + struct resource res;
> +
> pinfo->flags |= FLAG_SMC;
> pinfo->smcp = mem;
> pinfo->smcup = pram;
> +
> + if (of_address_to_resource(np, 1, &res)) {
> + ret = -ENOMEM;
> + goto out_pram;
> + }
> + pram_base = of_iomap(np, 2);
> + if (!pram_base) {
> + ret = -ENOMEM;
> + goto out_pram;
> + }
> + *pram_base = res.start;
First of all, use out_be32() rather than direct dereferencing.
Secondly, is it possible for things to get messed up if the SMC registers
were set somewhere else by the bootloader, and that area was previously
allocated by Linux for some other purpose, and the SMC updated the parameter
RAM and corrupted that other purpose? Especially if we have early debug
enabled, and thus don't reset the CPM on boot (or worse, are actively using
it prior to register relocation).
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/4] 82xx: MGCOGE support
On Tue, Jan 29, 2008 at 11:22:41AM +0100, Heiko Schocher wrote:
> + model = "MGCOGE";
> + compatible = "fsl,mgcoge";
keymile,mgcoge
> + PowerPC,[EMAIL PROTECTED] {
[snip]
> + compatible = "fsl,mpc8248-localbus",
All of these 8248s should be 8247.
> + // Temporary -- will go away once kernel uses ranges for
> get_immrbase().
> + reg = <0xf000 0x00053000>;
The patch to use ranges for get_immrbase() just went in, so we can drop this
now.
> + [EMAIL PROTECTED] {
> + compatible = "fsl,cpm-muram-data";
> + reg = <0 0x1100 0x1140
> +0xec0 0x9800 0x800>;
This doesn't look right. You're excluding 0x40 bytes at 0x1100, which is
where planetcore puts SMC1. However, you're using SMC2 -- and I'm guessing
aren't using planetcore, since this isn't an embedded planet board.
If you're using u-boot, this should be:
reg = <0x80 0x1f80 0x9800 0x800>;
> + /* Monitor port/SMC2 */
> + smc2: [EMAIL PROTECTED] {
> + device_type = "serial";
> + compatible = "fsl,mpc8248-smc-uart",
> + "fsl,cpm2-smc-uart";
> + reg = <0x11a90 0x20 0x1100 0x40 0x88fc 4>;
If you're using u-boot, this should be <0x11a90 0x20 0x40 0x40>.
> + current-speed = <0x1c200>;
This should be decimal.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/3] 82xx: MGCOGE support
On Tue, Jan 29, 2008 at 11:20:24AM +0100, Heiko Schocher wrote: > the following 4 patches adding support for the MPC8247 > based board MGCOGE from keymile. Please use descriptive subject lines, rather than the same one for each patch in the series. Also, the first three patches could be combined into one. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PATCH[1/1] 8xx: Add clock-frequency to .dts brg entries
On Mon, Jan 28, 2008 at 11:55:20PM +, Bryan O'Donoghue wrote: > You mean that arch/powerpc/boot/mpc8xx.c mpc8xx_set_clocks is supposed > to be adding this field ? Yes. Or u-boot, if you're not using the bootwrapper/cuImage. > I see arch/powerpc/boot/wrapper.a has a reference to the function but - > and this time I've checked all documentation - there's no mention of how > to use this library at all... it _looks_ to me like this isn't being > linked in any way. > > It for sure is nowhere in the uImage - and I've taken the preferred > route of making a uImage with .dtb - genreated from adder875-uboot.dts In that case, u-boot needs to add that property. > dtc -O -o adder875-uboot.dtb arch/powerpc/boot/dts/adder875-uboot.dtb You'll want to use the -p option to add some extra space for u-boot to use. > cpm_uart depends on "fsl,cpm-brg" and a field called "clock-frequency" > > as I understand it that's > > fsl,cpm-brg > |_clock-frequency > > whereas mpc8xx_set_clocks seems to add > > /soc/cpm/brg > |_clock-frequency The fsl,cpm-brg refers to the compatible property, not the node name. > mpc866ads.dts - also has a "fsl,cpm-brg" => clock-frequency entry in > > linux/arch/powerpc/boot/dts/mpc866ads.dts - and to me this looks like > the correct approach for get_brgfreq to function properly... And it's zero, meaning that you still need u-boot or the bootwrapper to fill in the correct value. The only difference is whether there's a placeholder property -- they used to be required by older u-boots, but are no longer necessary. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
PCI configuration with multiple PCI controllers
Hello, I have a MPC8641 based board. I try to use the two PCIe controllers. My firmware configures (physically) the PCI buses as follow: --+ MPC8641 PCIe 1 | bus 1 +--+ | --> | PCI device 0 | BUS 0 | +--+ - - - - - - - - - + MPC8641 PCIe 2 | bus 3 +--+ | --> | PCI device 1 | BUS 2 | +--+ --+ I launch the Linux image (2.6.23.9). During the Kernel PCI configuration, buses behind the 2nd MPC8641 PCIe are skipped because its primary bus don't start at bus number 0. The kernel reconfigure the primary bus number of the MPC8641 PCIe 2 controller from 2 to 0. I can patch the kernel to work with my firmware but I don't know if my PCI configuration is the good one. What is the common way to configure the PCI for Linux when a new controller is found: start the bus number to 0 or to the last bus number + 1? Regards ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 8/8] Cell IOMMU fixed mapping support
On Wed, Jan 30, 2008 at 02:13:45AM +1100, Michael Ellerman wrote: > On Tue, 2008-01-29 at 09:15 -0600, Olof Johansson wrote: > > On Wed, Jan 30, 2008 at 01:14:03AM +1100, Michael Ellerman wrote: > > > > > For example a machine with 4GB of memory would end up with the normal > > > IOMMU window from 0-2GB and the fixed mapping window from 2GB to 6GB. In > > > this case a 64-bit device wishing to DMA to 1GB would be told to DMA to > > > 3GB, plus any offset required by firmware. The firmware offset is encoded > > > in the "dma-ranges" property. > > > > Shouldn't the fixed mapping be between 4G and 8G (and the offset for 1G > > is at 5G), to account for the MMIO range at 2-4G? > > I don't think so, ie. it works setup like that, but I'm not entirely > sure why. Presumably the 2-4GB for MMIO is only for cycles heading out > of the CPU. Ben denied that being so yesterday. :-) If that's the case, then you can stick the dynamic range there for >32GB configs, since it's still addressable with 32 bits. -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch v6 3/4] USB: add Cypress c67x00 OTG controller HCD driver
On Tue, 29 Jan 2008, Peter Korsgaard wrote:
> This patch adds HCD support for the Cypress c67x00 family of devices.
> --- /dev/null
> +++ linux-2.6/drivers/usb/c67x00/c67x00-hcd.c
> +int c67x00_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status)
> +{
> + struct c67x00_hcd *c67x00 = hcd_to_c67x00_hcd(hcd);
> + unsigned long flags;
> + int rc;
> +
> + spin_lock_irqsave(&c67x00->lock, flags);
> + rc = usb_hcd_check_unlink_urb(hcd, urb, status);
> + if (rc)
> + goto done;
> +
> + c67x00_release_urb(c67x00, urb);
> + usb_hcd_unlink_urb_from_ep(hcd, urb);
> + spin_unlock_irqrestore(&c67x00->lock, flags);
> +
> + usb_hcd_giveback_urb(hcd, urb, status);
This is wrong. usb_hcd_giveback_urb() must be called with local
interrupts disabled.
> +/*
> + * pre: urb != NULL and c67x00 locked, urb unlocked
> + */
> +static inline void
> +c67x00_giveback_urb(struct c67x00_hcd *c67x00, struct urb *urb, int status)
> +{
> + struct c67x00_urb_priv *urbp;
> +
> + if (!urb)
> + return;
Since you have the documented precondition that urb != NULL, and since
this routine is never called in a context where urb could be NULL,
there's no need for this test. Also, I doubt that this routine really
needs to be inline (and besides, the compiler is better at making such
decisions than we are).
> +static void c67x00_sched_done(unsigned long __c67x00)
> +{
> + struct c67x00_hcd *c67x00 = (struct c67x00_hcd *)__c67x00;
> + struct c67x00_urb_priv *urbp, *tmp;
> + struct urb *urb;
> +
> + spin_lock(&c67x00->lock);
> +
> + /* Loop over the done list and give back all the urbs */
> + list_for_each_entry_safe(urbp, tmp, &c67x00->done_list, hep_node) {
> + urb = urbp->urb;
> + c67x00_release_urb(c67x00, urb);
> + if (!usb_hcd_check_unlink_urb(c67x00_hcd_to_hcd(c67x00),
> + urb, urbp->status)) {
The function call above is completely wrong. It is meant to be used only
from within the dequeue method.
> + usb_hcd_unlink_urb_from_ep(c67x00_hcd_to_hcd(c67x00),
> +urb);
> + spin_unlock(&c67x00->lock);
> + usb_hcd_giveback_urb(c67x00_hcd_to_hcd(c67x00), urb,
> + urbp->status);
> + spin_lock(&c67x00->lock);
> + }
> + }
> + spin_unlock(&c67x00->lock);
> +}
Is there some reason this routine needs to run in a tasklet? Why not
just call it directly?
Also, the fact that it is in a tasklet means that it runs with
interrupts enabled. Hence your spin_lock() and spin_unlock() calls
will not do the right thing.
Alan Stern
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 8/8] Cell IOMMU fixed mapping support
On Tue, 2008-01-29 at 09:15 -0600, Olof Johansson wrote: > On Wed, Jan 30, 2008 at 01:14:03AM +1100, Michael Ellerman wrote: > > > For example a machine with 4GB of memory would end up with the normal > > IOMMU window from 0-2GB and the fixed mapping window from 2GB to 6GB. In > > this case a 64-bit device wishing to DMA to 1GB would be told to DMA to > > 3GB, plus any offset required by firmware. The firmware offset is encoded > > in the "dma-ranges" property. > > Shouldn't the fixed mapping be between 4G and 8G (and the offset for 1G > is at 5G), to account for the MMIO range at 2-4G? I don't think so, ie. it works setup like that, but I'm not entirely sure why. Presumably the 2-4GB for MMIO is only for cycles heading out of the CPU. 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 signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 8/8] Cell IOMMU fixed mapping support
On Wed, Jan 30, 2008 at 01:14:03AM +1100, Michael Ellerman wrote: > For example a machine with 4GB of memory would end up with the normal > IOMMU window from 0-2GB and the fixed mapping window from 2GB to 6GB. In > this case a 64-bit device wishing to DMA to 1GB would be told to DMA to > 3GB, plus any offset required by firmware. The firmware offset is encoded > in the "dma-ranges" property. Shouldn't the fixed mapping be between 4G and 8G (and the offset for 1G is at 5G), to account for the MMIO range at 2-4G? -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][ppc] logical/bitand typo in powerpc/boot/4xx.c
Josh Boyer wrote:
> On Wed, 23 Jan 2008 23:37:33 +0100
> Roel Kluin <[EMAIL PROTECTED]> wrote:
>
>> logical/bitand typo
>>
>> Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
>> ---
>> diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
>> index ebf9e21..dcfb459 100644
>> --- a/arch/powerpc/boot/4xx.c
>> +++ b/arch/powerpc/boot/4xx.c
>> @@ -104,7 +104,7 @@ void ibm4xx_denali_fixup_memsize(void)
>> val = DDR_GET_VAL(val, DDR_CS_MAP, DDR_CS_MAP_SHIFT);
>> cs = 0;
>> while (val) {
>> -if (val && 0x1)
>> +if (val & 0x1)
>> cs++;
>> val = val >> 1;
>> }
>
> Hm, good catch.
Yes, thanks!
Sequoia and Rainier are currently the only boards using denali
controller and have both chipselects enabled (val = 0x3).
In this case the problem doesn't show up and we still get the right cs
value.
Thanks,
Valentine.
>
> Stefan, have you had problems with this code at all?
>
> josh
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 8/8] Cell IOMMU fixed mapping support
This patch adds support for setting up a fixed IOMMU mapping on certain
cell machines. For 64-bit devices this avoids the performance overhead of
mapping and unmapping pages at runtime. 32-bit devices are unable to use
the fixed mapping.
The fixed mapping is established at boot, and maps all of physical memory
1:1 into device space at some offset. On machines with < 30 GB of memory
we setup the fixed mapping immediately above the normal IOMMU window.
For example a machine with 4GB of memory would end up with the normal
IOMMU window from 0-2GB and the fixed mapping window from 2GB to 6GB. In
this case a 64-bit device wishing to DMA to 1GB would be told to DMA to
3GB, plus any offset required by firmware. The firmware offset is encoded
in the "dma-ranges" property.
On machines with 30GB or more of memory, we are unable to place the fixed
mapping above the normal IOMMU window as we would run out of address space.
Instead we move the normal IOMMU window to coincide with the hash page
table, this region does not need to be part of the fixed mapping as no
device should ever be DMA'ing to it. We then setup the fixed mapping
from 0 to 32GB.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iommu.c | 241 ++-
1 files changed, 240 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c
b/arch/powerpc/platforms/cell/iommu.c
index 3baade1..56c69cc 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -523,6 +523,9 @@ static struct cbe_iommu *cell_iommu_for_node(int nid)
static unsigned long cell_dma_direct_offset;
+static unsigned long dma_iommu_fixed_base;
+struct dma_mapping_ops dma_iommu_fixed_ops;
+
static void cell_dma_dev_setup_iommu(struct device *dev)
{
struct iommu_window *window;
@@ -545,11 +548,16 @@ static void cell_dma_dev_setup_iommu(struct device *dev)
archdata->dma_data = &window->table;
}
+static void cell_dma_dev_setup_static(struct device *dev);
+
static void cell_dma_dev_setup(struct device *dev)
{
struct dev_archdata *archdata = &dev->archdata;
- if (get_pci_dma_ops() == &dma_iommu_ops)
+ /* Order is important here, these are not mutually exclusive */
+ if (get_dma_ops(dev) == &dma_iommu_fixed_ops)
+ cell_dma_dev_setup_static(dev);
+ else if (get_pci_dma_ops() == &dma_iommu_ops)
cell_dma_dev_setup_iommu(dev);
else if (get_pci_dma_ops() == &dma_direct_ops)
archdata->dma_data = (void *)cell_dma_direct_offset;
@@ -752,6 +760,234 @@ static int __init cell_iommu_init_disabled(void)
return 0;
}
+static u64 cell_iommu_get_fixed_address(struct device *dev)
+{
+ u64 cpu_addr, size, best_size, pci_addr = OF_BAD_ADDR;
+ struct device_node *tmp, *np;
+ const u32 *ranges = NULL;
+ int i, len, best;
+
+ np = dev->archdata.of_node;
+ of_node_get(np);
+ ranges = of_get_property(np, "dma-ranges", &len);
+ while (!ranges && np) {
+ tmp = of_get_parent(np);
+ of_node_put(np);
+ np = tmp;
+ ranges = of_get_property(np, "dma-ranges", &len);
+ }
+
+ if (!ranges) {
+ dev_dbg(dev, "iommu: no dma-ranges found\n");
+ goto out;
+ }
+
+ len /= sizeof(u32);
+
+ /* dma-ranges format:
+* 1 cell: pci space
+* 2 cells: pci address
+* 2 cells: parent address
+* 2 cells: size
+*/
+ for (i = 0, best = -1, best_size = 0; i < len; i += 7) {
+ cpu_addr = of_translate_dma_address(np, ranges +i + 3);
+ size = of_read_number(ranges + i + 5, 2);
+
+ if (cpu_addr == 0 && size > best_size) {
+ best = i;
+ best_size = size;
+ }
+ }
+
+ if (best >= 0)
+ pci_addr = of_read_number(ranges + best + 1, 2);
+ else
+ dev_dbg(dev, "iommu: no suitable range found!\n");
+
+out:
+ of_node_put(np);
+
+ return pci_addr;
+}
+
+static int dma_set_mask_and_switch(struct device *dev, u64 dma_mask)
+{
+ if (!dev->dma_mask || !dma_supported(dev, dma_mask))
+ return -EIO;
+
+ if (dma_mask == DMA_BIT_MASK(64)) {
+ if (cell_iommu_get_fixed_address(dev) == OF_BAD_ADDR)
+ dev_dbg(dev, "iommu: 64-bit OK, but bad addr\n");
+ else {
+ dev_dbg(dev, "iommu: 64-bit OK, using fixed ops\n");
+ set_dma_ops(dev, &dma_iommu_fixed_ops);
+ cell_dma_dev_setup(dev);
+ }
+ } else {
+ dev_dbg(dev, "iommu: not 64-bit, using default ops\n");
+ set_dma_ops(dev, get_pci_dma_ops());
+ }
+
+ *dev->dma_mask = dma_mask;
+
+ return 0;
+}
+
+static void cell_dma_dev_setu
[PATCH 7/8] Split out the ioid fetching/checking logic
Split out the ioid fetching and checking logic so we can use it elsewhere
in a subsequent patch.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iommu.c | 23 +--
1 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c
b/arch/powerpc/platforms/cell/iommu.c
index 7779dbf..3baade1 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -443,25 +443,36 @@ static struct iommu_window *find_window(struct cbe_iommu
*iommu,
}
#endif
+static inline u32 cell_iommu_get_ioid(struct device_node *np)
+{
+ const u32 *ioid;
+
+ ioid = of_get_property(np, "ioid", NULL);
+ if (ioid == NULL) {
+ printk(KERN_WARNING "iommu: missing ioid for %s using 0\n",
+ np->full_name);
+ return 0;
+ }
+
+ return *ioid;
+}
+
static struct iommu_window * __init
cell_iommu_setup_window(struct cbe_iommu *iommu, struct device_node *np,
unsigned long offset, unsigned long size,
unsigned long pte_offset)
{
struct iommu_window *window;
- const unsigned int *ioid;
+ u32 ioid;
- ioid = of_get_property(np, "ioid", NULL);
- if (ioid == NULL)
- printk(KERN_WARNING "iommu: missing ioid for %s using 0\n",
- np->full_name);
+ ioid = cell_iommu_get_ioid(np);
window = kmalloc_node(sizeof(*window), GFP_KERNEL, iommu->nid);
BUG_ON(window == NULL);
window->offset = offset;
window->size = size;
- window->ioid = ioid ? *ioid : 0;
+ window->ioid = ioid;
window->iommu = iommu;
window->pte_offset = pte_offset;
--
1.5.3.7.1.g4e596e
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 6/8] Add support to cell_iommu_setup_page_tables() for multiple windows
Add support to cell_iommu_setup_page_tables() for handling two windows,
the dynamic window and the fixed window. A fixed window size of 0
indicates that there is no fixed window at all.
Currently there are no callers who pass a non-zero fixed window, but the
upcoming fixed IOMMU mapping patch will change that.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iommu.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c
b/arch/powerpc/platforms/cell/iommu.c
index e9769fc..7779dbf 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -307,14 +307,19 @@ static int cell_iommu_find_ioc(int nid, unsigned long
*base)
}
static void cell_iommu_setup_page_tables(struct cbe_iommu *iommu,
-unsigned long base, unsigned long size)
+ unsigned long dbase, unsigned long dsize,
+ unsigned long fbase, unsigned long fsize)
{
struct page *page;
int i;
unsigned long reg, segments, pages_per_segment, ptab_size, stab_size,
- n_pte_pages;
+ n_pte_pages, base;
- segments = size >> IO_SEGMENT_SHIFT;
+ base = dbase;
+ if (fsize != 0)
+ base = min(fbase, dbase);
+
+ segments = max(dbase + dsize, fbase + fsize) >> IO_SEGMENT_SHIFT;
pages_per_segment = 1ull << IO_PAGENO_BITS;
pr_debug("%s: iommu[%d]: segments: %lu, pages per segment: %lu\n",
@@ -366,7 +371,7 @@ static void cell_iommu_setup_page_tables(struct cbe_iommu
*iommu,
}
pr_debug("Setting up IOMMU stab:\n");
- for (i = 0; i * (1ul << IO_SEGMENT_SHIFT) < size; i++) {
+ for (i = base >> IO_SEGMENT_SHIFT; i < segments; i++) {
iommu->stab[i] = reg |
(__pa(iommu->ptab) + n_pte_pages * IOMMU_PAGE_SIZE * i);
pr_debug("\t[%d] 0x%016lx\n", i, iommu->stab[i]);
@@ -417,7 +422,7 @@ static void cell_iommu_enable_hardware(struct cbe_iommu
*iommu)
static void cell_iommu_setup_hardware(struct cbe_iommu *iommu,
unsigned long base, unsigned long size)
{
- cell_iommu_setup_page_tables(iommu, base, size);
+ cell_iommu_setup_page_tables(iommu, base, size, 0, 0);
cell_iommu_enable_hardware(iommu);
}
--
1.5.3.7.1.g4e596e
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/8] Split out the IOMMU logic from cell_dma_dev_setup()
Split the IOMMU logic out from cell_dma_dev_setup() into a separate
function. If we're not using dma_direct_ops or dma_iommu_ops we don't
know what the hell's going on, so BUG.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iommu.c | 19 +--
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c
b/arch/powerpc/platforms/cell/iommu.c
index a86e5bb..e9769fc 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -507,17 +507,12 @@ static struct cbe_iommu *cell_iommu_for_node(int nid)
static unsigned long cell_dma_direct_offset;
-static void cell_dma_dev_setup(struct device *dev)
+static void cell_dma_dev_setup_iommu(struct device *dev)
{
struct iommu_window *window;
struct cbe_iommu *iommu;
struct dev_archdata *archdata = &dev->archdata;
- if (get_pci_dma_ops() == &dma_direct_ops) {
- archdata->dma_data = (void *)cell_dma_direct_offset;
- return;
- }
-
/* Current implementation uses the first window available in that
* node's iommu. We -might- do something smarter later though it may
* never be necessary
@@ -534,6 +529,18 @@ static void cell_dma_dev_setup(struct device *dev)
archdata->dma_data = &window->table;
}
+static void cell_dma_dev_setup(struct device *dev)
+{
+ struct dev_archdata *archdata = &dev->archdata;
+
+ if (get_pci_dma_ops() == &dma_iommu_ops)
+ cell_dma_dev_setup_iommu(dev);
+ else if (get_pci_dma_ops() == &dma_direct_ops)
+ archdata->dma_data = (void *)cell_dma_direct_offset;
+ else
+ BUG();
+}
+
static void cell_pci_dma_dev_setup(struct pci_dev *dev)
{
cell_dma_dev_setup(&dev->dev);
--
1.5.3.7.1.g4e596e
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/8] Split cell_iommu_setup_hardware() into two parts
Split cell_iommu_setup_hardware() into two parts. Split the page table
setup into cell_iommu_setup_page_tables() and the bits that kick the
hardware into cell_iommu_enable_hardware().
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iommu.c | 38 +++---
1 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c
b/arch/powerpc/platforms/cell/iommu.c
index 4f1ca43..a86e5bb 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -306,20 +306,13 @@ static int cell_iommu_find_ioc(int nid, unsigned long
*base)
return -ENODEV;
}
-static void cell_iommu_setup_hardware(struct cbe_iommu *iommu, unsigned long
size)
+static void cell_iommu_setup_page_tables(struct cbe_iommu *iommu,
+unsigned long base, unsigned long size)
{
struct page *page;
- int ret, i;
+ int i;
unsigned long reg, segments, pages_per_segment, ptab_size, stab_size,
- n_pte_pages, xlate_base;
- unsigned int virq;
-
- if (cell_iommu_find_ioc(iommu->nid, &xlate_base))
- panic("%s: missing IOC register mappings for node %d\n",
- __FUNCTION__, iommu->nid);
-
- iommu->xlate_regs = ioremap(xlate_base, IOC_Reg_Size);
- iommu->cmd_regs = iommu->xlate_regs + IOC_IOCmd_Offset;
+ n_pte_pages;
segments = size >> IO_SEGMENT_SHIFT;
pages_per_segment = 1ull << IO_PAGENO_BITS;
@@ -378,6 +371,20 @@ static void cell_iommu_setup_hardware(struct cbe_iommu
*iommu, unsigned long siz
(__pa(iommu->ptab) + n_pte_pages * IOMMU_PAGE_SIZE * i);
pr_debug("\t[%d] 0x%016lx\n", i, iommu->stab[i]);
}
+}
+
+static void cell_iommu_enable_hardware(struct cbe_iommu *iommu)
+{
+ int ret;
+ unsigned long reg, xlate_base;
+ unsigned int virq;
+
+ if (cell_iommu_find_ioc(iommu->nid, &xlate_base))
+ panic("%s: missing IOC register mappings for node %d\n",
+ __FUNCTION__, iommu->nid);
+
+ iommu->xlate_regs = ioremap(xlate_base, IOC_Reg_Size);
+ iommu->cmd_regs = iommu->xlate_regs + IOC_IOCmd_Offset;
/* ensure that the STEs have updated */
mb();
@@ -407,6 +414,13 @@ static void cell_iommu_setup_hardware(struct cbe_iommu
*iommu, unsigned long siz
out_be64(iommu->cmd_regs + IOC_IOCmd_Cfg, reg);
}
+static void cell_iommu_setup_hardware(struct cbe_iommu *iommu,
+ unsigned long base, unsigned long size)
+{
+ cell_iommu_setup_page_tables(iommu, base, size);
+ cell_iommu_enable_hardware(iommu);
+}
+
#if 0/* Unused for now */
static struct iommu_window *find_window(struct cbe_iommu *iommu,
unsigned long offset, unsigned long size)
@@ -622,7 +636,7 @@ static void __init cell_iommu_init_one(struct device_node
*np,
base, base + size - 1);
/* Initialize the hardware */
- cell_iommu_setup_hardware(iommu, size);
+ cell_iommu_setup_hardware(iommu, base, size);
/* Setup the iommu_table */
cell_iommu_setup_window(iommu, np, base, size,
--
1.5.3.7.1.g4e596e
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/8] Split out the logic that allocates struct iommus
Split out the logic that allocates a struct iommu into a separate
function. This can fail however the calling code has never cared - so
just return if we can't allocate an iommu.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/cell/iommu.c | 20
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/cell/iommu.c
b/arch/powerpc/platforms/cell/iommu.c
index 9223559..4f1ca43 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -565,10 +565,9 @@ static int __init cell_iommu_get_window(struct device_node
*np,
return 0;
}
-static void __init cell_iommu_init_one(struct device_node *np, unsigned long
offset)
+static struct cbe_iommu * __init cell_iommu_alloc(struct device_node *np)
{
struct cbe_iommu *iommu;
- unsigned long base, size;
int nid, i;
/* Get node ID */
@@ -576,7 +575,7 @@ static void __init cell_iommu_init_one(struct device_node
*np, unsigned long off
if (nid < 0) {
printk(KERN_ERR "iommu: failed to get node for %s\n",
np->full_name);
- return;
+ return NULL;
}
pr_debug("iommu: setting up iommu for node %d (%s)\n",
nid, np->full_name);
@@ -592,7 +591,7 @@ static void __init cell_iommu_init_one(struct device_node
*np, unsigned long off
if (cbe_nr_iommus >= NR_IOMMUS) {
printk(KERN_ERR "iommu: too many IOMMUs detected ! (%s)\n",
np->full_name);
- return;
+ return NULL;
}
/* Init base fields */
@@ -603,6 +602,19 @@ static void __init cell_iommu_init_one(struct device_node
*np, unsigned long off
snprintf(iommu->name, sizeof(iommu->name), "iommu%d", i);
INIT_LIST_HEAD(&iommu->windows);
+ return iommu;
+}
+
+static void __init cell_iommu_init_one(struct device_node *np,
+ unsigned long offset)
+{
+ struct cbe_iommu *iommu;
+ unsigned long base, size;
+
+ iommu = cell_iommu_alloc(np);
+ if (!iommu)
+ return;
+
/* Obtain a window for it */
cell_iommu_get_window(np, &base, &size);
--
1.5.3.7.1.g4e596e
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/8] Allocate the hash table under 1G on cell
In order to support the fixed IOMMU mapping (in a subsequent patch), we
need the hash table to be inside the IOMMUs DMA window. This is usually 2G,
but let's make sure the hash table is under 1G as that will satisfy the
IOMMU requirements and also means the hash table will be on node 0.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/mm/hash_utils_64.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 9326a69..487c5e2 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -471,7 +471,7 @@ void __init htab_initialize(void)
unsigned long table;
unsigned long pteg_count;
unsigned long mode_rw;
- unsigned long base = 0, size = 0;
+ unsigned long base = 0, size = 0, limit;
int i;
extern unsigned long tce_alloc_start, tce_alloc_end;
@@ -505,9 +505,15 @@ void __init htab_initialize(void)
_SDR1 = 0;
} else {
/* Find storage for the HPT. Must be contiguous in
-* the absolute address space.
+* the absolute address space. On cell we want it to be
+* in the first 1 Gig.
*/
- table = lmb_alloc(htab_size_bytes, htab_size_bytes);
+ if (machine_is(cell))
+ limit = 0x4000;
+ else
+ limit = 0;
+
+ table = lmb_alloc_base(htab_size_bytes, htab_size_bytes, limit);
DBG("Hash table allocated at %lx, size: %lx\n", table,
htab_size_bytes);
--
1.5.3.7.1.g4e596e
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/8] Add set_dma_ops() to match get_dma_ops().
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
include/asm-powerpc/dma-mapping.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/asm-powerpc/dma-mapping.h
b/include/asm-powerpc/dma-mapping.h
index 5eea6db..bbefb69 100644
--- a/include/asm-powerpc/dma-mapping.h
+++ b/include/asm-powerpc/dma-mapping.h
@@ -76,6 +76,11 @@ static inline struct dma_mapping_ops *get_dma_ops(struct
device *dev)
return dev->archdata.dma_ops;
}
+static inline void set_dma_ops(struct device *dev, struct dma_mapping_ops *ops)
+{
+ dev->archdata.dma_ops = ops;
+}
+
static inline int dma_supported(struct device *dev, u64 mask)
{
struct dma_mapping_ops *dma_ops = get_dma_ops(dev);
--
1.5.3.7.1.g4e596e
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH][ppc] logical/bitand typo in powerpc/boot/4xx.c
>>> On Wed, 2008-01-23 at 23:37 +0100, Roel Kluin wrote:
- if (val && 0x1)
+ if (val & 0x1)
>> Joe Perches wrote:
>>> I think this pattern should be added to checkpatch
>>> + if ($line =~ /\&\&\s*0[xX]/) {
> On Thu, Jan 24, 2008 at 01:18:48AM +0100, Roel Kluin wrote:
>> I agree but there will be false positives, i'd propose to change that to
>> +if ($line =~ /(?:(?:\(|\&\&|\|\|)\s*0[xX]\s*(?:&&|\|\|)|
>> +(?:\&\&|\|\|)\s*0[xX]\s*(?:\)|&&|\|\|))/) {
Andy Whitcroft wrote:
> That one doesn't even match the original example. Seems to be missing
> some number matching. The concept seems sound though. Basically
> looking for numbers which are definatly adjacent to a boolean or a brace
> on both sides.
You are right. here's a version that does work. It works the same as
git-grep -E
"((\(|&&|\|\|)[[:space:]]*(0[xX][0-9a-fA-F]+|[0-9]+)[[:space:]]*(&&|\|\|)|(&&|\|\|)[[:space:]]*(0[xX][0-9a-fA-F]+|[0-9]+)[[:space:]]*(\)|&&|\|\|))"
---
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 579f50f..62276f7 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -1337,6 +1337,11 @@ sub process {
}
}
+# Check for bitwise tests written as boolean
+ if ($line =~
/((\(|&&|\|\|)\s*(0[xX][0-9a-fA-F]+|[0-9]+)\s*(&&|\|\|)|(&&|\|\|)\s*(0[xX][0-9a-fA-F]+|[0-9]+)\s*(\)|&&|\|\|))/)
{
+ WARN("boolean test with hexadecimal, perhaps just \'&\'
or \'|\'?\n" . $herecurr);
+ }
+
# if and else should not have general statements after it
if ($line =~ /^.\s*(?:}\s*)?else\b(.*)/ &&
$1 !~ /^\s*(?:\sif|{|\\|$)/) {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/1][PPC] Test value, not 1 in print_insn_spu(), arch/powerpc/xmon/spu-dis.c
On Mon, 2008-01-28 at 15:10 +0100, Roel Kluin wrote:
> untested, please confirm:
> The '|| 1' does nothing, should this be corrected like my patch does?
> --
> Test value, not 1.
>
> Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
> ---
> diff --git a/arch/powerpc/xmon/spu-dis.c b/arch/powerpc/xmon/spu-dis.c
> index e5f8983..74d45fb 100644
> --- a/arch/powerpc/xmon/spu-dis.c
> +++ b/arch/powerpc/xmon/spu-dis.c
> @@ -222,7 +222,7 @@ print_insn_spu (unsigned long insn, unsigned long memaddr)
> break;
> case A_U18:
> value = DECODE_INSN_U18 (insn);
> - if (value == 0 || 1)
> + if (value == 0 || value == 1)
> {
> hex_value = value;
> printf("%u", value);
The original binutils code looks like:
case A_U18:
value = DECODE_INSN_U18 (insn);
if (value == 0 || !(*info->symbol_at_address_func)(0, info))
{
hex_value = value;
(*info->fprintf_func) (info->stream, "%u", value);
}
else
(*info->print_address_func) (value, info);
break;
We don't have a symbol_at_address_func() so we always guess there isn't
a symbol at the address, as if the function had returned 0. Which gives
us:
if (value == 0 || !0)
or
if (value == 0 || 1)
The reason I left it like that rather than removing the if, was to
minimise the diff between the kernel version of spu-dis.c and the
binutils version.
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
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH powerpc] Fake NUMA emulation for PowerPC (Take 3)
On Mon, 2008-01-28 at 18:22 +0530, Balbir Singh wrote:
> Hi, Paul,
>
> Here's version 3 of the patch. I've commented the side-effect of
> repeatedly setting node 0 online (as to why that is done) and I've
> removed the side effect of not creating memory less nodes
> (when we hit the memory limit).
>
> I've described all my tests below
>
> Changelog v3
> 1. Remove the side-effect of not setting nodes online if they end
>up having no memory in them because of the memory limit.
>
> Changelog v2
>
> 1. Get rid of the constant 5 (based on comments from
> [EMAIL PROTECTED])
> 2. Implement suggestions from Olof Johannson
> 3. Check if cmdline is NULL in fake_numa_create_new_node()
> diff -puN arch/powerpc/mm/numa.c~fakenumappc arch/powerpc/mm/numa.c
> --- linux-2.6.24-rc8/arch/powerpc/mm/numa.c~fakenumappc 2008-01-28
> 17:05:34.0 +0530
> +++ linux-2.6.24-rc8-balbir/arch/powerpc/mm/numa.c2008-01-28
> 18:15:41.0 +0530
> @@ -39,6 +41,47 @@ static bootmem_data_t __initdata plat_no
> static int min_common_depth;
> static int n_mem_addr_cells, n_mem_size_cells;
>
> +static int __cpuinit fake_numa_create_new_node(unsigned long end_pfn,
> + unsigned int *nid)
> +{
> + unsigned long long mem;
> + char *p = cmdline;
> + static unsigned int fake_nid;
> + static unsigned long long curr_boundary;
> +
> + /*
> + * Modify node id, iff we started creating NUMA nodes
> + */
> + if (fake_nid)
> + *nid = fake_nid;
> + if (!p)
> + return 0;
Why do you check !p after assigning to nid? I assume it's because we
might have reached the end of the command line, ie. p == NULL, but we're
still adding memory to the last node? If so it's a it's a little subtle
and deserves a comment I think.
Otherwise this looks pretty good.
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
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch v6 2/4] USB: add Cypress c67x00 OTG controller core driver
This patch add the core driver for the c67x00 USB OTG controller. The core
driver is responsible for the platform bus binding and creating either
USB HCD or USB Gadget instances for each of the serial interface engines
on the chip.
This driver does not directly implement the HCD or gadget behaviours; it
just controls access to the chip.
Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
---
MAINTAINERS |6 +
drivers/usb/c67x00/c67x00-drv.c | 232
include/linux/usb/c67x00.h | 48
3 files changed, 286 insertions(+)
Index: linux-2.6/drivers/usb/c67x00/c67x00-drv.c
===
--- /dev/null
+++ linux-2.6/drivers/usb/c67x00/c67x00-drv.c
@@ -0,0 +1,232 @@
+/*
+ * c67x00-drv.c: Cypress C67X00 USB Common infrastructure
+ *
+ * Copyright (C) 2006-2008 Barco N.V.
+ *Derived from the Cypress cy7c67200/300 ezusb linux driver and
+ *based on multiple host controller drivers inside the linux kernel.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA.
+ */
+
+/*
+ * This file implements the common infrastructure for using the c67x00.
+ * It is both the link between the platform configuration and subdrivers and
+ * the link between the common hardware parts and the subdrivers (e.g.
+ * interrupt handling).
+ *
+ * The c67x00 has 2 SIE's (serial interface engine) wich can be configured
+ * to be host, device or OTG (with some limitations, E.G. only SIE1 can be
OTG).
+ *
+ * Depending on the platform configuration, the SIE's are created and
+ * the corresponding subdriver is initialized (c67x00_probe_sie).
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "c67x00.h"
+
+static void c67x00_probe_sie(struct c67x00_sie *sie,
+struct c67x00_device *dev, int sie_num)
+{
+ spin_lock_init(&sie->lock);
+ sie->dev = dev;
+ sie->sie_num = sie_num;
+ sie->mode = c67x00_sie_config(dev->pdata->sie_config, sie_num);
+
+ switch (sie->mode) {
+ case C67X00_SIE_UNUSED:
+ dev_info(sie_dev(sie),
+"Not using SIE %d as requested\n", sie->sie_num);
+ break;
+
+ default:
+ dev_err(sie_dev(sie),
+ "Unsupported configuration: 0x%x for SIE %d\n",
+ sie->mode, sie->sie_num);
+ break;
+ }
+}
+
+static void c67x00_remove_sie(struct c67x00_sie *sie)
+{
+}
+
+static irqreturn_t c67x00_irq(int irq, void *__dev)
+{
+ struct c67x00_device *c67x00 = __dev;
+ struct c67x00_sie *sie;
+ u16 msg, int_status;
+ int i, count = 8;
+
+ int_status = c67x00_ll_hpi_status(c67x00);
+ if (!int_status)
+ return IRQ_NONE;
+
+ while (int_status != 0 && (count-- >= 0)) {
+ c67x00_ll_irq(c67x00, int_status);
+ for (i = 0; i < C67X00_SIES; i++) {
+ sie = &c67x00->sie[i];
+ msg = 0;
+ if (int_status & SIEMSG_FLG(i))
+ msg = c67x00_ll_fetch_siemsg(c67x00, i);
+ if (sie->irq)
+ sie->irq(sie, int_status, msg);
+ }
+ int_status = c67x00_ll_hpi_status(c67x00);
+ }
+
+ if (int_status)
+ dev_warn(&c67x00->pdev->dev, "Not all interrupts handled! "
+"status = 0x%04x\n", int_status);
+
+ return IRQ_HANDLED;
+}
+
+/* - */
+
+static int __devinit c67x00_drv_probe(struct platform_device *pdev)
+{
+ struct c67x00_device *c67x00;
+ struct c67x00_platform_data *pdata;
+ struct resource *res, *res2;
+ int ret, i;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
+
+ res2 = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (!res2)
+ return -ENODEV;
+
+ pdata = pdev->dev.platform_data;
+ if (!pdata)
+ return -ENODEV;
+
+ c67x00 = kzalloc(sizeof(*c67x00), GFP_KERNEL);
+ if (!c67x00)
+ return -ENOMEM;
[patch v6 0/4] Cypress c67x00 (EZ-Host/EZ-OTG) support
The Cypress c67x00 (EZ-Host/EZ-OTG) controllers are multi-role low/fullspeed
USB controllers. This patch series implements a HCD driver and shows the
work-in-progress status of a gadget driver.
I believe patch 1..3 are ready, and I would like to see them queued up for
2.6.25.
Changes since v5:
- Merged c67x00_ll_{get,set}_siemsg() into c67x00_ll_fetch_siemsg().
- Fix for interrupt race condition at probe time (reported by Grant)
Changes since v4:
- Addressed Grant's comments (c67x00_dev->c67x00_hcd_dev, label indent)
- Moved c67x00_ll_set_ep_{ctrl,packet_size}_reg() to patch 4 as they are
only needed for gadget support.
- Added c67x00_ prefix to struct lcp_int_data
Changes since v3:
- Lots of cleanups: checkpatch, interrupt handling, c67x00_ prefixes, ..
- The dummy platform_device's created per serial engine are gone.
- Gadget driver (WIP)
--
Bye, Peter Korsgaard
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch v6 1/4] USB: add Cypress c67x00 low level interface code
This patch adds the low level support code for the Cypress c67x00 family of OTG controllers. The low level code is responsible for register access and implements the software protocol for communicating with the 16bit microcontroller inside the c67x00 device. Communication is done over the HPI interface (16bit SRAM-like parallel bus). Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]> --- drivers/usb/c67x00/c67x00-ll-hpi.c | 410 + drivers/usb/c67x00/c67x00.h| 285 + 2 files changed, 695 insertions(+) Index: linux-2.6/drivers/usb/c67x00/c67x00.h === --- /dev/null +++ linux-2.6/drivers/usb/c67x00/c67x00.h @@ -0,0 +1,285 @@ +/* + * c67x00.h: Cypress C67X00 USB register and field definitions + * + * Copyright (C) 2006-2008 Barco N.V. + *Derived from the Cypress cy7c67200/300 ezusb linux driver and + *based on multiple host controller drivers inside the linux kernel. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301 USA. + */ + +#ifndef _USB_C67X00_H +#define _USB_C67X00_H + +#include +#include +#include +#include + +/* - + * Cypress C67x00 register definitions + */ + +/* Hardware Revision Register */ +#define HW_REV_REG 0xC004 + +/* General USB registers */ +/* = */ + +/* USB Control Register */ +#define USB_CTL_REG(x) ((x) ? 0xC0AA : 0xC08A) + +#define LOW_SPEED_PORT(x) ((x) ? 0x0800 : 0x0400) +#define HOST_MODE 0x0200 +#define PORT_RES_EN(x) ((x) ? 0x0100 : 0x0080) +#define SOF_EOP_EN(x) ((x) ? 0x0002 : 0x0001) + +/* USB status register - Notice it has different content in hcd/udc mode */ +#define USB_STAT_REG(x)((x) ? 0xC0B0 : 0xC090) + +#define EP0_IRQ_FLG0x0001 +#define EP1_IRQ_FLG0x0002 +#define EP2_IRQ_FLG0x0004 +#define EP3_IRQ_FLG0x0008 +#define EP4_IRQ_FLG0x0010 +#define EP5_IRQ_FLG0x0020 +#define EP6_IRQ_FLG0x0040 +#define EP7_IRQ_FLG0x0080 +#define RESET_IRQ_FLG 0x0100 +#define SOF_EOP_IRQ_FLG0x0200 +#define ID_IRQ_FLG 0x4000 +#define VBUS_IRQ_FLG 0x8000 + +/* USB Host only registers */ +/* === */ + +/* Host n Control Register */ +#define HOST_CTL_REG(x)((x) ? 0xC0A0 : 0xC080) + +#define PREAMBLE_EN0x0080 /* Preamble enable */ +#define SEQ_SEL0x0040 /* Data Toggle Sequence Bit Select */ +#define ISO_EN 0x0010 /* Isochronous enable */ +#define ARM_EN 0x0001 /* Arm operation */ + +/* Host n Interrupt Enable Register */ +#define HOST_IRQ_EN_REG(x) ((x) ? 0xC0AC : 0xC08C) + +#define SOF_EOP_IRQ_EN 0x0200 /* SOF/EOP Interrupt Enable */ +#define SOF_EOP_TMOUT_IRQ_EN 0x0800 /* SOF/EOP Timeout Interrupt Enable */ +#define ID_IRQ_EN 0x4000 /* ID interrupt enable */ +#define VBUS_IRQ_EN0x8000 /* VBUS interrupt enable */ +#define DONE_IRQ_EN0x0001 /* Done Interrupt Enable */ + +/* USB status register */ +#define HOST_STAT_MASK 0x02FD +#define PORT_CONNECT_CHANGE(x) ((x) ? 0x0020 : 0x0010) +#define PORT_SE0_STATUS(x) ((x) ? 0x0008 : 0x0004) + +/* Host Frame Register */ +#define HOST_FRAME_REG(x) ((x) ? 0xC0B6 : 0xC096) + +#define HOST_FRAME_MASK0x07FF + +/* USB Peripheral only registers */ +/* = */ + +/* Device n Port Sel reg */ +#define DEVICE_N_PORT_SEL(x) ((x) ? 0xC0A4 : 0xC084) + +/* Device n Interrupt Enable Register */ +#define DEVICE_N_IRQ_EN_REG(x) ((x) ? 0xC0AC : 0xC08C) + +#define DEVICE_N_ENDPOINT_N_CTL_REG(dev, ep) ((dev) \ +? (0x0280 + (ep << 4)) \ +: (0x0200 + (ep << 4))) +#define DEVICE_N_ENDPOINT_N_STAT_REG(dev, ep) ((dev) \ +? (0x0286 + (ep << 4)) \ +: (0x0206 + (ep << 4))) + +#define DEVICE_N_ADDRESS(dev) ((dev) ? (0xC0
[patch v6 3/4] USB: add Cypress c67x00 OTG controller HCD driver
This patch adds HCD support for the Cypress c67x00 family of devices.
Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
---
drivers/usb/Makefile |2
drivers/usb/c67x00/Makefile| 11
drivers/usb/c67x00/c67x00-drv.c| 13
drivers/usb/c67x00/c67x00-hcd.c| 410
drivers/usb/c67x00/c67x00-hcd.h| 152
drivers/usb/c67x00/c67x00-ll-hpi.c | 75 ++
drivers/usb/c67x00/c67x00-sched.c | 1194 +
drivers/usb/c67x00/c67x00.h|9
drivers/usb/host/Kconfig | 12
9 files changed, 1878 insertions(+)
Index: linux-2.6/drivers/usb/c67x00/c67x00-hcd.c
===
--- /dev/null
+++ linux-2.6/drivers/usb/c67x00/c67x00-hcd.c
@@ -0,0 +1,410 @@
+/*
+ * c67x00-hcd.c: Cypress C67X00 USB Host Controller Driver
+ *
+ * Copyright (C) 2006-2008 Barco N.V.
+ *Derived from the Cypress cy7c67200/300 ezusb linux driver and
+ *based on multiple host controller drivers inside the linux kernel.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA.
+ */
+
+#include
+#include
+#include
+
+#include "c67x00.h"
+#include "c67x00-hcd.h"
+
+/* --
+ * Root Hub Support
+ */
+
+static __u8 c67x00_hub_des[] = {
+ 0x09, /* __u8 bLength; */
+ 0x29, /* __u8 bDescriptorType; Hub-descriptor */
+ 0x02, /* __u8 bNbrPorts; */
+ 0x00, /* __u16 wHubCharacteristics; */
+ 0x00, /* (per-port OC, no power switching) */
+ 0x32, /* __u8 bPwrOn2pwrGood; 2ms */
+ 0x00, /* __u8 bHubContrCurrent; 0 mA */
+ 0x00, /* __u8 DeviceRemovable; ** 7 Ports max ** */
+ 0xff, /* __u8 PortPwrCtrlMask; ** 7 ports max ** */
+};
+
+static void c67x00_hub_reset_host_port(struct c67x00_sie *sie, int port)
+{
+ struct c67x00_hcd *c67x00 = sie->private_data;
+ unsigned long flags;
+
+ c67x00_ll_husb_reset(sie, port);
+
+ spin_lock_irqsave(&c67x00->lock, flags);
+ c67x00_ll_husb_reset_port(sie, port);
+ spin_unlock_irqrestore(&c67x00->lock, flags);
+
+ c67x00_ll_set_husb_eot(sie->dev, DEFAULT_EOT);
+}
+
+static int c67x00_hub_status_data(struct usb_hcd *hcd, char *buf)
+{
+ struct c67x00_hcd *c67x00 = hcd_to_c67x00_hcd(hcd);
+ struct c67x00_sie *sie = c67x00->sie;
+ u16 status;
+ int i;
+
+ *buf = 0;
+ status = c67x00_ll_usb_get_status(sie);
+ for (i = 0; i < C67X00_PORTS; i++)
+ if (status & PORT_CONNECT_CHANGE(i))
+ *buf |= (1 << i);
+
+ /* bit 0 denotes hub change, b1..n port change */
+ *buf <<= 1;
+
+ return !!*buf;
+}
+
+static int c67x00_hub_control(struct usb_hcd *hcd, u16 typeReq, u16 wValue,
+ u16 wIndex, char *buf, u16 wLength)
+{
+ struct c67x00_hcd *c67x00 = hcd_to_c67x00_hcd(hcd);
+ struct c67x00_sie *sie = c67x00->sie;
+ u16 status, usb_status;
+ int len = 0;
+ unsigned int port = wIndex-1;
+ u16 wPortChange, wPortStatus;
+
+ switch (typeReq) {
+
+ case GetHubStatus:
+ *(__le32 *) buf = cpu_to_le32(0);
+ len = 4;/* hub power */
+ break;
+
+ case GetPortStatus:
+ if (wIndex > C67X00_PORTS)
+ return -EPIPE;
+
+ status = c67x00_ll_usb_get_status(sie);
+ usb_status = c67x00_ll_get_usb_ctl(sie);
+
+ wPortChange = 0;
+ if (status & PORT_CONNECT_CHANGE(port))
+ wPortChange |= USB_PORT_STAT_C_CONNECTION;
+
+ wPortStatus = USB_PORT_STAT_POWER;
+ if (!(status & PORT_SE0_STATUS(port)))
+ wPortStatus |= USB_PORT_STAT_CONNECTION;
+ if (usb_status & LOW_SPEED_PORT(port)) {
+ wPortStatus |= USB_PORT_STAT_LOW_SPEED;
+ c67x00->low_speed_ports |= (1 << port);
+ } else
+ c67x00->low_speed_ports &= ~(1 << port);
[patch v6 4/4] USB: add Cypress c67x00 OTG controller gadget driver
This patch adds USB gadget support for the Cypress c67x00 family of devices.
This is work in progress and not ready to be committed yet. I'm posting this
to show how it fits with the rest of the driver and to collect feedback.
The driver works good enought to use g_serial, but there are still issues
to be solved. The biggest issue is that endpoint 0 is currently handled by
the BIOS inside the c67x00, so the gadget stack never sees the data.
The BIOS also has other deficiencies, E.G. see the patching done in
c67x00_ll_susb_init().
---
drivers/usb/Kconfig|2
drivers/usb/Makefile |2
drivers/usb/c67x00/Kconfig | 21
drivers/usb/c67x00/Makefile|7
drivers/usb/c67x00/c67x00-drv.c| 11
drivers/usb/c67x00/c67x00-ll-hpi.c | 201
drivers/usb/c67x00/c67x00-udc.c| 905 +
drivers/usb/c67x00/c67x00-udc.h| 50 ++
drivers/usb/c67x00/c67x00.h| 21
drivers/usb/gadget/Kconfig |7
drivers/usb/gadget/gadget_chips.h |8
drivers/usb/host/Kconfig | 12
12 files changed, 1232 insertions(+), 15 deletions(-)
Index: linux-2.6/drivers/usb/c67x00/c67x00-udc.c
===
--- /dev/null
+++ linux-2.6/drivers/usb/c67x00/c67x00-udc.c
@@ -0,0 +1,905 @@
+/*
+ * c67x00-udc.c: Cypress C67X00 USB device controller
+ *
+ * Copyright (C) 2006-2008 Barco N.V.
+ *Derived from the Cypress cy7c67200/300 ezusb linux driver and
+ *based on multiple device controller drivers inside the linux kernel.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301 USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "c67x00.h"
+#include "c67x00-udc.h"
+
+/* Defined in DEVICE n ENDPOINT STATUS REGISTERS */
+#define OVERFLOW_FLG 0x0800 /* Receive overflow */
+#define UNDERFLOW_FLG 0x0400 /* Receive underflow */
+#define OUT_EXCEPTION_FLG 0x0200 /* OUT received when armed for IN */
+#define IN_EXCEPTION_FLG 0x0100 /* IN received when armed for OUT */
+#define STALL_FLG 0x0080 /* Stall sent */
+#define NAK_FLG0x0040 /* NAK sent */
+#define LENGTH_EXCEPT_FLG 0x0020 /* Overflow or Underflow occured */
+#define SETUP_FLG 0x0010 /* SETUP packet received */
+#define SEQ_STAT 0x0008 /* Last Data Toggle Sequence bit sent
+ or received */
+#define TIMEOUT_FLG0x0004 /* Last transmission timed out */
+#define ERROR_FLG 0x0002 /* CRC Err detected in last
+ reception*/
+#define ACK_FLG0x0001 /* Last transaction ACK'D (sent
+ or received) */
+
+/* Defined in DEVICE n ENDPOINT CONTROL REGISTERS */
+#define DIR_SEL_IN 0x0004 /* Last transmission timed out */
+#define EP_ENABLE 0x0002 /* Enable Endpoint */
+
+
+
+struct c67x00_request {
+ struct usb_request req;
+ struct list_head queue;
+};
+
+
+
+struct c67x00_udc_ep {
+ struct usb_ep ep;
+ struct c67x00_udc *udc;
+
+ struct list_head queue;
+ int ep_num;
+ int is_ep_in;
+ int enable;
+ int stopped;
+ int start_io;
+};
+
+#define C67X00_MAX_NB_END_POINTS 8
+
+struct c67x00_udc {
+ spinlock_t lock;
+ struct c67x00_sie *sie;
+ struct usb_gadget gadget;
+ struct usb_gadget_driver *driver;
+ struct c67x00_udc_ep ep[C67X00_MAX_NB_END_POINTS];
+ struct work_struct io_work;
+ int config_nr;
+ /* The highest string descriptor entry
+ (used to retrieve descriptors from gadget driver) */
+ int top_str_id;
+ u16 string_desc_addr;
+};
+
+const static unsigned char get_descriptor_device[] = {
+ USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE,
+ USB_REQ_GET_DESCRIPTOR,
+ 0x00,
+ USB_DT_DEVICE,
+ 0x00,
+ 0x00,
+ 0x12,
+ 0x00
+};
+
+const static unsigned char get_descriptor_config[] = {
+ USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_DEVICE,
+ USB_REQ_GET_DESCRIPTOR,
+ 0x00,
+ USB_DT_CONFIG,
+ 0x00,
+ 0x00,
+
Re: [PATCH][ppc] logical/bitand typo in powerpc/boot/4xx.c
On Thu, Jan 24, 2008 at 01:18:48AM +0100, Roel Kluin wrote:
> Joe Perches wrote:
> > On Wed, 2008-01-23 at 23:37 +0100, Roel Kluin wrote:
> >> Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
> >> ---
> >> diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c
> >> index ebf9e21..dcfb459 100644
> >> --- a/arch/powerpc/boot/4xx.c
> >> +++ b/arch/powerpc/boot/4xx.c
> >> @@ -104,7 +104,7 @@ void ibm4xx_denali_fixup_memsize(void)
> >>val = DDR_GET_VAL(val, DDR_CS_MAP, DDR_CS_MAP_SHIFT);
> >>cs = 0;
> >>while (val) {
> >> - if (val && 0x1)
> >> + if (val & 0x1)
> >>cs++;
> >>val = val >> 1;
> >
> > I think this pattern should be added to checkpatch
>
> I agree but...
>
> > Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
> >
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 579f50f..147e573 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -1337,6 +1337,11 @@ sub process {
> > }
> > }
> >
> > +# Check for bitwise tests written as boolean
> > + if ($line =~ /\&\&\s*0[xX]/) {
> > + WARN("boolean test with hexadecimal, perhaps just 1
> > \&?\n" . $herecurr);
> > + }
> > +
>
> when you use git-grep -n "\(&&\|||\)${s}0x\([A-Z0-9]*\|[a-z0-9]*\)",
> (with s="[[:space:]]*") there will be false positives like
>
> if (relocation < -0x2 || 0x1fffc < relocation)
> if (ARCH_SUN4C_SUN4 && addr < 0xe000 && 0x2000 - len < addr) {
> (and more)
>
> However, if you search with
> git-grep -n " \(&&\|||\)${s}0x\([A-Z0-9]*\|[a-z0-9]*\)$s\()\|&&\|||\)"
> you won't get these false positives, but you do get the one I fixed.
>
> Also there is the same logic flipped (though it did not give matches at
> this time):
> git-grep -n " \(&&\|||\|(\)${s}0x\([A-Z0-9]*\|[a-z0-9]*\)$s\(&&\|||\)"
>
> so i'd propose to change that to
> --
> Catch boolean tests with hexadecimals, based on suggestion by Joe Perches
>
> Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
> ---
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 579f50f..8ac7c7b 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -1337,6 +1337,12 @@ sub process {
> }
> }
>
> +# Check for bitwise tests written as boolean
> + if ($line =~ /(?:(?:\(|\&\&|\|\|)\s*0[xX]\s*(?:&&|\|\|)|
> + (?:\&\&|\|\|)\s*0[xX]\s*(?:\)|&&|\|\|))/) {
> + WARN("boolean test with hexadecimal, perhaps just 1 \&
> or \|?\n" . $herecurr);
> + }
> +
> # if and else should not have general statements after it
> if ($line =~ /^.\s*(?:}\s*)?else\b(.*)/ &&
> $1 !~ /^\s*(?:\sif|{|\\|$)/) {
That one doesn't even match the original example. Seems to be missing
some number matching. The concept seems sound though. Basically
looking for numbers which are definatly adjacent to a boolean or a brace
on both sides.
/me goes play with some examples to see if the falsies are better than
the reports.
-apw
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4] 82xx: MGCOGE support
Hello,
To get the serial console on the SMC2 working, the
following patch is needed:
Fixing serial console on a SMC on MPC82xx based
board and using CONFIG_PPC_CPM_NEW_BINDING
Signed-off-by: Heiko Schocher <[EMAIL PROTECTED]>
---
drivers/serial/cpm_uart/cpm_uart_core.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
b/drivers/serial/cpm_uart/cpm_uart_core.c
index b5e4478..7e610c2 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -978,9 +978,24 @@ static int cpm_uart_init_port(struct device_node *np,
pinfo->sccup = pram;
} else if (of_device_is_compatible(np, "fsl,cpm1-smc-uart") ||
of_device_is_compatible(np, "fsl,cpm2-smc-uart")) {
+ u16 __iomem *pram_base;
+ struct resource res;
+
pinfo->flags |= FLAG_SMC;
pinfo->smcp = mem;
pinfo->smcup = pram;
+
+ if (of_address_to_resource(np, 1, &res)) {
+ ret = -ENOMEM;
+ goto out_pram;
+ }
+ pram_base = of_iomap(np, 2);
+ if (!pram_base) {
+ ret = -ENOMEM;
+ goto out_pram;
+ }
+ *pram_base = res.start;
+ iounmap (pram_base);
} else {
ret = -ENODEV;
goto out_pram;
--
1.5.2.2
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/4] 82xx: MGCOGE support
Hello,
The following Patch adds the DTS File for the MGCOGE
plattform from keymile.
Signed-off-by: Heiko Schocher <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mgcoge.dts | 153 ++
1 files changed, 153 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mgcoge.dts
diff --git a/arch/powerpc/boot/dts/mgcoge.dts b/arch/powerpc/boot/dts/mgcoge.dts
new file mode 100644
index 000..1033e5a
--- /dev/null
+++ b/arch/powerpc/boot/dts/mgcoge.dts
@@ -0,0 +1,153 @@
+/*
+ * Device Tree for the MGCOGE plattform from keymile.
+ *
+ * Copyright 2008 DENX Software Engineering GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = "MGCOGE";
+ compatible = "fsl,mgcoge";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ aliases {
+ ethernet0 = ð0;
+ serial0 = &smc2;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <32>;
+ i-cache-line-size = <32>;
+ d-cache-size = <16384>;
+ i-cache-size = <16384>;
+ timebase-frequency = <0>;
+ clock-frequency = <0>;
+ bus-frequency = <0>;
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8248-localbus",
+"fsl,pq2-localbus",
+"simple-bus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <0xf0010100 0x40>;
+
+ ranges = <0 0 0xfe00 0x0040>;
+
+ [EMAIL PROTECTED],0 {
+ compatible = "cfi-flash";
+ reg = <0 0x0 0x40>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ bank-width = <1>;
+ device-width = <1>;
+ [EMAIL PROTECTED] {
+ label = "u-boot";
+ reg = <0 0x4>;
+ };
+ [EMAIL PROTECTED] {
+ label = "env";
+ reg = <0x4 0x2>;
+ };
+ [EMAIL PROTECTED] {
+ label = "user";
+ reg = <0x6 0x3a>;
+ };
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0>;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8248-immr", "fsl,pq2-soc", "simple-bus";
+ ranges = <0x 0xf000 0x00053000>;
+
+ // Temporary until code stops depending on it.
+ device_type = "soc";
+
+ // Temporary -- will go away once kernel uses ranges for
get_immrbase().
+ reg = <0xf000 0x00053000>;
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ compatible = "fsl,mpc8248-cpm", "fsl,cpm2",
+ "simple-bus";
+ reg = <0x119c0 0x30>;
+ ranges;
+
+ muram {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0 0x1>;
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,cpm-muram-data";
+ reg = <0 0x1100 0x1140
+ 0xec0 0x9800 0x800>;
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8248-brg",
+"fsl,cpm2-brg",
+"fsl,cpm-brg";
+ reg = <0x119f0 0x10 0x115f0 0x10>;
+ };
+
+ /* Monitor port/SMC2 */
+ smc2: [EMAIL PROTECTED] {
+ device_type = "serial";
+ compatible = "fsl,mpc8248-smc-uart",
+
[PATCH 2/4] 82xx: MGCOGE support
Hello The following Patchs adds the defconfig file for the MGCOGE plattform from keymile. Signed-off-by: Heiko Schocher <[EMAIL PROTECTED]> --- arch/powerpc/configs/mgcoge_defconfig | 749 + 1 files changed, 749 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/configs/mgcoge_defconfig diff --git a/arch/powerpc/configs/mgcoge_defconfig b/arch/powerpc/configs/mgcoge_defconfig new file mode 100644 index 000..d964c0d --- /dev/null +++ b/arch/powerpc/configs/mgcoge_defconfig @@ -0,0 +1,749 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.24-rc8 +# Tue Jan 29 08:30:19 2008 +# +# CONFIG_PPC64 is not set + +# +# Processor support +# +CONFIG_6xx=y +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +# CONFIG_44x is not set +# CONFIG_E200 is not set +CONFIG_PPC_FPU=y +CONFIG_PPC_STD_MMU=y +CONFIG_PPC_STD_MMU_32=y +# CONFIG_PPC_MM_SLICES is not set +# CONFIG_SMP is not set +CONFIG_PPC32=y +CONFIG_WORD_SIZE=32 +CONFIG_PPC_MERGE=y +CONFIG_MMU=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_TIME=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_IRQ_PER_CPU=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_ARCH_HAS_ILOG2_U32=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_FIND_NEXT_BIT=y +# CONFIG_ARCH_NO_VIRT_TO_BUS is not set +CONFIG_PPC=y +CONFIG_EARLY_PRINTK=y +CONFIG_GENERIC_NVRAM=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +CONFIG_ARCH_MAY_HAVE_PC_FDC=y +CONFIG_PPC_OF=y +CONFIG_OF=y +# CONFIG_PPC_UDBG_16550 is not set +# CONFIG_GENERIC_TBSYNC is not set +CONFIG_AUDIT_ARCH=y +CONFIG_GENERIC_BUG=y +# CONFIG_DEFAULT_UIMAGE is not set +# CONFIG_PPC_DCR_NATIVE is not set +# CONFIG_PPC_DCR_MMIO is not set +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# General setup +# +# CONFIG_EXPERIMENTAL is not set +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION="" +CONFIG_LOCALVERSION_AUTO=y +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_AUDIT is not set +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_CGROUPS is not set +CONFIG_FAIR_GROUP_SCHED=y +CONFIG_FAIR_USER_SCHED=y +# CONFIG_FAIR_CGROUP_SCHED is not set +CONFIG_SYSFS_DEPRECATED=y +# CONFIG_RELAY is not set +# CONFIG_BLK_DEV_INITRD is not set +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS=y +CONFIG_KALLSYMS_ALL=y +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_ANON_INODES=y +CONFIG_EPOLL=y +CONFIG_SIGNALFD=y +CONFIG_EVENTFD=y +CONFIG_SHMEM=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_SLAB=y +# CONFIG_SLUB is not set +# CONFIG_SLOB is not set +CONFIG_SLABINFO=y +CONFIG_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +# CONFIG_MODULES is not set +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +# CONFIG_IOSCHED_AS is not set +CONFIG_IOSCHED_DEADLINE=y +# CONFIG_IOSCHED_CFQ is not set +# CONFIG_DEFAULT_AS is not set +CONFIG_DEFAULT_DEADLINE=y +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="deadline" + +# +# Platform support +# +# CONFIG_PPC_MULTIPLATFORM is not set +CONFIG_PPC_82xx=y +# CONFIG_PPC_83xx is not set +# CONFIG_PPC_86xx is not set +# CONFIG_PPC_MPC52xx is not set +# CONFIG_PPC_MPC5200 is not set +# CONFIG_PPC_CELL is not set +# CONFIG_PPC_CELL_NATIVE is not set +# CONFIG_MPC8272_ADS is not set +# CONFIG_PQ2FADS is not set +# CONFIG_EP8248E is not set +CONFIG_MGCOGE=y +# CONFIG_PQ2ADS is not set +CONFIG_8260=y +CONFIG_8272=y +# CONFIG_IPIC is not set +# CONFIG_MPIC is not set +# CONFIG_MPIC_WEIRD is not set +# CONFIG_PPC_I8259 is not set +# CONFIG_PPC_RTAS is not set +# CONFIG_MMIO_NVRAM is not set +# CONFIG_PPC_MPC106 is not set +# CONFIG_PPC_970_NAP is not set +# CONFIG_PPC_INDIRECT_IO is not set +# CONFIG_GENERIC_IOMAP is not set +# CONFIG_CPU_FREQ is not set +CONFIG_CPM2=y +CONFIG_PPC_CPM_NEW_BINDING=y +# CONFIG_FSL_ULI1575 is not set +CONFIG_CPM=y + +# +# Kernel options +# +# CONFIG_HIGHMEM is not set +# CONFIG_TICK_ONESHOT is not set +# CONFIG_NO_HZ is not set +# CONFIG_HIGH_RES_TIMERS is not set +CONFIG_GENERIC_CLOCKEVENTS_BUILD=y +# CONFIG_HZ_100 is not set +CONFIG_HZ_250=y +# CONFIG_HZ_300 is not set +# CONFIG_HZ_1000 is not set +CONFIG_HZ=250 +CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_VOLUNTARY is not set +# CONFIG_PREEMPT is not set +CONFIG_BINFMT_ELF=y +CONFIG_BINFMT_MISC=y +CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y +CONFIG_ARCH_FLATMEM_ENABLE=y +CONFIG_ARCH_POPULATES_NODE_MAP=y +CONFIG_FLATMEM=y +CONFIG_FLAT_NODE_MEM_MAP=y +# CONFIG_SPARSEMEM_STATIC is not set +# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set +CONFIG_SPLI
[PATCH 1/4] 82xx: MGCOGE support
Hello,
The following Patch adds basic files for supporting the MGCOGE
plattform from keymile.
Signed-off-by: Heiko Schocher <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/82xx/Kconfig |9 +++
arch/powerpc/platforms/82xx/Makefile |1 +
arch/powerpc/platforms/82xx/mgcoge.c | 130 ++
3 files changed, 140 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/platforms/82xx/mgcoge.c
diff --git a/arch/powerpc/platforms/82xx/Kconfig
b/arch/powerpc/platforms/82xx/Kconfig
index 4fad6c7..f2ea477 100644
--- a/arch/powerpc/platforms/82xx/Kconfig
+++ b/arch/powerpc/platforms/82xx/Kconfig
@@ -39,6 +39,15 @@ config EP8248E
This board is also resold by Freescale as the QUICCStart
MPC8248 Evaluation System and/or the CWH-PPC-8248N-VE.
+config MGCOGE
+ bool "Keymile MGCOGE"
+ select 8272
+ select 8260
+ select FSL_SOC
+ select PPC_CPM_NEW_BINDING
+ help
+ This enables support for the Keymile MGCOGE board.
+
endchoice
config PQ2ADS
diff --git a/arch/powerpc/platforms/82xx/Makefile
b/arch/powerpc/platforms/82xx/Makefile
index 6cd5cd5..d982793 100644
--- a/arch/powerpc/platforms/82xx/Makefile
+++ b/arch/powerpc/platforms/82xx/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_CPM2) += pq2.o
obj-$(CONFIG_PQ2_ADS_PCI_PIC) += pq2ads-pci-pic.o
obj-$(CONFIG_PQ2FADS) += pq2fads.o
obj-$(CONFIG_EP8248E) += ep8248e.o
+obj-$(CONFIG_MGCOGE) += mgcoge.o
diff --git a/arch/powerpc/platforms/82xx/mgcoge.c
b/arch/powerpc/platforms/82xx/mgcoge.c
new file mode 100644
index 000..a8f2956
--- /dev/null
+++ b/arch/powerpc/platforms/82xx/mgcoge.c
@@ -0,0 +1,130 @@
+/*
+ * Keymile mgcoge support
+ * Copyright 2008 DENX Software Engineering GmbH
+ * Author: Heiko Schocher <[EMAIL PROTECTED]>
+ *
+ * based on code from:
+ * Copyright 2007 Freescale Semiconductor, Inc.
+ * Author: Scott Wood <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include "pq2.h"
+
+static void __init mgcoge_pic_init(void)
+{
+ struct device_node *np = of_find_compatible_node(NULL, NULL,
"fsl,pq2-pic");
+ if (!np) {
+ printk(KERN_ERR "PIC init: can not find cpm-pic node\n");
+ return;
+ }
+
+ cpm2_pic_init(np);
+ of_node_put(np);
+}
+
+struct cpm_pin {
+ int port, pin, flags;
+};
+
+static __initdata struct cpm_pin mgcoge_pins[] = {
+
+ /* SMC2 */
+ {1, 8, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {1, 9, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+
+ /* SCC4 */
+ {3, 25, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {3, 24, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {3, 9, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {3, 8, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {4, 22, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {4, 21, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {4, 22, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+};
+
+static void __init init_ioports(void)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(mgcoge_pins); i++) {
+ const struct cpm_pin *pin = &mgcoge_pins[i];
+ cpm2_set_pin(pin->port, pin->pin, pin->flags);
+ }
+
+ cpm2_smc_clk_setup(CPM_CLK_SMC2, CPM_BRG8);
+ cpm2_clk_setup(CPM_CLK_SCC4, CPM_CLK7, CPM_CLK_RX);
+ cpm2_clk_setup(CPM_CLK_SCC4, CPM_CLK8, CPM_CLK_TX);
+}
+
+static void __init mgcoge_setup_arch(void)
+{
+ if (ppc_md.progress)
+ ppc_md.progress("mgcoge_setup_arch()", 0);
+
+ cpm2_reset();
+
+ /* When this is set, snooping CPM DMA from RAM causes
+* machine checks. See erratum SIU18.
+*/
+ clrbits32(&cpm2_immr->im_siu_conf.siu_82xx.sc_bcr, MPC82XX_BCR_PLDP);
+
+ init_ioports();
+
+ if (ppc_md.progress)
+ ppc_md.progress("mgcoge_setup_arch(), finish", 0);
+}
+
+static __initdata struct of_device_id of_bus_ids[] = {
+ { .compatible = "simple-bus", },
+ {},
+};
+
+static int __init declare_of_platform_devices(void)
+{
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
+
+ return 0;
+}
+machine_device_initcall(mgcoge, declare_of_platform_devices);
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init mgcoge_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+ return of_flat_dt_is_compatible(root, "fsl,mgcoge");
+}
+
+define_machine(mgcoge)
+{
+ .name = "Keymile MGCOGE",
+ .probe = mgcoge_probe,
+ .setup_arch = mgcoge_setup_arch,
+ .init_IRQ = mgcoge_pic_init,
+ .get_irq = cpm2_get_irq,
+ .calibrate_decr = generic_calibrate_decr,
+ .res
[PATCH 0/3] 82xx: MGCOGE support
Hello, the following 4 patches adding support for the MPC8247 based board MGCOGE from keymile. The following Patch posted on this list is also needed, to get the Ethernet over SCC running. http://ozlabs.org/pipermail/linuxppc-dev/2008-January/049681.html bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc32: Weird process scheduling behaviour with 2.6.24-rc
On Mon, 2008-01-28 at 13:56 +0100, Ingo Molnar wrote: > * Peter Zijlstra <[EMAIL PROTECTED]> wrote: > > > > i think it would be OK to do half of this: make it easier to preempt > > > a +nice task. Michel, do you really need the -nice portion as well? > > > It's not a problem to super-preempt positively reniced tasks, but it > > > can be quite annoying if negatively reniced tasks have super-slices. > > > > This should do that (unless I need a stronger cup of tea). > > cool - thanks Peter. Michel, could you check Peter's patch, does it > resolve all the interactivity problems you've been seeing? I'm now running with this patch and Srivatsa's patch, and together they provide good interactivity even with CONFIG_FAIR_USER_SCHED enabled and the default value of /proc/sys/kernel/sched_wakeup_granularity_ns. :) So both patches seem to have the expected effect. /proc/sys/kernel/sched_features contains 7. Thanks, -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
