On Mon, Mar 17, 2014 at 2:02 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 17/03/14 17:33, Ilia Mirkin wrote: >> On Mon, Mar 17, 2014 at 1:12 PM, Emil Velikov <emil.l.veli...@gmail.com> >> wrote: >>> On 17/03/14 14:22, Ilia Mirkin wrote: >>>> Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu> >>> Hi Ilia >>> >>> I'm not sure if a nouveau specific quirk is a nice idea, although the >>> only other solution is to add the "quirk" in the driver_map table. >> >> Meh, I don't see what the big deal is. That function is there to >> abstract away all the nasties of figuring out which driver to use. >> Having a little specialized logic in there doesn't seem like such a >> big deal. This has the advantage that it doesn't require us to update >> it as new chipsets come out. This is nice, since things tend to be >> supported on a per-family basis. I suppose an alternative is to list >> out all the supported chip versions one by one, but IMO that's tedious >> and unnecessary, just to keep out a couple of easy-to-read lines from >> a rarey-looked-at piece of code. >> > And at the same time, loader_get_pci_id_for_fd returns the device id, > despite the somewhat ambugious parameter name chip_id. Which means that > things will not works as expected with your approach.
Hmmm... I did test my thing and it did work. However it seems like the loader_get_pci_id_for_fd I modified only gets run if udev isn't there (and defined(ANDROID) is). The fact that it built without adding a nouveau_drm.h include is a good sign that I patched the wrong thing. I guess I got lucky because I was testing with a NV05 with a pci id of 0x2d. ARGH! OK, this patch withdrawn. But the issue remains. I don't think the right move is to stick all the pci id's into a giant map. We'll never be able to keep up. I'll try to come up with a different option tonight unless someone beats me to it. -ilia _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
