On Sep 24, 2007, at 11:22 AM, Scott Wood wrote:
cpmp is a physical address on arch/ppc?
No, it's a well known ioremaped() address
into the IMMR space. The only physical
addresses in any of the CPM/CPM2 are
those required to by the buffer descriptors.
There are DPRAM offsets, but they should
On Mar 26, 2007, at 7:52 PM, Marcelo Tosatti wrote:
Shall this driver be removed?
May as well. I'm probably the only one in the
world with the hardware. If I need a driver I'll
just write another one :-)
Thanks.
-- Dan
-
To unsubscribe from this list: send the line "unsubscribe l
Since I'm probably the only one that
really uses the driver for custom
uses and cares..
On Mar 1, 2007, at 10:55 AM, Timur Tabi wrote:
Ok guys, I need a consensus here. Are we going to allocate a
second block of 4 minor numbers for the QE/CPM UART or not?
not.
My driver already has
On Feb 28, 2007, at 5:08 PM, Segher Boessenkool wrote:
Since you say no one has ever used more than 4 UARTs,
there are two options:
People have used more than 4, but we just
allocated the additional /dev entries to cover
them. I know of only one time this has happened.
It's such a custom cas
On Feb 28, 2007, at 2:43 PM, Timur Tabi wrote:
What about major number 205? It also has the screwed-up /dev/
ttyCPM entries, but it has more room, and the CPM driver doesn't
actually use it. At least, I can't see where it uses it.
Please, let's just leave the four we have and let
the driv
On Feb 28, 2007, at 12:35 PM, Timur Tabi wrote:
An alternative idea, which one person already shot down, was to
allow only 4 devices normally, but allow more devices if you use
udev, since udev doesn't care about minor number assignments. This
eliminates the overlap and encourages people
On Feb 28, 2007, at 12:04 PM, Timur Tabi wrote:
... However, ttyCPM0 is currently assigned to 46, and device 50 is
an Altix serial card. The only way to give the CPM 6 or 8 slots
without moving it is to overlap the Altix card.
Then, this is currently broken in all cases
and needs to be f
On Feb 28, 2007, at 9:54 AM, Segher Boessenkool wrote:
46 = /dev/ttyCPM0PPC CPM (SCC or SMC) - port 0
...
- 47 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5
+ 49 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5
If CPM0 is 46, then CPM5 is
On Aug 29, 2005, at 11:02 PM, Li Tony-r64360 wrote:
I think it is OK. The external interrupt can be edged. And it works
well in my board.
No, it can't. PCI interrupts must be level sensitive because multiple
slots can share an interrupt.
Thanks.
-- Dan
-
To unsubscribe from this l
On Aug 29, 2005, at 1:42 PM, Kumar Gala wrote:
diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.c
b/arch/ppc/platforms/83xx/mpc834x_sys.c
--- a/arch/ppc/platforms/83xx/mpc834x_sys.c
+++ b/arch/ppc/platforms/83xx/mpc834x_sys.c
@@ -62,9 +62,29 @@ extern unsigned long total_memory; /* in
unsig
On Mar 29, 2005, at 5:30 PM, Kumar Gala wrote:
Cleaned up irq_to_siubit array so we no longer need to do 1 <<
(31-bit),
just 1 << bit.
Will you please put a comment in here that indicates this array now
has this computation done? When I wrote it, these bit numbers
matched the registers and the do
On Feb 7, 2005, at 4:35 PM, Benjamin Herrenschmidt wrote:
Interesting... more than no swap, you must also make sure you have no
r/w mmap'ed file (which are technically equivalent to swap).
Yeah, I kinda had a similar thought. Just because you aren't
swapping doesn't mean the VM subsystem isn't loo
On Jan 31, 2005, at 11:01 AM, Alan Cox wrote:
Also you might not want to magically force settings like highmem
because
you want that for multi-target kernels - Geode is a sort of odd case
where it almost makes sense but its different enough to make me
dubious.
I've already taken that out.
In fact
On Jan 27, 2005, at 9:15 AM, Pavel Machek wrote:
We do not disable HIGHMEM_64GB for 486, I do not see why we should add
extra code to geode...
What about some of the other ones like MTRR and IOAPIC?
I was kinda passing this along from someone I thought knew
better than I, but I didn't like it eithe
On Jan 27, 2005, at 1:39 AM, Andi Kleen wrote:
How about you first submit all these patches for 2.6?
I know. They are on the way. I was passing these patches
through (with some minor fixing) from AMD as part of another
project we are working on.
It doesn't make much sense to add new features to 2
Hi Marcelo.
This patch for 2.4 adds support for the AMD / National
Semiconductor CS5535 chip set. Provided by AMD
as part of the Geode support.
Signed-off-by: Dan Malek <[EMAIL PROTECTED]>
amdns_5535.patch
Description: Binary data
Hi Marcelo!
Here is a patch for 2.4 that adds the basic AMD Geode GX2/GX3
and GX1/SC1200 support. This patch updates configuration
scripts, defconfig, and setup files.
Signed-off-by: Dan Malek <[EMAIL PROTECTED]>
geode_x86.patch
Description: Binary data
"David S. Miller" wrote:
> There is only one sticking point, and that is how to convey to the
> mmap() call whether you want I/O or Memory space.
Isn't I/O space obsolete by now :-)? It actually caused me to think
of something elseI have cards with multiple memory and I/O
spaces (rare, but
"David S. Miller" wrote:
> I played around with something akin to this, and some of the necessary
> Xfree86-4.0.x hackery needed, some time ago. But I never finished
> this.
Sounds pretty sweet. How about we finish it? Any complaints (well
reasonable ones :-) or concerns that came out of disc
[EMAIL PROTECTED] wrote:
> .. But I
> still can't get at the sigcontext.c on Linux Powerpc. For example, this
> simple program gives me a segmentation fault. (Linux ppc, suse 6.4, kernel
> 2.2.14
You are not the only one. I recently discovered some inconsistent
data structures and function
Paul Mackerras wrote:
> I don't think this is actually correct; I believe what Cort said is
> that he is no longer maintaining the http://www.ppc.linux.org/ web
> site.
That is the way I read it as well. Of course, I have been reading
things differently than others, lately :-).
> He is a
21 matches
Mail list logo
