similar to: [PATCH] drm/nouveau: allow nv04/nv50/nvc0+ parts of the driver to be separated

On Fri, Feb 14, 2014 at 7:38 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > So... I was wondering what the impact of splitting up the card compilation by > e.g. generation would be. Depending on the split things would get fairly > intertwined, so I thought I'd start small. This just splits NVC0 from > everything else. I figure that for the people this matters the most to,

So... I was wondering what the impact of splitting up the card compilation by e.g. generation would be. Depending on the split things would get fairly intertwined, so I thought I'd start small. This just splits NVC0 from everything else. I figure that for the people this matters the most to, NVC0 is the least relevant card -- people with sub-1GB of RAM, older hardware. With my config options

Op 14-09-14 om 10:31 schreef poma: > On 13.09.2014 23:45, Roy Spliet wrote: >> Dear Poma, >> >> Don't get anyone wrong, your input is greatly valued. The reason why >> "we" (nouveau developers) generally ask for a git bisection is because >> we don't know or track specific distributions. Although your search has >> narrowed the problem down

On 14.09.2014 11:53, Roy Spliet wrote: > Op 14-09-14 om 10:31 schreef poma: >> On 13.09.2014 23:45, Roy Spliet wrote: >>> Dear Poma, >>> >>> Don't get anyone wrong, your input is greatly valued. The reason why >>> "we" (nouveau developers) generally ask for a git bisection is because >>> we don't know or track specific

On 13.09.2014 23:45, Roy Spliet wrote: > Dear Poma, > > Don't get anyone wrong, your input is greatly valued. The reason why > "we" (nouveau developers) generally ask for a git bisection is because > we don't know or track specific distributions. Although your search has > narrowed the problem down (thanks for that!), we don't know how big the >

On 17 May 2014 02:43, "Ilia Mirkin" <imirkin at alum.mit.edu> wrote: > > Adds a NvReclock boolean option to allow the user to enable (or disable) > reclocking. All chipsets default to off, except NVAA/NVAC, which are > reportedly complete. Hey Ilia, I think I've expressed my thoughts on this previously via IRC, but let me stick them here too so there's a record

Adds a NvReclock boolean option to allow the user to enable (or disable) reclocking. All chipsets default to off, except NVAA/NVAC, which are reportedly complete. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Ben, I know you've been saying that reclocking is in a pretty bad state, but I do think that there are going to be groups of people for whom the current code can work

On Sat, Aug 31, 2013 at 10:06 AM, Martin Peres <martin.peres at free.fr> wrote: > From: Martin Peres <martin.peres at labri.fr> > > This is safe because ptherm hasn't been configured yet and will be a > little further down the initialization path. Ptherm should be safe > regarding to runtime reconfiguration. Any objections to instead sticking the ACK in a single

From: Martin Peres <martin.peres at labri.fr> This is safe because ptherm hasn't been configured yet and will be a little further down the initialization path. Ptherm should be safe regarding to runtime reconfiguration. v2: - do not limit this patch to nv84-a3 and make it nv84+ Signed-off-by: Martin Peres <martin.peres at labri.fr> ---

Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/core/core/gpuobj.c | 2 +- drivers/gpu/drm/nouveau/core/core/object.c | 8 ++++---- drivers/gpu/drm/nouveau/core/core/option.c | 2 +- .../drm/nouveau/core/engine/copy/fuc/nva3.fuc.h | 4 ++-- .../drm/nouveau/core/engine/copy/fuc/nvc0.fuc.h | 4 ++--

From: Martin Peres <martin.peres at labri.fr> This is safe because ptherm hasn't been configured yet and will be a little further down the initialization path. Ptherm should be safe regarding to runtime reconfiguration. v2: - do not limit this patch to nv84-a3 and make it nv84+ v3: - move the ack to fini() - disable IRQs on fini() - silently ignore un-requested IRQs

From: Martin Peres <martin.peres at labri.fr> Signed-off-by: Martin Peres <martin.peres at free.fr> --- drm/Kbuild | 1 + drm/core/subdev/therm/gm107.c | 1 + nvkm/engine/device/gm100.c | 4 +- nvkm/include/subdev/therm.h | 1 + nvkm/subdev/therm/Makefile.am | 3 +- nvkm/subdev/therm/fan.c | 9 ++++- nvkm/subdev/therm/gm107.c | 93

Hi Roy, On Fri, Jul 11, 2014 at 7:05 AM, Roy Spliet <seven at nimrod-online.com> wrote: > Hey Alex, > > Thanks. I have a couple of questions and remarks, but really, those should > be treated as discussion points rather than anything else. Besides some > inline comments, I was curious whether it is not necessary to pause PFIFO > and the engines like done with at least

Does GK20A itself have any kind of thermal protection capabilities? Upstream SOCTHERM support is not yet available (though I have a driver in my tree), so we are thinking of disabling CPU DVFS on boards that don't have always-on active cooling for now. Same might be necessary for GPU as well. On 10/07/14 10:34, Alexandre Courbot wrote: > This series adds support for reclocking on

On Sat, Jul 26, 2014 at 7:41 PM, Alexandre Courbot <gnurou at gmail.com> wrote: > Second version of the gk20a clock patches. I have tried to keep the therm and > volt devices mandatory in the clock driver, but unfortunately they are too tied > to bios to allow this, at least for the moment. Consequently this version is > mostly a port of the first version to Ben's tree.

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

For NV98+, BSP/VP/PPP are all FUC-based engines. Hook them all up in the same way as NVC0, but with a couple of different values. Also make sure that the PPP engine is handled in the fifo/mc/vm. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- It seems like VP4.0 is basically working here... only mpeg2/vc1 work, but I'm pretty sure that's just a user-side issue. My guess is

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 Thu, Jul 10, 2014 at 5:34 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > This series adds support for reclocking on GK20A. The first two patches touch > the clock subsystem to allow GK20A to operate, by making the presence of the > thermal and voltage devices optional, and allowing pstates to be provided > directly instead of being probed using the BIOS (which Tegra

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