[PATCH 1/2]Blackfin archtecture patche for 2.6.16

[PATCH 1/2]Blackfin archtecture patche for 2.6.16

[Luke Yang]

Hi all,

   This is the Blackfin archtecture patch for kernel 2.6.16.  This
patch include header files and arch files, which are hard to split. 
Thus the patch size is big, I hope that is OK for a new architecture
patch. For the other driver patches, I'll send them one by one in
small size. Thanks!

  Because of the big size, I put it here:
http://blackfin.uclinux.org/frs/download.php/810/blackfin-arch.patch.tar.bz2

Signed off by: Luke Yang <luke.adi@gmail.com>

--
Best regards,
Luke Yang
magic.yyang@gmail.com; luke.adi@gmail.com

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

[Luke Yang]

Hi,

   Anyone like to review this patch? Any comment or suggestion is
appreciated. If you have questions, send me mails.

   Thank you in advance!

Regards,
Luke Yang <luke.adi@gmail.com>

On 3/20/06, Luke Yang <luke.adi@gmail.com> wrote:
> Hi all,
>
>    This is the Blackfin archtecture patch for kernel 2.6.16.  This
> patch include header files and arch files, which are hard to split.
> Thus the patch size is big, I hope that is OK for a new architecture
> patch. For the other driver patches, I'll send them one by one in
> small size. Thanks!
>
>   Because of the big size, I put it here:
> http://blackfin.uclinux.org/frs/download.php/810/blackfin-arch.patch.tar.bz2
>
> Signed off by: Luke Yang <luke.adi@gmail.com>
>
> --
> Best regards,
> Luke Yang
> magic.yyang@gmail.com; luke.adi@gmail.com
>


--
Best regards,
Luke Yang
magic.yyang@gmail.com; luke.adi@gmail.com

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

[Andrew Morton]

"Luke Yang" <luke.adi@gmail.com> wrote:
>
>    This is the Blackfin archtecture patch for kernel 2.6.16.
>

There are few practical issues we need to be concerned about with new
architectures.

- 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?

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

- 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?

  It's a cost/benefit thing.  It costs us to add code to the kenrel.  How
  many people would benefit from us doing that?

- 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?

- A lot of this code appears to come from Analog Devices, but you don't ;)
  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.  

>  http://blackfin.uclinux.org/frs/download.php/810/blackfin-arch.patch.tar.bz2

As I said, 44kloc ;)

- Do you really need to support old_mmap()?

- It would be preferable to use the generic IRQ infrastructure in kernel/irq/

- 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.

- bug: coreb_ioctl() does copy_from_user() and down() inside spinlock.

- err, coreb_ioctl() does down(&file->f_dentry->d_inode->i_sem); but
  that's a mutex now, so I assume that's actually dead code?

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@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

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

[Andrew Morton]

Bernd Schmidt <bernds_cb1@t-online.de> wrote:
>
> 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.

OK.  Thanks for the contributions.

> ...
> >   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.

I think names of individuals would be preferred - the Signed-off-by: is
often used when hunting down maintainers/developers to bug about problems. 
Although as it's a single megapatch, that's less useful in this case.

If we go with the single signed-off-by: I guess it would be best if that
was a person within AD who is in a position to authorise the merge.  If you
say that person is yourself or Luke then fine.

> > - 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.

readl/writel and friends would be the preferred way of accessing
memory-mapped registers.  If that doesn't work then at least you should
wrap the volatile cast into a single inlined function somewhere so it's not
splattered everywhere.  That way the code is more pleasing to read and we
eliminate the risk that someone forgets to add the cast.

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

[Luke Yang]

  Thanks for your reply. See below.

On 3/21/06, Andrew Morton <akpm@osdl.org> wrote:
> "Luke Yang" <luke.adi@gmail.com> wrote:
> >
> >    This is the Blackfin archtecture patch for kernel 2.6.16.
> >
>
> There are few practical issues we need to be concerned about with new
> architectures.
>
> - 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?
>
>   The lack of a MAINTAINERS entry doesn't inspire confidence..
   As Bernd said, Analog Device has a group maintaining linux for
