AVR32 architecture patch against Linux 2.6.18-rc1 available

[Haavard Skinnemoen]

Hi everyone,

I've put up an updated set of patches for AVR32 support at
http://avr32linux.org/twiki/bin/view/Main/LinuxPatches

The most interesting patch probably is
http://avr32linux.org/twiki/pub/Main/LinuxPatches/avr32-arch-2.patch

which, at 544K, is too large to attach here. Please let me know if you
want me to do it anyway.

Anyone want to have a look at this? I understand that a full review is
a huge job, but I'd appreciate a pointer or two in the general
direction that I need to take this in order to get it acceptable for
mainline.

Håvard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Andrew Morton]

On Thu, 6 Jul 2006 10:52:27 +0200

Post by Haavard Skinnemoen
Hi everyone,
I've put up an updated set of patches for AVR32 support at
http://avr32linux.org/twiki/bin/view/Main/LinuxPatches
The most interesting patch probably is
http://avr32linux.org/twiki/pub/Main/LinuxPatches/avr32-arch-2.patch
which, at 544K, is too large to attach here. Please let me know if you
want me to do it anyway.
Anyone want to have a look at this? I understand that a full review is
a huge job, but I'd appreciate a pointer or two in the general
direction that I need to take this in order to get it acceptable for
mainline.

Looks pretty sane from a quick scan.

- request_irq() can use GFP_KERNEL?

- show_interrupts() should use for_each_online_cpu()

<wow, kprobes support>

- do you really need __udivdi3() and friends? We struggle hard to avoid
the necessity on x86 and you should be able to leverage that advantage.

- What are these for?

+EXPORT_SYMBOL(register_dma_controller);
+EXPORT_SYMBOL(find_dma_controller);

+EXPORT_SYMBOL(clk_get);
+EXPORT_SYMBOL(clk_put);
+EXPORT_SYMBOL(clk_enable);
+EXPORT_SYMBOL(clk_disable);
+EXPORT_SYMBOL(clk_get_rate);
+EXPORT_SYMBOL(clk_round_rate);
+EXPORT_SYMBOL(clk_set_rate);
+EXPORT_SYMBOL(clk_set_parent);
+EXPORT_SYMBOL(clk_get_parent);

- Was there a ./MAINTAINERS patch? I didn't see one.

- Who stands behind this port? How do we know this isn't a patch-n-run
exercise? How do we know that the code won't rot?

- How does one build a something->avr32 cross-toolchain?

Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Haavard Skinnemoen]

On Thu, 6 Jul 2006 02:19:06 -0700

Post by Andrew Morton
On Thu, 6 Jul 2006 10:52:27 +0200

Post by Haavard Skinnemoen
Hi everyone,
I've put up an updated set of patches for AVR32 support at
http://avr32linux.org/twiki/bin/view/Main/LinuxPatches
The most interesting patch probably is
http://avr32linux.org/twiki/pub/Main/LinuxPatches/avr32-arch-2.patc

h

Post by Andrew Morton

Post by Haavard Skinnemoen
which, at 544K, is too large to attach here. Please let me know if
you want me to do it anyway.
Anyone want to have a look at this? I understand that a full review
is a huge job, but I'd appreciate a pointer or two in the general
direction that I need to take this in order to get it acceptable fo

r

Post by Andrew Morton

Post by Haavard Skinnemoen
mainline.

Looks pretty sane from a quick scan.
- request_irq() can use GFP_KERNEL?

Probably, but the genirq implementation also uses GFP_ATOMIC.

Post by Andrew Morton
- show_interrupts() should use for_each_online_cpu()

Indeed. Haven't really touched that code for a while.

Post by Andrew Morton
<wow, kprobes support>
- do you really need __udivdi3() and friends? We struggle hard to
avoid the necessity on x86 and you should be able to leverage that
advantage.

__avr32_udiv64 has only one caller, in time_init(). I'll see if I can
eliminate it.

The 64-bit shift functions are called from architecture-independent
code, so that will be harder.

Post by Andrew Morton
- What are these for?
+EXPORT_SYMBOL(register_dma_controller);
+EXPORT_SYMBOL(find_dma_controller);

