Radeon again, Was: Mainline Linux-libre for Chromebook pixel 2013?

[Denis 'GNUtoo' Carikli]

On Sun, 29 Nov 2015 13:00:06 -0200
Alexandre Oliva <lxoliva at fsfla.org> wrote:

> I've taken a look at the driver, and it is buggy.  Even though it
> works without the blob, it treats an -EINVAL return from
> r*t_firmware_nowait as a hard error, instead of ignoring as it
> could/should, to work even upstream, when the firmware loader is
> disabled altogether in the build configuration.
That sounds familiar.
As I understand it, for the radeon driver which is in a similar
situation, Jason is carrying the patch around in his repository.

The time I have where I'm able to work on this issue changes a lot.
I wasn't able to work on it after doing the test with radeon.

What is the state of affairs with the radeon patch?
-> Should I find the commit that broke it, to understand the upstream
   policy with regard to the lack of non-free firmwares. By upstream I
   don't mean Linux in general, but rather the radeon driver within.

   For some drivers it's the other way around: A firmware was necessary
   not to make the driver bail out, and not it's not anymore:
   It's using the "in-rom" code if no fimrware is found.
   Here I'm referring to the SDMA firmware for I.MX6 hardware.
   Someone verified that on IRC for me, as I've seen the message but
   could not remember on which I.MXes it was for, so now we have a
   confirmed one among many others yet to be confirmed.
-> What should eventually be done for this "patch". I remember talking
   about sed and so on, but that's rather fragile.
   Maybe keeping it as a plain git patch would be better. It could even
   be rebased with git just to make the new patch.

Denis.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20151129/139f60e9/attachment.pgp>