* Re: Warp patches for 2.6.26
From: Josh Boyer @ 2008-04-13 0:50 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Sean MacLennan, linuxppc-dev
In-Reply-To: <20080413104430.c98244d2.sfr@canb.auug.org.au>
On Sun, 2008-04-13 at 10:44 +1000, Stephen Rothwell wrote:
> Hi Sean,
>
> First comment is that you need reasonable changelogs i.e. explain why you
> are making changes as well as what they do. Also the first line of each
> changelog (which becomes the subject of any mail generated from git)
> should be a useful and relatively unique summary.
Yes, what Stephen said.
josh
^ permalink raw reply
* Re: Warp patches for 2.6.26
From: Paul Mackerras @ 2008-04-13 1:11 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080412134831.424480cf@lappy.seanm.ca>
Sean MacLennan writes:
> I was going to hold off until the warp was officially released, but we
> might miss the merge window. So here they are. A lot of work has been
> done since 2.6.25 and I haven't been submitting patches to keep down on
> the churn.
<cracked record>
Your patches don't have any description at all. If they are to go in
they need a decent description of what they do and why they do it they
way they do. Putting stuff in a patch 0/5 doesn't really help since
that doesn't go into the git repository.
</cracked record>
Paul.
^ permalink raw reply
* Re: [PATCH] tg3: fix MMIO for PPC 44x platforms
From: David Miller @ 2008-04-13 1:31 UTC (permalink / raw)
To: sshtylyov; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <200804122101.22438.sshtylyov@ru.mvista.com>
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Date: Sat, 12 Apr 2008 21:01:22 +0400
> The driver stores the PCI resource addresses into 'unsigned long' variable
> before calling ioremap_nocache() on them. This warrants kernel oops when the
> registers are accessed on PPC 44x platforms which (being 32-bit) have PCI
> memory space mapped beyond 4 GB.
>
> The arch/ppc/ kernel has a fixup in ioremap() that creates an illusion that
> the PCI memory resource is mapped below 4 GB, but arch/powerpc/ code got rid
> of this trick, having instead CONFIG_RESOURCES_64BIT enabled.
>
> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Applied, thanks.
I added a bump of the driver version and release date for
the changeset.
^ permalink raw reply
* Re: Warp patches for 2.6.26
From: Sean MacLennan @ 2008-04-13 1:55 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20080413104430.c98244d2.sfr@canb.auug.org.au>
On Sun, 13 Apr 2008 10:44:30 +1000
"Stephen Rothwell" <sfr@canb.auug.org.au> wrote:
> Hi Sean,
>
> First comment is that you need reasonable changelogs i.e. explain why
> you are making changes as well as what they do. Also the first line
> of each changelog (which becomes the subject of any mail generated
> from git) should be a useful and relatively unique summary.
>
These patches are an amalgamation of a lot of commits. For
example, warp.c was changed 15 times since I last sent a patch to
linuxppc-dev. warp-nand.c was probably changed even more as we kept
shifting the design.
One of the advantages of an FPGA based design is you can work around a
lot of hardware problems. A disadvantage is that it is easy to change,
so it changes a lot. And the HW guys push the specs out to after they
actually get the feature going. There is no SW input into the FPGA
design.
So these patches are basically following the changes to the FPGA and
changes to the hardware. As new functionality was added, I updated the
code.
Is there a particular way I should word this to make it a changelog?
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH 1/5] Boot code
From: Sean MacLennan @ 2008-04-13 2:06 UTC (permalink / raw)
To: jwboyer; +Cc: linuxppc-dev
In-Reply-To: <1208047783.5869.35.camel@vader.jdub.homelinux.org>
On Sat, 12 Apr 2008 19:49:43 -0500
Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> On Sat, 2008-04-12 at 14:01 -0400, Sean MacLennan wrote:
> > Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
> >
>
> This patch is word wrapped.
Yes, sorry about that. I have been trying out a new mail client and I
pasted the text wrong :( I caught it in the other patches though,
so they should be good.
> > + char name[40];
> > + u32 v[2];
> > +
> > + sprintf(name, "/plb/opb/ebc/nor_flash@0,0/partition@%x",
> > from);
>
> Unless I can't count (which could very well be the case), you have a
> buffer overflow here. The fixed string is 37 characters, and the
> values you are passing in for "from" will extend the string past the
> 40 bytes you have allocated for "name".
No, you are right. Good catch. I will update that.
Cheers,
Sean
^ permalink raw reply
* Re: Warp patches for 2.6.26
From: Grant Likely @ 2008-04-13 2:09 UTC (permalink / raw)
To: Sean MacLennan; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <20080412215544.38fa2d0b@lappy.seanm.ca>
On Sat, Apr 12, 2008 at 7:55 PM, Sean MacLennan <seanm@seanm.ca> wrote:
> On Sun, 13 Apr 2008 10:44:30 +1000
> "Stephen Rothwell" <sfr@canb.auug.org.au> wrote:
>
> > Hi Sean,
> >
> > First comment is that you need reasonable changelogs i.e. explain why
> > you are making changes as well as what they do. Also the first line
> > of each changelog (which becomes the subject of any mail generated
> > from git) should be a useful and relatively unique summary.
> >
>
> These patches are an amalgamation of a lot of commits. For
> example, warp.c was changed 15 times since I last sent a patch to
> linuxppc-dev. warp-nand.c was probably changed even more as we kept
> shifting the design.
>
> One of the advantages of an FPGA based design is you can work around a
> lot of hardware problems. A disadvantage is that it is easy to change,
> so it changes a lot. And the HW guys push the specs out to after they
> actually get the feature going. There is no SW input into the FPGA
> design.
>
> So these patches are basically following the changes to the FPGA and
> changes to the hardware. As new functionality was added, I updated the
> code.
>
> Is there a particular way I should word this to make it a changelog?
You can still describe what the code changes; either by itemizing all
the changes; or if it now appears to be a whole new thing, but
describing what it does /now/. :-)
A changelog of "updates a bunch of stuff" is pretty much irrelevant in
all situations I can think of.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Warp patches for 2.6.26
From: Josh Boyer @ 2008-04-13 2:24 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080412134831.424480cf@lappy.seanm.ca>
On Sat, 2008-04-12 at 13:48 -0400, Sean MacLennan wrote:
> I was going to hold off until the warp was officially released, but we
> might miss the merge window. So here they are. A lot of work has been
> done since 2.6.25 and I haven't been submitting patches to keep down on
> the churn.
That's fair enough. And from what I can tell, your patches are fairly
localized to your platform. So once they get some initial review and
fixing, I don't foresee having too much trouble getting them merged.
One thing to keep in mind though, is that the closer we get to the merge
window, the tighter I get on what new stuff I'll bring in for the next
release. This may seem counter-intuitive, but I like to have the merge
window really be for testing out and fixing any issues that pop up
during the merge of all the various subsystem trees. You'll also want
to add in some lead time for patch review, etc.
That's a long winded way of saying "release early, release often" I
suppose :).
josh
^ permalink raw reply
* Re: Warp patches for 2.6.26
From: Sean MacLennan @ 2008-04-13 2:38 UTC (permalink / raw)
To: Grant Likely; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <fa686aa40804121909s4ee04731ua63afa76fe088828@mail.gmail.com>
> A changelog of "updates a bunch of stuff" is pretty much irrelevant in
> all situations I can think of.
Ok, I hope I got everything:
Changes to match new FPGA/HW functionality.
* Switched from 64M NOR/64M NAND to 4M NOR/256M NAND.
* Moved/resized partitions to match the flash changes.
* Fixup code added for Rev A boards to handle flash changes.
* Added DTM critical temperature.
* Added DTM fan error - currently disable in FPGA.
* Added POST information.
* Removed LED function, moved to new LED driver.
* Moved ad7414 to new style I2C initialization.
Cheers,
Sean
^ permalink raw reply
* Re: Warp patches for 2.6.26
From: Dale Farnsworth @ 2008-04-13 3:13 UTC (permalink / raw)
To: seanm; +Cc: linuxppc-dev
In-Reply-To: <20080412223833.27ca5f23@lappy.seanm.ca>
In article <20080412223833.27ca5f23@lappy.seanm.ca> you write:
>
> > A changelog of "updates a bunch of stuff" is pretty much irrelevant in
> > all situations I can think of.
>
> Ok, I hope I got everything:
>
> Changes to match new FPGA/HW functionality.
> * Switched from 64M NOR/64M NAND to 4M NOR/256M NAND.
> * Moved/resized partitions to match the flash changes.
> * Fixup code added for Rev A boards to handle flash changes.
> * Added DTM critical temperature.
> * Added DTM fan error - currently disable in FPGA.
> * Added POST information.
> * Removed LED function, moved to new LED driver.
> * Moved ad7414 to new style I2C initialization.
Each patch needs to be standalone. you need to add a header describing
what the patch is intended to accomplish. Being more descriptive is
better than less. Also, as Stephen said, make sure that the subject
of each email containing a patch is descriptive and reasonably unique
within the entire kernel. For example, instead of "WDT driver", as a
minimum something like: "[POWERPC] warp: Add WDT driver".
-Dale
^ permalink raw reply
* Re: PATCH 2/5] Platform code
From: Sean MacLennan @ 2008-04-13 3:15 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080412140325.69e1df3b@lappy.seanm.ca>
Here is the complete warp.c. It is probably easier to read this then
the patch.
Cheers,
Sean
/*
* PIKA Warp(tm) board specific routines
*
* Copyright (c) 2008 PIKA Technologies
* Sean MacLennan <smaclennan at pikatech.com>
*
* 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 <linux/init.h>
#include <linux/of_platform.h>
#include <linux/kthread.h>
#include <linux/i2c.h>
#include <linux/interrupt.h>
#include <linux/pika.h>
#include <asm/machdep.h>
#include <asm/prom.h>
#include <asm/udbg.h>
#include <asm/time.h>
#include <asm/uic.h>
#include "44x.h"
static __initdata struct of_device_id warp_of_bus[] = {
{ .compatible = "ibm,plb4", },
{ .compatible = "ibm,opb", },
{ .compatible = "ibm,ebc", },
{},
};
static __initdata struct i2c_board_info warp_i2c_info[] = {
{ I2C_BOARD_INFO("ad7414", 0x4a) }
};
static int __init warp_arch_init(void)
{
/* This should go away once support is moved to the dts. */
i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
return 0;
}
machine_arch_initcall(warp, warp_arch_init);
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();
return of_flat_dt_is_compatible(root, "pika,warp");
}
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,
};
/* I am not sure this is the best place for this... */
static int __init warp_post_info(void)
{
struct device_node *np;
void __iomem *fpga;
u32 post1, post2;
/* Sighhhh... POST information is in the sd area. */
np = of_find_compatible_node(NULL, NULL, "pika,fpga-sd");
if (np == NULL)
return -ENOENT;
fpga = of_iomap(np, 0);
of_node_put(np);
if (fpga == NULL)
return -ENOENT;
post1 = in_be32(fpga + 0x40);
post2 = in_be32(fpga + 0x44);
iounmap(fpga);
if (post1 || post2)
printk(KERN_INFO "Warp POST %08x %08x\n", post1, post2);
else
printk(KERN_INFO "Warp POST OK\n");
return 0;
}
machine_late_initcall(warp, warp_post_info);
#ifdef CONFIG_SENSORS_AD7414
static LIST_HEAD(dtm_shutdown_list);
static void __iomem *dtm_fpga;
struct dtm_shutdown {
struct list_head list;
void (*func)(void *arg);
void *arg;
};
int dtm_register_shutdown(void (*func)(void *arg), void *arg)
{
struct dtm_shutdown *shutdown;
shutdown = kmalloc(sizeof(struct dtm_shutdown), GFP_KERNEL);
if (shutdown == NULL)
return -ENOMEM;
shutdown->func = func;
shutdown->arg = arg;
list_add(&shutdown->list, &dtm_shutdown_list);
return 0;
}
EXPORT_SYMBOL(dtm_register_shutdown);
int dtm_unregister_shutdown(void (*func)(void *arg), void *arg)
{
struct dtm_shutdown *shutdown;
list_for_each_entry(shutdown, &dtm_shutdown_list, list)
if (shutdown->func == func && shutdown->arg == arg) {
list_del(&shutdown->list);
kfree(shutdown);
return 0;
}
return -EINVAL;
}
EXPORT_SYMBOL(dtm_unregister_shutdown);
static long wdt_keepalive(long time)
{
if (dtm_fpga) {
unsigned reset = in_be32(dtm_fpga + 0x14);
out_be32(dtm_fpga + 0x14, reset);
}
return 0;
}
static irqreturn_t temp_isr(int irq, void *context)
{
struct dtm_shutdown *shutdown;
/* Run through the shutdown list. */
list_for_each_entry(shutdown, &dtm_shutdown_list, list)
shutdown->func(shutdown->arg);
panic_timeout = 1800;
panic_blink = wdt_keepalive;
panic("Critical Temperature Shutdown");
return IRQ_HANDLED;
}
static void pika_setup_critical_temp(struct i2c_client *client)
{
struct device_node *np;
int irq, rc;
/* These registers are in 1 degree increments. */
i2c_smbus_write_byte_data(client, 2, 55); /* Thigh */
i2c_smbus_write_byte_data(client, 3, 50); /* Tlow */
np = of_find_compatible_node(NULL, NULL, "adi,ad7414");
if (np == NULL) {
printk(KERN_ERR __FILE__ ": Unable to find ad7414\n");
return;
}
irq = irq_of_parse_and_map(np, 0);
of_node_put(np);
if (irq == NO_IRQ) {
printk(KERN_ERR __FILE__ ": Unable to get ad7414 irq\n");
return;
}
rc = request_irq(irq, temp_isr, 0, "ad7414", NULL);
if (rc) {
printk(KERN_ERR __FILE__
": Unable to request ad7414 irq %d = %d\n", irq, rc);
return;
}
}
static inline void pika_dtm_check_fan(void __iomem *fpga)
{
static int fan_state;
u32 fan = in_be32(fpga + 0x34) & (1 << 14);
if (fan_state != fan) {
fan_state = fan;
if (fan)
printk(KERN_WARNING "Fan rotation error detected."
" Please check hardware.\n");
}
}
static int pika_dtm_thread(void __iomem *fpga)
{
struct i2c_adapter *adap;
struct i2c_client *client;
/* We loop in case either driver was compiled as a module and
* has not been insmoded yet.
*/
while (!(adap = i2c_get_adapter(0))) {
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(HZ);
}
while (1) {
list_for_each_entry(client, &adap->clients, list)
if (client->addr == 0x4a)
goto found_it;
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(HZ);
}
found_it:
i2c_put_adapter(adap);
pika_setup_critical_temp(client);
printk(KERN_INFO "PIKA DTM thread running.\n");
while (!kthread_should_stop()) {
u16 temp = swab16(i2c_smbus_read_word_data(client, 0));
out_be32(fpga + 0x20, temp);
pika_dtm_check_fan(fpga);
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(HZ);
}
return 0;
}
static int __init pika_dtm_start(void)
{
struct task_struct *dtm_thread;
struct device_node *np;
np = of_find_compatible_node(NULL, NULL, "pika,fpga");
if (np == NULL)
return -ENOENT;
dtm_fpga = of_iomap(np, 0);
of_node_put(np);
if (dtm_fpga == NULL)
return -ENOENT;
dtm_thread = kthread_run(pika_dtm_thread, dtm_fpga, "pika-dtm");
if (IS_ERR(dtm_thread)) {
iounmap(dtm_fpga);
return PTR_ERR(dtm_thread);
}
return 0;
}
machine_late_initcall(warp, pika_dtm_start);
#endif
^ permalink raw reply
* Re: [PATCH 4/5] LED driver
From: Peter Korsgaard @ 2008-04-13 12:28 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080412141039.25e14fae@lappy.seanm.ca>
>>>>> "Sean" == Sean MacLennan <smaclennan@pikatech.com> writes:
Hi,
Sean> Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
Sean> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
Sean> index 859814f..31e1746 100644
Sean> --- a/drivers/leds/Kconfig
Sean> +++ b/drivers/leds/Kconfig
Sean> @@ -145,6 +145,12 @@ config LEDS_CLEVO_MAIL
Sean> To compile this driver as a module, choose M here: the
Sean> module will be called leds-clevo-mail.
Sean> +config LEDS_WARP
Sean> + tristate "LED Support for the PIKA Warp LEDs"
Sean> + depends on LEDS_CLASS && WARP
Sean> + help
Sean> + This option enables support for the PIKA Warp LEDs.
Sean> +
Sean> comment "LED Triggers"
How about getting gpiolib working and use leds-gpio.c instead?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [LMB][1/2] Fix some whitespace and other formatting issues, use pr_debug
From: Paul Mackerras @ 2008-04-13 12:31 UTC (permalink / raw)
To: Nick Andrew; +Cc: linuxppc-dev, linux-kernel, davem
In-Reply-To: <20080412162940.GB29599@tull.net>
Nick Andrew writes:
> On Sat, Apr 12, 2008 at 03:20:59PM +1000, Paul Mackerras wrote:
> > + pr_debug("\n reserved.cnt = 0x%lx\n", lmb.reserved.cnt);
>
> This will only output an empty line at KERN_DEBUG level and the rest
> will be at default_message_loglevel. Problem is fixed my my patch in msg
> <20080412161733.24882.30930.stgit@marcab.local.tull.net>
>
> However, is a blank line in the log necessary?
No, and in fact the whole routine is probably not necessary any more.
Paul.
^ permalink raw reply
* Re: [PATCH 1/8] [POWERPC] fsl_elbc_nand: factor out localbus defines
From: David Woodhouse @ 2008-04-13 12:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Wood, linuxppc-dev@ozlabs.org list, linux-mtd
In-Reply-To: <C55A03A1-DDB4-4652-9758-2E78E38343B4@kernel.crashing.org>
On Fri, 2008-04-11 at 09:06 -0500, Kumar Gala wrote:
>
> David, can you ack this. It looks good to me but want a MTD
> maintainer ack before having it go through the powerpc tree.
Looks sane to me.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
--
dwmw2
^ permalink raw reply
* Re: [PATCH 4/5] LED driver
From: Sean MacLennan @ 2008-04-13 16:51 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev
In-Reply-To: <87r6daym53.fsf@macbook.be.48ers.dk>
On Sun, 13 Apr 2008 14:28:24 +0200
Peter Korsgaard <jacmet@sunsite.dk> wrote:
> How about getting gpiolib working and use leds-gpio.c instead?
Actually, I was going to just ask about that... how close is leds-gpio
to being working, and will it be in 2.6.26?
Cheers,
Sean
^ permalink raw reply
* [EFIKA] Really, don't pretend to be CHRP
From: David Woodhouse @ 2008-04-13 16:52 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Fedora 9 works on Efika without the separate 'device-tree supplement',
thanks to the kernel's own fixups. With one exception -- because 'CHRP'
still appears on the 'machine:' line in /proc/cpuinfo, the installer
misdetects the platform and misconfigures yaboot, putting it into a PReP
boot partition instead of in the /boot filesystem where the Efika's
firmware could find it.
The kernel's fixups for Efika already correct one instance of 'chrp', in
the 'device_type' property. This fixes it in the 'CODEGEN,description'
property too, since that's what's exposed to userspace in /proc/cpuinfo.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 5ab4c84..723422e 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -2240,6 +2240,14 @@ static void __init fixup_device_tree_efika(void)
if (rv != PROM_ERROR && (strcmp(prop, "chrp") == 0))
prom_setprop(node, "/", "device_type", "efika", sizeof("efika"));
+ /* CODEGEN,description is exposed in /proc/cpuinfo so
+ fix that too */
+ rv = prom_getprop(node, "CODEGEN,description", prop, sizeof(prop));
+ if (rv != PROM_ERROR && (strstr(prop, "CHRP")))
+ prom_setprop(node, "/", "CODEGEN,description",
+ "Efika 5200B PowerPC System",
+ sizeof("Efika 5200B PowerPC System"));
+
/* Fixup bestcomm interrupts property */
node = call_prom("finddevice", 1, 1, ADDR("/builtin/bestcomm"));
if (PHANDLE_VALID(node)) {
--
dwmw2
^ permalink raw reply related
* Re: [PATCH 4/5] LED driver
From: Peter Korsgaard @ 2008-04-13 17:34 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080413125119.6bb54a29@lappy.seanm.ca>
>>>>> "Sean" == Sean MacLennan <smaclennan@pikatech.com> writes:
>> How about getting gpiolib working and use leds-gpio.c instead?
Sean> Actually, I was going to just ask about that... how close is leds-gpio
Sean> to being working, and will it be in 2.6.26?
I haven't actually used leds-gpio, but it looks so simple that I
cannot imagine it not working. There also seems to be quite some
platforms using it, E.G:
% git grep '"leds-gpio"' arch|wc -l
11
Or are you referring to the status of gpiolib support on powerpc?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 4/5] LED driver
From: Sean MacLennan @ 2008-04-13 17:51 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev
In-Reply-To: <87hce5zmj5.fsf@macbook.be.48ers.dk>
On Sun, 13 Apr 2008 19:34:38 +0200
Peter Korsgaard <jacmet@sunsite.dk> wrote:
> I haven't actually used leds-gpio, but it looks so simple that I
> cannot imagine it not working. There also seems to be quite some
> platforms using it, E.G:
>
> % git grep '"leds-gpio"' arch|wc -l
> 11
>
> Or are you referring to the status of gpiolib support on powerpc?
Correct. It looks like the gpiolib will go in for 2.6.26 but not ppc44x
support. Which means I wouldn't be able to get warp support in for this
release.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
From: Andrew Morton @ 2008-04-14 0:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linux-Arch, linux-m32r, takata, linux-kernel, linuxppc-dev,
Paul Mackerras
In-Reply-To: <20080410032354.90CB1DDF0F@ozlabs.org>
On Thu, 10 Apr 2008 13:22:56 +1000 Benjamin Herrenschmidt <benh@ozlabs.org> wrote:
> Some architecture need to maintain a kmem cache for thread info
> structures. (next patch adds that to powerpc to fix an alignment
> problem).
>
> There is no good arch callback to use to initialize that cache
> that I can find, so this adds a new one and adds an empty macro
> for when it's not implemented.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> So we have the choice here between:
>
> - the ifdef on the func name that I did, consistent with what
> I did before for iomap, which iirc Linus liked
>
> - add some more ARCH_HAS_* or HAVE_* (yuck)
>
> - add an empty definition to all archs .h (pain in the neck but I
> can do it, though it will be an annoying patch to keep around)
>
> - do a weak function (will slightly bloat everybody for no good reason)
>
> So unless there is strong complaints, I'd like to stick to my
> current approach.
>
> include/linux/sched.h | 4 ++++
> init/main.c | 1 +
> 2 files changed, 5 insertions(+)
>
> --- linux-work.orig/init/main.c 2008-04-10 13:11:06.000000000 +1000
> +++ linux-work/init/main.c 2008-04-10 13:11:19.000000000 +1000
> @@ -623,6 +623,7 @@ asmlinkage void __init start_kernel(void
> if (efi_enabled)
> efi_enter_virtual_mode();
> #endif
> + thread_info_cache_init();
> fork_init(num_physpages);
> proc_caches_init();
> buffer_init();
> Index: linux-work/include/linux/sched.h
> ===================================================================
> --- linux-work.orig/include/linux/sched.h 2008-04-10 13:11:44.000000000 +1000
> +++ linux-work/include/linux/sched.h 2008-04-10 13:12:05.000000000 +1000
> @@ -1893,6 +1893,10 @@ static inline unsigned long *end_of_stac
>
> #endif
>
> +#ifndef thread_info_cache_init
> +#define thread_info_cache_init do { } while(0)
> +#endif
This trick does cause a bit of a problem: it is undefined which arch header
file is to provide the alternative definition of thread_info_cache_init.
So we can (and have) ended up in the situation where the override appears
in different files on different architectures and various screwups ensue.
So I'd suggest that we have a bigfatcomment telling implementors which file
the override should be implemented in. And make sure that this arch file is
directly included from within sched.h.
I have a suspicion that we can still get in a mess if .c files include the
per-arch file and don't include sched.h, but I forget where this happened
and why it broke stuff.
Sigh. A nice, coded-in-C implementation within each and every architecture
remains the best implementation, and all the little tricks-to-save-typing
have failure modes.
otoh, if only one .c file will ever call this function then I think that
all problems are solved by
a) moving the above ifdeffery into the .c file
b) adding a comment explaining which arch file must provide the override
c) directly including that file from within the .c file.
^ permalink raw reply
* Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
From: Benjamin Herrenschmidt @ 2008-04-14 0:38 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux-Arch, linux-m32r, takata, linux-kernel, linuxppc-dev,
Paul Mackerras
In-Reply-To: <20080413171953.bde5e9ac.akpm@linux-foundation.org>
> > +#ifndef thread_info_cache_init
> > +#define thread_info_cache_init do { } while(0)
> > +#endif
>
> This trick does cause a bit of a problem: it is undefined which arch header
> file is to provide the alternative definition of thread_info_cache_init.
I this case it's well defined: thread_info.h. Maybe I should add a
comment ?
> So we can (and have) ended up in the situation where the override appears
> in different files on different architectures and various screwups ensue.
Yup.
> So I'd suggest that we have a bigfatcomment telling implementors which file
> the override should be implemented in. And make sure that this arch file is
> directly included from within sched.h.
Will do.
> I have a suspicion that we can still get in a mess if .c files include the
> per-arch file and don't include sched.h, but I forget where this happened
> and why it broke stuff.
In this case, there's only one call site and will only every be one, so
that shouldn't be a problem. I don't see init/main.c not including
sched.h
> Sigh. A nice, coded-in-C implementation within each and every architecture
> remains the best implementation, and all the little tricks-to-save-typing
> have failure modes.
Well, I started doing it in all arch, and people around here told me
that was not a good idea , that it would be trouble if the prototype
ever had to change (adding an arg, etc... though very unlikely to happen
in that case, granted).
> otoh, if only one .c file will ever call this function then I think that
> all problems are solved by
>
> a) moving the above ifdeffery into the .c file
> b) adding a comment explaining which arch file must provide the override
> c) directly including that file from within the .c file.
I can definitely do that. I have no problem either way. I can add to all
archs too, it's just that whatever way I choose, some people won't be
happy with it :-)
Anyway, I'll move the ifdeferry to init/main.c then.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] [POWERPC] remove include of asm/of_device.h from pmi.h
From: Stephen Rothwell @ 2008-04-14 2:00 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: ppc-dev, Christian Krafft
pmi.h does not diectly reference anything in of_device.h and of the two
files that include asm/pmi.h, one includes of_device.h and the other
includes of_platform.h (which includes of_device.h).
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/asm-powerpc/pmi.h | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/pmi.h b/include/asm-powerpc/pmi.h
index 2259d4c..e1dc090 100644
--- a/include/asm-powerpc/pmi.h
+++ b/include/asm-powerpc/pmi.h
@@ -29,8 +29,6 @@
#ifdef __KERNEL__
-#include <asm/of_device.h>
-
#define PMI_TYPE_FREQ_CHANGE 0x01
#define PMI_READ_TYPE 0
#define PMI_READ_DATA0 1
--
1.5.5
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH] [POWERPC] remove include of asm/of_device.h from pmi.h
From: Stephen Rothwell @ 2008-04-14 2:03 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: ppc-dev, Christian Krafft
In-Reply-To: <20080414120047.8144976b.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 575 bytes --]
On Mon, 14 Apr 2008 12:00:47 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> pmi.h does not diectly reference anything in of_device.h and of the two
> files that include asm/pmi.h, one includes of_device.h and the other
> includes of_platform.h (which includes of_device.h).
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
I forgot to say this has been built for ppc64_defconfig and
cell_defconfig (the only two configs that use it).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] [POWEPC] replace asm/of_device.h with linux/of_device.h in macio.h
From: Stephen Rothwell @ 2008-04-14 2:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppc-dev
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
include/asm-powerpc/macio.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-powerpc/macio.h b/include/asm-powerpc/macio.h
index 3a6cb1a..079c06e 100644
--- a/include/asm-powerpc/macio.h
+++ b/include/asm-powerpc/macio.h
@@ -2,7 +2,7 @@
#define __MACIO_ASIC_H__
#ifdef __KERNEL__
-#include <asm/of_device.h>
+#include <linux/of_device.h>
extern struct bus_type macio_bus_type;
--
1.5.5
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH 1/2] Add thread_info_cache_init() to all archs
From: Andrew Morton @ 2008-04-14 2:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linux-Arch, linux-m32r, takata, linux-kernel, linuxppc-dev,
Paul Mackerras
In-Reply-To: <1208133506.6958.82.camel@pasglop>
On Mon, 14 Apr 2008 10:38:26 +1000 Benjamin Herrenschmidt <benh@ozlabs.org> wrote:
> > > +#ifndef thread_info_cache_init
> > > +#define thread_info_cache_init do { } while(0)
> > > +#endif
> >
> > This trick does cause a bit of a problem: it is undefined which arch header
> > file is to provide the alternative definition of thread_info_cache_init.
>
> I this case it's well defined: thread_info.h. Maybe I should add a
> comment ?
>
> > So we can (and have) ended up in the situation where the override appears
> > in different files on different architectures and various screwups ensue.
>
> Yup.
>
> > So I'd suggest that we have a bigfatcomment telling implementors which file
> > the override should be implemented in. And make sure that this arch file is
> > directly included from within sched.h.
>
> Will do.
>
> > I have a suspicion that we can still get in a mess if .c files include the
> > per-arch file and don't include sched.h, but I forget where this happened
> > and why it broke stuff.
>
> In this case, there's only one call site and will only every be one, so
> that shouldn't be a problem. I don't see init/main.c not including
> sched.h
As long as init.c directly includes sched.h, and as long as sched.h
directly includes thread_info.h and as long as all architectures which
provide the override put it in their thread_info.h, and as long as the same
applies to all future .c users, we're good. That's a lot of "as long as"'s ;)
> > Sigh. A nice, coded-in-C implementation within each and every architecture
> > remains the best implementation, and all the little tricks-to-save-typing
> > have failure modes.
>
> Well, I started doing it in all arch, and people around here told me
> that was not a good idea , that it would be trouble if the prototype
> ever had to change (adding an arg, etc... though very unlikely to happen
> in that case, granted).
Bah. Use of grep and basic typing skills: not so hard.
> > otoh, if only one .c file will ever call this function then I think that
> > all problems are solved by
> >
> > a) moving the above ifdeffery into the .c file
> > b) adding a comment explaining which arch file must provide the override
> > c) directly including that file from within the .c file.
>
> I can definitely do that. I have no problem either way. I can add to all
> archs too, it's just that whatever way I choose, some people won't be
> happy with it :-)
>
> Anyway, I'll move the ifdeferry to init/main.c then.
Thanks ;)
I'm still wounded by my recent encounter with set_softirq_pending()
and or_softirq_pending().
^ permalink raw reply
* Re: [EFIKA] Really, don't pretend to be CHRP
From: Grant Likely @ 2008-04-14 2:54 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, paulus
In-Reply-To: <1208105558.3026.137.camel@pmac.infradead.org>
On Sun, Apr 13, 2008 at 10:52 AM, David Woodhouse <dwmw2@infradead.org> wrote:
> Fedora 9 works on Efika without the separate 'device-tree supplement',
> thanks to the kernel's own fixups. With one exception -- because 'CHRP'
> still appears on the 'machine:' line in /proc/cpuinfo, the installer
> misdetects the platform and misconfigures yaboot, putting it into a PReP
> boot partition instead of in the /boot filesystem where the Efika's
> firmware could find it.
>
> The kernel's fixups for Efika already correct one instance of 'chrp', in
> the 'device_type' property. This fixes it in the 'CODEGEN,description'
> property too, since that's what's exposed to userspace in /proc/cpuinfo.
>
> Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Looks good to me. I don't see any reason not to pick this up.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index 5ab4c84..723422e 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -2240,6 +2240,14 @@ static void __init fixup_device_tree_efika(void)
> if (rv != PROM_ERROR && (strcmp(prop, "chrp") == 0))
> prom_setprop(node, "/", "device_type", "efika", sizeof("efika"));
>
> + /* CODEGEN,description is exposed in /proc/cpuinfo so
> + fix that too */
> + rv = prom_getprop(node, "CODEGEN,description", prop, sizeof(prop));
> + if (rv != PROM_ERROR && (strstr(prop, "CHRP")))
> + prom_setprop(node, "/", "CODEGEN,description",
> + "Efika 5200B PowerPC System",
> + sizeof("Efika 5200B PowerPC System"));
> +
> /* Fixup bestcomm interrupts property */
> node = call_prom("finddevice", 1, 1, ADDR("/builtin/bestcomm"));
> if (PHANDLE_VALID(node)) {
>
>
>
> --
> dwmw2
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* XPS_LL_TEMAC works correctly?
From: Mohammad Sadegh Sadri @ 2008-04-14 8:10 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]
Hi all,
Using:
EDK 9.2.02,
Xilinx Linux 2.6.24-rc8-xlnx
XPS_LL_TEMAC version 1.00.b
I bring up the Linux kernel on ML403 -Rev04 board,
LL_TEMAC buffer size 128kbits, and set to use SG DMA
I encounter the following messages when the kernel wants to mount the root file system, as one can see the kernel has mounter the nfs root file system and init is initiated, but after that a Link carrier lost happens and it stops working.
is this behavior natural? ( the PC has attansic gigabit ethernet port with kernel 2.6.24.4 running, nfs works very well in other tests)
thanks
.............
eth0: XLlTemac: speed set to 1000Mb/s
eth0: XLlTemac: Send Threshold = 24, Receive Threshold = 4
eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254
IP-Config: Complete:
device=eth0, addr=10.10.10.11, mask=255.255.255.0, gw=10.10.10.10,
host=10.10.10.11, domain=, nis-domain=(none),
bootserver=10.10.10.10, rootserver=10.10.10.10, rootpath=
Looking up port of RPC 100003/2 on 10.10.10.10
Looking up port of RPC 100005/1 on 10.10.10.10
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 88k init
eth0: XLlTemac: PHY Link carrier lost.
eth0: XLlTemac: speed set to 1000Mb/s
eth0: XLlTemac: PHY Link carrier restored.
( KERNEL STOPS WORKING HERE!!!!!!!!)
_________________________________________________________________
Try Chicktionary, a game that tests how many words you can form from the letters given. Find this and more puzzles at Live Search Games!
http://g.msn.ca/ca55/207
[-- Attachment #2: Type: text/html, Size: 1843 bytes --]
^ 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