On Thu, Apr 3, 2014 at 12:03 AM, Alexandre Courbot <gnurou@xxxxxxxxx> wrote: > On Wed, Mar 26, 2014 at 1:24 PM, Ben Skeggs <skeggsb@xxxxxxxxx> wrote: >> On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot <acourbot@xxxxxxxxxx> wrote: >>> Add a GR device for GK20A based on NVE4, with the correct classes >>> definitions (GK20A's 3D class is 0xa297). >>> >>> Most of the NVE4 code can be used on GK20A, so make relevant bits of >>> NVE4 available to other chips as well. >> This will need a bit of a rebase on top of the tree I mentioned >> earlier (also queued for drm-next now), where I've further split out >> and named the various chunks of state. > > Will do that. > >> >> Does GK104 match entirely correctly, or just happen to work? I could >> probably hunt down the GK20A netlist images and check that actually :) > > Do you mean, the init sequence? I haven't checked in detail (we are > certainly doing things differently in the non-DRM driver), but the > registers seem to match and the GPU is able to render after that. I > admit I have not looked much further for now. I meant the arrays of register data, there's generally been some differences for most major chipset bumps. Where can I find the netlist firmware packages that go with the android driver? I can pull all the required info out of there to check :) > > The only register that does not exist on GK20A is 0x260, but when > accessing it Nouveau will be able to continue unharmed after a memory > fault. I have it in my queue to fix that too, the register doesn't exist on a couple of the other chips we support too. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