Blackfin. Now I am the one who in charge of committing patches into
mainline, other developers may do the same thing later.  By
MAINTAINERS entry do you mean the linux-2.6/MAINTAINER? Or shall I
list maintainers name in the patch mail?
>
> - 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?
  As a DSP, Blackfin has been there for years and is somewhat popular.
But as a CPU which can run Linux, we are trying to make it popular.
Anyway a 5$ chip runs Linux and can do audio/video codec is a good toy
to play with.
>
>   It's a cost/benefit thing.  It costs us to add code to the kenrel.  How
>   many people would benefit from us doing that?
   As multimedia is becoming popular in embedded world, I believe many
people would benefit from a DSP running Linux.
>
> - 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?
http://docs.blackfin.uclinux.org/ is a good place to find documents.
In my opinion, not many CPU has such good documents site. Even a
beginner will find it as a good linux and embedded training place.
>
>   <looks>
>
>   OK, blackfin.uclinux.org seems to have that.  Does binutils support
>   blackfin?
>
> - A lot of this code appears to come from Analog Devices, but you don't ;)
  Actually I am. Just perfer gmail than outlook web (I don't use
window$, so don't have outlook to access company mailbox).
>   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.
  For this patch it is Luke Yang, then for other drivers or patches,
it would be the maintainer. All our work(software or even hardware) is
opened, our group don't do any un-GPLed software now.
>
> >  http://blackfin.uclinux.org/frs/download.php/810/blackfin-arch.patch.tar.bz2
>
> As I said, 44kloc ;)
  Sorry for the size, again :) But I really don't want to split it,
doesn't make much sense.
>
> - Do you really need to support old_mmap()?
>
> - It would be preferable to use the generic IRQ infrastructure in kernel/irq/
  Task added. I'll make it happen.
>
> - 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.
  volatile is not evil :) The only and correct usage is variables that
may be modified by hardware (such as MMR) or in a irq/signal handler.
I have checked my code.  Yes some kind of warpper may look better, we
have plan to change it, I'll send you patch for this.
>
> - bug: coreb_ioctl() does copy_from_user() and down() inside spinlock.
>
> - err, coreb_ioctl() does down(&file->f_dentry->d_inode->i_sem); but
>   that's a mutex now, so I assume that's actually dead code?
    Thanks. Bug reported.  Actually that's part of the reasons we want
to get into mainline: As we keep up to latest kernel, we can get rid
of the obsolete code in time.
>
>
>

--
Best regards,
Luke Yang
magic.yyang@gmail.com; luke.adi@gmail.com

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

[Luke Yang]

Hi,

   This is the patch of MAINTAINERS entry. As more Blackfin drivers
added in, I'll add more maintainers list.

diff --git a/MAINTAINERS b/MAINTAINERS
index 8db5c33..649cb01 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -425,6 +425,36 @@ M: tigran@veritas.com
 L:     linux-kernel@vger.kernel.org
 S:     Maintained

+BLACKFIN ARCHITECTURE
+P:     Luke Yang
+M:     luke.adi@gmail.com
+P:     Aubery Li
+M:     aubery.li@analog.com
+P:     Bernd Schmidt
+M:     bernd.schmidt@analog.com
+P:     Robin Getz
+M:     robin.retz@analog.com
+P:     Michael Hennerich
+M:     michael.hennerich@analog.com
+P:     Jie Zhang
+M:     jie.zhang@analog.com
+P:     Michael Kang
+M:     michael.kang@analog.com
+P:     Roy Huang
+M:     roy.huang@analog.com
+P:     Sonic Zhang
+M:     sonic.zhang@analog.com
+L:     linux-kernel@vger.kernel.org
+W:     http://blackfin.uclinux.org
+S:     Supported
+
+BLACKFIN SERIAL DRIVER
+P:     Sonic Zhang
+M:     sonic.zhang@analog.com
+L:     linux-kernel@vger.kernel.org
+W:     http://blackfin.uclinux.org
+S:     Supported
+
 BLOCK LAYER
 P:     Jens Axboe
 M:     axboe@suse.de

