similar to: [PATCH] drm/nouveau: support for platform devices

Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead of PCI to which Nouveau is tightly dependent. This patch allows Nouveau to handle platform devices by: - abstracting PCI-dependent functions that were typically used for resource querying and page mapping, - introducing a nv_device_is_pci() function that allows to make PCI-dependent code conditional, - providing a

On Mon, Feb 10, 2014 at 8:50 PM, Thierry Reding <thierry.reding at gmail.com> wrote: > On Mon, Feb 10, 2014 at 02:53:00PM +0900, Alexandre Courbot wrote: > [...] >> diff --git a/drivers/gpu/drm/nouveau/core/engine/device/base.c b/drivers/gpu/drm/nouveau/core/engine/device/base.c > [...] >> +resource_size_t >> +nv_device_resource_start(struct nouveau_device *device,

The T124 generation of Tegra GPUs uses the Kepler architecture and can thus be driven by Nouveau. However, they are declared as platform devices using the Device Tree, and Nouveau has a very strong dependency on PCI. This patch makes Nouveau core able to handle platform devices as well as PCI devices. Commonly-used PCI functions include resource range query and page mapping. These functions are

On Mon, Feb 10, 2014 at 02:53:00PM +0900, Alexandre Courbot wrote: [...] > diff --git a/drivers/gpu/drm/nouveau/core/engine/device/base.c b/drivers/gpu/drm/nouveau/core/engine/device/base.c [...] > +resource_size_t > +nv_device_resource_start(struct nouveau_device *device, unsigned int bar) > +{ > + if (nv_device_is_pci(device)) { > + return pci_resource_start(device->pdev,

On 12/02/14 05:38, Alexandre Courbot wrote: > Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead > of PCI to which Nouveau is tightly dependent. This patch allows Nouveau > to handle platform devices by: > > - abstracting PCI-dependent functions that were typically used for > resource querying and page mapping, > - introducing a nv_device_is_pci()

On Thu, Jul 31, 2014 at 06:09:42PM +0900, Alexandre Courbot wrote: > The DMA API is the recommended way to map pages no matter what the > underlying bus is. Use the DMA functions for page mapping and remove > currently existing wrappers. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > Cc: Daniel Vetter <daniel at ffwll.ch> > --- > Changes since

The DMA API is the recommended way to map pages no matter what the underlying bus is. Use the DMA functions for page mapping and remove currently existing wrappers. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> Cc: Daniel Vetter <daniel at ffwll.ch> --- Changes since v4: - Patch against the Nouveau tree instead of the kernel - Separated this patch from the rest of the

Hi Emil, On 02/12/2014 11:18 PM, Emil Velikov wrote: > On 12/02/14 05:38, Alexandre Courbot wrote: >> Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead >> of PCI to which Nouveau is tightly dependent. This patch allows Nouveau >> to handle platform devices by: >> >> - abstracting PCI-dependent functions that were typically used for >>

Hello everyone, GK20A is the Kepler-based GPU used in the upcoming Tegra K1 chips. The following patches perform architectural changes to Nouveau that are necessary to support non-PCI GPUs and add initial support for GK20A. Although the support is still very basic and more user-space changes will be needed to make the full graphics stack run on top of it, we were able to successfully open

Adapt the NVC0 BAR driver to make it able to support chips that do not expose a BAR3. When this happens, BAR1 is then used for USERD mapping and the BAR alloc() functions is disabled, making GPU objects unable to rely on BAR for data access and falling back to PRAMIN. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 101

Adapt the NVC0 BAR driver to make it able to support chips that do not expose a BAR3. When this happens, BAR1 is then used for USERD mapping and the BAR alloc() functions is disabled, making GPU objects unable to rely on BAR for data access and falling back to PRAMIN. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 115

On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Adapt the NVC0 BAR driver to make it able to support chips that do not > expose a BAR3. When this happens, BAR1 is then used for USERD mapping > and the BAR alloc() functions is disabled, making GPU objects unable > to rely on BAR for data access and falling back to PRAMIN. > >

Some chips that use system memory exclusively (e.g. GK20A) do not expose 2 BAR regions. For them only BAR1 exists, and it should be used for USERD mapping. Do not map BAR3 if its resource does not exist. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/base.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git

Some chips that use system memory exclusively (e.g. GK20A) do not expose 2 BAR regions. For them only BAR1 exists, and it should be used for USERD mapping. Do not map BAR3 if its resource does not exist. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/base.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git

On Sun, Jan 19, 2014 at 4:18 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > Also make nv_lockvgac work for nv50+ devices. This should fix IO_CONDITION and > related VBIOS opcodes that read/write the crtc regs. > > See https://bugs.freedesktop.org/show_bug.cgi?id=60680 > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- > > Ben, is this what you

On Tue, Jul 08, 2014 at 05:25:57PM +0900, Alexandre Courbot wrote: > page_to_phys() is not the correct way to obtain the DMA address of a > buffer on a non-PCI system. Use the DMA API functions for this, which > are portable and will allow us to use other DMA API functions for > buffer synchronization. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > ---

That's great -- can you just confirm that this is what you did (every so often things work for the wrong reasons): (a) grabbed the ~darktama repo (b) took the MXM patch, futzed with the paths (since it was against the linux tree), applied it (c) took the patch off the mailing list, applied it (paths should have been fine) (d) DID NOT apply the vbios-pq1 patch in any form And then you built

Also make nv_lockvgac work for nv50+ devices. This should fix IO_CONDITION and related VBIOS opcodes that read/write the crtc regs. See https://bugs.freedesktop.org/show_bug.cgi?id=60680 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Ben, is this what you had in mind? I haven't gotten a chance to test this yet since your tree doesn't build against mine (which is largely

No problem. I applied the patch (plus the other for the MXM issue), replaced the preexisting nouveau.ko.gz in /lib/mod/? with the new gzipped one, and rebuilt the initramfs. (With an updated DRIVER_DATE define just to be sure.) The HDMI output works fine. Attached are the dmesg outputs before and after, grepped for 'nouveau'. As you can see, there's no real change. On Sun, Jan 19,

On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > These chipsets include the VP2 engine which is composed of a bitstream > processor (BSP) that decodes H.264 and a video processor (VP) which can > do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are > driven by separate xtensa chips embedded in the hardware. This patch > provides the