An attempt at a DMA controller framework, which is used by our MMC
driver as well as a couple of sound drivers. I can remove it from the
patchset if you want, as I haven't forward-ported any of the users yet.

Post by Andrew Morton
+EXPORT_SYMBOL(clk_get);
+EXPORT_SYMBOL(clk_put);
+EXPORT_SYMBOL(clk_enable);
+EXPORT_SYMBOL(clk_disable);
+EXPORT_SYMBOL(clk_get_rate);
+EXPORT_SYMBOL(clk_round_rate);
+EXPORT_SYMBOL(clk_set_rate);
+EXPORT_SYMBOL(clk_set_parent);
+EXPORT_SYMBOL(clk_get_parent);

Implementation of the linux/clk.h API. David Brownell convinced me to
implement it for AVR32, as it is used by a lot of ARM drivers,
especially the AT91 ones which could mostly be shared with AVR32.

Post by Andrew Morton
- Was there a ./MAINTAINERS patch? I didn't see one.

Sorry, I missed that one. Appended below.

Post by Andrew Morton
- Who stands behind this port? How do we know this isn't a
patch-n-run exercise? How do we know that the code won't rot?

Atmel, or more precisely Atmel Norway, which is the design center
that designed the AVR and AVR32 architectures, stands behind it. Atmel
Applications Engineers have received a fair amount of Linux training
already, so I don't think we'll be dropping this on the floor any time
soon.

Post by Andrew Morton
- How does one build a something->avr32 cross-toolchain?

I've started writing up a "Getting Started" guide at
http://avr32linux.org/twiki/bin/view/Main/GettingStarted. It's mostly
complete, although I haven't actually uploaded the toolchain patches.
I'll do that in a couple of minutes.

Håvard

diff --git a/MAINTAINERS b/MAINTAINERS
index 196a31c..f7ab4ff 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -422,6 +422,23 @@ W: http://people.redhat.com/sgrubb/audit
T: git kernel.org:/pub/scm/linux/kernel/git/dwmw2/audit-2.6.git
S: Maintained

+AVR32 ARCHITECTURE
+P: Atmel AVR32 Support Team
+M: ***@atmel.com
+P: Haavard Skinnemoen
+M: ***@atmel.com
+W: http://www.atmel.com/products/AVR32/
+W: http://avr32linux.org/
+W: http://avrfreaks.net/
+S: Supported
+
+AVR32/AT32AP MACHINE SUPPORT
+P: Atmel AVR32 Support Team
+M: ***@atmel.com
+P: Haavard Skinnemoen
+M: ***@atmel.com
+S: Supported
+
AX.25 NETWORK LAYER
P: Ralf Baechle
M: ***@linux-mips.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Andrew Morton]

On Thu, 6 Jul 2006 12:03:19 +0200

[stuff]

OK, thanks. Send me the whole lot when you think it's ready and we'll get
it into the pipeline. Not for 2.6.18 though - we need to give people time
to look through it and send you nastygrams ;)

Post by Andrew Morton
- How does one build a something->avr32 cross-toolchain?

I've started writing up a "Getting Started" guide at
http://avr32linux.org/twiki/bin/view/Main/GettingStarted. It's mostly
complete, although I haven't actually uploaded the toolchain patches.
I'll do that in a couple of minutes.

OK, well the more you can do there the better - that way crazy people
cross-compile for your architecture and save you work.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Haavard Skinnemoen]

On Thu, 6 Jul 2006 03:14:16 -0700

Post by Andrew Morton
On Thu, 6 Jul 2006 12:03:19 +0200

[stuff]

OK, thanks. Send me the whole lot when you think it's ready and
we'll get it into the pipeline. Not for 2.6.18 though - we need to
give people time to look through it and send you nastygrams ;)

Great. I'll send you a patch when I get most/all the suggested changes
implemented.

Post by Andrew Morton

Post by Andrew Morton
- How does one build a something->avr32 cross-toolchain?

I've started writing up a "Getting Started" guide at
http://avr32linux.org/twiki/bin/view/Main/GettingStarted. It's
mostly complete, although I haven't actually uploaded the toolchain
patches. I'll do that in a couple of minutes.

OK, well the more you can do there the better - that way crazy people
cross-compile for your architecture and save you work.

I've uploaded patches for the basic stuff like binutils and gcc.
I've also updated the Getting Started page so that it should at least b
e
possible to build the kernel by following the instructions there.

So, all you crazy people should be able to start breaking stuff now ;)

Håvard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Haavard Skinnemoen]

On Thu, 6 Jul 2006 03:14:16 -0700

Post by Andrew Morton
OK, thanks. Send me the whole lot when you think it's ready and
we'll get it into the pipeline. Not for 2.6.18 though - we need to
give people time to look through it and send you nastygrams ;)

I've put up an updated patch at
http://avr32linux.org/twiki/pub/Main/LinuxPatches/avr32-arch-3.patch

which fixes most of the issues people have pointed out. Thanks a lot
to everyone for taking the time to look through this.

I've appended the changelog below, but first I'll mention the things I
didn't fix and why:

There are three libgcc functions left, which handle the three possible
variants of 64-bit shift. There's no easy way to eliminate these, but
maybe our gcc maintainer can get gcc to emit the instructions inline
instead. However, these functions are actually specified by the AVR32
ABI, so they should be the same no matter which compiler you use.

The clk API is still exported as non-GPL. I don't feel very strongly
one way or another, but since Russell is keeping them non-GPL on ARM,
it makes most sense to keep them non-GPL on AVR32 as well.

I've kept the volatiles in the arguments to the bitops functions as
they are. I'm not sure if they're really needed, but as I understood
from reading the recent thread about spinlocks, this doesn't fall in
the category of "obviously bad" usage of volatile.

Here's the shortlog:
Add MAINTAINERS entries for AVR32 and AT32AP
Remove EARLY_PRINTK support
Remove CONFIG_DW_DMAC symbol
Remove DMA controller framework
Add Kbuild file for 'make headers_install' on AVR32
Remove #ifdef __KERNEL__ from asm/atomic.h
Remove #ifdef __KERNEL__ from asm/bitops.h
Remove #ifdef __KERNEL__ from asm/dma-mapping.h
Remove #ifdef __KERNEL__ from asm/mmu_context.h
Remove #ifdef __KERNEL__ from asm/semaphore.h
Remove #ifdef __KERNEL__ from asm/thread_info.h
Move PAGE_SIZE and friends inside #ifdef __KERNEL__
Wrap __FD_SET and friends inside __KERNEL__
Kill _syscall[0123456]() and hand-code execve() instead
Remove obsolete #include <linux/config.h>
Replace MB -> MiB and KB -> KiB
Wire up 39 new syscalls
Use do_div() instead of open-coded div64 in time_init()
Use for_each_online_cpu in show_interrupts()
Add asm/futex.h
Ensure kprobes compiles again
Switch to genirq framework
Fix cpu_idle preempt bug
Process softirqs the usual way
Handle preempt in the interrupt- and exception handlers

Håvard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Andrew Morton]

On Mon, 10 Jul 2006 11:03:25 +0200

Post by Haavard Skinnemoen
On Thu, 6 Jul 2006 03:14:16 -0700

Post by Andrew Morton
OK, thanks. Send me the whole lot when you think it's ready and
we'll get it into the pipeline. Not for 2.6.18 though - we need to
give people time to look through it and send you nastygrams ;)

I've put up an updated patch at
http://avr32linux.org/twiki/pub/Main/LinuxPatches/avr32-arch-3.patch

Thanks, I'll grab it.

Post by Haavard Skinnemoen
which fixes most of the issues people have pointed out. Thanks a lot
to everyone for taking the time to look through this.
I've appended the changelog below, but first I'll mention the things I
There are three libgcc functions left, which handle the three possible
variants of 64-bit shift. There's no easy way to eliminate these, but
maybe our gcc maintainer can get gcc to emit the instructions inline
instead. However, these functions are actually specified by the AVR32
ABI, so they should be the same no matter which compiler you use.

Sure, if the compier doesn't inline 64-bit shift then you'll certainly need
the library function.

Post by Haavard Skinnemoen
The clk API is still exported as non-GPL. I don't feel very strongly
one way or another, but since Russell is keeping them non-GPL on ARM,
it makes most sense to keep them non-GPL on AVR32 as well.

OK.

Post by Haavard Skinnemoen
I've kept the volatiles in the arguments to the bitops functions as
they are. I'm not sure if they're really needed, but as I understood
from reading the recent thread about spinlocks, this doesn't fall in
the category of "obviously bad" usage of volatile.

Nope. i386 does it too, as does include/asm-generic/bitops/atomic.h
(wrongly, I suspect. The volatile gets typecast away.)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Andrew Morton]

On Mon, 10 Jul 2006 11:03:25 +0200

Post by Haavard Skinnemoen
I've put up an updated patch at
http://avr32linux.org/twiki/pub/Main/LinuxPatches/avr32-arch-3.patch

That diff doesn't update ./MAINTAINERS

Please prepare a nice changelog describing the architecture (what's an
avr?), who supports it, useful web pages, how to build cross-tools, etc.
The sort of things which Linus and kernel developers should know when
someone sends in a half-megabyte patch.

And a signed-off-by:, as per section 11 of Documentation/SubmittingPatches.

Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Haavard Skinnemoen]

On Mon, 10 Jul 2006 02:37:58 -0700

Post by Andrew Morton
On Mon, 10 Jul 2006 11:03:25 +0200

Post by Haavard Skinnemoen
I've put up an updated patch at
http://avr32linux.org/twiki/pub/Main/LinuxPatches/avr32-arch-3.patc

h

Post by Andrew Morton
That diff doesn't update ./MAINTAINERS

Crap, I can't belive I left that out two times in a row...

Post by Andrew Morton
Please prepare a nice changelog describing the architecture (what's a

n

Post by Andrew Morton
avr?), who supports it, useful web pages, how to build cross-tools,
etc. The sort of things which Linus and kernel developers should know
when someone sends in a half-megabyte patch.
And a signed-off-by:, as per section 11 of
Documentation/SubmittingPatches.

Updated patch with MAINTAINERS, a much longer changelog entry and
Signed-off-by:

http://avr32linux.org/twiki/pub/Main/LinuxPatches/avr32-arch-4.patch

By the way, there's a separate patch #ifdef'ing out /dev/port available
from the same LinuxPatches page. Should I fold it into the avr32-arch
patch? I don't consider this a permanent solution anyway, so I made it
a separate patch in order to drop it more easily when we actually
implement port-based I/O...

Thanks,
Håvard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[David Woodhouse]

On Mon, 2006-07-10 at 11:03 +0200, Haavard Skinnemoen wrote:
+ .global __sys_pselect6
+ .type __sys_pselect6,@function
+__sys_pselect6:
+ pushm lr
+ st.w --sp, ARG6
+ rcall sys_pselect6
+ sub sp, -4
+ popm pc


sys_pselect6() is just a hackish workaround for the fact that most
architectures don't allow seven-argument syscalls. Having your own
workaround in assembly, which then calls sys_pselect6(), seems a little
odd -- why not call sys_pselect7() directly instead from your assembly
wrapper?

Stop a moment and work out precisely what the best way to pass the
arguments _is_ if you have only 5 registers and the stack, perhaps.
--
dwmw2

¹ Note that I'm just _asking_ -- the answer "Uli doesn't want to s
upport
anything but the basic 6-argument sys_pselect6() in glibc" is an
acceptable answer on your part.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Haavard Skinnemoen]

On Mon, 10 Jul 2006 10:57:33 +0100

Post by David Woodhouse
+ .global __sys_pselect6
+ pushm lr
+ st.w --sp, ARG6
+ rcall sys_pselect6
+ sub sp, -4
+ popm pc
sys_pselect6() is just a hackish workaround for the fact that most
architectures don't allow seven-argument syscalls. Having your own
workaround in assembly, which then calls sys_pselect6(), seems a
little odd -- why not call sys_pselect7() directly instead from your
assembly wrapper?

Good point. The reason I did it this way is because I haven't written a
_syscall7() stub for uClibc yet, but I guess I should probably get that
done. I did a quick grep through include/asm-* and didn't find any
other architectures defining __NR_pselect7...

Post by David Woodhouse
Stop a moment and work out precisely what the best way to pass the
arguments _is_ if you have only 5 registers and the stack, perhaps.

The regular AVR32 call convention uses r12-r8 to pass up to 5 arguments
in registers, while any additional arguments are pushed on the stack.

For syscalls, I've modified this to pass the syscall number in r8 and
no arguments on the stack. arg5 is passed in r5 and moved to r8 by the
low-level syscall handler, while arg6 is passed through r3 and pushed
on the stack only if necessary.

So the best way to implement pselect7 is probably to pass the seventh
argument through r2 -- or maybe r4.

Post by David Woodhouse
¹ Note that I'm just _asking_ -- the answer "Uli doesn't want to
support anything but the basic 6-argument sys_pselect6() in glibc" is
an acceptable answer on your part.

Well, we haven't actually ported glibc yet. But if 7-argument syscalls
is going to cause problems later, we should probably not do it...

Håvard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Thomas Gleixner]

Post by Haavard Skinnemoen

Post by Andrew Morton
Looks pretty sane from a quick scan.
- request_irq() can use GFP_KERNEL?

Probably, but the genirq implementation also uses GFP_ATOMIC.

Is there a good reason, why AVR32 needs its own interrupt handling
implementation ?

Post by Haavard Skinnemoen
From a short glance there's nothing which can not be handled by the

generic code. Also there are a couple of things missing -e.g. recursive
enable/disable_irq() handling.

tglx



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Haavard Skinnemoen]

On Thu, 06 Jul 2006 13:30:25 +0200

Post by Thomas Gleixner

Post by Haavard Skinnemoen

Post by Andrew Morton
Looks pretty sane from a quick scan.
- request_irq() can use GFP_KERNEL?

Probably, but the genirq implementation also uses GFP_ATOMIC.

Is there a good reason, why AVR32 needs its own interrupt handling
implementation ?

No, not really. At least not after the genirq stuff went in. I used to
be a bit concerned about the generic irq code being too heavyweight,
but I think handle_simple_irq() might be just what we need for
chip-internal interrupt handling.

Post by Thomas Gleixner

Post by Haavard Skinnemoen
From a short glance there's nothing which can not be handled by the

generic code. Also there are a couple of things missing -e.g.
recursive enable/disable_irq() handling.

You're probably right. I'll see if I can get it converted to genirq
one of the next days.

Håvard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Thomas Gleixner]

Post by Haavard Skinnemoen
On Thu, 06 Jul 2006 13:30:25 +0200

Post by Thomas Gleixner

Post by Haavard Skinnemoen

Post by Andrew Morton
Looks pretty sane from a quick scan.
- request_irq() can use GFP_KERNEL?

Probably, but the genirq implementation also uses GFP_ATOMIC.

Is there a good reason, why AVR32 needs its own interrupt handling
implementation ?

No, not really. At least not after the genirq stuff went in. I used to
be a bit concerned about the generic irq code being too heavyweight,
but I think handle_simple_irq() might be just what we need for
chip-internal interrupt handling.

Post by Thomas Gleixner

Post by Haavard Skinnemoen
From a short glance there's nothing which can not be handled by the

generic code. Also there are a couple of things missing -e.g.
recursive enable/disable_irq() handling.

You're probably right. I'll see if I can get it converted to genirq
one of the next days.

Good. If there are any questions or things you find missing, don't
hesitate to ask.

tglx


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Haavard Skinnemoen]

On Thu, 06 Jul 2006 11:58:13 +0200

Post by Andrew Morton
- do you really need __udivdi3() and friends? We struggle hard to
avoid the necessity on x86 and you should be able to leverage that
advantage.
- What are these for?
+EXPORT_SYMBOL(register_dma_controller);
+EXPORT_SYMBOL(find_dma_controller);
+EXPORT_SYMBOL(clk_get);
+EXPORT_SYMBOL(clk_put);
+EXPORT_SYMBOL(clk_enable);
+EXPORT_SYMBOL(clk_disable);
+EXPORT_SYMBOL(clk_get_rate);
+EXPORT_SYMBOL(clk_round_rate);
+EXPORT_SYMBOL(clk_set_rate);
+EXPORT_SYMBOL(clk_set_parent);
+EXPORT_SYMBOL(clk_get_parent);

probably wants to be _GPL exports anyway

If so, ARM should probably be converted as well. On SH, they are
actually _GPL exports.

I'll convert dma_controller stuff anyway.

Håvard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Russell King]

Post by Haavard Skinnemoen
On Thu, 06 Jul 2006 11:58:13 +0200

Post by Andrew Morton
+EXPORT_SYMBOL(clk_get);
+EXPORT_SYMBOL(clk_put);
+EXPORT_SYMBOL(clk_enable);
+EXPORT_SYMBOL(clk_disable);
+EXPORT_SYMBOL(clk_get_rate);
+EXPORT_SYMBOL(clk_round_rate);
+EXPORT_SYMBOL(clk_set_rate);
+EXPORT_SYMBOL(clk_set_parent);
+EXPORT_SYMBOL(clk_get_parent);

probably wants to be _GPL exports anyway

If so, ARM should probably be converted as well. On SH, they are
actually _GPL exports.

That depends if you consider them to be a low level API or not. I don't.
They're staying as non-GPL on ARM, thanks.

[David Woodhouse]

Post by Haavard Skinnemoen
Hi everyone,
I've put up an updated set of patches for AVR32 support at
http://avr32linux.org/twiki/bin/view/Main/LinuxPatches
The most interesting patch probably is
http://avr32linux.org/twiki/pub/Main/LinuxPatches/avr32-arch-2.patch

Please add include/asm-avr32/Kbuild which lists those files which need
to be present in /usr/include/asm, over and above those listed in
asm-generic/Kbuild.asm. Then run 'make headers_install' and review the
exported headers to make sure they're suitable for building glibc, etc.

Should probably drop the #ifdef __KERNEL__ from asm/atomic.h. There's no
excuse for anything non-kernel to be using atomic.h, so by the time you
merge that'll probably have been taken out of asm-generic/Kbuild.asm.
Likewise bitops.h and anything else which isn't, or shouldn't be,
exported (including dma-mapping.h, probably also io.h, etc.)

You define PAGE_SIZE in asm/page.h where userspace can see it. No need
for that -- portable userspace must use sysconf(_SC_PAGE_SIZE) anyway --
you can move it inside the #ifdef __KERNEL__ you already have there.

Your posix_types.h wraps __FD_SET et al in
#if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)
I suspect that's not at all needed, so it can be fixed to just
__KERNEL__ as we did on s390 recently iirc.

Kill syscall[012456] from your unistd.h -- they aren't used anywhere. In
fact, you might as well kill syscall3() too, since you only use it in
one place for execve. Just do execve 'manually' with the appropriate
inline asm.

Do you really need the EARLY_PRINTK crap? Can't you just register your
proper console nice and early? There's no need to wait for
console_init() and use console_initcall(). You can do it right at the
beginning of setup_arch(), as long as you parse the command line early
enough for console= options.

You're including <linux/config.h> in a few places -- kill them all.

"DMA controller framework".... isn't that what drivers/dma was recently
invented for? If appropriate, you should probably use that. If not, you
should explain why, and perhaps we should get it fixed.

You're a bit behind on syscall support -- I note you have
TIF_RESTORE_SIGMASK (which means you're ahead of x86_64) but you haven't
wired up ppoll() and pselect(), amongst others.

You say 'MB' in a few places where you actually mean 'MiB', probably
copied from sloppy code elsewhere.

[Haavard Skinnemoen]

On Thu, 06 Jul 2006 12:58:03 +0100

[lots of stuff I'll get fixed]
Do you really need the EARLY_PRINTK crap? Can't you just register you

r

proper console nice and early? There's no need to wait for
console_init() and use console_initcall(). You can do it right at the
beginning of setup_arch(), as long as you parse the command line earl

y

enough for console= options.

I didn't know that. But since the "proper console" would usually mean
at91_serial, I'd have to remove console_initcall() from there and call
it directly from setup_arch().

I suppose I could just remove the EARLY_PRINTK crap now and worry
about driver modifications later.

You're including <linux/config.h> in a few places -- kill them all.

Will do.

"DMA controller framework".... isn't that what drivers/dma was
recently invented for? If appropriate, you should probably use that.
If not, you should explain why, and perhaps we should get it fixed.

It was written some time before the drivers/dma stuff. I suppose I
should try to use the DMA subsystem instead.

As I understand it, though, drivers/dma is mostly for memory-to-memory
to transfers, while what I really need is memory-to-hardware and
hardware-to-memory transfers.

I'll just drop the DMA controller stuff for now as it doesn't have any
users yet anyway.

You're a bit behind on syscall support -- I note you have
TIF_RESTORE_SIGMASK (which means you're ahead of x86_64) but you
haven't wired up ppoll() and pselect(), amongst others.

I'll sync up with i386. By the way, are there any syscalls I
_shouldn't_ have wired up? It's probably too late to remove any of them
at this point, but if we get it sorted out quickly, we might get away
with a shorter grace period than usual...

You say 'MB' in a few places where you actually mean 'MiB', probably
copied from sloppy code elsewhere.

Will do.

Thanks,
Håvard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[David Woodhouse]

Post by Haavard Skinnemoen

Post by David Woodhouse
"DMA controller framework".... isn't that what drivers/dma was
recently invented for? If appropriate, you should probably use that.
If not, you should explain why, and perhaps we should get it fixed.

It was written some time before the drivers/dma stuff. I suppose I
should try to use the DMA subsystem instead.
As I understand it, though, drivers/dma is mostly for memory-to-memory
to transfers, while what I really need is memory-to-hardware and
hardware-to-memory transfers.

With MMIO those are just a not-so-special case of memory-memory, surely?
If the new framework doesn't support that, it probably _should_.

Post by Haavard Skinnemoen

Post by David Woodhouse
You're a bit behind on syscall support -- I note you have
TIF_RESTORE_SIGMASK (which means you're ahead of x86_64) but you
haven't wired up ppoll() and pselect(), amongst others.

I'll sync up with i386. By the way, are there any syscalls I
_shouldn't_ have wired up? It's probably too late to remove any of them
at this point, but if we get it sorted out quickly, we might get away
with a shorter grace period than usual...

Looks OK -- I don't see any of the obvious ones like oldstat, oldfstat,
etc.

[Haavard Skinnemoen]

On Thu, 06 Jul 2006 15:34:52 +0100

Post by David Woodhouse

Post by Haavard Skinnemoen
As I understand it, though, drivers/dma is mostly for
memory-to-memory to transfers, while what I really need is
memory-to-hardware and hardware-to-memory transfers.

With MMIO those are just a not-so-special case of memory-memory,
surely? If the new framework doesn't support that, it probably
_should_.

Yes, but there are at least two important differences:

* Hanshaking. The DMA controller must know when the peripheral has
new data available/is able to accept more data. Thus, you need to
specify which set of handshaking signals to use as well as which
direction the data is moved.
* One of the pointers often stays the same during the whole transfer
.

I'm willing to give the drivers/dma framework a try, though, when the
time comes to forward-port the drivers that need such infrastructure.

Håvard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Arjan van de Ven]

Post by Haavard Skinnemoen
On Thu, 06 Jul 2006 12:58:03 +0100

Post by David Woodhouse
Please add include/asm-avr32/Kbuild which lists those files which need
to be present in /usr/include/asm, over and above those listed in
asm-generic/Kbuild.asm. Then run 'make headers_install' and review the
exported headers to make sure they're suitable for building glibc,
etc.

uClibc fails because it tries to grep for UTS_RELEASE in
linux/version.h and doesn't find it because it's been moved to
linux/utsrelease.h. I can update the script so that it checks
linux/utsrelease.h first, but that file is not installed by
make headers_install.

I would say that version.h should most certainly not be exposed to
userspace. utsrelease.h.. since it's exposing a string... MAYBE. But
really.. how can userspace use this at all in any useful way?

Greetings,
Arjan van de Ven

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Nick Piggin]

I don't see why test_bit() should be any more "special" than the & operator.

OTOH, I guess test_bit isn't a double underscore variant, and so perhaps
it is. What are the semantics of these things supposed to be? It gets
a bit complex if you're just trying to decide whether need_resched()
needs a barrier() or not :(