signed-off-by: Luke Yang <luke.adi@gmail.com>

Regards,
Luke Yang

On 3/22/06, Andrew Morton <akpm@osdl.org> wrote:
> "Luke Yang" <luke.adi@gmail.com> wrote:
> >
> >  >   The lack of a MAINTAINERS entry doesn't inspire confidence..
> >     As Bernd said, Analog Device has a group maintaining linux for
> >  Blackfin. Now I am the one who in charge of committing patches into
> >  mainline, other developers may do the same thing later.  By
> >  MAINTAINERS entry do you mean the linux-2.6/MAINTAINER? Or shall I
> >  list maintainers name in the patch mail?
>
> I was referring to an update to the MAINTAINERS file.
>


--
Best regards,
Luke Yang
magic.yyang@gmail.com; luke.adi@gmail.com

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

[Ingo Oeser]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

Hi Luke,

On Wednesday, 22. March 2006 04:45, you wrote:
>   As a DSP, Blackfin has been there for years and is somewhat popular.
> But as a CPU which can run Linux, we are trying to make it popular.
> Anyway a 5$ chip runs Linux and can do audio/video codec is a good toy
> to play with.

Yes, its awesome! And I would like to thank Analog Devices for doing 
and sponsoring this work. I also like to thank them for providing useful
test devices for reasonable prices. Hope you guys will make it.

I have seen a presentation and demo of this on the Chemnitzer Linux Tage 2006[1]
and was impressed big time considering how long it took to get sth. running
with other products and without any vendor Linux support.

And yes I'm a bit biased[2], as you'll find out, if you google a bit :-)


Regards

Ingo Oeser

[1] In German, sorry: http://chemnitzer.linux-tage.de/2006/vortraege/detail.html?idx=345
[2] towards coupling Linux & DSPs

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

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

[Luke Yang]

On 3/23/06, Ingo Oeser <ioe-lkml@rameria.de> wrote:
> Hi Luke,
>
> On Wednesday, 22. March 2006 04:45, you wrote:
> >   As a DSP, Blackfin has been there for years and is somewhat popular.
> > But as a CPU which can run Linux, we are trying to make it popular.
> > Anyway a 5$ chip runs Linux and can do audio/video codec is a good toy
> > to play with.
>
> Yes, its awesome! And I would like to thank Analog Devices for doing
> and sponsoring this work. I also like to thank them for providing useful
> test devices for reasonable prices. Hope you guys will make it.
>
> I have seen a presentation and demo of this on the Chemnitzer Linux Tage 2006[1]
> and was impressed big time considering how long it took to get sth. running
> with other products and without any vendor Linux support.
  Thank you! We'll try to make it.
>
> And yes I'm a bit biased[2], as you'll find out, if you google a bit :-)
  Is it a document? I googled by didn't find it.
>
>
> Regards
>
> Ingo Oeser
>
> [1] In German, sorry: http://chemnitzer.linux-tage.de/2006/vortraege/detail.html?idx=345
> [2] towards coupling Linux & DSPs
>
>
>


--
Best regards,
Luke Yang
magic.yyang@gmail.com; luke.adi@gmail.com

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

[Philippe Gerum]

Ingo Oeser <ioe-lkml <at> rameria.de> writes:

<snip>

> Yes, its awesome! And I would like to thank Analog Devices for doing 
> and sponsoring this work. I also like to thank them for providing useful
> test devices for reasonable prices. Hope you guys will make it.

<snip>

> And yes I'm a bit biased[2], as you'll find out, if you google a bit 
>

