[PATCH v2] Fix handling of memreserve if the range lands in highmem
There were several issues if a memreserve range existed and happened
to be in highmem:
* The bootmem allocator is only aware of lowmem so calling
reserve_bootmem with a highmem address would cause a BUG_ON
* All highmem pages were provided to the buddy allocator
Added a lmb_is_reserved() api that we now use to determine if a highem
page should continue to be PageReserved or provided to the buddy
allocator.
Also, we incorrectly reported the amount of pages reserved since all
highmem pages are initally marked reserved and we clear the
PageReserved flag as we "free" up the highmem pages.
---
Handle case pointed out by Scott Wood if a memreserve crosses the lowmem
boundary.
arch/powerpc/mm/lmb.c | 13 +
arch/powerpc/mm/mem.c | 20
include/asm-powerpc/lmb.h |1 +
3 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/lmb.c b/arch/powerpc/mm/lmb.c
index 8f4d2dc..4ce23bc 100644
--- a/arch/powerpc/mm/lmb.c
+++ b/arch/powerpc/mm/lmb.c
@@ -342,3 +342,16 @@ void __init lmb_enforce_memory_limit(unsigned long
memory_limit)
}
}
}
+
+int __init lmb_is_reserved(unsigned long addr)
+{
+ int i;
+
+ for (i = 0; i < lmb.reserved.cnt; i++) {
+ unsigned long upper = lmb.reserved.region[i].base +
+ lmb.reserved.region[i].size - 1;
+ if ((addr >= lmb.reserved.region[i].base) && (addr <= upper))
+ return 1;
+ }
+ return 0;
+}
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 5402fb6..0b29da3 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -218,9 +218,19 @@ void __init do_init_bootmem(void)
#endif
/* reserve the sections we're already using */
- for (i = 0; i < lmb.reserved.cnt; i++)
- reserve_bootmem(lmb.reserved.region[i].base,
- lmb_size_bytes(&lmb.reserved, i));
+ for (i = 0; i < lmb.reserved.cnt; i++) {
+ unsigned long addr = lmb.reserved.region[i].base +
+lmb_size_bytes(&lmb.reserved, i) - 1;
+ if (addr < total_lowmem)
+ reserve_bootmem(lmb.reserved.region[i].base,
+ lmb_size_bytes(&lmb.reserved, i));
+ else if (lmb.reserved.region[i].base < total_lowmem) {
+ unsigned long adjusted_size = total_lowmem -
+ lmb.reserved.region[i].base;
+ reserve_bootmem(lmb.reserved.region[i].base,
+ adjusted_size);
+ }
+ }
/* XXX need to clip this if using highmem? */
sparse_memory_present_with_active_regions(0);
@@ -334,11 +344,13 @@ void __init mem_init(void)
highmem_mapnr = total_lowmem >> PAGE_SHIFT;
for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) {
struct page *page = pfn_to_page(pfn);
-
+ if (lmb_is_reserved(pfn << PAGE_SHIFT))
+ continue;
ClearPageReserved(page);
init_page_count(page);
__free_page(page);
totalhigh_pages++;
+ reservedpages--;
}
totalram_pages += totalhigh_pages;
printk(KERN_DEBUG "High memory: %luk\n",
diff --git a/include/asm-powerpc/lmb.h b/include/asm-powerpc/lmb.h
index b5f9f4c..5d1dc48 100644
--- a/include/asm-powerpc/lmb.h
+++ b/include/asm-powerpc/lmb.h
@@ -51,6 +51,7 @@ extern unsigned long __init __lmb_alloc_base(unsigned long
size,
extern unsigned long __init lmb_phys_mem_size(void);
extern unsigned long __init lmb_end_of_DRAM(void);
extern void __init lmb_enforce_memory_limit(unsigned long memory_limit);
+extern int __init lmb_is_reserved(unsigned long addr);
extern void lmb_dump_all(void);
--
1.5.3.7
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH V3] [POWERPC] Add common clock setting routine mpc52xx_psc_set_clkdiv()
Hi Grant,
On Wed, 09 Jan 2008 22:26:30 -0700 Grant Likely <[EMAIL PROTECTED]> wrote:
>
> +mpc52xx_map_common_devices(void)
> {
> + /* Clock Distribution Module, used by PSC clock setting function */
> + np = of_find_matching_node(NULL, mpc52xx_cdm_ids);
What happens if we find no node?
> + mpc52xx_cdm = of_iomap(np, 0);
> + of_node_put(np);
> }
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpeZoPnntxuz.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix CPU hotplug when using the SLB shadow buffer
Before we register the SLB shadow buffer, we need to invalidate the
entries in the buffer otherwise we can end up stale entries from when we
offlined the CPU.
This patch does this invalidate as well as unregistering the buffer with
PHYP before we offline the cpu. Tested and fixes crashes seen on 970MP
(thanks to tonyb) and POWER5.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Updates for comments by mpe.
Also, thanks to Anton for helping find this problem.
arch/powerpc/mm/slb.c|2 +-
arch/powerpc/platforms/pseries/hotplug-cpu.c |2 ++
arch/powerpc/platforms/pseries/lpar.c|3 +++
include/asm-powerpc/mmu-hash64.h |1 +
4 files changed, 7 insertions(+), 1 deletion(-)
Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
@@ -77,7 +77,7 @@ static inline void slb_shadow_update(uns
get_slb_shadow()->save_area[entry].esid = mk_esid_data(ea, ssize,
entry);
}
-static inline void slb_shadow_clear(unsigned long entry)
+void slb_shadow_clear(unsigned long entry)
{
get_slb_shadow()->save_area[entry].esid = 0;
}
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/hotplug-cpu.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -29,6 +29,7 @@
#include
#include
#include "xics.h"
+#include "plpar_wrappers.h"
/* This version can't take the spinlock, because it never returns */
static struct rtas_args rtas_stop_self_args = {
@@ -58,6 +59,7 @@ static void pseries_mach_cpu_die(void)
local_irq_disable();
idle_task_exit();
xics_teardown_cpu(0);
+ unregister_slb_shadow(smp_processor_id(), __pa(get_slb_shadow()));
rtas_stop_self();
/* Should never get here... */
BUG();
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/lpar.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
@@ -253,6 +253,7 @@ void vpa_init(int cpu)
int hwcpu = get_hard_smp_processor_id(cpu);
unsigned long addr;
long ret;
+ int i;
if (cpu_has_feature(CPU_FTR_ALTIVEC))
lppaca[cpu].vmxregs_in_use = 1;
@@ -272,6 +273,8 @@ void vpa_init(int cpu)
*/
addr = __pa(&slb_shadow[cpu]);
if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
+ for (i = 0; i < SLB_NUM_BOLTED; i++)
+ slb_shadow_clear(i);
ret = register_slb_shadow(hwcpu, addr);
if (ret)
printk(KERN_ERR
Index: linux-2.6-ozlabs/include/asm-powerpc/mmu-hash64.h
===
--- linux-2.6-ozlabs.orig/include/asm-powerpc/mmu-hash64.h
+++ linux-2.6-ozlabs/include/asm-powerpc/mmu-hash64.h
@@ -286,6 +286,7 @@ extern void hpte_init_iSeries(void);
extern void hpte_init_beat(void);
extern void hpte_init_beat_v3(void);
+extern void slb_shadow_clear(unsigned long entry);
extern void stabs_alloc(void);
extern void slb_initialize(void);
extern void slb_flush_and_rebolt(void);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How complete should the DTS be?
On Thu, 2008-01-10 at 17:02 +1100, David Gibson wrote: > On Thu, Jan 10, 2008 at 12:53:57AM -0500, Sean MacLennan wrote: > > David Gibson wrote: > > > Hrm... I'd say this is not something which has a firm convention yet. > > > It's going to become more of an issue once we get a macros system for > > > dtc, so the "440EP" macro would have all the devices, even if some are > > > not connected on a given board. > > > > > > I'm contemplating suggesting that we adopt the "status" property from > > > IEEE1275 to cover this. > > > > > > > > When I am laying out the dts, leaving out what isn't used makes the dts > > file cleaner, at least in my view. It doesn't hurt to have the second > > i2c bus there, but it also doesn't help and leaving it out points out > > that it is not used. > > > > When we get a macro system I assume the second i2c bus will be there but > > hidden by a macro. It will still be clean and shouldn't cause grief. > > Right, but if it is there we'll want to mark it as unused in some way > so that the kernel doesn't waste resources attempting to drive it. Sure but I don't want to make it mandatory for people to put unused devices in. If the macro system brings them in, then yes, it's good to have a way to properly mark them unused. But people hand crafting DTS shouldn't have to bloat them. There is -one- case where you may want to put unused devices, is if you do some kind of resource management on that specific bus (like need to be able to dynamically allocate space on the bus). In this case, you want to know everything that's there and potentially decodes addresses to avoid collisions. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix CPU hotplug when using the SLB shadow buffer
Before we register the SLB shadow buffer, we need to invalidate the
entries in the buffer otherwise we can end up stale entries from when we
offlined the CPU.
This patch does this invalidate as well as unregistering the buffer with
PHYP before we offline the cpu. Tested and fixes crashes seen on 970MP
(thanks to tonyb) and POWER5.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
paulus: This, or some variant of it, is probably 2.6.24 material.
arch/powerpc/mm/slb.c|2 +-
arch/powerpc/platforms/pseries/hotplug-cpu.c |2 ++
arch/powerpc/platforms/pseries/lpar.c|6 ++
3 files changed, 9 insertions(+), 1 deletion(-)
Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
@@ -77,7 +77,7 @@ static inline void slb_shadow_update(uns
get_slb_shadow()->save_area[entry].esid = mk_esid_data(ea, ssize,
entry);
}
-static inline void slb_shadow_clear(unsigned long entry)
+void slb_shadow_clear(unsigned long entry)
{
get_slb_shadow()->save_area[entry].esid = 0;
}
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/hotplug-cpu.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -29,6 +29,7 @@
#include
#include
#include "xics.h"
+#include "plpar_wrappers.h"
/* This version can't take the spinlock, because it never returns */
static struct rtas_args rtas_stop_self_args = {
@@ -58,6 +59,7 @@ static void pseries_mach_cpu_die(void)
local_irq_disable();
idle_task_exit();
xics_teardown_cpu(0);
+ unregister_slb_shadow(smp_processor_id(), __pa(get_slb_shadow()));
rtas_stop_self();
/* Should never get here... */
BUG();
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/lpar.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
@@ -248,16 +248,22 @@ out:
of_node_put(stdout_node);
}
+extern void slb_shadow_clear(unsigned long entry);
+
void vpa_init(int cpu)
{
int hwcpu = get_hard_smp_processor_id(cpu);
unsigned long addr;
long ret;
+ int i;
if (cpu_has_feature(CPU_FTR_ALTIVEC))
lppaca[cpu].vmxregs_in_use = 1;
addr = __pa(&lppaca[cpu]);
+ for (i = 0; i < SLB_NUM_BOLTED; i++){
+ slb_shadow_clear(i);
+ }
ret = register_vpa(hwcpu, addr);
if (ret) {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How complete should the DTS be?
On Thu, Jan 10, 2008 at 12:53:57AM -0500, Sean MacLennan wrote: > David Gibson wrote: > > Hrm... I'd say this is not something which has a firm convention yet. > > It's going to become more of an issue once we get a macros system for > > dtc, so the "440EP" macro would have all the devices, even if some are > > not connected on a given board. > > > > I'm contemplating suggesting that we adopt the "status" property from > > IEEE1275 to cover this. > > > > > When I am laying out the dts, leaving out what isn't used makes the dts > file cleaner, at least in my view. It doesn't hurt to have the second > i2c bus there, but it also doesn't help and leaving it out points out > that it is not used. > > When we get a macro system I assume the second i2c bus will be there but > hidden by a macro. It will still be clean and shouldn't cause grief. Right, but if it is there we'll want to mark it as unused in some way so that the kernel doesn't waste resources attempting to drive it. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
On Jan 9, 2008, at 1:52 PM, Scott Wood wrote:
> Kumar Gala wrote:
>> I'm thinking I'll add something like:
>>if (addr < total_lowmem)
>>reserve_bootmem(lmb.reserved.region[i].base,
>>
>> lmb_size_bytes(&lmb.reserved, i));
>> + else if (lmb.reserved.region[i].base >
>> total_lowmem) {
>
> less than, surely?
damn, why didn't I see your email before a spent 20 minutes debugging
this ;)
>> + unsigned long adjusted_size;
>> +// adjusted_size = xxx;
>> need to figure out the math here.
>
> Wouldn't it just be total_lowmem - lmb.reserved.region[i].base?
yep, but that required my brain to have enough time to think about this.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How complete should the DTS be?
David Gibson wrote: > Hrm... I'd say this is not something which has a firm convention yet. > It's going to become more of an issue once we get a macros system for > dtc, so the "440EP" macro would have all the devices, even if some are > not connected on a given board. > > I'm contemplating suggesting that we adopt the "status" property from > IEEE1275 to cover this. > > When I am laying out the dts, leaving out what isn't used makes the dts file cleaner, at least in my view. It doesn't hurt to have the second i2c bus there, but it also doesn't help and leaving it out points out that it is not used. When we get a macro system I assume the second i2c bus will be there but hidden by a macro. It will still be clean and shouldn't cause grief. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On 1/9/08, David Gibson <[EMAIL PROTECTED]> wrote: > On Mon, Jan 07, 2008 at 06:28:54PM +, Mark Brown wrote: > > On Mon, Jan 07, 2008 at 09:52:03AM -0600, Timur Tabi wrote: > > > David Gibson wrote: > > > > > > Ok, but couldn't you strucutre your I2S or fabric driver so that it > > > > only becomes fully operational once the codec driver has registered > > > > with it? > > > > > Not in ASoC V1. You have to understand, ASoC V1 was designed without any > > > consideration for runtime-bindings and other OF goodies. All connections > > > between the drivers are static, literally. In fact, I wouldn't be > > > surprised if > > > some ASoC drivers cannot be compiled as modules. > > > > I'd just like to emphasise this point - ASoC v1 really doesn't > > understand the idea that the components of the sound subsystem might be > > probed separately. It's set up to handle bare hardware with everything > > being probed from code in the machine/fabric driver. This makes life > > very messy for platforms with something like the device tree. > > > > As has been said, handling this properly is one of the major motivations > > behind ASoC v2. > > Ick. Ok. > > Nonetheless, messing up the device tree to workaround ASoC V1's silly > limitations is not a good idea. The device tree must represent the > hardware as much as possible. If that means we have to have a bunch > of platform-specific hacks to instatiate the drivers in the correct > order / combination, that's unfortunate, but there you go. ASOC v2 is sitting on a Wolfson server out of tree. I have been using it for several months without problem. The pace of it being merged could probably be sped up. > > -- > 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 > -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH V3] [POWERPC] Add common clock setting routine mpc52xx_psc_set_clkdiv()
From: Grant Likely <[EMAIL PROTECTED]>
PSC drivers should not access the CDM registers directly. Instead provide
a common routine for setting the PSC clock parameters with the required
locking.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/52xx/efika.c |3 +
arch/powerpc/platforms/52xx/lite5200.c | 10 ++--
arch/powerpc/platforms/52xx/mpc5200_simple.c |6 +-
arch/powerpc/platforms/52xx/mpc52xx_common.c | 65 --
arch/ppc/syslib/mpc52xx_setup.c | 36 ++
include/asm-powerpc/mpc52xx.h|9 ++--
6 files changed, 114 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/efika.c
b/arch/powerpc/platforms/52xx/efika.c
index a0da70c..a2068fa 100644
--- a/arch/powerpc/platforms/52xx/efika.c
+++ b/arch/powerpc/platforms/52xx/efika.c
@@ -180,6 +180,9 @@ static void __init efika_setup_arch(void)
{
rtas_initialize();
+ /* Map important registers from the internal memory map */
+ mpc52xx_map_common_devices();
+
efika_pcisetup();
#ifdef CONFIG_PM
diff --git a/arch/powerpc/platforms/52xx/lite5200.c
b/arch/powerpc/platforms/52xx/lite5200.c
index f8ba5f2..42e87b6 100644
--- a/arch/powerpc/platforms/52xx/lite5200.c
+++ b/arch/powerpc/platforms/52xx/lite5200.c
@@ -150,15 +150,15 @@ static void __init lite5200_setup_arch(void)
if (ppc_md.progress)
ppc_md.progress("lite5200_setup_arch()", 0);
- /* Fix things that firmware should have done. */
- lite5200_fix_clock_config();
- lite5200_fix_port_config();
+ /* Map important registers from the internal memory map */
+ mpc52xx_map_common_devices();
/* Some mpc5200 & mpc5200b related configuration */
mpc5200_setup_xlb_arbiter();
- /* Map wdt for mpc52xx_restart() */
- mpc52xx_map_wdt();
+ /* Fix things that firmware should have done. */
+ lite5200_fix_clock_config();
+ lite5200_fix_port_config();
#ifdef CONFIG_PM
mpc52xx_suspend.board_suspend_prepare = lite5200_suspend_prepare;
diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c
b/arch/powerpc/platforms/52xx/mpc5200_simple.c
index 754aa93..c48b82b 100644
--- a/arch/powerpc/platforms/52xx/mpc5200_simple.c
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
@@ -39,12 +39,12 @@ static void __init mpc5200_simple_setup_arch(void)
if (ppc_md.progress)
ppc_md.progress("mpc5200_simple_setup_arch()", 0);
+ /* Map important registers from the internal memory map */
+ mpc52xx_map_common_devices();
+
/* Some mpc5200 & mpc5200b related configuration */
mpc5200_setup_xlb_arbiter();
- /* Map wdt for mpc52xx_restart() */
- mpc52xx_map_wdt();
-
mpc52xx_setup_pci();
}
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_common.c
b/arch/powerpc/platforms/52xx/mpc52xx_common.c
index 0211890..bf842e0 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_common.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_common.c
@@ -13,6 +13,7 @@
#undef DEBUG
#include
+#include
#include
#include
#include
@@ -24,7 +25,9 @@
* from interrupt context while node mapping (which calls ioremap())
* cannot be used at such point.
*/
-static volatile struct mpc52xx_gpt *mpc52xx_wdt = NULL;
+static spinlock_t mpc52xx_lock = SPIN_LOCK_UNLOCKED;
+static struct mpc52xx_gpt __iomem *mpc52xx_wdt;
+static struct mpc52xx_cdm __iomem *mpc52xx_cdm;
/**
* mpc52xx_find_ipb_freq - Find the IPB bus frequency for a device
@@ -121,18 +124,27 @@ mpc52xx_declare_of_platform_devices(void)
}
/*
- * match tables used by mpc52xx_map_wdt()
+ * match tables used by mpc52xx_map_common_devices()
*/
static struct of_device_id mpc52xx_gpt_ids[] __initdata = {
{ .compatible = "fsl,mpc5200-gpt", },
{ .compatible = "mpc5200-gpt", }, /* old */
{}
};
+static struct of_device_id mpc52xx_cdm_ids[] __initdata = {
+ { .compatible = "fsl,mpc5200-cdm", },
+ { .compatible = "mpc5200-cdm", }, /* old */
+ {}
+};
+/**
+ * mpc52xx_map_common_devices: iomap devices required by common code
+ */
void __init
-mpc52xx_map_wdt(void)
+mpc52xx_map_common_devices(void)
{
struct device_node *np;
+
/* mpc52xx_wdt is mapped here and used in mpc52xx_restart,
* possibly from a interrupt context. wdt is only implement
* on a gpt0, so check has-wdt property before mapping.
@@ -142,11 +154,56 @@ mpc52xx_map_wdt(void)
of_get_property(np, "has-wdt", NULL)) {
mpc52xx_wdt = of_iomap(np, 0);
of_node_put(np);
- return;
+ break;
}
}
+
+ /* Clock Distribution Module, used by PSC clock setting function */
+ np = of_find_matching_node(NULL, mpc52xx_cdm_ids);
+ mpc52xx_cdm = of_iomap(np, 0);
+ of_node_put(np);
}
Re: [PATCH 2/3] Handle absolute pathnames correctly in dtc_open_file.
On Sun, Jan 06, 2008 at 04:46:24PM -0600, Scott Wood wrote: > On Sun, Jan 06, 2008 at 02:37:16PM +1100, David Gibson wrote: > > > out: > > > + free((void *)file->dir); > > > > That cast shouldn't be there. > > It generates a constness warning otherwise. I was on the fence over > whether to just remove the constness (even though the data is never > modified during its lifetime); would that be preferable? I think that is preferable. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] add phy-handle property for fec_mpc52xx
On 1/9/08, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-01-09 at 09:32 -0700, Grant Likely wrote: > > From: Olaf Hering <[EMAIL PROTECTED]> > > > > This should go into the kernel because its appearently > > impossible to boot the script via tftp and then load the real boot > > binary (yaboot or zimage). > > > > (Olaf's s-o-b line needs to go here) > > Signed-off-by: Grant Likely <[EMAIL PROTECTED]> > > Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > > As much as I despise having to work around firmware bugs, it looks > indeed like this one has been broken for way too long to the point where > users are being hurt, distros are being hurt, and telling people to > whack things in nvramrc is just plain gross, so let's merge it. Thanks Ben. Olaf, can you please reply with your signed-off-by line? Then I'll ask paulus to pick this up for .24 Thanks, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
On Thu, 2008-01-10 at 13:21 +1100, Paul Mackerras wrote: > David Woodhouse writes: > > > It would be much better if the kernel would 'just work'. The ideal way > > of achieving that is for the firmware to be fixed -- but that's been > > promised for a long time now, and we just don't believe you any more. So > > working round it in the kernel seems to be the next best option. > > Does the efika use a boot wrapper? If so then putting the fixup in > the boot wrapper might be better. It's standard OF boot process, the fixup belongs in prom_init. Grant has a better version of the patch that puts the fixup along with other efika related ones that are already there. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] add phy-handle property for fec_mpc52xx
On Wed, 2008-01-09 at 09:32 -0700, Grant Likely wrote:
> From: Olaf Hering <[EMAIL PROTECTED]>
>
> The new network driver fec_mpc52xx will not work on efika because the
> firmware does not provide all required properties.
> http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
> create more properties. But only the phy stuff is required to get a
> working network.
>
> This should go into the kernel because its appearently
> impossible to boot the script via tftp and then load the real boot
> binary (yaboot or zimage).
>
> (Olaf's s-o-b line needs to go here)
> Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
As much as I despise having to work around firmware bugs, it looks
indeed like this one has been broken for way too long to the point where
users are being hurt, distros are being hurt, and telling people to
whack things in nvramrc is just plain gross, so let's merge it.
> ---
>
> Here's my respin of Olaf's patch to move it to fixup_device_tree_efika()
> and to make it check if the nodes exist before blindly creating them.
>
> Cheers,
> g.
>
> arch/powerpc/kernel/prom_init.c | 39
> +++
> 1 files changed, 39 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index 1add6ef..5d89a21 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -2216,6 +2216,45 @@ static void __init fixup_device_tree_efika(void)
> prom_printf("fixup_device_tree_efika: ",
> "skipped entry %x - setprop error\n", i);
> }
> +
> + /* Make sure ethernet mdio bus node exists */
> + node = call_prom("finddevice", 1, 1, ADDR("/builtin/mdio"));
> + if (!PHANDLE_VALID(node)) {
> + prom_printf("Adding Ethernet MDIO node\n");
> + call_prom("interpret", 1, 1,
> + " s\" /builtin\" find-device"
> + " new-device"
> + " 1 encode-int s\" #address-cells\" property"
> + " 0 encode-int s\" #size-cells\" property"
> + " s\" mdio\" 2dup device-name device-type"
> + " s\" mpc5200b-fec-phy\" encode-string"
> + " s\" compatible\" property"
> + " 0xf0003000 0x400 reg"
> + " 0x2 encode-int"
> + " 0x5 encode-int encode+"
> + " 0x3 encode-int encode+"
> + " s\" interrupts\" property"
> + " finish-device");
> + };
> +
> + /* Make sure ethernet phy device node exist */
> + node = call_prom("finddevice", 1, 1,
> ADDR("/builtin/mdio/ethernet-phy"));
> + if (!PHANDLE_VALID(node)) {
> + prom_printf("Adding Ethernet PHY node\n");
> + call_prom("interpret", 1, 1,
> + " s\" /builtin/mdio\" find-device"
> + " new-device"
> + " s\" ethernet-phy\" device-name"
> + " 0x10 encode-int s\" reg\" property"
> + " my-self"
> + " ihandle>phandle"
> + " finish-device"
> + " s\" /builtin/ethernet\" find-device"
> + " encode-int"
> + " s\" phy-handle\" property"
> + " device-end");
> + }
> +
> }
> #else
> #define fixup_device_tree_efika()
>
> ___
> 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
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
On Wed, 2008-01-09 at 22:12 -0600, Linas Vepstas wrote: > On 09/01/2008, Olof Johansson <[EMAIL PROTECTED]> wrote: > > On Wed, Jan 09, 2008 at 08:33:53PM -0600, Linas Vepstas wrote: > > > > > Heh. That's the elbow-grease of this thing. The easy part is to get > > > the core function working. The hard part is to test these various configs, > > > and when they don't work, figure out what went wrong. That will take > > > perseverence and brains. > > > > This just sounds like a whole lot of extra work to get a feature that > > already exists. > > Well, no. kexec is horribly ill-behaved with respect to PCI. The > kexec kernel starts running with PCI devices in some random > state; maybe they're DMA'ing or who knows what. kexec tries > real hard to whack a few needed pci devices into submission > but it has been hit-n-miss, and the source of 90% of the kexec > headaches and debugging effort. Its not pretty. Isn't that what EEH and the IOMMU are for? :) 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 1/8] pseries: phyp dump: Docmentation
On 09/01/2008, Olof Johansson <[EMAIL PROTECTED]> wrote: > On Wed, Jan 09, 2008 at 08:33:53PM -0600, Linas Vepstas wrote: > > > Heh. That's the elbow-grease of this thing. The easy part is to get > > the core function working. The hard part is to test these various configs, > > and when they don't work, figure out what went wrong. That will take > > perseverence and brains. > > This just sounds like a whole lot of extra work to get a feature that > already exists. Well, no. kexec is horribly ill-behaved with respect to PCI. The kexec kernel starts running with PCI devices in some random state; maybe they're DMA'ing or who knows what. kexec tries real hard to whack a few needed pci devices into submission but it has been hit-n-miss, and the source of 90% of the kexec headaches and debugging effort. Its not pretty. If all pci-host bridges could shut-down or settle the bus, and raise the #RST line high, and then if all BIOS'es supported this, you'd be right. But they can't --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [DTC PATCH 2/2] Preserve scanner state when /include/ing.
On Mon, Jan 07, 2008 at 02:27:51PM -0600, Scott Wood wrote: > This allows /include/s to work when in non-default states, > such as PROPNODECHAR. > > We may want to use state stacks to get rid of BEGIN_DEFAULT() altogether... And we should, if we're going to go to stacked states at all. I was anticipating we might need to use stacked states for handling propnamestate as we need expression support. I just hadn't realised we already needed it for includes. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] Return a non-zero exit code if an error occurs during dts parsing.
On Sun, Jan 06, 2008 at 04:55:09PM -0600, Scott Wood wrote: > On Fri, Jan 04, 2008 at 03:30:33PM +1100, David Gibson wrote: > > This is unequivocally wrong. boot_info should have information about > > the contents of the blob, not state information like the error. > > "This blob is invalid" *is* information about the contents of the blob. > > > If you're going to use an ugly global, then use it everywhere. > > Why go out of our way to make the code even less library-able/thread-safe? It doesn't make it any less thread-safe. A global variable used some places is just as bad as a global variable used everywhere from that point of view, and is more complicated. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
On Wed, 2008-01-09 at 20:47 -0600, Linas Vepstas wrote:
> On 09/01/2008, Michael Ellerman <[EMAIL PROTECTED]> wrote:
> >
> > > > Only if you can get at rtas, but you can't get at rtas at that point.
> >
> > AFAICT you don't need to get at RTAS, you just need to look at the
> > device tree to see if the property is present, and that is trivial.
> >
> > You probably just need to add a check in early_init_dt_scan_rtas() which
> > sets a flag for the PHYP dump stuff, or add your own scan routine if you
> > need.
>
> I no longer remember the details. I do remember spending a lot of time
> trying to figure out how to do this. I know I didn't want to write my own scan
> routine; maybe that's what stopped me. As it happens, we also did most
> of the development on a broken phyp which simply did not even have
> this property, no matter what, and so that may have brain-damaged me.
Sure, the API docs for the kernel are a little lacking ;)
> I went for the "most elegant" solution, where "most elegant" is defined
> as "fewest lines of code", "least effort", etc.
>
> Manish may need some hands-on help to extract this token during
> early boot. Hopefully, he'll let us know.
It would just be something like:
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -901,6 +901,11 @@ int __init early_init_dt_scan_rtas(unsigned long node,
rtas.size = *sizep;
}
+#ifdef CONFIG_PHYP_DUMP
+ if (of_get_flat_dt_prop(node, "ibm,dump-kernel", NULL))
+ phyp_dump_is_active++;
+#endif
+
#ifdef CONFIG_UDBG_RTAS_CONSOLE
basep = of_get_flat_dt_prop(node, "put-term-char", NULL);
if (basep)
Or to do your own scan routine:
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index acc0d24..442134e 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -1022,6 +1022,7 @@ void __init early_init_devtree(void *params)
/* Some machines might need RTAS info for debugging, grab it now. */
of_scan_flat_dt(early_init_dt_scan_rtas, NULL);
#endif
+ of_scan_flat_dt(early_init_dt_scan_phyp_dump, NULL);
/* Retrieve various informations from the /chosen node of the
* device-tree, including the platform type, initrd location and
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 52e95c2..af2b6e8 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -883,6 +883,19 @@ void __init rtas_initialize(void)
#endif
}
+int __init early_init_dt_scan_phyp_dump(unsigned long node,
+ const char *uname, int depth, void *data)
+{
+#ifdef CONFIG_PHYP_DUMP
+ if (depth != 1 || strcmp(uname, "rtas") != 0)
+ return 0;
+
+ if (of_get_flat_dt_prop(node, "ibm,dump-kernel", NULL))
+ phyp_dump_is_active++;
+#endif
+ return 1;
+}
+
int __init early_init_dt_scan_rtas(unsigned long node,
const char *uname, int depth, void *data)
{
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 2/3] Look for include files in the directory of the including file.
On Sun, Jan 06, 2008 at 04:52:52PM -0600, Scott Wood wrote:
> On Fri, Jan 04, 2008 at 03:27:39PM +1100, David Gibson wrote:
> > > + newfile = dtc_open_file(filename, searchptr);
> > > + if (!newfile) {
> > > + yyerrorf("Couldn't open \"%s\": %s",
> > > + filename, strerror(errno));
> > > + exit(1);
> >
> > Use die() here, that's what it's for.
>
> die() doesn't print file and line information.
>
> > > + while (search) {
> > > + if (dtc_open_one(file, search->dir, fname))
> > > + return file;
> >
> > Don't we need a different case here somewhere for if someone specifies
> > an include file as an absolute path? Have I missed something?
>
> Yeah, I forgot about that, and sent another patch to fix it when I
> noticed (jdl had already pulled, so I didn't send an amended patch).
>
> > [snip]
> > > +struct search_path {
> > > + const char *dir; /* NULL for current directory */
> > > + struct search_path *prev, *next;
> > > +};
> >
> > I wouldn't suggest a doubly linked list here. Or at least not without
> > converting our many existing singly linked lists at the same time.
>
> The doubly-linked list is intended to make it easier to construct search
> path lists one-at-a-time from arguments in the proper order, without
> needing to reverse the list at the end.
We've already got that problem with a bunch of the lists we create
during parsing (we have several ugly add-to-end-of-singly-linked-list
functions). Going to doubly-linked lists might not be a bad idea, but
we should do it across the board, probably using the kernel's list.h
or something like it.
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH] ASoC drivers for the Freescale MPC8610 SoC
On Mon, Jan 07, 2008 at 06:28:54PM +, Mark Brown wrote: > On Mon, Jan 07, 2008 at 09:52:03AM -0600, Timur Tabi wrote: > > David Gibson wrote: > > > > Ok, but couldn't you strucutre your I2S or fabric driver so that it > > > only becomes fully operational once the codec driver has registered > > > with it? > > > Not in ASoC V1. You have to understand, ASoC V1 was designed without any > > consideration for runtime-bindings and other OF goodies. All connections > > between the drivers are static, literally. In fact, I wouldn't be > > surprised if > > some ASoC drivers cannot be compiled as modules. > > I'd just like to emphasise this point - ASoC v1 really doesn't > understand the idea that the components of the sound subsystem might be > probed separately. It's set up to handle bare hardware with everything > being probed from code in the machine/fabric driver. This makes life > very messy for platforms with something like the device tree. > > As has been said, handling this properly is one of the major motivations > behind ASoC v2. Ick. Ok. Nonetheless, messing up the device tree to workaround ASoC V1's silly limitations is not a good idea. The device tree must represent the hardware as much as possible. If that means we have to have a bunch of platform-specific hacks to instatiate the drivers in the correct order / combination, that's unfortunate, but there you go. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] Warp Base Platform - dts
On Wed, Jan 09, 2008 at 10:33:56PM -0500, Sean MacLennan wrote: > Ok, the FPGA is off the EBC, I found it in the documentation. > > Under the ebc, I notice the walnut has @n,m. What are n,m? Are they tied > to chip selects? n is the chipselect, m is the address offset within that chipselect. > The FPGA is CS2 according to the documentation. Do I make it > [EMAIL PROTECTED],0? Probably, yes. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] Warp Base Platform - dts
On Wed, 09 Jan 2008 22:33:56 -0500 Sean MacLennan <[EMAIL PROTECTED]> wrote: > Ok, the FPGA is off the EBC, I found it in the documentation. > > Under the ebc, I notice the walnut has @n,m. What are n,m? Are they tied > to chip selects? chip select,offset. > The FPGA is CS2 according to the documentation. Do I make it [EMAIL > PROTECTED],0? If the fpga is on chip select 2, offset 0 from that, yes. Otherwise, substitute the proper offset in place of 0. The ranges property of the EBC node will do the actual address translation. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] Warp Base Platform - dts
Ok, the FPGA is off the EBC, I found it in the documentation. Under the ebc, I notice the walnut has @n,m. What are n,m? Are they tied to chip selects? The FPGA is CS2 according to the documentation. Do I make it [EMAIL PROTECTED],0? Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/5] Warp Base Platform
On Wed, Jan 09, 2008 at 10:17:26PM -0500, Sean MacLennan wrote:
> David Gibson wrote:
> > On Wed, Jan 09, 2008 at 03:22:46PM -0500, Sean MacLennan wrote:
> >
> >> Basically the powerpc/boot directory files.
> >>
> >
> > [snip]
> >
> >> --- /dev/null 2005-11-20 22:22:37.0 -0500
> >> +++ arch/powerpc/boot/cuboot-warp.c2008-01-08 12:09:39.0
> >> -0500
> >> @@ -0,0 +1,25 @@
> >> +/*
> >> + * Copyright (c) 2008 PIKA Technologies
> >> + * Sean MacLennan <[EMAIL PROTECTED]>
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify it
> >> + * under the terms of the GNU General Public License version 2 as
> >> published
> >> + * by the Free Software Foundation.
> >> + */
> >> +
> >> +#include "ops.h"
> >> +#include "44x.h"
> >> +#include "cuboot.h"
> >> +
> >> +#define TARGET_44x
> >> +#include "ppcboot.h"
> >> +
> >> +static bd_t bd;
> >> +
> >> +void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
> >> + unsigned long r6, unsigned long r7)
> >> +{
> >> + CUBOOT_INIT();
> >> +
> >> + warp_init(&bd.bi_enetaddr, &bd.bi_enet1addr);
> >> +}
> >> --- /dev/null 2005-11-20 22:22:37.0 -0500
> >> +++ arch/powerpc/boot/warp.c 2008-01-08 12:09:54.0 -0500
> >>
> >
> > Fold all this into cuboot-warp.c, unless you actually anticipate
> > adding another wrapper for another firmware which will also use the
> > functions in warp.c.
> >
> >
> Yes, there is still a plan to use the u-boot device tree. Although not
> in the near feature. I could roll them togeather for now and split them
> out later.
Yes, but device-tree aware u-boot doesn't need anything platform
specific in the bootwrapper, so won't be a second user of warp.c.
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] Warp Base Platform - dts
On Wed, 09 Jan 2008 22:14:17 -0500
Sean MacLennan <[EMAIL PROTECTED]> wrote:
> David Gibson wrote:
> > On Wed, Jan 09, 2008 at 03:21:07PM -0500, Sean MacLennan wrote:
> >
> >> Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
> >> ---
> >> --- /dev/null 2005-11-20 22:22:37.0 -0500
> >> +++ arch/powerpc/boot/dts/warp.dts 2008-01-08 12:04:10.0 -0500
> >>
> >
> > [snip]
> >
> >> + plb {
> >> + compatible = "ibm,plb-440ep", "ibm,plb-440gp", "ibm,plb4";
> >> + #address-cells = <2>;
> >> + #size-cells = <1>;
> >> + ranges;
> >> + clock-frequency = <0>; /* Filled in by zImage */
> >> +
> >> + SDRAM0: sdram {
> >> + compatible = "ibm,sdram-440ep", "ibm,sdram-405gp";
> >> + dcr-reg = <010 2>;
> >> + };
> >> +
> >> + DMA0: dma {
> >> + compatible = "ibm,dma-440ep", "ibm,dma-440gp";
> >> + dcr-reg = <100 027>;
> >> + };
> >> +
> >> + FPGA0: fpga {
> >>
> >
> > Surely this must be off the EBC, not directly of the PLB...?
> >
> Could be, I don't really know :( I will move it if it makes more sense.
Well, "making more sense" would be finding out where it is on the board
and putting it in the proper place :).
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/5] Warp Base Platform
David Gibson wrote:
> On Wed, Jan 09, 2008 at 03:22:46PM -0500, Sean MacLennan wrote:
>
>> Basically the powerpc/boot directory files.
>>
>
> [snip]
>
>> --- /dev/null2005-11-20 22:22:37.0 -0500
>> +++ arch/powerpc/boot/cuboot-warp.c 2008-01-08 12:09:39.0 -0500
>> @@ -0,0 +1,25 @@
>> +/*
>> + * Copyright (c) 2008 PIKA Technologies
>> + * Sean MacLennan <[EMAIL PROTECTED]>
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published
>> + * by the Free Software Foundation.
>> + */
>> +
>> +#include "ops.h"
>> +#include "44x.h"
>> +#include "cuboot.h"
>> +
>> +#define TARGET_44x
>> +#include "ppcboot.h"
>> +
>> +static bd_t bd;
>> +
>> +void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
>> + unsigned long r6, unsigned long r7)
>> +{
>> +CUBOOT_INIT();
>> +
>> +warp_init(&bd.bi_enetaddr, &bd.bi_enet1addr);
>> +}
>> --- /dev/null2005-11-20 22:22:37.0 -0500
>> +++ arch/powerpc/boot/warp.c 2008-01-08 12:09:54.0 -0500
>>
>
> Fold all this into cuboot-warp.c, unless you actually anticipate
> adding another wrapper for another firmware which will also use the
> functions in warp.c.
>
>
Yes, there is still a plan to use the u-boot device tree. Although not
in the near feature. I could roll them togeather for now and split them
out later.
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] Warp Base Platform - dts
David Gibson wrote:
> On Wed, Jan 09, 2008 at 03:21:07PM -0500, Sean MacLennan wrote:
>
>> Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
>> ---
>> --- /dev/null2005-11-20 22:22:37.0 -0500
>> +++ arch/powerpc/boot/dts/warp.dts 2008-01-08 12:04:10.0 -0500
>>
>
> [snip]
>
>> +plb {
>> +compatible = "ibm,plb-440ep", "ibm,plb-440gp", "ibm,plb4";
>> +#address-cells = <2>;
>> +#size-cells = <1>;
>> +ranges;
>> +clock-frequency = <0>; /* Filled in by zImage */
>> +
>> +SDRAM0: sdram {
>> +compatible = "ibm,sdram-440ep", "ibm,sdram-405gp";
>> +dcr-reg = <010 2>;
>> +};
>> +
>> +DMA0: dma {
>> +compatible = "ibm,dma-440ep", "ibm,dma-440gp";
>> +dcr-reg = <100 027>;
>> +};
>> +
>> +FPGA0: fpga {
>>
>
> Surely this must be off the EBC, not directly of the PLB...?
>
Could be, I don't really know :( I will move it if it makes more sense.
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: How complete should the DTS be?
On Tue, Jan 08, 2008 at 12:04:36AM -0600, Kumar Gala wrote: > > On Jan 7, 2008, at 8:07 PM, Sean MacLennan wrote: > > > Just a general question about DTS "completeness". Like all 440EP > > processors, the taco has two i2c buses. However, only one bus has > > anything connected to it. > > > > Should I show both bus entries in the DTS, or only the one that is > > used? > > I have generally only been showing the devices that are present. i.e. > > Only one emac, only one serial port. > > > > Is there a convention for this? > > The .dts should reflect the HW as its used. On some reference boards > we might put out more info because of the various configs these types > of boards can be setup in. However if something has a static config > just describe that. So in your example of two i2c buses with only one > connected, just describe the one that is used. Hrm... I'd say this is not something which has a firm convention yet. It's going to become more of an issue once we get a macros system for dtc, so the "440EP" macro would have all the devices, even if some are not connected on a given board. I'm contemplating suggesting that we adopt the "status" property from IEEE1275 to cover this. -- 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
On Wed, Jan 09, 2008 at 08:33:53PM -0600, Linas Vepstas wrote: > Heh. That's the elbow-grease of this thing. The easy part is to get > the core function working. The hard part is to test these various configs, > and when they don't work, figure out what went wrong. That will take > perseverence and brains. This just sounds like a whole lot of extra work to get a feature that already exists. Also, features like these seem to just get tested when the next enterprise distro is released, so they're broken for long stretches of time in mainline. There's a bunch of problems like the NUMA ones, which would by far be easiest to solve by just doing another reboot or kexec, wouldn't they? -Olof ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] sbc8560: Add device tree source for Wind River SBC8560 board
On Mon, Jan 07, 2008 at 09:25:29AM -0500, Paul Gortmaker wrote:
> This adds the device tree source for the Wind River SBC8560 board. The
> biggest difference between this and the MPC8560ADS reference platform
> dts is the use of an external 16550 compatible UART instead of the CPM2.
>
> Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/sbc8560.dts | 285
> +
[snip]
> + [EMAIL PROTECTED] {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "localbus";
This compatible doesn't look specific enough. It should at least have
a vendor prefix.
> + ranges = <0 fc00 00c0>;
Typically, we've been doing these external bust controller type
gadgets with address-cells = <2>, the first cell explicitly encoding
the chipselect. This gets us closer to the ideal of the device tree
encoding only hardware information, not how the bridge controller is
configured (although "ranges" will still have to contain configuration
dependent information).
> +
> + serial0: [EMAIL PROTECTED] {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <70 100>;
> + clock-frequency = <1C2000>;
> + interrupts = <9 2>;
> + interrupt-parent = <&mpic>;
> + };
> +
> + serial1: [EMAIL PROTECTED] {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <80 100>;
> + clock-frequency = <1C2000>;
> + interrupts = ;
> + interrupt-parent = <&mpic>;
> + };
> +
> + [EMAIL PROTECTED] {
> + compatible = "m48t59";
> + reg = <90 2000>;
> + };
> + };
> +};
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/5] Warp Base Platform
On Wed, Jan 09, 2008 at 03:22:46PM -0500, Sean MacLennan wrote:
> Basically the powerpc/boot directory files.
[snip]
> --- /dev/null 2005-11-20 22:22:37.0 -0500
> +++ arch/powerpc/boot/cuboot-warp.c 2008-01-08 12:09:39.0 -0500
> @@ -0,0 +1,25 @@
> +/*
> + * Copyright (c) 2008 PIKA Technologies
> + * Sean MacLennan <[EMAIL PROTECTED]>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> + * by the Free Software Foundation.
> + */
> +
> +#include "ops.h"
> +#include "44x.h"
> +#include "cuboot.h"
> +
> +#define TARGET_44x
> +#include "ppcboot.h"
> +
> +static bd_t bd;
> +
> +void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
> +unsigned long r6, unsigned long r7)
> +{
> + CUBOOT_INIT();
> +
> + warp_init(&bd.bi_enetaddr, &bd.bi_enet1addr);
> +}
> --- /dev/null 2005-11-20 22:22:37.0 -0500
> +++ arch/powerpc/boot/warp.c 2008-01-08 12:09:54.0 -0500
Fold all this into cuboot-warp.c, unless you actually anticipate
adding another wrapper for another firmware which will also use the
functions in warp.c.
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/5] Warp Base Platform - dts
On Wed, Jan 09, 2008 at 03:21:07PM -0500, Sean MacLennan wrote:
> Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
> ---
> --- /dev/null 2005-11-20 22:22:37.0 -0500
> +++ arch/powerpc/boot/dts/warp.dts2008-01-08 12:04:10.0 -0500
[snip]
> + plb {
> + compatible = "ibm,plb-440ep", "ibm,plb-440gp", "ibm,plb4";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges;
> + clock-frequency = <0>; /* Filled in by zImage */
> +
> + SDRAM0: sdram {
> + compatible = "ibm,sdram-440ep", "ibm,sdram-405gp";
> + dcr-reg = <010 2>;
> + };
> +
> + DMA0: dma {
> + compatible = "ibm,dma-440ep", "ibm,dma-440gp";
> + dcr-reg = <100 027>;
> + };
> +
> + FPGA0: fpga {
Surely this must be off the EBC, not directly of the PLB...?
> + compatible = "pika,fpga";
> + reg = <0 8000 2200>;
> + interrupts = <18 8>;
> + interrupt-parent = <&UIC0>;
> + };
[snip]
> + IIC0: [EMAIL PROTECTED] {
> + device_type = "i2c";
Drop this device_type.
> + compatible = "ibm,iic-440ep", "ibm,iic-440gp",
> "ibm,iic";
> + reg = ;
> + interrupt-parent = <&UIC0>;
> + interrupts = <2 4>;
> + };
> +
> + ZMII0: [EMAIL PROTECTED] {
> + device_type = "zmii-interface";
And this one.
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
On 09/01/2008, Michael Ellerman <[EMAIL PROTECTED]> wrote: > > > > Only if you can get at rtas, but you can't get at rtas at that point. > > AFAICT you don't need to get at RTAS, you just need to look at the > device tree to see if the property is present, and that is trivial. > > You probably just need to add a check in early_init_dt_scan_rtas() which > sets a flag for the PHYP dump stuff, or add your own scan routine if you > need. I no longer remember the details. I do remember spending a lot of time trying to figure out how to do this. I know I didn't want to write my own scan routine; maybe that's what stopped me. As it happens, we also did most of the development on a broken phyp which simply did not even have this property, no matter what, and so that may have brain-damaged me. I went for the "most elegant" solution, where "most elegant" is defined as "fewest lines of code", "least effort", etc. Manish may need some hands-on help to extract this token during early boot. Hopefully, he'll let us know. --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
David Woodhouse writes: > It would be much better if the kernel would 'just work'. The ideal way > of achieving that is for the firmware to be fixed -- but that's been > promised for a long time now, and we just don't believe you any more. So > working round it in the kernel seems to be the next best option. Does the efika use a boot wrapper? If so then putting the fixup in the boot wrapper might be better. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] Device tree for MPC5121 ADS
On Tue, Jan 08, 2008 at 09:01:30AM -0700, John Rigby wrote:
> Bare minimum tree containing only
> what is currently supported.
[snip]
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + PowerPC,[EMAIL PROTECTED] {
> + device_type = "cpu";
> + reg = <0>;
> + d-cache-line-size = <20>; // 32 bytes
> + i-cache-line-size = <20>; // 32 bytes
> + d-cache-size = <8000>; // L1, 32K
> + i-cache-size = <8000>; // L1, 32K
> + ref-frequency = <3ef1480>; // 66MHz ref clock
> + timebase-frequency = <2f34f60>; // 49.5MHz (396MHz/8)
> makes time tick correctly
> + bus-frequency = ; // 198MHz csb bus
> + clock-frequency = <179a7b00>; // 396MHz ppc core ??
> + 32-bit;
The "32-bit" property was only ever added by mistake. Drop it.
[snip]
> + [EMAIL PROTECTED] {
> + device_type = "board-control";
No device_type here. But you should have a "compatible" property.
[snip]
> + [EMAIL PROTECTED] {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #interrupt-cells = <2>;
> + device_type = "soc";
> + ranges = <0 8000 40>;
> + reg = <8000 40>;
> + ref-frequency = <3ef1480>; // 66MHz ref
What the hell is ref-frequency? Unfortunately, you have to work with
existing broken practice for SoC nodes here, but the principle clock
frequency for any device should always be encoded in a property called
"clock-frequency".
[snip]
> + ipic: [EMAIL PROTECTED] {
Should be "[EMAIL PROTECTED]"
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + reg = ;
> + built-in;
> + device_type = "ipic";
Drop this device_type. Should have a compatible value instead.
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
On 09/01/2008, Nathan Lynch <[EMAIL PROTECTED]> wrote: > Hi Linas, > > Linas Vepstas wrote: > > > > As a side effect, the system is in > > production *while* the dump is being taken; > > A dubious feature IMO. Hmm. Take it up with Ken Rozendal, this is supposed to be one of the two main selling points of this thing. > Seems that the design potentially trades > reliability of first failure data capture for availability. > E.g. system crashes, reboots, resumes processing while copying dump, > crashes again before dump procedure is complete. How is that handled, > if at all? Its handled by the hypervisor. phyp maintains the copy of the RMO of first crash, until such time that the OS declares the dump of the RMO to be complete. So you'll always have the RMO of the first crash. For the rest of RAM, it will come in two parts: some portion will have been dumped already. The rest has not yet been dumped, and it will still be there, preserved across the second crash. So you get both RMO and all of RAM from the first crash. > > with kdump, > > you can't go into production until after the dump is finished, > > and the system has been rebooted a second time. On > > systems with terabytes of RAM, the time difference can be > > hours. > > The difference in time it takes to resume the normal workload may be > significant, yes. But the time it takes to get a usable dump image > would seem to be the basically the same. Yes. > Since you bring up large systems... a system with terabytes of RAM is > practically guaranteed to be a NUMA configuration with dozens of cpus. > When processing a dump on such a system, I wonder how well we fare: > can we successfully boot with (say) 128 cpus and 256MB of usable > memory? Do we have to hot-online nodes as system memory is freed up > (and does that even work)? We need to be able to restore the system > to its optimal topology when the dump is finished; if the best we can > do is a degraded configuration, the workload will suffer and the > system admin is likely to just reboot the machine again so the kernel > will have the right NUMA topology. Heh. That's the elbow-grease of this thing. The easy part is to get the core function working. The hard part is to test these various configs, and when they don't work, figure out what went wrong. That will take perseverence and brains. --linas ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
Olaf Hering writes:
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -1487,6 +1487,34 @@ static void __init prom_find_mmu(void)
> else if (strncmp(version, "FirmWorks,3.", 12) == 0) {
> of_workarounds = OF_WA_CLAIM | OF_WA_LONGTRAIL;
> call_prom("interpret", 1, 1, "dev /memory 0 to allow-reclaim");
> +#ifdef CONFIG_PPC_MPC52xx
> + } else if (strcmp(version, "EFIKA5K2") == 0) {
Why have you added this stuff in prom_find_mmu rather than putting it
in fixup_device_tree_efika()?
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
On Wed, 9 Jan 2008 18:36:34 -0600 Olof Johansson <[EMAIL PROTECTED]> wrote:
>
> On Thu, Jan 10, 2008 at 10:40:48AM +1100, Stephen Rothwell wrote:
> > Hi Anton,
> >
> > Juts one small trivial comment (could be fixed later).
> >
> > On Wed, 9 Jan 2008 22:10:41 +0300 Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> > >
> > > +static struct of_device_id pata_of_platform_match[] = {
> >
> > This could be declared const.
>
> Good point, but let's not hold up merge based on this. Need something
> for janitors to do too, and it's good enough to merge as-is. :)
Absolutely. To me that is what "(could be fixed later)" means. :-)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpYYgEkMnLa3.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] sbc834x: Add device tree source for Wind River SBC834x board.
On Wed, Jan 09, 2008 at 12:49:31AM -0500, Paul Gortmaker wrote:
> This adds the device tree source for the Wind River SBC834x board.
> It is based on the MPC834x_MDS DTS, with the biggest difference being
> the lack of BCSR and the PCI2 that the MDS gets via the PIB. That,
> and this file is also dts-v1 format.
>
> Signed-off-by: Paul Gortmaker <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/sbc8349.dts | 247
> +
> 1 files changed, 247 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/sbc8349.dts
> b/arch/powerpc/boot/dts/sbc8349.dts
[snip]
> + [EMAIL PROTECTED] {
> + device_type = "watchdog";
> + compatible = "mpc83xx_wdt";
Grah! Hasn't someone fixed this so that the driver doesn't need the
crap device_type?
[snip]
> + [EMAIL PROTECTED] {
> + device_type = "spi";
> + compatible = "fsl_spi";
And again here.
[snip]
> + [EMAIL PROTECTED] {
> + device_type = "usb";
> + compatible = "fsl-usb2-mph";
And here.
[snip
> + /* May need to remove if on a part without crypto engine */
> + [EMAIL PROTECTED] {
> + device_type = "crypto";
> + model = "SEC2";
> + compatible = "talitos";
I'm almost certain this one was fixed, hasn't it been merged yet?
[snip]
> + ipic: [EMAIL PROTECTED] {
By generic names best practice this should be
"[EMAIL PROTECTED]", although that's probably not your error.
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 4/4 v3] PS3: Add logical performance monitor driver support
From: Takashi Yamamoto <[EMAIL PROTECTED]> Add PS3 logical performance monitor (lpm) device driver. The PS3's LV1 hypervisor provides a Logical Performance Monitor that abstracts the Cell processor's performance monitor features for use by guest operating systems. Signed-off-by: Takashi Yamamoto <[EMAIL PROTECTED]> Signed-off-by: Geoff Levand <[EMAIL PROTECTED]> --- v2: o Correct Yamamoto-san's mail addr. o Text cleanups. o Added more comments explaining lpm operation. o Split SRPN_BKMK into separate patch. o Use get_hard_smp_processor_id() in ps3_get_hw_thread_id(). o Split ps3_copy_trace_buffer() into ps3_lpm_copy_tb() and ps3_lpm_copy_tb_to_user(). o Replace mutex with atomic_t in ps3_lpm_open()/ps3_lpm_close(). o General cleanup of ps3_lpm_open()/ps3_lpm_close(). v3: o Add BE node_id to struct lpm_priv. o Change some dev_err() to dev_dbg(). o Fix kzalloc() bug. o Text fix 'lost' -> 'loss'. o Use lpm_priv->node_id with lv1_construct_lpm(). arch/powerpc/platforms/ps3/Kconfig | 13 drivers/ps3/Makefile |1 drivers/ps3/ps3-lpm.c | 1248 + include/asm-powerpc/ps3.h | 62 + 4 files changed, 1324 insertions(+) create mode 100644 arch/powerpc/platforms/ps3/ps3-lpm.c --- a/arch/powerpc/platforms/ps3/Kconfig +++ b/arch/powerpc/platforms/ps3/Kconfig @@ -138,4 +138,17 @@ config PS3_FLASH be disabled on the kernel command line using "ps3flash=off", to not allocate this fixed buffer. +config PS3_LPM + tristate "PS3 Logical Performance Monitor support" + depends on PPC_PS3 + help + Include support for the PS3 Logical Performance Monitor. + + This support is required to use the logical performance monitor + of the PS3's LV1 hypervisor. + + If you intend to use the advanced performance monitoring and + profiling support of the Cell processor with programs like + oprofile and perfmon2, then say Y or M, otherwise say N. + endmenu --- a/drivers/ps3/Makefile +++ b/drivers/ps3/Makefile @@ -4,3 +4,4 @@ ps3av_mod-objs += ps3av.o ps3av_cmd.o obj-$(CONFIG_PPC_PS3) += sys-manager-core.o obj-$(CONFIG_PS3_SYS_MANAGER) += ps3-sys-manager.o obj-$(CONFIG_PS3_STORAGE) += ps3stor_lib.o +obj-$(CONFIG_PS3_LPM) += ps3-lpm.o --- /dev/null +++ b/drivers/ps3/ps3-lpm.c @@ -0,0 +1,1248 @@ +/* + * PS3 Logical Performance Monitor. + * + * Copyright (C) 2007 Sony Computer Entertainment Inc. + * Copyright 2007 Sony Corp. + * + * 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; version 2 of the License. + * + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include +#include +#include +#include +#include +#include +#include + + +/* BOOKMARK tag macros */ +#define PS3_PM_BOOKMARK_START0x8000ULL +#define PS3_PM_BOOKMARK_STOP 0x4000ULL +#define PS3_PM_BOOKMARK_TAG_KERNEL 0x1000ULL +#define PS3_PM_BOOKMARK_TAG_USER 0x3000ULL +#define PS3_PM_BOOKMARK_TAG_MASK_HI 0xF000ULL +#define PS3_PM_BOOKMARK_TAG_MASK_LO 0x0F00ULL + +/* CBE PM CONTROL register macros */ +#define PS3_PM_CONTROL_PPU_TH0_BOOKMARK 0x1000 +#define PS3_PM_CONTROL_PPU_TH1_BOOKMARK 0x0800 +#define PS3_PM_CONTROL_PPU_COUNT_MODE_MASK 0x000C +#define PS3_PM_CONTROL_PPU_COUNT_MODE_PROBLEM0x0008 +#define PS3_WRITE_PM_MASK0xULL + +/* CBE PM START STOP register macros */ +#define PS3_PM_START_STOP_PPU_TH0_BOOKMARK_START 0x0200 +#define PS3_PM_START_STOP_PPU_TH1_BOOKMARK_START 0x0100 +#define PS3_PM_START_STOP_PPU_TH0_BOOKMARK_STOP 0x0002 +#define PS3_PM_START_STOP_PPU_TH1_BOOKMARK_STOP 0x0001 +#define PS3_PM_START_STOP_START_MASK 0xFF00 +#define PS3_PM_START_STOP_STOP_MASK 0x00FF + +/* CBE PM COUNTER register macres */ +#define PS3_PM_COUNTER_MASK_HI 0xULL +#define PS3_PM_COUNTER_MASK_LO 0xULL + +/* BASE SIGNAL GROUP NUMBER macros */ +#define PM_ISLAND2_BASE_SIGNAL_GROUP_NUMBER 0 +#define PM_ISLAND2_SIGNAL_GROUP_NUMBER1 6 +#define PM_ISLAND2_SIGNAL_GROUP_NUMBER2 7 +#define PM_ISLAND3_BASE_SIGNAL_GROUP_NUMBER 7 +#define PM_ISLAND4_BA
[patch 3/4 v3] PS3: Add logical performance monitor device support
Add PS3 logical performance monitor device support to the
PS3 system-bus and platform device registration routines.
Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
---
v2: o Add enum ps3_lpm_tb_type.
o Remove redundant enclosing structure and return proper
error codes from ps3_register_lpm_devices().
v3: o Add lpm.node_id to struct ps3_system_bus_device.
o Cleanup repository discovery logic.
arch/powerpc/platforms/ps3/device-init.c | 85 +++
arch/powerpc/platforms/ps3/system-bus.c |5 +
include/asm-powerpc/ps3.h|8 ++
3 files changed, 98 insertions(+)
create mode 100644 arch/powerpc/platforms/ps3/lpm.c
--- a/arch/powerpc/platforms/ps3/device-init.c
+++ b/arch/powerpc/platforms/ps3/device-init.c
@@ -30,6 +30,89 @@
#include "platform.h"
+static int __init ps3_register_lpm_devices(void)
+{
+ int result;
+ u64 tmp1;
+ u64 tmp2;
+ struct ps3_system_bus_device *dev;
+
+ pr_debug(" -> %s:%d\n", __func__, __LINE__);
+
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev)
+ return -ENOMEM;
+
+ dev->match_id = PS3_MATCH_ID_LPM;
+ dev->dev_type = PS3_DEVICE_TYPE_LPM;
+
+ /* The current lpm driver only supports a single BE processor. */
+
+ result = ps3_repository_read_be_node_id(0, &dev->lpm.node_id);
+
+ if (result) {
+ pr_debug("%s:%d: ps3_repository_read_be_node_id failed \n",
+ __func__, __LINE__);
+ goto fail_read_repo;
+ }
+
+ result = ps3_repository_read_lpm_privileges(dev->lpm.node_id, &tmp1,
+ &dev->lpm.rights);
+
+ if (result) {
+ pr_debug("%s:%d: ps3_repository_read_lpm_privleges failed \n",
+ __func__, __LINE__);
+ goto fail_read_repo;
+ }
+
+ lv1_get_logical_partition_id(&tmp2);
+
+ if (tmp1 != tmp2) {
+ pr_debug("%s:%d: wrong lpar\n",
+ __func__, __LINE__);
+ result = -ENODEV;
+ goto fail_rights;
+ }
+
+ if (!(dev->lpm.rights & PS3_LPM_RIGHTS_USE_LPM)) {
+ pr_debug("%s:%d: don't have rights to use lpm\n",
+ __func__, __LINE__);
+ result = -EPERM;
+ goto fail_rights;
+ }
+
+ pr_debug("%s:%d: pu_id %lu, rights %lu(%lxh)\n",
+ __func__, __LINE__, dev->lpm.pu_id, dev->lpm.rights,
+ dev->lpm.rights);
+
+ result = ps3_repository_read_pu_id(0, &dev->lpm.pu_id);
+
+ if (result) {
+ pr_debug("%s:%d: ps3_repository_read_pu_id failed \n",
+ __func__, __LINE__);
+ goto fail_read_repo;
+ }
+
+ result = ps3_system_bus_device_register(dev);
+
+ if (result) {
+ pr_debug("%s:%d ps3_system_bus_device_register failed\n",
+ __func__, __LINE__);
+ goto fail_register;
+ }
+
+ pr_debug(" <- %s:%d\n", __func__, __LINE__);
+ return 0;
+
+
+fail_register:
+fail_rights:
+fail_read_repo:
+ kfree(dev);
+ pr_debug(" <- %s:%d: failed\n", __func__, __LINE__);
+ return result;
+}
+
/**
* ps3_setup_gelic_device - Setup and register a gelic device instance.
*
@@ -787,6 +870,8 @@ static int __init ps3_register_devices(v
ps3_register_sound_devices();
+ ps3_register_lpm_devices();
+
pr_debug(" <- %s:%d\n", __func__, __LINE__);
return 0;
}
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -715,6 +715,7 @@ int ps3_system_bus_device_register(struc
static unsigned int dev_ioc0_count;
static unsigned int dev_sb_count;
static unsigned int dev_vuart_count;
+ static unsigned int dev_lpm_count;
if (!dev->core.parent)
dev->core.parent = &ps3_system_bus;
@@ -737,6 +738,10 @@ int ps3_system_bus_device_register(struc
snprintf(dev->core.bus_id, sizeof(dev->core.bus_id),
"vuart_%02x", ++dev_vuart_count);
break;
+ case PS3_DEVICE_TYPE_LPM:
+ snprintf(dev->core.bus_id, sizeof(dev->core.bus_id),
+ "lpm_%02x", ++dev_lpm_count);
+ break;
default:
BUG();
};
--- a/include/asm-powerpc/ps3.h
+++ b/include/asm-powerpc/ps3.h
@@ -317,6 +317,7 @@ enum ps3_match_id {
PS3_MATCH_ID_STOR_FLASH = 8,
PS3_MATCH_ID_SOUND = 9,
PS3_MATCH_ID_GRAPHICS = 10,
+ PS3_MATCH_ID_LPM= 11,
};
#define PS3_MODULE_ALIAS_EHCI "ps3:1"
@@ -329,11 +330,13 @@ enum ps3_match_id {
#define PS3_MODULE_ALIAS_STOR_FLASH "ps3:8"
#define PS3_MODULE_ALIAS_SOUND "ps3:9"
#define PS3_MODULE_ALIAS_GRAPHICS "ps3:10"
+#define PS3_MODULE_ALIAS_LPM"ps3:11"
enum ps3_system_bu
[patch 2/4 v3] PS3: Add logical performance monitor repository routines
From: Takashi Yamamoto <[EMAIL PROTECTED]>
Add repository routines for the PS3 logical performance monitor.
Signed-off-by: Takashi Yamamoto <[EMAIL PROTECTED]>
Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
---
v2: o Correct Yamamoto-san's mail addr.
v3: o Change num_pu and pu_id to type u64.
o Add comments to describe some symbol names.
arch/powerpc/platforms/ps3/platform.h | 12 +++--
arch/powerpc/platforms/ps3/repository.c | 75 +++-
2 files changed, 83 insertions(+), 4 deletions(-)
--- a/arch/powerpc/platforms/ps3/platform.h
+++ b/arch/powerpc/platforms/ps3/platform.h
@@ -186,10 +186,10 @@ int ps3_repository_read_stor_dev_region(
unsigned int dev_index, unsigned int region_index,
unsigned int *region_id, u64 *region_start, u64 *region_size);
-/* repository pu and memory info */
+/* repository logical pu and memory info */
-int ps3_repository_read_num_pu(unsigned int *num_pu);
-int ps3_repository_read_ppe_id(unsigned int *pu_index, unsigned int *ppe_id);
+int ps3_repository_read_num_pu(u64 *num_pu);
+int ps3_repository_read_pu_id(unsigned int pu_index, u64 *pu_id);
int ps3_repository_read_rm_base(unsigned int ppe_id, u64 *rm_base);
int ps3_repository_read_rm_size(unsigned int ppe_id, u64 *rm_size);
int ps3_repository_read_region_total(u64 *region_total);
@@ -200,9 +200,15 @@ int ps3_repository_read_mm_info(u64 *rm_
int ps3_repository_read_num_be(unsigned int *num_be);
int ps3_repository_read_be_node_id(unsigned int be_index, u64 *node_id);
+int ps3_repository_read_be_id(u64 node_id, u64 *be_id);
int ps3_repository_read_tb_freq(u64 node_id, u64 *tb_freq);
int ps3_repository_read_be_tb_freq(unsigned int be_index, u64 *tb_freq);
+/* repository performance monitor info */
+
+int ps3_repository_read_lpm_privileges(unsigned int be_index, u64 *lpar,
+ u64 *rights);
+
/* repository 'Other OS' area */
int ps3_repository_read_boot_dat_addr(u64 *lpar_addr);
--- a/arch/powerpc/platforms/ps3/repository.c
+++ b/arch/powerpc/platforms/ps3/repository.c
@@ -684,6 +684,35 @@ int ps3_repository_read_stor_dev_region(
return result;
}
+/**
+ * ps3_repository_read_num_pu - Number of logical PU processors for this lpar.
+ */
+
+int ps3_repository_read_num_pu(u64 *num_pu)
+{
+ *num_pu = 0;
+ return read_node(PS3_LPAR_ID_CURRENT,
+ make_first_field("bi", 0),
+ make_field("pun", 0),
+ 0, 0,
+ num_pu, NULL);
+}
+
+/**
+ * ps3_repository_read_pu_id - Read the logical PU id.
+ * @pu_index: Zero based index.
+ * @pu_id: The logical PU id.
+ */
+
+int ps3_repository_read_pu_id(unsigned int pu_index, u64 *pu_id)
+{
+ return read_node(PS3_LPAR_ID_CURRENT,
+ make_first_field("bi", 0),
+ make_field("pu", pu_index),
+ 0, 0,
+ pu_id, NULL);
+}
+
int ps3_repository_read_rm_size(unsigned int ppe_id, u64 *rm_size)
{
return read_node(PS3_LPAR_ID_CURRENT,
@@ -856,6 +885,10 @@ int ps3_repository_read_boot_dat_info(u6
: ps3_repository_read_boot_dat_size(size);
}
+/**
+ * ps3_repository_read_num_be - Number of physical BE processors in the system.
+ */
+
int ps3_repository_read_num_be(unsigned int *num_be)
{
int result;
@@ -871,6 +904,12 @@ int ps3_repository_read_num_be(unsigned
return result;
}
+/**
+ * ps3_repository_read_be_node_id - Read the physical BE processor node id.
+ * @be_index: Zero based index.
+ * @node_id: The BE processor node id.
+ */
+
int ps3_repository_read_be_node_id(unsigned int be_index, u64 *node_id)
{
return read_node(PS3_LPAR_ID_PME,
@@ -881,6 +920,22 @@ int ps3_repository_read_be_node_id(unsig
node_id, 0);
}
+/**
+ * ps3_repository_read_be_id - Read the physical BE processor id.
+ * @node_id: The BE processor node id.
+ * @be_id: The BE processor id.
+ */
+
+int ps3_repository_read_be_id(u64 node_id, u64 *be_id)
+{
+ return read_node(PS3_LPAR_ID_PME,
+ make_first_field("be", 0),
+ node_id,
+ 0,
+ 0,
+ be_id, NULL);
+}
+
int ps3_repository_read_tb_freq(u64 node_id, u64 *tb_freq)
{
return read_node(PS3_LPAR_ID_PME,
@@ -897,11 +952,29 @@ int ps3_repository_read_be_tb_freq(unsig
u64 node_id;
*tb_freq = 0;
- result = ps3_repository_read_be_node_id(0, &node_id);
+ result = ps3_repository_read_be_node_id(be_index, &node_id);
return result ? result
: ps3_repository_read_tb_freq(node_id, tb_freq);
}
+int ps3_repository_read_lpm_privileges(unsigned int be_index, u64 *lpar,
+ u64 *rights)
+{
+ int result;
+ u64 node_id;
+
+ *lpar = 0;
+ *rights = 0;
+ result = ps3_repository_read_be_node_id(be_index, &node_id);
+ return result ? result
+ : read_node(PS3_LPAR_ID_PME,
+
Re: [PATCH 1/3] add default device trees for MPC837x MDS board
On 1/9/08, David Gibson <[EMAIL PROTECTED]> wrote: > On Tue, Jan 08, 2008 at 08:58:17AM -0700, Grant Likely wrote: > > > + compatible = "mpc83xx_wdt"; > > > > "fsl,mpc8377_wdt", "fsl,mpc83xx_wdt" as per generic names recommended > > practice. > > Uh.. that's reasonable advice, but it has nothing to do with the > generic names recommended practice. Actually, that *is* advice given in the generic names recommended practice document: http://www.openfirmware.org/1275/practice/gnames/gnamv14a.html#HDR11 Section 6.2, last sentence. :-) Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix remainder calculating bug in single floating point division
On Wed, Jan 09, 2008 at 09:24:07AM +0800, Liu Yu wrote: > > > > > can you provide the test case that shows the error. > > > > It seems that math-emu only be used for MPC8xx on current kernel. It can be used for IBM/AMCC 4xx 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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] add default device trees for MPC837x MDS board
On Tue, Jan 08, 2008 at 08:58:17AM -0700, Grant Likely wrote:
> Hi Leo,
>
> comments below. I've made my comments on the first file, but they
> apply to the other two also.
>
> Cheers,
> g.
[snip]
> > + ranges = <0 e000 0010>;
> > + reg = ;
> > + bus-frequency = <0>;
> > +
> > + [EMAIL PROTECTED] {
> > + compatible = "mpc83xx_wdt";
>
> "fsl,mpc8377_wdt", "fsl,mpc83xx_wdt" as per generic names recommended
> practice.
Uh.. that's reasonable advice, but it has nothing to do with the
generic names recommended practice.
--
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
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
On Thu, Jan 10, 2008 at 10:40:48AM +1100, Stephen Rothwell wrote:
> Hi Anton,
>
> Juts one small trivial comment (could be fixed later).
>
> On Wed, 9 Jan 2008 22:10:41 +0300 Anton Vorontsov <[EMAIL PROTECTED]> wrote:
> >
> > +static struct of_device_id pata_of_platform_match[] = {
>
> This could be declared const.
Good point, but let's not hold up merge based on this. Need something
for janitors to do too, and it's good enough to merge as-is. :)
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
Hi Anton,
Juts one small trivial comment (could be fixed later).
On Wed, 9 Jan 2008 22:10:41 +0300 Anton Vorontsov <[EMAIL PROTECTED]> wrote:
>
> +static struct of_device_id pata_of_platform_match[] = {
This could be declared const.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpiwdpCxZY1X.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [SERIAL] qe-uart: add support for Freescale QUICCEngine UART
Add file ucc_uart.c, a serial device driver for the Freescale QUICCEngine.
Update the Kconfig and Makefile accordingly.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
drivers/serial/Kconfig| 10 +
drivers/serial/Makefile |1 +
drivers/serial/ucc_uart.c | 1507 +
3 files changed, 1518 insertions(+), 0 deletions(-)
create mode 100644 drivers/serial/ucc_uart.c
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index d7e1996..d962b74 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -1284,4 +1284,14 @@ config SERIAL_OF_PLATFORM
Currently, only 8250 compatible ports are supported, but
others can easily be added.
+config SERIAL_QE
+ tristate "Freescale QUICC Engine serial port support"
+ depends on QUICC_ENGINE
+ select SERIAL_CORE
+ select FW_LOADER
+ default n
+ help
+ This driver supports the QE serial ports on Freescale embedded
+ PowerPC that contain a QUICC Engine.
+
endmenu
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index af6377d..7eb4553 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -64,3 +64,4 @@ obj-$(CONFIG_SERIAL_UARTLITE) += uartlite.o
obj-$(CONFIG_SERIAL_NETX) += netx-serial.o
obj-$(CONFIG_SERIAL_OF_PLATFORM) += of_serial.o
obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o
+obj-$(CONFIG_SERIAL_QE) += ucc_uart.o
diff --git a/drivers/serial/ucc_uart.c b/drivers/serial/ucc_uart.c
new file mode 100644
index 000..6fe4cfc
--- /dev/null
+++ b/drivers/serial/ucc_uart.c
@@ -0,0 +1,1507 @@
+/*
+ * Freescale QUICC Engine UART device driver
+ *
+ * Author: Timur Tabi <[EMAIL PROTECTED]>
+ *
+ * Copyright 2007 Freescale Semiconductor, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ *
+ * This driver adds support for UART devices via Freescale's QUICC Engine
+ * found on some Freescale SOCs.
+ *
+ * If Soft-UART support is needed but not already present, then this driver
+ * will request and upload the "Soft-UART" microcode upon probe. The
+ * filename of the microcode should be fsl_qe_ucode_uart_X_YZ.bin, where "X"
+ * is the name of the SOC (e.g. 8323), and YZ is the revision of the SOC,
+ * (e.g. "11" for 1.1).
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+#include
+
+/*
+ * The GUMR flag for Soft UART. This would normally be defined in qe.h,
+ * but Soft-UART is a hack and we want to keep everything related to it in
+ * this file.
+ */
+#define UCC_SLOW_GUMR_H_SUART 0x4000 /* Soft-UART */
+
+/*
+ * soft_uart is 1 if we need to use Soft-UART mode
+ */
+static int soft_uart;
+/*
+ * firmware_loaded is 1 if the firmware has been loaded, 0 otherwise.
+ */
+static int firmware_loaded;
+
+/* Enable this macro to configure all serial ports in internal loopback
+ mode */
+/* #define LOOPBACK */
+
+/* The major and minor device numbers are defined in
+ * http://www.lanana.org/docs/device-list/devices-2.6+.txt. For the QE
+ * UART, we have major number 204 and minor numbers 46 - 49, which are the
+ * same as for the CPM2. This decision was made because no Freescale part
+ * has both a CPM and a QE.
+ */
+#define SERIAL_QE_MAJOR 204
+#define SERIAL_QE_MINOR 46
+
+/* Since we only have minor numbers 46 - 49, there is a hard limit of 4 ports
*/
+#define UCC_MAX_UART4
+
+/* The number of buffer descriptors for receiving characters. */
+#define RX_NUM_FIFO 4
+
+/* The number of buffer descriptors for transmitting characters. */
+#define TX_NUM_FIFO 4
+
+/* The maximum size of the character buffer for a single RX BD. */
+#define RX_BUF_SIZE 32
+
+/* The maximum size of the character buffer for a single TX BD. */
+#define TX_BUF_SIZE 32
+
+#define UCC_WAIT_CLOSING 100
+
+struct ucc_uart_pram {
+ struct ucc_slow_pram common;
+ u8 res1[8]; /* reserved */
+ __be16 maxidl; /* Maximum idle chars */
+ __be16 idlc;/* temp idle counter */
+ __be16 brkcr; /* Break count register */
+ __be16 parec; /* receive parity error counter */
+ __be16 frmec; /* receive framing error counter */
+ __be16 nosec; /* receive noise counter */
+ __be16 brkec; /* receive break condition counter */
+ __be16 brkln; /* last received break length */
+ __be16 uaddr[2];/* UART address character 1 & 2 */
+ __be16 rtemp; /* Temp storage */
+ __be16 toseq; /* Transmit out of sequence char */
+ __be16 cchars[8]; /* control characters 1-8 */
+ __be16 rccm;/* receive control character mask */
+ __be16 rccr;/* receive control character register */
+
[PATCH] [POWERPC] qe: add support for Freescale QUICCEngine UART
Add support for UART serial ports using a Freescale QUICCEngine. Update
booting-without-of.txt to define new properties for a QE UART node. Update
the MPC8323E-MDS device tree to add UCC5 as a UART. Update the QE library
to support slow UCC devices and modules.
Signed-off-by: Timur Tabi <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt |9 -
arch/powerpc/boot/dts/mpc832x_mds.dts| 50 ++
arch/powerpc/sysdev/qe_lib/Kconfig |2 +-
arch/powerpc/sysdev/qe_lib/ucc_slow.c| 10 +-
4 files changed, 68 insertions(+), 3 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 53c2295..7ad221f 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1619,7 +1619,7 @@ platforms are moved over to use the flattened-device-tree
model.
Required properties:
- device_type : should be "network", "hldc", "uart", "transparent"
-"bisync" or "atm".
+ "bisync", "atm", or "serial".
- compatible : could be "ucc_geth" or "fsl_atm" and so on.
- model : should be "UCC".
- device-id : the ucc number(1-8), corresponding to UCCx in UM.
@@ -1632,6 +1632,13 @@ platforms are moved over to use the
flattened-device-tree model.
- interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device.
- pio-handle : The phandle for the Parallel I/O port configuration.
+ - port-number : for UART drivers, the port number to use, between 0 and 3.
+ This usually corresponds to the /dev/ttyQE device, e.g. <0> = /dev/ttyQE0.
+ The port number is added to the minor number of the device. Unlike the
+ CPM UART driver, the port-number is required for the QE UART driver.
+ - soft-uart : for UART drivers, if specified this means the QE UART device
+ driver should use "Soft-UART" mode, which is needed on some SOCs that have
+ broken UART hardware. Soft-UART is provided via a microcode upload.
- rx-clock-name: the UCC receive clock source
"none": clock source is disabled
"brg1" through "brg16": clock source is BRG1-BRG16, respectively
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts
b/arch/powerpc/boot/dts/mpc832x_mds.dts
index 26ac467..758cd98 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -7,6 +7,18 @@
* 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.
+
+ * To enable external serial I/O on a Freescale MPC 8323 SYS/MDS board, do
+ * this:
+ *
+ * 1) On chip U61, lift (disconnect) pins 21 (TXD) and 22 (RXD) from the board.
+ * 2) Solder a wire from U61-21 to P19A-23. P19 is a grid of pins on the board
+ *next to the serial ports.
+ * 3) Solder a wire from U61-22 to P19K-22.
+ *
+ * Note that there's a typo in the schematic. The board labels the last column
+ * of pins "P19K", but in the schematic, that column is called "P19J". So if
+ * you're going by the schematic, the pin is called "P19J-K22".
*/
/ {
@@ -169,6 +181,23 @@
1 1e 1 0 1 0/* TX_EN */
1 1f 2 0 1 0>;/* CRS */
};
+ pio5: [EMAIL PROTECTED] {
+ pio-map = <
+ /*
+*open has
+* port pin dir drain sel irq
+*/
+ 201 020 /* TxD5 */
+ 282 020 /* RxD5 */
+
+ 2 1d2 000 /* CTS5 */
+ 2 1f1 020 /* RTS5 */
+
+ 2 182 000 /* CD */
+
+ >;
+ };
+
};
};
@@ -176,6 +205,7 @@
#address-cells = <1>;
#size-cells = <1>;
device_type = "qe";
+ compatible = "fsl,qe";
model = "QE";
ranges = <0 e010 0010>;
reg = ;
@@ -250,6 +280,26 @@
pio-handle = < &pio4 >;
};
+ [EMAIL PROTECTED] {
+ device_type = "serial";
+ compatible = "ucc_uart";
+ model = "UCC";
+ device-id = <5>;/* The UCC number, 1-7*/
+ port-number = <0>; /* Which ttyQEx device */
+ soft-uart; /* We need Soft-UART */
+
[PATCH 0/2] Add support for Freescale QUICCEngine UART
This patchset creates a new serial device driver for the Freescale QE. Part 1 of this patch set contains all the PowerPC-specific changes. Part 2 contains all the actual driver and changes for Kconfig and Makefile. The PowerPC portions of this patchset have already been reviewed and approved. I'd like someone from linux-serial to review the actual driver itself. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
> It's in "production" with 256MB of RAM? Err. Sure as the dump progresses > more RAM will be freed, but that's hardly production. I think Nathan's > right, any sysadmin who wants predictability will probably double reboot > anyway. Thats a changeable parameter. Its something we chose for now. It by no means is set in stone. Its not a design parameter. If you like to allocate 1GB we can. But that is something we did for now. we expect this to be a variable value dependent upon the size of the system. So if you have 128 GB system and you can spare 10 gb, you should be able to have 10 GB to boot with. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Help with device tree binding for SMC serial
> From: Scott Wood [mailto:[EMAIL PROTECTED]
> Rune Torgersen wrote:
> >> From: Scott Wood
> >> Don't forget to exclude the SMC parameter RAM from the muram
> >> data area
> >> in /soc/cpm/muram/data/reg. If you have an older device
> tree binding
> >> that has no /soc/cpm/muram node, but instead has two resources in
> >> /soc/cpm/reg, you need to move to head-of-tree to get this to work.
> >
> > Did that, now we get e checkstop resert. Time to hook up the
> > BDI-2000
> > Is there a way to have the bootwrapper use the u-boot
> serial for a while
> > (like a early srial port) for debugging?
>
> If you mean calling into u-boot for a console, no, there's no
> code for that.
>
> What do your cpm and muram nodes look like?
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
#interrupt-cells = <2>;
compatible = "fsl,mpc8280-cpm", "fsl,cpm2";
reg = <119c0 30>;
ranges;
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0 1>;
[EMAIL PROTECTED] {
compatible = "fsl,cpm-muram-data";
reg = <100 1f00 9800 800>;
};
};
[EMAIL PROTECTED] {
compatible = "fsl,mpc8280-brg",
"fsl,cpm2-brg",
"fsl,cpm-brg";
reg = <119f0 10 115f0 10>;
};
[EMAIL PROTECTED] {
device_type = "serial";
compatible = "fsl,mpc8280-smc-uart",
"fsl,cpm2-smc-uart";
reg = <11a80 10 0 40>;//
interrupts = <4 8>; // Interrupt from
table 4.3 of mpc8280rm, interrupt is level or edge
interrupt-parent = <&PIC>;
fsl,cpm-brg = <7>;
fsl,cpm-command = <1d00>; // Page and
Sub-block code of the CPCR
};
};
and chosen node (not sure if needed)
chosen {
linux,stdout-path = "/soc/cpm/[EMAIL PROTECTED]";
bootargs = "console=ttyS0,115200";
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
On Wed, 2008-01-09 at 12:44 -0600, Nathan Lynch wrote: > Hi Linas, > > Linas Vepstas wrote: > > > > On 08/01/2008, Nathan Lynch <[EMAIL PROTECTED]> wrote: > > > Manish Ahuja wrote: > > > > + > > > > +The goal of hypervisor-assisted dump is to enable the dump of > > > > +a crashed system, and to do so from a fully-reset system, and > > > > +to minimize the total elapsed time until the system is back > > > > +in production use. > > > > > > Is it actually faster than kdump? > > > > This is a basic presumption; > > > As a side effect, the system is in > > production *while* the dump is being taken; It's in "production" with 256MB of RAM? Err. Sure as the dump progresses more RAM will be freed, but that's hardly production. I think Nathan's right, any sysadmin who wants predictability will probably double reboot anyway. > > with kdump, > > you can't go into production until after the dump is finished, > > and the system has been rebooted a second time. On > > systems with terabytes of RAM, the time difference can be > > hours. > Since you bring up large systems... a system with terabytes of RAM is > practically guaranteed to be a NUMA configuration with dozens of cpus. > When processing a dump on such a system, I wonder how well we fare: > can we successfully boot with (say) 128 cpus and 256MB of usable > memory? Do we have to hot-online nodes as system memory is freed up > (and does that even work)? We need to be able to restore the system > to its optimal topology when the dump is finished; if the best we can > do is a degraded configuration, the workload will suffer and the > system admin is likely to just reboot the machine again so the kernel > will have the right NUMA topology. Yeah that's a good question. Even if the hot-onlining works, there's still kernel data structures allocated at boot which want to be node-local. So the end result will be != a "production" boot. > > > > +Implementation details: > > > > +-- > > > > +In order for this scheme to work, memory needs to be reserved > > > > +quite early in the boot cycle. However, access to the device > > > > +tree this early in the boot cycle is difficult, and device-tree > > > > +access is needed to determine if there is a crash data waiting. > > > > > > I don't think this bit about early device tree access is correct. By > > > the time your code is reserving memory (from early_init_devtree(), I > > > think), RTAS has been instantiated and you are able to test for the > > > existence of /rtas/ibm,dump-kernel. > > > > If I remember right, it was still too early to look up this token directly, > > so we wrote some code to crawl the flat device tree to find it. But > > not only was that a lot of work, but I somehow decided that doing this > > to the flat tree was wrong, as otherwise someone would surely have > > written the access code. If this can be made to work, that would be > > great, but we couldn't make it work at the time. > > > > > > +To work around this problem, all but 256MB of RAM is reserved > > > > +during early boot. A short while later in boot, a check is made > > > > +to determine if there is dump data waiting. If there isn't, > > > > +then the reserved memory is released to general kernel use. > > > > > > So I think these gymnastics are unneeded -- unless I'm > > > misunderstanding something, you should be able to determine very early > > > whether to reserve that memory. > > > > Only if you can get at rtas, but you can't get at rtas at that point. AFAICT you don't need to get at RTAS, you just need to look at the device tree to see if the property is present, and that is trivial. You probably just need to add a check in early_init_dt_scan_rtas() which sets a flag for the PHYP dump stuff, or add your own scan routine if you need. 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: Help with device tree binding for SMC serial
Rune Torgersen wrote: >> From: Scott Wood >> Don't forget to exclude the SMC parameter RAM from the muram >> data area >> in /soc/cpm/muram/data/reg. If you have an older device tree binding >> that has no /soc/cpm/muram node, but instead has two resources in >> /soc/cpm/reg, you need to move to head-of-tree to get this to work. > > Did that, now we get e checkstop resert. Time to hook up the > BDI-2000 > Is there a way to have the bootwrapper use the u-boot serial for a while > (like a early srial port) for debugging? If you mean calling into u-boot for a console, no, there's no code for that. What do your cpm and muram nodes look like? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Help with device tree binding for SMC serial
> From: Scott Wood > Don't forget to exclude the SMC parameter RAM from the muram > data area > in /soc/cpm/muram/data/reg. If you have an older device tree binding > that has no /soc/cpm/muram node, but instead has two resources in > /soc/cpm/reg, you need to move to head-of-tree to get this to work. Did that, now we get e checkstop resert. Time to hook up the BDI-2000 Is there a way to have the bootwrapper use the u-boot serial for a while (like a early srial port) for debugging? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Help with device tree binding for SMC serial
Rune Torgersen wrote:
> Ok we're now using
> [EMAIL PROTECTED] {
> device_type = "serial";
> compatible = "fsl,mpc8280-smc-uart",
>"fsl,cpm2-smc-uart";
> reg = <11a80 10 0 40>;// parameter_ram_address length>
> interrupts = <4 8>; // Interrupt from table 4.3
> of mpc8280rm, interrupt is level or edge
> interrupt-parent = <&PIC>;
> fsl,cpm-brg = <7>;
> fsl,cpm-command = <1d00>; // Page and Sub-block code
> of the CPCR
> };
Looks good.
> Right now we're trying to just get a kernel to give us some serial
> output, so we can continue the porting job.
> We're unsig a cuImage (using the pq2fads code right now).
>
> Now our problem is that the serial port is spitting out 0x0a's as fast
> as it can.
Don't forget to exclude the SMC parameter RAM from the muram data area
in /soc/cpm/muram/data/reg. If you have an older device tree binding
that has no /soc/cpm/muram node, but instead has two resources in
/soc/cpm/reg, you need to move to head-of-tree to get this to work.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Help with device tree binding for SMC serial
> From: Scott Wood
> Sent: Wednesday, January 09, 2008 1:46 PM
> > We're trying to get a SMC serial port on a8280 to work.
> > I cannot find any ecxamples on the binding, so we've tried
> to make one.
> >
> > is this anywhere close to workable?
> >
> > [EMAIL PROTECTED] {
> > device_type = "serial";
> > compatible = "fsl,mpc8280-smc-uart",
> > "fsl,cpm2-smc-uart";
> > reg = <11a80 10 87fc 2>;
>
> The current binding has the actual parameter ram block as the
> second reg
> property, not the two-byte pointer. If your firmware doesn't
> initialize
> the pointer, you'll have to do it in platform code.
>
> > interrupts = <4 8>;
> > interrupt-parent = <&PIC>;
> > fsl,cpm-brg = <7>;
> > fsl,cpm-command = <0100>;
> > };
>
> cpm-command should be <1d00> for SMC1.
>
> Otherwise, it looks OK.
Ok we're now using
[EMAIL PROTECTED] {
device_type = "serial";
compatible = "fsl,mpc8280-smc-uart",
"fsl,cpm2-smc-uart";
reg = <11a80 10 0 40>;//
interrupts = <4 8>; // Interrupt from table 4.3
of mpc8280rm, interrupt is level or edge
interrupt-parent = <&PIC>;
fsl,cpm-brg = <7>;
fsl,cpm-command = <1d00>; // Page and Sub-block code
of the CPCR
};
Right now we're trying to just get a kernel to give us some serial
output, so we can continue the porting job.
We're unsig a cuImage (using the pq2fads code right now).
Now our problem is that the serial port is spitting out 0x0a's as fast
as it can.
Seems to be repeadtin the linefeed at the end of "Uncompressing Kernel
Image ... OK"
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Generic MMC-over-SPI binding?
On Wednesday 09 January 2008, Simon Richter wrote: > > The important part where this connects to the mmc-spi driver is that > > you need to set spi_board_info->modalias to "mmc-spi", if the > > device node can be identified as an mmc card. > > Doing that now, using the code you provided as a base. The SPI child > device gets registered, but it appears something is still missing as no > messages I could attribute to mmc-spi appear. My suspicion would be that > it doesn't like the monolithic kernel for some reason (the mmc-spi > driver registers itself as a driver called "mmc_spi", not sure if the > modalias handling will catch that; still investigating there). Right, the modalias needs to be the same as the driver name, not the module name, so you should change it to mmc_spi as well. For loading the module it would not make a difference because - and _ are treated the same by the module loader, but the device only gets associated with the driver when it matches exactly. > > Then you call that function after registering the master, from > > mpc52xx_psc_spi_of_probe. > > I've changed mpc52xx_psc_spi_do_probe to have an additional argument for > the OF device node of the SPI master; ARCH=ppc can call this with NULL > as long as it still exists. Ok. keeping the code itself in the mpc52xx_psc_spi driver is fine as long as it's relatively small. Other of_platform_drivers for SPI will just have to it the same way. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 2/4 v2] PS3: Add logical performance monitor repository routines
On Wed, 9 Jan 2008 11:01:38 +0100 (CET) Geert Uytterhoeven <[EMAIL PROTECTED]>
wrote:
>
> On Wed, 9 Jan 2008, Stephen Rothwell wrote:
> > On Tue, 08 Jan 2008 22:35:36 -0800 Geoff Levand <[EMAIL PROTECTED]> wrote:
> > >
> > > +int ps3_repository_read_num_pu(unsigned int *num_pu)
> > > +{
> > > + int result;
> > > + u64 v1;
> > > +
> > > + v1 = 0;
> > > + result = read_node(PS3_LPAR_ID_CURRENT,
> > > +make_first_field("bi", 0),
> > > +make_field("pun", 0),
> > > +0, 0,
> > > +&v1, NULL);
> > > + *num_pu = v1;
> >
> > Why not just pass "num_pu" instead of &v1 to read_node()?
>
> We need a temporary because num_pu and v1 differ in size.
> The alternative is to make num_pu u64.
Ooops, sorry. I read the second one first and didn't look hard enough
when I came back to this one.
> > > +int ps3_repository_read_pu_id(unsigned int pu_index, u64 *pu_id)
> > > +{
> > > + int result;
> > > + u64 v1;
> > > +
> > > + v1 = 0;
> > > + result = read_node(PS3_LPAR_ID_CURRENT,
> > > + make_first_field("bi", 0),
> > > + make_field("pu", pu_index),
> > > + 0, 0,
> > > + &v1, NULL);
> > > + *pu_id = v1;
> >
> > Similarly with "pu_id"?
>
> Yep, here we don't need the temporary.
Which, of course means that the "result" temporary isn't needed either.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpJg5SLN9zwh.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
Kumar Gala wrote:
> I'm thinking I'll add something like:
>
> if (addr < total_lowmem)
> reserve_bootmem(lmb.reserved.region[i].base,
> lmb_size_bytes(&lmb.reserved, i));
> + else if (lmb.reserved.region[i].base > total_lowmem) {
less than, surely?
> + unsigned long adjusted_size;
> +// adjusted_size = xxx;
>
> need to figure out the math here.
Wouldn't it just be total_lowmem - lmb.reserved.region[i].base?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 5/5] Warp Base Platform - cputable
I think I sent this, but I will include it here for completeness.
It adds the 440EP Rev C to the cputable.
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index f1928af..ece0c71 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1226,6 +1226,18 @@ static struct cpu_spec __initdata cpu_specs[] = {
.machine_check = machine_check_4xx,
.platform = "ppc440",
},
+ { /* Matches both physical and logical PVR for 440EP (logical pvr = pvr
| 0x8) */
+ .pvr_mask = 0xfff7,
+ .pvr_value = 0x48d4,
+ .cpu_name = "440EP Rev. C",
+ .cpu_features = CPU_FTRS_44X,
+ .cpu_user_features = COMMON_USER_BOOKE |
PPC_FEATURE_HAS_FPU,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .cpu_setup = __setup_cpu_440ep,
+ .machine_check = machine_check_4xx,
+ .platform = "ppc440",
+ },
{ /* Use logical PVR for 440EP (logical pvr = pvr | 0x8) */
.pvr_mask = 0xffff,
.pvr_value = 0x48db,
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/5] Warp Base Platform - defconfig
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]> --- --- /dev/null 2005-11-20 22:22:37.0 -0500 +++ arch/powerpc/configs/warp_defconfig 2008-01-08 12:30:27.0 -0500 @@ -0,0 +1,1057 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.24-rc6 +# Tue Jan 8 12:23:23 2008 +# +# CONFIG_PPC64 is not set + +# +# Processor support +# +# CONFIG_6xx is not set +# CONFIG_PPC_85xx is not set +# CONFIG_PPC_8xx is not set +# CONFIG_40x is not set +CONFIG_44x=y +# CONFIG_E200 is not set +CONFIG_PPC_FPU=y +CONFIG_4xx=y +CONFIG_BOOKE=y +CONFIG_PTE_64BIT=y +CONFIG_PHYS_64BIT=y +# CONFIG_PPC_MM_SLICES is not set +CONFIG_NOT_COHERENT_CACHE=y +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=y +# CONFIG_GENERIC_TBSYNC is not set +CONFIG_AUDIT_ARCH=y +CONFIG_GENERIC_BUG=y +# CONFIG_DEFAULT_UIMAGE is not set +CONFIG_PPC_DCR_NATIVE=y +# CONFIG_PPC_DCR_MMIO is not set +CONFIG_PPC_DCR=y +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# General setup +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION="-pika" +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +# CONFIG_POSIX_MQUEUE is not set +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_USER_NS is not set +# CONFIG_PID_NS is not set +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +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=y +CONFIG_INITRAMFS_SOURCE="" +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# CONFIG_KALLSYMS_EXTRA_PASS is not set +# CONFIG_HOTPLUG is not set +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_RT_MUTEXES=y +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set +# CONFIG_BLK_DEV_BSG is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="anticipatory" + +# +# Platform support +# +# 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_PQ2ADS is not set +# CONFIG_BAMBOO is not set +# CONFIG_EBONY is not set +# CONFIG_SEQUOIA is not set +# CONFIG_TAISHAN is not set +# CONFIG_KATMAI is not set +# CONFIG_RAINIER is not set +CONFIG_WARP=y +CONFIG_440EP=y +CONFIG_IBM440EP_ERR42=y +# 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 is not set +# CONFIG_FSL_ULI1575 is not set + +# +# 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 is not set +# CONFIG_HZ_300 is not set +CONFIG_HZ_1000=y +CONFIG_HZ=1000 +CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_VOLUNTARY is not set +# CONFIG_PREEMPT is not set +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_MISC is not set +# CONFIG_MATH_EMULATION is not set +CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y +CONFIG_ARCH_FLATMEM_ENABLE=y +CONFIG_ARCH_POPULATES_NODE_MAP=y +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_FLATMEM_MANUAL=y +# CONFIG_DISCONTIGMEM_MANUAL is not set +# CONFIG_SPARSEMEM_MANUAL is not set +CONFIG_FLATMEM=y +CONFIG_FLAT_NODE_MEM_MAP=y +# CONFIG_SPARSEMEM_ST
[PATCH 3/5] Warp Base Platform
Basically the powerpc/boot directory files.
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/boot/44x.h b/arch/powerpc/boot/44x.h
index 0256344..9db0213 100644
--- a/arch/powerpc/boot/44x.h
+++ b/arch/powerpc/boot/44x.h
@@ -12,5 +12,6 @@
void ebony_init(void *mac0, void *mac1);
void bamboo_init(void *mac0, void *mac1);
+void warp_init(void *mac0, void *mac1);
#endif /* _PPC_BOOT_44X_H_ */
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index d1e625c..df0ef6f 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -56,13 +56,13 @@ src-wlib := string.S crt0.S stdio.c main.c \
gunzip_util.c elf_util.c $(zlib) devtree.c oflib.c ofconsole.c \
4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \
cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c uartlite.c \
- fsl-soc.c mpc8xx.c pq2.c
+ fsl-soc.c mpc8xx.c pq2.c warp.c
src-plat := of.c cuboot-52xx.c cuboot-83xx.c cuboot-85xx.c holly.c \
cuboot-ebony.c treeboot-ebony.c prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c cuboot-bamboo.c
\
fixed-head.S ep88xc.c cuboot-hpc2.c ep405.c cuboot-taishan.c \
- cuboot-katmai.c cuboot-rainier.c
+ cuboot-katmai.c cuboot-rainier.c cuboot-warp.c
src-boot := $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
@@ -206,6 +206,7 @@ image-$(CONFIG_RAINIER) +=
cuImage.rainier
image-$(CONFIG_WALNUT) += treeImage.walnut
image-$(CONFIG_TAISHAN)+= cuImage.taishan
image-$(CONFIG_KATMAI) += cuImage.katmai
+image-$(CONFIG_WARP) += cuImage.warp
endif
# For 32-bit powermacs, build the COFF and miboot images
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/boot/cuboot-warp.c 2008-01-08 12:09:39.0 -0500
@@ -0,0 +1,25 @@
+/*
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "44x.h"
+#include "cuboot.h"
+
+#define TARGET_44x
+#include "ppcboot.h"
+
+static bd_t bd;
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ CUBOOT_INIT();
+
+ warp_init(&bd.bi_enetaddr, &bd.bi_enet1addr);
+}
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/boot/warp.c2008-01-08 12:09:54.0 -0500
@@ -0,0 +1,33 @@
+/*
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <[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; version 2 of the License
+ */
+#include "ops.h"
+#include "4xx.h"
+#include "44x.h"
+
+static u8 *warp_mac0, *warp_mac1;
+
+static void warp_fixups(void)
+{
+ unsigned long sysclk = 6600;
+
+ ibm440ep_fixup_clocks(sysclk, 11059200, 5000);
+ ibm4xx_sdram_fixup_memsize();
+ ibm4xx_quiesce_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
+ dt_fixup_mac_addresses(warp_mac0, warp_mac1);
+}
+
+void warp_init(void *mac0, void *mac1)
+{
+ platform_ops.fixups = warp_fixups;
+ platform_ops.exit = ibm44x_dbcr_reset;
+ warp_mac0 = mac0;
+ warp_mac1 = mac1;
+ fdt_init(_dtb_start);
+ serial_console_init();
+}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/5] Warp Base Platform - dts
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
---
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/boot/dts/warp.dts 2008-01-08 12:04:10.0 -0500
@@ -0,0 +1,232 @@
+/*
+ * Device Tree Source for PIKA Warp
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <[EMAIL PROTECTED]>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "pika,warp";
+ compatible = "pika,warp";
+ dcr-parent = <&/cpus/[EMAIL PROTECTED]>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ serial0 = &UART0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ [EMAIL PROTECTED] {
+ device_type = "cpu";
+ model = "PowerPC,440EP";
+ reg = <0>;
+ clock-frequency = <0>; /* Filled in by zImage */
+ timebase-frequency = <0>; /* Filled in by zImage */
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
+ i-cache-size = <8000>;
+ d-cache-size = <8000>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 0>; /* Filled in by zImage */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-440ep","ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0c0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-440ep","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0d0 009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <1e 4 1f 4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-440ep";
+ dcr-reg = <00e 002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-440ep";
+ dcr-reg = <00c 002>;
+ };
+
+ plb {
+ compatible = "ibm,plb-440ep", "ibm,plb-440gp", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by zImage */
+
+ SDRAM0: sdram {
+ compatible = "ibm,sdram-440ep", "ibm,sdram-405gp";
+ dcr-reg = <010 2>;
+ };
+
+ DMA0: dma {
+ compatible = "ibm,dma-440ep", "ibm,dma-440gp";
+ dcr-reg = <100 027>;
+ };
+
+ FPGA0: fpga {
+ compatible = "pika,fpga";
+ reg = <0 8000 2200>;
+ interrupts = <18 8>;
+ interrupt-parent = <&UIC0>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-440ep", "ibm,mcmal-440gp",
"ibm,mcmal";
+ dcr-reg = <180 62>;
+ num-tx-chans = <4>;
+ num-rx-chans = <2>;
+ interrupt-parent = <&MAL0>;
+ interrupts = <0 1 2 3 4>;
+ #interrupt-cells = <1>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ interrupt-map = ;
+ };
+
+ POB0: opb {
+ compatible = "ibm,opb-440ep", "ibm,opb-440gp",
"ibm,opb";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = < 0 8000
+ 8000 0 8000 8000>;
+ interrupt-parent = <&UIC1>;
+ interrupts = <7 4>;
+ clock-frequency = <0>; /* Filled in by zImage */
+
+ EBC0: ebc {
+ compatible = "ibm,ebc-440ep", "ibm,ebc-440gp",
"ibm,ebc";
+ dcr-reg = <012 2>;
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-frequency = <0>; /* Filled in by zImage */
+ interrupts = <5 1>;
+ interrupt-parent
[PATCH 1/5] Warp Base Platform
I have split up the patches slightly differently based on Josh's comments.
The first patch is basically the platform/44x files.
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
---
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 66a3d8c..b3e4c35 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -469,7 +469,7 @@ config MCA
config PCI
bool "PCI support" if 40x || CPM2 || PPC_83xx || PPC_85xx || PPC_86xx \
|| PPC_MPC52xx || (EMBEDDED && (PPC_PSERIES || PPC_ISERIES)) \
- || PPC_PS3
+ || PPC_PS3 || 44x
default y if !40x && !CPM2 && !8xx && !PPC_83xx \
&& !PPC_85xx && !PPC_86xx
default PCI_PERMEDIA if !4xx && !CPM2 && !8xx
diff --git a/arch/powerpc/platforms/44x/Kconfig
b/arch/powerpc/platforms/44x/Kconfig
index d248013..a95409e 100644
--- a/arch/powerpc/platforms/44x/Kconfig
+++ b/arch/powerpc/platforms/44x/Kconfig
@@ -53,6 +53,19 @@ config RAINIER
help
This option enables support for the AMCC PPC440GRX evaluation board.
+config WARP
+ bool "PIKA Warp"
+ depends on 44x
+ default n
+ select 440EP
+ help
+ This option enables support for the PIKA Warp(tm) Appliance. The Warp
+ is a small computer replacement with up to 9 ports of FXO/FXS plus
VOIP
+ stations and trunks.
+
+ See http://www.pikatechnologies.com/ and follow the "PIKA for Computer
+ Telephony Developers" link for more information.
+
#config LUAN
# bool "Luan"
# depends on 44x
@@ -75,6 +88,7 @@ config 440EP
select PPC_FPU
select IBM440EP_ERR42
select IBM_NEW_EMAC_ZMII
+ select USB_ARCH_HAS_OHCI
config 440EPX
bool
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
index a2a0dc1..c1733c0 100644
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_BAMBOO)+= bamboo.o
obj-$(CONFIG_SEQUOIA) += sequoia.o
obj-$(CONFIG_KATMAI) += katmai.o
obj-$(CONFIG_RAINIER) += rainier.o
+obj-$(CONFIG_WARP) += warp.o
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/platforms/44x/warp.c 2008-01-08 17:59:48.0 -0500
@@ -0,0 +1,239 @@
+/*
+ * PIKA Warp(tm) board specific routines
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <[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 "44x.h"
+
+#define WARP_GPIO_BASE 0xEF600B00ULL
+
+static __initdata struct of_device_id warp_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ {},
+};
+
+static int __init warp_device_probe(void)
+{
+ of_platform_bus_probe(NULL, warp_of_bus, NULL);
+
+ return 0;
+}
+machine_device_initcall(warp, warp_device_probe);
+
+static int __init warp_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if(!of_flat_dt_is_compatible(root, "pika,warp"))
+ return 0;
+
+ return 1;
+}
+
+define_machine(warp) {
+ .name = "Warp",
+ .probe = warp_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq= uic_get_irq,
+ .restart= ppc44x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
+
+/* This is for the power LEDs 1 = on, 0 = off, -1 = leave alone */
+void warp_set_power_leds(int green, int red)
+{
+ static void *gpio_base = NULL;
+ unsigned leds;
+
+ if(gpio_base == NULL) {
+ if((gpio_base = ioremap(WARP_GPIO_BASE, 0x148)) == NULL) {
+ printk("ERROR: Unable to remap GPIO base.\n");
+ return;
+ }
+ }
+
+ leds = readl(gpio_base + 0x100);
+
+ switch(green) {
+ case 0: leds &= ~0x80; break;
+ case 1: leds |= 0x80; break;
+ }
+ switch(red) {
+ case 0: leds &= ~0x40; break;
+ case 1: leds |= 0x40; break;
+ }
+
+ writel(leds, gpio_base + 0x100);
+}
+EXPORT_SYMBOL(warp_set_power_leds);
+
+
+static int pika_dtm_thread(void *fpga)
+{
+ extern int ad7414_get_temp(int index);
+
+ while(!kthread_should_stop()) {
+ int temp = ad7414_get_temp(0);
+
+ out_be32(fpga, temp);
+
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
+ }
+
+ return 0;
+}
+
+
+static int __devinit warp_fpg
Re: [PATCH] Miscellaneous for Taco
Josh Boyer wrote: > > Ah, possibly. Did you try doing a 'select USB_ARCH_HAS_OHCI' in the > config 440EP section of arch/powerpc/platforms/44x/Kconfig? > > I'm just trying to save you some trouble. There's nothing actually > wrong with your patch now, other than it has to be sent to the right > maintainer. > > josh > That works. Thanks! Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Miscellaneous for Taco
On Wed, 09 Jan 2008 14:26:56 -0500 Sean MacLennan <[EMAIL PROTECTED]> wrote: > Josh Boyer wrote: > > On Wed, 09 Jan 2008 12:26:14 -0500 > > Sean MacLennan <[EMAIL PROTECTED]> wrote: > > > > > >> Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]> > >> > > > > This one needs to go to the linux-usb list and David Brownell. > > > > Although I'm not sure what the benefit here really is. You can still > > set this in the defconfig without adding this patch... I don't see a > > need to do a default. > > > Without the default, I was unable to select this option. I may have > solved it the wrong way. It seems if there is no string after the > tristate or boolean, you are not allowed to set the variable, it can > only default. So with no default, I cannot enable this option and > therefore cannot enable the ohci driver. > > Again, I think the "default PCI" case catches most boards and all > PCI-less, or possibly PCI-less, boards need a default. Ah, possibly. Did you try doing a 'select USB_ARCH_HAS_OHCI' in the config 440EP section of arch/powerpc/platforms/44x/Kconfig? I'm just trying to save you some trouble. There's nothing actually wrong with your patch now, other than it has to be sent to the right maintainer. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH for 2.6.24][NET] fs_enet: check for phydev existence in the ethtool handlers
On Wed, Jan 09, 2008 at 01:58:49PM +0100, Heiko Schocher wrote:
> @@ -1312,6 +1312,9 @@ static int __devinit fs_enet_probe(struct of_device
> *ofdev,
> ndev->dev_addr[0], ndev->dev_addr[1], ndev->dev_addr[2],
> ndev->dev_addr[3], ndev->dev_addr[4], ndev->dev_addr[5]);
>
> + /* to initialize the fep->cur_rx,... */
> + /* not doing this, will cause a crash in fs_enet_rx_napi */
> + fs_init_bds(ndev);
> return 0;
We don't want to allocate ring buffers for network interfaces that are never
opened, especially given the small amount of memory on some boards that use
this driver.
Instead, we should probably not be calling napi_enable() until the link is
up and init_bds() has been called.
> @@ -1342,9 +1345,13 @@ static int fs_enet_remove(struct of_device *ofdev)
> }
>
> static struct of_device_id fs_enet_match[] = {
> -#ifdef CONFIG_FS_ENET_HAS_SCC
> +#if defined(CONFIG_FS_ENET_HAS_SCC)
> {
> +#if defined(CONFIG_CPM1)
> .compatible = "fsl,cpm1-scc-enet",
> +#else
> + .compatible = "fsl,cpm2-scc-enet",
> +#endif
I know there are already ifdefs of this sort, and that multiplatform
cpm1/cpm2 is very unlikely to ever happen, but can we try to avoid
introducing more such ifdefs?
We can have both match entries present at the same time.
> .data = (void *)&fs_scc_ops,
> },
> #endif
> diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
> index 48f2f30..3b5ca76 100644
> --- a/drivers/net/fs_enet/mac-scc.c
> +++ b/drivers/net/fs_enet/mac-scc.c
> @@ -50,6 +50,7 @@
> #include "fs_enet.h"
>
> /*/
> +#define SCC_EB ((u_char)0x10) /* Set big endian byte order */
This is already defined in asm-powerpc/commproc.h, and thus will cause a
duplicate definition when building for 8xx. Please add this definition to
asm-powerpc/cpm2.h.
> +#if defined(CONFIG_CPM1)
> W16(cpmp, cp_cpcr, fpi->cp_command | CPM_CR_FLG | (op << 8));
> for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
> if ((R16(cpmp, cp_cpcr) & CPM_CR_FLG) == 0)
> return 0;
> +#else
> + W32(cpmp, cp_cpcr, fpi->cp_command | CPM_CR_FLG | op);
> + for (i = 0; i < MAX_CR_CMD_LOOPS; i++)
> + if ((R32(cpmp, cp_cpcr) & CPM_CR_FLG) == 0)
> + return 0;
> +
> +#endif
Commit 362f9b6fa8c9670cc5496390845021c2865d049b in Paul's tree makes this
unnecessary.
> @@ -306,8 +317,15 @@ static void restart(struct net_device *dev)
>
> /* Initialize function code registers for big-endian.
>*/
> +#ifdef CONFIG_CPM2
> + /* from oldstyle driver in arch/ppc */
> + /* seems necessary */
> + W8(ep, sen_genscc.scc_rfcr, SCC_EB | 0x20);
> + W8(ep, sen_genscc.scc_tfcr, SCC_EB | 0x20);
> +#else
> W8(ep, sen_genscc.scc_rfcr, SCC_EB);
> W8(ep, sen_genscc.scc_tfcr, SCC_EB);
> +#endif
Please define 0x20 as SCC_GBL (Snooping Enabled) in cpm2.h, and
conditionalize this on #ifndef CONFIG_NOT_COHERENT_CACHE.
You can remove the comment; it's really necessary, not just "seems" so. :-)
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Help with device tree binding for SMC serial
Rune Torgersen wrote:
> Hi
>
> We're trying to get a SMC serial port on a8280 to work.
> I cannot find any ecxamples on the binding, so we've tried to make one.
>
> is this anywhere close to workable?
>
> [EMAIL PROTECTED] {
> device_type = "serial";
> compatible = "fsl,mpc8280-smc-uart",
>"fsl,cpm2-smc-uart";
> reg = <11a80 10 87fc 2>;
The current binding has the actual parameter ram block as the second reg
property, not the two-byte pointer. If your firmware doesn't initialize
the pointer, you'll have to do it in platform code.
> interrupts = <4 8>;
> interrupt-parent = <&PIC>;
> fsl,cpm-brg = <7>;
> fsl,cpm-command = <0100>;
> };
cpm-command should be <1d00> for SMC1.
Otherwise, it looks OK.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
On Jan 9, 2008, at 1:30 PM, Scott Wood wrote:
> Kumar Gala wrote:
>> On Jan 9, 2008, at 12:53 PM, Scott Wood wrote:
>>> It looks like if the reserved area straddles the highmem boundary,
>>> it'll
>>> only reserve the highmem portion.
>> Yeah, I thought about that. I'm wondering if we should warn about
>> this.. its seems like a bad thing to do.
>
> How is the firmware supposed to know where Linux sets its lowmem
> limit? I think this is something that needs to be handled.
Yeah I agree with that as well.
I'm thinking I'll add something like:
if (addr < total_lowmem)
reserve_bootmem(lmb.reserved.region[i].base,
lmb_size_bytes(&lmb.reserved,
i));
+ else if (lmb.reserved.region[i].base > total_lowmem) {
+ unsigned long adjusted_size;
+// adjusted_size = xxx;
need to figure out the math here.
+ reserve_bootmem(lmb.reserved.region[i].base,
+ adjusted_size);
+ }
that should solve the problem.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Trying 10/HALF
Hi, After booting, my MPC8641 based board keeps printing "Trying 10/HALF" for ever. I am unable to use the Ethernet, even though there are interrupts occuring. Based on /proc/interrupts, both tx and rx interrupt count is increasing, and zero count for enet_error interrupt. I think this is coming from drivers/net/phy/phy.c during autonegotiation. However, I am not sure how to take care of this. Appreciate some pointers. Thanks Siva ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Help with device tree binding for SMC serial
Hi
We're trying to get a SMC serial port on a8280 to work.
I cannot find any ecxamples on the binding, so we've tried to make one.
is this anywhere close to workable?
[EMAIL PROTECTED] {
device_type = "serial";
compatible = "fsl,mpc8280-smc-uart",
"fsl,cpm2-smc-uart";
reg = <11a80 10 87fc 2>;
interrupts = <4 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <7>;
fsl,cpm-command = <0100>;
};
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
Kumar Gala wrote: > On Jan 9, 2008, at 12:53 PM, Scott Wood wrote: >> It looks like if the reserved area straddles the highmem boundary, it'll >> only reserve the highmem portion. > > Yeah, I thought about that. I'm wondering if we should warn about > this.. its seems like a bad thing to do. How is the firmware supposed to know where Linux sets its lowmem limit? I think this is something that needs to be handled. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
> > I used the word "actually". I already know that it is intended to be > faster. :) > >> it should blow it away, as, after all, >> it requires one less reboot! > > There's more than rebooting going on during system dump processing. > Depending on the system type, booting may not be where most time is > spent. > > >> As a side effect, the system is in >> production *while* the dump is being taken; > > A dubious feature IMO. Seems that the design potentially trades > reliability of first failure data capture for availability. > E.g. system crashes, reboots, resumes processing while copying dump, > crashes again before dump procedure is complete. How is that handled, > if at all? This is a simple version. The intent was not to have a complex dump taking mechanism in version 1. Subsequent versions will see planned improvement on the way the pages are tracked and freed. Also it is very easily possible now, to register for another dump as soon as the scratch area is copied to a user designated region. But for now this simple implementation exists. It is also possible to extend this further to only preserve pages that are kernel pages and free the non required pages like user/data pages etc. This would reduce the space preserved and would prevent any issues that are caused by reserving everything in memory except for the first 256 MB. Improvements and future versions are planned to make this efficient. But for now the intent is to get this off the ground and handle simple cases. > > >> with kdump, >> you can't go into production until after the dump is finished, >> and the system has been rebooted a second time. On >> systems with terabytes of RAM, the time difference can be >> hours. > > The difference in time it takes to resume the normal workload may be > significant, yes. But the time it takes to get a usable dump image > would seem to be the basically the same. > > Since you bring up large systems... a system with terabytes of RAM is > practically guaranteed to be a NUMA configuration with dozens of cpus. > When processing a dump on such a system, I wonder how well we fare: > can we successfully boot with (say) 128 cpus and 256MB of usable > memory? Do we have to hot-online nodes as system memory is freed up > (and does that even work)? We need to be able to restore the system > to its optimal topology when the dump is finished; if the best we can > do is a degraded configuration, the workload will suffer and the > system admin is likely to just reboot the machine again so the kernel > will have the right NUMA topology. > > +Implementation details: +-- +In order for this scheme to work, memory needs to be reserved +quite early in the boot cycle. However, access to the device +tree this early in the boot cycle is difficult, and device-tree +access is needed to determine if there is a crash data waiting. >>> I don't think this bit about early device tree access is correct. By >>> the time your code is reserving memory (from early_init_devtree(), I >>> think), RTAS has been instantiated and you are able to test for the >>> existence of /rtas/ibm,dump-kernel. >> If I remember right, it was still too early to look up this token directly, >> so we wrote some code to crawl the flat device tree to find it. But >> not only was that a lot of work, but I somehow decided that doing this >> to the flat tree was wrong, as otherwise someone would surely have >> written the access code. If this can be made to work, that would be >> great, but we couldn't make it work at the time. >> +To work around this problem, all but 256MB of RAM is reserved +during early boot. A short while later in boot, a check is made +to determine if there is dump data waiting. If there isn't, +then the reserved memory is released to general kernel use. >>> So I think these gymnastics are unneeded -- unless I'm >>> misunderstanding something, you should be able to determine very early >>> whether to reserve that memory. >> Only if you can get at rtas, but you can't get at rtas at that point. > > Sorry, but I think you are mistaken (see Michael's earlier reply). > > ___ > 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
Re: [PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
On Jan 9, 2008, at 12:53 PM, Scott Wood wrote:
> On Wed, Jan 09, 2008 at 11:28:30AM -0600, Kumar Gala wrote:
>> /* reserve the sections we're already using */
>> -for (i = 0; i < lmb.reserved.cnt; i++)
>> -reserve_bootmem(lmb.reserved.region[i].base,
>> -lmb_size_bytes(&lmb.reserved, i));
>> +for (i = 0; i < lmb.reserved.cnt; i++) {
>> +unsigned long addr = lmb.reserved.region[i].base +
>> + lmb_size_bytes(&lmb.reserved, i) - 1;
>> +if (addr < total_lowmem)
>> +reserve_bootmem(lmb.reserved.region[i].base,
>> +lmb_size_bytes(&lmb.reserved, i));
>> +}
>
> It looks like if the reserved area straddles the highmem boundary,
> it'll
> only reserve the highmem portion.
Yeah, I thought about that. I'm wondering if we should warn about
this.. its seems like a bad thing to do.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Miscellaneous for Taco
Josh Boyer wrote: > On Wed, 09 Jan 2008 12:26:14 -0500 > Sean MacLennan <[EMAIL PROTECTED]> wrote: > > >> Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]> >> > > This one needs to go to the linux-usb list and David Brownell. > > Although I'm not sure what the benefit here really is. You can still > set this in the defconfig without adding this patch... I don't see a > need to do a default. > Without the default, I was unable to select this option. I may have solved it the wrong way. It seems if there is no string after the tristate or boolean, you are not allowed to set the variable, it can only default. So with no default, I cannot enable this option and therefore cannot enable the ohci driver. Again, I think the "default PCI" case catches most boards and all PCI-less, or possibly PCI-less, boards need a default. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Miscellaneous for Taco
On Wed, 09 Jan 2008 12:26:14 -0500 Sean MacLennan <[EMAIL PROTECTED]> wrote: > Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]> This one needs to go to the linux-usb list and David Brownell. Although I'm not sure what the benefit here really is. You can still set this in the defconfig without adding this patch... I don't see a need to do a default. josh > --- > diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig > index 7580aa5..2660f30 100644 > --- a/drivers/usb/Kconfig > +++ b/drivers/usb/Kconfig > @@ -39,6 +39,7 @@ config USB_ARCH_HAS_OHCI > # PPC: > default y if STB03xxx > default y if PPC_MPC52xx > + default y if 440EP > # MIPS: > default y if SOC_AU1X00 > # more: > > > ___ > 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
Re: Base Warp Platform support
On Wed, 09 Jan 2008 12:30:39 -0500 Sean MacLennan <[EMAIL PROTECTED]> wrote: > So no comments? I got it perfect the first time :D Not quite.. :) The way you have the patches laid out right now will break compiling and git bisecting. Could you take these and roll them up into distinct patches that can all apply without breaking a compile individually? I recommend doing it this way: Patch 1) platform files in arch/powerpc/platforms/44x/ Patch 2) DTS Patch 3) boot files in arch/powerpc/boot Patch 4) defconfig or something along those lines. That way we can apply them in that order, nothing breaks for the compile, and they aren't scattered about. If you start a new email thread with those I think most of it looked fairly good otherwise. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] MTD for Taco
On Wed, 09 Jan 2008 13:50:41 -0500 Sean MacLennan <[EMAIL PROTECTED]> wrote: > No. You have to setup everything the old way. This *just* gets it > working so if you have the PPC layout, it will work. > > Unless testing goes *really* well, I doubt I will have time in the short > term to port it to the of_platform. I'm afraid I will have to live with > "it works, don't touch it" for now :( That's fine for you, nobody expects you to have to do all the porting for everything :). I don't want it actually ported to of_platform anyway. What I really want, and what Stefan has started some time ago, is to make it get the values from the device tree but still create the regular platform devices. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] [POWERPC] MPC8349E-mITX: introduce localbus and pata nodes
This patch adds localbus and pata nodes to use CF IDE interface
on MPC8349E-mITX boards.
Patch also updates defconfig and adds some code to probe localbus.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
Acked-by: Olof Johansson <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8349emitx.dts | 17 -
arch/powerpc/configs/mpc834x_itx_defconfig |3 ++-
arch/powerpc/platforms/83xx/mpc834x_itx.c | 12
3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index e354f26..06d5b9c 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -253,6 +253,21 @@
device_type = "pci";
};
+ [EMAIL PROTECTED] {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8349e-localbus",
+"fsl,pq2pro-localbus";
+ reg = ;
+ ranges = <3 0 f000 210>;
-
+ [EMAIL PROTECTED],0 {
+ compatible = "fsl,mpc8349emitx-pata", "ata-generic";
+ reg = <3 0 10 3 20c 4>;
+ reg-shift = <1>;
+ pio-mode = <6>;
+ interrupts = <17 8>;
+ interrupt-parent = <&ipic>;
+ };
+ };
};
diff --git a/arch/powerpc/configs/mpc834x_itx_defconfig
b/arch/powerpc/configs/mpc834x_itx_defconfig
index 6feb86e..2fbe4e5 100644
--- a/arch/powerpc/configs/mpc834x_itx_defconfig
+++ b/arch/powerpc/configs/mpc834x_itx_defconfig
@@ -570,7 +570,8 @@ CONFIG_SATA_SIL=y
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
-# CONFIG_PATA_PLATFORM is not set
+CONFIG_PATA_PLATFORM=y
+CONFIG_PATA_OF_PLATFORM=y
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_LINEAR=y
diff --git a/arch/powerpc/platforms/83xx/mpc834x_itx.c
b/arch/powerpc/platforms/83xx/mpc834x_itx.c
index aa76819..50e8f63 100644
--- a/arch/powerpc/platforms/83xx/mpc834x_itx.c
+++ b/arch/powerpc/platforms/83xx/mpc834x_itx.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -37,6 +38,17 @@
#include "mpc83xx.h"
+static struct of_device_id __initdata mpc834x_itx_ids[] = {
+ { .compatible = "fsl,pq2pro-localbus", },
+ {},
+};
+
+static int __init mpc834x_itx_declare_of_platform_devices(void)
+{
+ return of_platform_bus_probe(NULL, mpc834x_itx_ids, NULL);
+}
+machine_device_initcall(mpc834x_itx, mpc834x_itx_declare_of_platform_devices);
+
/*
*
* Setup the architecture
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
This driver nicely wraps around pata_platform library functions,
and provides OF platform bus bindings to the PATA devices.
Also add || PPC to the PATA_PLATFORM's "depends on" Kconfig entry,
needed for PA Semi Electra.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
Reviewed-by: Olof Johansson <[EMAIL PROTECTED]>
---
drivers/ata/Kconfig| 12 -
drivers/ata/Makefile |1 +
drivers/ata/pata_of_platform.c | 104
3 files changed, 116 insertions(+), 1 deletions(-)
create mode 100644 drivers/ata/pata_of_platform.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index ba63619..64b4964 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -607,13 +607,23 @@ config PATA_WINBOND_VLB
config PATA_PLATFORM
tristate "Generic platform device PATA support"
- depends on EMBEDDED || ARCH_RPC
+ depends on EMBEDDED || ARCH_RPC || PPC
help
This option enables support for generic directly connected ATA
devices commonly found on embedded systems.
If unsure, say N.
+config PATA_OF_PLATFORM
+ tristate "OpenFirmware platform device PATA support"
+ depends on PATA_PLATFORM && PPC_OF
+ help
+ This option enables support for generic directly connected ATA
+ devices commonly found on embedded systems with OpenFirmware
+ bindings.
+
+ If unsure, say N.
+
config PATA_ICSIDE
tristate "Acorn ICS PATA support"
depends on ARM && ARCH_ACORN
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index b13feb2..ebcee64 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_PATA_IXP4XX_CF) += pata_ixp4xx_cf.o
obj-$(CONFIG_PATA_SCC) += pata_scc.o
obj-$(CONFIG_PATA_BF54X) += pata_bf54x.o
obj-$(CONFIG_PATA_PLATFORM)+= pata_platform.o
+obj-$(CONFIG_PATA_OF_PLATFORM) += pata_of_platform.o
obj-$(CONFIG_PATA_ICSIDE) += pata_icside.o
# Should be last but two libata driver
obj-$(CONFIG_PATA_ACPI)+= pata_acpi.o
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
new file mode 100644
index 000..b7bc4e4
--- /dev/null
+++ b/drivers/ata/pata_of_platform.c
@@ -0,0 +1,104 @@
+/*
+ * OF-platform PATA driver
+ *
+ * Copyright (c) 2007 MontaVista Software, Inc.
+ * Anton Vorontsov <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License (Version 2) as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+
+static int __devinit pata_of_platform_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ int ret;
+ struct device_node *dn = ofdev->node;
+ struct resource io_res;
+ struct resource ctl_res;
+ struct resource irq_res;
+ unsigned int reg_shift = 0;
+ int pio_mode = 0;
+ int pio_mask;
+ const u32 *prop;
+
+ ret = of_address_to_resource(dn, 0, &io_res);
+ if (ret) {
+ dev_err(&ofdev->dev, "can't get IO address from "
+ "device tree\n");
+ return -EINVAL;
+ }
+
+ ret = of_address_to_resource(dn, 1, &ctl_res);
+ if (ret) {
+ dev_err(&ofdev->dev, "can't get CTL address from "
+ "device tree\n");
+ return -EINVAL;
+ }
+
+ ret = of_irq_to_resource(dn, 0, &irq_res);
+ if (ret == NO_IRQ)
+ irq_res.start = irq_res.end = -1;
+ else
+ irq_res.flags = 0;
+
+ prop = of_get_property(dn, "reg-shift", NULL);
+ if (prop)
+ reg_shift = *prop;
+
+ prop = of_get_property(dn, "pio-mode", NULL);
+ if (prop) {
+ pio_mode = *prop;
+ if (pio_mode > 6) {
+ dev_err(&ofdev->dev, "invalid pio-mode\n");
+ return -EINVAL;
+ }
+ } else {
+ dev_info(&ofdev->dev, "pio-mode unspecified, assuming PIO0\n");
+ }
+
+ pio_mask = 1 << pio_mode;
+ pio_mask |= (1 << pio_mode) - 1;
+
+ return __pata_platform_probe(&ofdev->dev, &io_res, &ctl_res, &irq_res,
+reg_shift, pio_mask);
+}
+
+static int __devexit pata_of_platform_remove(struct of_device *ofdev)
+{
+ return __pata_platform_remove(&ofdev->dev);
+}
+
+static struct of_device_id pata_of_platform_match[] = {
+ { .compatible = "ata-generic", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, pata_of_platform_match);
+
+static struct of_platform_driver pata_of_platform_driver = {
+ .name = "pata_of_platform",
+ .match_table= pata_of_platform_match,
+ .probe = pata_of_platform_probe,
+ .remove = __devexit_p(pat
[PATCH 1/3] [libata] pata_platform: make probe and remove functions device type neutral
Split pata_platform_{probe,remove} into two pieces:
1. pata_platform_{probe,remove} -- platform_device-dependant bits;
2. __ptata_platform_{probe,remove} -- device type neutral bits.
This is done to not duplicate code for the OF-platform driver.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
Acked-by: Olof Johansson <[EMAIL PROTECTED]>
Acked-by: Paul Mundt <[EMAIL PROTECTED]>
---
drivers/ata/pata_platform.c | 144
include/linux/pata_platform.h |9 +++
2 files changed, 95 insertions(+), 58 deletions(-)
diff --git a/drivers/ata/pata_platform.c b/drivers/ata/pata_platform.c
index ac03a90..224bb6c 100644
--- a/drivers/ata/pata_platform.c
+++ b/drivers/ata/pata_platform.c
@@ -93,14 +93,9 @@ static struct ata_port_operations pata_platform_port_ops = {
};
static void pata_platform_setup_port(struct ata_ioports *ioaddr,
-struct pata_platform_info *info)
+unsigned int shift)
{
- unsigned int shift = 0;
-
/* Fixup the port shift for platforms that need it */
- if (info && info->ioport_shift)
- shift = info->ioport_shift;
-
ioaddr->data_addr = ioaddr->cmd_addr + (ATA_REG_DATA<< shift);
ioaddr->error_addr = ioaddr->cmd_addr + (ATA_REG_ERR << shift);
ioaddr->feature_addr= ioaddr->cmd_addr + (ATA_REG_FEATURE << shift);
@@ -114,8 +109,13 @@ static void pata_platform_setup_port(struct ata_ioports
*ioaddr,
}
/**
- * pata_platform_probe - attach a platform interface
- * @pdev: platform device
+ * __pata_platform_probe - attach a platform interface
+ * @dev: device
+ * @io_res: Resource representing I/O base
+ * @ctl_res: Resource representing CTL base
+ * @irq_res: Resource representing IRQ and its flags
+ * @ioport_shift: I/O port shift
+ * @__pio_mask: PIO mask
*
* Register a platform bus IDE interface. Such interfaces are PIO and we
* assume do not support IRQ sharing.
@@ -135,42 +135,18 @@ static void pata_platform_setup_port(struct ata_ioports
*ioaddr,
*
* If no IRQ resource is present, PIO polling mode is used instead.
*/
-static int __devinit pata_platform_probe(struct platform_device *pdev)
+int __devinit __pata_platform_probe(struct device *dev,
+ struct resource *io_res,
+ struct resource *ctl_res,
+ struct resource *irq_res,
+ unsigned int ioport_shift,
+ int __pio_mask)
{
- struct resource *io_res, *ctl_res;
struct ata_host *host;
struct ata_port *ap;
- struct pata_platform_info *pp_info;
unsigned int mmio;
- int irq;
-
- /*
-* Simple resource validation ..
-*/
- if ((pdev->num_resources != 3) && (pdev->num_resources != 2)) {
- dev_err(&pdev->dev, "invalid number of resources\n");
- return -EINVAL;
- }
-
- /*
-* Get the I/O base first
-*/
- io_res = platform_get_resource(pdev, IORESOURCE_IO, 0);
- if (io_res == NULL) {
- io_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (unlikely(io_res == NULL))
- return -EINVAL;
- }
-
- /*
-* Then the CTL base
-*/
- ctl_res = platform_get_resource(pdev, IORESOURCE_IO, 1);
- if (ctl_res == NULL) {
- ctl_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (unlikely(ctl_res == NULL))
- return -EINVAL;
- }
+ int irq = 0;
+ int irq_flags = 0;
/*
* Check for MMIO
@@ -181,20 +157,21 @@ static int __devinit pata_platform_probe(struct
platform_device *pdev)
/*
* And the IRQ
*/
- irq = platform_get_irq(pdev, 0);
- if (irq < 0)
- irq = 0;/* no irq */
+ if (irq_res && irq_res->start > 0) {
+ irq = irq_res->start;
+ irq_flags = irq_res->flags;
+ }
/*
* Now that that's out of the way, wire up the port..
*/
- host = ata_host_alloc(&pdev->dev, 1);
+ host = ata_host_alloc(dev, 1);
if (!host)
return -ENOMEM;
ap = host->ports[0];
ap->ops = &pata_platform_port_ops;
- ap->pio_mask = pio_mask;
+ ap->pio_mask = __pio_mask;
ap->flags |= ATA_FLAG_SLAVE_POSS;
/*
@@ -209,25 +186,24 @@ static int __devinit pata_platform_probe(struct
platform_device *pdev)
* Handle the MMIO case
*/
if (mmio) {
- ap->ioaddr.cmd_addr = devm_ioremap(&pdev->dev, io_res->start,
+ ap->ioaddr.cmd_addr = devm_ioremap(dev, io_res->start,
[PATCH v4 0/3] OF-platform PATA driver
Hi all, Here is the resend (aka v4) version of the OF-platform PATA driver and related patches. Changes since v3: - Acked-by: Paul Mundt <[EMAIL PROTECTED]> - In the powerpc specific patch: update defconfig and use machine_device_initcall -- this is new call found in the galak/powerpc.git. Changes since v2: - "PPC" added to PATA_PLATFORM "depends on" Kconfig entry; I didn't remove EMBEDDED "depends on" -- this wasn't discussed much and these patches should not depend on the decision. - cosmetic fixes; - "s/ioport_shift/reg_shift/g" patch dropped. Changes since v1: - __pata_platform_probe now accepts pio_mask argument; - pata-platform compatible property renamed to ata-generic; - pata_of_platform understands pio-mode property. It's used to pass pio_mask to the __pata_platform_probe. That is, in ata-generic context pio-mode means "pio mode the bus already configured for"; - New optional patch that renames pata_platform_info's ioport_shift to reg_shift. Changes since RFC: - nuked drivers/ata/pata_platform.h; - powerpc bits: proper localbus node added. -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/2] Base Warp Platform support
Ooops. Guess I am not perfect after all ;)
Cheers,
Sean
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ arch/powerpc/platforms/44x/warp.c 2008-01-08 17:59:48.0 -0500
@@ -0,0 +1,239 @@
+/*
+ * PIKA Warp(tm) board specific routines
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <[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 "44x.h"
+
+#define WARP_GPIO_BASE 0xEF600B00ULL
+
+static __initdata struct of_device_id warp_of_bus[] = {
+ { .compatible = "ibm,plb4", },
+ { .compatible = "ibm,opb", },
+ { .compatible = "ibm,ebc", },
+ {},
+};
+
+static int __init warp_device_probe(void)
+{
+ of_platform_bus_probe(NULL, warp_of_bus, NULL);
+
+ return 0;
+}
+machine_device_initcall(warp, warp_device_probe);
+
+static int __init warp_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ if(!of_flat_dt_is_compatible(root, "pika,warp"))
+ return 0;
+
+ return 1;
+}
+
+define_machine(warp) {
+ .name = "Warp",
+ .probe = warp_probe,
+ .progress = udbg_progress,
+ .init_IRQ = uic_init_tree,
+ .get_irq= uic_get_irq,
+ .restart= ppc44x_reset_system,
+ .calibrate_decr = generic_calibrate_decr,
+};
+
+/* This is for the power LEDs 1 = on, 0 = off, -1 = leave alone */
+void warp_set_power_leds(int green, int red)
+{
+ static void *gpio_base = NULL;
+ unsigned leds;
+
+ if(gpio_base == NULL) {
+ if((gpio_base = ioremap(WARP_GPIO_BASE, 0x148)) == NULL) {
+ printk("ERROR: Unable to remap GPIO base.\n");
+ return;
+ }
+ }
+
+ leds = readl(gpio_base + 0x100);
+
+ switch(green) {
+ case 0: leds &= ~0x80; break;
+ case 1: leds |= 0x80; break;
+ }
+ switch(red) {
+ case 0: leds &= ~0x40; break;
+ case 1: leds |= 0x40; break;
+ }
+
+ writel(leds, gpio_base + 0x100);
+}
+EXPORT_SYMBOL(warp_set_power_leds);
+
+
+static int pika_dtm_thread(void *fpga)
+{
+ extern int ad7414_get_temp(int index);
+
+ while(!kthread_should_stop()) {
+ int temp = ad7414_get_temp(0);
+
+ out_be32(fpga, temp);
+
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
+ }
+
+ return 0;
+}
+
+
+static int __devinit warp_fpga_init(void)
+{
+ struct device_node *np;
+ void *fpga;
+ int irq;
+ struct resource res;
+ struct task_struct *dtm_thread;
+
+ if((np = of_find_compatible_node(NULL, NULL, "pika,fpga")) == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to find fpga\n");
+ return -ENOENT;
+ }
+
+ if((irq = irq_of_parse_and_map(np, 0)) == NO_IRQ) {
+ printk(KERN_ERR __FILE__ ": irq_of_parse_and_map failed\n");
+ return -EBUSY;
+ }
+
+ /* We do not call of_iomap here since it would map in the entire
+* fpga space, which is over 8k.
+*/
+ if(of_address_to_resource(np, 0, &res) ||
+ (fpga = ioremap(res.start, 0x24)) == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to map FPGA\n");
+ return -ENOENT;
+ }
+
+ /* Turn off the line LEDs */
+ out_be32(fpga + 8, 0);
+
+ dtm_thread = kthread_run(pika_dtm_thread, fpga + 0x20, "pika-dtm");
+
+ if(IS_ERR(dtm_thread)) {
+ iounmap(fpga);
+ printk(KERN_ERR __FILE__ ": Unable to start PIKA DTM thread\n");
+ return PTR_ERR(dtm_thread);
+ }
+
+ return 0;
+}
+device_initcall(warp_fpga_init);
+
+#define NAND_FLASH
+#ifdef NAND_FLASH
+/* --- All of this code is for the NAND flash */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */
+
+#define WARP_NAND_FLASH_REG_ADDR 0xD000UL
+#define WARP_NAND_FLASH_REG_SIZE 0x2000
+
+static struct resource warp_ndfc = {
+ .start = WARP_NAND_FLASH_REG_ADDR,
+ .end = WARP_NAND_FLASH_REG_ADDR + WARP_NAND_FLASH_REG_SIZE,
+ .flags = IORESOURCE_MEM,
+};
+
+static struct mtd_partition nand_parts[] = {
+ {
+ .name = "nand",
+ .offset = 0,
+ .size = MTDPART_SIZ_FULL,
+ }
+};
+
+struct ndfc_controller_settings warp_ndfc_settings = {
+
Re: [PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
On Wed, Jan 09, 2008 at 11:28:30AM -0600, Kumar Gala wrote:
> /* reserve the sections we're already using */
> - for (i = 0; i < lmb.reserved.cnt; i++)
> - reserve_bootmem(lmb.reserved.region[i].base,
> - lmb_size_bytes(&lmb.reserved, i));
> + for (i = 0; i < lmb.reserved.cnt; i++) {
> + unsigned long addr = lmb.reserved.region[i].base +
> + lmb_size_bytes(&lmb.reserved, i) - 1;
> + if (addr < total_lowmem)
> + reserve_bootmem(lmb.reserved.region[i].base,
> + lmb_size_bytes(&lmb.reserved, i));
> + }
It looks like if the reserved area straddles the highmem boundary, it'll
only reserve the highmem portion.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] MTD for Taco
Josh Boyer wrote: > On Wed, 09 Jan 2008 13:05:35 -0500 > Sean MacLennan <[EMAIL PROTECTED]> wrote: > > >> Stefan Roese wrote: >> >>> On Saturday 05 January 2008, Sean MacLennan wrote: >>> >>> This patch adds the maps for the taco. It also gets the ndfc.c NAND driver in a compilable state. The map is guaranteed to change since the exact NOR/NAND flash configuration is in flux right now when we found the 256M NAND flash won't boot properly. Currently it configures the NOR in a reasonable fashion and leaves the NAND as one honkin' parition. >>> >>> >>> >>> diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c index 1c0e89f..f5e93cf 100644 --- a/drivers/mtd/nand/ndfc.c +++ b/drivers/mtd/nand/ndfc.c @@ -24,11 +24,6 @@ #include #include -#ifdef CONFIG_40x -#include -#else -#include -#endif >>> You do break arch/ppc support with this patch. We have to still support >>> arch/ppc a few month, so please don't break this support for now. >>> >>> >> Here is an updated patch that does not break the ppc arch support. >> Unfortunately, it still has the taco specific patch. I can't find >> anything different between the taco and the sequoia and since this patch >> fixes the problem, the hardware guys refuse to look into it. I can't >> blame them as we are overloaded as it is. >> >> But I will send out the patch anyway in case anybody needs the ndfc >> driver working under the powerpc arch. >> > > This doesn't really get the addresses, etc from the device tree though, > correct? > > josh > ___ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev > No. You have to setup everything the old way. This *just* gets it working so if you have the PPC layout, it will work. Unless testing goes *really* well, I doubt I will have time in the short term to port it to the of_platform. I'm afraid I will have to live with "it works, don't touch it" for now :( Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] pseries: phyp dump: Docmentation
Hi Linas, Linas Vepstas wrote: > > On 08/01/2008, Nathan Lynch <[EMAIL PROTECTED]> wrote: > > Manish Ahuja wrote: > > > + > > > +The goal of hypervisor-assisted dump is to enable the dump of > > > +a crashed system, and to do so from a fully-reset system, and > > > +to minimize the total elapsed time until the system is back > > > +in production use. > > > > Is it actually faster than kdump? > > This is a basic presumption; I used the word "actually". I already know that it is intended to be faster. :) > it should blow it away, as, after all, > it requires one less reboot! There's more than rebooting going on during system dump processing. Depending on the system type, booting may not be where most time is spent. > As a side effect, the system is in > production *while* the dump is being taken; A dubious feature IMO. Seems that the design potentially trades reliability of first failure data capture for availability. E.g. system crashes, reboots, resumes processing while copying dump, crashes again before dump procedure is complete. How is that handled, if at all? > with kdump, > you can't go into production until after the dump is finished, > and the system has been rebooted a second time. On > systems with terabytes of RAM, the time difference can be > hours. The difference in time it takes to resume the normal workload may be significant, yes. But the time it takes to get a usable dump image would seem to be the basically the same. Since you bring up large systems... a system with terabytes of RAM is practically guaranteed to be a NUMA configuration with dozens of cpus. When processing a dump on such a system, I wonder how well we fare: can we successfully boot with (say) 128 cpus and 256MB of usable memory? Do we have to hot-online nodes as system memory is freed up (and does that even work)? We need to be able to restore the system to its optimal topology when the dump is finished; if the best we can do is a degraded configuration, the workload will suffer and the system admin is likely to just reboot the machine again so the kernel will have the right NUMA topology. > > > +Implementation details: > > > +-- > > > +In order for this scheme to work, memory needs to be reserved > > > +quite early in the boot cycle. However, access to the device > > > +tree this early in the boot cycle is difficult, and device-tree > > > +access is needed to determine if there is a crash data waiting. > > > > I don't think this bit about early device tree access is correct. By > > the time your code is reserving memory (from early_init_devtree(), I > > think), RTAS has been instantiated and you are able to test for the > > existence of /rtas/ibm,dump-kernel. > > If I remember right, it was still too early to look up this token directly, > so we wrote some code to crawl the flat device tree to find it. But > not only was that a lot of work, but I somehow decided that doing this > to the flat tree was wrong, as otherwise someone would surely have > written the access code. If this can be made to work, that would be > great, but we couldn't make it work at the time. > > > > +To work around this problem, all but 256MB of RAM is reserved > > > +during early boot. A short while later in boot, a check is made > > > +to determine if there is dump data waiting. If there isn't, > > > +then the reserved memory is released to general kernel use. > > > > So I think these gymnastics are unneeded -- unless I'm > > misunderstanding something, you should be able to determine very early > > whether to reserve that memory. > > Only if you can get at rtas, but you can't get at rtas at that point. Sorry, but I think you are mistaken (see Michael's earlier reply). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] MTD for Taco
On Wed, 09 Jan 2008 13:05:35 -0500 Sean MacLennan <[EMAIL PROTECTED]> wrote: > Stefan Roese wrote: > > On Saturday 05 January 2008, Sean MacLennan wrote: > > > >> This patch adds the maps for the taco. It also gets the ndfc.c NAND > >> driver in a compilable state. The map is guaranteed to change since the > >> exact NOR/NAND flash configuration is in flux right now when we found > >> the 256M NAND flash won't boot properly. > >> > >> Currently it configures the NOR in a reasonable fashion and leaves the > >> NAND as one honkin' parition. > >> > > > > > > > > > >> diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c > >> index 1c0e89f..f5e93cf 100644 > >> --- a/drivers/mtd/nand/ndfc.c > >> +++ b/drivers/mtd/nand/ndfc.c > >> @@ -24,11 +24,6 @@ > >> #include > >> > >> #include > >> -#ifdef CONFIG_40x > >> -#include > >> -#else > >> -#include > >> -#endif > >> > > > > You do break arch/ppc support with this patch. We have to still support > > arch/ppc a few month, so please don't break this support for now. > > > Here is an updated patch that does not break the ppc arch support. > Unfortunately, it still has the taco specific patch. I can't find > anything different between the taco and the sequoia and since this patch > fixes the problem, the hardware guys refuse to look into it. I can't > blame them as we are overloaded as it is. > > But I will send out the patch anyway in case anybody needs the ndfc > driver working under the powerpc arch. This doesn't really get the addresses, etc from the device tree though, correct? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3 v2] Add initial iomega StorCenter board port.
On Tue, Jan 08, 2008 at 04:07:17PM -0600, Jon Loeliger wrote:
> +static void storcenter_power_off(void)
> +{
> + /* No way to shut power off with software */
> + local_irq_disable();
> + for (;;) ;
> + /* NOTREACHED */
> +}
So leave it out, and let the generic halt function be used.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] MTD for Taco
Stefan Roese wrote:
> On Saturday 05 January 2008, Sean MacLennan wrote:
>
>> This patch adds the maps for the taco. It also gets the ndfc.c NAND
>> driver in a compilable state. The map is guaranteed to change since the
>> exact NOR/NAND flash configuration is in flux right now when we found
>> the 256M NAND flash won't boot properly.
>>
>> Currently it configures the NOR in a reasonable fashion and leaves the
>> NAND as one honkin' parition.
>>
>
>
>
>
>> diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
>> index 1c0e89f..f5e93cf 100644
>> --- a/drivers/mtd/nand/ndfc.c
>> +++ b/drivers/mtd/nand/ndfc.c
>> @@ -24,11 +24,6 @@
>> #include
>>
>> #include
>> -#ifdef CONFIG_40x
>> -#include
>> -#else
>> -#include
>> -#endif
>>
>
> You do break arch/ppc support with this patch. We have to still support
> arch/ppc a few month, so please don't break this support for now.
>
Here is an updated patch that does not break the ppc arch support.
Unfortunately, it still has the taco specific patch. I can't find
anything different between the taco and the sequoia and since this patch
fixes the problem, the hardware guys refuse to look into it. I can't
blame them as we are overloaded as it is.
But I will send out the patch anyway in case anybody needs the ndfc
driver working under the powerpc arch.
Cheers,
Sean
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
---
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 246d451..ca9f35a 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -153,7 +153,7 @@ config MTD_NAND_S3C2410_HWECC
config MTD_NAND_NDFC
tristate "NDFC NanD Flash Controller"
- depends on 4xx && !PPC_MERGE
+ depends on 4xx
select MTD_NAND_ECC_SMC
help
NDFC Nand Flash Controllers are integrated in IBM/AMCC's 4xx SoCs
diff --git a/drivers/mtd/nand/ndfc.c b/drivers/mtd/nand/ndfc.c
index 1c0e89f..fe19177 100644
--- a/drivers/mtd/nand/ndfc.c
+++ b/drivers/mtd/nand/ndfc.c
@@ -24,11 +24,13 @@
#include
#include
+#ifndef CONFIG_PPC_MERGE
#ifdef CONFIG_40x
#include
#else
#include
#endif
+#endif
struct ndfc_nand_mtd {
struct mtd_info mtd;
@@ -110,6 +112,40 @@ static int ndfc_calculate_ecc(struct mtd_info *mtd,
return 0;
}
+#ifdef CONFIG_WARP
+/* The NDFC may allow 32bit read/writes, but it sure doesn't work on
+ * the Warp!
+ */
+static void ndfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
+{
+ struct ndfc_controller *ndfc = &ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for(;len > 0; len -= 1)
+ *p++ = __raw_readb(ndfc->ndfcbase + NDFC_DATA);
+}
+
+static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
+{
+ struct ndfc_controller *ndfc = &ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for(;len > 0; len -= 1)
+ __raw_writeb(*p++, ndfc->ndfcbase + NDFC_DATA);
+}
+
+static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
+{
+ struct ndfc_controller *ndfc = &ndfc_ctrl;
+ uint8_t *p = (uint8_t *) buf;
+
+ for(;len > 0; len -= 1)
+ if (*p++ != __raw_readb(ndfc->ndfcbase + NDFC_DATA))
+ return -EFAULT;
+
+ return 0;
+}
+#else
/*
* Speedups for buffer read/write/verify
*
@@ -145,6 +181,7 @@ static int ndfc_verify_buf(struct mtd_info *mtd, const
uint8_t *buf, int len)
return -EFAULT;
return 0;
}
+#endif
/*
* Initialize chip structure
@@ -236,6 +273,8 @@ static int ndfc_nand_probe(struct platform_device *pdev)
#ifndef CONFIG_PHYS_64BIT
ndfc->ndfcbase = ioremap((phys_addr_t)phys, res->end - res->start + 1);
+#elif defined(CONFIG_PPC_MERGE)
+ ndfc->ndfcbase = ioremap(phys, res->end - res->start + 1);
#else
ndfc->ndfcbase = ioremap64(phys, res->end - res->start + 1);
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Kconfig scsi_wait_scan
Michael, I find I need to add a string to the SCSI_WAIT_SCAN tristate in order to be able to turn the module off. See the patch below. On our embedded appliance the only use for SCSI is for the usb_storage driver. Cheers, Sean MacLennan Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]> --- diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig index a6676be..960dc78 100644 --- a/drivers/scsi/Kconfig +++ b/drivers/scsi/Kconfig @@ -248,7 +248,7 @@ config SCSI_SCAN_ASYNC or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate "SCSI wait scan" default m depends on SCSI depends on MODULES ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] add phy-handle property for fec_mpc52xx
Sven Luther wrote: > This is crazy, and not future proof. The way Grant did it, checking for > the existence of the node before creating is enough for any reasonable > upgrade to the firmware. > > If future firmware will break with this, then they will break other > stuff anyway, and a new patch is needed. In other words, Grant's method is crazy and not future-proof, too. I don't see the difference, Sven, and this demonstrates entirely >> Just make sure it's less than.. let's say, a certain version of efika.forth, >> and I will roll a version which has a higher version and some extra features >> like CAN/I2C exposure. >> >> If you run efika.forth it will not touch the device tree. If you don't, it >> will add the small amount of patches. Add a huge comment that this hunk of >> code should be scheduled for deletion at some later date. Put a Kconfig >> around it so it can be taken out, even, at distro option. > > Have you not read Grant's code ? It create the nodes only if they are > not existent already. What if they ARE existant under other names, you will have two ethernet-phy in the system, maybe with the same name, and this is stupid. What if it adds the wrong properties if we work out something is wrong somewhere? Linux prom_init must not be a moving target for firmware development - it is the hardest thing to replace (it is not like loading and unloading a module) and it may in fact be polluting valid device trees REGARDLESS of any checks you might make. You cannot make Linux try and PREDICT how the device tree looks based on arbitrary name strings, because Linux device tree usage does not comply with the IEEE 1275-1994 definition of device tree properties. Grant's patch should look for a compatible property with "ethernet-phy" in it, check for phy-handle in the ethernet node, make sure that a node very similar to mdio does not already exist, etc, it is going into a screen of code to do it comprehensively and future proof. Just don't do it at all. The burden is on Genesi. So, it's difficult right now, and hard for users, so what? That's OUR problem, I dare say today it is MY problem. I do not want this to become a LINUX problem in the future when a new board comes out that is Efika-compatible, requiring patch removal, reshuffling, compliance testing etc. You do realise any new firmware with this kernel needs to work, regardless of the patch being present, in order to be validated? We can't ship an Efika board with a firmware which actively breaks because of a Linux kernel patch for older boards and some ancient bad decision, and saying "to use a new Efika you must use a brand new Linux kernel" is the kind of insanity in embedded development which made us choose SmartFirmware over U-Boot and FDT in the first place.. I am not happy that we are being dragged into this model of playing "first to mainline" with arbitrary snippets of code which do NOT improve things in the long term. -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
There were several issues if a memreserve range existed and happened
to be in highmem:
* The bootmem allocator is only aware of lowmem so calling
reserve_bootmem with a highmem address would cause a BUG_ON
* All highmem pages were provided to the buddy allocator
Added a lmb_is_reserved() api that we now use to determine if a highem
page should continue to be PageReserved or provided to the buddy
allocator.
Also, we incorrectly reported the amount of pages reserved since all
highmem pages are initally marked reserved and we clear the
PageReserved flag as we "free" up the highmem pages.
---
As normal, posted here for review, will be pushed via my for-2.6.25 branch
arch/powerpc/mm/lmb.c | 13 +
arch/powerpc/mm/mem.c | 14 ++
include/asm-powerpc/lmb.h |1 +
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/lmb.c b/arch/powerpc/mm/lmb.c
index 8f4d2dc..4ce23bc 100644
--- a/arch/powerpc/mm/lmb.c
+++ b/arch/powerpc/mm/lmb.c
@@ -342,3 +342,16 @@ void __init lmb_enforce_memory_limit(unsigned long
memory_limit)
}
}
}
+
+int __init lmb_is_reserved(unsigned long addr)
+{
+ int i;
+
+ for (i = 0; i < lmb.reserved.cnt; i++) {
+ unsigned long upper = lmb.reserved.region[i].base +
+ lmb.reserved.region[i].size - 1;
+ if ((addr >= lmb.reserved.region[i].base) && (addr <= upper))
+ return 1;
+ }
+ return 0;
+}
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 5402fb6..a004032 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -218,9 +218,13 @@ void __init do_init_bootmem(void)
#endif
/* reserve the sections we're already using */
- for (i = 0; i < lmb.reserved.cnt; i++)
- reserve_bootmem(lmb.reserved.region[i].base,
- lmb_size_bytes(&lmb.reserved, i));
+ for (i = 0; i < lmb.reserved.cnt; i++) {
+ unsigned long addr = lmb.reserved.region[i].base +
+lmb_size_bytes(&lmb.reserved, i) - 1;
+ if (addr < total_lowmem)
+ reserve_bootmem(lmb.reserved.region[i].base,
+ lmb_size_bytes(&lmb.reserved, i));
+ }
/* XXX need to clip this if using highmem? */
sparse_memory_present_with_active_regions(0);
@@ -334,11 +338,13 @@ void __init mem_init(void)
highmem_mapnr = total_lowmem >> PAGE_SHIFT;
for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) {
struct page *page = pfn_to_page(pfn);
-
+ if (lmb_is_reserved(pfn << PAGE_SHIFT))
+ continue;
ClearPageReserved(page);
init_page_count(page);
__free_page(page);
totalhigh_pages++;
+ reservedpages--;
}
totalram_pages += totalhigh_pages;
printk(KERN_DEBUG "High memory: %luk\n",
diff --git a/include/asm-powerpc/lmb.h b/include/asm-powerpc/lmb.h
index b5f9f4c..5d1dc48 100644
--- a/include/asm-powerpc/lmb.h
+++ b/include/asm-powerpc/lmb.h
@@ -51,6 +51,7 @@ extern unsigned long __init __lmb_alloc_base(unsigned long
size,
extern unsigned long __init lmb_phys_mem_size(void);
extern unsigned long __init lmb_end_of_DRAM(void);
extern void __init lmb_enforce_memory_limit(unsigned long memory_limit);
+extern int __init lmb_is_reserved(unsigned long addr);
extern void lmb_dump_all(void);
--
1.5.3.7
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Base Warp Platform support
So no comments? I got it perfect the first time :D Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Miscellaneous for Taco
Stefan Roese wrote: > On Tuesday 08 January 2008, Sean MacLennan wrote: > >> How about just 44x? >> >> Cheers, >> Sean >> >> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig >> index 7580aa5..682deae 100644 >> --- a/drivers/usb/Kconfig >> +++ b/drivers/usb/Kconfig >> @@ -39,6 +39,7 @@ config USB_ARCH_HAS_OHCI >> # PPC: >> default y if STB03xxx >> default y if PPC_MPC52xx >> + default y if 44x >> > > No. Not all 44x have OHCI built in. Currently 440EP, 440EPx and 405EZ have > it. > But since your patch only touches 440EP, you should just enable OHCI for > exactly this platform. > > Best regards, > Stefan > Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]> --- diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 7580aa5..2660f30 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -39,6 +39,7 @@ config USB_ARCH_HAS_OHCI # PPC: default y if STB03xxx default y if PPC_MPC52xx + default y if 440EP # MIPS: default y if SOC_AU1X00 # more: ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: add phy-handle property for fec_mpc52xx
On Wed, Jan 09, 2008 at 05:17:52PM +, Matt Sealey wrote: > > Sven Luther wrote: > >On Wed, Jan 09, 2008 at 04:36:19PM +, Matt Sealey wrote: > >>The link that Olaf presented, www.powerdeveloper.org/asset/by-id/46 *is* > >>the upstream support for now. What his patch does is say, the upstream > >>support exists, but we don't like it, so we will supplement the patch.. > > > >Matt, your work on efika.forth is laudable, and it is nice that you took > >the time to support it. > > > >*BUT* it is not acceptable for a distribution, or for someone who will > >have to do user support, to have to launch a second binary before > >launching the kernel. Especially when netbooting for example. > > Then I think you are all missing the fact that I said there *IS A REALLY > CUTE WAY OF INSTALLING IT ONCE* by uploading it into nvramrc, it will not > be a runnable script, but executed on boot, because it'll be flashed into > nvramrc. > > However I don't have the time to go into making this app, creating the > tools to munge efika.forth into a correct more uploadable format, and > creating the install tool. I barely have enough time to track this list > and make sure any drivers requiring firmware tree changes are taken care > of (I definitely lost the plot with the USB one, I haven't even checked > it even though I was asked to 2 weeks ago..) > > Unfortunately one guy who already has a significant amount of work to do > all day, who is not the responsible person for firmware issues, and is > not being assisted by anyone in the community either generated and > maintained by Genesi or existing around Linux, poses some serious problems > with timeliness of updates. > > If anyone wants to stop patching Linux and instead make efika.forth easier > to use, feel free, REALLY. Sven, are you volunteering for this REALLY > tiny task? It will probably take all of a day for a couple of guys to > work up the tools to do it based on very simple instructions and data > provided.. the work is probably worth the price of a pizza, so no > contracts are going to be worked out for it. Just fix it conditionally in linux, like it is being proposed, and everyone is happy :) Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ad7414 driver
Mark,
This patch adds a driver for the ad7414 chip. It was written by Stefan
Roese based on the ad7418 driver. All I did was get it compiling under
the newer kernels.
Cheers,
Sean MacLennan
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
---
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index a0445be..f14972a 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -57,6 +57,16 @@ config SENSORS_ABITUGURU3
This driver can also be built as a module. If so, the module
will be called abituguru3.
+config SENSORS_AD7414
+ tristate "Analog Devices AD7414"
+ depends on I2C && EXPERIMENTAL
+ help
+ If you say yes here you get support for the Analog Devices
+ AD7414 temperature monitoring chip.
+
+ This driver can also be built as a module. If so, the module
+ will be called ad7414.
+
config SENSORS_AD7418
tristate "Analog Devices AD7416, AD7417 and AD7418"
depends on I2C && EXPERIMENTAL
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 55595f6..fa6066e 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_SENSORS_W83791D) += w83791d.o
obj-$(CONFIG_SENSORS_ABITUGURU)+= abituguru.o
obj-$(CONFIG_SENSORS_ABITUGURU3)+= abituguru3.o
+obj-$(CONFIG_SENSORS_AD7414) += ad7414.o
obj-$(CONFIG_SENSORS_AD7418) += ad7418.o
obj-$(CONFIG_SENSORS_ADM1021) += adm1021.o
obj-$(CONFIG_SENSORS_ADM1025) += adm1025.o
@@ -72,4 +73,3 @@ obj-$(CONFIG_SENSORS_W83L785TS) += w83l785ts.o
ifeq ($(CONFIG_HWMON_DEBUG_CHIP),y)
EXTRA_CFLAGS += -DDEBUG
endif
-
--- /dev/null 2005-11-20 22:22:37.0 -0500
+++ drivers/hwmon/ad7414.c 2008-01-09 12:09:51.0 -0500
@@ -0,0 +1,322 @@
+/*
+ * An hwmon driver for the Analog Devices AD7414
+ *
+ * Copyright 2006 Stefan Roese <[EMAIL PROTECTED]>, DENX Software Engineering
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <[EMAIL PROTECTED]>
+ *
+ * Based on ad7418.c
+ * Copyright 2006 Tower Technologies, Alessandro Zummo <[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
+
+
+#define DRV_VERSION "0.2"
+
+/* straight from the datasheet */
+#define AD7414_TEMP_MIN (-55000)
+#define AD7414_TEMP_MAX 125000
+
+/* Addresses to scan */
+static unsigned short normal_i2c[] = { 0x48, 0x4a, I2C_CLIENT_END };
+
+/* Insmod parameters */
+I2C_CLIENT_INSMOD;
+
+/* AD7414 registers */
+#define AD7414_REG_TEMP0x00
+#define AD7414_REG_CONF0x01
+#define AD7414_REG_T_HIGH 0x02
+#define AD7414_REG_T_LOW 0x03
+
+struct ad7414_data {
+ struct i2c_client client;
+ struct device *dev;
+ struct mutexlock;
+ charvalid; /* !=0 if following fields are
valid */
+ unsigned long last_updated; /* In jiffies */
+ u16 temp_input; /* Register values */
+ u8 temp_max;
+ u8 temp_min;
+ u8 temp_alert;
+ u8 temp_max_flag;
+ u8 temp_min_flag;
+};
+
+
+struct ad7414_dev {
+ struct list_head list;
+ struct device *dev;
+};
+
+static LIST_HEAD(ad7414_dev_list);
+
+
+static int ad7414_attach_adapter(struct i2c_adapter *adapter);
+static int ad7414_detect(struct i2c_adapter *adapter, int address, int kind);
+static int ad7414_detach_client(struct i2c_client *client);
+
+static struct i2c_driver ad7414_driver = {
+ .driver = {
+ .name = "ad7414",
+ },
+ .attach_adapter = ad7414_attach_adapter,
+ .detach_client = ad7414_detach_client,
+};
+
+/*
+ * TEMP: 0.001C/bit (-55C to +125C)
+ * REG: (0.5C/bit, two's complement) << 7
+ */
+static inline int AD7414_TEMP_FROM_REG(u16 reg)
+{
+ /* use integer division instead of equivalent right shift to
+* guarantee arithmetic shift and preserve the sign
+*/
+ return ((s16)reg / 128) * 500;
+}
+
+/* All registers are word-sized, except for the configuration registers.
+ * AD7414 uses a high-byte first convention, which is exactly opposite to
+ * the usual practice.
+ */
+static int ad7414_read(struct i2c_client *client, u8 reg)
+{
+ if (reg == AD7414_REG_TEMP)
+ return swab16(i2c_smbus_read_word_data(client, reg));
+ else
+ return i2c_smbus_read_byte_data(client, reg);
+}
+
+static int ad7414_write(struct i2c_client *client, u8 reg, u16 value)
+{
+ return i2c_smbus_write_byte_data(client, reg, value);
+}
Re: [RFC] add phy-handle property for fec_mpc52xx
On Wed, Jan 09, 2008 at 04:56:17PM +, Matt Sealey wrote: > Okay I have a better suggestion. > > Apply all the prom_init fixes you like. But, instead of swizzling on the > individual nodes, do it blanket for the firmware version. > > For instance, wrap the entire efika fixups stuff with a check for the > openprom property "built-on" - this is the date the firmware was built. > efika.forth will change this! This is crazy, and not future proof. The way Grant did it, checking for the existence of the node before creating is enough for any reasonable upgrade to the firmware. If future firmware will break with this, then they will break other stuff anyway, and a new patch is needed. > Just make sure it's less than.. let's say, a certain version of efika.forth, > and I will roll a version which has a higher version and some extra features > like CAN/I2C exposure. > > If you run efika.forth it will not touch the device tree. If you don't, it > will add the small amount of patches. Add a huge comment that this hunk of > code should be scheduled for deletion at some later date. Put a Kconfig > around it so it can be taken out, even, at distro option. Have you not read Grant's code ? It create the nodes only if they are not existent already. Friendly, Sven Luther ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Generic MMC-over-SPI binding?
Hi, Arnd Bergmann wrote: > The important part where this connects to the mmc-spi driver is that > you need to set spi_board_info->modalias to "mmc-spi", if the > device node can be identified as an mmc card. Doing that now, using the code you provided as a base. The SPI child device gets registered, but it appears something is still missing as no messages I could attribute to mmc-spi appear. My suspicion would be that it doesn't like the monolithic kernel for some reason (the mmc-spi driver registers itself as a driver called "mmc_spi", not sure if the modalias handling will catch that; still investigating there). > Then you call that function after registering the master, from > mpc52xx_psc_spi_of_probe. I've changed mpc52xx_psc_spi_do_probe to have an additional argument for the OF device node of the SPI master; ARCH=ppc can call this with NULL as long as it still exists. Simon ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
