On Fri, Jan 22, 2016 at 12:47 PM, Ville Syrjälä
wrote:
> On Fri, Jan 22, 2016 at 05:40:54PM +, Emil Velikov wrote:
>> On 22 January 2016 at 17:29, Ilia Mirkin wrote:
>> > On Fri, Jan 22, 2016 at 12:18 PM, Marek Olšák
>> > wrote:
>> >> On Fri
On Mon, Jan 25, 2016 at 2:27 PM, Eric Anholt wrote:
> The headers were originally written in Mesa, imported to the kernel,
> and improved upon in vc4-gpu-tools. These come from the v-g-t copies
> and will replace the Mesa and v-g-t copies, and hopefully be used from
> new tests in igt, as well.
>
The warn in question is
static u32
nvkm_mc_intr_mask(struct nvkm_mc *mc)
{
u32 intr = mc->func->intr_mask(mc);
if (WARN_ON_ONCE(intr == 0x))
intr = 0; /* likely fallen off the bus */
return intr;
}
Which is basically a sign of total death. Is this n
On Thu, Jan 28, 2016 at 7:09 PM, Insu Yun wrote:
> drm_property_create_range can be failed in memory pressure.
> So, it needs to be handled.
>
> Signed-off-by: Insu Yun
> ---
> drivers/gpu/drm/nouveau/nouveau_display.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/dr
On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu wrote:
> Hi,
>
> Here are two patches to fix an issue reported on kernel bugzilla (infinite
> loop
> due to unchecked function) and a more important fix to fix hanging Optimus
> machines when runtime PM is enabled (with pm/pci patches).
>
> These are the
On Fri, Jul 15, 2016 at 12:27 PM, Alex Deucher wrote:
> On Fri, Jul 15, 2016 at 12:10 PM, Ilia Mirkin wrote:
>> On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu wrote:
>>> Hi,
>>>
>>> Here are two patches to fix an issue reported on kernel bugzilla (infinite
&g
On Fri, Jul 15, 2016 at 12:36 PM, Peter Wu wrote:
> On Fri, Jul 15, 2016 at 12:10:23PM -0400, Ilia Mirkin wrote:
>> On Fri, Jul 15, 2016 at 9:12 AM, Peter Wu wrote:
>> > Hi,
>> >
>> > Here are two patches to fix an issue reported on kernel bugzilla (infin
On Fri, Jul 15, 2016 at 12:40 PM, Alex Deucher wrote:
> On Fri, Jul 15, 2016 at 12:31 PM, Ilia Mirkin wrote:
>> On Fri, Jul 15, 2016 at 12:27 PM, Alex Deucher
>> wrote:
>>> On Fri, Jul 15, 2016 at 12:10 PM, Ilia Mirkin
>>> wrote:
>>>> On
On Wed, Jul 16, 2014 at 7:30 AM, Ricardo Ribalda Delgado
wrote:
> Hi
>
> I am trying to use a external monitor connected via display port to
> the dock station of a w520. Unfortunately nothing is on the screen and
> dmesg outputs:
>
> [ 520.916021] nouveau E[ PDISP][:01:00.0] DP:0006:0344:
On Wed, Jul 16, 2014 at 8:22 AM, Ricardo Ribalda Delgado
wrote:
> Hello LLia do you have any way of building new drivers into old kernel
> trees like the media-build?
Nope, sorry. You could try just copying over the drm directory, but
it's unlikely to yield positive results. Just build a fresh ke
hanges were substantial, and only
small fixes get backported in normal stable trees. Questions about
what a distro might do should be brought up with that distro.
Cheers,
-ilia
>
> Thanks!
>
>
>
>
> On Wed, Jul 16, 2014 at 3:33 PM, Maarten Lankhorst
> wrote:
>> op 16
This fixes hangs on GK208 which happen instantaneously on trying to use a
geometry shader.
Signed-off-by: Ilia Mirkin
Cc: stable at vger.kernel.org # v3.14+
---
ctxnvf0 also writes to these registers (although slightly diff values), so I
think this is right. So I guess trap 4 is whatever this
Signed-off-by: Ilia Mirkin
---
MMIO32 R 0x17e91c 0x0b040a0b PMFB_BROADCAST.SUBP_BROADCAST.UNK11C => 0xb040a0b
MMIO32 R 0x17e920 0x00090c03 PMFB_BROADCAST.SUBP_BROADCAST.UNK120 => 0x90c03
MMIO32 W 0x17e91c 0x0b030a0c PMFB_BROADCAST.SUBP_BROADCAST.UNK11C <= 0xb030a0c
MMIO32 W 0x17e920 0
On Sat, Jun 21, 2014 at 2:02 PM, Pavel Machek wrote:
> Hi!
>
> AFAICT, pstate file will contain something like
>
> 07: core 100 MHz memory 123 MHz *
> 08: core 100-200 MHz memory 123 MHz
>
> ...which does not look exactly like one-value-per-file, and I'm pretty
> sure userspace will get it wrong i
On Sat, Jun 21, 2014 at 2:50 PM, Pavel Machek wrote:
> On Sat 2014-06-21 14:22:59, Ilia Mirkin wrote:
>> On Sat, Jun 21, 2014 at 2:02 PM, Pavel Machek wrote:
>> > Hi!
>> >
>> > AFAICT, pstate file will contain something like
>> >
>> > 07: c
On Sat, Jun 21, 2014 at 3:45 PM, Greg KH wrote:
> On Sat, Jun 21, 2014 at 02:22:59PM -0400, Ilia Mirkin wrote:
>> On Sat, Jun 21, 2014 at 2:02 PM, Pavel Machek wrote:
>> > Hi!
>> >
>> > AFAICT, pstate file will contain something like
>> >
>> &g
On Mon, Jun 23, 2014 at 9:02 AM, Pavel Machek wrote:
> On Sun 2014-06-22 22:12:14, Ilia Mirkin wrote:
>> On Sat, Jun 21, 2014 at 3:45 PM, Greg KH wrote:
>> > On Sat, Jun 21, 2014 at 02:22:59PM -0400, Ilia Mirkin wrote:
>> >> On Sat, Jun 21, 2014 at 2:02 PM, P
On Mon, Jun 23, 2014 at 12:07 PM, Greg KH wrote:
> On Sun, Jun 22, 2014 at 10:12:14PM -0400, Ilia Mirkin wrote:
>> On Sat, Jun 21, 2014 at 3:45 PM, Greg KH wrote:
>> > On Sat, Jun 21, 2014 at 02:22:59PM -0400, Ilia Mirkin wrote:
>> >> On Sat, Jun 21, 2014 a
On Mon, Jun 23, 2014 at 12:36 PM, Greg KH wrote:
> On Mon, Jun 23, 2014 at 12:18:51PM -0400, Ilia Mirkin wrote:
>> On Mon, Jun 23, 2014 at 12:07 PM, Greg KH wrote:
>> > On Sun, Jun 22, 2014 at 10:12:14PM -0400, Ilia Mirkin wrote:
>> >> On Sat, Jun 21, 2014 at 3:45
On Mon, Jun 23, 2014 at 1:46 PM, Martin Peres wrote:
> Le 23/06/2014 18:40, Ilia Mirkin a ?crit :
>>
>> On Mon, Jun 23, 2014 at 12:36 PM, Greg KH wrote:
>>>
>>> On Mon, Jun 23, 2014 at 12:18:51PM -0400, Ilia Mirkin wrote:
>>> A list of valid "va
On Mon, Jun 23, 2014 at 2:00 PM, Martin Peres wrote:
> Le 23/06/2014 19:56, Ilia Mirkin a ?crit :
>
>> On Mon, Jun 23, 2014 at 1:46 PM, Martin Peres
>> wrote:
>>>
>>> Le 23/06/2014 18:40, Ilia Mirkin a ?crit :
>>>>
>>>>
>>>>
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
>> >> >> > core_clock_max
>> >> >> > memory_clock_min
>> >> >> > memory_clock_max
>> >> >> >
>> >> >
On Mon, Jun 23, 2014 at 4:26 PM, 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 lik
On Fri, Jul 26, 2013 at 2:28 PM, konrad wilk wrote:
> I just saw this on a box of mine (rc1 worked) I hadn't done yet a bisection.
> Any suggestions?
>
> ring 0 polarity 1
> [6.023776] Already setup the GSI :22
> ^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G^G[6.036680] nouveau [
> DEVICE]
Hello,
I've started seeing the following warning in 3.11-rc2. [In the
interest of full disclosure, I do have a patch applied that tries to
implement drm_planes, which I might have done completely incorrectly,
but looking around it doesn't seem related. I'm definitely not
invoking any of the planes
On Fri, Jul 26, 2013 at 8:39 PM, Ilia Mirkin wrote:
> Hello,
>
> I've started seeing the following warning in 3.11-rc2. [In the
> interest of full disclosure, I do have a patch applied that tries to
> implement drm_planes, which I might have done completely incorrectly,
>
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.
Signed-off-by: Ilia Mirkin
---
Only mild testing... reloaded nouveau a few times, all the connectors
kept their original ids.
drivers/gpu/drm
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.
Signed-off-by: Ilia Mirkin
---
v1 -> v2: correct loop condition... not sure how that slipped past
me... the code started out by being <
On Tue, Aug 6, 2013 at 8:40 PM, Rob Clark wrote:
> On Tue, Aug 6, 2013 at 8:12 PM, Dave Airlie wrote:
>> On Tue, Jul 30, 2013 at 5:51 PM, Ilia Mirkin wrote:
>>> This makes it so that reloading a module does not cause all the
>>> connector ids to change, which are user
On Wed, Aug 7, 2013 at 4:00 AM, Ville Syrjälä
wrote:
> On Tue, Jul 30, 2013 at 03:51:49AM -0400, Ilia Mirkin wrote:
>> This makes it so that reloading a module does not cause all the
>> connector ids to change, which are user-visible and sometimes used
>> for configuration
This makes it so that reloading a module does not cause all the
connector ids to change, which are user-visible and sometimes used
for configuration.
Signed-off-by: Ilia Mirkin
---
v2 -> v3:
- rename ida struct name to... ida. (i'm ready to accept my "creative name
of th
Commit dceef5d87 (drm/nouveau/fb: initialise vram controller as pfb
sub-object) moved some code around and introduced these null derefs.
pfb->ram is set to the new ram object outside of this ctor.
Reported-by: Ronald Uitermark
Tested-by: Ronald Uitermark
Signed-off-by: Ilia Mirkin
---
driv
On Mon, Aug 12, 2013 at 6:43 AM, Maarten Lankhorst
wrote:
> Some registers were not initialized in init, this causes them to be
> uninitialized after suspend.
>
> Signed-off-by: Maarten Lankhorst
> ---
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c
> b/drivers/gpu/drm/nouveau/cor
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: Pasi Kärkkäinen
Tested-by: Pasi Kärkkäinen
Signed-off-by:
-off-by: Ilia Mirkin
---
This will only happen if i2c_algo_bit.bit_test=1.
drivers/gpu/drm/nouveau/core/include/subdev/i2c.h | 8 +---
drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c | 10 --
drivers/gpu/drm/nouveau/core/subdev/i2c/base.c| 2 ++
drivers/gpu/drm/nouveau/core
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 some old, broken chipsets. But now that we
>> > already see systems where PCI legacy interr
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 +1000 schrieb Ben Skeggs:
>>>> On Wed, Aug 28, 2013 a
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 Mirkin wrote:
>>>> On Wed, Aug 28, 2013 at 3:28 AM, Lucas S
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 Mirkin wrote:
>>>> On Wed, Aug 28, 2013 at 8:07 PM, Ben Skegg
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 Mirkin wrote:
>>>> On Thu, Aug 29, 2013 at 12:45 AM, Ben Skegg
Signed-off-by: Ilia Mirkin
---
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 new "pvideo" engine -- that just seems way too
heavy-handed compared to the ~10 lines
This is helpful for differentiating between multiple devices that use
the same module.
Signed-off-by: Ilia Mirkin
---
tests/modetest/modetest.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index f0ed56b
Signed-off-by: Ilia Mirkin
---
tests/modetest/modetest.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 9d6e279..51c4e6d 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
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
---
Ben, I know you've been saying that reclocking is in a pretty bad state, but I
do think that
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)
>> reclocking. All chipsets default to off, except NVAA/NVAC, which are
>> reporte
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, "Ilia Mirkin" wrote:
>> >>
>> >> Adds a Nv
Signed-off-by: Ilia Mirkin
---
Hope I understood you correctly wrt the mem exec stuff.
nvkm/subdev/fb/ramnv50.c | 2 +-
nvkm/subdev/fb/ramnva3.c | 2 +-
nvkm/subdev/fb/ramnvc0.c | 2 +-
nvkm/subdev/fb/ramnve0.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/nvkm/subdev
Use with caution.
Signed-off-by: Ilia Mirkin
---
Same patch as before, but adds nv40 and nve0 as on by default, and removes end
user ability to turn it on for nv50/nva3/nvc0.
I finally found the nv50-related stuff you nuked, and yeah, the current code
definitely can't work as-is. Oh well.
On Mon, May 26, 2014 at 9:35 AM, Jani Nikula wrote:
> Generated using semantic patch:
>
> @@
> expression E;
> @@
>
> - drm_get_connector_name(E)
> + E->name
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/nouveau/dispnv04/dac.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv04/dfp.c |
On Tue, Aug 30, 2016 at 11:25 AM, Roland Singer
wrote:
> I tried these scenarios:
>
> 1. Booted the system without the bbswitch module. The nouveau module
>was loaded and is responsible for the power management of the GPU.
>The graphical session freezes after some minutes...
>
> 2. Booted
On Tue, Aug 30, 2016 at 11:44 AM, Ilia Mirkin wrote:
> On Tue, Aug 30, 2016 at 11:25 AM, Roland Singer
> wrote:
>> I tried these scenarios:
>>
>> 1. Booted the system without the bbswitch module. The nouveau module
>>was loaded and is responsible for t
On Tue, Aug 30, 2016 at 1:37 PM, Roland Singer
wrote:
> My conclusion:
>
> 1. Nouveau has couple of problems with GTX 9** M Nvidia GPUs.
>I would love to help here.
nouveau + bbswitch will always end in tears. You're going behind the
driver's back and messing around with state it believes it
On Tue, Aug 30, 2016 at 2:02 PM, Roland Singer
wrote:
> I configured bbswitch to not set any states automatically...
> So it's possible to obtain and verify the GPU power state.
>
> However I removed the bbswitch module and booted with nouveau.
>
> Kernel 4.7.2: nouveau switches the discrete GPU o
That's right -- nouveau currently requires 4k page sizes to work. This is a
software limitation, not a hardware one though.
On Dec 1, 2016 5:13 PM, "Jeremy Linton" wrote:
Hi,
I placed a 9600GT in a softiron 3k running fedora 25, and the nouveau
driver failed to claim the device with :
[drm] In
On Wed, Dec 7, 2016 at 4:57 AM, Alexandre Courbot wrote:
> On Wed, Dec 7, 2016 at 6:53 PM, Michel Dänzer wrote:
>> On 07/12/16 06:39 PM, Alexandre Courbot wrote:
>>> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin
>>> wrote:
>>>> That's right -- nouv
On Wed, Dec 7, 2016 at 11:42 AM, Robin Murphy wrote:
> By comparison, the same use-cases (fbcon and fb-test) under the same
> big-endian kernel do *not* show the same problem with nouveau driving a
> PCIe 7600GT card, which led me to believe it was HDLCD-specific.
Just to randomly insert info her
On Fri, Aug 21, 2015 at 10:39 AM, Emil Velikov
wrote:
> On 21/08/15 13:42, Thomas Hellstrom wrote:
>> I guess there's not much we can do
>> about it at this point? Even if I post the patches now we can't just
>> expect them to be reviewed within a couple of hours...
>>
> Unfortunately it seems li
On Mon, Aug 24, 2015 at 4:26 PM, Samuel Pitoiset
wrote:
> On 08/24/2015 10:16 PM, Rob Clark wrote:
>> On Mon, Aug 24, 2015 at 4:20 PM, Samuel Pitoiset
>> wrote:
>>>
>>> Hi Hai,
>>>
>>> I don't know what those bits are used for, but I'm a bit curious about
>>> how
>>> did you find them?
>>>
>>> Al
On Thu, Dec 3, 2015 at 10:34 AM, Laurent Pinchart
wrote:
> Hi Jaakko,
>
> On Thursday 03 December 2015 14:42:51 Hannikainen, Jaakko wrote:
>> Hello,
>>
>> We're developing Miracast (HDMI over Wireless connections). The current
>> progress is that it 'works' in the userspace but doesn't have any
>>
On Thu, Dec 3, 2015 at 10:53 AM, Laurent Pinchart
wrote:
> On Thursday 03 December 2015 10:42:50 Ilia Mirkin wrote:
>> On Thu, Dec 3, 2015 at 10:34 AM, Laurent Pinchart
>>
>> wrote:
>> > Hi Jaakko,
>> >
>> > On Thursday 03 December 2015
On Thu, Dec 3, 2015 at 11:10 AM, Laurent Pinchart
wrote:
> Hi Ilia,
>
> On Thursday 03 December 2015 11:03:28 Ilia Mirkin wrote:
>> On Thu, Dec 3, 2015 at 10:53 AM, Laurent Pinchart wrote:
>> > On Thursday 03 December 2015 10:42:50 Ilia Mirkin wrote:
>> >> On T
On Fri, Dec 4, 2015 at 3:45 AM, Daniel Vetter wrote:
> I want to remove the core ones since with atomic drivers system
> suspend/resume is solved much differently. And there's only 2 drivers
> (gma500 besides nouveau) really using them.
>
> Cc: Ben Skeggs
> Signed-off-by: Daniel Vetter
> ---
>
On Fri, Dec 4, 2015 at 12:07 PM, Russell King - ARM Linux
wrote:
> On Fri, Dec 04, 2015 at 03:00:03PM +0100, Lucas Stach wrote:
>> Signed-off-by: Lucas Stach
>
> Acked-by: Russell King
>
> Although, I would like to be copied on patches, I don't think we
> have a way to encode that information in
On Fri, Dec 4, 2015 at 3:31 PM, Russell King - ARM Linux
wrote:
> Moreover, DRI3 is not yet available for Gallium, so if we're talking
> about Xorg, then functional DRI2 is a requirement, and that _needs_
> to have a single device for the rendering instances. Xorg has no way
> to pass multiple re
On Fri, Dec 4, 2015 at 5:05 PM, Russell King - ARM Linux
wrote:
> On Fri, Dec 04, 2015 at 03:42:47PM -0500, Ilia Mirkin wrote:
>> On Fri, Dec 4, 2015 at 3:31 PM, Russell King - ARM Linux
>> wrote:
>> > Moreover, DRI3 is not yet available for Gallium, so if we're
On Tue, Dec 8, 2015 at 3:49 AM, Daniel Vetter wrote:
> We want this for consistency with existing page_flip semantics.
>
> Since this spurred quite a discussion on IRC also document why we
> reject even generation when the pipe is off: It's not that it's hard
event generation?
> to implement, bu
On Tue, Dec 8, 2015 at 8:43 AM, Ernst Sjöstrand wrote:
> Hello list!
>
> I lurk here and try to follow Mesa/DRI and most specifically Radeon
> driver development, report bugs, test new stuff and help get the bugs
> closed and so on...
>
> However I see that the commit messages for AMD/Radeon are
On Wed, Dec 28, 2016 at 5:30 AM, Andrzej Hajda wrote:
> In case of HW trigger mode, sysreg register should be configured to
> enable TE functionality. The patch refactors also trigger setup function.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 40
> +
On Thu, Sep 18, 2014 at 10:07 AM, Ortwin Gl?ck wrote:
> Hi,
>
> Since 3.16 an external monitor stays dark after resume from sleep. I didn't
> manage to activate it
> again with xrand. According to xrandr it is "connected" and configured with a
> mode, but I get no signal.
>
> Happens since 3.16
On Fri, Sep 19, 2014 at 10:41 AM, Ortwin Gl?ck wrote:
>
>
> On 18.09.2014 16:58, Ilia Mirkin wrote:
>> This has been reported a few times already -- probably the same thing
>> as bug https://bugs.freedesktop.org/show_bug.cgi?id=83550
>
> Ah, thanks. I would like to tr
On Fri, Sep 19, 2014 at 12:52 PM, Ortwin Gl?ck wrote:
> On 19.09.2014 17:58, Ilia Mirkin wrote:
>> git checkout 415f12efc1b2308411b2cbc3e82666b3db8a7758^
>
> Thanks again. I confirm that Bugzilla 83550 is the same issue. I have
> attached the captured logs
> there f
On Sat, Sep 20, 2014 at 11:34 AM, Rob Clark wrote:
> On Fri, Sep 19, 2014 at 3:16 PM, Rob Clark wrote:
>> For the mesa part, it looks like there is a bit of work needed to
>> teach egl about multi-planar buffers, buffers where offset[n] != 0,
>> etc. I'll start with patches to teach egl how to i
On Wed, Sep 24, 2014 at 6:24 AM, Daniel Vetter
wrote:
> Hi Dave,
>
> Just noticed that you've picked up the header rework stuff already, so
> I've rebased that out again. Otherwise just two stragglers from the vblank
> rework and the universal cursor planes locking fix. Plus sprinkling
> containe
On Fri, Sep 26, 2014 at 5:08 PM, Aaron Plattner wrote:
> On 09/23/2014 01:29 PM, Benjamin Herrenschmidt wrote:
>>
>> On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
>>>
>>> Adding proper people and mailing lists..
>>>
>>> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
>
On Sat, Sep 26, 2015 at 3:15 AM, Sudip Mukherjee
wrote:
> BTW, I had a doubt about drm drivers. Is there any library or test suite
> to test the driver? I am almost halfway in making a KMS driver for SM712
> but still don't know how to test it properly. I was thinkig of asking
> Daniel offlist but
On Fri, Apr 8, 2016 at 12:47 AM, Alexandre Courbot
wrote:
> Hi Robin,
>
> On 04/07/2016 08:50 PM, Robin Murphy wrote:
>>
>> Hello,
>>
>> With 4.6-rc2 (and -rc1) I'm seeing Nouveau blowing up at boot, from the
>> look of it by dereferencing some offset from NULL inside
>> nouveau_fbcon_imageblit()
On Fri, Apr 15, 2016 at 10:57 AM, Pierre Moreau
wrote:
> Currently, every backlight interface created by Nouveau uses the same name,
> nv_backlight. This leads to a sysfs warning as it tries to create an already
> existing folder. This patch adds a incremented number to the name, but keeps
> the
On Fri, Apr 15, 2016 at 11:22 AM, Pierre Moreau
wrote:
> On 11:06 AM - Apr 15 2016, Ilia Mirkin wrote:
>> On Fri, Apr 15, 2016 at 10:57 AM, Pierre Moreau
>> wrote:
>> > Currently, every backlight interface created by Nouveau uses the same name,
>> > nv_backlig
On Tue, Oct 9, 2018 at 1:40 PM Laurent Pinchart
wrote:
>
> Hi Jernej,
>
> Thank you for the patch.
>
> On Sunday, 7 October 2018 12:38:51 EEST Jernej Skrabec wrote:
> > It turns out that even new DW HDMI controllers exhibits same magenta
> > line issues as older versions.
> >
> > Enable workaround
On Tue, Oct 30, 2018 at 4:24 AM Y.C. Chen wrote:
>
> From: "Y.C. Chen"
>
> over-sample data to increase the stability with some specific monitors
>
> Signed-off-by: Y.C. Chen
> ---
> drivers/gpu/drm/ast/ast_mode.c | 32 ++--
> 1 file changed, 26 insertions(+), 6 dele
On Sun, May 27, 2018 at 5:54 PM, Colin King wrote:
> From: Colin Ian King
>
> The constant values being shifted are 32 bit integers and may potentially
> overflow on the shift. Avoid this potential overflow by making them
> unsigned long long values before the shift.
>
> Detected by CoverityScan
On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE enabled)
> try to allocate huge pages. However, not all drivers can take advantage
> of huge pages, but they would incur the overhead for allocating and
>
On Sat, Apr 28, 2018 at 7:02 PM, Michel Dänzer wrote:
> On 2018-04-28 06:30 PM, Ilia Mirkin wrote:
>> On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer wrote:
>>> From: Michel Dänzer
>>>
>>> Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEPAGE ena
On Wed, Nov 7, 2018 at 10:34 AM Thierry Reding wrote:
>
> On Tue, Nov 06, 2018 at 06:41:22PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 06, 2018 at 05:24:15PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > Irrespective of whether or not the device has any usable outputs, the
On Fri, Nov 23, 2018 at 7:31 AM Thierry Reding wrote:
>
> From: Thierry Reding
>
> The register region allocated per channel was decreased from 16384 bytes
> to 256 bytes on Tegra186 and later. Resize the region to make sure every
> channel (instead of only the first) is properly programmed.
>
>
On Mon, Aug 13, 2018 at 3:07 PM, Lyude Paul wrote:
> +bool
> +nouveau_fbcon_hotplugged_in_suspend(struct nouveau_fbdev *fbcon)
> +{
> + bool hotplug;
> +
> + if (!fbcon)
> + return false;
> +
> + mutex_lock(&fbcon->hotplug_lock);
> + hotplug = fbcon->hotplug_w
On Mon, Sep 3, 2018 at 12:45 PM, Daniel Vetter wrote:
> On Mon, Sep 03, 2018 at 12:57:54PM +0200, Gerd Hoffmann wrote:
>> Userspace on big endian machhines typically expects the ADDFB ioctl
>> returns a big endian framebuffer. drm_mode_addfb() will call
>> drm_mode_addfb2() unconditionally with l
Scrambling is required for supporting any mode over 340MHz. If it's not
supported, reject any modes that would require it.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 34 +++--
1 file changed, 22 insertions(+), 12 deletions(-)
diff
The register programmed by the clock method needs to contain a different
setting for the link speed as well as special divider settings.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 2 ++
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h | 5
High pixel clocks are required to use a 40 TMDS divider instead of 10,
and even low ones may optionally use scrambling depending on device
support.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/include/nvif/cl5070.h | 5 -
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h
When SCDC is supported, make sure that we configure the GPU and monitor
to the same parameters.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 40 -
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau
d by one or the
other. But at least it works a little bit!
Note that I have limited testing equipment, but I did verify that a
GM204 trace referred to the same register for controlling
scrambling. I may get access to a GM206 later in the week to verify
there.
Ilia Mirkin (5):
drm/nouveau/disp: add
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/engine/disp/Kbuild| 1 +
.../gpu/drm/nouveau/nvkm/engine/disp/hdmigm200.c | 34 ++
drivers/gpu/drm/nouveau/nvkm/engine/disp/ior.h | 2 ++
.../gpu/drm/nouveau/nvkm/engine/disp/sorgm200.c| 1 +
.../gpu
On Tue, Sep 4, 2018 at 4:00 AM, Michel Dänzer wrote:
> On 2018-09-03 7:07 p.m., Ilia Mirkin wrote:
>> On Mon, Sep 3, 2018 at 12:45 PM, Daniel Vetter wrote:
>>> On Mon, Sep 03, 2018 at 12:57:54PM +0200, Gerd Hoffmann wrote:
>>>> Userspace on big endian machhines typ
On Tue, Sep 4, 2018 at 11:02 AM, Michel Dänzer wrote:
> On 2018-09-04 3:05 p.m., Ilia Mirkin wrote:
>> On Tue, Sep 4, 2018 at 4:00 AM, Michel Dänzer wrote:
>>> On 2018-09-03 7:07 p.m., Ilia Mirkin wrote:
>>>> On Mon, Sep 3, 2018 at 12:45 PM, Daniel Vetter wrote:
&g
Lyude bisected a similar problem on a much newer GPU to this very same
change as well. [Sorry, no useful information beyond that, but thought
I'd make the connection.]
On Sun, Jun 17, 2018 at 5:46 PM, Adam Borowski wrote:
> Hi!
> On v4.18-rc1, the mouse cursor is missing on my right monitor.
> Ca
GF117 appears to use the same register as GK104 (but still with the
general Fermi readout mechanism).
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/subdev/volt/gf100.c | 3 ++-
1 file changed, 2 insertions(+), 1
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/engine/falcon.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/falcon.c
b/drivers/gpu/drm/nouveau/nvkm/engine
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: Pasi K?rkk?inen
Tested-by: Pasi K?rkk?inen
Signed-off-by:
-off-by: Ilia Mirkin
---
This will only happen if i2c_algo_bit.bit_test=1.
drivers/gpu/drm/nouveau/core/include/subdev/i2c.h | 8 +---
drivers/gpu/drm/nouveau/core/subdev/i2c/anx9805.c | 10 --
drivers/gpu/drm/nouveau/core/subdev/i2c/base.c| 2 ++
drivers/gpu/drm/nouveau/core
201 - 300 of 521 matches
Mail list logo
