* Re: G5 noisier under linux than firmware or OSX
From: Benjamin Herrenschmidt @ 2005-01-17 6:55 UTC (permalink / raw)
To: Jerome Glisse; +Cc: linuxppc-dev list
In-Reply-To: <41DFC28F.1000002@free.fr>
On Sat, 2005-01-08 at 12:22 +0100, Jerome Glisse wrote:
>
> From my memory, there have been some guess on values for
> therm regulation as Apple seems to not give informations or
> source code on that. Thus the values for regulating the fan are not
> the same as OS X.
>
> By the way, i also hear little more noise. The question is : Should
> we lower the speed or stay with this conservative values ? :)
On G5s where thermal control is supported, the values are exactly the
same except for the fan of the slots bay.
Ben.
^ permalink raw reply
* [PATCH] ppc32: Fix pmac kernel build with oprofile
From: Benjamin Herrenschmidt @ 2005-01-17 6:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev list, Linus Torvalds
Hi !
The recent oprofile changes for Motorola e500 broke oprofile for other
CPUs. This patch fixes the build.
Proper support for the G3/G4 PMCs would be interesting, and making sure the basic
interrupt PC sampling still works on CPUs that don't have supported PMCs too...
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/ppc/oprofile/Makefile
===================================================================
--- linux-work.orig/arch/ppc/oprofile/Makefile 2005-01-17 14:07:24.000000000 +1100
+++ linux-work/arch/ppc/oprofile/Makefile 2005-01-17 14:08:51.000000000 +1100
@@ -6,4 +6,9 @@
oprofilefs.o oprofile_stats.o \
timer_int.o )
-oprofile-y := $(DRIVER_OBJS) common.o op_model_fsl_booke.o
+oprofile-y := $(DRIVER_OBJS) common.o
+
+ifeq ($(CONFIG_FSL_BOOKE),y)
+ oprofile-y += op_model_fsl_booke.o
+endif
+
Index: linux-work/arch/ppc/oprofile/common.c
===================================================================
--- linux-work.orig/arch/ppc/oprofile/common.c 2005-01-14 12:01:04.000000000 +1100
+++ linux-work/arch/ppc/oprofile/common.c 2005-01-17 14:30:14.000000000 +1100
@@ -124,7 +124,7 @@
.cpu_type = NULL /* To be filled in below. */
};
-int __init oprofile_arch_init(struct oprofile_operations **ops)
+void __init oprofile_arch_init(struct oprofile_operations *ops)
{
char *name;
int cpu_id = smp_processor_id();
@@ -133,13 +133,13 @@
model = &op_model_fsl_booke;
#else
printk(KERN_ERR "oprofile enabled on unsupported processor!\n");
- return -ENODEV;
+ return;
#endif
name = kmalloc(32, GFP_KERNEL);
if (NULL == name)
- return -ENOMEM;
+ return;
sprintf(name, "ppc/%s", cur_cpu_spec[cpu_id]->cpu_name);
@@ -147,12 +147,10 @@
model->num_counters = cur_cpu_spec[cpu_id]->num_pmcs;
- *ops = &oprof_ppc32_ops;
+ *ops = oprof_ppc32_ops;
printk(KERN_INFO "oprofile: using %s performance monitoring.\n",
oprof_ppc32_ops.cpu_type);
-
- return 0;
}
void oprofile_arch_exit(void)
^ permalink raw reply
* Linux 2.6-10.rc3 8xx - Only 3 characters are printed well in __ init start_kernel() upon kernel booting - why ?
From: Povolotsky, Alexander @ 2005-01-16 19:54 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
> Per kind advise I have got, I have added baud rate to the command =
line (I
> did not have it there before):
>=20
> CONFIG_CMDLINE=3D"console=3DttyCPM0,115200 panic=3D3 root=3D/dev/ram"
>=20
> However, my real current problem (just 3 characters get printed
> correctly during the kernel boot) did not go away.
>=20
> Is there a way to check if the baud rate specified in the .config's
> commandline is indeed in effect for the kernel booting ?
>=20
> Any other reasons/explanation for my "3 character" problem ?
>=20
> -----Original Message-----
> From: Povolotsky, Alexander =20
> Sent: Sunday, January 16, 2005 5:59 AM
> To: 'linuxppc-dev@ozlabs.org'
> Subject: Linux 2.6-10.rc3 8xx kernel booting - how to set
> baud rate for the serial driver ?
>=20
> Hi,
> ...=20
> =20
> My bootloader uses 115200 baud rate for the serial output during
> boot strapping.
>=20
> I have:
> CONFIG_SERIAL_CPM_CONSOLE
> in my .config=20
> ...=20
> I could see some output during the kernel boot -
> I noticed that (only 3) characters (see below) from the linux_banner =
are
> printed
> in __init start_kernel() upon booting . Then a lot of garbage is =
outputted
> and eventually kernel hangs ...
>=20
> after gunzip
> done.
> Now booting the kernel
> =
Lin=FF=FF=FF=FF=FF=FF=FF=FF=C0=FF=FF=FF=FF=FF=FF=FF=FF=C08=C0=FF=FF=FF=FF=
=FF=FF=FF=FF=C0X=C0=FF=FF=FF=FF=FF=FF=FF=FF=C0x=C0=FF=FF=FF=FF=FF=FF=FF=FF=
=C0~=C0=FF=FF=FF=FF=FF=FF=FF=FF=C0=B8=C0=FF=FF=FF=FF=FF=FF=FF
> =FF=C0=D8=C0=FF=FF
> <more garbage>
> <hangs>
>=20
> to prove it I added printk("ALEX\n"); in __init start_kernel() prior =
to
> printk(linux_banner);
>=20
> ...=20
> lock_kernel();
> page_address_init();
> printk("ALEX\n");
> printk(linux_banner);
> setup_arch(&command_line);
> setup_per_cpu_areas();
> ...
>=20
> after gunzip
> done.
> Now booting the kernel
> =
ALE=FF=FF=FF=FF=FF=FF=FF=FF=C0=FF=FF=FF=FF=FF=FF=FF=FF=C08=C0=FF=FF=FF=FF=
=FF=FF=FF=FF=C0X=C0=FF=FF=FF=FF=FF=FF=FF=FF=C0x=C0=FF=FF=FF=FF=FF=FF=FF=FF=
=C0~=C0=FF=FF=FF=FF=FF=FF=FF=FF=C0=B8=C0=FF=FF=FF=FF=FF=FF=FF
> =FF=C0=D8=C0=FF=FF
> <more garbage>
> <hangs>
>=20
> Why would first 3 characters come out right ?
> Any ideas ?
> Thanks,
>=20
^ permalink raw reply
* RE: Linux 2.6-10.rc3 8xx - Only 3 characters are printed well i n __init start_kernel() upon kernel booting - why ?
From: Povolotsky, Alexander @ 2005-01-16 13:57 UTC (permalink / raw)
To: 'linuxppc-dev@ozlabs.org'
Per kind advise I have got, I have added baud rate to the command
line (I did not have it there before):
CONFIG_CMDLINE=3D"console=3DttyCPM0,115200 panic=3D3 root=3D/dev/ram"
However, my real current problem (just 3 characters get
printed correctly during the kernel boot) did not go away.
Is there a way to check if the baud rate specified in the
.config's commandline is indeed in effect for the kernel booting ?
Any other reasons/explanation for my "3 character" problem ?
> -----Original Message-----
> From: Povolotsky, Alexander =20
> Sent: Sunday, January 16, 2005 5:59 AM
> To: 'linuxppc-dev@ozlabs.org'
> Subject: Linux 2.6-10.rc3 8xx kernel booting - how to set
> baud rate for the serial driver ?
>=20
> Hi,
...=20
=20
> My bootloader uses 115200 baud rate for the serial output during
> boot strapping.
>=20
> I have:
> CONFIG_SERIAL_CPM_CONSOLE
> in my .config=20
...=20
I could see some output during the kernel boot -
I noticed that (only 3) characters (see below) from the linux_banner =
are
printed
in __init start_kernel() upon booting . Then a lot of garbage is =
outputted
and eventually kernel hangs ...
after gunzip
done.
Now booting the kernel
Lin=FF=FF=FF=FF=FF=FF=FF=FF=C0=FF=FF=FF=FF=FF=FF=FF=FF=C08=C0=FF=FF=FF=FF=
=FF=FF=FF=FF=C0X=C0=FF=FF=FF=FF=FF=FF=FF=FF=C0x=C0=FF=FF=FF=FF=FF=FF=FF=FF=
=C0~=C0=FF=FF=FF=FF=FF=FF=FF=FF=C0=B8=C0=FF=FF=FF=FF=FF=FF=FF=FF=C0
=D8=C0=FF=FF
<more garbage>
<hangs>
to prove it I added printk("ALEX\n"); in __init start_kernel() prior to
printk(linux_banner);
...=20
lock_kernel();
page_address_init();
printk("ALEX\n");
printk(linux_banner);
setup_arch(&command_line);
setup_per_cpu_areas();
...
after gunzip
done.
Now booting the kernel
ALE=FF=FF=FF=FF=FF=FF=FF=FF=C0=FF=FF=FF=FF=FF=FF=FF=FF=C08=C0=FF=FF=FF=FF=
=FF=FF=FF=FF=C0X=C0=FF=FF=FF=FF=FF=FF=FF=FF=C0x=C0=FF=FF=FF=FF=FF=FF=FF=FF=
=C0~=C0=FF=FF=FF=FF=FF=FF=FF=FF=C0=B8=C0=FF=FF=FF=FF=FF=FF=FF=FF=C0
=D8=C0=FF=FF
<more garbage>
<hangs>
Why would first 3 characters come out right ?
Any ideas ?
Thanks,
^ permalink raw reply
* RE: Linux 2.6-10.rc3 8xx kernel booting - how to set baud rate f or the serial driver ?
From: Povolotsky, Alexander @ 2005-01-16 11:13 UTC (permalink / raw)
To: 'linuxppc-dev@ozlabs.org'
I forgot to mention that my command line in .config is:
CONFIG_CMDLINE="console=ttyCPM0 panic=3 root=/dev/ram"
Could I specify the baud rate (just for kernel booting, not for
bootstrapping) in the command line ?
> -----Original Message-----
> From: Povolotsky, Alexander
> Sent: Sunday, January 16, 2005 5:59 AM
> To: 'linuxppc-dev@ozlabs.org'
> Subject: Linux 2.6-10.rc3 8xx kernel booting - how to set baud rate
> for the serial driver ?
>
> Hi,
>
> My bootloader uses 115200 baud rate for the serial output during boot
> strapping.
>
> Then, during Linux 2.6-10.rc3 8xx kernel booting - how to set certain
> baud rate for the serial driver ?
>
> When init_consoleI( ) is called - at what baud rate the 8xx serial driver
> is getting set ?
>
> Currently I am have:
> CONFIG_SERIAL_CPM_CONSOLE
> in my .config
>
> Is there a way to set (force) the baud rate in the .config (or by other
> means) to be in effect for the kernel booting ?
>
> Thanks,
> Best Regards
^ permalink raw reply
* Linux 2.6-10.rc3 8xx kernel booting - how to set baud rate for t he serial driver ?
From: Povolotsky, Alexander @ 2005-01-16 10:58 UTC (permalink / raw)
To: 'linuxppc-dev@ozlabs.org'
Hi,
My bootloader uses 115200 baud rate for the serial output during boot
strapping.
Then, during Linux 2.6-10.rc3 8xx kernel booting - how to set certain baud
rate for the serial driver ?
When init_consoleI( ) is called - at what baud rate the 8xx serial driver is
getting set ?
Currently I am have:
CONFIG_SERIAL_CPM_CONSOLE
in my .config
Is there a way to set (force) the baud rate in the .config (or by other
means) to be in effect for the kernel booting ?
Thanks,
Best Regards
^ permalink raw reply
* [2.6 patch] (mostly i386) mm cleanup (fwd)
From: Adrian Bunk @ 2005-01-16 2:01 UTC (permalink / raw)
To: Andrew Morton
Cc: jdike, user-mode-linux-devel, Dave Hansen, linux-kernel, dhowells,
linuxppc-dev, paulus
The patch forwarded below (already ACK'ed by David Howells) still
applies and compiles against 2.6.11-rc1-mm1.
Please apply.
----- Forwarded message from Adrian Bunk <bunk@stusta.de> -----
Date: Sun, 12 Dec 2004 03:10:56 +0100
From: Adrian Bunk <bunk@stusta.de>
To: Dave Hansen <haveblue@us.ibm.com>, linux-kernel@vger.kernel.org,
paulus@samba.org, linuxppc-dev@ozlabs.org, jdike@karaya.com,
user-mode-linux-devel@lists.sourceforge.net, dhowells@redhat.com
Subject: [2.6 patch] (mostly i386) mm cleanup
The patch below contains the following fixes:
- arch/i386/mm/boot_ioremap.c: make a variable static
- frv/ppc highmem.c: remove stale kmap_init prototypes
- arch/um/kernel/mem.c: make kmap_init static
- arch/i386/mm/init.c: make five functions static
diffstat output:
arch/i386/mm/boot_ioremap.c | 4 ++--
arch/i386/mm/init.c | 10 +++++-----
arch/um/kernel/mem.c | 2 +-
include/asm-frv/highmem.h | 2 --
include/asm-i386/highmem.h | 2 --
include/asm-ppc/highmem.h | 2 --
6 files changed, 8 insertions(+), 14 deletions(-)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.10-rc2-mm4-full/arch/i386/mm/boot_ioremap.c.old 2004-12-11 23:55:28.000000000 +0100
+++ linux-2.6.10-rc2-mm4-full/arch/i386/mm/boot_ioremap.c 2004-12-11 23:55:49.000000000 +0100
@@ -61,8 +61,8 @@
/* the virtual space we're going to remap comes from this array */
#define BOOT_IOREMAP_PAGES 4
#define BOOT_IOREMAP_SIZE (BOOT_IOREMAP_PAGES*PAGE_SIZE)
-__initdata char boot_ioremap_space[BOOT_IOREMAP_SIZE]
- __attribute__ ((aligned (PAGE_SIZE)));
+static __initdata char boot_ioremap_space[BOOT_IOREMAP_SIZE]
+ __attribute__ ((aligned (PAGE_SIZE)));
/*
* This only applies to things which need to ioremap before paging_init()
--- linux-2.6.10-rc2-mm4-full/include/asm-frv/highmem.h.old 2004-12-11 23:57:40.000000000 +0100
+++ linux-2.6.10-rc2-mm4-full/include/asm-frv/highmem.h 2004-12-11 23:57:51.000000000 +0100
@@ -44,8 +44,6 @@
#define kmap_pte ______kmap_pte_in_TLB
extern pte_t *pkmap_page_table;
-extern void kmap_init(void);
-
#define flush_cache_kmaps() do { } while (0)
/*
--- linux-2.6.10-rc2-mm4-full/include/asm-ppc/highmem.h.old 2004-12-11 23:58:00.000000000 +0100
+++ linux-2.6.10-rc2-mm4-full/include/asm-ppc/highmem.h 2004-12-11 23:58:03.000000000 +0100
@@ -35,8 +35,6 @@
extern pgprot_t kmap_prot;
extern pte_t *pkmap_page_table;
-extern void kmap_init(void) __init;
-
/*
* Right now we initialize only a single pte table. It can be extended
* easily, subsequent pte tables have to be allocated in one physical
--- linux-2.6.10-rc2-mm4-full/arch/um/kernel/mem.c.old 2004-12-11 23:58:14.000000000 +0100
+++ linux-2.6.10-rc2-mm4-full/arch/um/kernel/mem.c 2004-12-11 23:58:21.000000000 +0100
@@ -141,7 +141,7 @@
pte_offset_kernel(pmd_offset(pml4_pgd_offset(pml4_offset_k(vaddr), \
vaddr), (vaddr)), (vaddr))
-void __init kmap_init(void)
+static void __init kmap_init(void)
{
unsigned long kmap_vstart;
--- linux-2.6.10-rc2-mm4-full/include/asm-i386/highmem.h.old 2004-12-11 23:58:54.000000000 +0100
+++ linux-2.6.10-rc2-mm4-full/include/asm-i386/highmem.h 2004-12-11 23:58:57.000000000 +0100
@@ -33,8 +33,6 @@
extern pgprot_t kmap_prot;
extern pte_t *pkmap_page_table;
-extern void kmap_init(void);
-
/*
* Right now we initialize only a single pte table. It can be extended
* easily, subsequent pte tables have to be allocated in one physical
--- linux-2.6.10-rc2-mm4-full/arch/i386/mm/init.c.old 2004-12-11 23:58:29.000000000 +0100
+++ linux-2.6.10-rc2-mm4-full/arch/i386/mm/init.c 2004-12-12 00:15:07.000000000 +0100
@@ -254,7 +254,7 @@
#define kmap_get_fixmap_pte(vaddr) \
pte_offset_kernel(pmd_offset(pml4_pgd_offset(pml4_offset_k(vaddr), vaddr), (vaddr)), (vaddr))
-void __init kmap_init(void)
+static void __init kmap_init(void)
{
unsigned long kmap_vstart;
@@ -265,7 +265,7 @@
kmap_prot = PAGE_KERNEL;
}
-void __init permanent_kmaps_init(pgd_t *pgd_base)
+static void __init permanent_kmaps_init(pgd_t *pgd_base)
{
pgd_t *pgd;
pmd_t *pmd;
@@ -294,7 +294,7 @@
}
#ifndef CONFIG_DISCONTIGMEM
-void __init set_highmem_pages_init(int bad_ppro)
+static void __init set_highmem_pages_init(int bad_ppro)
{
int pfn;
for (pfn = highstart_pfn; pfn < highend_pfn; pfn++)
@@ -408,7 +408,7 @@
}
#ifndef CONFIG_DISCONTIGMEM
-void __init zone_sizes_init(void)
+static void __init zone_sizes_init(void)
{
unsigned long zones_size[MAX_NR_ZONES] = {0, 0, 0};
unsigned int max_dma, high, low;
@@ -545,7 +545,7 @@
* but fortunately the switch to using exceptions got rid of all that.
*/
-void __init test_wp_bit(void)
+static void __init test_wp_bit(void)
{
printk("Checking if this processor honours the WP bit even in supervisor mode... ");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
----- End forwarded message -----
^ permalink raw reply
* Linux 2.6-10.rc3 8xx: Only 3 characters are printed well in __i n it start_kernel() upon kernel booting
From: Povolotsky, Alexander @ 2005-01-16 0:55 UTC (permalink / raw)
To: 'linuxppc-dev@ozlabs.org'
__init start_kernel() in init/main.c
...
lock_kernel();
page_address_init();
printk(linux_banner);
setup_arch(&command_line);
setup_per_cpu_areas();
...
Are interrupts enabled in above code ?
If so, could I somehow disable interrupts and switch to the "polling mode"
of the serial driver (drivers/serial/cpm_uart/cpm_uart_core.c) just before
printk() ?
Thanks,
Alex
^ permalink raw reply
* Re: [RFC] Patch to Abstract Ethernet PHY support (using driver model)
From: Andy Fleming @ 2005-01-14 21:00 UTC (permalink / raw)
To: Jörn Engel; +Cc: Netdev, Embedded PPC Linux list
In-Reply-To: <20050114145518.GA21418@wohnheim.fh-wedel.de>
>> In fact, we use different switch chips connected to PPC4xx directly.
>> In this situation, in my NAPI IBM EMAC driver I just have special
>> "PHY-less" case which is trivial "fixed settings" one. And all this
>> PHY lib is completely unneeded bloat.
>
> Wrt. the proposed PHY lib, I agree. Didn't even bother to look at the
> code, it's mere size said enough.
Hmm... Before I spend too much time revising based on previous comments
ebs made, is there a general consensus that the code is much too large?
I know there's a lot in there, but the goal is to simplify PHY
management for all ethernet drivers, new and old, and thus reduce code
size, overall. Is this code heading in the right direction? Does it
do too much? Too little?
Andy Fleming
Open Source Team
Freescale Semiconductor, Inc
^ permalink raw reply
* RE: [PATCH] Handle I-TLB Error and Miss separately on 8xx
From: Joakim Tjernlund @ 2005-01-14 19:51 UTC (permalink / raw)
To: Tom Rini; +Cc: Linuxppc-Embedded@Ozlabs. Org
In-Reply-To: <20050114180511.GC28724@smtp.west.cox.net>
>
> On Fri, Jan 14, 2005 at 06:56:58PM +0100, Joakim Tjernlund wrote:
> > > > Your patch will fix this.
> > > > I havn't seen it go in yet, will you submit the patch to Linus/Marcelo?
> > >
> > > I was hoping Marcelo would pick this up since I thought he was on the
> > > list. I'll re-poke him. For 2.6, the app in question crashes
> > > differently, prior to hitting this bug, but I do want to get it pushed
> > > out. I've just been swamped lately.
> >
> > Is 2.6 on 8xx stable for you(except for this app)? I was under the impression that
> > 2.6 was a bit flaky due to an unidentified MM bug.
>
> No, I don't believe it's very stable (this wa the first chance I've had
> in a while to fire up my rpxlite).
BTW, there is a simpler fix to the TLB Miss problem.
In the TLB Miss handlers, just move the 2: label a few instr. upwards to
the same line as the "li r21, 0x00f0". That way you will force a
TLB error. You can do this for both Data and Instr. Miss handlers.
The code after where the 2: label used to be can be deleted.
Jocke
^ permalink raw reply
* Re: RFC: [PATCH] platform device driver model support
From: Andrew May @ 2005-01-14 19:13 UTC (permalink / raw)
To: Kumar Gala, Matt Porter; +Cc: linuxppc-embedded
In-Reply-To: <20050112141449.B22626@home.com>
On Wed, 2005-01-12 at 14:14 -0700, Matt Porter wrote:
> On Wed, Jan 12, 2005 at 12:36:37AM -0800, Eugene Surovegin wrote:
> > On Wed, Jan 12, 2005 at 01:43:09AM -0600, Kumar Gala wrote:
> >
> > In fact, I don't see any gain (at least for 4xx) in all these changes.
> > It makes 4xx much more tangled IMHO, because we'll still need all
> > those ibm405gp.c, ibm405ep.c, ibm440gp.c etc.
>
> Summarizing some stuff from IRC (now that I'm caught up after time
> off :P), I think we can live with this on 4xx. What seems to be
> acceptable is that we can have an soc_specs[] and soc_platform_devices[]
> in each 4xx SoC platform file. So, core_ocp[] can be merged and split
> into soc_specs[]/soc_platform_devices[]. The active one will be selected
> at build time just like we do now. This is due to the static nature
> of the 4xx memory map (per SoC) and well as the variation in location
> of iomem and irq resources as well as platform_data. Our soc_specs[]
> will only have one SoC in it, since there is one per file. Doing
> something like 85xx will scatter info about as you point out
> above...and that doesn't make sense for 4xx.
I would like to bring the Virtex-II Pro, into the thinking as well. It
is an FPGA around the 405 so it can be much more flexible on what makes
up the SoC.
I am stuck working on 2.4 for a non-released product (so no code to
submit) and we have 2 of these chips on 1 board.
One has only 1 UART and the other has 2. The rest of the standard
devices are the same, but they all have different IRQ mappings.
I really don't want to build 2 different kernels just to handle this. So
far I have just overwritten the OCP struct at boot time to deal with it,
based on a HW reg that tells me which chip I am running on. I also did
a kernel cmd line option saved in u-boot before I got the HW reg.
If FPGAs start to make up more of the SoC market it don't think a simple
array of the devices is a good model to have. The FPGA could be loaded
differently for special modes with a very different setup.
I am not sure what the trade off should be for the simple build time
array compared to the run time list that is built up.
Would something like this be OK?
struct chip_basic_features[] = { {}, {},....... };
struct chip_ext1_features[] = { {}, {},....... };
struct chip_ext2_features[] = { {}, {},....... };
LIST_HEAD(system_features);
board_init()
{
list_add_tail( &system_features, &chip_basic_features );
if( board1 ){
list_add_tail( &system_features, &chip_ext1_features );
}else{
list_add_tail( &system_features, &chip_ext2_features );
}
}
^ permalink raw reply
* Re: [PATCH] I2C-MPC: use wait_event_interruptible_timeout between transactions
From: Greg KH @ 2005-01-14 18:41 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-kernel, sensors, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0501131816260.27470@blarg.somerset.sps.mot.com>
On Thu, Jan 13, 2005 at 06:21:54PM -0600, Kumar Gala wrote:
> Use wait_event_interruptible_timeout so we dont waste time waiting between
> transactions like we use to. Also, we use the adapters timeout so the
> ioctl cmd I2C_TIMEOUT will now work.
Applied, thanks.
greg k-h
^ permalink raw reply
* Re: ELDK on a PowerPC host machine?
From: annamaya @ 2005-01-14 19:20 UTC (permalink / raw)
To: Mark Chambers, linuxppc-embedded
In-Reply-To: <064701c4fa6c$5d802e30$0301a8c0@chuck2>
Good idea. I'll give it a try.
--- Mark Chambers <markc@mail.com> wrote:
>
>
> > Thank you for your input. I guess I need to be
> more
> > specific about my needs. I am looking to
> cross-compile
> > for my 8xx and 82xx based boards using ELDK on
> PowerPC
> > host machines.
> >
>
> What about the 8xx tools in ppc_8xx/usr/bin? Won't
> they
> run on a 'big' PowerPC as well?
>
> Mark Chambers
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
^ permalink raw reply
* Re: RFC: [PATCH] platform device driver model support
From: Kumar Gala @ 2005-01-14 19:14 UTC (permalink / raw)
To: Andrew May; +Cc: Kumar Gala, linuxppc-embedded
In-Reply-To: <1105730023.5420.58.camel@mud>
Andrew,
What I have already done should be able to handle your situation,=20
assuming you can identify the two processor variants with a 32-bit=20
integer or a string. In your board code you determine which variant=20
you are and then the device list will get registered based on that.
- kumar
On Jan 14, 2005, at 1:13 PM, Andrew May wrote:
> On Wed, 2005-01-12 at 14:14 -0700, Matt Porter wrote:
> > On Wed, Jan 12, 2005 at 12:36:37AM -0800, Eugene Surovegin wrote:
> > > On Wed, Jan 12, 2005 at 01:43:09AM -0600, Kumar Gala wrote:
> > >
> > > In fact, I don't see any gain (at least for 4xx) in all these=20
> changes.
> > > It makes 4xx much more tangled IMHO, because we'll still need all
> > > those ibm405gp.c, ibm405ep.c, ibm440gp.c etc.
> >
> > Summarizing some stuff from IRC (now that I'm caught up after time
> > off :P), I think we can live with this on 4xx. What seems to be
> > acceptable is that we can have an soc_specs[] and=20
> soc_platform_devices[]
> > in each 4xx SoC platform file. So, core_ocp[] can be merged and =
split
> > into soc_specs[]/soc_platform_devices[]. The active one will be=20
> selected
> > at build time just like we do now. This is due to the static nature
> > of the 4xx memory map (per SoC) and well as the variation in=20
> location
> > of iomem and irq resources as well as platform_data. Our =
soc_specs[]
> > will only have one SoC in it, since there is one per file. Doing
> > something like 85xx will scatter info about as you point out
> > above...and that doesn't make sense for 4xx.
>
> I would like to bring the Virtex-II Pro, into the thinking as well. It
> is an FPGA around the 405 so it can be much more flexible on what=20
> makes
> up the SoC.
>
> I am stuck working on 2.4 for a non-released product (so no code to
> submit) and we have 2 of these chips on 1 board.
>
> One has only 1 UART and the other has 2. The rest of the standard
> devices are the same, but they all have different IRQ mappings.
>
> I really don't want to build 2 different kernels just to handle this.=20=
> So
> far I have just overwritten the OCP struct at boot time to deal with=20=
> it,
> based on a HW reg that tells me which chip I am running on. I also =
did
> a kernel cmd line option saved in u-boot before I got the HW reg.
>
> If FPGAs start to make up more of the SoC market it don't think a=20
> simple
> array of the devices is a good model to have. The FPGA could be =
loaded
> differently for special modes with a very different setup.
>
> I am not sure what the trade off should be for the simple build time
> array compared to the run time list that is built up.
>
> Would something like this be OK?
>
> struct chip_basic_features[] =3D { {}, {},....... };
>
> struct chip_ext1_features[] =3D { {}, {},....... };
> struct chip_ext2_features[] =3D { {}, {},....... };
>
> LIST_HEAD(system_features);
>
>
>
> board_init()
> {
> =A0=A0=A0=A0=A0=A0=A0 list_add_tail( &system_features, =
&chip_basic_features );
>
> =A0=A0=A0=A0=A0=A0=A0 if( board1 ){
> =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 list_add_tail( =
&system_features, &chip_ext1_features=20
> );
> =A0=A0=A0=A0=A0=A0=A0 }else{
> =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 list_add_tail( =
&system_features, &chip_ext2_features=20
> );
> =A0=A0=A0=A0=A0=A0=A0 }
> }
^ permalink raw reply
* platforms/MAINTAINERS
From: Kumar Gala @ 2005-01-14 15:52 UTC (permalink / raw)
To: Embedded PPC Linux list, Linux/PPC Development
Do we think its worth creating an arch/ppc/platforms/MAINTAINERS to
keep track of who is the maintainer for a given board port in a single
place.
MPC8540 ADS
P: Kumar Gala
M: kumar.gala@freescale.com
W: http://www.freescale.com/FOOBAR/MPC8540ADS
S: Supported
I've suggested this idea in the past, but this time I might actually do
something about it.
- kumar
^ permalink raw reply
* Re: ELDK on a PowerPC host machine?
From: Mark Chambers @ 2005-01-14 19:07 UTC (permalink / raw)
To: annamaya, linuxppc-embedded
In-Reply-To: <20050114184749.30461.qmail@web53806.mail.yahoo.com>
> Thank you for your input. I guess I need to be more
> specific about my needs. I am looking to cross-compile
> for my 8xx and 82xx based boards using ELDK on PowerPC
> host machines.
>
What about the 8xx tools in ppc_8xx/usr/bin? Won't they
run on a 'big' PowerPC as well?
Mark Chambers
^ permalink raw reply
* Re: [PATCH] I2C-MPC: Convert to platform_device driver
From: Greg KH @ 2005-01-14 18:42 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-kernel, sensors, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.61.0501132130580.27720@blarg.somerset.sps.mot.com>
On Thu, Jan 13, 2005 at 09:35:32PM -0600, Kumar Gala wrote:
> Converted the driver to work as either a OCP or platform_device driver.
> The intent in the future (once we convert all PPC sub-archs from OCP to
> platform_device) is to remove the OCP code.
Applied, thanks.
greg k-h
^ permalink raw reply
* Re: mpc-i2c.c in 2.6
From: Adrian Cox @ 2005-01-14 18:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: Scott Hall, Embedded PPC Linux list
In-Reply-To: <8A6296CC-65A9-11D9-B612-000393DBC2E8@freescale.com>
On Thu, 2005-01-13 at 15:24 -0600, Kumar Gala wrote:
> I was wondering if you had any opinions on the timeout between
> transactions in drivers/i2c/busses/mpc-i2c. Looking at it, we
> currently set the timeout between transactions to 1 second (HZ). Any
> reason its this high?
It only exists because when I started the driver I hadn't spotted the
timeout field in i2c_adapter. Your patch is fine.
--
Adrian Cox <adrian@humboldt.co.uk>
^ permalink raw reply
* Re: ELDK on a PowerPC host machine?
From: annamaya @ 2005-01-14 18:47 UTC (permalink / raw)
To: Clemens Koller, linuxppc-embedded
In-Reply-To: <41E801B4.1010909@anagramm.de>
Thank you for your input. I guess I need to be more
specific about my needs. I am looking to cross-compile
for my 8xx and 82xx based boards using ELDK on PowerPC
host machines.
--- Clemens Koller <clemens.koller@anagramm.de> wrote:
> Hello, Annamaya
>
> I am using a PPC Linux host here, too.
>
> > Thanks for the reply Wolfgang. Can you give me a
> hint
> > on the kind of work that is required to make this
> work
> > for the PPC host?
>
> Maybe you can save a lot of work using a mainstream
> Linux
> distribution for PPC and install the gcc/gdb
> development as
> you need it?!
> If you need the ELDK root tree for booting from nfs
> just copy the ppc_zyxx- folder over from the ELDK.
>
> Just today, I needed to move to ppc without the ELDK
> as we
> ran out of fast ix86 machines for compiling. I had
> to go
> 'back' to my PowerMac G4 which was my 'functional
> prototype'
> for Linux driver development.
> Right now (today) I didn't miss anything from the
> ELDK.
>
> I use the 'CRUX PPC' distribution on that
> ppc-machine which
> is really nice to use (no bells, no whistles).
> If you want a fully fledged KDE/Gnome X, maybe you
> check out
> the 'CRUX PPC Evolution' port.
> The most painful part was to have the Mac Bootloader
> installed
> to keep have 1x Linux, 2x MacOSX and 1x MacOS9
> bootable on
> that machine. :-) Maybe I should use U-Boot next
> time ;-)
>
> Best greets,
>
> Clemens Koller
> _______________________________
> R&D Imaging Devices
> Anagramm GmbH
> Rupert-Mayer-Str. 45/1
> 81379 Muenchen
> Germany
>
> http://www.anagramm.de
> Phone: +49-89-741518-50
> Fax: +49-89-741518-19
>
>
>
> > --- Wolfgang Denk <wd@denx.de> wrote:
> >
> >
> >>In message
>
>><20050114155131.22836.qmail@web53809.mail.yahoo.com>
> >>you wrote:
> >>
> >>>I noticed that ELDK from denx does not support
> >>
> >>running
> >>
> >>>on a PowerPC host machine like the Power G4 or
> G5.
> >>>When I tried rebuilding it on a Power G4 with
> >>>YellowDog installed on it, it complained that the
> >>>PowerPC host machine is not supported. Why is
> this
> >>
> >>Correct. PPC host are not supported yet. Also
> please
> >> not that only
> >>RedHat-7.3 will work as a build host without
> >>additional tweaking.
> >>
> >>
> >>>host architecture not supported? I also found out
> >>
> >>that
> >>
> >>Little demand? We have seen less than 5 requests
> for
> >>this so far.
> >>
> >>
> >>>MontaVista does not support the PowerPC host
> >>>architecture anymore which they did a while ago.
> >>
> >>What
> >>
> >>>seems to be the real reason for not supporting
> >>
> >>this?
> >>
> >>Probably the same reason: little demand.
> >>
> >>
> >>Well: the ELDK is free software - if you fix
> the
> >> existing build
> >>problems and send me a patch I promise to
> check
> >>it in on the CVS
> >>server (as long as it doesn't break anything). But
> >>don't expect this
> >>to be an easy job.
> >>
> >>Best regards,
> >>
> >>Wolfgang Denk
> >>
> >>--
> >>Software Engineering: Embedded and Realtime
> >>Systems, Embedded Linux
> >>Phone: (+49)-8142-66989-10 Fax:
> (+49)-8142-66989-80
> >>Email: wd@denx.de
> >>If only God would give me some clear sign! Like
> >>making a large depo-
> >>sit in my name at a Swiss Bank.
>
> >> - Woody Allen
> >>
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> >
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
>
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com
^ permalink raw reply
* Re: ELDK on a PowerPC host machine?
From: annamaya @ 2005-01-14 18:44 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <CAEA499A-6654-11D9-9846-003065F9B7DC@embeddededge.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1144 bytes --]
Thanks for the reply Dan. I may know someone who is
interested in porting ELDK for the PowerPC hosts. I'll
ask him to get in touch with you soon.
--- Dan Malek <dan@embeddededge.com> wrote:
>
> On Jan 14, 2005, at 11:16 AM, annamaya wrote:
>
> > Thanks for the reply Wolfgang. Can you give me a
> hint
> > on the kind of work that is required to make this
> work
> > for the PPC host?
>
> I do all of my development on PowerPC hosts because
> I don't have anything else. I regularly build
> compiler
> tools to work in a "cross" environment, mainly to
> ensure
> consistency of target binaries and libraries. I'd
> be happy
> to work with anyone that wants to rebuild ELDK for
> YDL 3.x hosts.
>
> If someone wants to use MVL 3.1 in such an
> environment,
> we can discuss that, too.
>
> Of course, if you have a PowerPC host, you can just
> cheat
> in most cases and use the host tools. This won't
> work for
> such things and 8xx or 85xx SPE, but it would get
> you
> started.
>
> -- Dan
>
>
__________________________________
Do you Yahoo!?
All your favorites on one personal page – Try My Yahoo!
http://my.yahoo.com
^ permalink raw reply
* Re: [PATCH] Handle I-TLB Error and Miss separately on 8xx
From: Tom Rini @ 2005-01-14 18:05 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Linuxppc-Embedded@Ozlabs. Org
In-Reply-To: <JPEALJAFNGDDLOPNDIEEAECFDAAA.joakim.tjernlund@lumentis.se>
On Fri, Jan 14, 2005 at 06:56:58PM +0100, Joakim Tjernlund wrote:
> > > Your patch will fix this.
> > > I havn't seen it go in yet, will you submit the patch to Linus/Marcelo?
> >
> > I was hoping Marcelo would pick this up since I thought he was on the
> > list. I'll re-poke him. For 2.6, the app in question crashes
> > differently, prior to hitting this bug, but I do want to get it pushed
> > out. I've just been swamped lately.
>
> Is 2.6 on 8xx stable for you(except for this app)? I was under the impression that
> 2.6 was a bit flaky due to an unidentified MM bug.
No, I don't believe it's very stable (this wa the first chance I've had
in a while to fire up my rpxlite).
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* RE: [PATCH] Handle I-TLB Error and Miss separately on 8xx
From: Joakim Tjernlund @ 2005-01-14 17:56 UTC (permalink / raw)
To: Tom Rini; +Cc: Linuxppc-Embedded@Ozlabs. Org
In-Reply-To: <20050114174734.GB28724@smtp.west.cox.net>
> > Your patch will fix this.
> > I havn't seen it go in yet, will you submit the patch to Linus/Marcelo?
>
> I was hoping Marcelo would pick this up since I thought he was on the
> list. I'll re-poke him. For 2.6, the app in question crashes
> differently, prior to hitting this bug, but I do want to get it pushed
> out. I've just been swamped lately.
Is 2.6 on 8xx stable for you(except for this app)? I was under the impression that
2.6 was a bit flaky due to an unidentified MM bug.
Jocke
^ permalink raw reply
* Re: ELDK on a PowerPC host machine?
From: Dan Malek @ 2005-01-14 17:50 UTC (permalink / raw)
To: annamaya; +Cc: linuxppc-embedded
In-Reply-To: <20050114161609.37891.qmail@web53805.mail.yahoo.com>
On Jan 14, 2005, at 11:16 AM, annamaya wrote:
> Thanks for the reply Wolfgang. Can you give me a hint
> on the kind of work that is required to make this work
> for the PPC host?
I do all of my development on PowerPC hosts because
I don't have anything else. I regularly build compiler
tools to work in a "cross" environment, mainly to ensure
consistency of target binaries and libraries. I'd be happy
to work with anyone that wants to rebuild ELDK for
YDL 3.x hosts.
If someone wants to use MVL 3.1 in such an environment,
we can discuss that, too.
Of course, if you have a PowerPC host, you can just cheat
in most cases and use the host tools. This won't work for
such things and 8xx or 85xx SPE, but it would get you
started.
-- Dan
^ permalink raw reply
* Re: [PATCH] Handle I-TLB Error and Miss separately on 8xx
From: Tom Rini @ 2005-01-14 17:47 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Linuxppc-Embedded@Ozlabs. Org
In-Reply-To: <JPEALJAFNGDDLOPNDIEEGECEDAAA.joakim.tjernlund@lumentis.se>
On Fri, Jan 14, 2005 at 06:38:35PM +0100, Joakim Tjernlund wrote:
> > > -----Original Message-----
> > > From: Tom Rini [mailto:trini@kernel.crashing.org]
> > > On Wed, Jan 12, 2005 at 08:15:08AM -0700, Tom Rini wrote:
> > > > On Wed, Jan 12, 2005 at 03:17:11PM +0100, Joakim Tjernlund wrote:
> > > > > > On Wed, Jan 12, 2005 at 08:53:17AM +0100, Joakim Tjernlund wrote:
> > > [snip]
> > > > > > > Patch looks good to me, but I want to ask when this error
> > > > > > > can be triggered in practice?
> > > > > >
> > > > > > It is possible to see this in the real world, as we (<hat=mvista>) found
> > > > > > this with a customers app.
> > > > >
> > > > > hmm, this app must have been doing something pretty special. Any idea what
> > > > > caused it?
> > > >
> > > > Only vaugely. I'll poke the folks who did the investigation to see if
> > > > they recall (the app is quite large) and follow up with details, I hope.
> > >
> > > First, we couldn't get this issue to happen w/ anything but the custom
> > > app. It would generate a lot of I-TLB Error exceptions, with bit 1 of
> > > SRR1 set, and these went fine, the I-TLB got updated, and execution
> > > continued. But then at some point, and we aren't sure why exactly, an
> > > 0x1100 is generated, and we crash. We don't know what went and caused
> > > an 0x1100 to be generated instead of an 0x1300 (my wild-ass-guess is the
> > > code jumped very very far ahead).
> >
> > To me this looks like you entered the I-TLB Miss handler with a NULL pte which
> > is something that never happens in my system, don't know why this is so but I am
> > guessing that the kernel populates all instruction pte's at exec time. On the
> > other hand I don't understand why there are so many I-TLB errors, is that normal?
> >
> > Does the app modify its own code or construct a code trampoline which it jumps to? Not
> > sure how that would be handled by the kernel w.r.t NULL pte's
> >
> > Jocke
>
> I think I have figured this out. The first TLB misses that happen at app startup is Data
> TLB misses. These will then hit the NULL L1 entry and end up in do_page_fault() which
> will populate the L1 entry. But when you have a very large app that spans more than one
> L1 entry (16 MB I think) it may happen that you will have I-TLB Miss first one of the
> L1 entrys which will make the I-TLB handler bail out to do_page_fault() and the app
> craches(SEGV).
Yes, that sounds like it. Thanks.
> Your patch will fix this.
> I havn't seen it go in yet, will you submit the patch to Linus/Marcelo?
I was hoping Marcelo would pick this up since I thought he was on the
list. I'll re-poke him. For 2.6, the app in question crashes
differently, prior to hitting this bug, but I do want to get it pushed
out. I've just been swamped lately.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* RE: [PATCH] Handle I-TLB Error and Miss separately on 8xx
From: Joakim Tjernlund @ 2005-01-14 17:38 UTC (permalink / raw)
To: Tom Rini; +Cc: Linuxppc-Embedded@Ozlabs. Org
In-Reply-To: <JPEALJAFNGDDLOPNDIEEAECDDAAA.joakim.tjernlund@lumentis.se>
> > -----Original Message-----
> > From: Tom Rini [mailto:trini@kernel.crashing.org]
> > On Wed, Jan 12, 2005 at 08:15:08AM -0700, Tom Rini wrote:
> > > On Wed, Jan 12, 2005 at 03:17:11PM +0100, Joakim Tjernlund wrote:
> > > > > On Wed, Jan 12, 2005 at 08:53:17AM +0100, Joakim Tjernlund wrote:
> > [snip]
> > > > > > Patch looks good to me, but I want to ask when this error
> > > > > > can be triggered in practice?
> > > > >
> > > > > It is possible to see this in the real world, as we (<hat=mvista>) found
> > > > > this with a customers app.
> > > >
> > > > hmm, this app must have been doing something pretty special. Any idea what
> > > > caused it?
> > >
> > > Only vaugely. I'll poke the folks who did the investigation to see if
> > > they recall (the app is quite large) and follow up with details, I hope.
> >
> > First, we couldn't get this issue to happen w/ anything but the custom
> > app. It would generate a lot of I-TLB Error exceptions, with bit 1 of
> > SRR1 set, and these went fine, the I-TLB got updated, and execution
> > continued. But then at some point, and we aren't sure why exactly, an
> > 0x1100 is generated, and we crash. We don't know what went and caused
> > an 0x1100 to be generated instead of an 0x1300 (my wild-ass-guess is the
> > code jumped very very far ahead).
>
> To me this looks like you entered the I-TLB Miss handler with a NULL pte which
> is something that never happens in my system, don't know why this is so but I am
> guessing that the kernel populates all instruction pte's at exec time. On the
> other hand I don't understand why there are so many I-TLB errors, is that normal?
>
> Does the app modify its own code or construct a code trampoline which it jumps to? Not
> sure how that would be handled by the kernel w.r.t NULL pte's
>
> Jocke
I think I have figured this out. The first TLB misses that happen at app startup is Data
TLB misses. These will then hit the NULL L1 entry and end up in do_page_fault() which
will populate the L1 entry. But when you have a very large app that spans more than one
L1 entry (16 MB I think) it may happen that you will have I-TLB Miss first one of the
L1 entrys which will make the I-TLB handler bail out to do_page_fault() and the app
craches(SEGV).
Your patch will fix this.
I havn't seen it go in yet, will you submit the patch to Linus/Marcelo?
Jocke
^ 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