obcd wrote:So, by reveiling a piece of code (that has nothing to do with graphics) that runs on one of the 47 cores which forms the soc gpu, competitors would be able to figure out how the gpu was designed?
I can understand that Broadcom needs to give it's permission before the code can be made public.
It still doesn't explain why we need both the FIQ and VPU approach.
If the driver can't be made public, so be it.
If it works as expected, I have no need to start digging into it's source.
You already have ALL the source code for the driver right now - feel free to dive in - there are lots of people complaining, but very few actually trying to help! At the moment, no GPU code has been written - and it may never be written depending on how the FIQ approach goes. I believe it was proposed because the GPU can service interrupts much faster than the Arm, so it was an option should the Arm not be fast enough.
As to revealing code, there is no problem with C code fragments like a driver giving away secrets, BUT, no-one would be able to compile it and build it in to the GPU blob anyway, so it would just be an reading exercise. But like I said, no GPU code for this USB issue exists, so it's a moot point anyway.
Volunteer at the Raspberry Pi Foundation, helper at Picademy September and October 2014.