lkml.org 
[lkml]   [2006]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2]Blackfin archtecture patche for 2.6.16
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@gmail.com> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-03-22 00:47    [W:1.096 / U:0.664 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site