Re: [RFC] Port TI DSP BRIDGE for a new dedicated branch in linux-omap

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Aug 15, 2008 at 11:16 PM, Woodruff, Richard <r-woodruff2@xxxxxx> wrote:
> Hi Felipe,
>
>> owner@xxxxxxxxxxxxxxx] On Behalf Of Felipe Contreras
>
> <snip>
>
>> >> As part of contributing this code there has been a lot of reworking
>> of the code. Last I had heard checkpatch and sparse warnings had been
>> killed. There was also a lot of work in making sure there would be no
>> legal impact to the kernel to clear its ability to be contributed.
>> >
>> > Not true: 13 errors, 246 warnings.
>
> Today another set of warning changes is in queue. Will have to check what the current number has become. It will be low. The start number a while back was defiantly very high.
>
> Checkpatch.pl is just a guide.  Completely changing code for the tool isn't probably a good idea. It might even get you severally flamed on LKML :)  The recent threads are informative (ok to read, bad to be in).
>
> Incidentally, when I asked the person working these changes, they had reported 0 functional errors had been fixed by the checkpatch changes.  A lot of the noise was typedef reduction.

I'm not familiar with checkpatch, but I guess the purpose is not to
highlight functional issues.

However, there are functional issues, but it makes sense to cleanup
the code first: there's no point in analyzing code that is never used.

> <snip>
>
>> Err, I got confused about the CE/Link, I meant the xdctools... or
>> whatever is needed to compile DSP nodes. AFAIK the DSP compiler is not
>> enough.
>
> You are correct that the internal DSP architecture is not opened up only the ARM side and the peripherals.  DSP internals is another topic.  You should be able to compile the ARM side.

Indeed, if I put myself the open source cap I can create ARM side
applications, but then I need something running on the DSP in order to
test them. If I put my corporate cap I can do that, and see that
effectively, my ARM application works. But how are maintainers
supposed to test this?

At the very least I would expect a base image binary, and a dummy dsp
node that simply copies the buffers received so that anyone can get
their hands dirty with the dsp bridge. Otherwise it's just some code
that nobody can test (hard to merge that way).

> A few years back I had heard about some people even successfully running Linux on the C6x DSP.  I think it ran well, but kind of neat all the same.  DSPBIOS or other tiny OSes work much better there.

Interesting, another platform to conquer for Linux ;)

Best regards.

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux