On 24 July 2015 at 12:39, Ilia Mirkin wrote:
> On Thu, Jul 23, 2015 at 10:32 PM, Ben Skeggs wrote:
>> On 24 July 2015 at 01:20, Hans de Goede wrote:
>>> MSI interrupts appear to not work for nv46 based cards. Change the mc
>>> subdev oclass for these cards from nv4
On 24 July 2015 at 01:20, Hans de Goede wrote:
> MSI interrupts appear to not work for nv46 based cards. Change the mc
> subdev oclass for these cards from nv44 to nv4c, the nv4c mc code is
> identical to the nv44 mc code except that it does not use msi
> (it does not define a msi_rearm
On 23 June 2015 at 16:16, Alexandre Courbot wrote:
> Second version of this patchset. Not many changes since first version - I hope
> this means the changes are not too controversial.
>
> Changes since v1:
> - Removed lookup for previous FW files in "nouveau/"
> - Went back to using
On 19 June 2015 at 15:22, Alexandre Courbot wrote:
> On Fri, Jun 19, 2015 at 1:40 PM, Ben Skeggs wrote:
>> On 19 June 2015 at 00:47, Alexandre Courbot wrote:
>>> NVIDIA will officially start providing signed firmwares through
>>> linux-firmware. Change the GR firmw
On 19 June 2015 at 00:47, Alexandre Courbot wrote:
> NVIDIA will officially start providing signed firmwares through
> linux-firmware. Change the GR firmware lookup function to look them up
> in addition to the extracted firmwares.
I wonder if perhaps we should just replace the mechanism
On 5 June 2015 at 21:35, Thierry Reding wrote:
> On Thu, Oct 16, 2014 at 11:54:54AM +0200, Thierry Reding wrote:
>> From: Thierry Reding
>>
>> The memory allocated for a nouveau_cli object in nouveau_cli_create() is
>> never freed. Free the memory in nouveau_cli_destroy() to plug this leak.
>>
On 28 May 2015 at 16:40, Pierre Moreau wrote:
> Changes since v1:
> * Factorise testing of the 3 different _DSMs presence with a single function
Not overly important, but this part could be split out into an earlier
commit, keeping this commit just for adding the gmux support?
> * Check for gmux
ernel driver to make sure the object remains coherent
> even on architectures for which coherency is not guaranteed by the bus.
>
> Signed-off-by: Alexandre Courbot
Reviewed-by: Ben Skeggs
> ---
> Changes since v1:
> None, just added Martin so he can merge the patch. R-b and A
On 21 May 2015 at 16:04, Alexandre Courbot wrote:
> On Thu, May 21, 2015 at 2:55 PM, Ben Skeggs wrote:
>> On 21 May 2015 at 15:49, Alexandre Courbot wrote:
>>> On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs wrote:
>>>> On 20 May 2015 at 15:56, Alexandre Courbot wr
On 21 May 2015 at 15:49, Alexandre Courbot wrote:
> On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs wrote:
>> On 20 May 2015 at 15:56, Alexandre Courbot wrote:
>>> Add a module option allowing to enable staging/unstable APIs. This will
>>> allow us to experiment fr
On 20 May 2015 at 15:56, Alexandre Courbot wrote:
> Add a module option allowing to enable staging/unstable APIs. This will
> allow us to experiment freely with experimental APIs for a while before
> setting them in stone.
>
> Signed-off-by: Alexandre Courbot
> ---
> drm/nouveau/nouveau_drm.c
On 21 May 2015 at 06:01, Ilia Mirkin wrote:
> Some newer chips have trouble coming up, and we get bad MMIO reads from
> them, like 0xbadf100. This ends up translating into crazy amounts of
> VRAM, which destroys all sorts of other logic down the line. Instead,
> fail device init.
Hrm, I'm not
On Fri, Jan 30, 2015 at 6:27 PM, Dan Carpenter
wrote:
> This if statement is correct but it wasn't indented, so it looked like
> some code was missing.
Thanks Dan, applied (along with a fix for the owner thing you mentioned).
Ben.
>
> Signed-off-by: Dan Carpenter
>
> diff --git
On Sun, Jan 11, 2015 at 11:53 PM, Rickard Strandqvist
wrote:
Hey Rickard,
> Remove the function nvif_device_new() that is not used anywhere.
It's used, just not by the kernel. All the code under core/ and nvif/
is also built into a userspace library (not in the kernel tree,
obviously) and used
On 23 Dec 2014 00:27, "Bruno Prémont" wrote:
>
> On Mon, 22 Dec 2014 08:46:48 -0500 Rob Clark wrote:
> > On Sun, Dec 21, 2014 at 11:43 AM, Bruno Prémont wrote:
> > > On !SMP systems spinlocks do not exist. Thus checking of they
> > > are active will always fail.
> > >
> > > Use
> > >
- Original Message -
> From: "Rickard Strandqvist"
> To: "David Airlie" , "Ben Skeggs"
> Cc: "Rickard Strandqvist" ,
> "Alexandre Courbot" , "Ilia
> Mirkin" , dri-devel at lists.freedesktop.org,
> linux-ke
> \
> + (struct nouveau_object **)o)
> +
> int nv50_fb_ctor(struct nouveau_object *, struct nouveau_object *,
> struct nouveau_oclass *, void *, u32,
> struct nouveau_object **);
> diff --git a/
DWords).
>>
>> Do not include the header size in Baseline_ELD_Len field. Fix all known
>> users of eld[2].
>>
>> While at it, switch to DIV_ROUND_UP instead of open coding it.
>>
>> Signed-off-by: Jani Nikula
Acked-by: Ben Skeggs
>>
>> ---
&g
Alex Deucher
> Cc: "Christian K?nig"
> Cc: David Herrmann
> Cc: Rashika
> Cc: Josh Triplett
> Cc: Daniel Vetter
> Cc: Fabian Frederick
> Cc: Gerd Hoffmann
> Cc: Ben Skeggs
> Cc: Alexandre Courbot
> Cc: Maarten Lankhorst
> Cc: Christian Eng
l that may wait on the about-to-be-deleted channel to signal.
>>
>> I'm nothing if not optimistic about any hope of recovery from that. ;-)
>>
>> Reported-by: Ted Percival
>> Signed-off-by: Maarten Lankhorst
Acked-by: Ben Skeggs
I'm still seeing issues with suspend
define NV04_PFB_DEBUG_0_PAGE_MODE 0x0001
> # define NV04_PFB_DEBUG_0_REFRESH_OFF 0x0010
> diff --git a/nvkm/subdev/fb/ramnv04.c b/nvkm/subdev/fb/ramnv04.c
> index e781080..1972268 100644
> --- a/nvkm/subdev/fb/ramnv04.c
> +++ b
- Original Message -
> From: "Dan Carpenter"
> To: bskeggs at redhat.com
> Cc: dri-devel at lists.freedesktop.org
> Sent: Wednesday, 13 August, 2014 9:29:16 PM
> Subject: re: drm/nv50-/disp: audit and version DAC_LOAD method
>
> Hello Ben Skeggs,
>
&
On Mon, Aug 4, 2014 at 5:32 PM, Daniel Vetter wrote:
> 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.
On Mon, Aug 4, 2014 at 7:28 PM, Alexandre Courbot
wrote:
> Pages allocated using the DMA API have a coherent memory mapping. Make
> this mapping visible to drivers so they can decide to use it instead of
> creating their own redundant one.
I've picked this up in nouveau's linux-3.17 staging
On Fri, Jul 11, 2014 at 12:35 PM, Alexandre Courbot
wrote:
> On 07/10/2014 09:58 PM, Daniel Vetter wrote:
>>
>> 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
On Fri, Jul 11, 2014 at 11:49 AM, Alexandre Courbot
wrote:
> On 07/10/2014 06:43 PM, Peter De Schrijver wrote:
>>
>> On Thu, Jul 10, 2014 at 09:34:34AM +0200, Alexandre Courbot wrote:
>>>
>>> This series adds support for reclocking on GK20A. The first two patches
>>> touch
>>> the clock
On Thu, Jul 10, 2014 at 5:34 PM, Alexandre Courbot
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
>
On Fri, Jul 4, 2014 at 5:27 AM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> ---
>
> Based on a recent discussion in #radeon, and also my own observation that the
> 'full' scaling causes no end of confusion among users.
>
> See https://bugs.freedesktop.org/show_bug.cgi?id=80868 for some
On Sat, Jun 28, 2014 at 11:41 AM, Ken Adams wrote:
>
> On 6/27/14 8:56 PM, "Ben Skeggs" wrote:
>
>>On Sat, Jun 28, 2014 at 4:51 AM, Ken Adams wrote:
>>> quick note re: tegra and gpu bars...
>>>
>>> to this point we've explicitly avoi
On Sat, Jun 28, 2014 at 4:51 AM, Ken Adams wrote:
> quick note re: tegra and gpu bars...
>
> to this point we've explicitly avoided providing user-mode mappings due to
> power management issues, etc.
> looks to me like this would allow such mappings. is that the case? are
> there any paths
On Tue, Jun 24, 2014 at 6:26 AM, Greg KH wrote:
> On Mon, Jun 23, 2014 at 04:18:39PM -0400, Ilia Mirkin wrote:
>> On Mon, Jun 23, 2014 at 4:15 PM, Pavel Machek wrote:
>> > Hi!
>> >
>> >> >> >> > I guess better interface would be something like
>> >> >> >> >
>> >> >> >> > pstate/07/core_clock_min
- Original Message -
> From: "Heinrich Schuchardt"
> To: "David Airlie"
> Cc: "Ben Skeggs" , dri-devel at lists.freedesktop.org,
> linux-kernel at vger.kernel.org, "Heinrich
> Schuchardt"
> Sent: Thursday, 19 June, 2014 5:
On Wed, Jun 18, 2014 at 12:38 AM, Maarten Lankhorst
wrote:
> Hey,
>
> This patch causes a regression on my display-less nvd7.
> Commenting out the aux, aux_stat and aux_mask members in nvd0_i2c_oclass
> fixes boot, and makes things work normally again.
>
Hey Maarten,
Yeah that probably makes
On Tue, Jun 17, 2014 at 11:01 PM, Maarten Lankhorst
wrote:
> If init doesn't run then disp->outp might not be initialized, resulting in an
> oops.
This can't actually happen (in the very least, it's not supposed
to)... What makes you think it can?
>
> Signed-off-by: Maarten Lankhorst
> ---
>
On Fri, Jun 13, 2014 at 10:34 AM, Pierre Moreau
wrote:
> The specified stride was not correct, resulting in erases overlapping and part
> of the zcull regions being not erased at all.
Hey Pierre,
Thanks, I've merged both patches.
>
> Signed-off-by: Pierre Moreau
> ---
>
ult of video.use_native_backlight=1 will cause
>> regressions.
>>
>> Note this effectively reverts commit 5bead799
>>
>> Also see: https://bugzilla.redhat.com/show_bug.cgi?id=1093171
>>
>> Signed-off-by: Hans de Goede
>
> It would be good to have an ACK from the
On Sat, May 17, 2014 at 2:06 PM, Ilia Mirkin wrote:
> On Fri, May 16, 2014 at 11:54 PM, Ben Skeggs wrote:
>> On 17 May 2014 13:39, "Ilia Mirkin" wrote:
>>>
>>> On Fri, May 16, 2014 at 11:17 PM, Ben Skeggs wrote:
>>> > On 17 May 2014 02:43, &qu
On 17 May 2014 13:39, "Ilia Mirkin" wrote:
>
> On Fri, May 16, 2014 at 11:17 PM, Ben Skeggs wrote:
> > On 17 May 2014 02:43, "Ilia Mirkin" wrote:
> >>
> >> Adds a NvReclock boolean option to allow the user to enable (or
disable)
> >>
On 17 May 2014 02:43, "Ilia Mirkin" 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
On Fri, May 9, 2014 at 5:57 PM, Alexandre Courbot
wrote:
> gk20a_ram_put() can be called with a NULL nouveau_mem in case of error.
> Handle that case the way is it done in other RAM drivers.
Got it, thanks!
>
> Signed-off-by: Alexandre Courbot
> ---
>
On Wed, May 7, 2014 at 9:20 AM, Dave Airlie wrote:
> So now I've been playing with MST I think get the feeling I might need
> some explicit locking on the AUX channel, I think at the moment the
> mode_config mutex implicitly defends the aux channel as the only real
> paths into it are
>
> a) from
On Fri, May 2, 2014 at 7:32 PM, Alexandre Courbot
wrote:
> Latest patches for GK20A, taking comments received for v3 into account.
>
> Changes since v3:
> - use only pfn_to_page() and page_to_pfn() in GK20A's FB. These functions
> are present on every arch and the physical address to page
On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot
wrote:
> Changes since v2:
> - Enabled software class
> - Removed unneeded changes to nouveau_accel_init()
> - Replaced use of architecture-private pfn_to_dma() and dma_to_pfn() with
> the portable page_to_phys()/phys_to_page()
page_to_phys()
On Thu, May 1, 2014 at 2:53 PM, Alexandre Courbot wrote:
> On Mon, Apr 28, 2014 at 11:10 AM, Ben Skeggs wrote:
>> On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot
>> wrote:
>>> nvc0_graph_ctor() would only let the graphics engine be enabled if its
>>> ocl
On Mon, Apr 28, 2014 at 4:57 PM, Thierry Reding
wrote:
> On Mon, Apr 28, 2014 at 12:10:27PM +1000, Ben Skeggs wrote:
>> On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot
>> wrote:
>> > nvc0_graph_ctor() would only let the graphics engine be enabled if its
>> &
On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot
wrote:
> nvc0_graph_ctor() would only let the graphics engine be enabled if its
> oclass has a proper microcode linked to it. This prevents GR from being
> enabled at all on chips that rely exclusively on external firmware, even
> though such a
On Tue, Apr 22, 2014 at 4:07 AM, Ilia Mirkin wrote:
> On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot
> wrote:
>> Skip the creation of a software channel for GK20A as software methods
>> are not yet supported.
>
> How is GK20A different from a nvc0+ card that lacks PDISPLAY (like all
> the
On Tue, Apr 22, 2014 at 4:03 AM, Ilia Mirkin wrote:
> On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot
> wrote:
>> Pad the microcode to a multiple of 0x40 bytes, otherwise firmware will
>
> bytes or u32's? From the code, I'm guessing the latter. (Similar
> concern about comment in the code.)
- Original Message -
> From: "Daeseok Youn"
> To: airlied at linux.ie
> Cc: bskeggs at redhat.com, dri-devel at lists.freedesktop.org, linux-kernel
> at vger.kernel.org
> Sent: Tuesday, 15 April, 2014 11:56:49 AM
> Subject: [PATCH] drm/nouveau/clk: fix possible NULL pointer dereference
>
On Fri, Apr 11, 2014 at 5:34 PM, Alexandre Courbot
wrote:
> On 04/11/2014 04:31 PM, Ben Skeggs wrote:
>>
>> On Fri, Apr 11, 2014 at 12:46 PM, Alexandre Courbot
>> wrote:
>>>
>>> On Wed, Mar 26, 2014 at 1:19 PM, Ben Skeggs wrote:
>>>>
&
t; Signed-off-by: Andreas Noever
Signed-off-by: Ben Skeggs
> ---
> drivers/gpu/drm/nouveau/core/subdev/bios/base.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/base.c
> b/drivers/gpu/drm/nouveau/core/subdev/b
On Fri, Apr 11, 2014 at 12:46 PM, Alexandre Courbot wrote:
> On Wed, Mar 26, 2014 at 1:19 PM, Ben Skeggs wrote:
>> On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding
>> wrote:
>>> On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote:
>>>>
On Thu, Apr 3, 2014 at 12:23 AM, Ilia Mirkin wrote:
> On Wed, Apr 2, 2014 at 10:14 AM, Alexandre Courbot
> wrote:
> + /* Need to figure out how to handle sw for gk20a */
> + if (device->chipset == 0xea)
> + goto skip_sw_init;
The commit message makes it
On Thu, Apr 3, 2014 at 12:03 AM, Alexandre Courbot wrote:
> On Wed, Mar 26, 2014 at 1:24 PM, Ben Skeggs wrote:
>> On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot
>> wrote:
>>> Add a GR device for GK20A based on NVE4, with the correct classes
>>> defini
On Thu, Mar 27, 2014 at 9:37 AM, Ilia Mirkin wrote:
> There appear to be a crop of new hardware where the vbios is not
> available from PROM/PRAMIN, but there is a valid _ROM method in ACPI.
> The data read from PCIROM almost invariably contains invalid
> instructions (still has the x86 opcodes),
On Thu, Mar 13, 2014 at 12:05 PM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
Already said on IRC, but for posterity:
Reviewed-by: Ben Skeggs
> ---
> nouveau/nouveau.c | 29 -
> nouveau/private.h | 3 ++-
> 2 files changed, 30 insertions(
On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot
wrote:
> Set the correct subdev/engine classes when GK20A (0xea) is probed.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/gpu/drm/nouveau/core/engine/device/nve0.c | 20
> 1 file changed, 20 insertions(+)
>
> diff
On Tue, Mar 25, 2014 at 9:10 AM, Thierry Reding
wrote:
> On Mon, Mar 24, 2014 at 05:42:33PM +0900, Alexandre Courbot wrote:
>> GK20A does not embed a dedicated COPY engine and thus cannot allocate
>> the copy channel that nouveau_accel_init() attempts to create. It also
>> lacks any display
On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot
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
On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot
wrote:
> Pad the microcode to a multiple of 0x40, otherwise firmware will fail to
> run from non-prepadded firmware files.
>
> Signed-off-by: Alexandre Courbot
> ---
> drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4
> 1 file
On Tue, Mar 25, 2014 at 8:58 AM, Thierry Reding
wrote:
> On Mon, Mar 24, 2014 at 05:42:30PM +0900, Alexandre Courbot wrote:
> [...]
>> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> index 6ef8bf181b2d..f997a18f5760 100644
>>
On Tue, Mar 25, 2014 at 8:13 AM, Thierry Reding
wrote:
> On Mon, Mar 24, 2014 at 05:42:25PM +0900, Alexandre Courbot wrote:
>> 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
On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding
wrote:
> On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote:
>> GK20A's timer is directly attached to the system timer and cannot be
>> calibrated. Skip the calibration phase on that chip since the
>> corresponding registers do not
On Wed, Feb 12, 2014 at 11:41 AM, Emil Velikov
wrote:
> commit 8613e7314ac254fdd67ed46192f021d76141e4c9
> Author: Ben Skeggs
> Date: Mon Oct 21 08:50:25 2013 +1000
>
> drm/nouveau/fb: remove ram oclass argument from base fb constructor
>
> Introduced a unfortunate reg
On Mon, Feb 10, 2014 at 6:51 AM, Ilia Mirkin wrote:
> The ffsll function is a lot slower than the __ffs64 built-in which
> compiles to a single instruction on 64-bit. It's also nice to avoid
> custom versions of standard functions. Note that __ffs == ffs - 1.
>
> Signed-off-by: Ilia Mirkin
On Sun, Feb 9, 2014 at 1:35 PM, Ilia Mirkin wrote:
> Commit ea7dce901 ("drm/nv50/gr: print mpc trap name when it's not an mp
> trap") added an nv_error call that was missing the priv parameter. This
> causes GPFs if the error is ever hit.
>
> Signed-off-by: Ilia Mirkin
Merged, thanks :)
> ---
>
On Fri, Feb 7, 2014 at 11:22 PM, Alexandre Courbot
wrote:
> Address of the ENG_RUNLIST register should be 0x002284 + (engine * 8),
> not 0x002284 + (engine * 4).
>
> Signed-off-by: Alexandre Courbot
> ---
> Stumbled upon this one and I'm quite certain the offset was not correct.
> This is
- Original Message -
> From: "Dan Carpenter"
> To: "David Airlie"
> Cc: "Ben Skeggs" , "Martin Peres" labri.fr>, "Ilia Mirkin" ,
> "Dave Airlie" , dri-devel at lists.freedesktop.org,
> kernel-janitors at v
- Original Message -
> From: "Jingoo Han"
> To: "Ben Skeggs"
> Cc: dri-devel at lists.freedesktop.org, "David Airlie" ,
> "Jingoo Han"
> Sent: Wednesday, 5 February, 2014 12:02:59 PM
> Subject: [PATCH] drm/nouveau/hw
On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot
wrote:
> GK20A's timer is directly attached to the system timer and cannot be
> calibrated. Skip the calibration phase on that chip since the
> corresponding registers do not exist.
Just a curiosity: What timer resolution does the HW initialise
On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot
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
On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot
wrote:
> Hello everyone,
Hey Alex,
The series looks pretty good to me. I'll reply to the relevant
patches with any minor nit-picks on top of what's already been said by
others.
Thank you, and welcome to Nouveau :)
Ben.
>
> GK20A is the
On Mon, Feb 3, 2014 at 1:14 PM, Ilia Mirkin wrote:
> On Sun, Feb 2, 2014 at 9:44 PM, Alexandre Courbot
> wrote:
>> One beginner question: is it appropriate to send kernel patches to the
>> nouveau list in addition to dri-devel? The moderation messages I receive
>> make me think that this list
On Tue, Jan 14, 2014 at 3:07 PM, Ben Skeggs wrote:
> On Tue, Jan 14, 2014 at 1:22 PM, Bob Gleitsmann
> wrote:
>> I should have mentioned that this applies to Linus' 3.13.0-rc7 and rc8
>> git. Maybe it's obvious.
> Hey Bob,
>
> Thanks for reporting this. Can you try
On Tue, Jan 14, 2014 at 1:22 PM, Bob Gleitsmann
wrote:
> I should have mentioned that this applies to Linus' 3.13.0-rc7 and rc8
> git. Maybe it's obvious.
Hey Bob,
Thanks for reporting this. Can you try the attached patch instead and
report if it helps you?
Ben.
>
> Sorry about that.
>
> Bob
- Original Message -
> From: "Ilia Mirkin"
> To: "Ben Skeggs"
> Cc: dri-devel at lists.freedesktop.org, "Ilia Mirkin" alum.mit.edu>
> Sent: Wednesday, 8 January, 2014 3:33:59 AM
> Subject: [PATCH] drm/nouveau/bios: fix offset calculati
On Fri, Nov 29, 2013 at 4:01 PM, Benjamin Herrenschmidt
wrote:
> On Thu, 2013-08-29 at 16:49 +1000, Ben Skeggs wrote:
>
>> > Additionally the current code is broken in that the upper layer in
>> > vm/base.c doesn't increment "pte" by the right amount.
>>
- Original Message -
> From: "Dan Carpenter"
> To: bskeggs at redhat.com
> Cc: dri-devel at lists.freedesktop.org
> Sent: Wednesday, 27 November, 2013 7:30:27 AM
> Subject: re: drm/nvd0/disp: initial crtc object implementation
>
> Hello Ben Skeggs,
>
&
- Original Message -
> From: "Dan Carpenter"
> To: bskeggs at redhat.com
> Cc: dri-devel at lists.freedesktop.org
> Sent: Tuesday, 12 November, 2013 7:54:33 PM
> Subject: re: drm/nouveau/pwr: initial implementation
>
> Hello Ben Skeggs,
Hey,
>
> The
- Original Message -
From: Geyslan G. Bem geys...@gmail.com
To: airl...@linux.ie, bske...@redhat.com, dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org, kernel...@googlegroups.com, Geyslan G.
Bem geys...@gmail.com
Sent: Tuesday, 8 October, 2013 8:14:26 AM
Subject:
- Original Message -
From: Geyslan Gregório Bem geys...@gmail.com
To: Felipe Pena felipe...@gmail.com
Cc: Ben Skeggs bske...@redhat.com, airl...@linux.ie,
dri-devel@lists.freedesktop.org,
linux-ker...@vger.kernel.org, kernel-br kernel...@googlegroups.com
Sent: Tuesday, 8 October
On Sat, Sep 28, 2013 at 6:17 AM, Dan Carpenter dan.carpen...@oracle.com wrote:
The test here should be = ARRAY_SIZE() instead of ARRAY_SIZE().
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Acked-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
Somehow this wasn't applied
On Thu, Sep 26, 2013 at 12:41 AM, Pasi Kärkkäinen pa...@iki.fi wrote:
Hello,
On Wed, Sep 04, 2013 at 08:59:13AM +0200, Maarten Lankhorst wrote:
Op 04-09-13 05:41, Ben Skeggs schreef:
On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Op 22-08-13 02
to avoid
gem-internal dependencies.
Note that the implementation follows the previous style. However, we no
longer can check for bo-gem != NULL to test for a valid gem object. This
wasn't done before, so we should be safe now.
Cc: Ben Skeggs skeg...@gmail.com
Cc: Maarten Lankhorst maarten.lankho
On Fri, Sep 20, 2013 at 2:40 AM, Damien Lespiau
damien.lesp...@intel.com wrote:
This field was only accessed by the nouveau driver, but never set. So
concluded we can rid of this one.
Cc: Ben Skeggs bske...@redhat.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Acked-by: Ben Skeggs
From: Ben Skeggs bske...@redhat.com
After a vmalloc failure in ttm_dma_tt_alloc_page_directory(),
ttm_dma_tt_init() will call ttm_tt_destroy() to cleanup, and end up
inside the driver's unpopulate() hook when populate() has never yet
been called.
On nouveau, the first issue to be hit because
On Wed, Sep 4, 2013 at 11:25 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Op 04-09-13 03:24, Ben Skeggs schreef:
On Mon, Jul 15, 2013 at 6:39 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Op 15-07-13 08:05, Ben Skeggs schreef:
On Fri, Jul 12, 2013 at 10:45 PM
On Wed, Sep 4, 2013 at 9:59 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Op 04-09-13 05:34, Ben Skeggs schreef:
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
There are a lot of places that allocate multiples of 1000,
but do not set
On Tue, Sep 10, 2013 at 12:08 PM, Rob Clark robdcl...@gmail.com wrote:
On Sat, Sep 7, 2013 at 9:36 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
Reviewed-by: Rob Clark robdcl...@gmail.com
Reviewed-and-tested-by: Ben Skeggs bske...@redhat.com
On Sun, Sep 8, 2013 at 9:25 PM, Pali Rohár pali.ro...@gmail.com wrote:
On Wednesday 21 August 2013 02:24:01 Ben Skeggs wrote:
On Mon, Aug 19, 2013 at 4:59 PM, Pali Rohár
pali.ro...@gmail.com wrote:
On Friday 16 August 2013 14:57:07 Pali Rohár wrote:
In commit
On Sun, Sep 8, 2013 at 10:33 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
This has received light testing on NV18 and NV34 cards, using the modetest
tool. Userspace support to use this for xv is not yet ready.
I decided against creating a
On Wed, Sep 4, 2013 at 10:37 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Op 04-09-13 05:21, Ben Skeggs schreef:
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
This increases the chance slightly that recovery from lockup can happen
On Sat, Aug 24, 2013 at 3:03 AM, Ilia Mirkin imir...@alum.mit.edu wrote:
i2c_bit_add_bus can call the pre_xfer function, which expects the func
pointer to be set. Pass in func to the port creation logic so that it is
set before i2c_bit_add_bus.
Merged, thanks!
Ben.
See
On Mon, Jul 15, 2013 at 6:39 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Op 15-07-13 08:05, Ben Skeggs schreef:
On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
I have no idea what this bogus restriction on placement is, but it breaks
On Fri, Aug 30, 2013 at 5:11 PM, Lucas Stach d...@lynxeye.de wrote:
Am Freitag, den 30.08.2013, 15:36 +1000 schrieb Ben Skeggs:
On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs skeg...@gmail.com wrote:
On Fri, Aug 30, 2013
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
This increases the chance slightly that recovery from lockup can happen
succesfully.
I'd *really* love to see proof of this. When channels die, all
outstanding fences are marked as signalled. This should
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
I don't see why the display engine would need write access to the entirety of
vram, when read-only access is enough.
Meh, this really doesn't matter... We're doing the same setup as
nvidia do here, and I
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
I was getting a order 4 allocation failure from kmalloc when testing some game
after a few days uptime with some suspend/resumes. For big allocations vmalloc
should be used instead.
I've picked up this
On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
There are a lot of places that allocate multiples of 1000,
but do not set alignment correctly and still require this
alignment implicitly or explicitly.
This is wrong. Where are the places you think you
On Thu, Aug 22, 2013 at 5:12 PM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Op 22-08-13 02:10, Ilia Mirkin schreef:
The code expects non-VRAM mem nodes to have a pages list. If that's not
set, it will do a null deref down the line. Warn on that condition and
return an error.
301 - 400 of 636 matches
Mail list logo
