* [PATCH] powermac: thermal control turns system off in normal temperature conditions
From: Bartlomiej Zolnierkiewicz @ 2009-08-30 18:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel, Lyonel Vincent
=46rom: Lyonel Vincent <lyonel@ezix.org>
Subject: [PATCH] powermac: thermal control turns system off in normal tempe=
rature conditions
On certain PowerMacs, a module (therm_windtunnel) controls various
thermal settings (it can report CPU/case temperature, change speed
of internal fans, etc.)
By default, the hardware thermal control has a temperature limit to
protect the computer from damages (the default limit seems to be 80=B0C)
but therm_windtunnel.c reduces it to an anormaly low value (65=B0C),
which means that he computer will shut down randomly when hit by direct
sun light or during summer (summer in France can be quite hot), actually
possibly losing data instead of protecting it.
The overheat limit in therm_windtunnel.c:253-254 should be set to 75=B0C
and 70=B0C instead of 65=B0C and 60=B0C respectively.
=46rom: Lyonel Vincent <lyonel@ezix.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
=2D--
Resurrected from Fedora's bugzilla (aka The Big Black Hole):
https://bugzilla.redhat.com/show_bug.cgi?id=3D171937
The patch itself seems perfectly valid to me
(especially given comments in therm_windtunnel.c).
drivers/macintosh/therm_windtunnel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/drivers/macintosh/therm_windtunnel.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=2D-- a/drivers/macintosh/therm_windtunnel.c
+++ b/drivers/macintosh/therm_windtunnel.c
@@ -239,8 +239,8 @@ setup_hardware( void )
* to be on the safe side (OSX doesn't)...
*/
if( x.overheat_temp =3D=3D (80 << 8) ) {
=2D x.overheat_temp =3D 65 << 8;
=2D x.overheat_hyst =3D 60 << 8;
+ x.overheat_temp =3D 75 << 8;
+ x.overheat_hyst =3D 70 << 8;
write_reg( x.thermostat, 2, x.overheat_hyst, 2 );
write_reg( x.thermostat, 3, x.overheat_temp, 2 );
=20
^ permalink raw reply
* RS6000/S70
From: rlima @ 2009-08-29 2:47 UTC (permalink / raw)
To: linuxppc-dev
I need help to compile a Kernel
How to compile kernel?
Where I can find the parameters necessary to compile a Kernel for a
mainframe IBM rs 6000/s70 (processor powerpc rs64)?
Which the archives necessary to create a boot disk
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: [Qemu-devel] Re: Extending virtio_console to support multiple ports
From: Jamie Lokier @ 2009-08-29 1:15 UTC (permalink / raw)
To: Alan Cox
Cc: kvm, borntraeger, qemu-devel, miltonm, linux-kernel, linuxppc-dev,
brueckner, Amit Shah, virtualization
In-Reply-To: <20090827100809.5f0aa0a7@linux.intel.com>
Alan Cox wrote:
> > - Then, are we certain that there's no case where the tty layer will
> > call us with some lock held or in an atomic context ? To be honest,
> > I've totally lost track of the locking rules in tty land lately so it
> > might well be ok, but something to verify.
>
> Some of the less well behaved line disciplines do this and always have
> done.
I had a backtrace in my kernel log recently which looked like that,
while doing PPP over Bluetooth RFCOMM. Resulted in AppArmor
complaining that it's hook was being called in irq context.
-- Jamie
^ permalink raw reply
* Re: [RFC] Clock binding
From: Benjamin Herrenschmidt @ 2009-08-28 22:33 UTC (permalink / raw)
To: Rafal Jaworowski; +Cc: linuxppc-dev list, devicetree-discuss, Stuart Yoder
In-Reply-To: <B7829AEE-B751-403D-9A16-CFE1A4E0FAB0@semihalf.com>
On Fri, 2009-08-28 at 20:24 +0200, Rafal Jaworowski wrote:
> Grant,
> When choosing the best location for the bindings page please consider
> it uniform enough so that various OSes can use it as a reference. We
> are very much interested in bringing FDT support for embedded FreeBSD
> (arm, powerpc), and one of the uncertainties is how to deal with
> existing Linux bindings definitions: at the moment they are maintained
> as part of kernel source tree, and there are doubts whether we should
> come up with our own set (most likely *very* similar), which we'd like
> to avoid.
I agree. We need to be OS neutral.
In fact, one of the main issue right now with the core binding is the
phandles, which are put into "linux,phandle" properties. That must
change and we need to make the kernel aware of the change.
We will still keep linux-specific properties around, I suppose, mostly
for linux-specific things exchanged between the boot wrapper and the
kernel, but the base tree should generally be devoid of a "linux,"
property.
Cheers,
Ben.
^ permalink raw reply
* Re: [RFC] Clock binding
From: Benjamin Herrenschmidt @ 2009-08-28 22:28 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev list, devicetree-discuss
In-Reply-To: <20090828112322.GA16192@yookeroo.seuss>
> > This is about the 3rd or 4th time this idea has come up over the past couple
> > of years. Maybe this time it will stick?
>
> There actually was one set up on power.org, for epapr bindings. I'm
> still digging around to try to relocate the address, though.
We need to double check that indeed the content is freely licenced,
especially if, in the future, for some reasons, power.org goes down,
that we are legally allowed to take that content and put it elsewhere.
Cheers,
Ben.
^ permalink raw reply
* [PATCH 1/1] powerpc: Fix to handle slb resize across migration
From: Brian King @ 2009-08-28 22:06 UTC (permalink / raw)
To: benh; +Cc: brking, linuxppc-dev
The SLB can change sizes across a live migration, which was not
being handled, resulting in possible machine crashes during
migration if migrating to a machine which has a smaller max SLB
size than the source machine. Fix this by first reducing the
SLB size to the minimum possible value, which is 32, prior to
migration. Then during the device tree update which occurs after
migration, we make the call to ensure the SLB gets updated. Also
add the slb_size to the lparcfg output so that the migration
tools can check to make sure the kernel has this capability
before allowing migration in scenarios where the SLB size will change.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/mmu-hash64.h | 2 ++
arch/powerpc/kernel/lparcfg.c | 3 +++
arch/powerpc/kernel/rtas.c | 7 ++++++-
arch/powerpc/mm/slb.c | 16 ++++++++++++----
arch/powerpc/platforms/pseries/reconfig.c | 9 ++++++++-
5 files changed, 31 insertions(+), 6 deletions(-)
diff -puN arch/powerpc/kernel/rtas.c~powerpc_slb_resize arch/powerpc/kernel/rtas.c
--- linux-2.6/arch/powerpc/kernel/rtas.c~powerpc_slb_resize 2009-08-21 16:14:41.000000000 -0500
+++ linux-2.6-bjking1/arch/powerpc/kernel/rtas.c 2009-08-21 16:14:41.000000000 -0500
@@ -39,6 +39,7 @@
#include <asm/smp.h>
#include <asm/atomic.h>
#include <asm/time.h>
+#include <asm/mmu-hash64.h>
struct rtas_t rtas = {
.lock = __RAW_SPIN_LOCK_UNLOCKED
@@ -713,6 +714,7 @@ static void rtas_percpu_suspend_me(void
{
long rc = H_SUCCESS;
unsigned long msr_save;
+ u16 slb_size = mmu_slb_size;
int cpu;
struct rtas_suspend_me_data *data =
(struct rtas_suspend_me_data *)info;
@@ -735,13 +737,16 @@ static void rtas_percpu_suspend_me(void
/* All other cpus are in H_JOIN, this cpu does
* the suspend.
*/
+ slb_set_size(SLB_MIN_SIZE);
printk(KERN_DEBUG "calling ibm,suspend-me on cpu %i\n",
smp_processor_id());
data->error = rtas_call(data->token, 0, 1, NULL);
- if (data->error)
+ if (data->error) {
printk(KERN_DEBUG "ibm,suspend-me returned %d\n",
data->error);
+ slb_set_size(slb_size);
+ }
} else {
printk(KERN_ERR "H_JOIN on cpu %i failed with rc = %ld\n",
smp_processor_id(), rc);
diff -puN arch/powerpc/include/asm/mmu-hash64.h~powerpc_slb_resize arch/powerpc/include/asm/mmu-hash64.h
--- linux-2.6/arch/powerpc/include/asm/mmu-hash64.h~powerpc_slb_resize 2009-08-21 16:14:41.000000000 -0500
+++ linux-2.6-bjking1/arch/powerpc/include/asm/mmu-hash64.h 2009-08-21 16:14:41.000000000 -0500
@@ -41,6 +41,7 @@ extern char initial_stab[];
#define SLB_NUM_BOLTED 3
#define SLB_CACHE_ENTRIES 8
+#define SLB_MIN_SIZE 32
/* Bits in the SLB ESID word */
#define SLB_ESID_V ASM_CONST(0x0000000008000000) /* valid */
@@ -296,6 +297,7 @@ extern void slb_flush_and_rebolt(void);
extern void stab_initialize(unsigned long stab);
extern void slb_vmalloc_update(void);
+extern void slb_set_size(u16 size);
#endif /* __ASSEMBLY__ */
/*
diff -puN arch/powerpc/mm/slb.c~powerpc_slb_resize arch/powerpc/mm/slb.c
--- linux-2.6/arch/powerpc/mm/slb.c~powerpc_slb_resize 2009-08-21 16:14:41.000000000 -0500
+++ linux-2.6-bjking1/arch/powerpc/mm/slb.c 2009-08-21 16:14:41.000000000 -0500
@@ -240,14 +240,22 @@ void switch_slb(struct task_struct *tsk,
static inline void patch_slb_encoding(unsigned int *insn_addr,
unsigned int immed)
{
- /* Assume the instruction had a "0" immediate value, just
- * "or" in the new value
- */
- *insn_addr |= immed;
+ *insn_addr = (*insn_addr & 0xffff0000) | immed;
flush_icache_range((unsigned long)insn_addr, 4+
(unsigned long)insn_addr);
}
+void slb_set_size(u16 size)
+{
+ extern unsigned int *slb_compare_rr_to_size;
+
+ if (mmu_slb_size == size)
+ return;
+
+ mmu_slb_size = size;
+ patch_slb_encoding(slb_compare_rr_to_size, mmu_slb_size);
+}
+
void slb_initialize(void)
{
unsigned long linear_llp, vmalloc_llp, io_llp;
diff -puN arch/powerpc/platforms/pseries/reconfig.c~powerpc_slb_resize arch/powerpc/platforms/pseries/reconfig.c
--- linux-2.6/arch/powerpc/platforms/pseries/reconfig.c~powerpc_slb_resize 2009-08-21 16:14:41.000000000 -0500
+++ linux-2.6-bjking1/arch/powerpc/platforms/pseries/reconfig.c 2009-08-28 13:36:55.000000000 -0500
@@ -20,6 +20,7 @@
#include <asm/machdep.h>
#include <asm/uaccess.h>
#include <asm/pSeries_reconfig.h>
+#include <asm/mmu-hash64.h>
@@ -439,9 +440,15 @@ static int do_update_property(char *buf,
if (!newprop)
return -ENOMEM;
+ if (!strcmp(name, "slb-size") || !strcmp(name, "ibm,slb-size"))
+ slb_set_size(*(int *)value);
+
oldprop = of_find_property(np, name,NULL);
- if (!oldprop)
+ if (!oldprop) {
+ if (strlen(name))
+ return prom_add_property(np, newprop);
return -ENODEV;
+ }
rc = prom_update_property(np, newprop, oldprop);
if (rc)
diff -puN arch/powerpc/kernel/lparcfg.c~powerpc_slb_resize arch/powerpc/kernel/lparcfg.c
--- linux-2.6/arch/powerpc/kernel/lparcfg.c~powerpc_slb_resize 2009-08-21 16:14:41.000000000 -0500
+++ linux-2.6-bjking1/arch/powerpc/kernel/lparcfg.c 2009-08-21 16:14:41.000000000 -0500
@@ -35,6 +35,7 @@
#include <asm/prom.h>
#include <asm/vdso_datapage.h>
#include <asm/vio.h>
+#include <asm/mmu-hash64.h>
#define MODULE_VERS "1.8"
#define MODULE_NAME "lparcfg"
@@ -537,6 +538,8 @@ static int pseries_lparcfg_data(struct s
seq_printf(m, "shared_processor_mode=%d\n", lppaca[0].shared_proc);
+ seq_printf(m, "slb_size=%d\n", mmu_slb_size);
+
return 0;
}
_
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: add kexec support on FSL-Book-E
From: Sebastian Andrzej Siewior @ 2009-08-28 19:35 UTC (permalink / raw)
To: wilbur.chan; +Cc: linuxppc-dev
In-Reply-To: <e997b7420908250909k74208353v81240eebd3d0896a@mail.gmail.com>
wilbur.chan wrote:
> Hi Sebastian,
Hi Wilbur,
> Recently I've implemented non-SMP kexec on MPC8572 and P2020ds(2G ram).
>
>
>
> I modified your
>
> misc_32.S that , I setuped two '1G' entries after the "rfi"
> instruction, so that I did
> not need to setup mapping for instruction address.
If you send some patches I could add them to my tree so we have
everything together.
> As for SMP supporting,I tried to close one of the CPUs in
> default_machine_kexec,
>
> and found that , when cpu1 closed ,and if the second kernel is NON-
>
> SMP,everything went well.so I added some code in
>
> kexec-tools, to make sure the 'kexec' process was running on CPU 0.
I remember that ppc64 had some code to suspend and start the second CPU in
the purgatory code. Not sure if there is a generic way for this on ppc32
or it is a book-e thing. Haven't look at it (yet).
> So, there left one problem, I can not start the second SMP-kernel,
> even if I closed
>
> CPU1. Any suggestions?
The interesting thing is where do you hang/crash. It could be possible
that the kernel is waiting for the non-boot cpus to show up and it
doesn't. Have you look how u-boot prepares the cpus and how kernel
disables them on shutdown?
> PTW:
>
> no-smp ---> no-smp.........OK
> no-smp --->smp...............OK
Does this mean your smp kernel has more that one CPU or just one?
> smp(with cpu1 closed)---->no-smp..............OK
> smpw(with cpu1 closed)---->smp ................FAILED
>
>
> regards,
>
> wilbur
Sebastian
^ permalink raw reply
* Re: [RFC] Clock binding
From: Grant Likely @ 2009-08-28 20:09 UTC (permalink / raw)
To: Stuart Yoder; +Cc: devicetree-discuss, linuxppc-dev list
In-Reply-To: <955e48b80908281105q60c057e8pfc16213f17da9138@mail.gmail.com>
On Fri, Aug 28, 2009 at 12:05 PM, Stuart Yoder<stuyoder@gmail.com> wrote:
>> Lets *not* do it on power.org. =A0I'd like to see the bindings used by
>> more than just powerpc people, and power.org might become a bit of a
>> mental barrier for non-powerpc folks. =A0kernel.org would be a good
>> host. =A0So would ozlabs or infradead. =A0Or I'd be happy to maintain on=
e
>> on secretlab.
>
> I think broadening it beyond power.org is good. =A0Along those lines I'd =
prefer
> not having this on kernel.org, as device trees are not Linux-centric. =A0=
There
> are other OS vendors I've interacted with that I'd like to see use device=
trees
> and separating it from Linux may be better IMO.
>
> We could also create a new domain like "devicetree.org" (?)..but it still
> would nee a host.
How about right here: http://fdt.secretlab.ca/
I've only just created the site. I'll fill in some documentation and
structure in the next few days. Feel free to create an account and
start adding stuff.
We'll need to talk about how best to manage bindings and have some
form of review/agreement before a binding is marked as "stable". And
the site URL could change as well. But in the meantime we've got a
sandbox to start playing in.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH V3] powerpc/pci: Merge ppc32 and ppc64 versions of phb_scan()
From: Grant Likely @ 2009-08-28 18:58 UTC (permalink / raw)
To: benh, galak, sfr, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
The two versions are doing almost exactly the same thing. No need to
maintain them as separate files. This patch also has the side effect
of making the PCI device tree scanning code available to 32 bit powerpc
machines, but no board ports actually make use of this feature at this
point.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
---
Changes in v3: Fixed up calls to scan_phb() in of_platform.c and
pc_dlpar.c
Changes in v2: renamed pcibios_scan_phb 'data' argument to 'sysdata'
arch/powerpc/include/asm/pci.h | 2 +
arch/powerpc/include/asm/ppc-pci.h | 1 -
arch/powerpc/kernel/of_platform.c | 2 +
arch/powerpc/kernel/pci-common.c | 49 ++++++++++++++++++++++++++++
arch/powerpc/kernel/pci_32.c | 25 +-------------
arch/powerpc/kernel/pci_64.c | 46 +++-----------------------
arch/powerpc/platforms/pseries/pci_dlpar.c | 2 +
7 files changed, 61 insertions(+), 66 deletions(-)
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index 9ae2e3e..6205a24 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -233,6 +233,8 @@ extern void pci_resource_to_user(const struct pci_dev *dev, int bar,
extern void pcibios_setup_bus_devices(struct pci_bus *bus);
extern void pcibios_setup_bus_self(struct pci_bus *bus);
+extern void pcibios_setup_phb_io_space(struct pci_controller *hose);
+extern void pcibios_scan_phb(struct pci_controller *hose, void *sysdata);
#endif /* __KERNEL__ */
#endif /* __ASM_POWERPC_PCI_H */
diff --git a/arch/powerpc/include/asm/ppc-pci.h b/arch/powerpc/include/asm/ppc-pci.h
index 854ab71..2828f9d 100644
--- a/arch/powerpc/include/asm/ppc-pci.h
+++ b/arch/powerpc/include/asm/ppc-pci.h
@@ -39,7 +39,6 @@ void *traverse_pci_devices(struct device_node *start, traverse_func pre,
extern void pci_devs_phb_init(void);
extern void pci_devs_phb_init_dynamic(struct pci_controller *phb);
-extern void scan_phb(struct pci_controller *hose);
/* From rtas_pci.h */
extern void init_pci_config_tokens (void);
diff --git a/arch/powerpc/kernel/of_platform.c b/arch/powerpc/kernel/of_platform.c
index 87df428..1a4fc0d 100644
--- a/arch/powerpc/kernel/of_platform.c
+++ b/arch/powerpc/kernel/of_platform.c
@@ -276,7 +276,7 @@ static int __devinit of_pci_phb_probe(struct of_device *dev,
#endif /* CONFIG_EEH */
/* Scan the bus */
- scan_phb(phb);
+ pcibios_scan_phb(phb, dev->node);
if (phb->bus == NULL)
return -ENXIO;
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 44497a8..6e02df4 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1617,3 +1617,52 @@ void __devinit pcibios_setup_phb_resources(struct pci_controller *hose)
(unsigned long)hose->io_base_virt - _IO_BASE);
}
+
+/**
+ * pci_scan_phb - Given a pci_controller, setup and scan the PCI bus
+ * @hose: Pointer to the PCI host controller instance structure
+ * @sysdata: value to use for sysdata pointer. ppc32 and ppc64 differ here
+ *
+ * Note: the 'data' pointer is a temporary measure. As 32 and 64 bit
+ * pci code gets merged, this parameter should become unnecessary because
+ * both will use the same value.
+ */
+void __devinit pcibios_scan_phb(struct pci_controller *hose, void *sysdata)
+{
+ struct pci_bus *bus;
+ struct device_node *node = hose->dn;
+ int mode;
+
+ pr_debug("PCI: Scanning PHB %s\n",
+ node ? node->full_name : "<NO NAME>");
+
+ /* Create an empty bus for the toplevel */
+ bus = pci_create_bus(hose->parent, hose->first_busno, hose->ops,
+ sysdata);
+ if (bus == NULL) {
+ pr_err("Failed to create bus for PCI domain %04x\n",
+ hose->global_number);
+ return;
+ }
+ bus->secondary = hose->first_busno;
+ hose->bus = bus;
+
+ /* Get some IO space for the new PHB */
+ pcibios_setup_phb_io_space(hose);
+
+ /* Wire up PHB bus resources */
+ pcibios_setup_phb_resources(hose);
+
+ /* Get probe mode and perform scan */
+ mode = PCI_PROBE_NORMAL;
+ if (node && ppc_md.pci_probe_mode)
+ mode = ppc_md.pci_probe_mode(bus);
+ pr_debug(" probe mode: %d\n", mode);
+ if (mode == PCI_PROBE_DEVTREE) {
+ bus->subordinate = hose->last_busno;
+ of_scan_bus(node, bus);
+ }
+
+ if (mode == PCI_PROBE_NORMAL)
+ hose->last_busno = bus->subordinate = pci_scan_child_bus(bus);
+}
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 1e807fe..4e415e1 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -354,36 +354,15 @@ pci_create_OF_bus_map(void)
}
}
-static void __devinit pcibios_scan_phb(struct pci_controller *hose)
+void __devinit pcibios_setup_phb_io_space(struct pci_controller *hose)
{
- struct pci_bus *bus;
- struct device_node *node = hose->dn;
unsigned long io_offset;
struct resource *res = &hose->io_resource;
- pr_debug("PCI: Scanning PHB %s\n",
- node ? node->full_name : "<NO NAME>");
-
- /* Create an empty bus for the toplevel */
- bus = pci_create_bus(hose->parent, hose->first_busno, hose->ops, hose);
- if (bus == NULL) {
- printk(KERN_ERR "Failed to create bus for PCI domain %04x\n",
- hose->global_number);
- return;
- }
- bus->secondary = hose->first_busno;
- hose->bus = bus;
-
/* Fixup IO space offset */
io_offset = (unsigned long)hose->io_base_virt - isa_io_base;
res->start = (res->start + io_offset) & 0xffffffffu;
res->end = (res->end + io_offset) & 0xffffffffu;
-
- /* Wire up PHB bus resources */
- pcibios_setup_phb_resources(hose);
-
- /* Scan children */
- hose->last_busno = bus->subordinate = pci_scan_child_bus(bus);
}
static int __init pcibios_init(void)
@@ -401,7 +380,7 @@ static int __init pcibios_init(void)
if (pci_assign_all_buses)
hose->first_busno = next_busno;
hose->last_busno = 0xff;
- pcibios_scan_phb(hose);
+ pcibios_scan_phb(hose, hose);
pci_bus_add_devices(hose->bus);
if (pci_assign_all_buses || next_busno <= hose->last_busno)
next_busno = hose->last_busno + pcibios_assign_bus_offset;
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 4d5b4ce..ba949a2 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -43,45 +43,6 @@ unsigned long pci_probe_only = 1;
unsigned long pci_io_base = ISA_IO_BASE;
EXPORT_SYMBOL(pci_io_base);
-void __devinit scan_phb(struct pci_controller *hose)
-{
- struct pci_bus *bus;
- struct device_node *node = hose->dn;
- int mode;
-
- pr_debug("PCI: Scanning PHB %s\n",
- node ? node->full_name : "<NO NAME>");
-
- /* Create an empty bus for the toplevel */
- bus = pci_create_bus(hose->parent, hose->first_busno, hose->ops, node);
- if (bus == NULL) {
- printk(KERN_ERR "Failed to create bus for PCI domain %04x\n",
- hose->global_number);
- return;
- }
- bus->secondary = hose->first_busno;
- hose->bus = bus;
-
- /* Get some IO space for the new PHB */
- pcibios_map_io_space(bus);
-
- /* Wire up PHB bus resources */
- pcibios_setup_phb_resources(hose);
-
- /* Get probe mode and perform scan */
- mode = PCI_PROBE_NORMAL;
- if (node && ppc_md.pci_probe_mode)
- mode = ppc_md.pci_probe_mode(bus);
- pr_debug(" probe mode: %d\n", mode);
- if (mode == PCI_PROBE_DEVTREE) {
- bus->subordinate = hose->last_busno;
- of_scan_bus(node, bus);
- }
-
- if (mode == PCI_PROBE_NORMAL)
- hose->last_busno = bus->subordinate = pci_scan_child_bus(bus);
-}
-
static int __init pcibios_init(void)
{
struct pci_controller *hose, *tmp;
@@ -103,7 +64,7 @@ static int __init pcibios_init(void)
/* Scan all of the recorded PCI controllers. */
list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
- scan_phb(hose);
+ pcibios_scan_phb(hose, hose->dn);
pci_bus_add_devices(hose->bus);
}
@@ -237,6 +198,11 @@ int __devinit pcibios_map_io_space(struct pci_bus *bus)
}
EXPORT_SYMBOL_GPL(pcibios_map_io_space);
+void __devinit pcibios_setup_phb_io_space(struct pci_controller *hose)
+{
+ pcibios_map_io_space(hose->bus);
+}
+
#define IOBASE_BRIDGE_NUMBER 0
#define IOBASE_MEMORY 1
#define IOBASE_IO 2
diff --git a/arch/powerpc/platforms/pseries/pci_dlpar.c b/arch/powerpc/platforms/pseries/pci_dlpar.c
index ad152a0..b6fa3e4 100644
--- a/arch/powerpc/platforms/pseries/pci_dlpar.c
+++ b/arch/powerpc/platforms/pseries/pci_dlpar.c
@@ -151,7 +151,7 @@ struct pci_controller * __devinit init_phb_dynamic(struct device_node *dn)
if (dn->child)
eeh_add_device_tree_early(dn);
- scan_phb(phb);
+ pcibios_scan_phb(phb, dn);
pcibios_finish_adding_to_bus(phb->bus);
return phb;
^ permalink raw reply related
* Re: [PATCH V2 3/3] powerpc/pci: Merge ppc32 and ppc64 versions of phb_scan()
From: Grant Likely @ 2009-08-28 18:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: sfr, linuxppc-dev
In-Reply-To: <1251351981.20467.37.camel@pasglop>
On Wed, Aug 26, 2009 at 11:46 PM, Benjamin
Herrenschmidt<benh@kernel.crashing.org> wrote:
> On Wed, 2009-08-26 at 00:07 -0600, Grant Likely wrote:
>> From: Grant Likely <grant.likely@secretlab.ca>
>>
>> The two versions are doing almost exactly the same thing. =A0No need to
>> maintain them as separate files. =A0This patch also has the side effect
>> of making the PCI device tree scanning code available to 32 bit powerpc
>> machines, but no board ports actually make use of this feature at this
>> point.
>
> You missed various calls to scan_phb() in arch/powerpc :-)
>
> At least pSeries with dynamic LPAR is broken
Oops, yup. I also broke CONFIG_PPC_OF_PLATFORM_PCI in of_platform.c.
Fixed now.
> I think iSeries might break too.
iSeries has its own unrelated scan_phb() implementation. I don't
think I broke it.
> Try a ppc64_defconfig.
Done.
> I tentatively applied the other patches to -test
Thanks. New scan_phb() patch to follow.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC] Clock binding
From: M. Warner Losh @ 2009-08-28 18:23 UTC (permalink / raw)
To: stuyoder; +Cc: linuxppc-dev, devicetree-discuss
In-Reply-To: <955e48b80908281105q60c057e8pfc16213f17da9138@mail.gmail.com>
In message: <955e48b80908281105q60c057e8pfc16213f17da9138@mail.gmail.co=
m>
Stuart Yoder <stuyoder@gmail.com> writes:
: > Lets *not* do it on power.org. =A0I'd like to see the bindings used=
by
: > more than just powerpc people, and power.org might become a bit of =
a
: > mental barrier for non-powerpc folks. =A0kernel.org would be a good=
: > host. =A0So would ozlabs or infradead. =A0Or I'd be happy to mainta=
in one
: > on secretlab.
: =
: I think broadening it beyond power.org is good. Along those lines I'=
d prefer
: not having this on kernel.org, as device trees are not Linux-centric.=
There
: are other OS vendors I've interacted with that I'd like to see use de=
vice trees
: and separating it from Linux may be better IMO.
I know of at least one other free OS that will be migrating to device
trees for enumeration of devices in the embedded space...
Warner
^ permalink raw reply
* Re: [RFC] Clock binding
From: Rafal Jaworowski @ 2009-08-28 18:24 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev list, devicetree-discuss, Stuart Yoder
In-Reply-To: <fa686aa40908280906w7953017ek44ee498d57e0a642@mail.gmail.com>
On 2009-08-28, at 18:06, Grant Likely wrote:
> On Fri, Aug 28, 2009 at 6:16 AM, Stuart Yoder<stuyoder@gmail.com>
> wrote:
>> On Thu, Aug 27, 2009 at 9:43 PM, Benjamin
>> Herrenschmidt<benh@kernel.crashing.org> wrote:
>>> On Thu, 2009-08-27 at 16:36 -1000, Mitch Bradley wrote:
>>>> The idea of a wiki as a registration authority is a good one, but
>>>> I'm
>>>> not volunteering to maintain it :-)
>>>
>>> here goes my hope :-)
>>>
>>> Do we have wiki's we could use on power.org or should we aim for a
>>> community place ? Anybody has suggestions ? I wouldn't even try to
>>> maintain a web site myself, that would be irresponsible of anybody
>>> to
>>> let me do so !
>>
>> There was an ePAPR wiki on power.org, that I had started developing,
>> but it seems to have disappeared. I'm looking into what happened.
>
> Lets *not* do it on power.org. I'd like to see the bindings used by
> more than just powerpc people, and power.org might become a bit of a
> mental barrier for non-powerpc folks. kernel.org would be a good
> host. So would ozlabs or infradead. Or I'd be happy to maintain one
> on secretlab.
>
> What about openfirmware.info? I don't know anything about Core
> Systems who maintains that site though.
Grant,
When choosing the best location for the bindings page please consider
it uniform enough so that various OSes can use it as a reference. We
are very much interested in bringing FDT support for embedded FreeBSD
(arm, powerpc), and one of the uncertainties is how to deal with
existing Linux bindings definitions: at the moment they are maintained
as part of kernel source tree, and there are doubts whether we should
come up with our own set (most likely *very* similar), which we'd like
to avoid.
Rafal
^ permalink raw reply
* Re: [RFC] Clock binding
From: Mitch Bradley @ 2009-08-28 18:12 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev list, devicetree-discuss, Stuart Yoder
In-Reply-To: <fa686aa40908280906w7953017ek44ee498d57e0a642@mail.gmail.com>
>
> What about openfirmware.info? I don't know anything about Core
> Systems who maintains that site though.
>
Stefan Reinauer is the main guy there. He has been very helpful in
hosting the Open Firmware source tree. I expect that he would be
willing to host the wiki, since he has been interested in Open Firmware
for many years.
^ permalink raw reply
* Re: [RFC] Clock binding
From: Stuart Yoder @ 2009-08-28 18:05 UTC (permalink / raw)
To: Grant Likely; +Cc: devicetree-discuss, linuxppc-dev list
In-Reply-To: <fa686aa40908280906w7953017ek44ee498d57e0a642@mail.gmail.com>
> Lets *not* do it on power.org. =A0I'd like to see the bindings used by
> more than just powerpc people, and power.org might become a bit of a
> mental barrier for non-powerpc folks. =A0kernel.org would be a good
> host. =A0So would ozlabs or infradead. =A0Or I'd be happy to maintain one
> on secretlab.
I think broadening it beyond power.org is good. Along those lines I'd pref=
er
not having this on kernel.org, as device trees are not Linux-centric. Ther=
e
are other OS vendors I've interacted with that I'd like to see use device t=
rees
and separating it from Linux may be better IMO.
We could also create a new domain like "devicetree.org" (?)..but it still
would nee a host.
Stuart
^ permalink raw reply
* RS6000 /S70
From: gilmar @ 2009-08-28 16:40 UTC (permalink / raw)
To: linuxppc-dev
> Hi ,
>
> I need help to compile a Kernel
> how to compile kernel?
where I can find the parameters necessary
to compile a Kernel for a mainframe IBM rs 6000/s70 (processor powerpc rs64)?
which the archives necessary to create
a boot disk ?
^ permalink raw reply
* MPC866 FEC's Receive processing thru pre allocated buffers
From: Ganesh Kumar @ 2009-08-28 6:20 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
I'm working on MPC860 with Linux Kernel 2.4.18.
As I'm fine tuning the FEC(Fast Ethernet Controller) driver,
I came across the receive side processing of the ethernet frames
where in the Rx BD rings are preallocated with the buffers and each time
a new frame is received, the whole frame will get copied from the Buffer
Descriptors to the external memory by allocating the skb.
Is this the right way to do that ?, as memcpy is not efficient inside the
ISRs.
So I did some changes in the RX BDs initialization, like allocate the skb
and initialize the BD's address pointer with the skb->data(using __pa)
and then on reception of the frame I take out the skb from theBD and allocate
a new skb and reinit the BD address with the newly allocated skb->data.
It works for normal conditions, but if I load the driver then
I receive lots of corrupted frames, So I tried increasing the RX_RING_SIZE(16)
and also enabling the receive dscriptor active only after I come out of the
while loop (inside fec_enet_rx)
Increasing the Rx ring eliminated the frame corruption and runs fine on load
test.
But if I configure my Linux box in bridge mode then it doesn't work,
i.e., the bridging doesn't happen,
PC-1 ---->eth0 [Bridge machine] eth1 ----> PC-2
What I mean here is if we initiate a ping from the
PC-1 to PC-2, I don't get any response,
it continously try to resole the ARP.
What may be the reason??
Thanks in advance
Please do CC to me as I'm not subscribed to this list.
--GK
^ permalink raw reply
* Re: [ewg] [PATCH] IB/ehca: Construct MAD redirect replies from request MAD
From: Roland Dreier @ 2009-08-28 16:28 UTC (permalink / raw)
To: Joachim Fenkes
Cc: Hal Rosenstock, OF-EWG, LKML, Jason Gunthorpe, LinuxPPC-Dev,
Christoph Raisch, OF-General, Stefan Roscher, Hal Rosenstock
In-Reply-To: <OFA25F14CC.CE7042E9-ONC1257620.00453C46-C1257620.00474D70@de.ibm.com>
> Given that you seem to like the rest of the code and Jason hasn't spoken
> up yet, I think we can have Roland merge this patch. Roland, what do you
> think?
I don't see any problem with the idea and this does sound like a step
forward, so I am planning on merging this (pending review).
^ permalink raw reply
* Re: [RFC] Clock binding
From: Grant Likely @ 2009-08-28 16:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, devicetree-discuss
In-Reply-To: <1250569288.19007.15.camel@pasglop>
On Mon, Aug 17, 2009 at 10:21 PM, Benjamin
Herrenschmidt<benh@kernel.crashing.org> wrote:
> However, it's a bit nasty to mix strings and numbers (phandles) in a
> single property. It's possible, but would likely lead to the phandle not
> being aligned and tools such as lsprop to fail miserably to display
> those properties in any kind of readable form.
[...]
> However, I really dislike that numerical clock ID. Magic numbers suck.
> It should be a string.
Agreed.
> Hence my idea below. It's not perfect but it's the less sucky i've come
> up with so far. And then we can do some small refinements.
>
> =A0 =A0 =A0 =A0* Device has:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- "clock-input-names" as above
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- "clock-map" contains list of phandle,ind=
ex
>
> =A0 =A0 =A0 =A0* Clock source has:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- "clock-output-names" list of strings
The big problem as you say is the referencing of both phandles and
strings in the same property, but it's not particularly pretty to
disperse the data across multiple properties. Changes to the two
properties must be kept in sync, and if order changes in one and not
the other then badness occurs... Actually, I don't *dislike* you're
proposed binding, but in the interest of generating and endless
goodness argument, what about the following?
As above, clock source has:
- "clock-output-names" list of strings. All possible inputs
must be in this list in the interest of clarity and sanity checking,
but drivers must not depend on the order of the list. Drivers must
always resolve clocks by name.
Clock consumer has:
- "clock-inputs" property. Array of string 'tuples' in the
form: "input-name","clock-source-path","output-name".
This sidesteps the phandle issue by using the path string instead.
It's not as efficient space wise, but (at least when using dtc) the
syntax stays pretty sane, and the output remains mere-mortal parsable:
ie: clock-inputs =3D "sysclk", &clocksource, "clkout_orange";
> The "index" in the clock map thus would reference the
> "clock-output-names" array in the clock provider. That means that the
> "magic number" here is entirely local to a given device-tree, doesn't
> leak into driver code, which continues using names.
>
> In addition, we can even have some smooth "upgrade" path from existing
> "clock-frequency" properties by assuming that if "clock-output-names" is
> absent, but "clock-frequency" exist, then index 0 references a fixed
> frequency clock source without a driver. This could be generally handy
> anyway to represent crystals of fixed bus clocks without having to write
> a clock source driver for them.
The analog of this could be:
clock-inputs =3D "sysclk", &clocksource, "0";
Otherwise, I think the approach is sound and I agree fully that
referencing names makes sense.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC] Clock binding
From: Grant Likely @ 2009-08-28 16:06 UTC (permalink / raw)
To: Stuart Yoder; +Cc: devicetree-discuss, linuxppc-dev list
In-Reply-To: <955e48b80908280516m457530cfn3b07b52f2fa2c471@mail.gmail.com>
On Fri, Aug 28, 2009 at 6:16 AM, Stuart Yoder<stuyoder@gmail.com> wrote:
> On Thu, Aug 27, 2009 at 9:43 PM, Benjamin
> Herrenschmidt<benh@kernel.crashing.org> wrote:
>> On Thu, 2009-08-27 at 16:36 -1000, Mitch Bradley wrote:
>>> The idea of a wiki as a registration authority is a good one, but I'm
>>> not volunteering to maintain it :-)
>>
>> here goes my hope :-)
>>
>> Do we have wiki's we could use on power.org or should we aim for a
>> community place ? Anybody has suggestions ? I wouldn't even try to
>> maintain a web site myself, that would be irresponsible of anybody to
>> let me do so !
>
> There was an ePAPR wiki on power.org, that I had started developing,
> but it seems to have disappeared. =A0I'm looking into what happened.
Lets *not* do it on power.org. I'd like to see the bindings used by
more than just powerpc people, and power.org might become a bit of a
mental barrier for non-powerpc folks. kernel.org would be a good
host. So would ozlabs or infradead. Or I'd be happy to maintain one
on secretlab.
What about openfirmware.info? I don't know anything about Core
Systems who maintains that site though.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH v2] powerpc/85xx: Add eSDHC support for MPC8536DS boards
From: Anton Vorontsov @ 2009-08-28 15:19 UTC (permalink / raw)
To: Hu Mingkai-B21284
Cc: Ben Dooks, linux-kernel, sdhci-devel, linuxppc-dev, Andrew Morton,
Pierre Ossman, David Vrabel
In-Reply-To: <73839B4A0818E747864426270AC332C304438438@zmy16exm20.fsl.freescale.net>
On Fri, Aug 28, 2009 at 07:02:51PM +0800, Hu Mingkai-B21284 wrote:
> > On Tue, Aug 18, 2009 at 08:24:17PM -0500, Kumar Gala wrote:
> > >
> > > On Aug 18, 2009, at 6:38 PM, Anton Vorontsov wrote:
> > >
> > > >This patch simply adds sdhci node to the device tree.
> > > >
> > > >We specify clock-frequency manually, so that eSDHC will
> > work without
> > > >upgrading U-Boot. Though, that'll only work for default setup (1500
> > > >MHz) on new board revisions. For non-default setups, it's
> > recommended
> > > >to upgrade U-Boot, since it will fixup clock-frequency
> > automatically.
> > > >
> > > >Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > >
> > > out of interest the 85xx eSDHC don't need the sdhci,wp-inverted
> > > property?
> >
> > Yes, eSDHC controllers in MPC85xx report normal state in its
> > registers.
> >
>
> Hi Anton,
>
> The eSDHC controller in different silicon version on MPC8536 reports
> different WP state in the register PRSSTAT:
Thanks a million for the heads up!
Yes, the manual I used ("MPC8536ERM Rev. 0 10/2008") doesn't mention
that, but the newer manual that I just downloaded ("MPC8536ERM Rev. 1
05/2009") does.
[...]
> For silicon 1.0, the macro SDHCI_QUIRK_INVERTED_WRITE_PROTECT is also
> defined,
> so the dirver will report the error WP state in function sdhci_get_ro.
Not any longer. We don't actually define it for any 85xx CPUs.
I need to think how should we handle all these WP inversions. :-)
So, we have inversion in BCSR (depending on the BCSR revision),
configurable inversion in CPU via GENCFGR for 1.1 silicon, and
non-configurable non-inverted reporting for 1.0 silicon...
Do you know if there are any plans to fix the WP inversion for
MPC8569E-MDS boards, or make something like GENCFGR for MPC8569
CPUs?
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 4/5] powerpc/85xx: Add suspend/resume support
From: Anton Vorontsov @ 2009-08-28 15:15 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Timur Tabi
In-Reply-To: <28CAE6C1-8A32-4482-B606-6A22EE5BA5A9@kernel.crashing.org>
On Fri, Aug 28, 2009 at 12:38:51AM -0500, Kumar Gala wrote:
>
> On Aug 27, 2009, at 12:30 PM, Anton Vorontsov wrote:
>
> >This patch adds suspend/resume support for MPC8540-compatible and
> >MPC8569 CPUs.
> >
> >MPC8540-compatible PMCs are trivial: we just write SLP bit into PM
> >control and status register.
> >
> >MPC8569 is a bit trickier, QE turns off during suspend and so on
> >resume we must reload QE microcode firmware and reset QE.
> >
> >So far we don't support Deep Sleep mode as found in newer MPC85xx
> >CPUs (i.e. MPC8536). It can be relatively easy implemented though,
> >and for it we reserve 'mem' suspend type.
> >
> >Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> >---
> >arch/powerpc/Kconfig | 2 +-
> >arch/powerpc/platforms/85xx/Makefile | 1 +
> >arch/powerpc/platforms/85xx/suspend.c | 115
> >+++++++++++++++++++++++++++++++++
> >3 files changed, 117 insertions(+), 1 deletions(-)
> >create mode 100644 arch/powerpc/platforms/85xx/suspend.c
>
> How did you test this?
--- Prerequisites:
1. Following patches should be applied in addition:
rtc: Set wakeup capability for I2C and SPI RTC drivers
[5/5] ucc_geth: Implement suspend/resume and Wake-On-LAN support
[4/5] ucc_geth: Remove UGETH_MAGIC_PACKET Kconfig symbol and code
[3/5] ucc_geth: Factor out MAC initialization steps into a call
[2/5] powerpc/qe: Implement qe_alive_during_sleep() helper function
[1/5] ucc_geth: Fix NULL pointer dereference in uec_get_ethtool_stats()
2. QE microcode should be placed into /lib/firmware/, i.e.
wget http://opensource.freescale.com/firmware/fsl_qe_ucode_8569_10.zip
unzip fsl_qe_ucode_8569_10.zip
cp fsl_qe_ucode_8569_10.bin /<nfsroot>/lib/firmware/fsl_qe_ucode_8569.bin
--- Wakeup on RTC alarm:
# cd /sys/class/rtc/rtc0/
# echo $(( `cat since_epoch` + 10 )) > wakealarm
# echo standby > /sys/power/state
mpc85xx-pmc e00e0080.power: firmware: requesting fsl_qe_ucode_8569.bin
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.02 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
The board is now suspended, CPU asserted ASLEEP signal that is
reflected by the ASLEEP LED on the board (the LED is near UEC2
port). 10 seconds later the board will wakeup:
qe-firmware: firmware 'MPC8569 QE Microcode Rel_B6900155' for 8569 V1.0
qe-firmware: uploading microcode 'MPC8569 QE Microcode Rel_B69001' version 1.0.0
pci 0000:00:00.0: enabling device (0106 -> 0107)
Restarting tasks ... done.
PHY: mdio@e0082120:07 - Link is Up - 100/Full
--- Wakeup on PHY/link changes (no magic packet support in MPC8569, as
QE turns off during sleep):
# ethtool -s eth0 wol p
# echo standby > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
To wakeup, trigger the PHY interrupt (e.g. pull out the ethernet
cable from eth0):
qe-firmware: firmware 'MPC8569 QE Microcode Rel_B6900155' for 8569 V1.0
qe-firmware: uploading microcode 'MPC8569 QE Microcode Rel_B69001' version 1.0.0
pci 0000:00:00.0: enabling device (0106 -> 0107)
Restarting tasks ... done.
UCC magic packet detection was tested on MPC8360E-MDS boards
(ethtool -s eth0 wol g), I'll send power management support
patches for 83xx QE boards soon.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 2/5] powerpc/qe: Make qe_reset() code path safe for repeated invocation
From: Anton Vorontsov @ 2009-08-28 15:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev, Timur Tabi
In-Reply-To: <A4A4F2A7-4F4C-48A9-A598-6BFB0982656A@kernel.crashing.org>
On Fri, Aug 28, 2009 at 12:34:50AM -0500, Kumar Gala wrote:
[...]
> >static int qe_sdma_init(void)
> >{
> > struct sdma __iomem *sdma = &qe_immr->sdma;
> >- unsigned long sdma_buf_offset;
> >+ static unsigned long sdma_buf_offset;
> >
> > if (!sdma)
> > return -ENODEV;
> >
> > /* allocate 2 internal temporary buffers (512 bytes size each) for
> > * the SDMA */
> >- sdma_buf_offset = qe_muram_alloc(512 * 2, 4096);
> >- if (IS_ERR_VALUE(sdma_buf_offset))
> >- return -ENOMEM;
> >+ if (!sdma_buf_offset) {
> >+ sdma_buf_offset = qe_muram_alloc(512 * 2, 4096);
> >+ if (IS_ERR_VALUE(sdma_buf_offset))
>
> shouldn't we zero out sdma_buf_offset otherwise if we call this
> again we'll think its set.
Technically, no. If qe_sdma_init() fails, kernel will panic:
void __init qe_reset(void)
{
...
if (qe_sdma_init())
panic("sdma init failed!");
}
But I see your point, it isn't obvious and may lead to a bug if
we'll decide to not panic later on. Therefore I'd better make the
change.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: LITE5200 configuration
From: Grant Likely @ 2009-08-28 14:10 UTC (permalink / raw)
To: FIXED-TERM Seeh Thomas (BEG/EMS1)
Cc: linuxppc-dev@lists.ozlabs.org, Wolfgang Denk
In-Reply-To: <6E9D235B18CE694399D781F05D9C42E79F0C2F04@SI-MBX11.de.bosch.com>
On Thu, Aug 27, 2009 at 8:14 AM, FIXED-TERM Seeh Thomas
(BEG/EMS1)<fixed-term.Thomas.Seeh@de.bosch.com> wrote:
> ------snip---------
> [ 2346.499181] VFS: Mounted root (nfs filesystem) on device 0:11.
> [ 2346.505748] Freeing unused kernel memory: 160k init
> [ 2346.865420] net eth0: FEC_IEVENT_RFIFO_ERROR
> [ 2346.871668] ------------[ cut here ]------------
> [ 2346.876434] Kernel BUG at c01ae1d0 [verbose debug info unavailable]
[...]
> Anyone an idea, what I do wrong?
Looks like an Ethernet driver problem which has been seen before. Try
the following patch. Also, you should enable CONFIG_KALLSYMS so that
your traceback actually shows function names.
Cheers,
g.
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index cc78633..6d1afb6 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -758,12 +758,6 @@ static void mpc52xx_fec_reset(struct net_device *dev)
mpc52xx_fec_hw_init(dev);
- if (priv->phydev) {
- phy_stop(priv->phydev);
- phy_write(priv->phydev, MII_BMCR, BMCR_RESET);
- phy_start(priv->phydev);
- }
-
bcom_fec_rx_reset(priv->rx_dmatsk);
bcom_fec_tx_reset(priv->tx_dmatsk);
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply related
* Re: [ewg] [PATCH] IB/ehca: Construct MAD redirect replies from request MAD
From: Joachim Fenkes @ 2009-08-28 12:58 UTC (permalink / raw)
To: Hal Rosenstock
Cc: Hal Rosenstock, OF-EWG, LKML, Jason Gunthorpe, LinuxPPC-Dev,
Christoph Raisch, OF-General, Stefan Roscher
In-Reply-To: <f0e08f230908270631j3e159f3fgb0034eb41acdac7b@mail.gmail.com>
Hal Rosenstock <hal.rosenstock@gmail.com> wrote on 27.08.2009 15:31:40:
> I don't think it should be hard coded. IMO it would be better to default
to 18
> and somehow able to be adjusted (via a (dynamic) module parameter ?).
I don't see how making this a parameter would benefit any end user, while
on the other hand it clutters up our parameter list.
Changing RespTimeValue won't influence the IB performance or user-visible
behavior of our driver in any way, and in fact, all RespTimeValue says is
"Please use a timeout of one second for all future MADs you send me", only
there won't be any more MADs in the future because we just redirected the
client to someone else. So, the RespTimeValue field is a don't care in the
redirection scenario. Setting it to an arbitrary, but legal value isn't
much more than a concession towards any broken clients that may be out
there.
Given that you seem to like the rest of the code and Jason hasn't spoken
up yet, I think we can have Roland merge this patch. Roland, what do you
think?
Regards,
Joachim
^ permalink raw reply
* Re: [RFC] Clock binding
From: Stuart Yoder @ 2009-08-28 12:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, devicetree-discuss
In-Reply-To: <1251427388.20467.122.camel@pasglop>
On Thu, Aug 27, 2009 at 9:43 PM, Benjamin
Herrenschmidt<benh@kernel.crashing.org> wrote:
> On Thu, 2009-08-27 at 16:36 -1000, Mitch Bradley wrote:
>> The idea of a wiki as a registration authority is a good one, but I'm
>> not volunteering to maintain it :-)
>
> here goes my hope :-)
>
> Do we have wiki's we could use on power.org or should we aim for a
> community place ? Anybody has suggestions ? I wouldn't even try to
> maintain a web site myself, that would be irresponsible of anybody to
> let me do so !
There was an ePAPR wiki on power.org, that I had started developing,
but it seems to have disappeared. I'm looking into what happened.
Stuart
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox