* Re: [Cbe-oss-dev] [PATCH 3/3] Cell IOMMU static mapping support
From: Olof Johansson @ 2008-01-28 21:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, cbe-oss-dev@ozlabs.org, Arnd Bergmann
In-Reply-To: <1201554977.6815.189.camel@pasglop>
On Tue, Jan 29, 2008 at 08:16:17AM +1100, Benjamin Herrenschmidt wrote:
>
> On Mon, 2008-01-28 at 10:23 -0600, Olof Johansson wrote:
> > Ok, makes sense.
> >
> > I was going to protest the hack for >32GB configs, with the motivation
> > that just using the htab-backed window is way too small for such a
> > config. However, with 32GB memory and 4K pages, that window is 512MB, so
> > we should be fine.
>
> Might be a problem with 64K pages tho... Or do we use the same
> calculation ?
The current code is hardcoded at page shift 12. That's probably the
safest thing to do, since even though PAGE_SHIFT might be 16, if we're
doing the software-based 64K approach we can't use a smaller table.
See htab_get_table_size() in arch/powerpc/mm/hash_utils_64.c.
> In addition, on those blades, really the only device that is limited to
> 32 bits (and thus is forced to use the iommu remapped region) is USB.
>
> > Having that described in the patch (or at least in the patch description)
> > to make it more clear could be good. That, and the fact that the mapping
> > is offset on <32GB memory machines, and thus not really a 1:1 mapping.
>
> Should be called a "linear" mapping.
Yep. Linear with a fixed offset.
> > Does the cell I/O bridge reflect out accesses to 2-4GB on the bus
> > again? If not, that could be another place to stick the dynamic range
> > for large config machines.
>
> On the PCI bus itself, 2-4GB is where MMIO sits.
Depending on the implementation, 2-4GB accesses _from_ PCI could mean
something else. But for most machines it doesn't, and I'm guessing cell
is one of those.
-Olof
^ permalink raw reply
* Re: Patches added to for-2.6.25/master branches of powerpc.git
From: Michael Ellerman @ 2008-01-28 22:08 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200801282119.41403.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]
On Mon, 2008-01-28 at 21:19 +0100, Arnd Bergmann wrote:
> On Sunday 27 January 2008, Michael Ellerman wrote:
> > Can you grab these four assuming there's no objections in the meantime.
> >
> > http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=16430
> > http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=16433
> > http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=16434
> > http://patchwork.ozlabs.org/linuxppc/patch?q=ellerman&id=16437
> >
>
> Yes, they all look good to me, you can add an
> 'Acked-by: Arnd Bergmann <arnd@arndb.de>' if you like.
>
> What about your other series that adds the linear iommu mapping
> for cell blades? Are you still waiting for more feedback and
> testing on that, or can it also go in?
I'd like to clean it up a bit, split the big patch up a bit. I'll try to
do that today or tomorrow. And more testing would definitely be good,
but that's a little tricky from LCA :)
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH] remove section mappinng
From: Badari Pulavarty @ 2008-01-28 22:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-mm, linuxppc-dev, anton
In-Reply-To: <18330.35819.738293.742989@cargo.ozlabs.ibm.com>
On Sat, 2008-01-26 at 12:24 +1100, Paul Mackerras wrote:
> Badari Pulavarty writes:
>
> > Here is the code I cooked up, it seems to be working fine.
> > But I have concerns where I need your help.
> >
> > In order to invalidate htab entries, we need to find the "slot".
> > But I can only find the hpte group. Is it okay to invalidate the
> > first entry in the group ? Do I need to invalidate the entire group ?
>
> You do need to find the correct slot. (I suppose you could invalidate
> the entire group, but that would be pretty gross.)
>
> Note that in the CONFIG_DEBUG_PAGEALLOC case we use 4k pages and keep
> a map of the slot numbers in linear_map_hash_slots[]. But in that
> case I assume that the generic code would have already unmapped all
> the pages of the LMB that you're trying to hot-unplug.
>
> In the non-DEBUG_PAGEALLOC case on a System p machine, the hash table
> will be big enough that the linear mapping entries should always be in
> slot 0. So just invalidating slot 0 would probably work in practice,
> but it seems pretty fragile. We might want to use your new
> htab_remove_mapping() function on a bare-metal system with a smaller
> hash table in future, for instance.
>
> Have a look at pSeries_lpar_hpte_updateboltedpp. It calls
> pSeries_lpar_hpte_find to find the slot for a bolted HPTE. You could
> do something similar. In fact maybe the best approach is to do a
> pSeries_lpar_hpte_remove_bolted() and not try to solve the more
> general problem.
Paul,
Thank you for your input and suggestions. Does this look reasonable
to you ?
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 <pbadari@us.ibm.com>
---
arch/powerpc/mm/hash_utils_64.c | 23 +++++++++++++++++++++++
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.000000000 -0800
+++ linux-2.6.24-rc8/arch/powerpc/mm/hash_utils_64.c 2008-01-28 11:45:40.000000000 -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.000000000 -0800
+++ linux-2.6.24-rc8/include/asm-powerpc/sparsemem.h 2008-01-25 08:18:11.000000000 -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/platforms/pseries/lpar.c
===================================================================
--- linux-2.6.24-rc8.orig/arch/powerpc/platforms/pseries/lpar.c 2008-01-15 20:22:48.000000000 -0800
+++ linux-2.6.24-rc8/arch/powerpc/platforms/pseries/lpar.c 2008-01-28 14:10:58.000000000 -0800
@@ -520,6 +520,20 @@ static void pSeries_lpar_hpte_invalidate
BUG_ON(lpar_rc != H_SUCCESS);
}
+static void pSeries_lpar_hpte_removebolted(unsigned long ea,
+ int psize, int ssize)
+{
+ unsigned long slot, vsid, va;
+
+ vsid = get_kernel_vsid(ea, ssize);
+ va = hpt_va(ea, vsid, ssize);
+
+ slot = pSeries_lpar_hpte_find(va, psize, ssize);
+ BUG_ON(slot == -1);
+
+ pSeries_lpar_hpte_invalidate(slot, va, psize, ssize, 0);
+}
+
/* Flag bits for H_BULK_REMOVE */
#define HBR_REQUEST 0x4000000000000000UL
#define HBR_RESPONSE 0x8000000000000000UL
@@ -597,6 +611,7 @@ void __init hpte_init_lpar(void)
ppc_md.hpte_updateboltedpp = pSeries_lpar_hpte_updateboltedpp;
ppc_md.hpte_insert = pSeries_lpar_hpte_insert;
ppc_md.hpte_remove = pSeries_lpar_hpte_remove;
+ ppc_md.hpte_removebolted = pSeries_lpar_hpte_removebolted;
ppc_md.flush_hash_range = pSeries_lpar_flush_hash_range;
ppc_md.hpte_clear_all = pSeries_lpar_hptab_clear;
}
Index: linux-2.6.24-rc8/include/asm-powerpc/machdep.h
===================================================================
--- linux-2.6.24-rc8.orig/include/asm-powerpc/machdep.h 2008-01-25 08:04:41.000000000 -0800
+++ linux-2.6.24-rc8/include/asm-powerpc/machdep.h 2008-01-28 11:45:17.000000000 -0800
@@ -68,6 +68,8 @@ struct machdep_calls {
unsigned long vflags,
int psize, int ssize);
long (*hpte_remove)(unsigned long hpte_group);
+ void (*hpte_removebolted)(unsigned long ea,
+ int psize, int ssize);
void (*flush_hash_range)(unsigned long number, int local);
/* special for kexec, to be called in real mode, linar mapping is
^ permalink raw reply
* Please pull from 'for-2.6.25' branch (updated)
From: Kumar Gala @ 2008-01-28 22:17 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.25' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.25
to receive the following updates:
Documentation/powerpc/booting-without-of.txt | 177 ++-
arch/powerpc/boot/Makefile | 5
arch/powerpc/boot/cuboot-85xx-cpm2.c | 66 +
arch/powerpc/boot/dts/mpc8313erdb.dts | 156 +-
arch/powerpc/boot/dts/mpc8315erdb.dts | 287 +++++
arch/powerpc/boot/dts/mpc832x_mds.dts | 270 ++--
arch/powerpc/boot/dts/mpc832x_rdb.dts | 177 +--
arch/powerpc/boot/dts/mpc8349emitx.dts | 159 +-
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 113 +-
arch/powerpc/boot/dts/mpc834x_mds.dts | 260 ++--
arch/powerpc/boot/dts/mpc836x_mds.dts | 287 ++---
arch/powerpc/boot/dts/mpc8377_mds.dts | 141 +-
arch/powerpc/boot/dts/mpc8377_rdb.dts | 296 +++++
arch/powerpc/boot/dts/mpc8378_mds.dts | 133 +-
arch/powerpc/boot/dts/mpc8378_rdb.dts | 282 ++++
arch/powerpc/boot/dts/mpc8379_mds.dts | 149 +-
arch/powerpc/boot/dts/mpc8379_rdb.dts | 310 +++++
arch/powerpc/boot/dts/mpc8568mds.dts | 24
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 227 ++--
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 333 ++---
arch/powerpc/boot/dts/sbc8349.dts | 244 ++++
arch/powerpc/boot/dts/sbc8548.dts | 244 ++++
arch/powerpc/boot/dts/sbc8560.dts | 330 +++++
arch/powerpc/boot/dts/storcenter.dts | 73 -
arch/powerpc/boot/dts/stx_gp3_8560.dts | 228 ++++
arch/powerpc/boot/dts/tqm8540.dts | 204 +++
arch/powerpc/boot/dts/tqm8541.dts | 228 ++++
arch/powerpc/boot/dts/tqm8555.dts | 228 ++++
arch/powerpc/boot/dts/tqm8560.dts | 245 ++++
arch/powerpc/boot/libfdt-wrapper.c | 9
arch/powerpc/boot/ops.h | 11
arch/powerpc/configs/mpc8313_rdb_defconfig | 2
arch/powerpc/configs/mpc8315_rdb_defconfig | 1417 +++++++++++++++++++++++++
arch/powerpc/configs/mpc837x_rdb_defconfig | 887 +++++++++++++++
arch/powerpc/configs/mpc83xx_defconfig | 887 +++++++++++++++
arch/powerpc/configs/mpc85xx_defconfig | 1523 +++++++++++++++++++++++++++
arch/powerpc/configs/sbc834x_defconfig | 800 ++++++++++++++
arch/powerpc/configs/sbc8548_defconfig | 741 +++++++++++++
arch/powerpc/configs/sbc8560_defconfig | 764 +++++++++++++
arch/powerpc/configs/stx_gp3_defconfig | 1183 ++++++++++++++++++++
arch/powerpc/configs/tqm8540_defconfig | 1032 ++++++++++++++++++
arch/powerpc/configs/tqm8541_defconfig | 1044 ++++++++++++++++++
arch/powerpc/configs/tqm8555_defconfig | 1044 ++++++++++++++++++
arch/powerpc/configs/tqm8560_defconfig | 1044 ++++++++++++++++++
arch/powerpc/kernel/legacy_serial.c | 45
arch/powerpc/kernel/misc_32.S | 10
arch/powerpc/platforms/82xx/mpc8272_ads.c | 5
arch/powerpc/platforms/82xx/pq2fads.c | 5
arch/powerpc/platforms/83xx/Kconfig | 62 -
arch/powerpc/platforms/83xx/Makefile | 4
arch/powerpc/platforms/83xx/mpc8313_rdb.c | 101 -
arch/powerpc/platforms/83xx/mpc831x_rdb.c | 93 +
arch/powerpc/platforms/83xx/mpc832x_mds.c | 11
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 11
arch/powerpc/platforms/83xx/mpc836x_mds.c | 11
arch/powerpc/platforms/83xx/mpc837x_rdb.c | 99 +
arch/powerpc/platforms/83xx/sbc834x.c | 115 ++
arch/powerpc/platforms/83xx/usb.c | 4
arch/powerpc/platforms/85xx/Kconfig | 87 +
arch/powerpc/platforms/85xx/Makefile | 4
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 32
arch/powerpc/platforms/85xx/sbc8548.c | 167 ++
arch/powerpc/platforms/85xx/sbc8560.c | 283 +++++
arch/powerpc/platforms/85xx/stx_gp3.c | 183 +++
arch/powerpc/platforms/85xx/tqm85xx.c | 187 +++
arch/powerpc/platforms/8xx/ep88xc.c | 5
arch/powerpc/platforms/8xx/m8xx_setup.c | 11
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 8
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 7
arch/powerpc/platforms/8xx/mpc8xx.h | 21
arch/powerpc/platforms/Kconfig | 6
arch/powerpc/platforms/Kconfig.cputype | 10
arch/powerpc/platforms/embedded6xx/ls_uart.c | 5
arch/powerpc/sysdev/Makefile | 4
arch/powerpc/sysdev/commproc.c | 650 -----------
arch/powerpc/sysdev/commproc.h | 12
arch/powerpc/sysdev/cpm1.c | 612 ++++++++++
arch/powerpc/sysdev/cpm2.c | 469 ++++++++
arch/powerpc/sysdev/cpm2_common.c | 470 --------
arch/powerpc/sysdev/fsl_soc.c | 99 +
arch/powerpc/sysdev/ipic.c | 6
arch/powerpc/sysdev/micropatch.c | 2
arch/powerpc/sysdev/mpc8xx_pic.c | 1
arch/powerpc/sysdev/qe_lib/qe.c | 63 -
arch/ppc/8260_io/enet.c | 2
arch/ppc/8xx_io/commproc.c | 40
arch/ppc/8xx_io/enet.c | 6
arch/ppc/8xx_io/fec.c | 2
arch/ppc/8xx_io/micropatch.c | 2
arch/ppc/Kconfig | 91 -
arch/ppc/Makefile | 9
arch/ppc/boot/simple/iic.c | 2
arch/ppc/boot/simple/m8xx_tty.c | 2
arch/ppc/configs/TQM8540_defconfig | 973 -----------------
arch/ppc/configs/TQM8541_defconfig | 986 -----------------
arch/ppc/configs/TQM8555_defconfig | 983 -----------------
arch/ppc/configs/TQM8560_defconfig | 992 -----------------
arch/ppc/configs/mpc834x_sys_defconfig | 844 --------------
arch/ppc/configs/mpc8540_ads_defconfig | 706 ------------
arch/ppc/configs/mpc8548_cds_defconfig | 658 -----------
arch/ppc/configs/mpc8555_cds_defconfig | 784 -------------
arch/ppc/configs/mpc8560_ads_defconfig | 769 -------------
arch/ppc/configs/stx_gp3_defconfig | 989 -----------------
arch/ppc/kernel/Makefile | 1
arch/ppc/kernel/asm-offsets.c | 6
arch/ppc/kernel/entry.S | 12
arch/ppc/kernel/head_booke.h | 55
arch/ppc/kernel/head_fsl_booke.S | 1065 ------------------
arch/ppc/kernel/misc.S | 46
arch/ppc/kernel/ppc_ksyms.c | 11
arch/ppc/kernel/setup.c | 3
arch/ppc/kernel/traps.c | 121 --
arch/ppc/mm/Makefile | 1
arch/ppc/mm/fsl_booke_mmu.c | 236 ----
arch/ppc/mm/init.c | 6
arch/ppc/mm/mmu_context.c | 2
arch/ppc/mm/mmu_decl.h | 6
arch/ppc/mm/pgtable.c | 28
arch/ppc/mm/ppc_mmu.c | 2
arch/ppc/platforms/83xx/Makefile | 4
arch/ppc/platforms/83xx/mpc834x_sys.c | 346 ------
arch/ppc/platforms/83xx/mpc834x_sys.h | 54
arch/ppc/platforms/85xx/Kconfig | 106 -
arch/ppc/platforms/85xx/Makefile | 13
arch/ppc/platforms/85xx/mpc8540_ads.c | 226 ----
arch/ppc/platforms/85xx/mpc8540_ads.h | 22
arch/ppc/platforms/85xx/mpc8555_cds.h | 23
arch/ppc/platforms/85xx/mpc8560_ads.c | 303 -----
arch/ppc/platforms/85xx/mpc8560_ads.h | 24
arch/ppc/platforms/85xx/mpc85xx_ads_common.c | 197 ---
arch/ppc/platforms/85xx/mpc85xx_ads_common.h | 67 -
arch/ppc/platforms/85xx/mpc85xx_cds_common.c | 601 ----------
arch/ppc/platforms/85xx/mpc85xx_cds_common.h | 80 -
arch/ppc/platforms/85xx/sbc8560.c | 234 ----
arch/ppc/platforms/85xx/sbc8560.h | 47
arch/ppc/platforms/85xx/sbc85xx.c | 166 --
arch/ppc/platforms/85xx/sbc85xx.h | 70 -
arch/ppc/platforms/85xx/stx_gp3.c | 339 ------
arch/ppc/platforms/85xx/stx_gp3.h | 69 -
arch/ppc/platforms/85xx/tqm85xx.c | 412 -------
arch/ppc/platforms/85xx/tqm85xx.h | 53
arch/ppc/platforms/mpc866ads_setup.c | 2
arch/ppc/platforms/mpc885ads_setup.c | 2
arch/ppc/syslib/Makefile | 13
arch/ppc/syslib/ipic.c | 646 -----------
arch/ppc/syslib/ipic.h | 47
arch/ppc/syslib/mpc83xx_devices.c | 251 ----
arch/ppc/syslib/mpc83xx_sys.c | 122 --
arch/ppc/syslib/mpc85xx_devices.c | 826 --------------
arch/ppc/syslib/mpc85xx_sys.c | 233 ----
arch/ppc/syslib/mpc8xx_devices.c | 2
arch/ppc/syslib/ocp.c | 2
arch/ppc/syslib/open_pic.c | 2
arch/ppc/syslib/ppc83xx_pci.h | 151 --
arch/ppc/syslib/ppc83xx_setup.c | 410 -------
arch/ppc/syslib/ppc83xx_setup.h | 55
arch/ppc/syslib/ppc85xx_common.c | 38
arch/ppc/syslib/ppc85xx_common.h | 22
arch/ppc/syslib/ppc85xx_setup.c | 367 ------
arch/ppc/syslib/ppc85xx_setup.h | 56
arch/ppc/syslib/ppc8xx_pic.h | 1
arch/ppc/xmon/start_8xx.c | 2
drivers/ata/Kconfig | 2
drivers/net/Kconfig | 2
drivers/net/fec_8xx/fec_8xx-netta.c | 2
drivers/net/fec_8xx/fec_main.c | 2
drivers/net/fec_8xx/fec_mii.c | 2
drivers/net/fs_enet/fs_enet.h | 2
drivers/net/fs_enet/mac-fec.c | 2
drivers/net/fs_enet/mac-scc.c | 2
drivers/net/ucc_geth_mii.c | 3
drivers/pci/Makefile | 2
drivers/serial/cpm_uart/cpm_uart_cpm1.h | 2
drivers/spi/spi_mpc83xx.c | 6
include/asm-powerpc/commproc.h | 752 -------------
include/asm-powerpc/cpm.h | 73 +
include/asm-powerpc/cpm1.h | 685 ++++++++++++
include/asm-powerpc/cpm2.h | 64 -
include/asm-powerpc/irq.h | 212 ---
include/asm-powerpc/mpc8xx.h | 20
include/asm-ppc/commproc.h | 692 ------------
include/asm-ppc/cpm1.h | 688 ++++++++++++
include/asm-ppc/cpm2.h | 2
include/asm-ppc/immap_85xx.h | 126 --
include/asm-ppc/mmu_context.h | 5
include/asm-ppc/mpc83xx.h | 107 -
include/asm-ppc/mpc85xx.h | 192 ---
include/asm-ppc/pgtable.h | 46
include/asm-ppc/ppc_sys.h | 4
include/asm-ppc/ppcboot.h | 8
include/asm-ppc/reg_booke.h | 26
include/asm-ppc/serial.h | 4
192 files changed, 21067 insertions(+), 22059 deletions(-)
Anton Vorontsov (4):
[POWERPC] QE: get rid of most device_types and model
ucc_geth: get rid of device_type for mdio
spi_mpc83xx: use brg-frequency for SPI in QE
[POWERPC] fsl_spi: stop using device_type = "spi"
Grant Likely (1):
[POWERPC] 82xx and embedded6xx: Use machine_*_initcall() hooks in platform code
Jochen Friedrich (7):
[POWERPC] 8xx: Remove unused m8xx_cpm_hostalloc/free/dump()
[POWERPC] 8xx: Rename m8xx_pic_init to mpc8xx_pics_init
[POWERPC] 8xx: Remove unneeded and misspelled prototype m8xx_calibrate_decr
[POWERPC] 8xx: Remove sysdev/commproc.h
[POWERPC] 8xx: Get rid of conditional includes of board specific setup
[POWERPC] CPM: Rename commproc to cpm1 and cpm2_common.c to cpm2.c
[POWERPC] CPM: Move definition of buffer descriptor to cpm.h
Jon Loeliger (2):
[POWERPC] 86xx: Convert all 86xx DTS files to /dts-v1/ format.
[POWERPC] Convert StorCenter DTS file to /dts-v1/ format.
Kim Phillips (10):
[POWERPC] 83xx: fold the mpc8313 platform into the mpc831x platform
[POWERPC] 83xx: add base platform support for the mpc8315 rdb board
[POWERPC] 83xx: Add the MPC8315E RDB dts
[POWERPC] 83xx: enable FSL SATA driver config for Freescale SoCs
[POWERPC] 83xx: ipic: add interrupt vector 94
[POWERPC] 83xx: add the mpc8315 rdb defconfig
[POWERPC] 83xx: add MPC837x RDB platform support
[POWERPC] 83xx: add the mpc837[789]_rdb dts files
[POWERPC] 83xx: add the mpc837x rdb defconfig
[POWERPC] 83xx: Fix typo in mpc837x compatible entries
Kumar Gala (13):
[POWERPC] Always build setup-bus.c on powerpc
[POWERPC] bootwrapper: Add find_node_by_compatible
[POWERPC] Add a cuboot wrapper for 85xx with CPM2
[POWERPC] 85xx: Port STX GP3 board over from arch/ppc
[POWERPC] 85xx: Port TQM85xx boards over from arch/ppc
[POWERPC] 85xx: some minor cleanups for stx_gp3 and tqm85xx
[PPC] Remove 83xx from arch/ppc
[PPC] Remove 85xx from arch/ppc
[POWERPC] 86xx: Remove unused IRQ defines
[POWERPC] 85xx: rework platform Kconfig
[POWERPC] 83xx: rework platform Kconfig
[POWERPC] 85xx: convert sbc85* boards to use machine_device_initcall
[POWERPC] 85xx: Only invalidate TLB0 and TLB1
Li Yang (1):
[POWERPC] Add docs for Freescale PowerQUICC SATA device tree nodes
Paul Gortmaker (14):
[POWERPC] Reduce code duplication in legacy_serial, add UART parent types
[POWERPC] 85xx: Add support for Wind River SBC8560 in arch/powerpc
[POWERPC] 85xx: Add v1 device tree source for Wind River SBC8560 board
[POWERPC] CPM2: Make support for the CPM2 optional on 8560 based boards
[POWERPC] 85xx: Add default .config file for Wind River SBC8560
[POWERPC] 85xx: Add basic support for Wind River SBC8548 board
[POWERPC] 85xx: Add v1 device tree source for Wind River SBC8548 board
[POWERPC] 85xx: Add default .config file for Wind River SBC8548
[POWERPC] 83xx: Add support for Wind River SBC834x boards
[POWERPC] 83xx: Add device tree source for Wind River SBC834x board.
[POWERPC] 83xx: Add default config file for Wind River SBC8349 board
[POWERPC] 83xx: mpc834x_mds - Convert device tree source to dts-v1
[POWERPC] QE: Explicitly set address-cells and size cells for muram
[POWERPC] 83xx: Clean up / convert mpc83xx board DTS files to v1 format.
Zhang Wei (1):
[POWERPC] Add docs for Freescale DMA & DMA channel device tree nodes
^ permalink raw reply
* Re: [PATCH] powerpc: fix typo in mpc837x compatible entries
From: Kumar Gala @ 2008-01-28 22:19 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20080128130037.db88184d.kim.phillips@freescale.com>
On Mon, 28 Jan 2008, Kim Phillips wrote:
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> arch/powerpc/boot/dts/mpc8377_rdb.dts | 2 +-
> arch/powerpc/boot/dts/mpc8378_rdb.dts | 2 +-
> arch/powerpc/boot/dts/mpc8379_rdb.dts | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts b/arch/powerpc/boot/dts/mpc8377_rdb.dts
applied.
- k
^ permalink raw reply
* Re: [PATCH] 83xx: Clean up / convert mpc83xx board DTS files to v1 format.
From: Kumar Gala @ 2008-01-28 22:19 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev
In-Reply-To: <1201554576-32653-1-git-send-email-paul.gortmaker@windriver.com>
On Mon, 28 Jan 2008, Paul Gortmaker wrote:
> This patch converts the remaining 83xx boards to the dts-v1 format.
> This includes the mpc8313_rdb, mpc832x_mds, mpc8323_rdb, mpc8349emitx,
> mpc8349emitxgp and the mpc836x_mds.
>
> The mpc8315_rdb mpc834x_mds, mpc837[789]_*, and sbc8349 were already
> dts-v1 and only undergo minor changes for the sake of formatting
> consistency across the whole group of boards; i.e. the idea being
> that you can do a "diff -u board_A.dts board_B.dts" and see something
> meaningful.
>
> The general rule I've applied is that entries for values normally
> parsed by humans are left in decimal (i.e. IRQ, cache size, clock
> rates, basic counts and indexes) and all other data (i.e. reg and
> ranges, IRQ flags etc.) remain in hex.
>
> I've used dtc to confirm that the output prior to this changeset
> matches the output after this changeset is applied for all boards.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
> arch/powerpc/boot/dts/mpc8313erdb.dts | 152 +++++++++---------
> arch/powerpc/boot/dts/mpc8315erdb.dts | 100 ++++++------
> arch/powerpc/boot/dts/mpc832x_mds.dts | 252 +++++++++++++++--------------
> arch/powerpc/boot/dts/mpc832x_rdb.dts | 154 +++++++++---------
> arch/powerpc/boot/dts/mpc8349emitx.dts | 155 +++++++++---------
> arch/powerpc/boot/dts/mpc8349emitxgp.dts | 109 +++++++------
> arch/powerpc/boot/dts/mpc834x_mds.dts | 36 ++--
> arch/powerpc/boot/dts/mpc836x_mds.dts | 260 +++++++++++++++---------------
> arch/powerpc/boot/dts/mpc8377_mds.dts | 138 ++++++++--------
> arch/powerpc/boot/dts/mpc8377_rdb.dts | 102 ++++++------
> arch/powerpc/boot/dts/mpc8378_mds.dts | 130 ++++++++--------
> arch/powerpc/boot/dts/mpc8378_rdb.dts | 94 ++++++------
> arch/powerpc/boot/dts/mpc8379_mds.dts | 146 +++++++++---------
> arch/powerpc/boot/dts/mpc8379_rdb.dts | 112 +++++++-------
> arch/powerpc/boot/dts/sbc8349.dts | 44 +++---
> 15 files changed, 999 insertions(+), 985 deletions(-)
>
applied. Checkout for whitespace in the future (sbc8349.dts)
- k
^ permalink raw reply
* Re: [PATCH] 83xx: Clean up / convert mpc83xx board DTS files to v1 format.
From: Paul Gortmaker @ 2008-01-28 22:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0801281619040.28029@blarg.am.freescale.net>
Kumar Gala wrote:
> On Mon, 28 Jan 2008, Paul Gortmaker wrote:
>
>
>> This patch converts the remaining 83xx boards to the dts-v1 format.
>> This includes the mpc8313_rdb, mpc832x_mds, mpc8323_rdb, mpc8349emitx,
>> mpc8349emitxgp and the mpc836x_mds.
>>
>> The mpc8315_rdb mpc834x_mds, mpc837[789]_*, and sbc8349 were already
>> dts-v1 and only undergo minor changes for the sake of formatting
>> consistency across the whole group of boards; i.e. the idea being
>> that you can do a "diff -u board_A.dts board_B.dts" and see something
>> meaningful.
>>
>> The general rule I've applied is that entries for values normally
>> parsed by humans are left in decimal (i.e. IRQ, cache size, clock
>> rates, basic counts and indexes) and all other data (i.e. reg and
>> ranges, IRQ flags etc.) remain in hex.
>>
>> I've used dtc to confirm that the output prior to this changeset
>> matches the output after this changeset is applied for all boards.
>>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>> ---
>> arch/powerpc/boot/dts/mpc8313erdb.dts | 152 +++++++++---------
>> arch/powerpc/boot/dts/mpc8315erdb.dts | 100 ++++++------
>> arch/powerpc/boot/dts/mpc832x_mds.dts | 252 +++++++++++++++--------------
>> arch/powerpc/boot/dts/mpc832x_rdb.dts | 154 +++++++++---------
>> arch/powerpc/boot/dts/mpc8349emitx.dts | 155 +++++++++---------
>> arch/powerpc/boot/dts/mpc8349emitxgp.dts | 109 +++++++------
>> arch/powerpc/boot/dts/mpc834x_mds.dts | 36 ++--
>> arch/powerpc/boot/dts/mpc836x_mds.dts | 260 +++++++++++++++---------------
>> arch/powerpc/boot/dts/mpc8377_mds.dts | 138 ++++++++--------
>> arch/powerpc/boot/dts/mpc8377_rdb.dts | 102 ++++++------
>> arch/powerpc/boot/dts/mpc8378_mds.dts | 130 ++++++++--------
>> arch/powerpc/boot/dts/mpc8378_rdb.dts | 94 ++++++------
>> arch/powerpc/boot/dts/mpc8379_mds.dts | 146 +++++++++---------
>> arch/powerpc/boot/dts/mpc8379_rdb.dts | 112 +++++++-------
>> arch/powerpc/boot/dts/sbc8349.dts | 44 +++---
>> 15 files changed, 999 insertions(+), 985 deletions(-)
>>
>>
>
> applied. Checkout for whitespace in the future (sbc8349.dts)
>
Oops -- leaked one space in my rush to get it done and to
you today. Thanks for catching it.
P.
> - k
>
^ permalink raw reply
* Re: Preferred GIT URL for arch/powerpc, and BINUTILS
From: Steve Heflin @ 2008-01-28 22:46 UTC (permalink / raw)
To: linuxppc-embedded
At 02:30 PM 1/28/2008, Steve Heflin wrote:
>Josh, you're a life saver!! Your GIT tree is exactly what I've been
>looking for. I have an AMCC440EPx based product that makes heavy use
>of all the devices embedded in the microcontroller. I'll be able to
>give that platform a very good testing.
>
>Now can you help me with BINUTILS? What version do you use and can
>you point me to a decent GIT tree for it? I tried to use version
>2.18 and the build blows up because it tries to "strip" a script file
>"embedspu".
Whoa! I spoke too soon. Upon attempting a "make menuconfig" on the
2.6.24-rc8 which I cloned from your git tree, I don't even SEE the
powerpc architecture appearing! What's up?
^ permalink raw reply
* Re: Linux boot on a ppc 405
From: Ricardo Ayres Severo @ 2008-01-28 22:53 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <fa686aa40801271315m5ba4ea08p913fd6235eb1d240@mail.gmail.com>
Grant,
my output is the following:
loaded at: 00400000 004E919C
board data at: 00000000 0000007C
relocated to: 00404040 004040BC
zimage at: 00404E2C 004E620A
avail ram: 004EA000 8DA05119
Linux/PPC load: console=ttyUL0,9600
Uncompressing Linux...done.
Now booting the kernel
nothing shows up next.
I tried to look at __log_buf but the debugger doesn't recognize it.
The debugger only knows the code of the part that boots the kernel.
I also tried setting ttyUL0 and ttyS0 for the linux console.
Any ideas of how I can get the real position of __log_buf?
Thanks,
On Jan 27, 2008 7:15 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 1/27/08, Ricardo Severo <severo.ricardo@gmail.com> wrote:
> > Hi all,
> >
> > I am working with a Xilinx Virtex II Pro evaluation board, wich has two
> > PowerPC 405 and I'm trying to boot a vanilla linux kernel 2.6.23.14.
> > Until now I've manged to make it uncompress the kernel, but it doesn't boot.
> > My question is how the initial execution (the one who uncompresses the
> > kernel image) transfers the processor to the kernel itself. I've looked
> > in the arch/ppc/boot/simple/relocate.S code and it jumps to the position
> > 0x0 after uncompressing, is it right? The kernel is uncompressed at that
> > position?
>
> Post your output log please.
>
> If your getting a message that the kernel is uncompressing, but you
> don't have any output beyond that then most likely your console is not
> setup correctly. If you've got a debugger, look at memory at the
> __log_buf location to see if there are any boot logs there.
>
> Cheers,
> g.
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
--
Ricardo Ayres Severo <severo.ricardo@gmail.com>
^ permalink raw reply
* RE: Linux boot on a ppc 405
From: Stephen Neuendorffer @ 2008-01-28 22:55 UTC (permalink / raw)
To: Ricardo Ayres Severo; +Cc: linuxppc-embedded
In-Reply-To: <5ee408090801281453l3e6fe3e5x2f8f1b0b130ad163@mail.gmail.com>
You have to look at the System.map file, find the __log_buf symbol, and
then look at the address manually.
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Ricardo
Ayres Severo
> Sent: Monday, January 28, 2008 2:53 PM
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux boot on a ppc 405
>=20
> Grant,
>=20
> my output is the following:
>=20
> loaded at: 00400000 004E919C
>=20
> board data at: 00000000 0000007C
>=20
> relocated to: 00404040 004040BC
>=20
> zimage at: 00404E2C 004E620A
>=20
> avail ram: 004EA000 8DA05119
>=20
>=20
> Linux/PPC load: console=3DttyUL0,9600
>=20
> Uncompressing Linux...done.
>=20
> Now booting the kernel
>=20
>=20
>=20
> nothing shows up next.
> I tried to look at __log_buf but the debugger doesn't recognize it.
> The debugger only knows the code of the part that boots the kernel.
> I also tried setting ttyUL0 and ttyS0 for the linux console.
> Any ideas of how I can get the real position of __log_buf?
>=20
> Thanks,
>=20
> On Jan 27, 2008 7:15 PM, Grant Likely <grant.likely@secretlab.ca>
wrote:
> > On 1/27/08, Ricardo Severo <severo.ricardo@gmail.com> wrote:
> > > Hi all,
> > >
> > > I am working with a Xilinx Virtex II Pro evaluation board, wich
has two
> > > PowerPC 405 and I'm trying to boot a vanilla linux kernel
2.6.23.14.
> > > Until now I've manged to make it uncompress the kernel, but it
doesn't boot.
> > > My question is how the initial execution (the one who uncompresses
the
> > > kernel image) transfers the processor to the kernel itself. I've
looked
> > > in the arch/ppc/boot/simple/relocate.S code and it jumps to the
position
> > > 0x0 after uncompressing, is it right? The kernel is uncompressed
at that
> > > position?
> >
> > Post your output log please.
> >
> > If your getting a message that the kernel is uncompressing, but you
> > don't have any output beyond that then most likely your console is
not
> > setup correctly. If you've got a debugger, look at memory at the
> > __log_buf location to see if there are any boot logs there.
> >
> > Cheers,
> > g.
> >
> >
> > --
> > Grant Likely, B.Sc., P.Eng.
> > Secret Lab Technologies Ltd.
> >
>=20
>=20
>=20
> --
> Ricardo Ayres Severo <severo.ricardo@gmail.com>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Linux boot on a ppc 405
From: Ricardo Ayres Severo @ 2008-01-28 23:00 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-embedded
In-Reply-To: <20080128225505.22226C20071@mail131-dub.bigfish.com>
Steve,
I tried that, but the System.map is not the real memory address, it's
processed by the mmu isn't it?
This is my System.map: c01e0cc4 b __log_buf
when I try to look at the position 0xc01e0cc4 the debugger returns:
Error: Cannot access memory at address 0xc01e0cc4
Am I doing something wrong?
Thanks,
On Jan 28, 2008 8:55 PM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>
> You have to look at the System.map file, find the __log_buf symbol, and
> then look at the address manually.
>
> Steve
>
>
> > -----Original Message-----
> > From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org
> [mailto:linuxppc-embedded-
> > bounces+stephen=neuendorffer.name@ozlabs.org] On Behalf Of Ricardo
> Ayres Severo
> > Sent: Monday, January 28, 2008 2:53 PM
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: Linux boot on a ppc 405
> >
> > Grant,
> >
> > my output is the following:
> >
> > loaded at: 00400000 004E919C
> >
> > board data at: 00000000 0000007C
> >
> > relocated to: 00404040 004040BC
> >
> > zimage at: 00404E2C 004E620A
> >
> > avail ram: 004EA000 8DA05119
> >
> >
> > Linux/PPC load: console=ttyUL0,9600
> >
> > Uncompressing Linux...done.
> >
> > Now booting the kernel
> >
> >
> >
> > nothing shows up next.
> > I tried to look at __log_buf but the debugger doesn't recognize it.
> > The debugger only knows the code of the part that boots the kernel.
> > I also tried setting ttyUL0 and ttyS0 for the linux console.
> > Any ideas of how I can get the real position of __log_buf?
> >
> > Thanks,
> >
> > On Jan 27, 2008 7:15 PM, Grant Likely <grant.likely@secretlab.ca>
> wrote:
> > > On 1/27/08, Ricardo Severo <severo.ricardo@gmail.com> wrote:
> > > > Hi all,
> > > >
> > > > I am working with a Xilinx Virtex II Pro evaluation board, wich
> has two
> > > > PowerPC 405 and I'm trying to boot a vanilla linux kernel
> 2.6.23.14.
> > > > Until now I've manged to make it uncompress the kernel, but it
> doesn't boot.
> > > > My question is how the initial execution (the one who uncompresses
> the
> > > > kernel image) transfers the processor to the kernel itself. I've
> looked
> > > > in the arch/ppc/boot/simple/relocate.S code and it jumps to the
> position
> > > > 0x0 after uncompressing, is it right? The kernel is uncompressed
> at that
> > > > position?
> > >
> > > Post your output log please.
> > >
> > > If your getting a message that the kernel is uncompressing, but you
> > > don't have any output beyond that then most likely your console is
> not
> > > setup correctly. If you've got a debugger, look at memory at the
> > > __log_buf location to see if there are any boot logs there.
> > >
> > > Cheers,
> > > g.
> > >
> > >
> > > --
> > > Grant Likely, B.Sc., P.Eng.
> > > Secret Lab Technologies Ltd.
> > >
> >
> >
> >
> > --
> > Ricardo Ayres Severo <severo.ricardo@gmail.com>
>
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
>
--
Ricardo Ayres Severo <severo.ricardo@gmail.com>
^ permalink raw reply
* RE: Linux boot on a ppc 405
From: Stephen Neuendorffer @ 2008-01-28 23:02 UTC (permalink / raw)
To: Ricardo Ayres Severo; +Cc: linuxppc-embedded
In-Reply-To: <5ee408090801281500q467fe03anf00a5a31a5473846@mail.gmail.com>
I've you've reset the processor, then the MMU has been reset too, in
which case your
log_buf will most likely be at 1e0cc4. The 'trick' is that resetting
the processor
leaves the memory intact.
Steve
> -----Original Message-----
> From: Ricardo Ayres Severo [mailto:severo.ricardo@gmail.com]
> Sent: Monday, January 28, 2008 3:00 PM
> To: Stephen Neuendorffer
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux boot on a ppc 405
>=20
> Steve,
>=20
> I tried that, but the System.map is not the real memory address, it's
> processed by the mmu isn't it?
>=20
> This is my System.map: c01e0cc4 b __log_buf
> when I try to look at the position 0xc01e0cc4 the debugger returns:
> Error: Cannot access memory at address 0xc01e0cc4
>=20
> Am I doing something wrong?
>=20
> Thanks,
>=20
> On Jan 28, 2008 8:55 PM, Stephen Neuendorffer
> <stephen.neuendorffer@xilinx.com> wrote:
> >
> > You have to look at the System.map file, find the __log_buf symbol,
and
> > then look at the address manually.
> >
> > Steve
> >
> >
> > > -----Original Message-----
> > > From:
linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> > [mailto:linuxppc-embedded-
> > > bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of =
Ricardo
> > Ayres Severo
> > > Sent: Monday, January 28, 2008 2:53 PM
> > > Cc: linuxppc-embedded@ozlabs.org
> > > Subject: Re: Linux boot on a ppc 405
> > >
> > > Grant,
> > >
> > > my output is the following:
> > >
> > > loaded at: 00400000 004E919C
> > >
> > > board data at: 00000000 0000007C
> > >
> > > relocated to: 00404040 004040BC
> > >
> > > zimage at: 00404E2C 004E620A
> > >
> > > avail ram: 004EA000 8DA05119
> > >
> > >
> > > Linux/PPC load: console=3DttyUL0,9600
> > >
> > > Uncompressing Linux...done.
> > >
> > > Now booting the kernel
> > >
> > >
> > >
> > > nothing shows up next.
> > > I tried to look at __log_buf but the debugger doesn't recognize
it.
> > > The debugger only knows the code of the part that boots the
kernel.
> > > I also tried setting ttyUL0 and ttyS0 for the linux console.
> > > Any ideas of how I can get the real position of __log_buf?
> > >
> > > Thanks,
> > >
> > > On Jan 27, 2008 7:15 PM, Grant Likely <grant.likely@secretlab.ca>
> > wrote:
> > > > On 1/27/08, Ricardo Severo <severo.ricardo@gmail.com> wrote:
> > > > > Hi all,
> > > > >
> > > > > I am working with a Xilinx Virtex II Pro evaluation board,
wich
> > has two
> > > > > PowerPC 405 and I'm trying to boot a vanilla linux kernel
> > 2.6.23.14.
> > > > > Until now I've manged to make it uncompress the kernel, but it
> > doesn't boot.
> > > > > My question is how the initial execution (the one who
uncompresses
> > the
> > > > > kernel image) transfers the processor to the kernel itself.
I've
> > looked
> > > > > in the arch/ppc/boot/simple/relocate.S code and it jumps to
the
> > position
> > > > > 0x0 after uncompressing, is it right? The kernel is
uncompressed
> > at that
> > > > > position?
> > > >
> > > > Post your output log please.
> > > >
> > > > If your getting a message that the kernel is uncompressing, but
you
> > > > don't have any output beyond that then most likely your console
is
> > not
> > > > setup correctly. If you've got a debugger, look at memory at
the
> > > > __log_buf location to see if there are any boot logs there.
> > > >
> > > > Cheers,
> > > > g.
> > > >
> > > >
> > > > --
> > > > Grant Likely, B.Sc., P.Eng.
> > > > Secret Lab Technologies Ltd.
> > > >
> > >
> > >
> > >
> > > --
> > > Ricardo Ayres Severo <severo.ricardo@gmail.com>
> >
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
> >
>=20
>=20
>=20
> --
> Ricardo Ayres Severo <severo.ricardo@gmail.com>
^ permalink raw reply
* Re: Linux boot on a ppc 405
From: Grant Likely @ 2008-01-28 23:04 UTC (permalink / raw)
To: Ricardo Ayres Severo; +Cc: Stephen Neuendorffer, linuxppc-embedded
In-Reply-To: <5ee408090801281500q467fe03anf00a5a31a5473846@mail.gmail.com>
On 1/28/08, Ricardo Ayres Severo <severo.ricardo@gmail.com> wrote:
> Steve,
>
> I tried that, but the System.map is not the real memory address, it's
> processed by the mmu isn't it?
>
> This is my System.map: c01e0cc4 b __log_buf
> when I try to look at the position 0xc01e0cc4 the debugger returns:
> Error: Cannot access memory at address 0xc01e0cc4
Drop the kernel offset of 0xc0000000
So; 0xc01e0cc4 becomes 0x001e0cc4 after reset.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: PATCH[1/1] 8xx: Add clock-frequency to .dts brg entries
From: Bryan O'Donoghue @ 2008-01-28 23:55 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20080128155012.GA27054@ld0162-tx32.am.freescale.net>
On Mon, 2008-01-28 at 09:50 -0600, Scott Wood wrote:
> On Mon, Jan 28, 2008 at 01:53:11AM +0000, Bryan O'Donoghue wrote:
> > cpm_uart_core has a dependency on fsl,cpm-brg/clock-frequency, this
> > means that a .dts that uses the cpm uart driver needs to supply a
> > clock-frequency entry for get_brgfreq to return a meaningful number.
> >
> > Included is a patchset which adds the correct brgclk to the adder port -
> > @ 50Mhz and also adds an entry for mpc885ads - which I've noticed is
> > missing a clock-frequency entry.
>
> It's not missing -- it's added by the bootwrapper.
>
> -Scott
Hmm..
You mean that arch/powerpc/boot/mpc8xx.c mpc8xx_set_clocks is supposed
to be adding this field ?
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
dtc -O -o adder875-uboot.dtb arch/powerpc/boot/dts/adder875-uboot.dtb
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
So unless I'm not understanding the structure of the tree - possible - I
don't see how /soc/cpm/brg => clock-frequency could /possibly/ satisfy
get_brgfreq in fsl_soc.c
If there's something other then making a uImage and dtb and booting
these from u-boot that I'm supposed to be doing here ... it'd help if
you could say..
Otherwise in order to get the UART working using a uImage + dbt I've
found it necessary to add this field to the .dts....
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...
What do you think ?
^ permalink raw reply
* Re: [PATCH] [NET]: Remove PowerPC code from fec.c
From: Greg Ungerer @ 2008-01-28 23:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-m68k, uClinux list, Kernel, Linux, linuxppc-dev list,
netdev@vger.kernel.org, Scott Wood, Garzik, Jeff
In-Reply-To: <Pine.LNX.4.64.0801251544480.13060@anakin>
> ---------- Forwarded message ----------
> Date: Fri, 25 Jan 2008 15:33:45 +0100
> From: Jochen Friedrich <jochen@scram.de>
> To: "Garzik, Jeff" <jgarzik@pobox.com>
> Cc: Vitaly Bordug <vitb@kernel.crashing.org>,
> Scott Wood <scottwood@freescale.com>,
> Kumar Gala <galak@kernel.crashing.org>,
> Geert Uytterhoeven <geert@linux-m68k.org>,
> "Kernel, Linux" <linux-kernel@vger.kernel.org>,
> "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
> linuxppc-dev list <linuxppc-dev@ozlabs.org>,
linux-m68k@vger.kernel.org
> Subject: [PATCH] [NET]: Remove PowerPC code from fec.c
>
> fec.c is only used on M68k Coldfire CPUs. Remove leftover
> PowerPC code from this driver.
I was always hoping that this driver would be supported on both
architectures. After all the underlying eth device is essentially
the same on both.
Anyway... I don't have a problem with this patch, looks ok
the me.
Acked-by: Greg Ungerer <gerg@uclinux.org>
Regards
Greg
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
> ---
> drivers/net/fec.c | 136
+---------------------------------------------------
> 1 files changed, 3 insertions(+), 133 deletions(-)
>
> diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> index 0fbf1bb..0499cbb 100644
> --- a/drivers/net/fec.c
> +++ b/drivers/net/fec.c
> @@ -23,6 +23,9 @@
> *
> * Bug fixes and cleanup by Philippe De Muyter (phdm@macqel.be)
> * Copyright (c) 2004-2006 Macq Electronique SA.
> + *
> + * This driver is now only used on ColdFire processors. Remove
conditional
> + * Powerpc code.
> */
>
> #include <linux/module.h>
> @@ -49,17 +52,9 @@
> #include <asm/pgtable.h>
> #include <asm/cacheflush.h>
>
> -#if defined(CONFIG_M523x) || defined(CONFIG_M527x) || \
> - defined(CONFIG_M5272) || defined(CONFIG_M528x) || \
> - defined(CONFIG_M520x) || defined(CONFIG_M532x)
> #include <asm/coldfire.h>
> #include <asm/mcfsim.h>
> #include "fec.h"
> -#else
> -#include <asm/8xx_immap.h>
> -#include <asm/mpc8xx.h>
> -#include "commproc.h"
> -#endif
>
> #if defined(CONFIG_FEC2)
> #define FEC_MAX_PORTS 2
> @@ -1223,14 +1218,9 @@ static phy_info_t const * const phy_info[] = {
>
> /*
------------------------------------------------------------------------- */
> #if !defined(CONFIG_M532x)
> -#ifdef CONFIG_RPXCLASSIC
> -static void
> -mii_link_interrupt(void *dev_id);
> -#else
> static irqreturn_t
> mii_link_interrupt(int irq, void * dev_id);
> #endif
> -#endif
>
> #if defined(CONFIG_M5272)
> /*
> @@ -1800,121 +1790,6 @@ static void __inline__ fec_uncache(unsigned
long addr)
> /*
------------------------------------------------------------------------- */
>
>
> -#else
> -
> -/*
> - * Code specific to the MPC860T setup.
> - */
> -static void __inline__ fec_request_intrs(struct net_device *dev)
> -{
> - volatile immap_t *immap;
> -
> - immap = (immap_t *)IMAP_ADDR; /* pointer to internal registers */
> -
> - if (request_8xxirq(FEC_INTERRUPT, fec_enet_interrupt, 0, "fec",
dev) != 0)
> - panic("Could not allocate FEC IRQ!");
> -
> -#ifdef CONFIG_RPXCLASSIC
> - /* Make Port C, bit 15 an input that causes interrupts.
> - */
> - immap->im_ioport.iop_pcpar &= ~0x0001;
> - immap->im_ioport.iop_pcdir &= ~0x0001;
> - immap->im_ioport.iop_pcso &= ~0x0001;
> - immap->im_ioport.iop_pcint |= 0x0001;
> - cpm_install_handler(CPMVEC_PIO_PC15, mii_link_interrupt, dev);
> -
> - /* Make LEDS reflect Link status.
> - */
> - *((uint *) RPX_CSR_ADDR) &= ~BCSR2_FETHLEDMODE;
> -#endif
> -#ifdef CONFIG_FADS
> - if (request_8xxirq(SIU_IRQ2, mii_link_interrupt, 0, "mii", dev) != 0)
> - panic("Could not allocate MII IRQ!");
> -#endif
> -}
> -
> -static void __inline__ fec_get_mac(struct net_device *dev)
> -{
> - bd_t *bd;
> -
> - bd = (bd_t *)__res;
> - memcpy(dev->dev_addr, bd->bi_enetaddr, ETH_ALEN);
> -
> -#ifdef CONFIG_RPXCLASSIC
> - /* The Embedded Planet boards have only one MAC address in
> - * the EEPROM, but can have two Ethernet ports. For the
> - * FEC port, we create another address by setting one of
> - * the address bits above something that would have (up to
> - * now) been allocated.
> - */
> - dev->dev_adrd[3] |= 0x80;
> -#endif
> -}
> -
> -static void __inline__ fec_set_mii(struct net_device *dev, struct
fec_enet_private *fep)
> -{
> - extern uint _get_IMMR(void);
> - volatile immap_t *immap;
> - volatile fec_t *fecp;
> -
> - fecp = fep->hwp;
> - immap = (immap_t *)IMAP_ADDR; /* pointer to internal registers */
> -
> - /* Configure all of port D for MII.
> - */
> - immap->im_ioport.iop_pdpar = 0x1fff;
> -
> - /* Bits moved from Rev. D onward.
> - */
> - if ((_get_IMMR() & 0xffff) < 0x0501)
> - immap->im_ioport.iop_pddir = 0x1c58; /* Pre rev. D */
> - else
> - immap->im_ioport.iop_pddir = 0x1fff; /* Rev. D and later */
> -
> - /* Set MII speed to 2.5 MHz
> - */
> - fecp->fec_mii_speed = fep->phy_speed =
> - ((bd->bi_busfreq * 1000000) / 2500000) & 0x7e;
> -}
> -
> -static void __inline__ fec_enable_phy_intr(void)
> -{
> - volatile fec_t *fecp;
> -
> - fecp = fep->hwp;
> -
> - /* Enable MII command finished interrupt
> - */
> - fecp->fec_ivec = (FEC_INTERRUPT/2) << 29;
> -}
> -
> -static void __inline__ fec_disable_phy_intr(void)
> -{
> -}
> -
> -static void __inline__ fec_phy_ack_intr(void)
> -{
> -}
> -
> -static void __inline__ fec_localhw_setup(void)
> -{
> - volatile fec_t *fecp;
> -
> - fecp = fep->hwp;
> - fecp->fec_r_hash = PKT_MAXBUF_SIZE;
> - /* Enable big endian and don't care about SDMA FC.
> - */
> - fecp->fec_fun_code = 0x78000000;
> -}
> -
> -static void __inline__ fec_uncache(unsigned long addr)
> -{
> - pte_t *pte;
> - pte = va_to_pte(mem_addr);
> - pte_val(*pte) |= _PAGE_NO_CACHE;
> - flush_tlb_page(init_mm.mmap, mem_addr);
> -}
> -
> #endif
>
> /*
------------------------------------------------------------------------- */
> @@ -2126,13 +2001,8 @@ mii_discover_phy(uint mii_reg, struct
net_device *dev)
>
> /* This interrupt occurs when the PHY detects a link change.
> */
> -#ifdef CONFIG_RPXCLASSIC
> -static void
> -mii_link_interrupt(void *dev_id)
> -#else
> static irqreturn_t
> mii_link_interrupt(int irq, void * dev_id)
> -#endif
> {
> struct net_device *dev = dev_id;
> struct fec_enet_private *fep = netdev_priv(dev);
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com
SnapGear -- a Secure Computing Company PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* [-mm PATCH] updates for hotplug memory remove
From: Badari Pulavarty @ 2008-01-29 0:31 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, pbadari, linuxppc-dev
Hi Andrew,
Here are the updates for hotplug memory remove code currently in -mm.
1) Please don't push this patch to mainline (for the merge window).
memory-hotplug-add-removable-to-sysfs-to-show-memblock-removability.patch
I didn't find this consistently useful - even though memory is marked
removable, I found cases where I can't move it. When we get it right,
we can push it at that time. Please leave this in -mm.
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
Supply ppc64 remove_memory() function. Arch specific is still
being reviewed by Paul Mackerras.
From: Badari Pulavarty <pbadari@us.ibm.com>
---
arch/powerpc/mm/mem.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
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:04:32.000000000 -0800
+++ linux-2.6.24-rc8/arch/powerpc/mm/mem.c 2008-01-25 08:16:37.000000000 -0800
@@ -145,6 +145,22 @@ walk_memory_resource(unsigned long start
return (*func)(start_pfn, nr_pages, arg);
}
+#ifdef CONFIG_MEMORY_HOTREMOVE
+int remove_memory(u64 start, u64 size)
+{
+ unsigned long start_pfn, end_pfn;
+ int ret;
+
+ start_pfn = start >> PAGE_SHIFT;
+ end_pfn = start_pfn + (size >> PAGE_SHIFT);
+ ret = offline_pages(start_pfn, end_pfn, 120 * HZ);
+ if (ret)
+ goto out;
+ /* Arch-specific calls go here - next patch */
+out:
+ return ret;
+}
+#endif /* CONFIG_MEMORY_HOTREMOVE */
#endif /* CONFIG_MEMORY_HOTPLUG */
void show_mem(void)
^ permalink raw reply
* Re: [PATCH 4/9] enable FSL SATA driver config for Freescale SoCs
From: Kim Phillips @ 2008-01-25 17:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-ide, linuxppc-dev, jgarzik, Jerry Huang
In-Reply-To: <089EA00D-8EAB-417D-9A4B-FA500D23FF8D@kernel.crashing.org>
On Fri, 25 Jan 2008 10:04:08 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jan 24, 2008, at 8:46 PM, Kim Phillips wrote:
>
> > The mpc8315 shares the same SATA controller as the mpc837x,
> > and likelihood is that future SoCs from Freescale will also.
> >
> > Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> > Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> > ---
> > Kumar, let me know if you want me to post this to the ata list (I'm
> > assuming it's not necessary).
>
> It is necessary so they are aware. CC jgarizk, but we'll take it via
> powerpc.
>
> - k
>
ok, cc'ing Jeff, linux-ide here:
From: Kim Phillips <kim.phillips@freescale.com>
Date: Thu, 24 Jan 2008 01:49:24 -0600
Subject: [PATCH] enable FSL SATA driver config for Freescale SoCs
The mpc8315 shares the same SATA controller as the mpc837x,
and likelihood is that future SoCs from Freescale will also.
Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
drivers/ata/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 64b4964..75939dd 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -184,7 +184,7 @@ config PATA_ACPI
config SATA_FSL
tristate "Freescale 3.0Gbps SATA support"
- depends on PPC_MPC837x
+ depends on FSL_SOC
help
This option enables support for Freescale 3.0Gbps SATA controller.
It can be found on MPC837x and MPC8315.
--
1.5.2.2
^ permalink raw reply related
* Re: [-mm PATCH] updates for hotplug memory remove
From: Badari Pulavarty @ 2008-01-29 0:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-mm, linuxppc-dev
In-Reply-To: <1201566682.29357.15.camel@dyn9047017100.beaverton.ibm.com>
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 <pbadari@us.ibm.com>
---
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.000000000 -0800
+++ linux-2.6.24-rc8/arch/powerpc/mm/hash_utils_64.c 2008-01-28 11:45:40.000000000 -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.000000000 -0800
+++ linux-2.6.24-rc8/include/asm-powerpc/sparsemem.h 2008-01-25 08:18:11.000000000 -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.000000000 -0800
+++ linux-2.6.24-rc8/arch/powerpc/mm/mem.c 2008-01-25 08:20:33.000000000 -0800
@@ -156,7 +156,9 @@ int remove_memory(u64 start, u64 size)
ret = offline_pages(start_pfn, end_pfn, 120 * HZ);
if (ret)
goto out;
- /* Arch-specific calls go here - next patch */
+
+ start = (unsigned long)__va(start);
+ remove_section_mapping(start, start + size);
out:
return ret;
}
Index: linux-2.6.24-rc8/arch/powerpc/platforms/pseries/lpar.c
===================================================================
--- linux-2.6.24-rc8.orig/arch/powerpc/platforms/pseries/lpar.c 2008-01-15 20:22:48.000000000 -0800
+++ linux-2.6.24-rc8/arch/powerpc/platforms/pseries/lpar.c 2008-01-28 14:10:58.000000000 -0800
@@ -520,6 +520,20 @@ static void pSeries_lpar_hpte_invalidate
BUG_ON(lpar_rc != H_SUCCESS);
}
+static void pSeries_lpar_hpte_removebolted(unsigned long ea,
+ int psize, int ssize)
+{
+ unsigned long slot, vsid, va;
+
+ vsid = get_kernel_vsid(ea, ssize);
+ va = hpt_va(ea, vsid, ssize);
+
+ slot = pSeries_lpar_hpte_find(va, psize, ssize);
+ BUG_ON(slot == -1);
+
+ pSeries_lpar_hpte_invalidate(slot, va, psize, ssize, 0);
+}
+
/* Flag bits for H_BULK_REMOVE */
#define HBR_REQUEST 0x4000000000000000UL
#define HBR_RESPONSE 0x8000000000000000UL
@@ -597,6 +611,7 @@ void __init hpte_init_lpar(void)
ppc_md.hpte_updateboltedpp = pSeries_lpar_hpte_updateboltedpp;
ppc_md.hpte_insert = pSeries_lpar_hpte_insert;
ppc_md.hpte_remove = pSeries_lpar_hpte_remove;
+ ppc_md.hpte_removebolted = pSeries_lpar_hpte_removebolted;
ppc_md.flush_hash_range = pSeries_lpar_flush_hash_range;
ppc_md.hpte_clear_all = pSeries_lpar_hptab_clear;
}
Index: linux-2.6.24-rc8/include/asm-powerpc/machdep.h
===================================================================
--- linux-2.6.24-rc8.orig/include/asm-powerpc/machdep.h 2008-01-25 08:04:41.000000000 -0800
+++ linux-2.6.24-rc8/include/asm-powerpc/machdep.h 2008-01-28 11:45:17.000000000 -0800
@@ -68,6 +68,8 @@ struct machdep_calls {
unsigned long vflags,
int psize, int ssize);
long (*hpte_remove)(unsigned long hpte_group);
+ void (*hpte_removebolted)(unsigned long ea,
+ int psize, int ssize);
void (*flush_hash_range)(unsigned long number, int local);
/* special for kexec, to be called in real mode, linar mapping is
^ permalink raw reply
* Re: [PATCH UCC TDM 3/3 ] Modified Documentation to explain dtsentries for TDM driver
From: Scott Wood @ 2008-01-25 18:13 UTC (permalink / raw)
To: Aggrwal Poonam
Cc: Barkowski Michael, netdev, Gala Kumar, linux-kernel, rubini,
linuxppc-dev, Kalra Ashish, Cutler Richard, akpm, Tabi Timur
In-Reply-To: <FBA61160C48B8D438F3323FEFB4EF2C279AFF5@zin33exm24.fsl.freescale.net>
Aggrwal Poonam wrote:
> The device tree already has a brg-frequency property in qe node which
> is the value of BRGCLK.
Yes, I'm saying it belongs as brg/clock-frequency. :-)
CPM1/2 already do this.
-Scott
^ permalink raw reply
* Re: [PATCH 5/5] [POWERPC] fsl_soc, legacy_serial: add support for "soc" compatible matching
From: Scott Wood @ 2008-01-25 19:03 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev list, Yoder Stuart
In-Reply-To: <20080125185341.GA13450@localhost.localdomain>
Anton Vorontsov wrote:
> $ grep qe@ arch/powerpc/boot/dts/*
> arch/powerpc/boot/dts/mpc832x_mds.dts: qe@e0100000 {
> arch/powerpc/boot/dts/mpc832x_rdb.dts: qe@e0100000 {
> arch/powerpc/boot/dts/mpc836x_mds.dts: qe@e0100000 {
> arch/powerpc/boot/dts/mpc8568mds.dts: qe@e0080000 {
>
> ^^^ if the practice is wrong, then we should fix it, and then
> -immr would be the good name indeed (just as I've said previously).
It's wrong, and we should fix it. It would make sense if the QE block
were relocatable separately from IMMR (but even if it were, the QE
compatible should be fsl,xxxx-qe or similar, so no conflict with
fsl,xxxx-immr) -- but it isn't, at least on the 8323 and 8360 (I don't
have an 8568 manual handy).
-Scott
^ permalink raw reply
* Re: Preferred GIT URL for arch/powerpc, and BINUTILS
From: Josh Boyer @ 2008-01-29 1:43 UTC (permalink / raw)
To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <20080128224710.9C1C4DDEE1@ozlabs.org>
On Mon, 28 Jan 2008 17:46:47 -0500
Steve Heflin <sheflin@newagemicro.com> wrote:
> At 02:30 PM 1/28/2008, Steve Heflin wrote:
> >Josh, you're a life saver!! Your GIT tree is exactly what I've been
> >looking for. I have an AMCC440EPx based product that makes heavy use
> >of all the devices embedded in the microcontroller. I'll be able to
> >give that platform a very good testing.
> >
> >Now can you help me with BINUTILS? What version do you use and can
> >you point me to a decent GIT tree for it? I tried to use version
> >2.18 and the build blows up because it tries to "strip" a script file
> >"embedspu".
>
> Whoa! I spoke too soon. Upon attempting a "make menuconfig" on the
> 2.6.24-rc8 which I cloned from your git tree, I don't even SEE the
> powerpc architecture appearing! What's up?
I dunno. I never use make menuconfig. I typically do:
make ARCH=powerpc sequoia_defconfig
or something similar if I'm cross-building from x86. Otherwise if I'm
on the G5, it's just:
make sequoia_defconfig
josh
^ permalink raw reply
* Re: Preferred GIT URL for arch/powerpc, and BINUTILS
From: Josh Boyer @ 2008-01-29 1:48 UTC (permalink / raw)
To: Steve Heflin; +Cc: linuxppc-embedded
In-Reply-To: <20080128194352.206f3ead@zod.rchland.ibm.com>
On Mon, 28 Jan 2008 19:43:52 -0600
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Mon, 28 Jan 2008 17:46:47 -0500
> Steve Heflin <sheflin@newagemicro.com> wrote:
>
> > At 02:30 PM 1/28/2008, Steve Heflin wrote:
> > >Josh, you're a life saver!! Your GIT tree is exactly what I've been
> > >looking for. I have an AMCC440EPx based product that makes heavy use
> > >of all the devices embedded in the microcontroller. I'll be able to
> > >give that platform a very good testing.
> > >
> > >Now can you help me with BINUTILS? What version do you use and can
> > >you point me to a decent GIT tree for it? I tried to use version
> > >2.18 and the build blows up because it tries to "strip" a script file
> > >"embedspu".
> >
> > Whoa! I spoke too soon. Upon attempting a "make menuconfig" on the
> > 2.6.24-rc8 which I cloned from your git tree, I don't even SEE the
> > powerpc architecture appearing! What's up?
>
> I dunno. I never use make menuconfig. I typically do:
>
> make ARCH=powerpc sequoia_defconfig
>
> or something similar if I'm cross-building from x86. Otherwise if I'm
> on the G5, it's just:
>
> make sequoia_defconfig
Oh, and that's on the for-2.6.25 branch of my tree. I'll update the
master soon-ish to match the powerpc git tree.
josh
^ permalink raw reply
* Re: [PATCH 0/9] 83xx DTS fixes and v1 conversions
From: Paul Gortmaker @ 2008-01-28 16:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <54AD0075-E36B-4A95-BFD9-C750E590513F@kernel.crashing.org>
Kumar Gala wrote:
>
> On Jan 28, 2008, at 9:51 AM, Paul Gortmaker wrote:
>
>> Kumar Gala wrote:
>>> On Mon, 28 Jan 2008, Paul Gortmaker wrote:
>>>
>>>
>>>> This series incorporates my earlier qe/muram fix before converting
>>>> the existing mpc83xx DTS files to v1 format. I've also redone the
>>>> mpc834x_mds with the IRQs as decimal as per Kumar's comments and
>>>> re-included that too. I've kept each board as a separate commit
>>>> in case one of them conflicts with what someone else is working on.
>>>>
>>>> Boards covered are: 8349mds, 8349mitx, 8349mitx-gp, 836x_mds,
>>>> 8323_mds, 8323_rdb, and the 8313_rdb. Plus a small tweak to the
>>>> sbc8349 (it was already v1 -- but IRQs were in hex.)
>>>>
>>>> I've fed all the files to DTC before and after to ensure the
>>>> output is the same after the conversion.
>>>>
>>>> I'm not aware of any explicit rules for what is hex vs decimal.
>>>> I've tried to keep things that are usually discussed in decimal
>>>> as decimal quantities (i.e. cache size, IRQ, counts, indicies)
>>>> and all other data that you'd normally expect in hex (addresses,
>>>> IRQ flags, masks) as hex -- including prefixing 0x on values from
>>>> zero to 10 where it tends to make rows of numbers (e.g. ranges)
>>>> align for better readability, even though it isn't required.
>>>>
>>>>
>>>
>>> Can you regen these patches (2..9) againast my latest tree. Also, a
>>> single patch that cleans up all the boards is sufficient.
>>>
>>
>> The patches should be current to your tree still as of today; they
>> are based on:
>>
>> f09f415ea23272ae68f9322f90246680d46f4868 not-for-merge
>> branch 'for-2.6.25' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc
>>
>> My patch #1 with all four qe/muram boards was posted earlier here:
>>
>> http://ozlabs.org/pipermail/linuxppc-dev/2008-January/050767.html
>>
>> Let me know what you need them based against and I can respin
>> as required.
>
> I've pushed out a bunch of stuff today.
>
> commit 390167efa329d11099957108fc23d1ad15c3f37e
>
> I'm expect a respin since the patches don't currently apply to my tree.
OK - no problem, I've pulled todays updates; I'll rebase and resend.
P.
>
> - k
>
^ permalink raw reply
* Re: [PATCHv3 2.6.25] i2c: adds support for i2c bus on Freescale CPM1/CPM2 controllers
From: Scott Wood @ 2008-01-28 16:49 UTC (permalink / raw)
To: Jochen Friedrich
Cc: Jean Delvare, linuxppc-dev list, Kernel, Linux, Linux I2C
In-Reply-To: <479A185D.6010406@scram.de>
On Fri, Jan 25, 2008 at 06:11:57PM +0100, Jochen Friedrich wrote:
> diff --git a/arch/powerpc/boot/dts/mpc866ads.dts b/arch/powerpc/boot/dts/mpc866ads.dts
> index daf9433..80c08bf 100644
> --- a/arch/powerpc/boot/dts/mpc866ads.dts
> +++ b/arch/powerpc/boot/dts/mpc866ads.dts
> @@ -169,6 +169,16 @@
> fsl,cpm-command = <0000>;
> linux,network-index = <1>;
> };
> +
> + i2c@860 {
> + compatible = "fsl,mpc866-i2c",
> + "fsl,cpm1-i2c",
> + "fsl,cpm-i2c";
> + reg = <860 20 3c80 30>;
> + interrupts = <10 3>;
> + interrupt-parent = <&Cpm_pic>;
The label is &CPM_PIC in the current mpc866ads.dts.
-Scott
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: some minor cleanups for stx_gp3 and tqm85xx
From: David Gibson @ 2008-01-29 5:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0801251039220.17501@blarg.am.freescale.net>
On Fri, Jan 25, 2008 at 10:39:38AM -0600, Kumar Gala wrote:
> * "simple-bus" covers all our needs for of_platform_bus_probe()
> * make device tree name just 'soc' not 'soc85..'
Getting rid of the device_type="soc" would be nice, too...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox