Re: [PATCH 1/2]Blackfin archtecture patche for 2.6.16

[Bernd Schmidt]

Luke is probably still asleep at this time of night, so I'll try to 
answer what I can...

Andrew Morton wrote:
> "Luke Yang" <luke.adi@xxxxxxxxx> wrote:
> >    This is the Blackfin archtecture patch for kernel 2.6.16.
>
> - We don't want to be putting 44000 lines of new code in the kernel and
>   then have it rot.  Who will support this in the long-term?  What
>   resources are behind it?  IOW: what can you say to convince us that it
>   won't rot?

We're a team inside Analog Devices who are maintaining a GNU toolchain, 
uClinux kernel, and user space apps for the Blackfin.  All of this is 
available on our blackfin.uclinux.org site.  We do not expect to go away 
anytime soon.

>   The lack of a MAINTAINERS entry doesn't inspire confidence..

That should probably be fixed.

> - How widespread/popular is the blackfin?  Are many devices using it? 
>   How old/mature is it?  Is it a new thing or is it near end-of-life?

Neither, really.  It's been around for a bit, but the uClinux port is 
only now beginning to really take off, and we certainly hope that more 
and more devices will begin using it.

> - Are easy-to-install x86 cross-build packages available?  If not, are
>   there straightforward instructions anywhere to guide people in generating
>   a cross-build setup?
>
>   <looks>
>
>   OK, blackfin.uclinux.org seems to have that.  Does binutils support
>   blackfin?

On blackfin.uclinux.org you'll find our local trees and the RPM releases 
we recommend to users.  The Blackfin port is in gcc and binutils 
mainline; we hope to be able to get into the kernel mainline as well. 
If you have additional questions about the chip, please ask.

> - A lot of this code appears to come from Analog Devices, but you don't ;)

We do, actually.  We just don't like Outlook.

>   We'd need to see some sort of authorisation from the original authors
>   for the inclusion of their code.  Preferably in the form of
>   Signed-off-by:s.  

I'll pass that along to the right people.  Would a "Signed-off-by: 
Analog Devices" (similar to our FSF copyright assignments) be ok or does 
it have to be individuals?  I believe the port actually predates the 
involvement of most of the people working on it now.

> - Do you really need to support old_mmap()?

From what I can tell, no we don't, although we'll have to make a small 
change to our uClibc.  (A lot of this code got copied from the m68k port 
initially... that may explain a few things).

> - Too much use of open-coded `volatile'.  The objective should be to have
>   zero occurrences in .c files.  And volatile sometimes creates suspicion
>   even when it's used in .h files.

Are you referring to the ones in 
include/asm-blackfin/mach-bf533/cdefBF532.h?  These are memory-mapped 
hardware registers (MMRs); do you have any better suggestions how to 
access these?  That file actually comes from our in-house Visual DSP 
compiler, and while there may be better ways of accessing the register 
than those macros, there is something to be said for being able to drop 
in a replacement if future chips have different addresses for these 
registers.

The Blackfin has a lot of peripherals sitting on the same die as the 
core, and they're all accessed through MMRs.


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