* Re: [PPC,SOUND] Fix audio gpio state detection
From: Benjamin Herrenschmidt @ 2006-02-12 23:27 UTC (permalink / raw)
To: Ben Collins; +Cc: alsa-devel, Ben Collins, linuxppc-dev
In-Reply-To: <1139784411.25288.11.camel@grayson>
On Sun, 2006-02-12 at 17:46 -0500, Ben Collins wrote:
> On Mon, 2006-02-13 at 09:35 +1100, Benjamin Herrenschmidt wrote:
> > Can you sync with the patches Ben Collins is doing on this as well ?
> >
> > Ben, what is your status ? Are you feeding those through upstream the
> > alsa folks ? Or waiting for me to do something ? :)
> >
> > The above, if it appear to works well enough might be worth merging
> > now ...
>
> I haven't synced because I've been waiting for some kind of go ahead
> from you. I can rediff against 2.6.16-git and send them to alsa, CC ppc
> list.
Please, do so !
Thanks,
Ben.
^ permalink raw reply
* Re: [PPC,SOUND] Fix audio gpio state detection
From: Ben Collins @ 2006-02-12 22:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: alsa-devel, Ben Collins, linuxppc-dev
In-Reply-To: <1139783738.5247.54.camel@localhost.localdomain>
On Mon, 2006-02-13 at 09:35 +1100, Benjamin Herrenschmidt wrote:
> Can you sync with the patches Ben Collins is doing on this as well ?
>
> Ben, what is your status ? Are you feeding those through upstream the
> alsa folks ? Or waiting for me to do something ? :)
>
> The above, if it appear to works well enough might be worth merging
> now ...
I haven't synced because I've been waiting for some kind of go ahead
from you. I can rediff against 2.6.16-git and send them to alsa, CC ppc
list.
--
Ben Collins
Kernel Developer - Ubuntu Linux
^ permalink raw reply
* Re: [PPC,SOUND] Fix audio gpio state detection
From: Benjamin Herrenschmidt @ 2006-02-12 22:35 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev, alsa-devel, Ben Collins
In-Reply-To: <jehd7527wq.fsf@sykes.suse.de>
On Sat, 2006-02-11 at 17:10 +0100, Andreas Schwab wrote:
> When booting with line out or headphone plugged, you won't hear anything.
> The problem is that after reset all channels are muted, but the actual
> value of the gpio port doesn't exactly match the active_val settings as
> expected by check_audio_gpio. For example, the line_mute port is set to
> 7, but check_audio_gpio would expect 0xd or 0xf, thus its return value
> indicates that it is not active, even though it is. AFAICS only looking
> at the low bit is enough to determine whether the port is active.
>
> Signed-off-by: Andreas Schwab <schwab@suse.de>
>
> Index: linux-2.6.16-rc2/sound/ppc/tumbler.c
> ===================================================================
> --- linux-2.6.16-rc2.orig/sound/ppc/tumbler.c 2006-02-03 19:43:50.000000000 +0100
> +++ linux-2.6.16-rc2/sound/ppc/tumbler.c 2006-02-11 03:46:30.000000000 +0100
> @@ -207,7 +207,7 @@ static int check_audio_gpio(struct pmac_
>
> ret = do_gpio_read(gp);
>
> - return (ret & 0xd) == (gp->active_val & 0xd);
> + return (ret & 0x1) == (gp->active_val & 0x1);
> }
>
> static int read_audio_gpio(struct pmac_gpio *gp)
Can you sync with the patches Ben Collins is doing on this as well ?
Ben, what is your status ? Are you feeding those through upstream the
alsa folks ? Or waiting for me to do something ? :)
The above, if it appear to works well enough might be worth merging
now ...
Ben.
^ permalink raw reply
* Re: Flattened device tree for Pegasos
From: Benjamin Herrenschmidt @ 2006-02-12 22:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.44.0602101844150.31619-100000@gate.crashing.org>
On Fri, 2006-02-10 at 18:46 -0600, Kumar Gala wrote:
> On Fri, 10 Feb 2006, Mark A. Greer wrote:
>
> > If anyone happens to have a Pegasos running the merged powerpc kernel
> > handy, I would greatly appreciate a dump of flattened device tree that
> > it uses.
>
> We really need to put OF tree's somewhere that people can get to, maybe
> penguinppc.org.
>
> Ben, Segher, Paul:
>
> You guys have either access to HW or tree dump's already. Would you be
> willing to share them?
There is an unresolved issue about what is the (c) for those
device-tree, especially since the Apple ones may contain driver blobs...
Ben.
^ permalink raw reply
* SPI Katix subsytem
From: dibacco @ 2006-02-12 21:36 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I would like to use a SPI subsystem on 2.4 but katix framework seems to b=
e not continuosly updated. Katix is also present in 2.6 or is there anot=
her more supported framework there?
Bye,
Antonio.
^ permalink raw reply
* PReP PCI resource allocations
From: Bob Brose @ 2006-02-12 21:01 UTC (permalink / raw)
To: linuxppc-dev
This is a 7248-133 43p. I had a lot of trouble with the early 2.6
kernels on this prep machine however 2.6.14.7 runs well (the
vga console driver even works now). There is one thing I noticed
different from 2.4.32 involving PCI resources. On 2.6.14.7 I get...
Total memory = 192MB; using 512kB for hash table (at c0300000)
Linux version 2.6.14.7 (root@oldbb) (gcc version 4.0.3 20051201 (prerelease)
(Debian 4.0.2-5)) #4 Fri Feb 10 13:27:45 CST 2006
PReP architecture
IBM planar ID: f7
...
PCI: Probing PCI hardware
Setting PCI interrupts for a "IBM 7248, PowerSeries 830/850 (Carolina)"
PCI: Cannot allocate resource region 0 of device 0000:00:0c.0
PCI: Cannot allocate resource region 1 of device 0000:00:0c.0
PCI: Cannot allocate resource region 0 of device 0000:00:10.0
The regions correspond to:
Region 0: I/O ports at 80001020 [size=32] of the builtin pcnet32 ethernet.
Region 1: Memory at c0800100 (32-bit, non-prefetchable) [size=32] pcnet32..
Region 0: I/O ports at 80001400 [size=256] of the Symbios Logic 53c810 scsi.
Both the ethernet and scsi work fine though..
2.4.32 remaps these...
Linux version 2.4.32 (root@oldbb) (gcc version 2.95.4 20011002
(Debian prerelease)) #2 Tue Feb 7 12:30:21 CST 2006
PReP architecture
IBM planar ID: 000000f7
...
PCI: Cannot allocate resource region 0 of device 00:0c.0
PCI: Cannot allocate resource region 0 of device 00:10.0
PCI: moved device 00:0c.0 resource 0 (101) to 1020
PCI: moved device 00:0c.0 resource 1 (200) to 0
PCI: moved device 00:10.0 resource 0 (101) to 1400
Is this important??
2.6.15 BTW doesn't work at all. I need to hook up a serial console to
see if I can figure out what is going on...
Bob
^ permalink raw reply
* Re:MBX AMD AM29F080 flash not recognized
From: dibacco @ 2006-02-12 20:17 UTC (permalink / raw)
To: dibacco; +Cc: linuxppc-embedded
Sorry, the problem was that I didn't configure the Interleave 4, and the =
MBX use 4 chips of AM29F080.
---------- Initial Header -----------
>From : linuxppc-embedded-bounces@ozlabs.org
To : "linuxppc-embedded" linuxppc-embedded@ozlabs.org
Cc :
Date : Sat, 11 Feb 2006 17:51:08 +0100
Subject : MBX AMD AM29F080 flash not recognized
> Hi,
>
> on my MBX board I have two flashes: AM29F040 called bootrom and four ch=
ips of AM29F080 (each one 8 Mbit for a total of 4MB).
>
> The kernel (from DENX) doesn't find the AM29F080. I added the following=
in amd_flash.c to support AM29F040 (a friend of mine told me)
>
> #define AM29F040 0x00A4
>
> and also:
>
> {
> mfr_id: MANUFACTURER_AMD,
> dev_id: AM29F040,
> name: "AMD AMD29F040",
> size: 0x00080000,
> numeraseregions: 1,
> regions: {
> { offset: 0x000000, erasesize: 0x10000, numblocks: 8 },
> }
> },
>
> in the amd_flash_info table.
>
> For AM29F080 I don't know what to add and if to add something is ok !?!=
?!?!?
>
> Someone knows?
>
> Furthermore, how can I specify that there are 4 chips of AM29F080?
>
> The kernel will handle this automatically?
>
> Bye,
> Antonio.
>
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: system tick in PPC
From: Eugene Surovegin @ 2006-02-12 18:33 UTC (permalink / raw)
To: dibacco@inwind.it; +Cc: linuxppc-embedded
In-Reply-To: <IUL5ER$96FFE4CFF38D6FFE5A07D5798F74338C@libero.it>
On Sun, Feb 12, 2006 at 06:47:15PM +0100, dibacco@inwind.it wrote:
> Someone knows how the jiffies is incremented in PPC?
> Using PIT, Decrementer or what?
I think you should be looking at include/asm-powerpc/time.h,
set_dec() & get_dec() functions.
timer_interrupt() uses set_dec().
In short, usually PPC uses decrementer, but some sub-archs are special.
--
Eugene
^ permalink raw reply
* system tick in PPC
From: dibacco @ 2006-02-12 17:47 UTC (permalink / raw)
To: linuxppc-embedded
Someone knows how the jiffies is incremented in PPC?
Using PIT, Decrementer or what?
Thanks,
Antonio.
^ permalink raw reply
* CONFIG_DEBUG_SLAB and non-cache coherent CPUs
From: Eugene Surovegin @ 2006-02-12 0:32 UTC (permalink / raw)
To: linuxppc-embedded
Hi!
I just wanted to let people on this list know that turning slab
debugging may cause slab corruption on non-coherent cache CPUs (4xx,
8xx).
The reason for this is that usually drivers which use DMA assume
L1 cache line alignment for buffers (e.g. returned from alloc_skb).
Unfortunately, with slab debugging enabled this is no longer the case,
and during cache invalidates we corrupt slab cache (or at least slab
poison markers).
I tried to define ARCH_KMALLOC_MINALIGN and/or ARCH_SLAB_MINALIGN but
it didn't work (and even if it did, it'd effectively disabled slab
debugging anyway).
I don't understand why slab debugging feature has to change allocation
alignment, as it can be obviously implemented without breaking this
alignment. Probably the reason is the usual one - nobody cares/cared
about non-coherent cache CPUs and saving couple of bytes was more
important :).
Anyway, I made a hack for my EMAC driver:
http://kernel.ebshome.net/emac_slab_debug.diff
which helps with this problem, although other drivers may experience
the same problem when used on 4xx/8xx with slab debugging enabled. In
fact, 3COM 905 driver crashed Ocotea in this configuration too.
--
Eugene
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-11 19:00 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200602110906.05547.sr@denx.de>
> Do you really need this I2O unit? You could easily create some message
> ringbuffers, one in the 440EP's SDRAM for the host-to-440 messages and one in
> the host-cpu SDRAM for the 440-to-host messages. This way, all messages will
> be transferred using pci writes.
Actually, its not the I2O unit I want, really just the doorbell
registers in the messaging unit. The MPC834x's seem to have
dropped the I2O units in that the 8272-family appears to
have, but they have the messaging unit registers.
I plan to create something like the ring-buffers scheme you
mention. And of course, you don't need an I2O unit to
implement it. However, you do need to be able to interrupt
the 440 from the host - which was the original issue.
But, there is a work-around :)
BTW, even with this scheme you really want to use DMA on
the adapter board for transfers in either direction, i.e.,
use the peripheral for both DMA read and write.
Unless of course you want to turn your 1GHz x86 host processor
into a 1MHz CPU. Check out the following performance tests
that I did between the current boards and an x86 host:
http://www.ovro.caltech.edu/~dwh/correlator/pdf/pci_performance.pdf
The boards use a PLX-9054 bridge and can DMA between themselves
at 118MB/s. However, the DMA through bridges, and DMA to/from host
bandwidth is less due to burst capabilites (or lack thereof) of
the bridges. CPU reads/writes by the host were dismal; look
at p19-26.
Of course, if I had used a PowerPC host I'm sure I would
have been fine!
Dave
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-11 18:15 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200602110921.33245.sr@denx.de>
> Hmmm. The 440EP is around for quite a while. I would be surprised if you
> couldn't buy those parts right now. But I have to admit, I never tried to. I
> would contact my AMCC distributor for availability...
I always figure that if you can find it on a distributor web
site without having to explicitly ask for the part, then
it really is available. I got my Yosemite kit through
Avnet, so lets start there:
1. Avnet
http://www.em.avnet.com
Search for 440EP from the vendor AMCC, and it only shows up
the eval boards.
Search for 'contains' MPC834 from Freescale, and there are
lots of hits (though no stock for most of them).
2. Arrow North America
http://www.arrownac.com
No AMCC stuff there.
A search for the Freescale part shows up a bunch, although they
have no stock either.
The successful search hits for the Freescale part gives me
more confidence in those parts. However, you are correct, if I
really want to know the availablity of parts, I should talk
directly to an AMCC rep.
Cheers
Dave
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: David Hawkins @ 2006-02-11 18:06 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-embedded
In-Reply-To: <200602110906.05547.sr@denx.de>
>>However, its not totally out of the question ... $50 per 21555
>>and 20 per crate, thats $1000, about half the price of
>>a CPU. But of course, without the I20 unit on the 440EP,
>>I might need the 21555 anyway.
>
>
> Do you really need this I2O unit? You could easily create some message
> ringbuffers, one in the 440EP's SDRAM for the host-to-440 messages and one in
> the host-cpu SDRAM for the 440-to-host messages. This way, all messages will
> be transferred using pci writes.
Hi Stefan,
Nope, I can always work with the 440EP. I was just disappointed
to find that the 440EP had no way for an external host to
generate an interrupt (without coming up with the work-arounds
I suggested). I don't have the part designed into a board, I'm
merely evaluating it. So, I wanted to see what else was out
there with a similar set of features; the MPC834x has them.
So, now I have two possible processors to evaluate :)
I'll finish the other tests I want to do with the 440EP, get
myself a MPC834x and repeat the same tests with it (which
shouldn't take too long, since it'll be a repeat of the
440 tests).
The MPC834x does have features to make communications between a
host and a target (PCI 'agent') work much nicer than the 440EP.
It also appears to have a faster local bus. I haven't had time
to benchmark, or estimate from timing diagrams, the performance
of the 440EP external memory bus, but there is a chance that
it will fail to meet my spec.
I wouldn't consider the 440EP work to be wasted. Its been a good
learning experience, and mainly I've just been working on this
stuff in the evenings and weekends to see whether the processor
will work. This was my first experience with PowerPC processors,
so its all good fun!
Cheers
Dave
^ permalink raw reply
* [PATCH] remove duplicate exports
From: Olaf Hering @ 2006-02-11 17:21 UTC (permalink / raw)
To: Paul Mackeras, linuxppc-dev
A few symbols are exported twice, remove them from ppc_ksyms.c
Remove users of sys_ctrler in arch/ppc/
WARNING: vmlinux: duplicate symbol '__delay' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol '__up' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol '__down' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol '__down_interruptible' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'sys_ctrler' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'strncat' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'strncmp' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'strchr' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'strrchr' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'strnlen' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'strpbrk' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'memscan' previous definition was in vmlinux
WARNING: vmlinux: duplicate symbol 'strstr' previous definition was in vmlinux
Signed-off-by: Olaf Hering <olh@suse.de>
arch/powerpc/kernel/ppc_ksyms.c | 16 ----------------
arch/ppc/kernel/ppc_ksyms.c | 8 --------
arch/ppc/xmon/start.c | 15 +--------------
include/asm-ppc/machdep.h | 13 -------------
4 files changed, 1 insertion(+), 51 deletions(-)
Index: linux-2.6.16-rc2-olh/arch/powerpc/kernel/ppc_ksyms.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/powerpc/kernel/ppc_ksyms.c
+++ linux-2.6.16-rc2-olh/arch/powerpc/kernel/ppc_ksyms.c
@@ -78,15 +78,8 @@ EXPORT_SYMBOL(sys_sigreturn);
EXPORT_SYMBOL(strcpy);
EXPORT_SYMBOL(strncpy);
EXPORT_SYMBOL(strcat);
-EXPORT_SYMBOL(strncat);
-EXPORT_SYMBOL(strchr);
-EXPORT_SYMBOL(strrchr);
-EXPORT_SYMBOL(strpbrk);
-EXPORT_SYMBOL(strstr);
EXPORT_SYMBOL(strlen);
-EXPORT_SYMBOL(strnlen);
EXPORT_SYMBOL(strcmp);
-EXPORT_SYMBOL(strncmp);
EXPORT_SYMBOL(strcasecmp);
EXPORT_SYMBOL(csum_partial);
@@ -184,9 +177,6 @@ EXPORT_SYMBOL(adb_try_handler_change);
EXPORT_SYMBOL(cuda_request);
EXPORT_SYMBOL(cuda_poll);
#endif /* CONFIG_ADB_CUDA */
-#ifdef CONFIG_PPC_PMAC
-EXPORT_SYMBOL(sys_ctrler);
-#endif
#ifdef CONFIG_VT
EXPORT_SYMBOL(kd_mksound);
#endif
@@ -204,7 +194,6 @@ EXPORT_SYMBOL(__lshrdi3);
EXPORT_SYMBOL(memcpy);
EXPORT_SYMBOL(memset);
EXPORT_SYMBOL(memmove);
-EXPORT_SYMBOL(memscan);
EXPORT_SYMBOL(memcmp);
EXPORT_SYMBOL(memchr);
@@ -213,7 +202,6 @@ EXPORT_SYMBOL(screen_info);
#endif
#ifdef CONFIG_PPC32
-EXPORT_SYMBOL(__delay);
EXPORT_SYMBOL(timer_interrupt);
EXPORT_SYMBOL(irq_desc);
EXPORT_SYMBOL(tb_ticks_per_jiffy);
@@ -221,10 +209,6 @@ EXPORT_SYMBOL(console_drivers);
EXPORT_SYMBOL(cacheable_memcpy);
#endif
-EXPORT_SYMBOL(__up);
-EXPORT_SYMBOL(__down);
-EXPORT_SYMBOL(__down_interruptible);
-
#ifdef CONFIG_8xx
EXPORT_SYMBOL(cpm_install_handler);
EXPORT_SYMBOL(cpm_free_handler);
Index: linux-2.6.16-rc2-olh/arch/ppc/kernel/ppc_ksyms.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/ppc/kernel/ppc_ksyms.c
+++ linux-2.6.16-rc2-olh/arch/ppc/kernel/ppc_ksyms.c
@@ -93,15 +93,8 @@ EXPORT_SYMBOL(test_and_change_bit);
EXPORT_SYMBOL(strcpy);
EXPORT_SYMBOL(strncpy);
EXPORT_SYMBOL(strcat);
-EXPORT_SYMBOL(strncat);
-EXPORT_SYMBOL(strchr);
-EXPORT_SYMBOL(strrchr);
-EXPORT_SYMBOL(strpbrk);
-EXPORT_SYMBOL(strstr);
EXPORT_SYMBOL(strlen);
-EXPORT_SYMBOL(strnlen);
EXPORT_SYMBOL(strcmp);
-EXPORT_SYMBOL(strncmp);
EXPORT_SYMBOL(strcasecmp);
EXPORT_SYMBOL(__div64_32);
@@ -253,7 +246,6 @@ EXPORT_SYMBOL(memcpy);
EXPORT_SYMBOL(cacheable_memcpy);
EXPORT_SYMBOL(memset);
EXPORT_SYMBOL(memmove);
-EXPORT_SYMBOL(memscan);
EXPORT_SYMBOL(memcmp);
EXPORT_SYMBOL(memchr);
Index: linux-2.6.16-rc2-olh/include/asm-ppc/machdep.h
===================================================================
--- linux-2.6.16-rc2-olh.orig/include/asm-ppc/machdep.h
+++ linux-2.6.16-rc2-olh/include/asm-ppc/machdep.h
@@ -154,19 +154,6 @@ extern char cmd_line[COMMAND_LINE_SIZE];
extern void setup_pci_ptrs(void);
-/*
- * Power macintoshes have either a CUDA or a PMU controlling
- * system reset, power, NVRAM, RTC.
- */
-typedef enum sys_ctrler_kind {
- SYS_CTRLER_UNKNOWN = 0,
- SYS_CTRLER_CUDA = 1,
- SYS_CTRLER_PMU = 2,
- SYS_CTRLER_SMU = 3,
-} sys_ctrler_t;
-
-extern sys_ctrler_t sys_ctrler;
-
#ifdef CONFIG_SMP
struct smp_ops_t {
void (*message_pass)(int target, int msg);
Index: linux-2.6.16-rc2-olh/arch/ppc/xmon/start.c
===================================================================
--- linux-2.6.16-rc2-olh.orig/arch/ppc/xmon/start.c
+++ linux-2.6.16-rc2-olh/arch/ppc/xmon/start.c
@@ -146,19 +146,6 @@ xmon_map_scc(void)
static int scc_initialized = 0;
void xmon_init_scc(void);
-extern void cuda_poll(void);
-
-static inline void do_poll_adb(void)
-{
-#ifdef CONFIG_ADB_PMU
- if (sys_ctrler == SYS_CTRLER_PMU)
- pmu_poll_adb();
-#endif /* CONFIG_ADB_PMU */
-#ifdef CONFIG_ADB_CUDA
- if (sys_ctrler == SYS_CTRLER_CUDA)
- cuda_poll();
-#endif /* CONFIG_ADB_CUDA */
-}
int
xmon_write(void *handle, void *ptr, int nb)
@@ -189,7 +176,7 @@ xmon_write(void *handle, void *ptr, int
ct = 0;
for (i = 0; i < nb; ++i) {
while ((*sccc & TXRDY) == 0)
- do_poll_adb();
+ ;
c = p[i];
if (c == '\n' && !ct) {
c = '\r';
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* MBX AMD AM29F080 flash not recognized
From: dibacco @ 2006-02-11 16:51 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
on my MBX board I have two flashes: AM29F040 called bootrom and four chip=
s of AM29F080 (each one 8 Mbit for a total of 4MB).
The kernel (from DENX) doesn't find the AM29F080. I added the following i=
n amd_flash.c to support AM29F040 (a friend of mine told me)
#define AM29F040 0x00A4
and also:
{
mfr_id: MANUFACTURER_AMD,
dev_id: AM29F040,
name: "AMD AMD29F040",
size: 0x00080000,
numeraseregions: 1,
regions: {
{ offset: 0x000000, erasesize: 0x10000, numblocks: 8 },
}
},
in the amd_flash_info table.
For AM29F080 I don't know what to add and if to add something is ok !?!?!=
?!?
Someone knows?
Furthermore, how can I specify that there are 4 chips of AM29F080?
The kernel will handle this automatically?
Bye,
Antonio.
^ permalink raw reply
* [PPC,SOUND] Fix audio gpio state detection
From: Andreas Schwab @ 2006-02-11 16:10 UTC (permalink / raw)
To: alsa-devel; +Cc: linuxppc-dev
When booting with line out or headphone plugged, you won't hear anything.
The problem is that after reset all channels are muted, but the actual
value of the gpio port doesn't exactly match the active_val settings as
expected by check_audio_gpio. For example, the line_mute port is set to
7, but check_audio_gpio would expect 0xd or 0xf, thus its return value
indicates that it is not active, even though it is. AFAICS only looking
at the low bit is enough to determine whether the port is active.
Signed-off-by: Andreas Schwab <schwab@suse.de>
Index: linux-2.6.16-rc2/sound/ppc/tumbler.c
===================================================================
--- linux-2.6.16-rc2.orig/sound/ppc/tumbler.c 2006-02-03 19:43:50.000000000 +0100
+++ linux-2.6.16-rc2/sound/ppc/tumbler.c 2006-02-11 03:46:30.000000000 +0100
@@ -207,7 +207,7 @@ static int check_audio_gpio(struct pmac_
ret = do_gpio_read(gp);
- return (ret & 0xd) == (gp->active_val & 0xd);
+ return (ret & 0x1) == (gp->active_val & 0x1);
}
static int read_audio_gpio(struct pmac_gpio *gp)
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Stability of MPC5200 FEC
From: Wolfgang Denk @ 2006-02-11 16:08 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Asier Llano Palacios, John Rigby, linuxppc-embedded
In-Reply-To: <43EE029A.5040504@246tNt.com>
In message <43EE029A.5040504@246tNt.com> you wrote:
>
> > had before the Platform Device rework. But the problem is that we are
> > experiencing that the FEC stops working after a long uptime.
>
> Did you ever observe that behavior on a lite5200 ?
> What is 'long uptime' and do you have sustained transfer during that
> period ? (To try reproduice the problem).
This is a well-known problem, I'm afraid. To trigger it, it is
usually (*) sufficient to transfer a large file (700 MB or so) over
FTP to the target. Note that I've encountered the problem in the
context of the 2.4 kernel.
(*) In some cases you can run several such transfers in a row without
problem. Power-cycling the board will bring it back to "normal" mode.
It's probably Bestcomm related. See the previous discussions with
Freescale about known issues with the 2.6 Bestcomm code.
> Also, what are the 'symptoms' ? (anything in dmesg ?)
No, nothing.
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
Like winter snow on summer lawn, time past is time gone.
^ permalink raw reply
* Re: Stability of MPC5200 FEC
From: Sylvain Munaut @ 2006-02-11 15:28 UTC (permalink / raw)
To: Asier Llano Palacios; +Cc: John Rigby, linuxppc-embedded
In-Reply-To: <1139592010.14894.22.camel@localhost.localdomain>
Asier Llano Palacios wrote:
> We are working with MPC5200 cpu.
> We've been using it since early 2.6 kernel versions.
> We're currently quite stabilished with the version of the kernel Sylvain
> had before the Platform Device rework. But the problem is that we are
> experiencing that the FEC stops working after a long uptime.
Did you ever observe that behavior on a lite5200 ?
What is 'long uptime' and do you have sustained transfer during that
period ? (To try reproduice the problem).
Also, what are the 'symptoms' ? (anything in dmesg ?)
> So, do you think that the current git version is more stable than the
> one we are using? Do you think that there is anything that could stop us
> upgrading to the latest version?
Doubtfull, I haven't touched the FEC code much except to remove the
aligment code (newer bestcomm microcode doesn't require alignement of
the skb). It should be reworked to use the generic phy code and remove
some "bugs" (like the fact when we down the interface, we stop the task
but not deactivate the MAC IIRC, which cause warning in dmesg).
You can send me the driver/net/fec_mpc52xx and arch/ppc/syslib/bestcomm
you're using, I'll tell you if there was major changes.
> The problem is that we have a custom board, with some custom devices, so
> it is not so easy to upgrade. We need to know that a new version, is
> more stable than the previous one, before we upgrade. As soon as we
> upgrade, we can help if we find any problem.
Sylvain
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: Wolfgang Denk @ 2006-02-11 13:03 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <43ED7E1E.2030700@ovro.caltech.edu>
In message <43ED7E1E.2030700@ovro.caltech.edu> you wrote:
>
> What MPC834x development kit are you using? What would you recommend?
We use (*) the TQM834x modules (with a STK83xx/85xx starter kit).
(*) "use" means that we ported U-Boot and Linux for it.
> - I'd like to get a board in a PCI or cPCI-form factor, since
> I could use it as a PCI agent/peripheral
Both PCI and cPSI are present on the STK83xx board.
> - I'd really like to get access to the external bus
> too.
Available on headers, too
Feel free to contact me for details.
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
To know how another being, another creature feels - that is impos-
sible. - Terry Pratchett, _The Dark Side of the Sun_
^ permalink raw reply
* Re: kernel startup
From: Wolfgang Denk @ 2006-02-11 12:59 UTC (permalink / raw)
To: atul.sabharwal; +Cc: linuxppc-embedded
In-Reply-To: <4A062D477D842B4C8FC48EA5AF2D41F201BA209B@us-bv-m23.global.tektronix.net>
In message <4A062D477D842B4C8FC48EA5AF2D41F201BA209B@us-bv-m23.global.tektronix.net> you wrote:
> >>Please do yourself a favour and read some docs and FAQ's first. With
> >>a low mapping ogf the IMMR like 0x00f00000 you will never be able to
> >>run Linux.
>
> I know that the processor does not allow setting up a base address for the
> exception vectors. In this situation, it would never be able to handle
This has nothing to do with that. Please *read* the FAQ!
> Just don't know if this is feasible so scrambling for any other docs. I
> have the instruction reference and development manual.
You can reinvent the wheel, or read the documented experience of
others who went the same way long time ago.
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
The perversity of nature is nowhere better demonstrated by the fact
that, when exposed to the same atmosphere, bread becomes hard while
crackers become soft.
^ permalink raw reply
* [PATCH] ppc64: poison invalid cpus
From: Anton Blanchard @ 2006-02-11 11:55 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20060210140008.GA11864@suse.de>
Ensure that per cpu access to !possible cpus causes a fault instead of silent
corruption.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Olaf Hering <olh@suse.de>
---
Thanks Olaf, I had forgotten to send it out.
Index: linux-2.6.16-rc1-git3/arch/powerpc/kernel/setup_64.c
===================================================================
--- linux-2.6.16-rc1-git3.orig/arch/powerpc/kernel/setup_64.c
+++ linux-2.6.16-rc1-git3/arch/powerpc/kernel/setup_64.c
@@ -670,6 +670,14 @@ void __init setup_per_cpu_areas(void)
size = PERCPU_ENOUGH_ROOM;
#endif
+ /*
+ * Poison invalid cpus, with lots of high bits set this should
+ * always fault
+ */
+ for (i = 0; i < NR_CPUS; i++) {
+ paca[i].data_offset = 0xeeeeeeeeeeeeeeeeULL;
+ }
+
for_each_cpu(i) {
ptr = alloc_bootmem_node(NODE_DATA(cpu_to_node(i)), size);
if (!ptr)
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: Stefan Roese @ 2006-02-11 8:21 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43ED7E1E.2030700@ovro.caltech.edu>
Hi David,
On Saturday 11 February 2006 07:03, David Hawkins wrote:
> Indeed you were correct. The MPC834x series meets my requirements.
> It is also a 3.3V PCI device, so I'm checking into whether
> the Trenton CPUs I can use as host CPUs use a 3.3V PCI interface.
> If that is the case, then I'll move the Force CPUs into another
> system, and I'll just define the cPCI bus in the correlator
> system as 3.3V-only.
Ahhh. ;-)
> The potential advantages of the MPC834x over the 440EP are;
>
> - it has doorbell registers and mailboxes for PCI
> host-to-host comms (though does not have an I2O interface)
>
> - its DDR-SDRAM controller can run faster than the 440EP
>
> - its external local bus is wider and faster than
> the 440EP
>
> - but I think the MPC834x internal buses are slower than
> the 440EP CoreConnect buses, so I'll need to benchmark
> to compare the two.
>
> - it exists! I can find them on distributors web sites
> (can't say the same for the 440EP yet!)
Hmmm. The 440EP is around for quite a while. I would be surprised if you
couldn't buy those parts right now. But I have to admit, I never tried to. I
would contact my AMCC distributor for availability...
Best regards,
Stefan
^ permalink raw reply
* Re: Yosemite/440EP 'issues' as a PCI target
From: Stefan Roese @ 2006-02-11 8:06 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <43ECD753.5000105@ovro.caltech.edu>
Hi David,
On Friday 10 February 2006 19:11, David Hawkins wrote:
> > Just use newer host CPU's! ;-)
>
> Ah, the words of a true engineer :)
>
> Of course the project manager wouldn't appreciate me doing that.
>
> However, its not totally out of the question ... $50 per 21555
> and 20 per crate, thats $1000, about half the price of
> a CPU. But of course, without the I20 unit on the 440EP,
> I might need the 21555 anyway.
Do you really need this I2O unit? You could easily create some message
ringbuffers, one in the 440EP's SDRAM for the host-to-440 messages and one in
the host-cpu SDRAM for the 440-to-host messages. This way, all messages will
be transferred using pci writes.
Best regards,
Stefan
^ permalink raw reply
* linux 2.6.13 URL
From: bharathi kandimalla @ 2006-02-11 6:48 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 410 bytes --]
Hi
I want to download the linux 2.6.13 as I am using it
But I did not find it source code at
http://www.kernel.org/
As I have find all other different versions 2.6,15
2.6.16 ..
where can I download linux 2.6.13?
will you please give me the URL?
best regards
Bharathi
---------------------------------
Yahoo! Mail
Use Photomail to share photos without annoying attachments.
[-- Attachment #2: Type: text/html, Size: 676 bytes --]
^ permalink raw reply
* accessing serial port of MPC860T
From: bharathi kandimalla @ 2006-02-11 6:37 UTC (permalink / raw)
To: jagadish, linuxppc-embedded@ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 638 bytes --]
Hi
I am able to open the scc2 port from the user space application
but I am not able to write to the device.
I think write function is not implemented correctly
even if I wrote code for write function in the file
cpm_uart_cpm1.c it is effecting console port
As the code comes from the linux 2.6.13 for the
Mpc860T works correctly? /or it requires some modifications to work properly
If the port (SMC2 OR SCC1 OR SMC] is configured as the CONSOLE it is working fine
best regards
BHARATHI
---------------------------------
Yahoo! Mail
Use Photomail to share photos without annoying attachments.
[-- Attachment #2: Type: text/html, Size: 905 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