I'm likely terminally biased, but FWIW, ADI has been really supportive of our
effort in porting Adeos and the Xenomai real-time sub-system over their
architecture. Their tireless effort in improving the Blackfin kernel port and
also the toolchain, while providing information in total openness, made this
possible.

--
Philippe

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

[Robin Getz]

Luke Yang wrote:
>On 3/21/06, Andrew Morton <akpm@osdl.org> wrote:
> > - 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?
>   As a DSP, Blackfin has been there for years and is somewhat popular.
>But as a CPU which can run Linux, we are trying to make it popular.
>Anyway a 5$ chip runs Linux and can do audio/video codec is a good toy to 
>play with.

I would not describe it as a toy (sorry Luke), plus I would consider the 
work we have done to be mildly popular in terms of Linux support. I think 
that since Luke mostly has his head down doing development, doesn't see all 
the people that are in production...

I still consider Blackfin a "new" architecture (in terms of processors). 
Some background on Blackfin/MSA can be found:
http://www.intel.com/design/msa/

Blackfin is a low cost (under $5.00 @ 400MHz) high performance (Dual core 
at 600MHz each) processor that people are using, and shipping in real products.
http://www.analog.com/processors/processors/blackfin/BlackfinFamilyReferenceTable.html
Our kernel source supports BF531, BF532, BF533, BF534, BF536, BF537, BF561

A few people what started shipping that we did press releases with (many 
others did not):
thermal infrared imaging camera:
http://www.analog.com/en/press/0,2890,3%255F%255F92455,00.html
Internet-Protocol Television (IPTV) set-top boxes:
http://www.analog.com/en/press/0,2890,3%255F%255F86425,00.html

We are engaged with lots of people - from students to people shipping 
millions of units. We have almost 1600 registered developers on our web 
site, and have had over 66,000 individual downloads of our kernel source 
(not including checkouts or rsync of our cvs) - lots of people are using 
it. That doesn't compare to the traffic on kernel.org, or people using x86, 
but it is not bad for a "new" architecture.

People are making uClinux based SBC based on Blackfin:
http://www.zbrain.ch/htm/docs/zbrain_flyer_gnu_kit.pdf
http://www.tinyboards.com/rainbow2006/site/hardware/core_modules/__cm-bf537e/313/cm-bf537e.aspx
http://www.camsig.co.uk/products.htm

People are making 3rd party emulators (for those who don't want to use gdb 
or kgdb, - we support both):
http://www.section5.ch/?which=1&sub=1

It is not a toy - people (including the 15 and growing people working full 
time on this at ADI) make their living making sure it is acceptable both to 
the people deploying it in a product, but also to the community at large - 
we don't want to end up with a maintenance issues either, and have been 
working pretty hard in getting into the mainline trees for all the projects 
we are working on (toolchain, bootloader, ltp, kernel). Luke is spending 
almost 90% of his time, ensuring that everything in our kernel source meets 
the feedback from the mainline maintainers (and soon will help re-write the 
serial driver, based on Russell King's feedback :)


> >   It's a cost/benefit thing.  It costs us to add code to the kenrel.  How
> >   many people would benefit from us doing that?
>    As multimedia is becoming popular in embedded world, I believe many 
> people would benefit from a DSP running Linux.

IMHO - It is more than just another processor running Linux.

For people who ship large volume, it is a new mix of 
price/performance/power/peripherals that embedded Linux has not been able 
to meet in the past. We are enabling people to add (or keep) Linux to their 
products, and decrease their cost. We enable Linux on the network edge - 
for example : IP Phones - we worked with the maintainer of Linphone, and 
people are deploying that in their systems for VoIP.

For people who ship zero volume (which is great) - it is a completely free 
system. free toolchain, free debugger, free libraries, free kernel, free 
applications, free schematics, free simulator (skyeye), free documentation 
(web site), free support (web site). Free as in speech (open source), and 
in beer(zero cost). For those who want to run it on hardware - - $200(US) 
at Digikey, you get a board with 10/100 Networking, 500MHz CPU, 64Meg 
SDRAM, 4 Meg Flash, and lots of expansion.

If you think our patch sucks, fine - let us know where to fix it. We will 
be back at 2.6.17 with an update - and you can tell us where that sucks 
then too. (Just like we did at 2.6.13, where lots of people pointed out 
issues, which we worked on fixing for now)

-Robin

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

[Andrew Morton]

Robin Getz <rgetz@blackfin.uclinux.org> wrote:
>
> Luke Yang wrote:
> >On 3/21/06, Andrew Morton <akpm@osdl.org> wrote:
> > > - 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?
> >   As a DSP, Blackfin has been there for years and is somewhat popular.
> >But as a CPU which can run Linux, we are trying to make it popular.
> >Anyway a 5$ chip runs Linux and can do audio/video codec is a good toy to 
> >play with.
> 
> I would not describe it as a toy (sorry Luke),
>
> [ interesting info ]
>

Thanks.

> If you think our patch sucks, fine - let us know where to fix it.

It looks reasonable to me, from a ten-minute-scan.

Well.  All architecture ports suck.  Yours sucks averagely ;)

