Hi Vijay, On Sat, Aug 16, 2008 at 12:59 AM, Pasam, Vijay <[EMAIL PROTECTED]> wrote: >> 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. > > There are about 9 errors with the latest set of patches. These are all > false positives - not really errors. Majority of warnings also fall > under this category.
I'm not talking about issues returned by checkpatch, but issues visible to the human observer. >> I'm not familiar with checkpatch, but I guess the purpose is >> not to highlight functional issues. >> 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). > > > There are some sample applications distributed to test bridge > functionality. There are DSP side binaries provided along with ARM side > application that can be used to test the changes done on Bridge. You can > download sample applications at > http://omapzoom.org/gf/project/omapbridge/wiki/?pagename=Software+Inform > ation It's not possible to build the nodes in 'dspbridge_samples.tar.gz'. It seems the 'ti.bios' package is missing. Apparently the 'ti.rtdx' package is missing too, but I don't think it's really required for simple nodes. The source for 'cexec' and 'dynreg' is present, so that's good. Still, there's no base image binary. So now way of testing the nodes anyway. Best regards. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
