Re: [Linux-fbdev-devel] [Sm5xx-devel] SM501 framebuffer driver

[Paul M. <le...@li...>]

Hi Bill, fancy seeing you in this thread ;-)

On Sun, Oct 15, 2006 at 12:34:28PM -0500, William A. Gatliff wrote:
> One thing that concerns me about all of the ALSA implementations I've
> seen so far is that the source code for the 8051 side is never
> included.  GPL questions aside, for legacy reasons alone we've got to
> make sure that stuff gets in too.
> 
We want the 8051 blob in userspace if anything, there's little reason to
tie this in to the module specifically, and it's handy to expose the
interface for people that are specifically interested in loading in
alternate code on the 8051.

As far as including source for the 8051 code itself, that would be nice
to have, but I doubt it's something the majority of users are going to
care about. I've certainly never seen any.

> But then again, there's the question of where the source code is at all,
> and what toolsystem you use to produce the binary image...
> 
I suspect it's just a simple binary blob and little else, there's
certainly no infrastructure in the loading side for dealing with
anything more elaborate, and it is just a stupid 8051 after all. Taking
and disassembling the thing will likely get you as close as to what the
real source looks like as anything else, but again, most people aren't
going to have a use for this.

Kbuild also doesn't have a simple facility for mapping in multiple cross
compilers depending on target preference, which is one of the things we
hit when trying to figure out how to interface the ARM7 firmware build
for the AICA on the Dreamcast (prior to the request_firmware() interface
being added). This is now handled by pushing everything to userspace,
which seems the obvious choice for the 8051, too.

On that note, do you have a pointer to some of the various ALSA
implementations that are floating around? I've only seen the OSS driver
we had in CVS, and that provides a rather dysmal starting point..