The todo list of which I'm aware is

- use serial core in that driver

- Fix up that ioctl so it a) doesn't sleep in spinlock and b) compiles

- Use generic IRQ framework

- Review all the volatiles, consolidate them in some helper-in-header-file.

- Sort out maintainance issues, gather signed-off-bys. (Done, it appears)

More things might come out once people start paying more attention, but if
that's the extent of things, I'd be OK with a merge when you're ready.

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

[Luke Yang]

On 3/22/06, Andrew Morton <akpm@osdl.org> wrote:
> Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> >
> > Luke Yang wrote:
> > >On 3/21/06, Andrew Morton <akpm@osdl.org> wrote:
> > > > - 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?
> > >   As a DSP, Blackfin has been there for years and is somewhat popular.
> > >But as a CPU which can run Linux, we are trying to make it popular.
> > >Anyway a 5$ chip runs Linux and can do audio/video codec is a good toy to
> > >play with.
> >
> > I would not describe it as a toy (sorry Luke),
> >
> > [ interesting info ]
> >
>
> Thanks.
>
> > If you think our patch sucks, fine - let us know where to fix it.
>
> It looks reasonable to me, from a ten-minute-scan.
>
> Well.  All architecture ports suck.  Yours sucks averagely ;)
>
> The todo list of which I'm aware is
>
> - use serial core in that driver
>
> - Fix up that ioctl so it a) doesn't sleep in spinlock and b) compiles
>
> - Use generic IRQ framework
>
> - Review all the volatiles, consolidate them in some helper-in-header-file.
>
> - Sort out maintainance issues, gather signed-off-bys. (Done, it appears)
>
> More things might come out once people start paying more attention, but if
> that's the extent of things, I'd be OK with a merge when you're ready.
  Does this merge has to be within 1 week after the release, so we
have to wait for 2.6.17? Or this can be done on mm-tree?
>


--
Best regards,
Luke Yang
magic.yyang@gmail.com; luke.adi@gmail.com

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

[Andrew Morton]

"Luke Yang" <luke.adi@gmail.com> wrote:
>
>  > More things might come out once people start paying more attention, but if
>  > that's the extent of things, I'd be OK with a merge when you're ready.
>    Does this merge has to be within 1 week after the release, so we
>  have to wait for 2.6.17? Or this can be done on mm-tree?

The whole patch affects just one line in one Kconfig file outside
arch/bluefin, so I don't see a reason why this needs to be tied into the
two-week-window thing.  I figure that if we can get it into -mm within a
few weeks we'll be OK for 2.6.17.

But that depends upon review comments.  My ten-minute-peek was not
sufficient.  But given this discussion and its probably appearance in -mm,
I'd expect a few more people will get in there and help.

We'll see how it goes.