On Tue, Sep 3, 2013 at 12:31 AM, Maarten Lankhorst
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 do absolutely
nothing...
>
>
On Fri, Aug 30, 2013 at 5:11 PM, Lucas Stach wrote:
> Am Freitag, den 30.08.2013, 15:36 +1000 schrieb Ben Skeggs:
>> On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin wrote:
>> > On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs wrote:
>> >> On Fri, Aug 30, 2013 at 11:10
On Mon, Jul 15, 2013 at 6:39 PM, Maarten Lankhorst
wrote:
> Op 15-07-13 08:05, Ben Skeggs schreef:
>> On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
>> wrote:
>>> I have no idea what this bogus restriction on placement is, but it breaks
>>> decoding 1080p
&
On Sat, Aug 24, 2013 at 3:03 AM, Ilia Mirkin 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 https://bugs.freedesktop.org/show_bug
On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin wrote:
> On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs wrote:
>> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin
>> wrote:
>>> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
>>>> On Thu, Aug 29, 2013 at 3:00 PM
On Fri, Aug 30, 2013 at 11:58 AM, Ben Skeggs wrote:
> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin wrote:
>> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
>>> On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin
>>> wrote:
>>>> On Thu, Aug 29, 2013 at 12
On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin wrote:
> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
>> On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin wrote:
>>> On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs wrote:
>>>> On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mir
On Fri, Aug 30, 2013 at 12:01 PM, Ilia Mirkin wrote:
> On Thu, Aug 29, 2013 at 9:58 PM, Ben Skeggs wrote:
>> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin wrote:
>>> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
>>>> On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mi
On Fri, Aug 30, 2013 at 11:58 AM, Ben Skeggs wrote:
> On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin wrote:
>> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
>>> On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin wrote:
>>>> On Thu, Aug 29, 2013 at 12:45 AM, Ben Sk
On Fri, Aug 30, 2013 at 11:10 AM, Ilia Mirkin wrote:
> On Thu, Aug 29, 2013 at 1:07 AM, Ben Skeggs wrote:
>> On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin wrote:
>>> On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs wrote:
>>>> On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mi
On Sun, Aug 11, 2013 at 7:35 PM, Benjamin Herrenschmidt
wrote:
> On Sun, 2013-08-11 at 11:02 +0200, Maarten Lankhorst wrote:
>
>> > diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
>> > b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
>> > index 5c7433d..c314a5f 100644
>> > --- a/dri
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin wrote:
> On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs wrote:
>> On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin
>> wrote:
>>> On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs wrote:
>>>> On Wed, Aug 28, 2013 at 11:54 PM
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin wrote:
> On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs wrote:
>> On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin
>> wrote:
>>> On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach wrote:
>>>> Am Mittwoch, den 28.08.
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin wrote:
> On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach wrote:
>> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
>>> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach wrote:
>>> > MSIs were only problematic on
On Sun, Aug 11, 2013 at 7:35 PM, Benjamin Herrenschmidt
wrote:
> On Sun, 2013-08-11 at 11:02 +0200, Maarten Lankhorst wrote:
>
>> > diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
>> > b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c
>> > index 5c7433d..c314a5f 100644
>> > --- a/dri
On Thu, Aug 29, 2013 at 3:00 PM, Ilia Mirkin wrote:
> On Thu, Aug 29, 2013 at 12:45 AM, Ben Skeggs wrote:
>> On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin wrote:
>>> On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs wrote:
>>>> On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mi
On Thu, Aug 29, 2013 at 12:20 PM, Ilia Mirkin wrote:
> On Wed, Aug 28, 2013 at 8:07 PM, Ben Skeggs wrote:
>> On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin wrote:
>>> On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach wrote:
>>>> Am Mittwoch, den 28.08.2013, 17:09 +100
On Wed, Aug 28, 2013 at 5:50 PM, Thierry Reding
wrote:
> On Wed, Aug 28, 2013 at 02:00:44AM +0200, Lucas Stach wrote:
>> This is the first set of patches to make Nouveau work
>> on Tegra.
>
> Perhaps you should clarify that this patch series allows discrete GPUs
> to be used via Tegra's PCIe inter
On Wed, Aug 28, 2013 at 6:12 AM, Peter Hurley
wrote:
> This series was originally motivated by a deadlock, introduced in
> commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b
> 'drm/nouveau/disp: port vblank handling to event interface',
> due to inverted lock order between nouveau_drm_vblank_enable(
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach wrote:
> This flag allows userspace to give the kernel a hint that it should use
> a non-snooped resource. To guarantee coherency at all times mappings
> into userspace are done write combined, so userspace should avoid
> reading back from those resour
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach wrote:
> MSIs were only problematic on some old, broken chipsets. But now that we
> already see systems where PCI legacy interrupts are somewhat flaky, it's
> really time to move to MSIs.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/nouveau
On Wed, Aug 28, 2013 at 11:54 PM, Ilia Mirkin wrote:
> On Wed, Aug 28, 2013 at 3:28 AM, Lucas Stach wrote:
>> Am Mittwoch, den 28.08.2013, 17:09 +1000 schrieb Ben Skeggs:
>>> On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach wrote:
>>> > MSIs were only problematic on
On Wed, Aug 28, 2013 at 5:50 PM, Thierry Reding
wrote:
> On Wed, Aug 28, 2013 at 02:00:44AM +0200, Lucas Stach wrote:
>> This is the first set of patches to make Nouveau work
>> on Tegra.
>
> Perhaps you should clarify that this patch series allows discrete GPUs
> to be used via Tegra's PCIe inter
On Wed, Aug 28, 2013 at 6:12 AM, Peter Hurley wrote:
> This series was originally motivated by a deadlock, introduced in
> commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b
> 'drm/nouveau/disp: port vblank handling to event interface',
> due to inverted lock order between nouveau_drm_vblank_enable()
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach wrote:
> This flag allows userspace to give the kernel a hint that it should use
> a non-snooped resource. To guarantee coherency at all times mappings
> into userspace are done write combined, so userspace should avoid
> reading back from those resour
On Wed, Aug 28, 2013 at 10:00 AM, Lucas Stach wrote:
> MSIs were only problematic on some old, broken chipsets. But now that we
> already see systems where PCI legacy interrupts are somewhat flaky, it's
> really time to move to MSIs.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/nouveau
On Thu, Aug 22, 2013 at 10:10 AM, Ilia Mirkin wrote:
> 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.
>
> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
>
> Reported-by: Pas
On Thu, Aug 22, 2013 at 10:10 AM, Ilia Mirkin wrote:
> 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.
>
> See https://bugs.freedesktop.org/show_bug.cgi?id=64774
>
> Reported-by: Pas
On Mon, Aug 19, 2013 at 4:59 PM, Pali Roh?r wrote:
> On Friday 16 August 2013 14:57:07 Pali Roh?r wrote:
>> In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
>> introduced error which cause that reclocking on nv40 not
>> working anymore. There is missing assigment of return value
>> from pll_
On Mon, Aug 19, 2013 at 4:59 PM, Pali Rohár wrote:
> On Friday 16 August 2013 14:57:07 Pali Rohár wrote:
>> In commit 77145f1cbdf8d28b46ff8070ca749bad821e0774 was
>> introduced error which cause that reclocking on nv40 not
>> working anymore. There is missing assigment of return value
>> from pll_
On Thu, Aug 8, 2013 at 1:16 AM, Maarten Lankhorst
wrote:
> Allocating type=0 marks the memory as free. This allows the ltcg memory to be
> allocated twice. Add a BUG_ON in core/mm.c to prevent this ever happening
> again.
> Additionally some registers were not initialized in init, this causes the
On Thu, Aug 8, 2013 at 1:24 AM, Maarten Lankhorst
wrote:
> It's my megabyte, I want to use it! At this point in init
> vbios is copied over already, so there's no reason it cannot
> used to hold other data now.
I believe there's areas in here where the SBIOS/VBIOS can communicate
to the driver on
On Thu, Aug 8, 2013 at 1:16 AM, Maarten Lankhorst
wrote:
> Allocating type=0 marks the memory as free. This allows the ltcg memory to be
> allocated twice. Add a BUG_ON in core/mm.c to prevent this ever happening
> again.
> Additionally some registers were not initialized in init, this causes the
On Thu, Aug 8, 2013 at 1:24 AM, Maarten Lankhorst
wrote:
> It's my megabyte, I want to use it! At this point in init
> vbios is copied over already, so there's no reason it cannot
> used to hold other data now.
I believe there's areas in here where the SBIOS/VBIOS can communicate
to the driver on
On Tue, Jul 30, 2013 at 4:10 PM, Maarten Lankhorst
wrote:
> Op 30-07-13 04:42, Ben Skeggs schreef:
>> On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst
>> wrote:
>>> Sort of fixes mmiotrace for me again, I could sear I sent a similar patch
>>> before
>&g
On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst
wrote:
> Sort of fixes mmiotrace for me again, I could sear I sent a similar patch
> before
> the rework to event interface, so I guess it got reintroduced.
I don't know how/why you think this fixes anything. The interrupt
handler can't possibl
On Tue, Jul 30, 2013 at 4:10 PM, Maarten Lankhorst
wrote:
> Op 30-07-13 04:42, Ben Skeggs schreef:
>> On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst
>> wrote:
>>> Sort of fixes mmiotrace for me again, I could sear I sent a similar patch
>>> before
>&g
On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst
wrote:
> Sort of fixes mmiotrace for me again, I could sear I sent a similar patch
> before
> the rework to event interface, so I guess it got reintroduced.
I don't know how/why you think this fixes anything. The interrupt
handler can't possibl
On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
wrote:
> I have no idea what this bogus restriction on placement is, but it breaks
> decoding 1080p
> VDPAU at boot speed. With this patch applied I only need to bump the vdec
> clock to
> get real-time 1080p decoding. It prevents a lot of VRAM
On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
wrote:
> I have no idea what this bogus restriction on placement is, but it breaks
> decoding 1080p
> VDPAU at boot speed. With this patch applied I only need to bump the vdec
> clock to
> get real-time 1080p decoding. It prevents a lot of VRAM
On Mon, Jun 17, 2013 at 11:09 PM, Maarten Lankhorst
wrote:
> Most graphics cards nowadays have a multiple of this limit as their vram, so
> limiting GART doesn't seem to make much sense.
Pushed, thanks :)
>
> Signed-off-by: Maarten >Lnkhorst
> ---
> diff --git a/drivers/gpu/drm/nouveau/nouveau_t
On Mon, Jun 17, 2013 at 11:09 PM, Maarten Lankhorst
wrote:
> Most graphics cards nowadays have a multiple of this limit as their vram, so
> limiting GART doesn't seem to make much sense.
Pushed, thanks :)
>
> Signed-off-by: Maarten >Lnkhorst
> ---
> diff --git a/drivers/gpu/drm/nouveau/nouveau_t
On Tue, Jun 11, 2013 at 10:17 PM, Maarten Lankhorst
wrote:
> Appears to fix the regression from "drm/nvc0/vm: handle bar tlb flushes
> internally".
> nvidia always seems to do this flush after writing values.
Thanks, patch applied.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drive
On Tue, Jun 11, 2013 at 10:17 PM, Maarten Lankhorst
wrote:
> Appears to fix the regression from "drm/nvc0/vm: handle bar tlb flushes
> internally".
> nvidia always seems to do this flush after writing values.
Thanks, patch applied.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drive
On Wed, Jun 5, 2013 at 5:16 PM, Ilia Mirkin wrote:
> On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst
> wrote:
>> Hey,
>>
>> Op 04-06-13 20:38, Ilia Mirkin schreef:
>>> On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin wrote:
These chipsets include the VP2 engine which is composed of a bitstream
On Wed, Jun 5, 2013 at 5:16 PM, Ilia Mirkin wrote:
> On Wed, Jun 5, 2013 at 3:05 AM, Maarten Lankhorst
> wrote:
>> Hey,
>>
>> Op 04-06-13 20:38, Ilia Mirkin schreef:
>>> On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin wrote:
These chipsets include the VP2 engine which is composed of a bitstream
On Fri, May 31, 2013 at 11:05 PM, Konrad Rzeszutek Wilk <
konrad.wilk at oracle.com> wrote:
> On Tue, May 28, 2013 at 08:55:29PM +0200, Sven Joachim wrote:
> > On 2013-05-26 23:09 +0200, Maarten Maathuis wrote:
> >
> > > My NV96 does not resume from suspend to ram (the screen stays black,
> magic
On Fri, May 31, 2013 at 11:05 PM, Konrad Rzeszutek Wilk <
konrad.w...@oracle.com> wrote:
> On Tue, May 28, 2013 at 08:55:29PM +0200, Sven Joachim wrote:
> > On 2013-05-26 23:09 +0200, Maarten Maathuis wrote:
> >
> > > My NV96 does not resume from suspend to ram (the screen stays black,
> magic
> >
On Mon, 2013-05-20 at 19:14 +0200, Alexander Stein wrote:
> Code refactoring in commit 8e9e3d2deacc460fbb8a4691140318f6e85e6891
> (drm/nv84/disp: move hdmi control into core) disabled HDMI audio on my
> nv84 by removing too much old code without adding it in the new one.
> This patch adds the missi
On Mon, 2013-05-20 at 19:14 +0200, Alexander Stein wrote:
> Code refactoring in commit 8e9e3d2deacc460fbb8a4691140318f6e85e6891
> (drm/nv84/disp: move hdmi control into core) disabled HDMI audio on my
> nv84 by removing too much old code without adding it in the new one.
> This patch adds the missi
On Mon, Apr 8, 2013 at 10:04 PM, Maarten Lankhorst <
maarten.lankhorst at canonical.com> wrote:
> Seems to make suspend slightly more reliable on my system.
>
NACK.
"Seems to", and "slightly" don't make a very good argument for this.
Likely all you've done is change the timing of certain things
On Mon, Apr 8, 2013 at 10:04 PM, Maarten Lankhorst <
maarten.lankho...@canonical.com> wrote:
> Seems to make suspend slightly more reliable on my system.
>
NACK.
"Seems to", and "slightly" don't make a very good argument for this.
Likely all you've done is change the timing of certain things hap
On Fri, Mar 29, 2013 at 7:33 AM, Peter Hurley
wrote:
> On Thu, 2013-03-28 at 16:16 +0100, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
>> ---
>> Oops, fixed to apply this time..
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
>> b/drivers/gpu/drm/nouveau/nouveau_dis
On Fri, Mar 29, 2013 at 7:33 AM, Peter Hurley wrote:
> On Thu, 2013-03-28 at 16:16 +0100, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
>> ---
>> Oops, fixed to apply this time..
>>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c
>> b/drivers/gpu/drm/nouveau/nouveau_disp
On Fri, 2013-03-22 at 14:54 -0500, Calvin Owens wrote:
> On 03/21/13 02:56, Calvin Owens wrote:
> > On 03/21/13 02:24, Calvin Owens wrote:
> >> On 03/21/13 01:59, Ben Skeggs wrote:
> >>> On Thu, 2013-03-21 at 01:34 -0500, Calvin Owens wrote:
> >>>> DRM
On Thu, 2013-03-21 at 01:34 -0500, Calvin Owens wrote:
> DRM hasn't worked on my desktop machine (GeForce 9800) with Nouveau for
> a little while (v3.9-rc1 didn't), but worked as of commit e204378 on
> Linus' tree for one boot, and subsequently always fails.
>
> After running that version, v3.6, w
On Tue, 2013-02-26 at 20:02 -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 09:35:14AM -0800, Greg KH wrote:
> > On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
> > > On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
> > > > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrot
On Tue, 2013-02-26 at 20:02 -0800, Greg KH wrote:
> On Tue, Feb 26, 2013 at 09:35:14AM -0800, Greg KH wrote:
> > On Mon, Feb 25, 2013 at 07:45:45PM -0800, Greg KH wrote:
> > > On Mon, Feb 25, 2013 at 02:32:43PM -0800, Greg KH wrote:
> > > > On Mon, Feb 25, 2013 at 04:06:02PM +1000, Dave Airlie wrot
On Mon, Feb 04, 2013 at 10:59:28PM +0100, Maarten Lankhorst wrote:
> Op 04-02-13 22:30, Marcin Slusarz schreef:
> > 1) Lockdep thinks all nouveau subdevs belong to the same class and can be
> > locked in arbitrary order, which is not true (at least in general case).
> > Tell it to distinguish subde
On Mon, Feb 04, 2013 at 10:59:28PM +0100, Maarten Lankhorst wrote:
> Op 04-02-13 22:30, Marcin Slusarz schreef:
> > 1) Lockdep thinks all nouveau subdevs belong to the same class and can be
> > locked in arbitrary order, which is not true (at least in general case).
> > Tell it to distinguish subde
On Sat, 2013-01-26 at 11:53 +0100, Antonio Ospite wrote:
> Hi,
>
> I am experiencing a bug with nouveau with linux-3.8-rc5, my video
> adapter is the one integrated on the MSI M3N78-VM motherboard (hence
> x86_64):
>
> 02:00.0 VGA compatible controller: NVIDIA Corporation C77 [GeForce 8200] (rev
On Sat, 2013-01-26 at 11:53 +0100, Antonio Ospite wrote:
> Hi,
>
> I am experiencing a bug with nouveau with linux-3.8-rc5, my video
> adapter is the one integrated on the MSI M3N78-VM motherboard (hence
> x86_64):
>
> 02:00.0 VGA compatible controller: NVIDIA Corporation C77 [GeForce 8200] (rev
On Fri, 2013-01-11 at 16:04 +0100, Maarten Lankhorst wrote:
> When a specific engine is needed that's not GR, struct nve0_fifo should be
> used,
> and the engine member should be used to select the engine.
>
> This will fail on kernels before 3.8, since no support for such engines has
> been add
On Fri, 2013-01-11 at 16:04 +0100, Maarten Lankhorst wrote:
> When a specific engine is needed that's not GR, struct nve0_fifo should be
> used,
> and the engine member should be used to select the engine.
>
> This will fail on kernels before 3.8, since no support for such engines has
> been add
On Tue, 2012-11-27 at 09:04 +0530, Sachin Kamat wrote:
> ping
>
> On 20 November 2012 11:23, Sachin Kamat wrote:
> > nouveau_ttm.h was included twice.
I've queued it in my tree, thanks!
Ben.
> >
> > Signed-off-by: Sachin Kamat
> > ---
> > drivers/gpu/drm/nouveau/nouveau_drm.c |2 --
> > 1
On Tue, 2012-11-27 at 09:04 +0530, Sachin Kamat wrote:
> ping
>
> On 20 November 2012 11:23, Sachin Kamat wrote:
> > nouveau_ttm.h was included twice.
I've queued it in my tree, thanks!
Ben.
> >
> > Signed-off-by: Sachin Kamat
> > ---
> > drivers/gpu/drm/nouveau/nouveau_drm.c |2 --
> > 1
On Tue, 2012-10-30 at 09:03 +0100, Mathieu Chouquet-Stringer wrote:
> On Tue, Oct 30, 2012 at 03:12:59PM +1000, Ben Skeggs wrote:
> > Not sure what's up with the hang yet, however, I noticed the issue [1]
> > which is likely causing the error messages from nouveau's i2c
On Mon, 2012-10-29 at 23:16 +0100, Antonio Ospite wrote:
> Hi,
>
> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1),
> my video adapter is the one integrated on the MSI M3N78-VM motherboard
> (hence x86_64):
>
> 02:00.0 VGA compatible controller: NVIDIA Corporation C77 [GeF
On Tue, 2012-10-30 at 00:32 +0100, Mathieu Chouquet-Stringer wrote:
> Hi again,
>
> On Tue, Oct 30, 2012 at 09:15:59AM +1000, Ben Skeggs wrote:
> > Are you able to go back to the current master, and get me a
> > log/screenshot with "nouveau.debug=trace" appe
l
options?
Thanks,
Ben.
>
> Note my uefi settings weren't modified during the whole thing.
>
> I've bisected the issue and git found that commit 4196fa is the one
> causing trouble (looking at the diff, it's pretty big):
>
> Author: Ben Skeggs
> Date: Tue
On Tue, 2012-10-30 at 09:03 +0100, Mathieu Chouquet-Stringer wrote:
> On Tue, Oct 30, 2012 at 03:12:59PM +1000, Ben Skeggs wrote:
> > Not sure what's up with the hang yet, however, I noticed the issue [1]
> > which is likely causing the error messages from nouveau's i2c
On Mon, 2012-10-29 at 23:16 +0100, Antonio Ospite wrote:
> Hi,
>
> I am experiencing a bug with nouveau with linux-3.7-rc3 (and since rc1),
> my video adapter is the one integrated on the MSI M3N78-VM motherboard
> (hence x86_64):
>
> 02:00.0 VGA compatible controller: NVIDIA Corporation C77 [GeF
On Tue, 2012-10-30 at 00:32 +0100, Mathieu Chouquet-Stringer wrote:
> Hi again,
>
> On Tue, Oct 30, 2012 at 09:15:59AM +1000, Ben Skeggs wrote:
> > Are you able to go back to the current master, and get me a
> > log/screenshot with "nouveau.debug=trace" appe
l
options?
Thanks,
Ben.
>
> Note my uefi settings weren't modified during the whole thing.
>
> I've bisected the issue and git found that commit 4196fa is the one
> causing trouble (looking at the diff, it's pretty big):
>
> Author: Ben Skeggs
> Date: Tue
On Sun, 2012-10-21 at 00:19 +0200, Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Marcin Slusarz wrote:
> >
> > > Try this one.
> >
> > It works, now I can boot again. However, nouveau seems to be dead now.
> > The dmesg output with your p
On Sun, 2012-10-21 at 00:19 +0200, Marcin Slusarz wrote:
> On Sat, Oct 20, 2012 at 11:20:36PM +0200, Heinz Diehl wrote:
> > On 20.10.2012, Marcin Slusarz wrote:
> >
> > > Try this one.
> >
> > It works, now I can boot again. However, nouveau seems to be dead now.
> > The dmesg output with your p
On Fri, Sep 14, 2012 at 01:29:55PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> We noticed a plymouth bug on Fedora 18, and I then
> noticed this stupid thinko, fixing it fixed the problem
> with plymouth.
>
> Signed-off-by: Dave Airlie
Signed-off-by: Ben Skeggs
>
On Fri, Sep 14, 2012 at 01:29:55PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> We noticed a plymouth bug on Fedora 18, and I then
> noticed this stupid thinko, fixing it fixed the problem
> with plymouth.
>
> Signed-off-by: Dave Airlie
Signed-off-by: Ben Skeggs
>
On Mon, Aug 27, 2012 at 04:24:02PM -0400, Adam Jackson wrote:
> On 8/23/12 7:50 PM, Dave Airlie wrote:
> >Hi guys (but mainly ajax)
> >
> >I have a bunch of EDID and quirk stuff outstanding,
> >
> >I've made a bundle on patchwork for it
> >https://patchwork.kernel.org/bundle/airlied/edid-review/
>
On Mon, Aug 27, 2012 at 04:24:02PM -0400, Adam Jackson wrote:
> On 8/23/12 7:50 PM, Dave Airlie wrote:
> >Hi guys (but mainly ajax)
> >
> >I have a bunch of EDID and quirk stuff outstanding,
> >
> >I've made a bundle on patchwork for it
> >https://patchwork.kernel.org/bundle/airlied/edid-review/
>
On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
> On 2012-08-08 07:37 +0200, Ben Skeggs wrote:
>
> > On Mon, Aug 06, 2012 at 11:38:04PM +0300, Maxim Levitsky wrote:
> >> On Sat, 2012-08-04 at 17:41 +0300, Maxim Levitsky wrote:
> >> > On Mon, 2012-07
On Mon, Aug 06, 2012 at 11:38:04PM +0300, Maxim Levitsky wrote:
> On Sat, 2012-08-04 at 17:41 +0300, Maxim Levitsky wrote:
> > On Mon, 2012-07-23 at 18:25 +0300, Aioanei Rares wrote:
> > > On Thu, Jul 5, 2012 at 11:24 PM, Martin Nyhus
> > > wrote:
> > > >
> > > > On Mon, 11 Jun 2012 23:18:42 +0
On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
> On 2012-08-08 07:37 +0200, Ben Skeggs wrote:
>
> > On Mon, Aug 06, 2012 at 11:38:04PM +0300, Maxim Levitsky wrote:
> >> On Sat, 2012-08-04 at 17:41 +0300, Maxim Levitsky wrote:
> >> > On Mon, 2012-07
On Mon, Aug 06, 2012 at 11:38:04PM +0300, Maxim Levitsky wrote:
> On Sat, 2012-08-04 at 17:41 +0300, Maxim Levitsky wrote:
> > On Mon, 2012-07-23 at 18:25 +0300, Aioanei Rares wrote:
> > > On Thu, Jul 5, 2012 at 11:24 PM, Martin Nyhus
> > > wrote:
> > > >
> > > > On Mon, 11 Jun 2012 23:18:42 +0
On Sat, Aug 04, 2012 at 08:00:45AM +0200, Henrik Rydberg wrote:
> The nva3 copy engine exhibits random memory corruption in at least one
> case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch
> omits creating the engine for the specific chipset, falling back to
> M2MF, which kills
On Sat, Aug 04, 2012 at 08:00:45AM +0200, Henrik Rydberg wrote:
> The nva3 copy engine exhibits random memory corruption in at least one
> case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch
> omits creating the engine for the specific chipset, falling back to
> M2MF, which kills
orruption in at least one
> case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch
> omits creating the engine for the specific chipset, falling back to
> M2MF, which kills the symptoms.
> ---
Signed-off-by: Ben Skeggs
> drivers/gpu/drm/nouveau/nouveau_state.c |
orruption in at least one
> case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch
> omits creating the engine for the specific chipset, falling back to
> M2MF, which kills the symptoms.
> ---
Signed-off-by: Ben Skeggs
> drivers/gpu/drm/nouveau/nouveau_state.c |
From: Ben Skeggs
nv_two_heads() was never meant to be used outside of pre-nv50 code. The
code checks for >= NV_10 for 2 CRTCs, then downgrades a few specific
chipsets to 1 CRTC based on (pci_device & 0x0ff0).
The breakage example seen is on GTX 560Ti, with a pciid of 0x1200, whi
From: Ben Skeggs
nv_two_heads() was never meant to be used outside of pre-nv50 code. The
code checks for >= NV_10 for 2 CRTCs, then downgrades a few specific
chipsets to 1 CRTC based on (pci_device & 0x0ff0).
The breakage example seen is on GTX 560Ti, with a pciid of 0x1200, whi
On Fri, May 18, 2012 at 03:32:02PM +0100, Dave Airlie wrote:
> From: Dave Airlie
>
> This seems to be wrong to me, spotted while thinking about dma-buf.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Ben Skeggs
Cc: stable at vger.kernel.org
> ---
> drivers/gpu/drm/nouvea
On Fri, May 18, 2012 at 03:32:02PM +0100, Dave Airlie wrote:
> From: Dave Airlie
>
> This seems to be wrong to me, spotted while thinking about dma-buf.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Ben Skeggs
Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/nouvea
On Thu, May 17, 2012 at 10:30 AM, Ben Skeggs wrote:
> Am Mittwoch, den 16.05.2012, 12:17 -0600 schrieb Tim Gardner:
>> commit b99da31ed8521eb78d5d6930f3128f8ecdb75fae causes the backlight in
>> my Dell XPS M1710 to stop working. Symptoms are dim display and won't
>>
Am Mittwoch, den 16.05.2012, 12:17 -0600 schrieb Tim Gardner:
> commit b99da31ed8521eb78d5d6930f3128f8ecdb75fae causes the backlight in
> my Dell XPS M1710 to stop working. Symptoms are dim display and won't
> respond to key brightness events. I bisected and confirmed that
> reverting this single p
On Thu, May 17, 2012 at 10:30 AM, Ben Skeggs wrote:
> Am Mittwoch, den 16.05.2012, 12:17 -0600 schrieb Tim Gardner:
>> commit b99da31ed8521eb78d5d6930f3128f8ecdb75fae causes the backlight in
>> my Dell XPS M1710 to stop working. Symptoms are dim display and won't
>>
Am Mittwoch, den 16.05.2012, 12:17 -0600 schrieb Tim Gardner:
> commit b99da31ed8521eb78d5d6930f3128f8ecdb75fae causes the backlight in
> my Dell XPS M1710 to stop working. Symptoms are dim display and won't
> respond to key brightness events. I bisected and confirmed that
> reverting this single p
On Wed, 2012-05-02 at 21:31 +1000, Ben Skeggs wrote:
> On Wed, 2012-05-02 at 09:54 +0200, Jean Delvare wrote:
> > Hi Luca, Maarten,
> >
> > On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
> > > On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis > &
On Wed, 2012-05-02 at 21:31 +1000, Ben Skeggs wrote:
> On Wed, 2012-05-02 at 09:54 +0200, Jean Delvare wrote:
> > Hi Luca, Maarten,
> >
> > On Monday 30 April 2012 01:01:30 pm Luca Tettamanti wrote:
> > > On Mon, Apr 30, 2012 at 11:07 AM, Maarten Maathuis
>
EDID checksum is invalid,
> > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.087659]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.107
,
> > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.087659]
> > >> [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid,
> > >> remainder is 208 Apr 27 09:13:03 dtor-d630 kernel: [44602.107147]
> > >> [drm:drm_edid_block_valid]
401 - 500 of 658 matches
Mail list logo
