On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä
wrote:
>
> On Mon, Aug 26, 2019 at 09:36:50AM -0400, Ilia Mirkin wrote:
> > This should probably be fixed to account for the scenario where an
> > HDMI connector is plugged directly into the DP++ port. I don't think
> >
On Wed, Aug 28, 2019 at 10:54 AM Ville Syrjälä
wrote:
>
> On Wed, Aug 28, 2019 at 10:47:08AM -0400, Ilia Mirkin wrote:
> > On Wed, Aug 28, 2019 at 10:38 AM Ville Syrjälä
> > wrote:
> > >
> > > On Mon, Aug 26, 2019 at 09:36:50AM -0400, Ilia Mirkin wrote:
>
So how would this work with a DP++ connector? Should it list the HDMI
or DP properties? Or do we need a custom property checker which is
aware of what is currently plugged in to validate the values?
On Tue, Sep 3, 2019 at 5:12 AM Gwan-gyeong Mun
wrote:
>
> In order to use colorspace property to D
On Wed, Sep 4, 2019 at 4:08 PM Jyri Sarha wrote:
>
> On 04/09/2019 14:11, Laurent Pinchart wrote:
> > Hi Jyri,
> >
> > On Wed, Sep 04, 2019 at 10:17:00AM +0300, Jyri Sarha wrote:
> >> On 03/09/2019 18:24, Laurent Pinchart wrote:
> >>> On Mon, Sep 02, 2019 at 03:53:56PM +0300, Tomi Valkeinen wrote:
The hardware supports either size. Also add checks to ensure that only
these two sizes may be used for supplying a LUT.
Signed-off-by: Ilia Mirkin
---
Only tested on G84 and GK208. The GV100+ is entirely untested.
With the fixed modetest tool, setting ilut and olut sizes to different
On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä
wrote:
>
> On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma wrote:
> >
> >
> > >-Original Message-
> > >From: Ilia Mirkin
> > >Sent: Tuesday, September 3, 2019 6:12 PM
> > >To:
On Sat, Sep 7, 2019 at 7:20 PM Mun, Gwan-gyeong
wrote:
>
> On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote:
> > On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä
> > wrote:
> > > On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma wrote:
> > &g
On Wed, Aug 21, 2019 at 7:55 AM Thierry Reding wrote:
>
> On Wed, Aug 21, 2019 at 04:33:58PM +1000, Ben Skeggs wrote:
> > On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann wrote:
> > >
> > > Hi,
> > >
> > > > > Changing the order doesn't look hard. Patch attached (untested, have
> > > > > no
> > >
On Tue, Sep 10, 2019 at 3:34 AM Mun, Gwan-gyeong
wrote:
>
> On Sat, 2019-09-07 at 21:43 -0400, Ilia Mirkin wrote:
> > On Sat, Sep 7, 2019 at 7:20 PM Mun, Gwan-gyeong
> > wrote:
> > > On Fri, 2019-09-06 at 09:24 -0400, Ilia Mirkin wrote:
> > > > On Fr
On Tue, Sep 10, 2019 at 9:21 AM Ilia Mirkin wrote:
>
> On Tue, Sep 10, 2019 at 3:34 AM Mun, Gwan-gyeong
> wrote:
> >
> > On Sat, 2019-09-07 at 21:43 -0400, Ilia Mirkin wrote:
> > > On Sat, Sep 7, 2019 at 7:20 PM Mun, Gwan-gyeong
> > > wrote:
> >
On Wed, Aug 7, 2019 at 5:55 PM Daniel Vetter wrote:
>
> On Wed, Aug 07, 2019 at 05:33:00PM -0400, Lyude Paul wrote:
> > The code claims to grab a runtime PM ref when at least one CRTC is
> > active, but that's not actually the case as we grab a runtime PM ref
> > whenever a CRTC is enabled regardl
Another instance of a report like this here:
https://gitlab.freedesktop.org/drm/nouveau/-/issues/92
On Sat, Jun 5, 2021 at 3:53 PM Ondrej Zary wrote:
>
> Hello,
> I'm testing 5.13.0-rc4 and nouveau crashes with NULL pointer dereference in
> nouveau_bo_sync_for_device.
> Found various reports lik
Christian - potentially relevant is that Tegra doesn't have VRAM at
all -- all GTT (or GART or whatever it's called nowadays). No
fake/stolen VRAM.
Cheers,
-ilia
On Wed, Jun 9, 2021 at 10:18 AM Christian König
wrote:
>
> Hi Mikko,
>
> strange sounds like Nouveau was somehow also using the GEM
that later
> today.
>
> Regards,
> Christian.
>
> Am 09.06.21 um 16:52 schrieb Ilia Mirkin:
> > Christian - potentially relevant is that Tegra doesn't have VRAM at
> > all -- all GTT (or GART or whatever it's called nowadays). No
> > fake/stolen VRAM.
On Fri, May 26, 2023 at 5:11 AM Karol Herbst wrote:
>
> 1ba6113a90a0 removed a lot of the kernel GPU channel, but method 0x128
> was important as otherwise the GPU spams us with `CACHE_ERROR` messages.
>
> We use the blit subchannel inside our vblank handling, so we should keep
> at least this par
On Wed, Mar 29, 2017 at 10:24 AM, Alastair Bridgewater
wrote:
> On Wed, Mar 29, 2017 at 8:02 AM, Ville Syrjälä
> wrote:
>>
>> On Mon, Mar 27, 2017 at 05:57:57PM -0400, Alastair Bridgewater wrote:
>> > And the tenth patch enables stereo mode support... on HDMI and DPort
>> > connectors on nv50+ h
On Mon, Apr 10, 2017 at 10:17 AM, Gerd Hoffmann wrote:
> Hi,
>
>> which software have you used as representative of "reality"?
>
> ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm
> driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and
> only format supp
On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen wrote:
> On Mon, 10 Apr 2017 16:17:27 +0200
> Gerd Hoffmann wrote:
>
>> Hi,
>>
>> > which software have you used as representative of "reality"?
>>
>> ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm
>> driver. Xorg with
On Tue, Apr 11, 2017 at 3:31 AM, Pekka Paalanen wrote:
> On Mon, 10 Apr 2017 12:10:14 -0400
> Ilia Mirkin wrote:
>
>> On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen wrote:
>
>> > I also wonder if a real BE machine could have different results than
>> > the
On Tue, Apr 11, 2017 at 1:11 PM, Alastair Bridgewater
wrote:
> Enable stereoscopic output for HDMI and DisplayPort connectors on
> NV50+ (G80+) hardware. We do not enable stereoscopy on older
> hardware in case there is some older board that still has HDMI
> output but for which we have no logic
On Thu, Apr 13, 2017 at 11:36 AM, Alex Deucher wrote:
> On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan wrote:
>> 2017-04-13 16:05 keltezéssel, Alex Deucher írta:
>>>
>>> On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan wrote:
Hi,
how can I disable the behaviour in th
On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote:
>> However, I totally agree with Alex that someone with a BE machine
>> should review the whole stack before we could be confident with anything.
>
> Here's what I'm confident about: xf86-video-nouveau worked just fi
On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer wrote:
> On 17/04/17 03:43 PM, Ilia Mirkin wrote:
>> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin wrote:
>>>> However, I totally agree with Alex that someone with a BE machine
>>>> should review the whole stack
fourcc is not a string, it's a packed integer. This happens to work out
on LE, but gets reversed on BE.
Signed-off-by: Ilia Mirkin
---
tests/modetest/modetest.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/tests/modetest/modetest.c b/tests/modetest/modet
On Tue, Apr 18, 2017 at 9:01 PM, Michel Dänzer wrote:
> On 18/04/17 07:14 PM, Gerd Hoffmann wrote:
>> Hi,
>>
Quite true that this proves nothing. However one should note that
fbcon -> fbdev works,
>>>
>>> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses
>>> e.g.
On Tue, Apr 18, 2017 at 11:19 PM, Ilia Mirkin wrote:
> On Tue, Apr 18, 2017 at 9:01 PM, Michel Dänzer wrote:
>> On 18/04/17 07:14 PM, Gerd Hoffmann wrote:
>>> Hi,
>>>
>>>>> Quite true that this proves nothing. However one should note that
>&
All kernel patches must have a Signed-off-by: $user. See
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin
On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador
wrote:
> This is a preparation for the next patches. It just adds th
On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador
wrote:
> +static char *input_label = "GPU core";
This needs to be static const char input_label[] = "GPU core";
or at least static const char *const input_label = "GPU core";
-ilia
___
dri-devel mailin
On Mon, Apr 17, 2017 at 3:47 AM, Oscar Salvador
wrote:
> This patch creates a special group attributes for attrs like "*auto_point*".
> We check if we have support for them, and if we do, we gather them all in
> an attribute_group's structure which is the parameter regarding special groups
> of hw
t know whether they're broken, and comments we're
pretty sure are at least somewhat wrong. Furthermore the hardware is
relatively rare and developers with time to work on improving it are
even rarer.
I'd like to reiterate that the status quo does end up in a functioning
system. Let's t
On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä
wrote:
> On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote:
>> On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann wrote:
>> > While working on graphics support for virtual machines on ppc64 (which
>> > exists in
On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä
wrote:
> On Sat, Apr 22, 2017 at 01:07:57AM -0400, Ilia Mirkin wrote:
>> On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä
>> wrote:
>> > On Fri, Apr 21, 2017 at 10:49:49AM -0400, Ilia Mirkin wrote:
>> >> On Fri, Ap
On Sat, Apr 22, 2017 at 9:40 AM, Ilia Mirkin wrote:
> On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä
> wrote:
>> On Sat, Apr 22, 2017 at 01:07:57AM -0400, Ilia Mirkin wrote:
>>> On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä
>>> wrote:
>>> > On F
On Sat, Apr 22, 2017 at 9:48 AM, Ilia Mirkin wrote:
> On Sat, Apr 22, 2017 at 9:40 AM, Ilia Mirkin wrote:
>> On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä
>> wrote:
>>> On Sat, Apr 22, 2017 at 01:07:57AM -0400, Ilia Mirkin wrote:
>>>> On Fri, Apr 21, 2017 at
On Tue, May 2, 2017 at 11:06 AM, Gerd Hoffmann wrote:
> Radeon and nvidia (nv40) cards where mentioned. I'll try to summarize
> (feel free to correct me if I'm wrong).
>
> nvidia has support for 8 bit-per-color formats only on bigendian hosts.
> Not sure whenever this is a driver or hardware limi
d=97620
Cc: sta...@vger.kernel.org # v4.6+
Signed-off-by: Ilia Mirkin
---
Not sure if this is safe to do esp on GM20x+ boards?
drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gf100.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gf1
620
Cc: # v4.6+
Signed-off-by: Ilia Mirkin
---
v1 -> v2: add vga.h include (had it sitting in my local tree but forgot to
amend the commit with it)
drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gf100.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/n
I believe what's missing at this point is a mmiotrace of the NVIDIA
driver to make sure that there's nothing different about this GPU. If
you can make one (see https://wiki.ubuntu.com/X/MMIOTracing for a
guide - should end up ~100MB uncompressed), please send a compressed
one to mmio.du...@gmail.co
On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita
wrote:
> I'm happy to file
> a bugzilla entry and provide any other needed information or help with
> testing. Are nouveau bugs tracked on bugs.kernel.org or the fdo
> bugzilla?
Nouveau bugs are tracked on the fdo bugzilla. It would appear t
On Fri, Feb 17, 2017 at 11:22 AM, João Paulo Rechi Vita
wrote:
> Hello Ilia,
>
> On 17 February 2017 at 11:14, Ilia Mirkin wrote:
>> On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita
>> wrote:
>>> I'm happy to file
>>> a bugzilla entry and provi
On Tue, Nov 8, 2016 at 8:56 AM, Arnd Bergmann wrote:
> The newly introduced LED handling for nouveau fails to link when the
> driver is built-in but the LED subsystem is a loadable module:
>
> drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do_suspend':
> tvnv17.c:(.text.nouveau_do_suspend
On Tue, Jun 20, 2017 at 12:54 PM, Olof Johansson wrote:
> Hey,
>
> This was reported back in February and it seems nobody's given a shit?
>
Apparently not -- including you. Someone who was interested in seeing this
issue fixed would certainly have provided a kernel bisection result as it's
appar
Some details that may be useful in analysis of the bug:
1. lspci -nn -d 10de:
2. What displays, if any, you have plugged into the NVIDIA board when
this happens?
3. Any boot parameters, esp relating to ACPI, PM, or related?
Cheers,
-ilia
On Tue, Jul 11, 2017 at 1:32 PM, Mike Galbraith wrote:
On Tue, Jul 11, 2017 at 2:08 PM, Mike Galbraith wrote:
> On Tue, 2017-07-11 at 13:51 -0400, Ilia Mirkin wrote:
>> Some details that may be useful in analysis of the bug:
>>
>> 1. lspci -nn -d 10de:
>
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204
On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith wrote:
> On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote:
>> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote:
>> >
>> > Some display stuff did change for 4.13 for GM20x+ boards. If it's not
>>
On Thu, Mar 16, 2017 at 5:25 PM, Dylan Baker wrote:
> Why bother, and why would we want this?
>│~
>
> First it's written in python, which means the potential developer base
> is massive. And it provides a recursive view for humans, but
=70388
Signed-off-by: Ilia Mirkin
Cc: sta...@vger.kernel.org
---
OK, so I'm not 100% sure about my claims, but I don't have the necessary
hardware to test it out. Right now, AGP nv41+ boards are getting the nv04
mmu, while PCI nv41+ boards are getting the PCIE one. Perhaps this work
Signed-off-by: Ilia Mirkin
Fixes: 590801c1a3 ("drm/nouveau/mpeg: remove dependence on namedb/engctx
lookup")
Cc: sta...@vger.kernel.org # v4.3+
---
This is just a nice-to-have, as it only affects an error print afterwards.
drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv31.c | 2 +-
d
On Tue, Mar 21, 2017 at 11:13 AM, Grazvydas Ignotas wrote:
> everyone building graphics stacks or contributing to
> mesa should already be comfortable with cmake thanks to piglit and
> llvm, which might not be the case for meson.
Or they could be contributing to mesa because it's the last project
On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC 1
On Thu, Mar 23, 2017 at 11:22 AM, Sharma, Shashank
wrote:
> On 3/23/2017 5:17 PM, Ilia Mirkin wrote:
>>
>> On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
>> wrote:
>>>
>>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC
>>>
On Sun, Mar 26, 2017 at 6:14 PM, Ben Skeggs wrote:
> On 03/19/2017 06:23 AM, Ilia Mirkin wrote:
>>
>> The NV4A (aka NV44A) is an oddity in the family. It only comes in AGP
>> and PCI varieties, rather than a core PCIE chip with a bridge for
>> AGP/PCI as necessary. A
ction.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 80 +++---
1 file changed, 52 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index e54944d23268..ee7df9e
m.
I haven't at all tested on my NV05 or NV1x hardware. Should probably do that
before we push this out. But since I've already been sitting on these patches
for a few weeks, thought I'd get them out there.
Ilia Mirkin (3):
drm/nouveau/overlay: improve error detection, fix pitch sett
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
index ee7df9ef2695..96354a5ff21c 100644
--- a/drivers
55 however, as tested with modetest.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 36 -
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/cr
On Wed, Jun 7, 2017 at 7:52 AM, Noralf Trønnes wrote:
> Hi Emil,
>
>
> Den 07.06.2017 11.30, skrev Emil Velikov:
>>
>> Hi Noralf,
>>
>> Small drive-by comment, noticed while going through my morning coffee.
>> By no means a full review.
>>
>> On 2 June 2017 at 12:49, Noralf Trønnes wrote:
>>
>>
>
On Wed, Jun 7, 2017 at 6:36 PM, Rob Herring wrote:
> On Fri, Jun 02, 2017 at 09:42:19PM +0200, Maxime Ripard wrote:
>> On Fri, Jun 02, 2017 at 06:10:24PM +0800, Chen-Yu Tsai wrote:
>> > The MSI Primo81 tablet has a micro HDMI connector at the bottom.
>> > This is connected to the SoCs HDMI output.
Hi Alex,
As you're well-aware, your commit
8539b37acef73949861a16808b60cb8b5b9b3bab (drm/nouveau/gr: use
NVIDIA-provided external firmwares) broke tons of existing setups for
people who were using extracted firmware files (stored in the
"nouveau" firmware directory) as a result of nouveau's ctxsw
On Mon, Oct 31, 2016 at 2:31 AM, Alexandre Courbot wrote:
> On Mon, Oct 31, 2016 at 1:34 AM, Ilia Mirkin wrote:
>> Hi Alex,
>>
>> As you're well-aware, your commit
>> 8539b37acef73949861a16808b60cb8b5b9b3bab (drm/nouveau/gr: use
>> NVIDIA-provided exte
On Mon, Jan 2, 2017 at 6:31 AM, vathsala nagaraju
wrote:
> Program EDP_PSR_DEBUG_CTL (PSR_MASK) to enable system
> to go to deep sleep while in psr2.PSR2_STATUS bit 31:28
> should report value 8 , if system enters deep sleep state.
>
> Also, EDP_FRAMES_BEFORE_SU_ENTRY is set 1 , if not set,
> flic
On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter wrote:
> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
>> From: Randy Dunlap
>>
>> Fix build errors in nouveau driver when CONFIG_LEDS_CLASS=m and
>> CONFIG_DRM_NOUVEAU=y.
>> If LEDS_CLASS is enabled, DRM_NOUVEAU is restricted to the s
On Wed, Jan 4, 2017 at 9:52 PM, Randy Dunlap wrote:
> On 01/04/17 06:25, Ilia Mirkin wrote:
>> On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter wrote:
>>> On Sun, Jan 01, 2017 at 04:20:53PM -0800, Randy Dunlap wrote:
>>>> From: Randy Dunlap
>>>>
&g
On Wed, Jan 4, 2017 at 10:17 PM, Randy Dunlap wrote:
> On 01/04/17 19:09, Ilia Mirkin wrote:
>> On Wed, Jan 4, 2017 at 9:52 PM, Randy Dunlap
>> wrote:
>>> On 01/04/17 06:25, Ilia Mirkin wrote:
>>>> On Wed, Jan 4, 2017 at 3:45 AM, Daniel Vetter wrote:
>
The issue was recorded in fd.o bug 27501, not 25701.
Signed-off-by: Ilia Mirkin
---
drivers/gpu/drm/nouveau/nvkm/subdev/fb/rammcp77.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/rammcp77.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb
On Tue, Jan 17, 2017 at 5:42 PM, Alastair Bridgewater
wrote:
> HDMI specification 1.4a, table 8-15 is very explicitly a "must
> support at least one of" table, not a "must support all of" table.
> It is not hard to find hardware that does not support some of the
> so-called "mandatory" modes.
>
>
On Wed, Jan 18, 2017 at 6:45 AM, Damien Lespiau
wrote:
> On Wed, Jan 18, 2017 at 12:10:56AM -0500, Ilia Mirkin wrote:
>> On Tue, Jan 17, 2017 at 5:42 PM, Alastair Bridgewater
>> wrote:
>> > HDMI specification 1.4a, table 8-15 is very explicitly a "must
>> >
On Wed, Jan 18, 2017 at 11:41 AM, Damien Lespiau
wrote:
> On Wed, Jan 18, 2017 at 04:33:43PM +, Damien Lespiau wrote:
>> On Wed, Jan 18, 2017 at 11:27:16AM -0500, Ilia Mirkin wrote:
>> > Damien - did you ever test these mandatory modes on an actual
>> > commerc
On Wed, Jan 18, 2017 at 11:57 AM, Ilia Mirkin wrote:
> On Wed, Jan 18, 2017 at 11:41 AM, Damien Lespiau
> wrote:
>> On Wed, Jan 18, 2017 at 04:33:43PM +, Damien Lespiau wrote:
>>> On Wed, Jan 18, 2017 at 11:27:16AM -0500, Ilia Mirkin wrote:
>>> > Damien -
On May 3, 2016 9:49 AM, "Mika Kahola" wrote:
>
> DP specification 1.3 defines DP downstream ports for
> DP++ and wireless devices. Let's add these to port
> definitions.
>
> Signed-off-by: Mika Kahola
> ---
> include/drm/drm_dp_helper.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/
Do you have mesa 11.2 or later? GM20x support was only added in mesa 11.2.
Cheers,
-ilia
On Sat, May 28, 2016 at 4:51 PM, Andy Lutomirski wrote:
> I have the signed firmware (I think) and I'm running a fresh 4.6
> kernel. I got an image to show up briefly, rendering the Fedora
> sign-in scre
On Sun, May 29, 2016 at 3:07 PM, Andy Lutomirski wrote:
> On Sat, May 28, 2016 at 5:48 PM, Ilia Mirkin wrote:
>> Do you have mesa 11.2 or later? GM20x support was only added in mesa 11.2.
>>
>
> I just upgraded to 11.2. I'm getting errors like this in the log:
>
>
On Wed, Jan 6, 2016 at 10:26 AM, Sascha Hauer wrote:
> On Wed, Jan 06, 2016 at 02:53:30PM +0100, Boris Brezillon wrote:
>> Hi Sascha,
>>
>> On Wed, 6 Jan 2016 14:47:36 +0100
>> Sascha Hauer wrote:
>>
>> > Hi Boris,
>> >
>> > On Wed, Jan 06, 2016 at 12:25:50PM +0100, Boris Brezillon wrote:
>> > >
Reviewed-by: Ilia Mirkin
On Tue, Jan 12, 2016 at 4:14 PM, Marek Olšák wrote:
> From: Marek Olšák
>
> It warns for all "{}" initializers. Well, I want us to use {}.
> ---
> configure.ac | 3 ++-
> intel/intel_decode.c | 2 --
> 2 files change
Interesting. I do remember seeing some snow on NV5's overlay at high
resolutions. Wonder if it was because of this missing code...
On Thu, Apr 30, 2020 at 4:19 PM Souptick Joarder wrote:
>
> These are dead code since 3.10. If there is no plan to use
> it further, these can be removed forever.
>
>
On Fri, May 1, 2020 at 9:15 AM Souptick Joarder wrote:
>
> On Fri, May 1, 2020 at 2:21 AM Ilia Mirkin wrote:
> >
> > Interesting. I do remember seeing some snow on NV5's overlay at high
> > resolutions. Wonder if it was because of this missing code...
>
> W
On Mon, May 11, 2020 at 6:42 PM Lyude Paul wrote:
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index 43bcbb6d73c4..6dae00da5d7e 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_connec
On Fri, Oct 9, 2020 at 5:54 PM Karol Herbst wrote:
>
> On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary wrote:
> >
> > Hello,
> > I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped working:
> > [0.00] Linux version 5.9.0-rc8+ (zary@gsql) (gcc (Debian 8.3.0-6)
> > 8.3.0, GNU ld (GNU Binuti
On Tue, Oct 20, 2020 at 1:17 PM Alex Deucher wrote:
>
> On Mon, Oct 19, 2020 at 3:43 PM Kevin Brace wrote:
> >
> > Hi Sam,
> >
> > Thanks for asking the question.
> > The current OpenChrome DRM code has these two major issues.
> >
> > 1) It does not support atomic modesetting
> >
> > I do interna
On Thu, Oct 22, 2020 at 12:55 PM Lyude Paul wrote:
>
> Noticed this when trying to compile with -Wall on a kernel fork. We
> potentially
> don't set width here, which causes the compiler to complain about width
> potentially being uninitialized in drm_cvt_modes(). So, let's fix that.
>
> Signed-o
Hi Boris,
There was a fixup to that patch that you'll also have to revert first
-- 7dbbdd37f2ae7dd4175ba3f86f4335c463b18403. I guess there's some
subtle difference between the old open-coded logic and the helper,
they were supposed to be identical.
Cheers,
-ilia
On Thu, Jun 18, 2020 at 4:09 P
Not an enormous fan of what you had to do in atomic_set_planes, but
OTOH I don't see a much better way to do it either.
Reviewed-by: Ilia Mirkin
On Tue, Mar 17, 2020 at 8:11 AM Rohit Visavalia
wrote:
>
> Current implementation shows error as "failed to set gamma: Function
>
Can we use 6bpc on arbitrary DP monitors, or is there a capability for
it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8?
On Tue, Sep 22, 2020 at 5:06 PM Lyude Paul wrote:
>
> While I thought I had this correct (since it actually did reject modes
> like I expected during testin
On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul wrote:
>
> On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote:
> > Can we use 6bpc on arbitrary DP monitors, or is there a capability for
> > it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8?
>
> I don'
On Fri, Sep 25, 2020 at 6:08 PM Lyude Paul wrote:
>
> On Tue, 2020-09-22 at 17:22 -0400, Ilia Mirkin wrote:
> > On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul wrote:
> > > On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote:
> > > > Can we use 6bpc on arbitrary DP m
On Wed, Aug 12, 2020 at 8:24 AM Karol Herbst wrote:
>
> On Wed, Aug 12, 2020 at 12:43 PM Karol Herbst wrote:
> >
> > On Wed, Aug 12, 2020 at 12:27 PM Karol Herbst wrote:
> > >
> > > On Wed, Aug 12, 2020 at 2:19 AM James Jones wrote:
> > > >
> > > > Sorry for the slow reply here as well. I've b
Isn't this already fixed by
https://cgit.freedesktop.org/drm/drm/commit/?id=7dbbdd37f2ae7dd4175ba3f86f4335c463b18403
On Wed, May 27, 2020 at 9:43 AM Arnd Bergmann wrote:
>
> Calling directly into the fbdev stack only works when the
> fbdev layer is built into the kernel as well, or both are
> lo
On Mon, May 18, 2015 at 3:04 PM, Christian König
wrote:
> On 18.05.2015 20:50, Denys Vlasenko wrote:
>>
>> On 05/18/2015 08:06 PM, Christian König wrote:
>>>
>>> I'm actually surprised how often people come along with that. The last
>>> time we tried this it caused a noticeable performance drop.
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.
Signed-off-by: Ilia Mirkin
Cc: stable at kernel.org
---
drm
just reporting it?
>
> But for now this adds a helpful error message... you may add my R-b.
>
>
> On 20.05.2015 22:01, Ilia Mirkin wrote:
>>
>> Some newer chips have trouble coming up, and we get bad MMIO reads from
>> them, like 0xbadf100. This ends up translatin
On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau wrote:
> Most _DSM will return an integer value of 0x8002 when given an unknown
> UUID, revision ID or function ID. Checking locally allows us to differentiate
> that case from other ACPI errors, and to not report a "failed to evaluate
> _DSM"
>
On Tue, May 26, 2015 at 1:10 AM, Pierre Moreau wrote:
>> On 26 May 2015, at 00:39, Ilia Mirkin wrote:
>>
>>> On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau
>>> wrote:
>>> Most _DSM will return an integer value of 0x8002 when given an unknown
>>
ird option. Since having a page flip
> interrupt that happens when the pageflip gets armed and not when it
> completes in the next vblank seems to be fairly common (older i915 hw
> works very similarly) create a new helper to arm vblank events for
> such drivers.
>
> Bugzilla: https
On Jun 11, 2016 12:09 AM, "Andres Rodriguez"
wrote:
>
> When executing in a PCI passthrough based virtuzliation environemnt, the
> hypervisor will usually attempt to send a PCIe bus reset signal to the
> ASIC when the VM reboots. In this scenario, the card is not correctly
> initialized, but we st
On Thu, Jun 16, 2016 at 8:09 AM, Jose Abreu wrote:
> Hi Daniel,
>
> Sorry to bother you again. I promise this is the last time :)
>
> On 15-06-2016 11:15, Daniel Vetter wrote:
>> On Wed, Jun 15, 2016 at 11:48 AM, Jose Abreu
>> wrote:
>>> On 15-06-2016 09:52, Daniel Vetter wrote:
On Tue, Jun
On Sun, Jun 26, 2016 at 1:49 PM, Andy Lutomirski wrote:
> On Sun, May 29, 2016 at 12:27 PM, Andy Lutomirski wrote:
>> On Sun, May 29, 2016 at 12:22 PM, Ilia Mirkin
>> wrote:
>>> On Sun, May 29, 2016 at 3:07 PM, Andy Lutomirski wrote:
>>>> On Sat,
On Sun, Jun 26, 2016 at 2:04 PM, Andy Lutomirski wrote:
> Eeek! My desire to hack on EXA is pretty low. If there was some
Well, the EXA hacking was all done a long time ago. You'd just need to
add support for sticking 4 vertices into a buffer. (Maxwell killed
direct vertex submit, which was inc
On Tue, Jan 19, 2016 at 2:05 AM, Christian Gmeiner
wrote:
> The varyings count is stored as part of register VIVS_HI_CHIP_SPECS_3.
> Userspace still needs to validate the returned values as it can be 0
> like on the imx6q.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etna
On Tue, Jan 19, 2016 at 3:11 AM, Christian Gmeiner
wrote:
> 2016-01-19 8:16 GMT+01:00 Ilia Mirkin :
>> On Tue, Jan 19, 2016 at 2:05 AM, Christian Gmeiner
>> wrote:
>>> The varyings count is stored as part of register VIVS_HI_CHIP_SPECS_3.
>>> Userspace still need
On Fri, Jan 22, 2016 at 12:18 PM, Marek Olšák wrote:
> On Fri, Jan 22, 2016 at 6:13 PM, Emil Velikov
> wrote:
>> On 21 January 2016 at 16:58, Marek Olšák wrote:
>>> On Thu, Jan 21, 2016 at 2:09 PM, Emil Velikov
>>> wrote:
On 21 January 2016 at 12:08, Marek Olšák wrote:
> On Th
101 - 200 of 521 matches
Mail list logo
