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

From: Bernd Schmidt
Date: Tue Mar 21 2006 - 18:42:29 EST


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/