Re: [drm/nouveau] GeForce 8600 GT boot/suspend grumbling

[Ilia Mirkin]

On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith  wrote:
> Greetings,
>
> box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside
> kernel: master.today (v4.12-11690-gccd5d1b91f22)
>
> lspci -nn -d 10de:
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce 
> 8600 GT] [10de:0402] (rev a1)
>
> abreviated dmesg:
> ...
> [3.720990] fb: switching to nouveaufb from VESA VGA
> [3.744489] Console: switching to colour dummy device 80x25
> [3.744966] nouveau :01:00.0: NVIDIA G84 (084200a2)
> ...
> [3.846963] usbcore: registered new interface driver uas
> [3.849938] nouveau :01:00.0: bios: version 60.84.6e.00.12
> [3.870769] hid-generic 0003:04CA:002B.0002: input,hidraw1: USB HID v1.11 
> Keyboard [Liteon Wireless keyboard and mouse] on usb-:00:1d.0-1/input0
> [3.870773] nouveau :01:00.0: bios: M0203T not found
> [3.870774] nouveau :01:00.0: bios: M0203E not matched!
> [3.870777] nouveau :01:00.0: fb: 256 MiB DDR2
> [3.871168] input: Liteon Wireless keyboard and mouse as 
> /devices/pci:00/:00:1d.0/usb4/4-1/4-1:1.1/0003:04CA:002B.0003/input/input7
> [3.896090] usb 3-2: new low-speed USB device number 3 using uhci_hcd
> [3.919101] [TTM] Zone  kernel: Available graphics memory: 3881208 kiB
> [3.919106] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
> [3.919110] [TTM] Initializing pool allocator
> [3.919120] [TTM] Initializing DMA pool allocator
> [3.919141] nouveau :01:00.0: DRM: VRAM: 256 MiB
> [3.919146] nouveau :01:00.0: DRM: GART: 1048576 MiB
> [3.919152] nouveau :01:00.0: DRM: TMDS table version 2.0
> [3.919157] nouveau :01:00.0: DRM: DCB version 4.0
> [3.919162] nouveau :01:00.0: DRM: DCB outp 00: 04000310 0028
> [3.919167] nouveau :01:00.0: DRM: DCB outp 01: 02011300 0028
> [3.919171] nouveau :01:00.0: DRM: DCB outp 02: 01011302 0030
> [3.919176] nouveau :01:00.0: DRM: DCB outp 03: 02022322 00020010
> [3.919180] nouveau :01:00.0: DRM: DCB outp 04: 010333f1 00c0c083
> [3.919185] nouveau :01:00.0: DRM: DCB conn 00: 
> [3.919189] nouveau :01:00.0: DRM: DCB conn 01: 1130
> [3.919194] nouveau :01:00.0: DRM: DCB conn 02: 2261
> [3.919198] nouveau :01:00.0: DRM: DCB conn 03: 0310
> [3.919202] nouveau :01:00.0: DRM: DCB conn 04: 0311
> [3.919206] nouveau :01:00.0: DRM: DCB conn 05: 0313
> [3.919258] [ cut here ]
> [3.919316] WARNING: CPU: 3 PID: 224 at 
> drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c:83 
> nvkm_outp_xlat.isra.0+0x26/0x80 [nouveau]

The code in question is

static enum nvkm_ior_proto
nvkm_outp_xlat(struct nvkm_outp *outp, enum nvkm_ior_type *type)
{
switch (outp->info.location) {
case 0:
switch (outp->info.type) {
case DCB_OUTPUT_ANALOG: *type = DAC; return  CRT;
case DCB_OUTPUT_TMDS  : *type = SOR; return TMDS;
case DCB_OUTPUT_LVDS  : *type = SOR; return LVDS;
case DCB_OUTPUT_DP: *type = SOR; return   DP;
default:
break;
}
break;
case 1:
switch (outp->info.type) {
case DCB_OUTPUT_TMDS: *type = PIOR; return TMDS;
case DCB_OUTPUT_DP  : *type = PIOR; return TMDS; /* not a bug */
default:
break;
}
break;
default:
break;
}
WARN_ON(1);
return UNKNOWN;
}

Looks like someone forgot about TV S-Video/Composite outputs (which
existed up until the GT21x's).

> [3.919180] nouveau :01:00.0: DRM: DCB outp 04: 010333f1 00c0c083

And there ya go (the type is the lowest nibble of the first dword). We
don't support TV outputs on nv50+, so you could just add a

case DCB_OUTPUT_TV: return UNKNOWN;

in the location == 0 case.

I don't think that's related to the issue you're seeing on suspend
though, as the TV connector isn't created anyways, it's just an
"annoyance" warn, and you were also seeing it on your GM20x which has
no such thing.

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Ilia Mirkin]

On Fri, Jul 14, 2017 at 11:19 AM, Tobias Klausmann
 wrote:
> The conversion is a nice catch, but i'd like to have a bit more context, see
> below!
>
> With a better description:
>
> Tobias Klausmann 

I don't think it was meant as a serious patch. WARN_ON_ONCE should
work. The fix isn't to remove all instances of WARN_ON_ONCE. The fix
is to fix WARN_ON_ONCE.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Ilia Mirkin]

On Fri, Jul 14, 2017 at 11:15 AM, Mike Galbraith  wrote:
> On Fri, 2017-07-14 at 17:10 +0200, Karol Herbst wrote:
>> Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE
>> usage we could convert to WARN_ONCE?
>
> Shooting the messenger is generally considered uncool :)

That's never stopped it from being a popular practice...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Ilia Mirkin]

On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith <efa...@gmx.de> 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
>> > too much trouble, a bisect would be pretty useful.
>>
>> Bisection seemingly went fine, but the result is odd.
>>
>> e98c58e55f68f8785aebfab1f8c9a03d8de0afe1 is the first bad commit
>
> But it really really is bad.  Looking at gitk fork in the road leading
> to it...
>
> 52d9d38c183b drm/sti:fix spelling mistake: "compoment" -> "component" - good
> e4e818cc2d7c drm: make drm_panel.h self-contained - good
> 9cf8f5802f39 drm: add missing declaration to drm_blend.h  - good
>
> Before the git highway splits, all is well.  The lane with commits
> works fine at both ends, but e98c58e55f68 is busted.  Merge arfifact?

Hmmm... that tree does not appear to have gotten a v4.12 backmerge at
any point. The last backmerge from Linus as far as I can tell was
v4.11-rc7. Could be an interaction with some out-of-tree change.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Ilia Mirkin]

On Tue, Jul 11, 2017 at 2:08 PM, Mike Galbraith <efa...@gmx.de> 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 [GeForce 
> GTX 980] [10de:13c0] (rev a1)
> 01:00.1 Audio device [0403]: NVIDIA Corporation GM204 High Definition Audio 
> Controller [10de:0fbb] (rev a1
>
>> 2. What displays, if any, you have plugged into the NVIDIA board when
>> this happens?
>
> A Philips 273V, via DVI.
>
>> 3. Any boot parameters, esp relating to ACPI, PM, or related?
>
> None for those, what's there that will be unfamiliar to you are for
> patches that aren't applied.
>
> nortsched hpc_cpusets skew_tick=1 ftrace_dump_on_oops audit=0
> nodelayacct cgroup_disable=memory rtkthreads=1 rtworkqueues=2 panic=60
> ignore_loglevel crashkernel=256M,high

OK, thanks. So in other words, a fairly standard desktop with a PCIe
board plugged in. No funny business. (Laptops can create a ton of
additional weirdness, which I assumed you had since you were talking
about STR.)

My best guess is that gf119_head_vblank_put either has a bogus head id
(should be in the 0..3 range) which causes it to do an out-of-bounds
read on MMIO space, or that the MMIO mapping has already been removed
by the time nouveau_display_suspend runs. Adding Ben Skeggs for
additional insight.

Some display stuff did change for 4.13 for GM20x+ boards. If it's not
too much trouble, a bisect would be pretty useful.

Cheers,

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

[Ilia Mirkin]

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:
> Greetings,
>
> I met $subject in master-rt post drm merge, but taking the config
> (attached) to virgin v4.12-10624-g9967468c0a10, it's reproducible.
>
>   KERNEL: vmlinux-4.12.0.g9967468-preempt.gz
> DUMPFILE: vmcore
> CPUS: 8
> DATE: Tue Jul 11 18:55:28 2017
>   UPTIME: 00:02:03
> LOAD AVERAGE: 3.43, 1.39, 0.52
>TASKS: 467
> NODENAME: homer
>  RELEASE: 4.12.0.g9967468-preempt
>  VERSION: #155 SMP PREEMPT Tue Jul 11 18:18:11 CEST 2017
>  MACHINE: x86_64  (3591 Mhz)
>   MEMORY: 16 GB
>PANIC: "BUG: unable to handle kernel paging request at 
> a022990f"
>  PID: 4658
>  COMMAND: "kworker/u16:26"
> TASK: 8803c6068f80  [THREAD_INFO: 8803c6068f80]
>  CPU: 7
>STATE: TASK_RUNNING (PANIC)
>
> crash> bt
> PID: 4658   TASK: 8803c6068f80  CPU: 7   COMMAND: "kworker/u16:26"
>  #0 [c900039f76a0] machine_kexec at 810481fc
>  #1 [c900039f76f0] __crash_kexec at 81109e3a
>  #2 [c900039f77b0] crash_kexec at 8110adc9
>  #3 [c900039f77c8] oops_end at 8101d059
>  #4 [c900039f77e8] no_context at 81055ce5
>  #5 [c900039f7838] do_page_fault at 81056c5b
>  #6 [c900039f7860] page_fault at 81690a88
> [exception RIP: report_bug+93]
> RIP: 8167227d  RSP: c900039f7918  RFLAGS: 00010002
> RAX: a0229905  RBX: a020af0f  RCX: 0001
> RDX: 0907  RSI: a020af11  RDI: 98f6
> RBP: c900039f7a58   R8: 0001   R9: 03fc
> R10: 81a01906  R11: 8803f84711f8  R12: a02231fb
> R13: 0260  R14: 0004  R15: 0006
> ORIG_RAX:   CS: 0010  SS: 0018
>  #7 [c900039f7910] report_bug at 81672248
>  #8 [c900039f7938] fixup_bug at 8101af85
>  #9 [c900039f7950] do_trap at 8101b0d9
> #10 [c900039f79a0] do_error_trap at 8101b190
> #11 [c900039f7a50] invalid_op at 8169063e
> [exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335]
> RIP: a020af0f  RSP: c900039f7b00  RFLAGS: 00010086
> RAX: a04fa100  RBX: 8803f9550800  RCX: 0001
> RDX: a0228a58  RSI: 0001  RDI: a022321b
> RBP: c900039f7b80   R8:    R9: a020adc0
> R10: a048a1b0  R11: 8803f84711f8  R12: 0001
> R13: 8803f8471000  R14: c900039f7b94  R15: c900039f7bd0
> ORIG_RAX:   CS: 0010  SS: 0018
> #12 [c900039f7b18] gf119_head_vblank_put at a04422f9 [nouveau]
> #13 [c900039f7b88] drm_get_last_vbltimestamp at a020ad91 [drm]
> #14 [c900039f7ba8] drm_update_vblank_count at a020b3e1 [drm]
> #15 [c900039f7c10] drm_vblank_disable_and_save at a020bbe9 [drm]
> #16 [c900039f7c40] drm_crtc_vblank_off at a020c3c0 [drm]
> #17 [c900039f7cb0] nouveau_display_fini at a048a4d6 [nouveau]
> #18 [c900039f7ce0] nouveau_display_suspend at a048ac4f [nouveau]
> #19 [c900039f7d00] nouveau_do_suspend at a047e5ec [nouveau]
> #20 [c900039f7d38] nouveau_pmops_suspend at a047e77d [nouveau]
> #21 [c900039f7d50] pci_pm_suspend at 813b1ff0
> #22 [c900039f7d80] dpm_run_callback at 814c4dbd
> #23 [c900039f7db8] __device_suspend at 814c5a61
> #24 [c900039f7e30] async_suspend at 814c5cfa
> #25 [c900039f7e48] async_run_entry_fn at 81091683
> #26 [c900039f7e70] process_one_work at 810882bc
> #27 [c900039f7eb0] worker_thread at 8108854a
> #28 [c900039f7f10] kthread at 8108e387
> #29 [c900039f7f50] ret_from_fork at 8168fa85
> crash> gdb list *drm_calc_vbltimestamp_from_scanoutpos+335
> 0xa020af0f is in drm_calc_vbltimestamp_from_scanoutpos 
> (drivers/gpu/drm/drm_vblank.c:608).
> 603 /* If mode timing undefined, just return as no-op:
> 604  * Happens during initial modesetting of a crtc.
> 605  */
> 606 if (mode->crtc_clock == 0) {
> 607 DRM_DEBUG("crtc %u: Noop due to uninitialized 
> mode.\n", pipe);
> 608 WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev));
> 609
> 610 return false;
> 611 }
> 612
> crash> gdb list *report_bug+93
> 0x8167227d is in report_bug (lib/bug.c:177).
> 172 return BUG_TRAP_TYPE_WARN;
> 173
> 174

Re: [Bug 99900] nouveau: freeze / crash after kernel update to 4.10

[Ilia Mirkin]

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
apparently so easy to reproduce. (And if it's happening to so many people,
as you suggest, being an enormous regression, we should have hundreds of
bisection results by now all pointing to the same change.)

If you're not up to the task of providing a bisect result or helping with
further debugging, you should be reporting this to the distribution, which
has processes in place to deal with end-users, tracking distro regressions,
and interfacing with upstream development "teams".

Cheers,

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 19/19] ARM: sun6i: a31s: Enable HDMI display output on the MSI Primo81 tablet

[Ilia Mirkin]

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.
>> >
>> > Enable the display pipeline and the HDMI output.
>> >
>> > Signed-off-by: Chen-Yu Tsai 
>> > ---
>> >  arch/arm/boot/dts/sun6i-a31s-primo81.dts | 25 +
>> >  1 file changed, 25 insertions(+)
>> >
>> > diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts 
>> > b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
>> > index f3712753fa42..26154b2f87a3 100644
>> > --- a/arch/arm/boot/dts/sun6i-a31s-primo81.dts
>> > +++ b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
>> > @@ -52,17 +52,42 @@
>> >  / {
>> > model = "MSI Primo81 tablet";
>> > compatible = "msi,primo81", "allwinner,sun6i-a31s";
>> > +
>> > +   hdmi-connector {
>> > +   compatible = "hdmi-connector";
>> > +   type = "c";
>>
>> Should we add a connector type for this one?
>
> c as in USB Type C? I'd prefer to see a new compatible string. Is type
> even documented?

Probably as in HDMI Type C (there are Type A, C, and D connectors, aka
"regular", "mini", and "micro").
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/4] drm/tinydrm: Add RePaper e-ink driver

[Ilia Mirkin]

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:
>>
>>
>>> +/* pixels on display are numbered from 1 */
>>> +static void repaper_all_pixels(struct repaper_epd *epd, u8 **pp,
>>> +  const u8 *data, u8 fixed_value, const u8
>>> *mask,
>>> +  enum repaper_stage stage)
>>> +{
>>> +   unsigned int b;
>>> +
>>> +   for (b = epd->width / 8; b > 0; b--) {
>>> +   if (data) {
>>> +   u16 pixels = repaper_interleave_bits(data[b -
>>> 1]);
>>> +   u16 pixel_mask = 0x;
>>> +
>>> +   if (mask) {
>>> +   u16 pixel_mask =
>>> repaper_interleave_bits(mask[b - 1]);
>>> +
>>> +   pixel_mask = (pixel_mask ^ pixels) &
>>> 0x;
>>> +   pixel_mask |= pixel_mask << 1;
>>
>> The second u16 pixel_mask seems very suspicious - likely a copy/paste
>> mistake ?
>
>
> Actually it's a correct copy. The same pattern is used in three places.
> I did look at the datasheet to try and understand what was going on,
> but the current and previous frame is applied in normal and inverted
> form in several stages, the pixels are converted to black/white/nochange
> and then I lost track of it all.
> So I decided that the Pervasive people who wrote the driver probably
> knew what they where doing. At least it works!

It's doubling up the bits... 0x is a 0101010101010101 pattern, so
pixel_mask |= pixel_mask << 1 (after pixel_mask is x & 0x) is just
saying that the same bit should be repeated twice.

As for why you'd want to do that ... no clue. Maybe it's a
2-bit-per-pixel packed mask and you want to set each pixel to 11 or 00
here?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 3/3] drm/nouveau/dispnv04: fix exposed format list

[Ilia Mirkin]

drm_crtc_init exposes the XRGB and ARGB formats. In actuality,
ARGB's 32-bit depth messes up some formulas that weren't meant for
it, and the alpha is failry meaningless for the primary plane.

The modesetting logic appears to be fully prepared for RGB565 as well as
XRGB1555 however, as tested with modetest.

Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
 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/crtc.c
index 4b4b0b496262..c078811b4e11 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -1099,6 +1099,38 @@ static const struct drm_crtc_helper_funcs 
nv04_crtc_helper_funcs = {
.disable = nv_crtc_disable,
 };
 
+static const uint32_t modeset_formats[] = {
+DRM_FORMAT_XRGB,
+DRM_FORMAT_RGB565,
+DRM_FORMAT_XRGB1555,
+};
+
+static struct drm_plane *
+create_primary_plane(struct drm_device *dev)
+{
+struct drm_plane *primary;
+int ret;
+
+primary = kzalloc(sizeof(*primary), GFP_KERNEL);
+if (primary == NULL) {
+DRM_DEBUG_KMS("Failed to allocate primary plane\n");
+return NULL;
+}
+
+/* possible_crtc's will be filled in later by crtc_init */
+ret = drm_universal_plane_init(dev, primary, 0,
+   _primary_helper_funcs,
+   modeset_formats,
+   ARRAY_SIZE(modeset_formats),
+   DRM_PLANE_TYPE_PRIMARY, NULL);
+if (ret) {
+kfree(primary);
+primary = NULL;
+}
+
+return primary;
+}
+
 int
 nv04_crtc_create(struct drm_device *dev, int crtc_num)
 {
@@ -1122,7 +1154,9 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num)
nv_crtc->save = nv_crtc_save;
nv_crtc->restore = nv_crtc_restore;
 
-   drm_crtc_init(dev, _crtc->base, _crtc_funcs);
+   drm_crtc_init_with_planes(dev, _crtc->base,
+  create_primary_plane(dev), NULL,
+  _crtc_funcs, NULL);
drm_crtc_helper_add(_crtc->base, _crtc_helper_funcs);
drm_mode_crtc_set_gamma_size(_crtc->base, 256);
 
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 0/3] drm/nouveau/dispnv04 overlay and primary fb format fixes

[Ilia Mirkin]

This came out of some debugging I was doing to figure out how BE mode works
on this hardware. Among other things, it came out that we're not exposing
16-bpp mode support and that the ARGB mode that we do expose is broken.
Also the overlay logic was pretty broken, I must have only tested with very
"normal" overlay buffer sizes with modetest before.

That said, this code has only received literal testing on a NV34/G5 PPC combo.
I was poking at various registers on a NV34/x86 to make modetest display the
correct data though. That's where e.g. the pitch mask comes from.

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 setting
  drm/nouveau/overlay: add NV21 support
  drm/nouveau/dispnv04: fix exposed format list

 drivers/gpu/drm/nouveau/dispnv04/crtc.c| 36 +++-
 drivers/gpu/drm/nouveau/dispnv04/overlay.c | 89 +++---
 2 files changed, 93 insertions(+), 32 deletions(-)

-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 2/3] drm/nouveau/overlay: add NV21 support

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
 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/gpu/drm/nouveau/dispnv04/overlay.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
@@ -63,6 +63,7 @@ static uint32_t formats[] = {
DRM_FORMAT_YUYV,
DRM_FORMAT_UYVY,
DRM_FORMAT_NV12,
+   DRM_FORMAT_NV21,
 };
 
 /* Sine can be approximated with
@@ -177,16 +178,18 @@ nv10_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
nvif_wr32(dev, NV_PVIDEO_POINT_OUT(flip), crtc_y << 16 | crtc_x);
nvif_wr32(dev, NV_PVIDEO_SIZE_OUT(flip), crtc_h << 16 | crtc_w);
 
-   if (fb->format->format != DRM_FORMAT_UYVY)
+   if (fb->format->format == DRM_FORMAT_YUYV ||
+   fb->format->format == DRM_FORMAT_NV12)
format |= NV_PVIDEO_FORMAT_COLOR_LE_CR8YB8CB8YA8;
-   if (fb->format->format == DRM_FORMAT_NV12)
+   if (fb->format->format == DRM_FORMAT_NV12 ||
+   fb->format->format == DRM_FORMAT_NV21)
format |= NV_PVIDEO_FORMAT_PLANAR;
if (nv_plane->iturbt_709)
format |= NV_PVIDEO_FORMAT_MATRIX_ITURBT709;
if (nv_plane->colorkey & (1 << 24))
format |= NV_PVIDEO_FORMAT_DISPLAY_COLOR_KEY;
 
-   if (fb->format->format == DRM_FORMAT_NV12) {
+   if (format & NV_PVIDEO_FORMAT_PLANAR) {
nvif_wr32(dev, NV_PVIDEO_UVPLANE_BASE(flip), 0);
nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
nv_fb->nvbo->bo.offset + fb->offsets[1]);
-- 
2.13.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 1/3] drm/nouveau/overlay: improve error detection, fix pitch setting

[Ilia Mirkin]

We were previously setting the pitch based on a perfectly packed buffer.
This does not necessarily happen. Either modetest started generating
such buffers recently, or earlier testing only happened with well-picked
overlay sizes.

While we're at it, beef up and refactor the error state detection.

Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---
 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..ee7df9ef2695 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/overlay.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/overlay.c
@@ -90,6 +90,42 @@ cos_mul(int degrees, int factor)
 }
 
 static int
+verify_fb(const struct drm_framebuffer *fb, uint32_t src_w, uint32_t src_h,
+ uint32_t crtc_w, uint32_t crtc_h, bool scale_fail, bool offset_fail)
+{
+   if (fb->pitches[0] & 0x3f) {
+   DRM_DEBUG_KMS("Unsuitable framebuffer for plane: align 64: 
0x%x\n",
+ fb->pitches[0]);
+   return -EINVAL;
+   }
+
+   if (fb->pitches[0] >= 0x1) {
+   DRM_DEBUG_KMS("Unsuitable framebuffer for plane: pitch 0x%x >= 
0x1\n",
+ fb->pitches[0]);
+   return -EINVAL;
+   }
+
+   if (fb->pitches[1] && fb->pitches[0] != fb->pitches[1]) {
+   DRM_DEBUG_KMS("Unsuitable framebuffer for plane: diff pitches: 
0x%x != 0x%x\n",
+ fb->pitches[0], fb->pitches[1]);
+   return -ERANGE;
+   }
+
+   if (scale_fail) {
+   DRM_DEBUG_KMS("Unsuitable framebuffer scaling: %dx%d -> 
%dx%d\n",
+ src_w, src_h, crtc_w, crtc_h);
+   return -ERANGE;
+   }
+
+   if (offset_fail) {
+   DRM_DEBUG_KMS("Unsuitable framebuffer offset\n");
+   return -ERANGE;
+   }
+
+   return 0;
+}
+
+static int
 nv10_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
  struct drm_framebuffer *fb, int crtc_x, int crtc_y,
  unsigned int crtc_w, unsigned int crtc_h,
@@ -107,7 +143,9 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
bool flip = nv_plane->flip;
int soff = NV_PCRTC0_SIZE * nv_crtc->index;
int soff2 = NV_PCRTC0_SIZE * !nv_crtc->index;
-   int format, ret;
+   unsigned shift = drm->client.device.info.chipset >= 0x30 ? 1 : 3;
+   unsigned format = 0;
+   int ret;
 
/* Source parameters given in 16.16 fixed point, ignore fractional. */
src_x >>= 16;
@@ -115,18 +153,11 @@ nv10_update_plane(struct drm_plane *plane, struct 
drm_crtc *crtc,
src_w >>= 16;
src_h >>= 16;
 
-   format = ALIGN(src_w * 4, 0x100);
-
-   if (format > 0x)
-   return -ERANGE;
-
-   if (drm->client.device.info.chipset >= 0x30) {
-   if (crtc_w < (src_w >> 1) || crtc_h < (src_h >> 1))
-   return -ERANGE;
-   } else {
-   if (crtc_w < (src_w >> 3) || crtc_h < (src_h >> 3))
-   return -ERANGE;
-   }
+   ret = verify_fb(fb, src_w, src_h, crtc_w, crtc_h,
+   crtc_w < (src_w >> shift) || crtc_h < (src_h >> shift),
+   false);
+   if (ret)
+   return ret;
 
ret = nouveau_bo_pin(nv_fb->nvbo, TTM_PL_FLAG_VRAM, false);
if (ret)
@@ -160,7 +191,7 @@ nv10_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
nvif_wr32(dev, NV_PVIDEO_UVPLANE_OFFSET_BUFF(flip),
nv_fb->nvbo->bo.offset + fb->offsets[1]);
}
-   nvif_wr32(dev, NV_PVIDEO_FORMAT(flip), format);
+   nvif_wr32(dev, NV_PVIDEO_FORMAT(flip), format | fb->pitches[0]);
nvif_wr32(dev, NV_PVIDEO_STOP, 0);
/* TODO: wait for vblank? */
nvif_wr32(dev, NV_PVIDEO_BUFFER, flip ? 0x10 : 0x1);
@@ -357,7 +388,7 @@ nv04_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
struct nouveau_bo *cur = nv_plane->cur;
uint32_t overlay = 1;
int brightness = (nv_plane->brightness - 512) * 62 / 512;
-   int pitch, ret, i;
+   int ret, i;
 
/* Source parameters given in 16.16 fixed point, ignore fractional. */
src_x >>= 16;
@@ -365,17 +396,9 @@ nv04_update_plane(struct drm_plane *plane, struct drm_crtc 
*crtc,
src_w >>= 16;
src_h >>= 16;
 
-   pitch = ALIGN(src_w * 4, 0x100);
-
-   if (pitch > 0x)
-   return -ERANGE;
-
-   /* TODO: Compute an offset? Not sure how to do this for YUYV.

Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN

[Ilia Mirkin]

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 limitation.

Let me just summarize the NVIDIA situation. First off, pre-nv50 and
nv50+ are entirely different and unrelated beasts.

The (pre-nv50) hardware has (a few) "big endian mode" bits. Those bits
are kind of unrelated to each other and control their own "domains".
One of the domains is reading of the scanout fb. So as a result, the
hardware can scan out XRGB, RGB565, and XRGB1555 stored in either
little or big endian packings, irrespective of the "mode" that other
parts of the hardware are in.

However there's the delicate little question of the GPU *generating*
the data. These older GPUs don't have quite the format flexibility
offered by newer hw. So only XRGB is supported, packed in whatever
"mode" the whole PGRAPH unit is in. (I say this because things seem to
work when rendering using the XRGB format while scanning out with
the BE flag set.)

There are no APIs for controlling the endianness of each engine in
nouveau, so it ends up being in "big endian" mode on BE hosts, so the
GPU can only render to big-endian-packed framebuffers.

None of this applies to nv50+ hw. (Although it might in broad strokes.)

Currently the driver is exposing XRGB and ARGB formats as
that's what drm_crtc_init does for it. However the ARGB format
doesn't work (and shouldn't be exposed, the alpha is meaningless on a
single-plane setup), and the XRGB format is assumed to be packed
in cpu host endian (and the "BE" bit is set accordingly).

Hope this helps!

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

On Sat, Apr 22, 2017 at 9:48 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> On Sat, Apr 22, 2017 at 9:40 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>> On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä
>> <ville.syrj...@linux.intel.com> 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ä
>>>> <ville.syrj...@linux.intel.com> 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 <kra...@redhat.com> 
>>>> >> wrote:
>>>> >> > While working on graphics support for virtual machines on ppc64 (which
>>>> >> > exists in both little and big endian variants) I've figured the 
>>>> >> > comments
>>>> >> > for various drm fourcc formats in the header file don't match reality.
>>>> >> >
>>>> >> > Comments says the RGB formats are little endian, but in practice they
>>>> >> > are native endian.  Look at the drm_mode_legacy_fb_format() helper.  
>>>> >> > It
>>>> >> > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no 
>>>> >> > matter
>>>> >> > whenever the machine is little endian or big endian.  The users of 
>>>> >> > this
>>>> >> > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the 
>>>> >> > framebuffer
>>>> >> > is native endian, not little endian.  Most userspace also operates on
>>>> >> > native endian only.
>>>> >> >
>>>> >> > So, go update the comments for all 16+24+32 bpp RGB formats.
>>>> >> >
>>>> >> > Leaving the yuv formats as-is.  I have no idea if and how those are 
>>>> >> > used
>>>> >> > on bigendian machines.
>>>> >>
>>>> >> I think this is premature. The current situation is that I can't get
>>>> >> modetest to work *at all* on my NV34 / BE setup (I mean, it runs, just
>>>> >> the colors displayed are wrong). I believe that currently it packs
>>>> >> things in "cpu native endian". I've tried futzing with that without
>>>> >> much success, although I didn't spend too much time on it. I have a
>>>> >> NV34 plugged into my LE setup as well although I haven't tested to
>>>> >> double-check that it all works there. However I'm quite sure it used
>>>> >> to, as I used modetest to help develop the YUV overlay support for
>>>> >> those GPUs.
>>>> >
>>>> > I just took a quick stab at fixing modetest to respect the current
>>>> > wording in drm_fourcc.h:
>>>> >
>>>> > git://github.com/vsyrjala/libdrm.git modetest_endian
>>>>
>>>> Looks like there was some careless testing on my part :( So ... it
>>>> looks like the current modetest without those changes does, in fact,
>>>> work on NV34/BE. With the changes, it breaks (and the handling of the
>>>> b* modes is a little broken in those patches -- they're not selectable
>>>> from the cmdline.) Which means that, as Michel & co predicted, it
>>>> appears to be taking BE input not LE input. This is very surprising to
>>>> me, but it is what it is. As I mentioned before, the details of how
>>>> the "BE" mode works on the GPUs is largely unknown to us beyond a few
>>>> basics. Note that only XR24 works, AR24 ends up with all black
>>>> displayed. This also happens on LE.
>>>
>>> Did you try 8bpp or 16bpp formats? I expect that if you've just blindly
>>> enabled some magic byte swapper in the hardware it will only for
>>> a specific pixel size.
>>
>> Thankfully dispnv04 exposes no such madness - just XR24 (and AR24,
>> although that doesn't appear functional). Yes, it's likely that
>> there's a byteswap happening somewhere. In fact the copy engines have
>> parameters somewhere to tell how the swap should be done (basically
>> what the element size is). I don't quite know how to set that though
>> on this generation. I should poke at VRAM via the mmio peephole and
>> see what's actually being stored. Although of course MMIO accesses are
>> also auto-byteswapped. It's all just one big massive headache.
>
> Or it could jus

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

On Sat, Apr 22, 2017 at 9:40 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä
> <ville.syrj...@linux.intel.com> 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ä
>>> <ville.syrj...@linux.intel.com> 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 <kra...@redhat.com> wrote:
>>> >> > While working on graphics support for virtual machines on ppc64 (which
>>> >> > exists in both little and big endian variants) I've figured the 
>>> >> > comments
>>> >> > for various drm fourcc formats in the header file don't match reality.
>>> >> >
>>> >> > Comments says the RGB formats are little endian, but in practice they
>>> >> > are native endian.  Look at the drm_mode_legacy_fb_format() helper.  It
>>> >> > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no 
>>> >> > matter
>>> >> > whenever the machine is little endian or big endian.  The users of this
>>> >> > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer
>>> >> > is native endian, not little endian.  Most userspace also operates on
>>> >> > native endian only.
>>> >> >
>>> >> > So, go update the comments for all 16+24+32 bpp RGB formats.
>>> >> >
>>> >> > Leaving the yuv formats as-is.  I have no idea if and how those are 
>>> >> > used
>>> >> > on bigendian machines.
>>> >>
>>> >> I think this is premature. The current situation is that I can't get
>>> >> modetest to work *at all* on my NV34 / BE setup (I mean, it runs, just
>>> >> the colors displayed are wrong). I believe that currently it packs
>>> >> things in "cpu native endian". I've tried futzing with that without
>>> >> much success, although I didn't spend too much time on it. I have a
>>> >> NV34 plugged into my LE setup as well although I haven't tested to
>>> >> double-check that it all works there. However I'm quite sure it used
>>> >> to, as I used modetest to help develop the YUV overlay support for
>>> >> those GPUs.
>>> >
>>> > I just took a quick stab at fixing modetest to respect the current
>>> > wording in drm_fourcc.h:
>>> >
>>> > git://github.com/vsyrjala/libdrm.git modetest_endian
>>>
>>> Looks like there was some careless testing on my part :( So ... it
>>> looks like the current modetest without those changes does, in fact,
>>> work on NV34/BE. With the changes, it breaks (and the handling of the
>>> b* modes is a little broken in those patches -- they're not selectable
>>> from the cmdline.) Which means that, as Michel & co predicted, it
>>> appears to be taking BE input not LE input. This is very surprising to
>>> me, but it is what it is. As I mentioned before, the details of how
>>> the "BE" mode works on the GPUs is largely unknown to us beyond a few
>>> basics. Note that only XR24 works, AR24 ends up with all black
>>> displayed. This also happens on LE.
>>
>> Did you try 8bpp or 16bpp formats? I expect that if you've just blindly
>> enabled some magic byte swapper in the hardware it will only for
>> a specific pixel size.
>
> Thankfully dispnv04 exposes no such madness - just XR24 (and AR24,
> although that doesn't appear functional). Yes, it's likely that
> there's a byteswap happening somewhere. In fact the copy engines have
> parameters somewhere to tell how the swap should be done (basically
> what the element size is). I don't quite know how to set that though
> on this generation. I should poke at VRAM via the mmio peephole and
> see what's actually being stored. Although of course MMIO accesses are
> also auto-byteswapped. It's all just one big massive headache.

Or it could just be the obvious:

static void nv_crtc_commit(struct drm_crtc *crtc)
{
struct drm_device *dev = crtc->dev;
const struct drm_crtc_helper_funcs *funcs = crtc->helper_private;
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);

nouveau_hw_load_state(dev, nv_crtc->index,
_display(dev)->mode_reg);
nv04_crtc_mode_set_base(crtc, crtc->x, crtc->y, NULL);

#ifdef __BIG_ENDIAN
/* turn on LFB swapping */
{
uint8_t tmp = NVReadVgaCrtc(dev, nv_crtc->index,
NV_CIO_CRE_RCR);
tmp |= MASK(NV_CIO_CRE_RCR_ENDIAN_BIG);
NVWriteVgaCrtc(dev, nv_crtc->index, NV_CIO_CRE_RCR, tmp);
}
#endif

funcs->dpms(crtc, DRM_MODE_DPMS_ON);
drm_crtc_vblank_on(crtc);
}

So presumably instead of that __BIG_ENDIAN thing, it should instead be
if crtc->primary->fb->fourcc & BIG_ENDIAN. (Although that's probably
going to break the universe.) There's also some questionable support
for 16-bit modes in the code, I'm going to see how easy it is to flip
on.

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

On Sat, Apr 22, 2017 at 5:50 AM, Ville Syrjälä
<ville.syrj...@linux.intel.com> 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ä
>> <ville.syrj...@linux.intel.com> 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 <kra...@redhat.com> wrote:
>> >> > While working on graphics support for virtual machines on ppc64 (which
>> >> > exists in both little and big endian variants) I've figured the comments
>> >> > for various drm fourcc formats in the header file don't match reality.
>> >> >
>> >> > Comments says the RGB formats are little endian, but in practice they
>> >> > are native endian.  Look at the drm_mode_legacy_fb_format() helper.  It
>> >> > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter
>> >> > whenever the machine is little endian or big endian.  The users of this
>> >> > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer
>> >> > is native endian, not little endian.  Most userspace also operates on
>> >> > native endian only.
>> >> >
>> >> > So, go update the comments for all 16+24+32 bpp RGB formats.
>> >> >
>> >> > Leaving the yuv formats as-is.  I have no idea if and how those are used
>> >> > on bigendian machines.
>> >>
>> >> I think this is premature. The current situation is that I can't get
>> >> modetest to work *at all* on my NV34 / BE setup (I mean, it runs, just
>> >> the colors displayed are wrong). I believe that currently it packs
>> >> things in "cpu native endian". I've tried futzing with that without
>> >> much success, although I didn't spend too much time on it. I have a
>> >> NV34 plugged into my LE setup as well although I haven't tested to
>> >> double-check that it all works there. However I'm quite sure it used
>> >> to, as I used modetest to help develop the YUV overlay support for
>> >> those GPUs.
>> >
>> > I just took a quick stab at fixing modetest to respect the current
>> > wording in drm_fourcc.h:
>> >
>> > git://github.com/vsyrjala/libdrm.git modetest_endian
>>
>> Looks like there was some careless testing on my part :( So ... it
>> looks like the current modetest without those changes does, in fact,
>> work on NV34/BE. With the changes, it breaks (and the handling of the
>> b* modes is a little broken in those patches -- they're not selectable
>> from the cmdline.) Which means that, as Michel & co predicted, it
>> appears to be taking BE input not LE input. This is very surprising to
>> me, but it is what it is. As I mentioned before, the details of how
>> the "BE" mode works on the GPUs is largely unknown to us beyond a few
>> basics. Note that only XR24 works, AR24 ends up with all black
>> displayed. This also happens on LE.
>
> Did you try 8bpp or 16bpp formats? I expect that if you've just blindly
> enabled some magic byte swapper in the hardware it will only for
> a specific pixel size.

Thankfully dispnv04 exposes no such madness - just XR24 (and AR24,
although that doesn't appear functional). Yes, it's likely that
there's a byteswap happening somewhere. In fact the copy engines have
parameters somewhere to tell how the swap should be done (basically
what the element size is). I don't quite know how to set that though
on this generation. I should poke at VRAM via the mmio peephole and
see what's actually being stored. Although of course MMIO accesses are
also auto-byteswapped. It's all just one big massive headache.

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

On Fri, Apr 21, 2017 at 12:59 PM, Ville Syrjälä
<ville.syrj...@linux.intel.com> 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 <kra...@redhat.com> wrote:
>> > While working on graphics support for virtual machines on ppc64 (which
>> > exists in both little and big endian variants) I've figured the comments
>> > for various drm fourcc formats in the header file don't match reality.
>> >
>> > Comments says the RGB formats are little endian, but in practice they
>> > are native endian.  Look at the drm_mode_legacy_fb_format() helper.  It
>> > maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter
>> > whenever the machine is little endian or big endian.  The users of this
>> > function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer
>> > is native endian, not little endian.  Most userspace also operates on
>> > native endian only.
>> >
>> > So, go update the comments for all 16+24+32 bpp RGB formats.
>> >
>> > Leaving the yuv formats as-is.  I have no idea if and how those are used
>> > on bigendian machines.
>>
>> I think this is premature. The current situation is that I can't get
>> modetest to work *at all* on my NV34 / BE setup (I mean, it runs, just
>> the colors displayed are wrong). I believe that currently it packs
>> things in "cpu native endian". I've tried futzing with that without
>> much success, although I didn't spend too much time on it. I have a
>> NV34 plugged into my LE setup as well although I haven't tested to
>> double-check that it all works there. However I'm quite sure it used
>> to, as I used modetest to help develop the YUV overlay support for
>> those GPUs.
>
> I just took a quick stab at fixing modetest to respect the current
> wording in drm_fourcc.h:
>
> git://github.com/vsyrjala/libdrm.git modetest_endian

Looks like there was some careless testing on my part :( So ... it
looks like the current modetest without those changes does, in fact,
work on NV34/BE. With the changes, it breaks (and the handling of the
b* modes is a little broken in those patches -- they're not selectable
from the cmdline.) Which means that, as Michel & co predicted, it
appears to be taking BE input not LE input. This is very surprising to
me, but it is what it is. As I mentioned before, the details of how
the "BE" mode works on the GPUs is largely unknown to us beyond a few
basics. Note that only XR24 works, AR24 ends up with all black
displayed. This also happens on LE.

Furthermore, all of YUYV, UYVY, and NV12 plane overlays don't appear
to work properly. The first half of the overlay is OK (but I think
compressed), while the second half is gibberish. Testing this on my
board plugged into a LE CPU, I also get the same type of issue, so I'm
guessing that it's just bitrot of the feature. (Or modetest gained a
bug.)

Cheers,

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

On Fri, Apr 21, 2017 at 3:58 AM, Gerd Hoffmann <kra...@redhat.com> wrote:
> While working on graphics support for virtual machines on ppc64 (which
> exists in both little and big endian variants) I've figured the comments
> for various drm fourcc formats in the header file don't match reality.
>
> Comments says the RGB formats are little endian, but in practice they
> are native endian.  Look at the drm_mode_legacy_fb_format() helper.  It
> maps -- for example -- bpp/depth 32/24 to DRM_FORMAT_XRGB, no matter
> whenever the machine is little endian or big endian.  The users of this
> function (fbdev emulation, DRM_IOCTL_MODE_ADDFB) expect the framebuffer
> is native endian, not little endian.  Most userspace also operates on
> native endian only.
>
> So, go update the comments for all 16+24+32 bpp RGB formats.
>
> Leaving the yuv formats as-is.  I have no idea if and how those are used
> on bigendian machines.

I think this is premature. The current situation is that I can't get
modetest to work *at all* on my NV34 / BE setup (I mean, it runs, just
the colors displayed are wrong). I believe that currently it packs
things in "cpu native endian". I've tried futzing with that without
much success, although I didn't spend too much time on it. I have a
NV34 plugged into my LE setup as well although I haven't tested to
double-check that it all works there. However I'm quite sure it used
to, as I used modetest to help develop the YUV overlay support for
those GPUs.

Does modetest work for you, under any interpretation of the formats?

There's an additional complication wrt looking at what fbcon does,
since it will feed the data in via special accel interfaces in fbdev,
which at least on nouveau, may end up byteswapping the data on upload
to VRAM (I'm not 100% clear on whether they do or not). However
modetest, which is creating its own fb, likely won't get such
treatment.

This is a shitty situation - we have hardware we don't know how it
works, tools we don'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 try not to break that.

Cheers,

  -ilia

>
> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Cc: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Pekka Paalanen <ppaala...@gmail.com>
> Cc: Ilia Mirkin <imir...@alum.mit.edu>
> Cc: Michel Dänzer <mic...@daenzer.net>
> Cc: Alex Deucher <alexdeuc...@gmail.com>
> Cc: amd-...@lists.freedesktop.org
> Signed-off-by: Gerd Hoffmann <kra...@redhat.com>
> ---
>  include/uapi/drm/drm_fourcc.h | 82 
> +--
>  1 file changed, 41 insertions(+), 41 deletions(-)
>
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 995c8f9..1579765 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -42,68 +42,68 @@ extern "C" {
>  #define DRM_FORMAT_R8  fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
>
>  /* 16 bpp Red */
> -#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R 
> little endian */
> +#define DRM_FORMAT_R16 fourcc_code('R', '1', '6', ' ') /* [15:0] R 
> native endian */
>
>  /* 16 bpp RG */
> -#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /* 
> [15:0] R:G 8:8 little endian */
> -#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /* 
> [15:0] G:R 8:8 little endian */
> +#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /* 
> [15:0] R:G 8:8 native endian */
> +#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /* 
> [15:0] G:R 8:8 native endian */
>
>  /* 32 bpp RG */
> -#define DRM_FORMAT_RG1616  fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 
> 16:16 little endian */
> -#define DRM_FORMAT_GR1616  fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
> 16:16 little endian */
> +#define DRM_FORMAT_RG1616  fourcc_code('R', 'G', '3', '2') /* [31:0] R:G 
> 16:16 native endian */
> +#define DRM_FORMAT_GR1616  fourcc_code('G', 'R', '3', '2') /* [31:0] G:R 
> 16:16 native endian */
>
>  /* 8 bpp RGB */
>  #define DRM_FORMAT_RGB332  fourcc_code('R', 'G', 'B', '8') /* [7:0] 
> R:G:B 3:3:2 */
>  #define DRM_FORMAT_BGR233  fourcc_code('B', 'G', 'R', '8') /* [7:0] 
> B:G:R 2:3:3 */
>
>  /* 16 bpp RGB */
> -#define DRM_FORMAT_XRGBfourcc_code('X', 'R', '1', '2') /* [15:0] 
> x:R:G:B 4:4:4:4 little endian */
> -#define DRM_FORMAT_XBGRfourcc_code('X', 'B', '1', '2') /* [15:0] 
> x:B:G:R 4:4:4:4 little endian 

Re: [PATCH v2 4/5] nouveau_hwmon: Add support for auto_point attributes

[Ilia Mirkin]

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 hwmon_device_register_with_info.
> ---
>  drivers/gpu/drm/nouveau/nouveau_hwmon.c | 29 -
>  1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c 
> b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> index 538bf67..655ae11 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> @@ -359,6 +359,23 @@ nouveau_hwmon_get_power1_crit(struct nouveau_drm *drm)
> return iccsense->power_w_crit;
>  }
>
> +static struct attribute *pwm_fan_sensor_attrs[] = {

static const struct. Below as well.

> +   _dev_attr_pwm1_min.dev_attr.attr,
> +   _dev_attr_pwm1_max.dev_attr.attr,
> +   NULL
> +};
> +ATTRIBUTE_GROUPS(pwm_fan_sensor);
> +
> +static struct attribute *temp1_auto_point_sensor_attrs[] = {
> +   _dev_attr_temp1_auto_point1_pwm.dev_attr.attr,
> +   _dev_attr_temp1_auto_point1_temp.dev_attr.attr,
> +   _dev_attr_temp1_auto_point1_temp_hyst.dev_attr.attr,
> +   NULL
> +};
> +ATTRIBUTE_GROUPS(temp1_auto_point_sensor);
> +
> +#define N_ATTR_GROUPS   3
> +
>  static const u32 nouveau_config_chip[] = {
> HWMON_C_UPDATE_INTERVAL,
> 0
> @@ -789,17 +806,27 @@ nouveau_hwmon_init(struct drm_device *dev)
>  #if defined(CONFIG_HWMON) || (defined(MODULE) && 
> defined(CONFIG_HWMON_MODULE))
> struct nouveau_drm *drm = nouveau_drm(dev);
> struct nvkm_therm *therm = nvxx_therm(>client.device);
> +   const struct attribute_group *special_groups[N_ATTR_GROUPS];
> struct nouveau_hwmon *hwmon;
> struct device *hwmon_dev;
> int ret = 0;
> +   int i = 0;
>
> hwmon = drm->hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
> if (!hwmon)
> return -ENOMEM;
> hwmon->dev = dev;
>
> +   if (therm && therm->attr_get && therm->attr_set) {
> +   if (nvkm_therm_temp_get(therm) >= 0)
> +   special_groups[i++] = _auto_point_sensor_group;
> +   if (therm->fan_get && therm->fan_get(therm) >= 0)
> +   special_groups[i++] = _fan_sensor_group;
> +   }
> +
> +   special_groups[i] = 0;
> hwmon_dev = hwmon_device_register_with_info(dev->dev, "nouveau", dev,
> -   _chip_info, NULL);
> +   _chip_info, special_groups);
> if (IS_ERR(hwmon_dev)) {
> ret = PTR_ERR(hwmon_dev);
> NV_ERROR(drm, "Unable to register hwmon device: %d\n", ret);
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH v2 2/5] nouveau_hwmon: Add nouveau_hwmon_ops structure with .is_visible/.read_string

[Ilia Mirkin]

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 mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH v2 1/5] nouveau_hwmon: Add config for all sensors and their settings

[Ilia Mirkin]

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 the sensors with
> their possible configurable settings and then fills the struct 
> hwmon_channel_info
> with all this information.
> ---
>  drivers/gpu/drm/nouveau/nouveau_hwmon.c | 72 
> +
>  1 file changed, 72 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_hwmon.c 
> b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> index 23b1670..24b40c5 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_hwmon.c
> @@ -692,6 +692,78 @@ static const struct attribute_group 
> hwmon_power_attrgroup = {
>  static const struct attribute_group hwmon_power_caps_attrgroup = {
> .attrs = hwmon_power_caps_attributes,
>  };
> +
> +static const u32 nouveau_config_chip[] = {
> +   HWMON_C_UPDATE_INTERVAL,
> +   0
> +};
> +
> +static const u32 nouveau_config_in[] = {
> +   HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX | HWMON_I_LABEL,
> +   0
> +};
> +
> +static const u32 nouveau_config_temp[] = {
> +   HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
> +   HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_EMERGENCY |
> +   HWMON_T_EMERGENCY_HYST,
> +   0
> +};
> +
> +static const u32 nouveau_config_fan[] = {
> +   HWMON_F_INPUT,
> +   0
> +};
> +
> +static const u32 nouveau_config_pwm[] = {
> +   HWMON_PWM_INPUT | HWMON_PWM_ENABLE,
> +   0
> +};
> +
> +static const u32 nouveau_config_power[] = {
> +   HWMON_P_INPUT | HWMON_P_CAP_MAX | HWMON_P_CRIT,
> +   0
> +};
> +
> +static const struct hwmon_channel_info nouveau_chip = {
> +   .type = hwmon_chip,
> +   .config = nouveau_config_chip,
> +};
> +
> +static const struct hwmon_channel_info nouveau_temp = {
> +   .type = hwmon_temp,
> +   .config = nouveau_config_temp,
> +};
> +
> +static const struct hwmon_channel_info nouveau_fan = {
> +   .type = hwmon_fan,
> +   .config = nouveau_config_fan,
> +};
> +
> +static const struct hwmon_channel_info nouveau_in = {
> +   .type = hwmon_in,
> +   .config = nouveau_config_in,
> +};
> +
> +static const struct hwmon_channel_info nouveau_pwm = {
> +   .type = hwmon_pwm,
> +   .config = nouveau_config_pwm,
> +};
> +
> +static const struct hwmon_channel_info nouveau_power = {
> +   .type = hwmon_power,
> +   .config = nouveau_config_power,
> +};
> +
> +static const struct hwmon_channel_info *nouveau_info[] = {
> +   _chip,
> +   _temp,
> +   _fan,
> +   _in,
> +   _pwm,
> +   _power,
> +   NULL
> +};
>  #endif
>
>  int
> --
> 2.1.4
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

On Tue, Apr 18, 2017 at 11:19 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> On Tue, Apr 18, 2017 at 9:01 PM, Michel Dänzer <mic...@daenzer.net> 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. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses
>>>> native endian packed colour values.
>>>
>>> Same is true for DRM_IOCTL_MODE_ADDFB, with depth/bpp 24/32 you'll get
>>> DRM_FORMAT_XRGB (only DRM_IOCTL_MODE_ADDFB2 allows userspace specify
>>> fourcc formats directly).
>>
>> Right, and since all major Xorg drivers use DRM_IOCTL_MODE_ADDFB,
>> they're effectively using DRM_FORMAT_XRGB as native endianness as well.
>
> In the meanwhile, it has been pointed out to me that pre-nv50 display
> code actually doesn't use DRM_FORMAT_* at all -- it uses some helpers
> which end up advertising XR24 / AR24. However from what I can tell,
> that's not a well-reasoned selection. Either way, I'm going to test
> Gerd's patch, hopefully during the week, or weekend at the latest. My
> current suspicion is that it will have no effect on nouveau either
> way. We'll find out.

(And as Michel points out, the patch doesn't actually touch anything,
just comments. I originally thought it changed format -> fourcc
mapping.)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

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. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses
>>> native endian packed colour values.
>>
>> Same is true for DRM_IOCTL_MODE_ADDFB, with depth/bpp 24/32 you'll get
>> DRM_FORMAT_XRGB (only DRM_IOCTL_MODE_ADDFB2 allows userspace specify
>> fourcc formats directly).
>
> Right, and since all major Xorg drivers use DRM_IOCTL_MODE_ADDFB,
> they're effectively using DRM_FORMAT_XRGB as native endianness as well.

In the meanwhile, it has been pointed out to me that pre-nv50 display
code actually doesn't use DRM_FORMAT_* at all -- it uses some helpers
which end up advertising XR24 / AR24. However from what I can tell,
that's not a well-reasoned selection. Either way, I'm going to test
Gerd's patch, hopefully during the week, or weekend at the latest. My
current suspicion is that it will have no effect on nouveau either
way. We'll find out.

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH libdrm] modetest: fix printing of fourcc on BE machines

[Ilia Mirkin]

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 <imir...@alum.mit.edu>
---
 tests/modetest/modetest.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index c390d87..b8891ff 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -174,6 +174,15 @@ static const char *mode_flag_names[] = {
 
 static bit_name_fn(mode_flag)
 
+static void dump_fourcc(uint32_t fourcc)
+{
+   printf(" %c%c%c%c",
+   fourcc,
+   fourcc >> 8,
+   fourcc >> 16,
+   fourcc >> 24);
+}
+
 static void dump_encoders(struct device *dev)
 {
drmModeEncoder *encoder;
@@ -443,7 +452,7 @@ static void dump_planes(struct device *dev)
 
printf("  formats:");
for (j = 0; j < ovr->count_formats; j++)
-   printf(" %4.4s", (char *)>formats[j]);
+   dump_fourcc(ovr->formats[j]);
printf("\n");
 
if (plane->props) {
-- 
2.10.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

On Mon, Apr 17, 2017 at 10:53 PM, Michel Dänzer <mic...@daenzer.net> wrote:
> On 17/04/17 03:43 PM, Ilia Mirkin wrote:
>> On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin <imir...@alum.mit.edu> 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 fine
>>> on top of kernel 4.3 on an AGP GeForce FX 5200 (with AGPGART turned
>>> off because ... well ... uninorth). fbcon/fbdev accel worked,
>>> xf86-video-nouveau's 2d accel worked, and simple demos (ala glxgears)
>>> worked after I fixed up mesa and nv30 driver items in version ... 11.1
>>> it seems. As I recall it had gotten all broken in 10.0 or so by Adam
>>> Jackson in the name of making llvmpipe work on BE, declaring all other
>>> drivers broken, with various fixes by Michel Dänzer to get it back to
>>> working over the years.
>>>
>>> Anyone "fixing" the stack has to maintain that level of functioning
>>> through their various fixing.
>>>
>>> I will double-check that the above still works with the latest
>>> kernel/xorg/xf86-video-nouveau/mesa and report back (hopefully by this
>>> weekend). If there are any patches you'd like me to test, now's the
>>> time to ask -- getting the box up and running is the hard part,
>>> booting up an extra kernel -- easy.
>>
>> OK, so I revived my PowerMac7,3 G5 setup (PPC64 BE, NV34 GPU). Booted
>> it with an upstream 4.11-rc7 kernel, loaded up the nouveau kernel
>> module (which is included in that kernel), updated X to 1.19.2 and
>> mesa to 17.0.3. Everything works fine. Specifically:
>>
>> fbcon on top of fbdev provided by nouveau -- colors are fine
>> glxgears hw-accelerated by mesa on top of xf86-video-nouveau using
>> DRI2 -- colors are fine
>> glxgears softpipe-accelerated by mesa on top of xf86-video-nouveau --
>> colors are fine
>> glxgears softpipe-accelerated by mesa on top of xf86-video-modesetting
>> -- colors are fine
>> xterm on top of xf86-video-nouveau -- colors are fine
>> xterm on top of xf86-video-modesetting -- colors are fine
>>
>> I couldn't test anything with GLAMOR since GLAMOR requires GL 2.1 or
>> higher, whereas nouveau's NV3x acceleration only provides GL 1.5 (due
>> to lacking NPOT and a handful of other things).
>>
>> The modetest utility did have trouble with AR24 and I'm pretty sure
>> the XR24 pattern was off too. However I wouldn't be surprised if the
>> modetest utility itself had endian issues in the pattern generation
>> logic. (Seems to be the case, based on a quick glance at the
>> tests/util/format.c logic and how it's used in pattern.c.)
>>
>> So in short, I think the current definitions of format are fine.
>
> I agree with Pekka that it's not that simple. What you've established is
> that things look fine after going through several layers of abstraction.
> It's possible that multiple bugs in those layers cancel each other out;
> in particular, it's quite likely that the code dealing with DRM formats
> is treating them as using native endianness (one possible giveaway for
> that is using shifts for (un)packing colour components).

Quite true that this proves nothing. However one should note that
fbcon -> fbdev works, and both mesa hw driver and softpipe driver
work, in addition to regular DDX accel. Which means that the bugs, if
they exist, are pretty consistent amongst each other, spanning
multiple layers, all agreeing as to what the proper bugginess is. One
could go so far as to declare it to be a feature.

It does show is that things generally work today in at least some, if
not many, setups, and one can't go around breaking them willy nilly.

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

On Tue, Apr 11, 2017 at 10:18 AM, Ilia Mirkin <imir...@alum.mit.edu> 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 fine
> on top of kernel 4.3 on an AGP GeForce FX 5200 (with AGPGART turned
> off because ... well ... uninorth). fbcon/fbdev accel worked,
> xf86-video-nouveau's 2d accel worked, and simple demos (ala glxgears)
> worked after I fixed up mesa and nv30 driver items in version ... 11.1
> it seems. As I recall it had gotten all broken in 10.0 or so by Adam
> Jackson in the name of making llvmpipe work on BE, declaring all other
> drivers broken, with various fixes by Michel Dänzer to get it back to
> working over the years.
>
> Anyone "fixing" the stack has to maintain that level of functioning
> through their various fixing.
>
> I will double-check that the above still works with the latest
> kernel/xorg/xf86-video-nouveau/mesa and report back (hopefully by this
> weekend). If there are any patches you'd like me to test, now's the
> time to ask -- getting the box up and running is the hard part,
> booting up an extra kernel -- easy.

OK, so I revived my PowerMac7,3 G5 setup (PPC64 BE, NV34 GPU). Booted
it with an upstream 4.11-rc7 kernel, loaded up the nouveau kernel
module (which is included in that kernel), updated X to 1.19.2 and
mesa to 17.0.3. Everything works fine. Specifically:

fbcon on top of fbdev provided by nouveau -- colors are fine
glxgears hw-accelerated by mesa on top of xf86-video-nouveau using
DRI2 -- colors are fine
glxgears softpipe-accelerated by mesa on top of xf86-video-nouveau --
colors are fine
glxgears softpipe-accelerated by mesa on top of xf86-video-modesetting
-- colors are fine
xterm on top of xf86-video-nouveau -- colors are fine
xterm on top of xf86-video-modesetting -- colors are fine

I couldn't test anything with GLAMOR since GLAMOR requires GL 2.1 or
higher, whereas nouveau's NV3x acceleration only provides GL 1.5 (due
to lacking NPOT and a handful of other things).

The modetest utility did have trouble with AR24 and I'm pretty sure
the XR24 pattern was off too. However I wouldn't be surprised if the
modetest utility itself had endian issues in the pattern generation
logic. (Seems to be the case, based on a quick glance at the
tests/util/format.c logic and how it's used in pattern.c.)

So in short, I think the current definitions of format are fine.

Cheers,

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: KMS question

[Ilia Mirkin]

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 the KMS drivers
 that enables all outputs at once?

 It is very annoying that on a POS machine with an
 1024x768 LVDS and a 800x480 secondary monitor (both built-in)
 the KMS driver wakes up both. Then the framebuffer console
 and plymouth use both screens, making the primary output
 very odd with only the top-left part used by the boot splash.

 I would like the boot splash to be shown only on the primary
 output at its full resolution instead of on all outputs using
 the smallest common rectangle.

 Is there a kernel command line configuration that achieves this?

 The device in question uses the gma500 kernel driver but the same
 behaviour is observed with the i915 and radeon drivers.

>>>
>>> The problem is fbdev is not multi-head aware.  The fbdev emulation in
>>> the KMS drivers attempts to light up all monitors so that something
>>> shows up on all heads.  If you really want different per head
>>> configurations, you need to use the KMS API directly.  As a
>>> workaround, you can use the kernel command line to disable the output
>>> you don't want to be lit up.  See:
>>> https://wiki.archlinux.org/index.php/kernel_mode_setting
>>> for more info.  basically add video=TV-1:d to disable the output in
>>> question.  Replace TV-1 with whatever connector you want to disable.
>>
>>
>> I tried adding video=DVI-D-1:d to the kernel command line.
>>
>> The effect is while the second output is indeed disabled, the
>> framebuffer console still takes the second output's resolution
>> into account and the boot splash is still using only the top-left
>> 800x480 part of the 1024x768 primary screen.
>>
>> Also, the secondary screen got disabled also in X which is not desired.
>> Can I wake it up under X somehow? This device is using the modesetting
>> DDX driver.
>
> Can you enable it via randr?

I think the video= based disable forces the connector to be disabled
irrevocably.

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH v3 10/10] drm/nouveau: Enable stereoscopic 3D output over HDMI

[Ilia Mirkin]

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 for setting the Vendor
> InfoFrame.
>
> With this, I get an obvious 3D output when using the "testdisplay"
> program from intel-gpu-tools with the "-3" parameter and outputting
> to a 3D-capable HDMI display, for all available 3D modes (be they
> TB, SBSH, or FP) on all four G80+ DISPs.
>
> Signed-off-by: Alastair Bridgewater 
> ---
>  drivers/gpu/drm/nouveau/nouveau_connector.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index 9a91e79..ff188c7 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
> @@ -1324,6 +1324,13 @@ nouveau_connector_create(struct drm_device *dev, int 
> index)
> break;
> }
>
> +   /* HDMI 3D support */
> +   if ((disp->disp.oclass >= NV50_DISP)

You probably meant G82_DISP. Although I don't know if there were any
G80's with DP or HDMI. Either way, all that logic is in hdmig84.c (and
newer), so ... :)

> +   && ((type == DRM_MODE_CONNECTOR_DisplayPort)
> +   || (type == DRM_MODE_CONNECTOR_eDP)
> +   || (type == DRM_MODE_CONNECTOR_HDMIA)))
> +   connector->stereo_allowed = true;
> +
> /* defaults, will get overridden in detect() */
> connector->interlace_allowed = false;
> connector->doublescan_allowed = false;
> --
> 2.10.2
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

On Tue, Apr 11, 2017 at 3:31 AM, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Mon, 10 Apr 2017 12:10:14 -0400
> Ilia Mirkin <imir...@alum.mit.edu> wrote:
>
>> On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen <ppaala...@gmail.com> wrote:
>
>> > I also wonder if a real BE machine could have different results than
>> > the virtual machine.
>>
>> I have a PPC G5 with an AGP GeForce FX 5200 that I can test things on,
>> if necessary. (I got it specifically for this purpose, as the people
>> who use this type of hw daily tend to perform updates rarely... in no
>> small part due to the fact that updates tend to break the HW.)
>>
>> Just let know what you need tested, I should be able to turn it around
>> within a couple of days.
>
> That's part of my problem. I don't really know what should be tested.
> What do people do with their BE machines that we should avoid breaking?
>
> I suppose correlating with what Gerd was testing would be nice, i.e.
> does X.org with modesetting look right with and without GLAMOR? Maybe
> you also want to throw in xf86-video-nouveau for comparison.

GLAMOR? That's funny. No way that works. Pretty sure it doesn't work
on nv30/nv40 GPUs on LE boxes (at least I get bugs about it). I've
gotten mesa to the point where simple demos work again (after it got
"fixed" for BE, thus breaking all previously working setups). However
there's too much confusion in my head about how to store buffer data,
and precisely what the "BE" mode on the GPUs does for anything complex
to work.

> As to what apps to test those with... Gerd? I presume anything that does
> *not* use OpenGL, since we have doubts of Mesa's correctness on BE,
> right? So maybe some of the traditional ancient X11 apps? xterm with
> colours?

Mesa's fine on BE again, at least the nv30 driver. I had to do some
slightly dubious things to get it to that state, but it does function
mostly properly (as long as you don't try to use VBOs ... or index
buffers ... something ends up getting byteswapped one too many times,
however that's a wholly nv30-private issue).

> 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 fine
on top of kernel 4.3 on an AGP GeForce FX 5200 (with AGPGART turned
off because ... well ... uninorth). fbcon/fbdev accel worked,
xf86-video-nouveau's 2d accel worked, and simple demos (ala glxgears)
worked after I fixed up mesa and nv30 driver items in version ... 11.1
it seems. As I recall it had gotten all broken in 10.0 or so by Adam
Jackson in the name of making llvmpipe work on BE, declaring all other
drivers broken, with various fixes by Michel Dänzer to get it back to
working over the years.

Anyone "fixing" the stack has to maintain that level of functioning
through their various fixing.

I will double-check that the above still works with the latest
kernel/xorg/xf86-video-nouveau/mesa and report back (hopefully by this
weekend). If there are any patches you'd like me to test, now's the
time to ask -- getting the box up and running is the hard part,
booting up an extra kernel -- easy.

Cheers,

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

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 modesetting driver uses DRM_FORMAT_XRGB (one and
>> only format supported by bochs-drm), and we have to interpret that in
>> bigendian byte order on the host side to get a correct display.
>
> I wonder if that is just an oversight from trying to match OpenGL
> formats to DRM formats. It's full of gotcha's.
>
> Did you try with GLAMOR? Do you see a difference with and without
> GLAMOR? Hmm, but you have no GPU support, so GLAMOR would be through a
> Mesa software renderer? I think I heard someone say something about
> Mesa software on BE...
>
> But even if this actually is a valid example of software we must keep
> working as is, well, ouch. But if I cannot show that your fix breaks
> anything, then I suppose you win. Your proposal would certainly solve
> the dilemma we have with wl_shm formats in Wayland.
>
> I also wonder if a real BE machine could have different results than
> the virtual machine.

I have a PPC G5 with an AGP GeForce FX 5200 that I can test things on,
if necessary. (I got it specifically for this purpose, as the people
who use this type of hw daily tend to perform updates rarely... in no
small part due to the fact that updates tend to break the HW.)

Just let know what you need tested, I should be able to turn it around
within a couple of days.

Cheers,

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

[Ilia Mirkin]

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 supported by bochs-drm), and we have to interpret that in
> bigendian byte order on the host side to get a correct display.
>
> Didn't try wayland.  Can do, but will take a while.  Don't have a
> wayland-capable guest install at hand, and installing one takes a while
> because I don't have a physical pseries and emulation is slww.
>
>> To solve that problem, we would like to know if anything existing would
>> break for each possible solution, but no developers using BE have really
>> turned up.
>
> That is part of the problem.
> And even ppc is moving to little endian these days ...

The poor saps who are still using PPC G4's and G5's with NVIDIA and
ATI boards constantly get their working setups broken by people trying
to "fix" BE. I think it's important to keep them in mind, and test
those setups, whenever one tries to make a large sweeping change.

Cheers,

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH v2 00/10] Enable HDMI Stereoscopy

[Ilia Mirkin]

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+ hardware.  HDMI connectors because obvious.  DPort
>> > connectors because of DPort to HDMI adaptors.
>>
>> Do you mean DP++ or actual protocol converters? DP++ is just HDMI with
>> a some electrical tweaks, but IIRC proper DP defines 3D stereo quite
>> differently than HDMI. I'm not sure if we should be able to push HDMI
>> style 3D through DP->HDMI/DP++ adaptors. The specs are unfortunately
>> very vague when it comes to such devices.
>
> DP++. Good point about the protocol converters, though I don't recall
> seeing any way to distinguish between a DP and a DP++ connector in
> nouveau, nor do I know if nVidia actually made any boards with DP that
> isn't DP++. I guess I have some digging to do in that direction. Thank
> you.

I wouldn't be surprised if the externally-encodered G200 DP connectors
didn't support DP++. I do think that the vast majority of DP ports are
actually DP++ (on NVIDIA, and probably everywhere). However since this
is (edge case)^2 [G200 DP, 3D DP], I wouldn't spend too much time
worrying about it. I doubt it's documented anywhere, and equally
doubtful any such sinks exist. Should be able to find a VBIOS with the
external DP encoders though, and you can check the DCB specs that
NVIDIA published at
ftp://download.nvidia.com/open-gpu-doc/DCB/2/DCB-4.x-Specification.html.
(Looks like there is something there under "DFP Specific Information"
-> HDMI, not 100% sure where in nouveau it's decoded though.)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one

[Ilia Mirkin]

On Sun, Mar 26, 2017 at 6:14 PM, Ben Skeggs <skeg...@gmail.com> 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. As a result, it appears that the MMU is also
>> non-functional. For AGP cards, the vast majority of the NV4A lineup,
>> this worked out since we force AGP cards to use the nv04 mmu. However
>> for PCI variants, this did not work.
>>
>> Switching to the NV04 MMU makes it work like a charm. Thanks to mwk for
>> the suggestion. This should be a no-op for NV4A AGP boards, as they were
>> using it already.
>
> This is probably fine for NV4A in that case (more below).
>
>>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388
>> Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
>> 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 works
>> for them, however such boards are rare, and I don't have one. Perhaps all
>> PCI boards should be routed to the nv04 mmu, not just the NV4A ones.
>
> I wonder if it wouldn't be useful to also change the checks in nv41/nv44
> implementations to be "if (device->type != NVKM_DEVICE_PCIE ..." too?

So ... mwk and I were talking about it, and we weren't sure. Were
there non-NV4A, non-IGP PCI boards? And if so, if it's a PCIE <-> PCI
thing that translates the bus transactions, the GPU-side MMU should
still be there, no? (Is there anything PCIE-specific going on?) In
case you can't tell, I'm well past the edge of my understanding of how
all this works...

Perhaps you could check if you have such a board, or if they're purely
mythical? If such boards do exist, see what happens when you plug it
in and boot nouveau with it. My issues with NV4A were immediate - the
fifo basically didn't initialize. If the boards are mythical, then we
can just change nv44/nv41 to check for != PCIE.

Cheers,

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Ilia Mirkin]

On Thu, Mar 23, 2017 at 11:22 AM, Sharma, Shashank
<shashank.sha...@intel.com> wrote:
> On 3/23/2017 5:17 PM, Ilia Mirkin wrote:
>>
>> On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma
>> <shashank.sha...@intel.com> 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-107).
>>>
>>> This patch adds a bool input variable, which indicates if the connected
>>> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
>>> HDMI 2.0 VIC to a HDMI 1.4 sink.
>>
>> Should this patch come before the patch which recognizes VICs 65+?
>> Otherwise if only the first patch is applied but not this one, you
>> could end up with the bad scenario. (As can happen in bisections, for
>> example.)
>
> I kindof agree, this could be the case, but also, for the correct
> functionality, you should have the whole series
> together.

OK, so ... I have a bug in my filesystem, and I'm bisecting it and
rebooting my box at each step. I happen to hit this commit in my
bisect and my monitor doesn't turn on? Seems unpleasant, no?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

[Ilia Mirkin]

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-107).
>
> This patch adds a bool input variable, which indicates if the connected
> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
> HDMI 2.0 VIC to a HDMI 1.4 sink.

Should this patch come before the patch which recognizes VICs 65+?
Otherwise if only the first patch is applied but not this one, you
could end up with the bad scenario. (As can happen in bisections, for
example.)

>
> This patch touches all drm drivers, who are callers of this function
> drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
> no change in current behavior, is_hdmi2 is kept as false.
>
> In case of I915 driver, this patch checks the connector->display_info
> to check if the connected display is HDMI 2.0.
>
> Cc: Ville Syrjala 
> Cc: Jose Abreu 
> Cc: Andrzej Hajda 
> Cc: Alex Deucher 
> Cc: Daniel Vetter 
>
> PS: This patch touches a few lines in few files, which were
> already above 80 char, so checkpatch gives 80 char warning again.
> - gpu/drm/omapdrm/omap_encoder.c
> - gpu/drm/i915/intel_sdvo.c
>
> Signed-off-by: Shashank Sharma 
> ---
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 +-
>  drivers/gpu/drm/bridge/analogix-anx78xx.c |  3 ++-
>  drivers/gpu/drm/bridge/sii902x.c  |  2 +-
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c |  2 +-
>  drivers/gpu/drm/drm_edid.c| 12 +++-
>  drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 +-
>  drivers/gpu/drm/i2c/tda998x_drv.c |  2 +-
>  drivers/gpu/drm/i915/intel_hdmi.c |  5 -
>  drivers/gpu/drm/i915/intel_sdvo.c |  3 ++-
>  drivers/gpu/drm/mediatek/mtk_hdmi.c   |  2 +-
>  drivers/gpu/drm/omapdrm/omap_encoder.c|  3 ++-
>  drivers/gpu/drm/radeon/radeon_audio.c |  2 +-
>  drivers/gpu/drm/rockchip/inno_hdmi.c  |  2 +-
>  drivers/gpu/drm/sti/sti_hdmi.c|  2 +-
>  drivers/gpu/drm/tegra/hdmi.c  |  2 +-
>  drivers/gpu/drm/tegra/sor.c   |  2 +-
>  drivers/gpu/drm/vc4/vc4_hdmi.c|  2 +-
>  drivers/gpu/drm/zte/zx_hdmi.c |  2 +-
>  include/drm/drm_edid.h|  3 ++-
>  21 files changed, 38 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index d4452d8..ab7a399 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -1877,7 +1877,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder 
> *encoder,
> dce_v10_0_audio_write_sad_regs(encoder);
> dce_v10_0_audio_write_latency_fields(encoder, mode);
>
> -   err = drm_hdmi_avi_infoframe_from_display_mode(, mode);
> +   err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index 5b24e89..3c5fd83 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -1861,7 +1861,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder 
> *encoder,
> dce_v11_0_audio_write_sad_regs(encoder);
> dce_v11_0_audio_write_latency_fields(encoder, mode);
>
> -   err = drm_hdmi_avi_infoframe_from_display_mode(, mode);
> +   err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index d2590d7..c564dca 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -1760,7 +1760,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder 
> *encoder,
> dce_v8_0_audio_write_sad_regs(encoder);
> dce_v8_0_audio_write_latency_fields(encoder, mode);
>
> -   err = drm_hdmi_avi_infoframe_from_display_mode(, mode);
> +   err = drm_hdmi_avi_infoframe_from_display_mode(, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c 
> b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> index a2a8236..f9b77b8 100644
> --- 

Re: [RFC libdrm 0/2] Replace the build system with meson

[Ilia Mirkin]

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
with a sane build system.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau/mpeg: mthd returns true on success now

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
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 +-
 drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv44.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv31.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv31.c
index 003ac91..8a88952 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv31.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv31.c
@@ -198,7 +198,7 @@ nv31_mpeg_intr(struct nvkm_engine *engine)
}
 
if (type == 0x0010) {
-   if (!nv31_mpeg_mthd(mpeg, mthd, data))
+   if (nv31_mpeg_mthd(mpeg, mthd, data))
show &= ~0x0100;
}
}
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv44.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv44.c
index e536f37..c3cf02e 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv44.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/mpeg/nv44.c
@@ -172,7 +172,7 @@ nv44_mpeg_intr(struct nvkm_engine *engine)
}
 
if (type == 0x0010) {
-   if (!nv44_mpeg_mthd(subdev->device, mthd, data))
+   if (nv44_mpeg_mthd(subdev->device, mthd, data))
show &= ~0x0100;
}
}
-- 
2.10.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one

[Ilia Mirkin]

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. As a result, it appears that the MMU is also
non-functional. For AGP cards, the vast majority of the NV4A lineup,
this worked out since we force AGP cards to use the nv04 mmu. However
for PCI variants, this did not work.

Switching to the NV04 MMU makes it work like a charm. Thanks to mwk for
the suggestion. This should be a no-op for NV4A AGP boards, as they were
using it already.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70388
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
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 works
for them, however such boards are rare, and I don't have one. Perhaps all
PCI boards should be routed to the nv04 mmu, not just the NV4A ones.

 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index 273562d..0fc41db 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -714,7 +714,7 @@ nv4a_chipset = {
.i2c = nv04_i2c_new,
.imem = nv40_instmem_new,
.mc = nv44_mc_new,
-   .mmu = nv44_mmu_new,
+   .mmu = nv04_mmu_new,
.pci = nv40_pci_new,
.therm = nv40_therm_new,
.timer = nv41_timer_new,
-- 
2.10.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC libdrm 0/2] Replace the build system with meson

[Ilia Mirkin]

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 a
> non-recursive view for the system. This is the best of both worlds,
> humans can organize the build system in a way that makes sense, and the
> machine gets a non-recursive build system. It also uses ninja rather
> than make, and ninja is faster than make inherently. Meson is also a
> simpler syntax than autotools or cmake it's not Turing Complete by
> design nor does it expose python, again, by design. This allows meson
> itself to be reimplemented in a another language if python becomes a
> dead-end or a bottle-neck. It also makes it much easier to understand
> what the build system is doing.
>
> What's different about using meson?
>
> Well, apart from a faster builds and less magic in the build system? The
> configure flags are different, it uses -D= more like cmake
> than the --enable or --with flags of autotools, although oddly it uses
> --prefix and friends when calling meson, but not with mesonconf, there's
> a bug opened on this. Meson also doesn't support in-tree builds at all;
> all builds are done out of tree. It also doesn't provide a "make dist"
> target, fortunately there's this awesome tool called git, and it
> provides a "git archive" command that does much the same thing. Did I
> mention it's fast?
>
> Here are the performance numbers I see on a 2 core 4 thread SKL, without
> initial configuration, and building out of tree (using zsh):
>
> For meson the command line is:
> time (meson build -Dmanpages=true && ninja -C build)
>
> For autotools the command line is:
> time (mdkir build && cd build && ../autotools && make -j5 -l4)

Probably mkdir...

>
> meson (cold ccache): 13.37s user 1.74s system 255% cpu  5.907 total
> autotools (cold ccache): 26.50s user 1.71s system 129% cpu 21.835 total
> meson (hot ccache):   2.13s user 0.39s system 154% cpu  1.633 total
> autotools (hot ccache):  13.93s user 0.73s system 102% cpu 14.259 total
>
> That's ~4x faster for a cold build and ~10x faster for a hot build.
>
> For a make clean && make style build with a hot cache:
> meson: 4.64s user 0.33s system 334% cpu 1.486 total
> autotools: 7.93s user 0.32s system 167% cpu 4.920 total
>
> Why bother with libdrm?
>
> It's a simple build system, that could be completely (or mostly
> completely) be ported in a very short time, and could serve as a tech
> demo for the advantages of using meson to garner feedback for embarking
> on a larger project, like mesa (which is what I'm planning to work on
> next).
>
> tl;dr
>
> I wrote this as practice for porting Mesa, and figured I might as well
> send it out since I wrote it.
>
> It is very likely that neither of these large patches will show up on the
> mailing list, but this is available at my github:
> https://github.com/dcbaker/libdrm wip/meson

I haven't looked at meson or your patches in detail, but autotools
supports 2 very important use-cases very well:

1. ./configure --help
2. Cross-compilation with minimal requirement from the project being built

Can you comment on how these are handled in meson?

Cheers,

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: nouveau preventing shutdown after suspend-resume

[Ilia Mirkin]

On Fri, Feb 17, 2017 at 11:22 AM, João Paulo Rechi Vita
<jprv...@gmail.com> wrote:
> Hello Ilia,
>
> On 17 February 2017 at 11:14, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>> On Fri, Feb 17, 2017 at 10:54 AM, João Paulo Rechi Vita
>> <jprv...@gmail.com> 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 that
>> you're using a 4.8 kernel. Do issues persist with a 4.10 kernel? I'm
>> thinking of upstream commit cae9ff036ee, but it's likely that there
>> have also been others I'm not thinking of.
>>
>
> Yes, although the logs I have pasted were indeed collected using a 4.8
> kernel, the problem persists with a recent Linus' tree (v4.10-rc8 + a
> couple of commits) which contains cae9ff036ee.

You should file a bug with all the relevant info. BTW, odd that the
device is reported as 179c. 1780-17bf isn't allocated to anything.
There *is* a 139c device, "GM107M [GeForce 940M]", but that would
imply there's an extra 0x0400 bit set.

Cheers,

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: nouveau preventing shutdown after suspend-resume

[Ilia Mirkin]

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 that
you're using a 4.8 kernel. Do issues persist with a 4.10 kernel? I'm
thinking of upstream commit cae9ff036ee, but it's likely that there
have also been others I'm not thinking of.

Cheers,

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau/core: recognise GP107 chipset

[Ilia Mirkin]

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.com or make available some other way.

On Tue, Feb 14, 2017 at 2:34 PM, Daniel Drake  wrote:
> From: Chris Chiu 
>
> This new graphics card was failing to initialize with nouveau due to
> an "unknown chipset" error.
>
> Copy the GP106 configuration and rename for GP107/NV137. We don't
> know for certain that this is fully correct, but brief desktop testing
> suggests this is working fine.
>
> Signed-off-by: Chris Chiu 
> Signed-off-by: Daniel Drake 
> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 29 
> +++
>  1 file changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> index fea30d6..d242431 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> @@ -2237,6 +2237,34 @@ nv136_chipset = {
> .fifo = gp100_fifo_new,
>  };
>
> +static const struct nvkm_device_chip
> +nv137_chipset = {
> +   .name = "GP107",
> +   .bar = gf100_bar_new,
> +   .bios = nvkm_bios_new,
> +   .bus = gf100_bus_new,
> +   .devinit = gm200_devinit_new,
> +   .fb = gp104_fb_new,
> +   .fuse = gm107_fuse_new,
> +   .gpio = gk104_gpio_new,
> +   .i2c = gm200_i2c_new,
> +   .ibus = gm200_ibus_new,
> +   .imem = nv50_instmem_new,
> +   .ltc = gp100_ltc_new,
> +   .mc = gp100_mc_new,
> +   .mmu = gf100_mmu_new,
> +   .pci = gp100_pci_new,
> +   .timer = gk20a_timer_new,
> +   .top = gk104_top_new,
> +   .ce[0] = gp104_ce_new,
> +   .ce[1] = gp104_ce_new,
> +   .ce[2] = gp104_ce_new,
> +   .ce[3] = gp104_ce_new,
> +   .disp = gp104_disp_new,
> +   .dma = gf119_dma_new,
> +   .fifo = gp100_fifo_new,
> +};
> +
>  static int
>  nvkm_device_event_ctor(struct nvkm_object *object, void *data, u32 size,
>struct nvkm_notify *notify)
> @@ -2673,6 +2701,7 @@ nvkm_device_ctor(const struct nvkm_device_func *func,
> case 0x130: device->chip = _chipset; break;
> case 0x134: device->chip = _chipset; break;
> case 0x136: device->chip = _chipset; break;
> +   case 0x137: device->chip = _chipset; break;
> default:
> nvdev_error(device, "unknown chipset (%08x)\n", 
> boot0);
> goto done;
> --
> 2.9.3
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/nouveau/devinit/gf100-: try to avoid double-running vbios scripts

[Ilia Mirkin]

Turns out some VBIOSes don't actually set the bit in question in 2240c.
Use the nv50-style detection to try avoiding running the vbios twice.

Fixes: a6a0f67ca7aa ("drm/nouveau/devinit/gf100-: detect if BIOS invoked
devinit")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97620
Cc: <sta...@vger.kernel.org> # v4.6+
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---

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/nouveau/nvkm/subdev/devinit/gf100.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gf100.c
index 8b1b34c..686f788 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gf100.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 int
 gf100_devinit_pll_set(struct nvkm_devinit *init, u32 type, u32 freq)
@@ -102,6 +103,25 @@ gf100_devinit_preinit(struct nvkm_devinit *base)
 * can use it as a reliable way to know whether we should run devinit.
 */
base->post = ((nvkm_rd32(device, 0x2240c) & BIT(1)) == 0);
+
+   /*
+* However some VBIOS init sequences miss this bit. So fall back to
+* the nv50 method of checking if the bit is not set. Running the
+* VBIOS multiple times may have detrimental effects.
+*/
+   if (base->post) {
+   u64 disable = nvkm_devinit_disable(base);
+   /* magic to detect whether or not x86 vbios code has
+* executed the devinit scripts to initialise the
+* board. only works if there's a display engine.
+*/
+   if (!(disable & (1ULL << NVKM_ENGINE_DISP))) {
+   if (nvkm_rdvgac(device, 0, 0x00) ||
+   nvkm_rdvgac(device, 0, 0x1a)) {
+   base->post = false;
+   }
+   }
+   }
 }
 
 static const struct nvkm_devinit_func
-- 
2.10.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau/devinit/gf100-: try to avoid double-running vbios scripts

[Ilia Mirkin]

Turns out some VBIOSes don't actually set the bit in question in 2240c.
Use the nv50-style detection to try avoiding running the vbios twice.

Fixes: a6a0f67ca7aa ("drm/nouveau/devinit/gf100-: detect if BIOS invoked 
devinit")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97620
Cc: sta...@vger.kernel.org # v4.6+
Signed-off-by: Ilia Mirkin <imir...@alum.mit.edu>
---

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/gf100.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gf100.c
index 8b1b34c..a568bbf 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gf100.c
@@ -102,6 +102,25 @@ gf100_devinit_preinit(struct nvkm_devinit *base)
 * can use it as a reliable way to know whether we should run devinit.
 */
base->post = ((nvkm_rd32(device, 0x2240c) & BIT(1)) == 0);
+
+   /*
+* However some VBIOS init sequences miss this bit. So fall back to
+* the nv50 method of checking if the bit is not set. Running the
+* VBIOS multiple times may have detrimental effects.
+*/
+   if (base->post) {
+   u64 disable = nvkm_devinit_disable(base);
+   /* magic to detect whether or not x86 vbios code has
+* executed the devinit scripts to initialise the
+* board. only works if there's a display engine.
+*/
+   if (!(disable & (1ULL << NVKM_ENGINE_DISP))) {
+   if (nvkm_rdvgac(device, 0, 0x00) ||
+   nvkm_rdvgac(device, 0, 0x1a)) {
+   base->post = false;
+   }
+   }
+   }
 }
 
 static const struct nvkm_devinit_func
-- 
2.10.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

[Ilia Mirkin]

On Wed, Jan 18, 2017 at 11:57 AM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> On Wed, Jan 18, 2017 at 11:41 AM, Damien Lespiau
> <damien.lesp...@intel.com> 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
>>> > commercial 3D TV or similar device?
>>>
>>> My main testing device was a Samsung TV with this 3D_present bit set and
>>> all the advertised modes were working. Can't quite remember if that
>>> included the interleaved mode.
>>
>> I even pushed the EDID of that TV to edid-decode [1] if someone needs to
>> check that the EDID parsing is correct. It'd be interesting to see what
>> the tool has to say about the edid of the sink causing problems, in
>> particular compare the mandatory modes to the other modes advertised by
>> that TV. Maybe we could see some kind of pattern emerge, like the 3D
>> modes supported being the ones with the timings in table 8-15.
>
> This is Alastair's display (one of them): http://paste.lisp.org/display/335893
>
> I believe this is the interesting part:
>
>   Video data block
> VIC  16 1920x1080@60Hz
> VIC  31 1920x1080@50Hz
> VIC   5 1920x1080i@60Hz
> VIC  20 1920x1080i@50Hz
> VIC   4 1280x720@60Hz
> VIC  19 1280x720@50Hz
> VIC   3 720x480@60Hz
> VIC   2 720x480@60Hz
> VIC  18 720x576@50Hz
> VIC  17 720x576@50Hz
> VIC   7 1440x480i@60Hz
> VIC   6 1440x480i@60Hz
> VIC  22 1440x576i@50Hz
> VIC  21 1440x576i@50Hz
> VIC  32 1920x1080@24Hz
> VIC   1 640x480@60Hz
> ...
> Extended HDMI video details:
>   3D present
>   Base EDID image size is in units of 1cm
>   VIC index 2 supports side-by-side (half, horizontal)
>   VIC index 3 supports side-by-side (half, horizontal)
>   VIC index 4 supports side-by-side (half, horizontal)
>   VIC index 5 supports side-by-side (half, horizontal)
>   VIC index 14 supports side-by-side (half, horizontal)
>   VIC index 0 supports top-and-bottom
>   VIC index 1 supports top-and-bottom

And for the record, this is his other TV (available at the same paste
url as above):

  Video data block
VIC  16 1920x1080@60Hz (native)
VIC  34 1920x1080@30Hz
VIC  32 1920x1080@24Hz
VIC   5 1920x1080i@60Hz
VIC   4 1280x720@60Hz
VIC   3 720x480@60Hz
VIC   2 720x480@60Hz
VIC   1 640x480@60Hz
Extended HDMI video details:
  3D present
  3D-capable-VIC mask present
  3D: Side-by-side (half, horizontal)
  3D: Top-and-bottom
  3D VIC indices: 2 4
  VIC index 0 supports side-by-side (half, horizontal)
  VIC index 1 supports side-by-side (half, horizontal)
  VIC index 2 supports side-by-side (half, horizontal)
  VIC index 3 supports side-by-side (half, horizontal)
  VIC index 4 supports side-by-side (half, horizontal)

After some more conversations with Alastair, it sounds like what's
actually going on is that it's just the frame-packing modes that
aren't working, but all the side-by-side and top-and-bottom modes from
the "mandatory" list work. At this point, I'm more inclined to believe
that there's an issue in the nouveau implementation for frame-packed
modes. But it could still be the TVs themselves that don't support
that at all.

Cheers,

  -ilia
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

[Ilia Mirkin]

On Wed, Jan 18, 2017 at 11:41 AM, Damien Lespiau
<damien.lesp...@intel.com> 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
>> > commercial 3D TV or similar device?
>>
>> My main testing device was a Samsung TV with this 3D_present bit set and
>> all the advertised modes were working. Can't quite remember if that
>> included the interleaved mode.
>
> I even pushed the EDID of that TV to edid-decode [1] if someone needs to
> check that the EDID parsing is correct. It'd be interesting to see what
> the tool has to say about the edid of the sink causing problems, in
> particular compare the mandatory modes to the other modes advertised by
> that TV. Maybe we could see some kind of pattern emerge, like the 3D
> modes supported being the ones with the timings in table 8-15.

This is Alastair's display (one of them): http://paste.lisp.org/display/335893

I believe this is the interesting part:

  Video data block
VIC  16 1920x1080@60Hz
VIC  31 1920x1080@50Hz
VIC   5 1920x1080i@60Hz
VIC  20 1920x1080i@50Hz
VIC   4 1280x720@60Hz
VIC  19 1280x720@50Hz
VIC   3 720x480@60Hz
VIC   2 720x480@60Hz
VIC  18 720x576@50Hz
VIC  17 720x576@50Hz
VIC   7 1440x480i@60Hz
VIC   6 1440x480i@60Hz
VIC  22 1440x576i@50Hz
VIC  21 1440x576i@50Hz
VIC  32 1920x1080@24Hz
VIC   1 640x480@60Hz
...
Extended HDMI video details:
  3D present
  Base EDID image size is in units of 1cm
  VIC index 2 supports side-by-side (half, horizontal)
  VIC index 3 supports side-by-side (half, horizontal)
  VIC index 4 supports side-by-side (half, horizontal)
  VIC index 5 supports side-by-side (half, horizontal)
  VIC index 14 supports side-by-side (half, horizontal)
  VIC index 0 supports top-and-bottom
  VIC index 1 supports top-and-bottom
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

[Ilia Mirkin]

On Wed, Jan 18, 2017 at 6:45 AM, Damien Lespiau
<damien.lesp...@intel.com> 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
>> <alastair.bridgewa...@gmail.com> 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.
>> >
>> > More seriously, this code generates invalid display modes for both
>> > of the 3D-capable panels that I have (a 42-inch LG TV and a Sony
>> > PlayStation 3D Display).
>> >
>> > If we want to be persnickety, one option would be to check the
>> > final list of modes against the table and give some message if
>> > none of them are valid, but it's a whole lot easier just to delete
>> > the code in question.
>>
>> Damien added this in commit c858cfcae6d some 3 years ago.
>>
>> Damien, do you remember why you added these "required" modes? Did you
>> have a monitor that only advertised 3D support without the actual
>> modes?
>
> Another quick glance at the specs leads me to believe c858cfcae6d is
> correct.
>
> 8-15 does say that a sink supporting 3D must at lesst support one of the
> modes listed in that table. But that's just the very start of the story
> and we are really talking about the 3D_present bit in the HMDI VSDB and
> the associated "mandatory" modes (the term comes from the spec).
>
> HDMI 1.4a Page 155:
>
> "3D_present [1bit] This bit indicates 3D support by the HDMI Sink,
> including the mandatory formats. If set (=1), an HDMI Sink supports the
> 3D video formats that are mandatory formats,"
>
> Continuing page 157:
>
> "If 3D_present is set (=1), an HDMI Sink shall support 3D video formats
> per the following requirements.
> ・An HDMI Sink which supports at least one 59.94 / 60Hz 2D video format
> shall support *all* of "
> ・An HDMI Sink which supports at least one 50Hz 2D video format shall
> support *all* of "
>
> The 3D pdf extraction from the spec is available would one want to
> triple check the above:
>
>http://www.hdmi.org/manufacturer/specification.aspx
>
> I have even dug up a direct link that someone made available:
>
>   https://etmriwi.home.xs4all.nl/forum/hdmi_spec1.4a_3dextraction.pdf
>
> Look for 3D_present, p. 15 and 17.
>
> If the above is indeed correct, there may still be an issue in the way
> we derive the mandatory modes - that part isn't really clear. Or, it
> could be that people don't follow standards!

OK, so the text definitely makes it seem like you're right.

Damien - did you ever test these mandatory modes on an actual
commercial 3D TV or similar device?

Alastair - I think this warrants some more attempts at getting those
"extra" modes to work. I'd be especially curious whether the blob
shows support for these modes, or what Windows shows with any
hardware.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

[Ilia Mirkin]

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.
>
> More seriously, this code generates invalid display modes for both
> of the 3D-capable panels that I have (a 42-inch LG TV and a Sony
> PlayStation 3D Display).
>
> If we want to be persnickety, one option would be to check the
> final list of modes against the table and give some message if
> none of them are valid, but it's a whole lot easier just to delete
> the code in question.

Damien added this in commit c858cfcae6d some 3 years ago.

Damien, do you remember why you added these "required" modes? Did you
have a monitor that only advertised 3D support without the actual
modes?

>
> Signed-off-by: Alastair Bridgewater 
> ---
>  drivers/gpu/drm/drm_edid.c | 66 
> --
>  1 file changed, 66 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 336be31..723116a 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2926,70 +2926,6 @@ do_cea_modes(struct drm_connector *connector, const u8 
> *db, u8 len)
> return modes;
>  }
>
> -struct stereo_mandatory_mode {
> -   int width, height, vrefresh;
> -   unsigned int flags;
> -};
> -
> -static const struct stereo_mandatory_mode stereo_mandatory_modes[] = {
> -   { 1920, 1080, 24, DRM_MODE_FLAG_3D_TOP_AND_BOTTOM },
> -   { 1920, 1080, 24, DRM_MODE_FLAG_3D_FRAME_PACKING },
> -   { 1920, 1080, 50,
> - DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
> -   { 1920, 1080, 60,
> - DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
> -   { 1280, 720,  50, DRM_MODE_FLAG_3D_TOP_AND_BOTTOM },
> -   { 1280, 720,  50, DRM_MODE_FLAG_3D_FRAME_PACKING },
> -   { 1280, 720,  60, DRM_MODE_FLAG_3D_TOP_AND_BOTTOM },
> -   { 1280, 720,  60, DRM_MODE_FLAG_3D_FRAME_PACKING }
> -};
> -
> -static bool
> -stereo_match_mandatory(const struct drm_display_mode *mode,
> -  const struct stereo_mandatory_mode *stereo_mode)
> -{
> -   unsigned int interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE;
> -
> -   return mode->hdisplay == stereo_mode->width &&
> -  mode->vdisplay == stereo_mode->height &&
> -  interlaced == (stereo_mode->flags & DRM_MODE_FLAG_INTERLACE) &&
> -  drm_mode_vrefresh(mode) == stereo_mode->vrefresh;
> -}
> -
> -static int add_hdmi_mandatory_stereo_modes(struct drm_connector *connector)
> -{
> -   struct drm_device *dev = connector->dev;
> -   const struct drm_display_mode *mode;
> -   struct list_head stereo_modes;
> -   int modes = 0, i;
> -
> -   INIT_LIST_HEAD(_modes);
> -
> -   list_for_each_entry(mode, >probed_modes, head) {
> -   for (i = 0; i < ARRAY_SIZE(stereo_mandatory_modes); i++) {
> -   const struct stereo_mandatory_mode *mandatory;
> -   struct drm_display_mode *new_mode;
> -
> -   if (!stereo_match_mandatory(mode,
> -   
> _mandatory_modes[i]))
> -   continue;
> -
> -   mandatory = _mandatory_modes[i];
> -   new_mode = drm_mode_duplicate(dev, mode);
> -   if (!new_mode)
> -   continue;
> -
> -   new_mode->flags |= mandatory->flags;
> -   list_add_tail(_mode->head, _modes);
> -   modes++;
> -   }
> -   }
> -
> -   list_splice_tail(_modes, >probed_modes);
> -
> -   return modes;
> -}
> -
>  static int add_hdmi_mode(struct drm_connector *connector, u8 vic)
>  {
> struct drm_device *dev = connector->dev;
> @@ -3090,8 +3026,6 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, 
> const u8 *db, u8 len,
> /* 3D_Present */
> offset++;
> if (db[8 + offset] & (1 << 7)) {
> -   modes += add_hdmi_mandatory_stereo_modes(connector);
> -
> /* 3D_Multi_present */
> multi_present = (db[8 + offset] & 0x60) >> 5;
> }
> --
> 2.10.2
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [PATCH] drm/nouveau: Fix HDA ELD handling (thus, HDMI audio) on gt215

[Ilia Mirkin]

On Wed, Jan 11, 2017 at 3:47 PM, Alastair Bridgewater
<alastair.bridgewa...@gmail.com> wrote:
> Store the ELD correctly, not just enough copies of the first byte
> to pad out the given ELD size.
>
> Signed-off-by: Alastair Bridgewater <alastair.bridgewa...@gmail.com>

Great find! Here are some more tags:

Fixes: 120b0c39c756 ("drm/nv50-/disp: audit and version SOR_HDA_ELD method")
Cc: sta...@vger.kernel.org # v3.17+
Reviewed-by: Ilia Mirkin <imir...@alum.mit.edu>

> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c
> index 6f0436d..f8f2f16 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c
> @@ -59,7 +59,7 @@ gt215_hda_eld(NV50_DISP_MTHD_V1)
> );
> }
> for (i = 0; i < size; i++)
> -   nvkm_wr32(device, 0x61c440 + soff, (i << 8) | 
> args->v0.data[0]);
> +   nvkm_wr32(device, 0x61c440 + soff, (i << 8) | 
> args->v0.data[i]);
> for (; i < 0x60; i++)
> nvkm_wr32(device, 0x61c440 + soff, (i << 8));
> nvkm_mask(device, 0x61c448 + soff, 0x8003, 0x8003);
> --
> 2.10.2
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/nouveau: fix bug id typo in comment

[Ilia Mirkin]

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/rammcp77.c
index 0a0e44b..017a91d 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/rammcp77.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/rammcp77.c
@@ -39,7 +39,7 @@ mcp77_ram_init(struct nvkm_ram *base)
u32 flush  = ((ram->base.size - (ram->poller_base + 0x40)) >> 5) - 1;

/* Enable NISO poller for various clients and set their associated
-* read address, only for MCP77/78 and MCP79/7A. (fd#25701)
+* read address, only for MCP77/78 and MCP79/7A. (fd#27501)
 */
nvkm_wr32(device, 0x100c18, dniso);
nvkm_mask(device, 0x100c14, 0x, 0x0001);
-- 
2.10.2

[PATCH] drm: nouveau: fix build when LEDS_CLASS=m

[Ilia Mirkin]

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:
>>>>> 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 same
>>>>>> kconfig value as LEDS_CLASS.
>>>>>>
>>>>>> drivers/built-in.o: In function `nouveau_do_suspend':
>>>>>> nouveau_drm.c:(.text+0x2030b1): undefined reference to 
>>>>>> `nouveau_led_suspend'
>>>>>> drivers/built-in.o: In function `nouveau_do_resume':
>>>>>> nouveau_drm.c:(.text+0x2034ca): undefined reference to 
>>>>>> `nouveau_led_resume'
>>>>>> drivers/built-in.o: In function `nouveau_drm_unload':
>>>>>> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini'
>>>>>> drivers/built-in.o: In function `nouveau_drm_load':
>>>>>> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init'
>>>>>>
>>>>>> BTW, this line in Kbuild:
>>>>>> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o
>>>>>> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y.
>>>>>>
>>>>>> Signed-off-by: Randy Dunlap 
>>>>>> Reported-by: kbuild test robot 
>>>>>> Cc: Martin Peres 
>>>>>> Cc: Ben Skeggs 
>>>>>
>>>>> Thrown into drm-misc, thanks.
>>>>> -Daniel
>>>>
>>>> Wasn't there already a different solution from Martin for this, using
>>>> IS_REACHABLE, instead of adding a dependency in Kconfig?
>>>
>>> nouveau_led.h contains a few lines that are bounded by
>>> #if IS_ENABLED(CONFIG_LEDS_CLASS)
>>>
>>> but that's not sufficient.
>>>
>>> Is there another patch?
>>
>> https://lists.freedesktop.org/archives/nouveau/2016-December/026744.html
>>
>> Not sure why it's not upstream yet. I guess Ben missed it?
>
> Ok, if you all are OK with a slightly crippled driver.

The LED functionality is to allow adjusting the light inside the case
of the high-end GTX TITAN boards. I think people will be fine with
that level of crippled for when they build nouveau in and the leds
class as a module.

  -ilia

[PATCH] drm: nouveau: fix build when LEDS_CLASS=m

[Ilia Mirkin]

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 
>>>>
>>>> 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 same
>>>> kconfig value as LEDS_CLASS.
>>>>
>>>> drivers/built-in.o: In function `nouveau_do_suspend':
>>>> nouveau_drm.c:(.text+0x2030b1): undefined reference to 
>>>> `nouveau_led_suspend'
>>>> drivers/built-in.o: In function `nouveau_do_resume':
>>>> nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume'
>>>> drivers/built-in.o: In function `nouveau_drm_unload':
>>>> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini'
>>>> drivers/built-in.o: In function `nouveau_drm_load':
>>>> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init'
>>>>
>>>> BTW, this line in Kbuild:
>>>> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o
>>>> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y.
>>>>
>>>> Signed-off-by: Randy Dunlap 
>>>> Reported-by: kbuild test robot 
>>>> Cc: Martin Peres 
>>>> Cc: Ben Skeggs 
>>>
>>> Thrown into drm-misc, thanks.
>>> -Daniel
>>
>> Wasn't there already a different solution from Martin for this, using
>> IS_REACHABLE, instead of adding a dependency in Kconfig?
>
> nouveau_led.h contains a few lines that are bounded by
> #if IS_ENABLED(CONFIG_LEDS_CLASS)
>
> but that's not sufficient.
>
> Is there another patch?

https://lists.freedesktop.org/archives/nouveau/2016-December/026744.html

Not sure why it's not upstream yet. I guess Ben missed it?

  -ilia

[PATCH] drm: nouveau: fix build when LEDS_CLASS=m

[Ilia Mirkin]

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 same
>> kconfig value as LEDS_CLASS.
>>
>> drivers/built-in.o: In function `nouveau_do_suspend':
>> nouveau_drm.c:(.text+0x2030b1): undefined reference to `nouveau_led_suspend'
>> drivers/built-in.o: In function `nouveau_do_resume':
>> nouveau_drm.c:(.text+0x2034ca): undefined reference to `nouveau_led_resume'
>> drivers/built-in.o: In function `nouveau_drm_unload':
>> nouveau_drm.c:(.text+0x203a15): undefined reference to `nouveau_led_fini'
>> drivers/built-in.o: In function `nouveau_drm_load':
>> nouveau_drm.c:(.text+0x204423): undefined reference to `nouveau_led_init'
>>
>> BTW, this line in Kbuild:
>> nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o
>> does nothing when CONFIG_LEDS_CLASS=m and CONFIG_DRM_NOUVEAU=y.
>>
>> Signed-off-by: Randy Dunlap 
>> Reported-by: kbuild test robot 
>> Cc: Martin Peres 
>> Cc: Ben Skeggs 
>
> Thrown into drm-misc, thanks.
> -Daniel

Wasn't there already a different solution from Martin for this, using
IS_REACHABLE, instead of adding a dependency in Kconfig?

>
>> ---
>>  drivers/gpu/drm/nouveau/Kconfig |1 +
>>  1 file changed, 1 insertion(+)
>>
>> --- lnx-410-rc2.orig/drivers/gpu/drm/nouveau/Kconfig
>> +++ lnx-410-rc2/drivers/gpu/drm/nouveau/Kconfig
>> @@ -1,6 +1,7 @@
>>  config DRM_NOUVEAU
>>   tristate "Nouveau (NVIDIA) cards"
>>   depends on DRM && PCI
>> + depends on LEDS_CLASS || LEDS_CLASS=n
>>  select FW_LOADER
>>   select DRM_KMS_HELPER
>>   select DRM_TTM
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 07/10] drm/i915/psr: set PSR_MASK bits for deep sleep

[Ilia Mirkin]

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,
> flickering is observed on psr2 panel.
>
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: Vathsala Nagaraju 
> Signed-off-by: Patil Deepti 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  7 +++
>  drivers/gpu/drm/i915/intel_dp.c  |  1 -
>  drivers/gpu/drm/i915/intel_psr.c | 29 -
>  3 files changed, 27 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 5ca506a..0cbe564 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3600,6 +3600,12 @@ enum {
>  #define   EDP_PSR_DEBUG_MASK_LPSP  (1<<27)
>  #define   EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
>  #define   EDP_PSR_DEBUG_MASK_HPD   (1<<25)
> +#define   EDP_PSR_DEBUG_MASK_MAX_SLEEP (1<<28)
> +#define   EDP_PSR_DEBUG_MASK_LPSP  (1<<27)
> +#define   EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
> +#define   EDP_PSR_DEBUG_MASK_HPD   (1<<25)

Looks like you're defining the above 3 (maybe 4 - not enough context)
a second time.

  -ilia

[PATCH] drm/exynos/decon5433: configure sysreg in case of hardware trigger

[Ilia Mirkin]

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 
> +--
>  1 file changed, 32 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 6ca1f31..1bef2ec 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -13,9 +13,11 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>
> @@ -25,6 +27,9 @@
>  #include "exynos_drm_plane.h"
>  #include "exynos_drm_iommu.h"
>
> +#define DSD_CFG_MUX 0x1004
> +#define DSD_CFG_MUX_TE_UNMASK_GLOBAL BIT(13)
> +
>  #define WINDOWS_NR 3
>  #define MIN_FB_WIDTH_FOR_16WORD_BURST  128
>
> @@ -56,6 +61,7 @@ struct decon_context {
> struct exynos_drm_plane planes[WINDOWS_NR];
> struct exynos_drm_plane_config  configs[WINDOWS_NR];
> void __iomem*addr;
> +   struct regmap   *sysreg;
> struct clk  *clks[ARRAY_SIZE(decon_clks_name)];
> int pipe;
> unsigned long   flags;
> @@ -117,12 +123,22 @@ static void decon_disable_vblank(struct exynos_drm_crtc 
> *crtc)
>
>  static void decon_setup_trigger(struct decon_context *ctx)
>  {
> -   u32 val = !(ctx->out_type & I80_HW_TRG)
> -   ? TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
> - TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
> -   : TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F |
> - TRIGCON_HWTRIGMASK | TRIGCON_HWTRIGEN;
> -   writel(val, ctx->addr + DECON_TRIGCON);
> +   if (!(ctx->out_type & (IFTYPE_I80 | I80_HW_TRG)))
> +   return;
> +
> +   if (!(ctx->out_type & I80_HW_TRG)) {
> +   writel(TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN
> +  | TRIGCON_TE_AUTO_MASK | TRIGCON_SWTRIGEN,
> +  ctx->addr + DECON_TRIGCON);
> +   return;
> +   }
> +
> +   writel(TRIGCON_TRIGEN_PER_F | TRIGCON_TRIGEN_F | TRIGCON_HWTRIGMASK
> +  | TRIGCON_HWTRIGEN, ctx->addr + DECON_TRIGCON);
> +
> +   if (regmap_update_bits(ctx->sysreg, DSD_CFG_MUX,
> +  DSD_CFG_MUX_TE_UNMASK_GLOBAL, ~0))
> +   DRM_ERROR("Cannot update sysreg.\n");
>  }
>
>  static void decon_commit(struct exynos_drm_crtc *crtc)
> @@ -147,8 +163,7 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
> val = CMU_CLKGAGE_MODE_SFR_F | CMU_CLKGAGE_MODE_MEM_F;
> writel(val, ctx->addr + DECON_CMU);
>
> -   if (ctx->out_type & (IFTYPE_I80 | I80_HW_TRG))
> -   decon_setup_trigger(ctx);
> +   decon_setup_trigger(ctx);
>
> /* lcd on and use command if */
> val = VIDOUT_LCD_ON;
> @@ -640,6 +655,15 @@ static int exynos5433_decon_probe(struct platform_device 
> *pdev)
> ctx->out_type |= IFTYPE_I80;
> }
>
> +   if (ctx->out_type | I80_HW_TRG) {

Did you mean & here?

> +   ctx->sysreg = syscon_regmap_lookup_by_phandle(dev->of_node,
> +   
> "samsung,disp-sysreg");
> +   if (IS_ERR(ctx->sysreg)) {
> +   dev_err(dev, "failed to get system register\n");
> +   return PTR_ERR(ctx->sysreg);
> +   }
> +   }
> +
> for (i = 0; i < ARRAY_SIZE(decon_clks_name); i++) {
> struct clk *clk;
>
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: hdlcd: Work properly in big-endian mode

[Ilia Mirkin]

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 here... NV11+ cards have a "big endian"
mode, where you can do 32-bit mmio from a big-endian cpu, and the card
will auto-swap those. There are similar additional bits that make
operating and accelerating off a big-endian CPU tolerable. Some care
has gone into the kernel to make sure that all that stuff works. (One
of those bits is that data gets byteswapped on upload to VRAM by
virtue of being uploaded by sticking data into a pushbuf, as I
recall.)

  -ilia

[Nouveau] 4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k

[Ilia Mirkin]

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 -- nouveau currently requires 4k page sizes to work. This is a
>>>> software limitation, not a hardware one though.
>>>
>>> Looking at the trace I wonder - is the limitation in Nouveau or in TTM?
>>
>> Nouveau. Non-4K page sizes work fine with radeon (and presumably amdgpu).
>
> Thanks for the precision. I will check if Tegra iGPUs are also
> affected by this - if they are then it gives me a good excuse to take
> care of this bug.

For the most part it's confusion in the (nouveau) code as to what's a
gpu page and what's a cpu page (and the shifts involved). There are
some fringe issues that will need to be addressed, like the fact that
it's no longer a 1:1 mapping, which might be assumed in some places.

However I thought that 64K-pages were frowned upon nowadays for the
kernel - outside of HPC loads, most of the kernel memory becomes
pagecache, and files don't tend to be 64K-sized, so you have tons of
wasted memory (since you never cache multiple files in the same page).

But don't take that as me disapproving of such a project. It'd esp be
nice to do something like this outside of the PPC64 environment, where
BE concerns mix in with the 64K page concerns, and nothing works as a
result.

  -ilia

4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k

[Ilia Mirkin]

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] Initialized
nouveau :01:00.0: NVIDIA G94 (094100a1)
nouveau :01:00.0: bios: version 62.94.0d.00.04
nouveau: probe of :01:00.0 failed with error -22

Which with a little bit of debugging seems to be a failure in:

[77216.692605] [] ttm_bo_validate+0xb0/0x1e8 [ttm]
[77216.698697] [] ttm_bo_init+0x354/0x410 [ttm]
[77216.704706] [] nouveau_bo_new+0x1f4/0x314 [nouveau]
[77216.711308] [] nv50_display_create+0x10c/0xa1c
[nouveau]
[77216.718340] [] nouveau_display_create+0x50c/0x59c
[nouveau]
[77216.725632] [] nouveau_drm_load+0x22c/0x8c0 [nouveau]
[77216.732286] [] drm_dev_register+0xc0/0xf0 [drm]
[77216.738409] [] drm_get_pci_dev+0xbc/0x188 [drm]
[77216.744663] [] nouveau_drm_probe+0x180/0x208 [nouveau]
[77216.751354] [] local_pci_probe+0x50/0xb4
[77216.756827] [] pci_device_probe+0xf8/0x148
[77216.762474] [] driver_probe_device+0x284/0x420
[77216.768467] [] __driver_attach+0x120/0x124
[77216.774115] [] bus_for_each_dev+0x6c/0xac
[77216.779673] [] driver_attach+0x2c/0x34
[77216.784972] [] bus_add_driver+0x244/0x2b0
[77216.790531] [] driver_register+0x68/0xfc
[77216.796004] [] __pci_register_driver+0x60/0x6c
[77216.802047] [] drm_pci_init+0x108/0x138 [drm]
[77216.808146] [] nouveau_drm_init+0x158/0x1 [nouveau]
[77216.814922] [] do_one_initcall+0x44/0x128
[77216.820483] [] do_init_module+0x68/0x1e0
[77216.825957] [] load_module+0xfac/0x12bc
[77216.831343] [] SyS_finit_module+0xe4/0xf0
[77216.836902] [] el0_svc_naked+0x24/0x28

By default fedora is using a 64k page kernel, switching to a mainline
4.9-rc7 kernel using the same configuration the same problem exists (there
are a couple others, mentioned briefly in the defect). Changing the
mainline kernel from 64k to 4k pages corrects the problem and a terminal
display can be seen.

The fedora defect is:
https://bugzilla.redhat.com/show_bug.cgi?id=1400623


Thanks,
___
dri-devel mailing list
dri-devel at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL: 

[PATCH] drm/nouveau: fix LEDS_CLASS=m configuration

[Ilia Mirkin]

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+0x10): undefined reference to 
> `nouveau_led_suspend'
> drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do_resume':
> tvnv17.c:(.text.nouveau_do_resume+0xf0): undefined reference to 
> `nouveau_led_resume'
> drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_drm_unload':
> tvnv17.c:(.text.nouveau_drm_unload+0x34): undefined reference to 
> `nouveau_led_fini'
> drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_drm_load':
> tvnv17.c:(.text.nouveau_drm_load+0x7d0): undefined reference to 
> `nouveau_led_init'
>
> This adds a separate Kconfig symbol for the LED support that
> correctly tracks the dependencies.
>
> Fixes: 8d021d71b324 ("drm/nouveau/drm/nouveau: add a LED driver for the 
> NVIDIA logo")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/nouveau/Kbuild| 2 +-
>  drivers/gpu/drm/nouveau/Kconfig   | 8 
>  drivers/gpu/drm/nouveau/nouveau_led.h | 2 +-
>  3 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/Kbuild b/drivers/gpu/drm/nouveau/Kbuild
> index fde6e3656636..5e00e911daa6 100644
> --- a/drivers/gpu/drm/nouveau/Kbuild
> +++ b/drivers/gpu/drm/nouveau/Kbuild
> @@ -22,7 +22,7 @@ nouveau-$(CONFIG_DEBUG_FS) += nouveau_debugfs.o
>  nouveau-y += nouveau_drm.o
>  nouveau-y += nouveau_hwmon.o
>  nouveau-$(CONFIG_COMPAT) += nouveau_ioc32.o
> -nouveau-$(CONFIG_LEDS_CLASS) += nouveau_led.o
> +nouveau-$(CONFIG_DRM_NOUVEAU_LED) += nouveau_led.o
>  nouveau-y += nouveau_nvif.o
>  nouveau-$(CONFIG_NOUVEAU_PLATFORM_DRIVER) += nouveau_platform.o
>  nouveau-y += nouveau_usif.o # userspace <-> nvif
> diff --git a/drivers/gpu/drm/nouveau/Kconfig b/drivers/gpu/drm/nouveau/Kconfig
> index 78631fb61adf..715cd6f4dc31 100644
> --- a/drivers/gpu/drm/nouveau/Kconfig
> +++ b/drivers/gpu/drm/nouveau/Kconfig
> @@ -46,6 +46,14 @@ config NOUVEAU_DEBUG
>   The paranoia and spam levels will add a lot of extra checks which
>   may potentially slow down driver operation.
>
> +config DRM_NOUVEAU_LED
> +   bool "Support for logo LED"
> +   depends on DRM_NOUVEAU && LEDS_CLASS
> +   depends on !(DRM_NOUVEAU=y && LEDS_CLASS=m)
> +   help
> + Say Y here to enabling controlling the brightness of the
> + LED behind NVIDIA logo on certain Titan cards.

This is a very odd restriction... could this be written as

depends on DRM_NOUVEAU
select LEDS_CLASS

Or will that not flip the LEDS_CLASS from m to y in case
DRM_NOUVEAU=y? If not, is there a way to cause that to happen?

Separately, perhaps we should just drop this LEDS_CLASS select into
DRM_NOUVEAU? We've tended to avoid adding tons of options.

Cheers,

  -ilia

[Nouveau] Nouveau regression since kernel 4.3: loading NVIDIA's firwmare files

[Ilia Mirkin]

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 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 fw being
>> ... lacking. This is especially common on GK106's for some reason.
>>
>> The arguments for doing this at the time was that (a) all the bugs in
>> nouveau's fw have been fixed and thus those people don't need to be
>> using those extracted firmware files and (b) NVIDIA was going to
>> release firmware and so things would Just Work (tm) since the new
>> files would be at the new locations.
>>
>> Neither of these have come to fruition. Plenty of people still have
>> GK106's that don't work well with nouveau's fw. NVIDIA has shown no
>> interest in releasing firmware in a redistributable fashion.
>>
>> Can you please create a patch to fix this up so that it still tries to
>> load files from the previous location with the previous names so that
>> people's previously-working setups can keep on working?
>
> Certainly. Actually my first version of 8539b37acef7 did fall back to
> the original paths for loading firmware, but Ben suggested that we
> just replace the paths entirely, hence the version currently merged:
>
> https://lists.freedesktop.org/archives/dri-devel/2015-June/084914.html
>
> Ben, do you agree with falling back to the old "nouveau/nvxx_fuc"
> firmware names so people don't need to move their firmware files
> around?

The theory was that the nouveau fw was going to be sufficient for
pre-GM200 chips. Practice hasn't lived up to that - a ton of people
with a GTX 660's have issues with the nouveau fw being unstable, whose
issues are fixed by the extracted firmware from the blob.

  -ilia

Nouveau regression since kernel 4.3: loading NVIDIA's firwmare files

[Ilia Mirkin]

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 fw being
... lacking. This is especially common on GK106's for some reason.

The arguments for doing this at the time was that (a) all the bugs in
nouveau's fw have been fixed and thus those people don't need to be
using those extracted firmware files and (b) NVIDIA was going to
release firmware and so things would Just Work (tm) since the new
files would be at the new locations.

Neither of these have come to fruition. Plenty of people still have
GK106's that don't work well with nouveau's fw. NVIDIA has shown no
interest in releasing firmware in a redistributable fashion.

Can you please create a patch to fix this up so that it still tries to
load files from the previous location with the previous names so that
people's previously-working setups can keep on working?

Thanks,

  -ilia

Kernel Freeze with American Megatrends BIOS

[Ilia Mirkin]

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 off.
>   I can't trigger the freeze, because bbswitch is missing.
>   I'll work with the system and see if it will freeze.
>
> Kernel 4.8-rc4: nouveau does not care about the power state and
> the discrete GPU is never switched off. I will notice
> this, because the second cooling FAN will stop...
> Same log messages as send before.

That's surprising. I believe there's an issue with the new logic when
there's an HDMI audio subdevice. However that only appears if there's
a cable plugged in, at least in the systems Peter tested. You should
be able to see whether it's there or not with 'lspci'.

You can check for sure by looking in the vgaswitcheroo state. It
should say DynOff when it's powered off.

Either way, I think using bbswitch + nouveau isn't supported by
anyone, so if you want to use it that way, you're on your own. (You
may want to load nouveau with runpm=0 so that nouveau doesn't try to
manage the GPU suspend stuff.)

  -ilia

Kernel Freeze with American Megatrends BIOS

[Ilia Mirkin]

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 is
managing. What if you just use nouveau and let it auto-power-off the
GPU like it's designed to, with v4.8-rc?

  -ilia

Kernel Freeze with American Megatrends BIOS

[Ilia Mirkin]

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 the power management of the GPU.
>>The graphical session freezes after some minutes...
>>
>> 2. Booted the system without bbswitch and with nouveau blacklisted.
>>Manually loaded bbswitch to switch off the discrete GPU.
>>Same freeze after a while or by explicitly obtaining the GPU state.
>>
>> Is there a possibility to switch off the discrete card without bbswitch?
>> If this is possible, then I could test this without nouveau and bbswitch
>> at all. If the system hangs, then it is not the video driver nor bbswitch.
>
> You can use acpi_call (a random search points to
> https://github.com/mkottman/acpi_call, but I don't know if that's the
> "official" version) - need to find the right method to call, but
> that's basically all it takes to acpi-suspend a gpu.
>
> Separately, there was a recent fix to ... something, including but not
> limited to nouveau, involving hangs on gpu suspend on newer laptops. I
> don't think it's upstream yet. Look for patches from Lukas Wunner.

Er oops. Looks like I misremembered. Patches are from Peter Wu, and at
least one of them is in v4.8-rc1:

commit 692a17dcc2922a91c6bcf11b3321503a3377b1b1
Author: Peter Wu 
Date:   Fri Jul 15 15:12:18 2016 +0200

drm/nouveau/acpi: fix lockup with PCIe runtime PM

along with a number of other related patches. It's not clear which
kernel you were trying this with... can you give v4.8-rcN a shot?

  -ilia

Kernel Freeze with American Megatrends BIOS

[Ilia Mirkin]

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 the system without bbswitch and with nouveau blacklisted.
>Manually loaded bbswitch to switch off the discrete GPU.
>Same freeze after a while or by explicitly obtaining the GPU state.
>
> Is there a possibility to switch off the discrete card without bbswitch?
> If this is possible, then I could test this without nouveau and bbswitch
> at all. If the system hangs, then it is not the video driver nor bbswitch.

You can use acpi_call (a random search points to
https://github.com/mkottman/acpi_call, but I don't know if that's the
"official" version) - need to find the right method to call, but
that's basically all it takes to acpi-suspend a gpu.

Separately, there was a recent fix to ... something, including but not
limited to nouveau, involving hangs on gpu suspend on newer laptops. I
don't think it's upstream yet. Look for patches from Lukas Wunner.

  -ilia

[PATCH] Re: Mullins support in xf86-video-amdgpu

[Ilia Mirkin]

On Mon, Aug 22, 2016 at 10:57 PM, Reid Hekman  wrote:
> On 08/22/2016 08:27 PM, Michel Dänzer wrote:
>>
>> On 23/08/16 10:18 AM, Reid Hekman wrote:
>>>
>>>
>>> I was encouraged by a commit I saw today to add Sea Islands PCI ids to
>>> xf86-video-amdgpu.  However I did not see MULLINS included. Are there
>>> other showstoppers preventing inclusion?
>>
>>
>> I assume the commit you're referring to was the one adding the
>> *Southern* Islands (SI) PCI IDs. Since Mullins is Sea Islands (CIK), it
>> should already be supported by the amdgpu kernel driver; its omission
>> from xf86-video-amdgpu is probably just an oversight. Can you send a
>> patch to the amd-gfx mailing list?
>>
>
> Michael, oops, yes, sorry, apparently my head was on the wrong AMD islands.
> Admittedly I'm a total newb at this, but David's script makes this seem
> fairly simple.  Does the following look correct?
>
> Regards,
> Reid
>
> ---
> diff -aur a/src/amdgpu_chipinfo_gen.h b/src/amdgpu_chipinfo_gen.h
> --- a/src/amdgpu_chipinfo_gen.h 2016-08-22 21:25:49.101755291 -0500
> +++ b/src/amdgpu_chipinfo_gen.h 2016-08-22 21:41:26.758967344 -0500
> @@ -100,6 +100,22 @@
>   { 0x983D, CHIP_FAMILY_KABINI },
>   { 0x983E, CHIP_FAMILY_KABINI },
>   { 0x983F, CHIP_FAMILY_KABINI },
> + { 0x9850, CHIP_FAMILY_MULLINS },
> + { 0x9851, CHIP_FAMILY_MULLINS },
> + { 0x9852, CHIP_FAMILY_MULLINS },
> + { 0x9853, CHIP_FAMILY_MULLINS },
> + { 0x9854, CHIP_FAMILY_MULLINS },
> + { 0x9855, CHIP_FAMILY_MULLINS },
> + { 0x9856, CHIP_FAMILY_MULLINS },
> + { 0x9857, CHIP_FAMILY_MULLINS },
> + { 0x9858, CHIP_FAMILY_MULLINS },
> + { 0x9859, CHIP_FAMILY_MULLINS },
> + { 0x985a, CHIP_FAMILY_MULLINS },
> + { 0x985b, CHIP_FAMILY_MULLINS },
> + { 0x985c, CHIP_FAMILY_MULLINS },
> + { 0x985d, CHIP_FAMILY_MULLINS },
> + { 0x985e, CHIP_FAMILY_MULLINS },
> + { 0x985f, CHIP_FAMILY_MULLINS },
>   { 0x1304, CHIP_FAMILY_KAVERI },
>   { 0x1305, CHIP_FAMILY_KAVERI },
>   { 0x1306, CHIP_FAMILY_KAVERI },
> diff -aur a/src/amdgpu_chipset_gen.h b/src/amdgpu_chipset_gen.h
> --- a/src/amdgpu_chipset_gen.h  2016-08-22 21:25:49.101755291 -0500
> +++ b/src/amdgpu_chipset_gen.h  2016-08-22 21:41:26.758967344 -0500
> @@ -100,6 +100,22 @@
>{ PCI_CHIP_KABINI_983D, "KABINI" },
>{ PCI_CHIP_KABINI_983E, "KABINI" },
>{ PCI_CHIP_KABINI_983F, "KABINI" },
> +  { PCI_CHIP_MULLINS 9850, "MULLINS" },
> +  { PCI_CHIP_MULLINS 9851, "MULLINS" },
> +  { PCI_CHIP_MULLINS 9852, "MULLINS" },
> +  { PCI_CHIP_MULLINS 9853, "MULLINS" },
> +  { PCI_CHIP_MULLINS 9854, "MULLINS" },
> +  { PCI_CHIP_MULLINS 9855, "MULLINS" },
> +  { PCI_CHIP_MULLINS 9856, "MULLINS" },
> +  { PCI_CHIP_MULLINS 9857, "MULLINS" },
> +  { PCI_CHIP_MULLINS 9858, "MULLINS" },
> +  { PCI_CHIP_MULLINS 9859, "MULLINS" },
> +  { PCI_CHIP_MULLINS 985a, "MULLINS" },
> +  { PCI_CHIP_MULLINS 985b, "MULLINS" },
> +  { PCI_CHIP_MULLINS 985c, "MULLINS" },
> +  { PCI_CHIP_MULLINS 985d, "MULLINS" },
> +  { PCI_CHIP_MULLINS 985e, "MULLINS" },
> +  { PCI_CHIP_MULLINS 985f, "MULLINS" },
>{ PCI_CHIP_KAVERI_1304, "KAVERI" },
>{ PCI_CHIP_KAVERI_1305, "KAVERI" },
>{ PCI_CHIP_KAVERI_1306, "KAVERI" },
> diff -aur a/src/amdgpu_pci_chipset_gen.h b/src/amdgpu_pci_chipset_gen.h
> --- a/src/amdgpu_pci_chipset_gen.h  2016-08-22 21:25:49.104755254 -0500
> +++ b/src/amdgpu_pci_chipset_gen.h  2016-08-22 21:41:26.758967344 -0500
> @@ -100,6 +100,22 @@
>   { PCI_CHIP_KABINI_983D, PCI_CHIP_KABINI_983D, RES_SHARED_VGA },
>   { PCI_CHIP_KABINI_983E, PCI_CHIP_KABINI_983E, RES_SHARED_VGA },
>   { PCI_CHIP_KABINI_983F, PCI_CHIP_KABINI_983F, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9850, PCI_CHIP_MULLINS 9850, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9851, PCI_CHIP_MULLINS 9851, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9852, PCI_CHIP_MULLINS 9852, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9853, PCI_CHIP_MULLINS 9853, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9854, PCI_CHIP_MULLINS 9854, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9855, PCI_CHIP_MULLINS 9855, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9856, PCI_CHIP_MULLINS 9856, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9857, PCI_CHIP_MULLINS 9857, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9858, PCI_CHIP_MULLINS 9858, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 9859, PCI_CHIP_MULLINS 9859, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 985a, PCI_CHIP_MULLINS 985a, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 985b, PCI_CHIP_MULLINS 985b, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 985c, PCI_CHIP_MULLINS 985c, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 985d, PCI_CHIP_MULLINS 985d, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 985e, PCI_CHIP_MULLINS 985e, RES_SHARED_VGA },
> + { PCI_CHIP_MULLINS 985f, PCI_CHIP_MULLINS 985f, RES_SHARED_VGA },
>   { PCI_CHIP_KAVERI_1304, PCI_CHIP_KAVERI_1304, RES_SHARED_VGA },
>   { PCI_CHIP_KAVERI_1305, PCI_CHIP_KAVERI_1305, RES_SHARED_VGA },
>   { PCI_CHIP_KAVERI_1306, PCI_CHIP_KAVERI_1306, RES_SHARED_VGA },
> diff -aur a/src/amdgpu_pci_device_match_gen.h
> b/src/amdgpu_pci_device_match_gen.h
> --- 

[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)

[Ilia Mirkin]

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 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 final patches targeting v4.8. Changes compared to v2[1]:
>>>>> collected R-b from Hans and Mika and fixed a minor comment style issue.
>>>>>
>>>>> I recommend it to be merged before the pci/pm patches[2], otherwise there 
>>>>> is a
>>>>> window where newer Nvidia Optimus laptops might fail to runtime resume 
>>>>> and/or
>>>>> lock up.  Once the pci/pm branch is merged I will propose another patch to
>>>>> improve reliability[3].
>>>>>
>>>>> Known issue with patch 4: when a Nvidia HDMI audio function is present, 
>>>>> the
>>>>> bridge will not suspend and hence the Nvidia card will still be powered. 
>>>>> Fixing
>>>>
>>>> That's basically all optimus gpu's, right? Anything GT21x+ has a HDMI
>>>> audio subfunction, and prior to that, the nvidia gpu tended to be the
>>>> only gpu, or hard-muxed.
>>>
>>> I'd imagine there is a strap on the asic so the audio function is only
>>> enabled if there is a connector actually wired to the dGPU.  It
>>> doesn't make much sense to expose audio if there is no way to use it.
>>
>> A lot of the time, there actually is a connector wired up. A lot of
>> the other time, there is no connector, but the display unit is still
>> there. Very recently, NVIDIA gpu's have started coming out marked as
>> "3d accelerator", which sometimes but not always means that there's no
>> display unit, and for those, I would assume there is no audio
>> subfunction.
>>
>
> Just because there is a display block, doesn't mean the audio function
> is always enabled.  I suspect it is disabled by hardware straps on
> systems with no display connectors or other specific OEM configs.

That's what I'm saying - it is not. There are straps, and they can be
used to disable the display block. But they're often not set that way.

  -ilia

[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)

[Ilia Mirkin]

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 (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 final patches targeting v4.8. Changes compared to v2[1]:
>> > collected R-b from Hans and Mika and fixed a minor comment style issue.
>> >
>> > I recommend it to be merged before the pci/pm patches[2], otherwise there 
>> > is a
>> > window where newer Nvidia Optimus laptops might fail to runtime resume 
>> > and/or
>> > lock up.  Once the pci/pm branch is merged I will propose another patch to
>> > improve reliability[3].
>> >
>> > Known issue with patch 4: when a Nvidia HDMI audio function is present, the
>> > bridge will not suspend and hence the Nvidia card will still be powered. 
>> > Fixing
>>
>> That's basically all optimus gpu's, right? Anything GT21x+ has a HDMI
>> audio subfunction, and prior to that, the nvidia gpu tended to be the
>> only gpu, or hard-muxed.
>>
>> If that's the case, that's pretty much a non-starter, IMO.
>
> For some reason the audio function tends to disappear/hide, so maybe it
> is not as problematic as it appears (see
> https://bugs.freedesktop.org/show_bug.cgi?id=75985). For my laptop I

I'm aware of that bug. I believe this is an exceedingly rare scenario
or it would have been reported a lot more.

> also had to runtime suspend/resume before lspci -H1 shows the device,
> loading with runpm=0 didn't return my HDMI audio device.

Hm ok. Do you have the same laptop as the reporter of that bug?

>
> The powered on issue will also only appear on devices produced in 2013
> and newer that happen to have this ACPI _PR3 ACPI method (which is quite
> common for new machines supporting Windows 8 though).
>
> For these newer laptops, after the pci/pm merge and after a patch like
> http://www.spinics.net/lists/linux-pci/msg52601.html, the user can
> revert to the old DSM method by booting with pcie_port_pm=off which will
> retain the current behavior.
>
> The advantage of this patch is that it fixes memory corruption on some
> devices. The risk is that the card stays on because the audio subsystem
> needs some more work.  FWIW, I was working on some patches that properly
> suspended in presence of the HDA controller, but somehow the audio
> device was not properly resumed resulting in "no AFG or MFG node found"
> and "snd_hda_intel :01:00.1: no codecs initialized".

Does this restriction (runpm being broken in presence of the audio
subfunction) only affect devices with _PR3? If so, that's a lot more
palatable - I bet Windows 8+ is in an era when the display-less thing
became more popular, and thus less likely to affect a ton of people.

  -ilia

[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)

[Ilia Mirkin]

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 
>>> 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 final patches targeting v4.8. Changes compared to v2[1]:
>>> collected R-b from Hans and Mika and fixed a minor comment style issue.
>>>
>>> I recommend it to be merged before the pci/pm patches[2], otherwise there 
>>> is a
>>> window where newer Nvidia Optimus laptops might fail to runtime resume 
>>> and/or
>>> lock up.  Once the pci/pm branch is merged I will propose another patch to
>>> improve reliability[3].
>>>
>>> Known issue with patch 4: when a Nvidia HDMI audio function is present, the
>>> bridge will not suspend and hence the Nvidia card will still be powered. 
>>> Fixing
>>
>> That's basically all optimus gpu's, right? Anything GT21x+ has a HDMI
>> audio subfunction, and prior to that, the nvidia gpu tended to be the
>> only gpu, or hard-muxed.
>
> I'd imagine there is a strap on the asic so the audio function is only
> enabled if there is a connector actually wired to the dGPU.  It
> doesn't make much sense to expose audio if there is no way to use it.

A lot of the time, there actually is a connector wired up. A lot of
the other time, there is no connector, but the display unit is still
there. Very recently, NVIDIA gpu's have started coming out marked as
"3d accelerator", which sometimes but not always means that there's no
display unit, and for those, I would assume there is no audio
subfunction.

However this is a fraction of all devices using runpm.

  -ilia

[Nouveau] [PATCH v3 0/4] nouveau RPM fixes for Optimus (final)

[Ilia Mirkin]

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 final patches targeting v4.8. Changes compared to v2[1]:
> collected R-b from Hans and Mika and fixed a minor comment style issue.
>
> I recommend it to be merged before the pci/pm patches[2], otherwise there is a
> window where newer Nvidia Optimus laptops might fail to runtime resume and/or
> lock up.  Once the pci/pm branch is merged I will propose another patch to
> improve reliability[3].
>
> Known issue with patch 4: when a Nvidia HDMI audio function is present, the
> bridge will not suspend and hence the Nvidia card will still be powered. 
> Fixing

That's basically all optimus gpu's, right? Anything GT21x+ has a HDMI
audio subfunction, and prior to that, the nvidia gpu tended to be the
only gpu, or hard-muxed.

If that's the case, that's pretty much a non-starter, IMO.

  -ilia

[Nouveau] Should I expect nouveau on 4.6 to work on a GM206?

[Ilia Mirkin]

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 incredibly convenient for the DDX.)

> straightforward way I could try to figure out why GLAMOR was so slow,
> maybe I could fiddle with that a bit.

Upgrade mesa & pray. I think that X11 can end up being pretty
glReadPixels-heavy, which in a UMA system is ~free, but much more
expensive when the FB is in VRAM. Recently some changes were committed
to cache the entire texture in a staging texture if someone does a lot
of readpixels on it. Could help. Or could be totally unrelated.

You could do an apitrace of the X server
(github.com/apitrace/apitrace) and then analyze what all it's doing.

>
> FWIW, my i915-based laptop uses the modesetting driver and GLAMOR as
> well, and it's plenty fast, so I don't think the problem is that
> GLAMOR is inherently terrible at legacy X11 operations.

Different workloads, I suppose. I had to use GLAMOR on a SKL while the
regular ddx was still lacking support for it, and my favorite
screensaver was unbearably slow on it (xlock -mode wator, in case
you're curious). [And regular usage was also not great, but not to the
point of frustration.] It runs plenty fast with the SNA backend
though.

  -ilia

[Nouveau] Should I expect nouveau on 4.6 to work on a GM206?

[Ilia Mirkin]

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, 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:
>>>>
>>>> [ 5383.723240] nouveau :09:00.0: fifo: read fault at 011000
>>>> engine 07 [PBDMA0] client 06 [HOST] reason 00 [PDE] on channel -1
>>>> [007f9ed000 unknown]
>>>> [ 5398.722676] nouveau :09:00.0: systemd-logind[30778]: failed to
>>>> idle channel 2 [systemd-logind[30778]]
>>>> [ 5413.722853] nouveau :09:00.0: systemd-logind[30778]: failed to
>>>> idle channel 2 [systemd-logind[30778]]
>>>>
>>>> and the display output in general is unreliable enough that I'm having
>>>> trouble telling whether the performance is remotely reasonable.
>>>
>>> If you're having trouble telling, that means it's not :) The error you
>>> pasted is quite odd. Was there anything in the log before those
>>> messages? If there's no channel associated, that means that it's the
>>> background copying between vram and sysmem? Not sure.
>>
>> Don't get too excited yet.  In the process of upgrading mesa, I
>> managed to boot 4.5 without noticing.  I'll post back later today with
>> actual valid test results.
>>
>
> I replaced the monitor (turns out that my monitor had a known DP
> problem), and now the screen lights up reliably.  I still get

Great to hear!

> occasional log lines like this:
>
> [Jun26 09:25] nouveau :09:00.0: fifo: FB_FLUSH_TIMEOUT
> [Jun26 09:30] nouveau :09:00.0: fifo: FB_FLUSH_TIMEOUT
> [Jun26 09:32] nouveau :09:00.0: fifo: CHSW_ERROR 0004
> [  +0.000162] nouveau :09:00.0: fifo: CHSW_ERROR 0005

These don't sound good at all!

> [Jun26 09:46] nouveau :09:00.0: disp: outp 04:0006:0f44: link
> training failed
> [  +0.107894] nouveau :09:00.0: disp: outp 04:0006:0f44: link
> training failed

These are surprising if your monitor is working. Usually it means
"couldn't establish link with the monitor". Perhaps something forces
it to retry and it eventually succeeds.

>
> but they aren't causing an obvious problem.
>
>>>
>>> Note that with maxwell we have yet to add EXA support to
>>> xf86-video-nouveau, so you're ending up with GLAMOR (and Ben and I
>>> disagree on whether EXA support should be added in the first place).
>>> There was also an issue that glamor was hitting with nouveau which
>>> appears to have dissipated, either due to a change in nouveau or a
>>> change in glamor. So you might consider upgrading to Xorg 1.18.3 (as
>>> glamor is part of X).
>
> I do have a serious performance issue, though: when I scroll in
> Firefox (default configuration), the whole system drops to ~1fps or
> less and, if I scroll enough (even putting the mouse over a simple
> page like start.fedoraproject.org and flicking the wheel up and down a
> few times), the entire desktop will become unusable for several
> seconds.  I seem to have this problem under X and under Wayland.
>
> For better or for worse, forcing Firefox's layers acceleration on
> fixes the problem and scrolling is fast.
>
> I have no idea whether this is an X problem, a gnome-shell problem, a
> mesa problem, a kernel problem, or something else.

I believe the issue is with GLAMOR, but I'm not sure - in my
experience, GLAMOR is slow as molasses for actual X11 ops that aren't
"take this composited image and stick it on the screen", and the fact
that you are on the lowest perf level of your GPU isn't helping your
cause. Turning on acceleration in firefox probably makes it use more
optimized GL paths than having some X11 -> GL translation layer.

If you're interested, I've a 95% (percentage made up) completed EXA
backend for maxwell, but I don't have the hw, or, to be frank, the
interest in completing it (as a result of NVIDIA's creation of these
locked down, actively anti-open source GPUs). However you're welcome
to hack on it if you like -
https://github.com/imirkin/xf86-video-nouveau/commit/abf0933a236b6069f42f86ad5b0bf5bbab28e0d6
- if you ask in #nouveau on irc.freenode.net, would be happy to talk
about what all needs finishing.

  -ilia

DRM DMA Engine

[Ilia Mirkin]

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 14, 2016 at 1:19 PM, Jose Abreu  
 wrote:
>> I assume that xilinx VDMA is the only way to feed pixel data into your
>> display pipeline. Under that assumption:
>>
>> drm_plane should map to Xilinx VDMA, and the drm_plane->drm_crtc link
>> would represent the dma channel. With atomic you can subclass
>> drm_plane/crtc_state structures to store all the runtime configuration in
>> there.
>>
>> The actual buffer itsel would be represented by a drm_framebuffer, which
>> either wraps a shmem gem or a cma gem object.
>>
>> If you want to know about the callbacks used by the atomic helpers to 
>> push
>> out plane updates, look at the hooks drm_atomic_helper_commit_planes()
>> (and the related functions, see kerneldoc) calls.
>>
>> I hope this helps a bit more.
>> -Daniel
> Thanks a lot! With your help I was able to implement all the
> needed logic. Sorry to bother you but I have one more question.
> Right now I can initialize and configure the vdma correctly but I
> can only send one frame. I guess when the dma completes
> transmission I need to ask drm for a new frame, right? Because
> the commit function starts the vdma correctly but then the dma
> halts waiting for a new descriptor.
 DRM has a continuous scanout model, i.e. when userspace doesn't give
 you a new frame you're supposed to keep scanning out the current one.
 So you need to rearm your upload code with the same drm_framebuffer if
 userspace hasn't supplied a new one since the last time before the
 vblank period starts.

 This is different to v4l, where userspace has to supply each frame
 (and the kernel gets angry when there's not enough frames and signals
 an underrun of the queue). This is because drm is geared at desktops,
 and there it's perfectly normal to show the exact same frame for a
 long time.
 -Daniel
>>> Thanks, I was thinking this was similar to v4l. I am now able to
>>> send multiple frames so it is finally working! I have one little
>>> implementation detail: The controller that I am using supports
>>> deep color mode but I am using FB CMA helpers to create the
>>> framebuffer and I've seen that the supported bpp in these helpers
>>> only goes up to 32, right? Does this means that with these
>>> helpers I can't use deep color? Can I implement this deep color
>>> mode (48bpp) using a custom fb or do I also need custom gem
>>> allocation functions (Right now I am using GEM CMA helpers)?
>> Suprising the cma doesn't take pixel_format into account. If this
>> really doesn't work, pls fix up the cma helpers, not roll your own
>> copypasta ;-)
>>
>> Note that the fbdev emulation itself (maybe that's what threw you off)
>> only supports legacy rgb formats up to 32bits. But native kms can
>> support anything, we just might need to add the DRM_FOURCC codes for
>> that.
>> -Daniel
>
> So, I ended up using 32bits and everything is working fine! I
> tested using [1] and [2] but now I have kind of a dumb question:
> I want to use the new driver that I created as a secondary output
> of my desktop so that I can play videos using mplayer but I am
> not being able to do this. If I check in my linux settings only
> one display is being detected, although in /dev/dri the two video
> cards are present (the native one and the one I added). Does the
> driver needs something additional to do this or is it only in my
> X configuration? I tried editing this configuration but still
> doesn't work. I believe that because my driver is not being
> probed at runtime the display is not being created by X. Is this
> correct?

Have a look at

https://nouveau.freedesktop.org/wiki/Optimus/

specifically the section titled "Using outputs on discrete GPU". If
you're still having trouble, please provide an Xorg log.

[PATCH] amdgpu: fix asic initialization for virtualized environments

[Ilia Mirkin]

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 still consider it to be posted. Therefore, in a
> passthrough based environemnt we should always post the card to guarantee
> it is in a good state for driver initialization.
>
> However, if we are operating in SR-IOV mode it is up to the GIM driver
> to manage the asic state, therefore we should not post the card (and
> shouldn't be able to do it either).
>
> Signed-off-by: Andres Rodriguez 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  7 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 16 +++-
>  drivers/gpu/drm/amd/amdgpu/cik.c   |  7 +++
>  drivers/gpu/drm/amd/amdgpu/vi.c| 15 +++
>  4 files changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 26fe670..fe71dea 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1835,6 +1835,8 @@ struct amdgpu_asic_funcs {
> /* MM block clocks */
> int (*set_uvd_clocks)(struct amdgpu_device *adev, u32 vclk, u32
dclk);
> int (*set_vce_clocks)(struct amdgpu_device *adev, u32 evclk, u32
ecclk);
> +   /* query virtual capabilities */
> +   u32 (*get_virtual_caps)(struct amdgpu_device *adev);
>  };
>
>  /*
> @@ -1932,8 +1934,12 @@ void amdgpu_cgs_destroy_device(struct cgs_device
*cgs_device);
>
>
>  /* GPU virtualization */
> +#define AMDGPU_VIRT_CAPS_SRIOV_EN   (1 << 0)
> +#define AMDGPU_VIRT_CAPS_IS_VF  (1 << 1)
>  struct amdgpu_virtualization {
> bool supports_sr_iov;
> +   bool is_virtual;
> +   u32 caps;
>  };
>
>  /*
> @@ -2226,6 +2232,7 @@ amdgpu_get_sdma_instance(struct amdgpu_ring *ring)
>  #define amdgpu_asic_get_xclk(adev) (adev)->asic_funcs->get_xclk((adev))
>  #define amdgpu_asic_set_uvd_clocks(adev, v, d)
(adev)->asic_funcs->set_uvd_clocks((adev), (v), (d))
>  #define amdgpu_asic_set_vce_clocks(adev, ev, ec)
(adev)->asic_funcs->set_vce_clocks((adev), (ev), (ec))
> +#define amdgpu_asic_get_virtual_caps(adev)
((adev)->asic_funcs->get_virtual_caps((adev)))
>  #define amdgpu_asic_get_gpu_clock_counter(adev)
(adev)->asic_funcs->get_gpu_clock_counter((adev))
>  #define amdgpu_asic_read_disabled_bios(adev)
(adev)->asic_funcs->read_disabled_bios((adev))
>  #define amdgpu_asic_read_bios_from_rom(adev, b, l)
(adev)->asic_funcs->read_bios_from_rom((adev), (b), (l))
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index b494212..629e4e3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1392,6 +1392,14 @@ static int amdgpu_resume(struct amdgpu_device
*adev)
> return 0;
>  }
>
> +static bool amdgpu_device_is_virtual(void)
> +{
> +#ifdef CONFIG_X86
> +   return boot_cpu_has(X86_FEATURE_HYPERVISOR);
> +#else
> +   return false

Missing semicolon here...

> +#endif
> +}
>
>  /**
>   * amdgpu_device_has_dal_support - check if dal is supported
> @@ -1560,8 +1568,14 @@ int amdgpu_device_init(struct amdgpu_device *adev,
> adev->virtualization.supports_sr_iov =
> amdgpu_atombios_has_gpu_virtualization_table(adev);
>
> +   /* Check if we are executing in a virtualized environment */
> +   adev->virtualization.is_virtual = amdgpu_device_is_virtual();
> +   adev->virtualization.caps = amdgpu_asic_get_virtual_caps(adev);
> +
> /* Post card if necessary */
> -   if (!amdgpu_card_posted(adev)) {
> +   if (!amdgpu_card_posted(adev) ||
> +   (adev->virtualization.is_virtual &&
> +!adev->virtualization.caps & AMDGPU_VIRT_CAPS_SRIOV_EN)) {
> if (!adev->bios) {
> dev_err(adev->dev, "Card not posted and no BIOS -
ignoring\n");
> return -EINVAL;
> diff --git a/drivers/gpu/drm/amd/amdgpu/cik.c
b/drivers/gpu/drm/amd/amdgpu/cik.c
> index 40f4fda..907bb28 100644
> --- a/drivers/gpu/drm/amd/amdgpu/cik.c
> +++ b/drivers/gpu/drm/amd/amdgpu/cik.c
> @@ -963,6 +963,12 @@ static bool cik_read_bios_from_rom(struct
amdgpu_device *adev,
> return true;
>  }
>
> +static u32 cik_get_virtual_caps(struct amdgpu_device *adev)
> +{
> +   /* CIK does not support SR-IOV */
> +   return 0;
> +}
> +
>  static const struct amdgpu_allowed_register_entry
cik_allowed_read_registers[] = {
> {mmGRBM_STATUS, false},
> {mmGB_ADDR_CONFIG, false},
> @@ -2176,6 +2182,7 @@ static const struct amdgpu_asic_funcs
cik_asic_funcs =
> .get_xclk = _get_xclk,
> .set_uvd_clocks = _set_uvd_clocks,
> .set_vce_clocks = _set_vce_clocks,
> +   .get_virtual_caps = 

[Nouveau] Should I expect nouveau on 4.6 to work on a GM206?

[Ilia Mirkin]

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:
>
> [ 5383.723240] nouveau :09:00.0: fifo: read fault at 011000
> engine 07 [PBDMA0] client 06 [HOST] reason 00 [PDE] on channel -1
> [007f9ed000 unknown]
> [ 5398.722676] nouveau :09:00.0: systemd-logind[30778]: failed to
> idle channel 2 [systemd-logind[30778]]
> [ 5413.722853] nouveau :09:00.0: systemd-logind[30778]: failed to
> idle channel 2 [systemd-logind[30778]]
>
> and the display output in general is unreliable enough that I'm having
> trouble telling whether the performance is remotely reasonable.

If you're having trouble telling, that means it's not :) The error you
pasted is quite odd. Was there anything in the log before those
messages? If there's no channel associated, that means that it's the
background copying between vram and sysmem? Not sure.

Note that with maxwell we have yet to add EXA support to
xf86-video-nouveau, so you're ending up with GLAMOR (and Ben and I
disagree on whether EXA support should be added in the first place).
There was also an issue that glamor was hitting with nouveau which
appears to have dissipated, either due to a change in nouveau or a
change in glamor. So you might consider upgrading to Xorg 1.18.3 (as
glamor is part of X).

FWIW a few other people have been using GM20x without incident, but
this can all be very sensitive to your desktop/etc. Lots of things
like to use GL nowadays - I stick to a more classic desktop - no
compositor, simple window manager, etc.

  -ilia

[Nouveau] Should I expect nouveau on 4.6 to work on a GM206?

[Ilia Mirkin]

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 screen at something like one frame per ten seconds.  But then
> I got all kinds of garbage, and I see:
>
> [  719.300820] nouveau :09:00.0: disp: outp 04:0006:0f44: link
> training failed
>
> dmesg |grep nouveau says:
>
> [   10.053162] fb: switching to nouveaufb from EFI VGA
> [   10.053349] nouveau :09:00.0: NVIDIA GM206 (126010a1)
> [   10.174033] nouveau :09:00.0: bios: version 84.06.0d.00.01
> [   10.174854] nouveau :09:00.0: disp: dcb 15 type 8 unknown
> [   10.178375] nouveau :09:00.0: fb: 2048 MiB GDDR5
> [   10.202108] nouveau :09:00.0: DRM: VRAM: 2048 MiB
> [   10.202109] nouveau :09:00.0: DRM: GART: 1048576 MiB
> [   10.202113] nouveau :09:00.0: DRM: TMDS table version 2.0
> [   10.202114] nouveau :09:00.0: DRM: DCB version 4.1
> [   10.202116] nouveau :09:00.0: DRM: DCB outp 00: 01000f02 00020030
> [   10.202117] nouveau :09:00.0: DRM: DCB outp 01: 02000f00 
> [   10.202118] nouveau :09:00.0: DRM: DCB outp 02: 02811f76 04400020
> [   10.202120] nouveau :09:00.0: DRM: DCB outp 03: 02011f72 00020020
> [   10.202121] nouveau :09:00.0: DRM: DCB outp 04: 04822f86 04400010
> [   10.202122] nouveau :09:00.0: DRM: DCB outp 05: 04022f82 00020010
> [   10.202123] nouveau :09:00.0: DRM: DCB outp 06: 04833f96 04400020
> [   10.202124] nouveau :09:00.0: DRM: DCB outp 07: 04033f92 00020020
> [   10.202125] nouveau :09:00.0: DRM: DCB outp 08: 02044f62 00020010
> [   10.202126] nouveau :09:00.0: DRM: DCB outp 15: 01df5ff8 
> [   10.202127] nouveau :09:00.0: DRM: DCB conn 00: 1030
> [   10.202128] nouveau :09:00.0: DRM: DCB conn 01: 00020146
> [   10.202129] nouveau :09:00.0: DRM: DCB conn 02: 01000246
> [   10.202130] nouveau :09:00.0: DRM: DCB conn 03: 02000346
> [   10.202131] nouveau :09:00.0: DRM: DCB conn 04: 00010461
> [   10.202132] nouveau :09:00.0: DRM: DCB conn 05: 0570
> [   10.202134] nouveau :09:00.0: DRM: Pointer to flat panel table invalid
> [   10.214683] nouveau :09:00.0: DRM: unknown connector type 70
> [   10.214728] nouveau :09:00.0: DRM: failed to create encoder 1/8/0: -19
> [   10.214730] nouveau :09:00.0: DRM: Unknown-1 has no encoders, removing
> [   10.369691] nouveau :09:00.0: DRM: MM: using COPY for buffer copies
> [   10.478561] nouveau :09:00.0: priv: GPC0: 419df4  (1e40820e)
> [   10.478578] nouveau :09:00.0: priv: GPC1: 419df4  (1e40820e)
> [   10.607100] nouveau :09:00.0: DRM: allocated 3840x2160 fb:
> 0x6, bo 88044aad7400
> [   10.607276] fbcon: nouveaufb (fb0) is primary device
> [   10.607576] nouveau :09:00.0: fb0: nouveaufb frame buffer device
> [   10.617064] [drm] Initialized nouveau 1.3.1 20120801 for
> :09:00.0 on minor 0
> [  719.282184] nouveau :09:00.0: disp: outp 04:0006:0f44: link
> training failed
> [  719.300820] nouveau :09:00.0: disp: outp 04:0006:0f44: link
> training failed
>
>
>
> Thanks,
> Andy
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau

[PATCH 2/3] drm: Add DP port types from DP 1.3 specification

[Ilia Mirkin]

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/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 92d9a52..9a15099 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -210,6 +210,8 @@
>  # define DP_DS_PORT_TYPE_DVI   2
>  # define DP_DS_PORT_TYPE_HDMI  3
>  # define DP_DS_PORT_TYPE_NON_EDID  4
> +# define DP_DP_PORT_TYPE_DP_DUALMODE5

DP_DS right? (Like all the others)

> +# define DP_DS_PORT_TYPE_WIRELESS   6
>  # define DP_DS_PORT_HPD(1 << 3)
>  /* offset 1 for VGA is maximum megapixels per second / 8 */
>  /* offset 2 */
> --
> 1.9.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
An HTML attachment was scrubbed...
URL: 

[Nouveau] [PATCH 1/2] nouveau/bl: Assign different names to interfaces

[Ilia Mirkin]

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_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 initial name as nv_backlight, to avoid possibly breaking userspace; the
>> > second interface will be named nv_backlight1, and so on.
>> >
>> > Fixes: fdo#86539
>> > Signed-off-by: Pierre Moreau 
>> > ---
>> >  drm/nouveau/nouveau_backlight.c | 35 +--
>> >  1 file changed, 33 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drm/nouveau/nouveau_backlight.c 
>> > b/drm/nouveau/nouveau_backlight.c
>> > index 89eb460..914e2cb 100644
>> > --- a/drm/nouveau/nouveau_backlight.c
>> > +++ b/drm/nouveau/nouveau_backlight.c
>> > @@ -36,6 +36,10 @@
>> >  #include "nouveau_reg.h"
>> >  #include "nouveau_encoder.h"
>> >
>> > +static atomic_t bl_interfaces_nb = { 0 };
>>
>> static data is initialized to 0, this should be unnecessary.
>
> I didn’t know that. But on the other hand, I like having it explicit, and it
> should not add any overhead.

It increases the size of the object file. I believe it's kernel policy
to avoid static initializations to 0. (Note that this doesn't hold in
regular user applications, just the kernel.)

  -ilia

[Nouveau] [PATCH 1/2] nouveau/bl: Assign different names to interfaces

[Ilia Mirkin]

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 initial name as nv_backlight, to avoid possibly breaking userspace; the
> second interface will be named nv_backlight1, and so on.
>
> Fixes: fdo#86539
> Signed-off-by: Pierre Moreau 
> ---
>  drm/nouveau/nouveau_backlight.c | 35 +--
>  1 file changed, 33 insertions(+), 2 deletions(-)
>
> diff --git a/drm/nouveau/nouveau_backlight.c b/drm/nouveau/nouveau_backlight.c
> index 89eb460..914e2cb 100644
> --- a/drm/nouveau/nouveau_backlight.c
> +++ b/drm/nouveau/nouveau_backlight.c
> @@ -36,6 +36,10 @@
>  #include "nouveau_reg.h"
>  #include "nouveau_encoder.h"
>
> +static atomic_t bl_interfaces_nb = { 0 };

static data is initialized to 0, this should be unnecessary.

I'd also call it "backlights" or something like that. No need for
multiple words...

> +
> +static char* nouveau_get_backlight_name(void);

Please organize the code to avoid forward declarations.

> +
>  static int
>  nv40_get_intensity(struct backlight_device *bd)
>  {
> @@ -74,6 +78,7 @@ nv40_backlight_init(struct drm_connector *connector)
> struct nvif_object *device = >device.object;
> struct backlight_properties props;
> struct backlight_device *bd;
> +   char* backlight_name = NULL;
>
> if (!(nvif_rd32(device, NV40_PMC_BACKLIGHT) & 
> NV40_PMC_BACKLIGHT_MASK))
> return 0;
> @@ -81,8 +86,14 @@ nv40_backlight_init(struct drm_connector *connector)
> memset(, 0, sizeof(struct backlight_properties));
> props.type = BACKLIGHT_RAW;
> props.max_brightness = 31;
> -   bd = backlight_device_register("nv_backlight", connector->kdev, drm,
> +   backlight_name = nouveau_get_backlight_name();
> +   bd = backlight_device_register(backlight_name , connector->kdev, drm,
>_bl_ops, );
> +
> +   // backlight_device_register() makes a copy
> +   kfree(backlight_name);
> +   backlight_name = NULL;
> +
> if (IS_ERR(bd))
> return PTR_ERR(bd);
> drm->backlight = bd;
> @@ -182,6 +193,7 @@ nv50_backlight_init(struct drm_connector *connector)
> struct backlight_properties props;
> struct backlight_device *bd;
> const struct backlight_ops *ops;
> +   char* backlight_name = NULL;
>
> nv_encoder = find_encoder(connector, DCB_OUTPUT_LVDS);
> if (!nv_encoder) {
> @@ -203,8 +215,14 @@ nv50_backlight_init(struct drm_connector *connector)
> memset(, 0, sizeof(struct backlight_properties));
> props.type = BACKLIGHT_RAW;
> props.max_brightness = 100;
> -   bd = backlight_device_register("nv_backlight", connector->kdev,
> +   backlight_name = nouveau_get_backlight_name();
> +   bd = backlight_device_register(backlight_name, connector->kdev,
>nv_encoder, ops, );
> +
> +   // backlight_device_register() makes a copy
> +   kfree(backlight_name);
> +   backlight_name = NULL;
> +
> if (IS_ERR(bd))
> return PTR_ERR(bd);
>
> @@ -252,3 +270,16 @@ nouveau_backlight_exit(struct drm_device *dev)
> drm->backlight = NULL;
> }
>  }
> +
> +static char*
> +nouveau_get_backlight_name(void)
> +{
> +   // 12 chars for "nv_backlight" + 2 for two digits number + 1 for '\0'
> +   char* backlight_name = (char*)kmalloc(sizeof(char[15]), GFP_KERNEL);

Making this stack-allocated in the caller would be so much simpler...

> +   const int nb = atomic_inc_return(_interfaces_nb) - 1;

This kinda sucks if you reload nouveau a bunch. How about using an
"ida". Have a look in drivers/gpu/drm/drm_crtc.c for how I use that
one.

> +   if (nb > 0 && nb < 100)
> +   sprintf(backlight_name, "nv_backlight%d", nb);
> +   else
> +   sprintf(backlight_name, "nv_backlight");
> +   return backlight_name;
> +}
> --
> 2.8.0
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau

Nouveau crashes in 4.6-rc on arm64

[Ilia Mirkin]

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(). My setup is an old XFX 7600GT card plugged
>> into an ARM Juno r1 board, which works fine with 4.5 and earlier.
>>
>> Attached are a couple of logs from booting arm64 defconfig plus DRM and
>> Nouveau enabled - the second also has framebuffer console rotation
>> turned on, which interestingly seems to move the point of failure, and
>> the display does eventually come up to show the tail end of the panic in
>> that case.
>>
>> I might be able to find time for a full bisection next week if isn't
>> something sufficiently obvious to anyone who knows this driver.
>
>
> Looking at the log it is not clear to me what could be causing this. I can
> boot 4.6-rc2 with a GM206 card without any issue. A bisect would indeed be
> useful here.

Presumably not on an arm64 board though. This is happening in the
memcpy done somewhere in fbcon, when doing an OUT_RINGp if the
backtrace is to be believed. This means that the fifo is somehow not
writable, or not set, or ... something. Also note that it's a G73 (aka
pre-G80), so very different paths being taken through the driver.

  -ilia

[PATCH] drm: Make drm.h uapi header safe for C++

[Ilia Mirkin]

On Wed, Mar 30, 2016 at 9:47 AM, Daniel Vetter  
wrote:
> virtual is a protected keyword in C++ and can't be used at all. Ugh.
>
> This aligns the kernel versions of the drm headers with the ones in
> libdrm.
>
> Cc: Emil Velikov 
> Signed-off-by: Daniel Vetter 
> ---
>  include/uapi/drm/drm.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index a0ebfe7c9a28..d299c7749091 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -373,7 +373,11 @@ struct drm_buf_pub {
>   */
>  struct drm_buf_map {
> int count;  /**< Length of the buffer list */
> +#ifdef __cplusplus
> +   void *virt;

Shouldn't this also be __user for consistency? (I realize it'll never
play since the kernel doesn't get built with C++...)

> +#else
> void __user *virtual;   /**< Mmap'd area in user-virtual */
> +#endif
> struct drm_buf_pub __user *list;/**< Buffer information */
>  };
>
> --
> 2.8.0.rc3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] nouveau: need to handle failed allocation

[Ilia Mirkin]

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/drm/nouveau/nouveau_display.c 
> b/drivers/gpu/drm/nouveau/nouveau_display.c
> index 24be27d..26b4902 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_display.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_display.c
> @@ -443,6 +443,12 @@ nouveau_display_create_properties(struct drm_device *dev)
> /* -100..+100 */
> disp->color_vibrance_property =
> drm_property_create_range(dev, 0, "color vibrance", 0, 200);
> +
> +   if (!disp->underscan_hborder_property ||
> +   !disp->underscan_vborder_property ||
> +   !disp->vibrant_hue_property ||
> +   !disp->color_vibrance_property)
> +   return;

Aren't we at the end of the function anyways?

>  }
>
>  int
> --
> 1.9.1
>

Trying nouveau reclocking

[Ilia Mirkin]

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 new with 4.5-rc1, or
is this the first time you've tried reclocking this chip?

  -ilia


On Wed, Jan 27, 2016 at 6:59 AM, Boszormenyi Zoltan  wrote:
> Hi,
>
> I was trying to use re-clocking with nouveau in 4.5.0-rc1 with:
>
> # echo "0f" >/sys/kernel/debug/dri/0/pstate
>
> while Chromium with a WebGL app already running. (www.playmapscube.com)
>
> The video chip in question is:
>
> 03:00.0 VGA compatible controller: NVIDIA Corporation GT218 [ION] (rev a2)
>
> or in numbers:
>
> 03:00.0 0300: 10de:0a64 (rev a2)
>
> It is an integrated chip on the mainboard.
>
> The result was:
>
> [   77.531009] [ cut here ]
> [   77.531009] WARNING: CPU: 3 PID: 405 at
> drivers/gpu/drm/nouveau/nvkm/subdev/mc/base.c:51 nvkm_mc_intr+0x102/0x110 
> [nouveau]()
> [   77.531009] Modules linked in: tun ums_realtek uas usb_storage joydev 
> input_leds
> hid_generic usbhid hid cdc_acm snd_hda_codec_hdmi nouveau arc4 mxm_wmi wmi 
> ath9k
> i2c_algo_bit iTCO_wdt drm_kms_helper iTCO_vendor_support gpio_ich ath9k_common
> snd_hda_codec_realtek ttm snd_hda_codec_generic ath9k_hw drm snd_hda_intel ath
> snd_hda_codec mac80211 snd_hwdep syscopyarea lpc_ich snd_hda_core sysfillrect 
> mfd_core
> sysimgblt fb_sys_fops coretemp snd_pcm serio_raw i2c_i801 xhci_pci pcspkr 
> xhci_hcd
> cfg80211 r8169 snd_timer i2c_core snd mii ehci_pci uhci_hcd rfkill ehci_hcd 
> soundcore
> acpi_cpufreq xt_limit xt_multiport xt_recent ip6table_filter xt_conntrack 
> ip6table_nat
> iptable_nat nf_conntrack_ipv6 nf_nat_ipv4 nf_defrag_ipv6 nf_conntrack_ipv4 
> nf_nat_ipv6
> nf_defrag_ipv4 nf_nat xt_connmark nf_conntrack ip6_tables
> [   77.531009]  iptable_mangle
> [   77.531009] CPU: 3 PID: 405 Comm: Xorg.bin Not tainted 4.5.0-rc1 #1
> [   77.531009] Hardware name: To Be Filled By O.E.M. To Be Filled By 
> O.E.M./To Be Filled
> By O.E.M., BIOS 080016  05/05/2011
> [   77.531009]  a053b6f0 88007fd83cd8 80761604 
> 
> [   77.531009]  88007fd83d10 8048e7a2 88007c0ef480 
> 880037838840
> [   77.531009]  88007a4b3800  a04fa9a0 
> 88007fd83d20
> [   77.531009] Call Trace:
> [   77.531009][] dump_stack+0x44/0x60
> [   77.531009]  [] warn_slowpath_common+0x82/0xc0
> [   77.531009]  [] warn_slowpath_null+0x1a/0x20
> [   77.531009]  [] nvkm_mc_intr+0x102/0x110 [nouveau]
> [   77.531009]  [] nvkm_pci_intr+0x44/0x70 [nouveau]
> [   77.531009]  [] handle_irq_event_percpu+0x75/0x180
> [   77.531009]  [] handle_irq_event+0x3b/0x60
> [   77.531009]  [] handle_edge_irq+0x74/0x130
> [   77.531009]  [] handle_irq+0x1a/0x30
> [   77.531009]  [] do_IRQ+0x4b/0xd0
> [   77.531009]  [] common_interrupt+0x82/0x82
> [   77.531009]  [] ? __do_softirq+0x7b/0x260
> [   77.531009]  [] irq_exit+0xb1/0xc0
> [   77.531009]  [] smp_apic_timer_interrupt+0x42/0x50
> [   77.531009]  [] apic_timer_interrupt+0x82/0x90
> [   77.531009][] ? nouveau_fence_emit+0xf1/0x1a0 
> [nouveau]
> [   77.531009]  [] ? nouveau_fence_emit+0x13f/0x1a0 
> [nouveau]
> [   77.531009]  [] nouveau_fence_new+0x59/0xa0 [nouveau]
> [   77.531009]  [] nouveau_gem_ioctl_pushbuf+0xeb5/0x1730 
> [nouveau]
> [   77.531009]  [] drm_ioctl+0x152/0x540 [drm]
> [   77.531009]  [] ? nouveau_gem_ioctl_new+0x1c0/0x1c0 
> [nouveau]
> [   77.531009]  [] ? fpu__activate_curr+0x15/0x20
> [   77.531009]  [] nouveau_drm_ioctl+0x68/0xc0 [nouveau]
> [   77.531009]  [] do_vfs_ioctl+0x92/0x580
> [   77.531009]  [] ? security_file_ioctl+0x43/0x60
> [   77.531009]  [] SyS_ioctl+0x79/0x90
> [   77.531009]  [] entry_SYSCALL_64_fastpath+0x16/0x75
> [   77.531009] ---[ end trace 4a0b55289f0a358e ]---
> [   78.561529] nouveau :03:00.0: timeout at
> drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:332/gt215_clk_pre()!
> [   90.693743] nouveau :03:00.0: gr: PGRAPH TLB flush idle timeout fail
> [   90.693743] nouveau :03:00.0: gr: PGRAPH_STATUS 01dffe03 [BUSY 
> DISPATCH VFETCH
> CCACHE_PREGEOM STRMOUT_VATTR_POSTGEOM VCLIP RATTR_APLANE TRAST CLIPID ZCULL 
> ENG2D RMASK
> TPC_RAST TPC_PROP
> ]
> [   90.693743] nouveau :03:00.0: gr: PGRAPH_VSTATUS0: 00145b49 [VFETCH 
> CCACHE]
> [   90.693743] nouveau :03:00.0: gr: PGRAPH_VSTATUS1: 1a2d [TPC_MP]
> [   90.693743] nouveau :03:00.0: gr: PGRAPH_VSTATUS2: 0034db43 [ENG2D ROP]
> [   93.001694] nouveau :03:00.0: gr: PGRAPH TLB flush idle timeout fail
> [   93.001694] nouveau :03:00.0: gr: PGRAPH_STATUS 01dffe03 [BUSY 
> DISPATCH VFETCH
> CCACHE_PREGEOM STRMOUT_VATTR_POSTGEOM VCLIP RATTR_APLANE TRAST CLIPID ZCULL 
> ENG2D RMASK
> TPC_RAST TPC_PROP
> ]
> [   93.001694] nouveau :03:00.0: gr: PGRAPH_VSTATUS0: 00145b49 [VFETCH 
> CCACHE]
> [   93.001694] nouveau 

[PATCH 3/3] vc4: Add headers and .pc files for VC4 userspace development.

[Ilia Mirkin]

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.
>
> Signed-off-by: Eric Anholt 
> ---
> --- /dev/null
> +++ b/vc4/libdrm_vc4.pc.in
> @@ -0,0 +1,11 @@
> +prefix=@prefix@
> +exec_prefix=@exec_prefix@
> +libdir=@libdir@
> +includedir=@includedir@
> +
> +Name: libdrm_vc4
> +Description: Userspace interface to vc4 kernel DRM services
> +Version: @PACKAGE_VERSION@
> +Requires: libdrm
> +Libs: -L${libdir} -ldrm_intel

This probably wants to be -ldrm_vc4? Or nothing if there's no such lib yet?

> +Cflags: -I${includedir} -I${includedir}/libdrm

[PATCH] configure.ac: disable annoying warning -Wmissing-field-initializers

[Ilia Mirkin]

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, Jan 22, 2016 at 6:13 PM, Emil Velikov > >> gmail.com> wrote:
>> >>> On 21 January 2016 at 16:58, Marek Olšák  wrote:
>> >>>> On Thu, Jan 21, 2016 at 2:09 PM, Emil Velikov > >>>> gmail.com> wrote:
>> >>>>> On 21 January 2016 at 12:08, Marek Olšák  wrote:
>> >>>>>> On Thu, Jan 21, 2016 at 11:51 AM, Emil Velikov > >>>>>> gmail.com> wrote:
>> >>>>>>> On 18 January 2016 at 22:53, Marek Olšák  
>> >>>>>>> wrote:
>> >>>>>>>> Try explaining that to people who have a compulsion to fix them or
>> >>>>>>>> argue about them. :) Ignore? REALLY? IGNORE???
>> >>>>>>>>
>> >>>>>>> Now that we have a few people off your back can you please point out
>> >>>>>>> where this triggers warnings ?
>> >>>>>>
>> >>>>>> This particular warning is trigged by {}
>> >>>>> As mentioned previously neither {} nor {0} trigger any warning here.
>> >>>>> Jani hinted that you might be using an old (buggy?) compiler which
>> >>>>> generates them.
>> >>>>> Which version of GCC are you using ? Do you mind showing the first few
>> >>>>> warnings ?
>> >>>>>
>> >>>>>> or any { ... } which doesn't
>> >>>>>> initialize all members.
>> >>>>>>
>> >>>>> Do we have any outside of intel_decode.c ? I'm failing to spot any.
>> >>>>
>> >>>> amdgpu_bo.c has 7 occurences of "= {}" and they all print the warning.
>> >>> With 200+ cases of memset and 40+ of "= *{ *0 *}". Any objections if I
>> >>> send a patch to transition to either one of these two ?
>> >>
>> >> That's up to you, but please note that I don't plan to stop using "= {}",
>> >> because it's the most convenient way to clear memory in a lot of
>> >> cases and takes only 4 bytes of text.
>> >
>> > I like {} too and think we should encourage that. I'd rather
>> > transition the { 0 } stuff over to {}.
>> >
>> So people feel against seeing/writing single extra character 0,
>> despite that the warning has helped catch actual bug ?
>> And now are willing to transitions 40+ cases as opposed to ~15... that
>> feels strange to say the least.
>
> Does the '= { 0 }' thing even work if the first member happens to be
> something other than an integer?

No. That's why I like {}. Otherwise you end up doing {{0}.

  -ilia

[PATCH] configure.ac: disable annoying warning -Wmissing-field-initializers

[Ilia Mirkin]

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 Thu, Jan 21, 2016 at 11:51 AM, Emil Velikov  gmail.com> wrote:
>> On 18 January 2016 at 22:53, Marek Olšák  wrote:
>>> Try explaining that to people who have a compulsion to fix them or
>>> argue about them. :) Ignore? REALLY? IGNORE???
>>>
>> Now that we have a few people off your back can you please point out
>> where this triggers warnings ?
>
> This particular warning is trigged by {}
 As mentioned previously neither {} nor {0} trigger any warning here.
 Jani hinted that you might be using an old (buggy?) compiler which
 generates them.
 Which version of GCC are you using ? Do you mind showing the first few
 warnings ?

> or any { ... } which doesn't
> initialize all members.
>
 Do we have any outside of intel_decode.c ? I'm failing to spot any.
>>>
>>> amdgpu_bo.c has 7 occurences of "= {}" and they all print the warning.
>> With 200+ cases of memset and 40+ of "= *{ *0 *}". Any objections if I
>> send a patch to transition to either one of these two ?
>
> That's up to you, but please note that I don't plan to stop using "= {}",
> because it's the most convenient way to clear memory in a lot of
> cases and takes only 4 bytes of text.

I like {} too and think we should encourage that. I'd rather
transition the { 0 } stuff over to {}.

  -ilia

[PATCH 1/2] etnaviv: add gpu param for number of varyings

[Ilia Mirkin]

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 needs to validate the returned values as it can be 0
>>> like on the imx6q.
>>>
>>> Signed-off-by: Christian Gmeiner 
>>> ---
>>>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c  | 11 +-
>>>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h  |  3 +++
>>>  drivers/gpu/drm/etnaviv/state_hi.xml.h | 37 
>>> --
>>>  include/uapi/drm/etnaviv_drm.h |  1 +
>>>  4 files changed, 49 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
>>> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>>> index 056a72e..e4f6008 100644
>>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
>>> @@ -112,6 +112,10 @@ int etnaviv_gpu_get_param(struct etnaviv_gpu *gpu, u32 
>>> param, u64 *value)
>>> *value = gpu->identity.num_constants;
>>> break;
>>>
>>> +   case ETNAVIV_PARAM_GPU_NUM_VARYINGS:
>>> +   *value = gpu->identity.num_varyings;
>>> +   break;
>>> +
>>> default:
>>> DBG("%s: invalid param: %u", dev_name(gpu->dev), param);
>>> return -EINVAL;
>>> @@ -124,10 +128,11 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
>>>  {
>>> if (gpu->identity.minor_features0 &
>>> chipMinorFeatures0_MORE_MINOR_FEATURES) {
>>> -   u32 specs[2];
>>> +   u32 specs[3];
>>>
>>> specs[0] = gpu_read(gpu, VIVS_HI_CHIP_SPECS);
>>> specs[1] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_2);
>>> +   specs[2] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_3);
>>>
>>> gpu->identity.stream_count =
>>> (specs[0] & VIVS_HI_CHIP_SPECS_STREAM_COUNT__MASK)
>>> @@ -160,6 +165,10 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
>>> gpu->identity.num_constants =
>>> (specs[1] & 
>>> VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__MASK)
>>> >> 
>>> VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__SHIFT;
>>> +
>>> +   gpu->identity.num_varyings =
>>> +   (specs[2] & 
>>> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK)
>>> +   >> 
>>> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT;
>>> }
>>>
>>> /* Fill in the stream count if not specified */
>>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h 
>>> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
>>> index c75d503..259012d 100644
>>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
>>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
>>> @@ -75,6 +75,9 @@ struct etnaviv_chip_identity {
>>>
>>> /* Buffer size */
>>> u32 buffer_size;
>>> +
>>> +   /* varyings count */
>>> +   u32 num_varyings;
>>>  };
>>>
>>>  struct etnaviv_event {
>>> diff --git a/drivers/gpu/drm/etnaviv/state_hi.xml.h 
>>> b/drivers/gpu/drm/etnaviv/state_hi.xml.h
>>> index 0064f26..2dc7aa2 100644
>>> --- a/drivers/gpu/drm/etnaviv/state_hi.xml.h
>>> +++ b/drivers/gpu/drm/etnaviv/state_hi.xml.h
>>> @@ -8,8 +8,12 @@ http://0x04.net/cgit/index.cgi/rules-ng-ng
>>>  git clone git://0x04.net/rules-ng-ng
>>>
>>>  The rules-ng-ng source files this header was generated from are:
>>> -- state_hi.xml (  23420 bytes, from 2015-03-25 11:47:21)
>>> -- common.xml   (  18437 bytes, from 2015-03-25 11:27:41)
>>> +- state.xml(  18940 bytes, from 2015-12-12 08:59:16)
>>> +- common.xml   (  18379 bytes, from 2014-07-14 14:44:55)
>>> +- state_hi.xml (  24309 bytes, from 2015-12-12 09:02:53)
>>> +- state_2d.xml (  51520 bytes, from 2015-12-12 08:59:16)
>>> +- state_3d.xml (  54570 bytes, from 2014-07-14 14:44:55)
>>> +- state_vg.xml (   5942 bytes, from 2014-07-14 14:44:55)
>>
>> You guys should agree on a way of running headergen so that you don't
>> keep adding/removing files here...
>>
>
> I have taken the updated file from https://github.com/etnaviv/etna_viv .

I just mean that it was originally just generated for state_hi.xml,
while you have it with each file in there. It has to do with how you
run the headergen command. That's what I'm suggesting you standardize
on, so that you don't add state_2d/3d/vg and then the next commit
removes them, and then the next commit adds them, etc.

  -ilia

[PATCH 1/2] etnaviv: add gpu param for number of varyings

[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 needs to validate the returned values as it can be 0
> like on the imx6q.
>
> Signed-off-by: Christian Gmeiner 
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.c  | 11 +-
>  drivers/gpu/drm/etnaviv/etnaviv_gpu.h  |  3 +++
>  drivers/gpu/drm/etnaviv/state_hi.xml.h | 37 
> --
>  include/uapi/drm/etnaviv_drm.h |  1 +
>  4 files changed, 49 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 056a72e..e4f6008 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -112,6 +112,10 @@ int etnaviv_gpu_get_param(struct etnaviv_gpu *gpu, u32 
> param, u64 *value)
> *value = gpu->identity.num_constants;
> break;
>
> +   case ETNAVIV_PARAM_GPU_NUM_VARYINGS:
> +   *value = gpu->identity.num_varyings;
> +   break;
> +
> default:
> DBG("%s: invalid param: %u", dev_name(gpu->dev), param);
> return -EINVAL;
> @@ -124,10 +128,11 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
>  {
> if (gpu->identity.minor_features0 &
> chipMinorFeatures0_MORE_MINOR_FEATURES) {
> -   u32 specs[2];
> +   u32 specs[3];
>
> specs[0] = gpu_read(gpu, VIVS_HI_CHIP_SPECS);
> specs[1] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_2);
> +   specs[2] = gpu_read(gpu, VIVS_HI_CHIP_SPECS_3);
>
> gpu->identity.stream_count =
> (specs[0] & VIVS_HI_CHIP_SPECS_STREAM_COUNT__MASK)
> @@ -160,6 +165,10 @@ static void etnaviv_hw_specs(struct etnaviv_gpu *gpu)
> gpu->identity.num_constants =
> (specs[1] & VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__MASK)
> >> VIVS_HI_CHIP_SPECS_2_NUM_CONSTANTS__SHIFT;
> +
> +   gpu->identity.num_varyings =
> +   (specs[2] & VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK)
> +   >> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT;
> }
>
> /* Fill in the stream count if not specified */
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h 
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> index c75d503..259012d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> @@ -75,6 +75,9 @@ struct etnaviv_chip_identity {
>
> /* Buffer size */
> u32 buffer_size;
> +
> +   /* varyings count */
> +   u32 num_varyings;
>  };
>
>  struct etnaviv_event {
> diff --git a/drivers/gpu/drm/etnaviv/state_hi.xml.h 
> b/drivers/gpu/drm/etnaviv/state_hi.xml.h
> index 0064f26..2dc7aa2 100644
> --- a/drivers/gpu/drm/etnaviv/state_hi.xml.h
> +++ b/drivers/gpu/drm/etnaviv/state_hi.xml.h
> @@ -8,8 +8,12 @@ http://0x04.net/cgit/index.cgi/rules-ng-ng
>  git clone git://0x04.net/rules-ng-ng
>
>  The rules-ng-ng source files this header was generated from are:
> -- state_hi.xml (  23420 bytes, from 2015-03-25 11:47:21)
> -- common.xml   (  18437 bytes, from 2015-03-25 11:27:41)
> +- state.xml(  18940 bytes, from 2015-12-12 08:59:16)
> +- common.xml   (  18379 bytes, from 2014-07-14 14:44:55)
> +- state_hi.xml (  24309 bytes, from 2015-12-12 09:02:53)
> +- state_2d.xml (  51520 bytes, from 2015-12-12 08:59:16)
> +- state_3d.xml (  54570 bytes, from 2014-07-14 14:44:55)
> +- state_vg.xml (   5942 bytes, from 2014-07-14 14:44:55)

You guys should agree on a way of running headergen so that you don't
keep adding/removing files here...

>
>  Copyright (C) 2015
>  */
> @@ -182,8 +186,25 @@ Copyright (C) 2015
>
>  #define VIVS_HI_CHIP_MINOR_FEATURE_3   0x0088
>
> +#define VIVS_HI_CHIP_SPECS_3   0x008c
> +#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK  0x01f0
> +#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT 4
> +#define VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT(x) (((x) << 
> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__SHIFT) & 
> VIVS_HI_CHIP_SPECS_3_VARYINGS_COUNT__MASK)
> +#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__MASK  0x0007
> +#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__SHIFT 0
> +#define VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT(x) (((x) << 
> VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__SHIFT) & 
> VIVS_HI_CHIP_SPECS_3_GPU_CORE_COUNT__MASK)
> +
>  #define VIVS_HI_CHIP_MINOR_FEATURE_4   0x0094
>
> +#define VIVS_HI_CHIP_SPECS_4   0x009c
> +#define VIVS_HI_CHIP_SPECS_4_STREAM_COUNT__MASK
> 0x0001f000
> +#define VIVS_HI_CHIP_SPECS_4_STREAM_COUNT__SHIFT   12
> +#define 

[PATCH] configure.ac: disable annoying warning -Wmissing-field-initializers

[Ilia Mirkin]

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 changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index c8c4ace..057a846 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -174,7 +174,8 @@ MAYBE_WARN="-Wall -Wextra \
>  -Wstrict-aliasing=2 -Winit-self \
>  -Wdeclaration-after-statement -Wold-style-definition \
>  -Wno-unused-parameter \
> --Wno-attributes -Wno-long-long -Winline -Wshadow"
> +-Wno-attributes -Wno-long-long -Winline -Wshadow \
> +-Wno-missing-field-initializers"
>
>  # invalidate cached value if MAYBE_WARN has changed
>  if test "x$libdrm_cv_warn_maybe" != "x$MAYBE_WARN"; then
> diff --git a/intel/intel_decode.c b/intel/intel_decode.c
> index e7aef74..287c342 100644
> --- a/intel/intel_decode.c
> +++ b/intel/intel_decode.c
> @@ -38,8 +38,6 @@
>  #include "intel_chipset.h"
>  #include "intel_bufmgr.h"
>
> -/* The compiler throws ~90 warnings. Do not spam the build, until we fix 
> them. */
> -#pragma GCC diagnostic ignored "-Wmissing-field-initializers"
>
>  /* Struct for tracking drm_intel_decode state. */
>  struct drm_intel_decode {
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm: bridge: sil902x

[Ilia Mirkin]

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:
>> > > Add basic support for the sil902x RGB -> HDMI bridge.
>> > > This driver does not support audio output yet.
>> > >
>> > > Signed-off-by: Boris Brezillon 
>> > > ---
>> > > Hello,
>> > >
>> > > This patch is only adding basic support for the sil9022 chip.
>> >
>> > This thing is a SiI9022 for camel case "Silicon Image" with a capital 'I',
>> > not a small 'l'.
>>
>> Oh, my bad, I'll fix that, but the vendor prefix defined in
>> Documentation/devicetree/bindings/vendor-prefixes.txt is not helping in
>> getting this right.
>
> No, indeed not. Unfortunately sii is already taken by Seiko.
>
>>
>> Should I also change the driver name?
>
> I would suggest so, yes.

For opposing opinions:

drivers/gpu/drm/i2c/sil164_drv.c
drivers/media/platform/s5p-tv/sii9234_drv.c

One of each :)

  -ilia

AMD guys: commit messages?

[Ilia Mirkin]

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 often very
> unhelpful. They don't state the motivation behind the commits. Is this
> a optimization, a nice-to-have cleanup or does this actually fix
> something? What does this fix?
> Are there tests or bugreports related?
>
> Improving this could make it easier for new developers to start
> contributing in the long run also!
>
> Examples:
>
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=d5a5dbd71f0e8756494809025ba2119efdf26373
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=338d7bf0531a10d90db75ad333f7e0a31693641f
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=4ebcf5194d98b47bd9e8a72b7418054708b14750
>
> This is also in the mesa dev guidelines, www.mesa3d.org/devinfo.html :
> "Patch fix is not clearly described. For example, a commit message of
> only a single line, no description of the bug, no mention of bugzilla,
> etc."

So... what's the appropriate amount? Have every commit describe, in
detail, how the GPU works, how the driver works, and what little bit
of interaction is being changed? I'm not an AMD developer (I do hack
on nouveau though), but I basically get what all 3 of the above are
doing. The reason why you're having trouble is probably because you
don't know what the ingredients are -- what's a mip level, what's a
ring index, what's fence, what's a winsys, what's a "emit vertex", all
in the context of the relevant drivers. If you know what all these
things are, the above commits become much clearer. But having to
describe each of those things every time would ... not fly :)

You can usually tell a cleanup/hypothetical fix apart from a real fix
by seeing if it (a) references a bugzilla, (b) mentions a commit it
fixes, or (c) cc'd to stable.

  -ilia

[PATCH 4/5] drm/atomic-helper: Reject legacy flips on a disabled pipe

[Ilia Mirkin]

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, but userspace has a track recording proofing that it's

has a track record which proves that it's

> way too easy to accidentally abuse and cause havoc. We want to make
> sure userspace doesn't get away with that.
>
> v2: Somehow thought we do reject events already, but that code only
> existed in my imagination ... Also suggestions from Thierry.
>
> Cc: Daniel Stone 
> Cc: Ville Syrjälä 
> Cc: Thierry Reding 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic.c| 16 
>  drivers/gpu/drm/drm_atomic_helper.c |  9 +
>  include/drm/drm_crtc.h  |  3 ++-
>  3 files changed, 27 insertions(+), 1 deletion(-)

[PATCH 02/12] drm/etnaviv: add devicetree bindings

[Ilia Mirkin]

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 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 render nodes to client over DRI2.
>>
>> Just to correct... DRI3 has been available on gallium [at least in the
>> context of st/mesa] basically since DRI3 was introduced. Not sure what
>> issue you're fighting with, but it's definitely not a gallium
>> limitation... could be something related to platform devices.
>
> Well, my statement is based on the fact that there's nothing in
> src/gallium/state-tracker/dri which hints at being DRI3.  Maybe it's
> implemented differently, I don't know.  I never wanted to hack MESA -
> I'm supposed to be the ARM kernel maintainer - and I'm still very new
> to MESA.
>
> I think it's a DRI3 limitation.  The issue with the DRI3 design is that:
>
> * The client has access to the GPU render nodes only, but not the
>   corresponding KMS node.
> * Buffers in DRI3 are allocated from the GPU render nodes.
> * The Xorg Present protocol is then used to manage the vblank
>   synchonisation and page flips.
>
> Now, the KMS scanout hardware typically does not support any kind of
> scatter-gather: the buffers it has must be contiguous.  These can be
> allocated from the KMS DRM device.
>
> However, the DRI3 client has no access to the KMS DRM device to allocate
> linear buffers from, and GPUs typically don't have dumb buffer support.
> Hence, the client can't pass a suitable buffer to the present layer.
>
> Hence, I can see no way for the resource_create() to be able to allocate
> any kind of scanout capable buffer.
>
> That's a separate issue though: you've pointed out that you can select
> which render node to use: what if we want to use multiple render nodes
> simultaneously - eg, because we want to use multiple 3D GPU cores
> together?  How does that work with stuff?

This is a bit like the SLI question -- let's say you have 2 pricey
desktop GPUs, with a fast interconnect between them, which lets them
know about each other, how do you make use of that. Solution: unsolved
:)

In an ideal world, you'd have a single driver that knows how to
interact with multiple devices and make them do cool things. However
this a completely untrodden path. (Not to mention the problem of *how*
to break up a workload across 2 GPUs.)

>
> I think the idea that individual GPU cores should be exposed as
> separate DRM devices is fundamentally flawed, and adds a hell of a
> lot of complexity.
>
> In any case, I've spent _way_ too much time on etnaviv during November -
> quite literally almost every day (I worked out that I was producing 4.5
> patches a day during November for Etnaviv MESA.)  I'm afraid that it's
> now time that I switch my attention elsewhere, so if this means that
> Etnaviv is rejected for merging, I'm afraid it'll be a few months before
> I can get back to it.
>
> It would have been nice if these issues had been brought up much earlier,
> during the RFC posting of the patches.  These are nothing new, and I now
> feel that this whole thing has been a total waste of time.

The whole multi-gpu thing is a bit of an open question right now. It
works in theory, but in practice nobody's done it. Maarten tried to
get nouveau/gk20a + tegra/drm on Jetson TK1 to play nice with, e.g., X
2d accel, and it was an exercise in pain. Not sure that he ever
succeeded.

I think it's unfair to try to make new hardware enablement the time to
attempt to heap extra work onto those authors unfortunate enough to
have slightly unorthodox hardware that maps nicely onto some
desired-but-not-quite-there-yet usage model -- they have enough
problems.

The way everything works is one drm node can do everything. PRIME is a
barely-functional way to offload some things onto a (single) secondary
GPU. Everything beyond that is purely theoretical.

None of what's being done now prevents some future where these things
are broken up. No need to force it now.

  -ilia

[PATCH 02/12] drm/etnaviv: add devicetree bindings

[Ilia Mirkin]

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 render nodes to client over DRI2.

Just to correct... DRI3 has been available on gallium [at least in the
context of st/mesa] basically since DRI3 was introduced. Not sure what
issue you're fighting with, but it's definitely not a gallium
limitation... could be something related to platform devices.

It is also possible to use DRI_PRIME= to select which
device to use. Not sure whether that has been available since the
beginning or not.

That said e.g. st/vdpau still doesn't deal with DRI3 which is a bit
annoying. And your other points all still stand (buffer sharing =
pain, tiling = not figured out, etc).

  -ilia

[PATCH 11/12] MAINTAINERS: add Lucas Stach as maintainer for the etnaviv DRM driver

[Ilia Mirkin]

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 MAINTAINERS.

>From the top of the MAINTAINERS file:

Descriptions of section entries:

P: Person (obsolete)
M: Mail patches to: FullName 
R: Designated reviewer: FullName 
   These reviewers should be CCed on patches.

So I guess that'd mean you want to be a reviewer?

  -ilia

[PATCH 13/28] drm/nouveau: Use private save/restore hooks

[Ilia Mirkin]

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 
> ---
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c |  5 +++--
>  drivers/gpu/drm/nouveau/dispnv04/disp.c | 11 ++-
>  drivers/gpu/drm/nouveau/nouveau_crtc.h  |  3 +++
>  3 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
> b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index dab24066fa21..bb9e9cb14b9d 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -1081,8 +1081,6 @@ nouveau_crtc_set_config(struct drm_mode_set *set)
>  }
>
>  static const struct drm_crtc_funcs nv04_crtc_funcs = {
> -   .save = nv_crtc_save,
> -   .restore = nv_crtc_restore,
> .cursor_set = nv04_crtc_cursor_set,
> .cursor_move = nv04_crtc_cursor_move,
> .gamma_set = nv_crtc_gamma_set,
> @@ -1123,6 +1121,9 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num)
> nv_crtc->index = crtc_num;
> nv_crtc->last_dpms = NV_DPMS_CLEARED;
>
> +   nv_crtc->save = nv_crtc_save;
> +   nv_crtc->restore = nv_crtc_restore;
> +
> drm_crtc_init(dev, _crtc->base, _crtc_funcs);
> drm_crtc_helper_add(_crtc->base, _crtc_helper_funcs);
> drm_mode_crtc_set_gamma_size(_crtc->base, 256);
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> index 9e650081c357..ebd9430e0628 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> @@ -39,7 +39,7 @@ nv04_display_create(struct drm_device *dev)
> struct dcb_table *dcb = >vbios.dcb;
> struct drm_connector *connector, *ct;
> struct drm_encoder *encoder;
> -   struct drm_crtc *crtc;
> +   struct nouveau_crtc *crtc;
> struct nv04_display *disp;
> int i, ret;
>
> @@ -107,8 +107,8 @@ nv04_display_create(struct drm_device *dev)
> }
>
> /* Save previous state */
> -   list_for_each_entry(crtc, >mode_config.crtc_list, head)
> -   crtc->funcs->save(crtc);
> +   list_for_each_entry(crtc, >mode_config.crtc_list, base.head)
> +   crtc->save(crtc);

Won't this warn about incompatible types? (function wants drm_crtc,
but you're giving it nouveau_crtc)?

>
> list_for_each_entry(encoder, >mode_config.encoder_list, head) {
> const struct drm_encoder_helper_funcs *func = 
> encoder->helper_private;
> @@ -128,6 +128,7 @@ nv04_display_destroy(struct drm_device *dev)
> struct nouveau_drm *drm = nouveau_drm(dev);
> struct drm_encoder *encoder;
> struct drm_crtc *crtc;
> +   struct nouveau_crtc *nv_crtc;
>
> /* Turn every CRTC off. */
> list_for_each_entry(crtc, >mode_config.crtc_list, head) {
> @@ -145,8 +146,8 @@ nv04_display_destroy(struct drm_device *dev)
> func->restore(encoder);
> }
>
> -   list_for_each_entry(crtc, >mode_config.crtc_list, head)
> -   crtc->funcs->restore(crtc);
> +   list_for_each_entry(nv_crtc, >mode_config.crtc_list, base.head)
> +   nv_crtc->restore(crtc);

Why is this OK? Don't you want to use nv_crtc here as the function argument?

>
> nouveau_hw_save_vga_fonts(dev, 0);
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_crtc.h 
> b/drivers/gpu/drm/nouveau/nouveau_crtc.h
> index f19cb1c5fc5a..863f10b8d818 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_crtc.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_crtc.h
> @@ -73,6 +73,9 @@ struct nouveau_crtc {
> int (*set_dither)(struct nouveau_crtc *crtc, bool update);
> int (*set_scale)(struct nouveau_crtc *crtc, bool update);
> int (*set_color_vibrance)(struct nouveau_crtc *crtc, bool update);
> +
> +   void (*save)(struct drm_crtc *crtc);
> +   void (*restore)(struct drm_crtc *crtc);
>  };
>
>  static inline struct nouveau_crtc *nouveau_crtc(struct drm_crtc *crtc)
> --
> 2.5.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Implementing Miracast?

[Ilia Mirkin]

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 Thu, Dec 3, 2015 at 10:34 AM, Laurent Pinchart wrote:
>> >>> 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 integration with X/Wayland and can only mirror the current desktop
>> >>>> using gstreamer.
>> >>>>
>> >>>> We're looking into extending the implementation so that we would be
>> >>>> able to use the remote screens just as any other connected screen, but
>> >>>> we're not quite sure where we should implement it.
>> >>>>
>> >>>> The DRM interface seems like the perfect fit since we wouldn't need to
>> >>>> patch every compositor.
>> >>>>
>> >>>> Right now, gstreamer is the equivalent of the crtc/encoder, in the DRM
>> >>>> model. Screens / crtcs are discovered using a WiFi's p2p protocol
>> >>>> which means that screens should be hotpluggable. Since we cannot
>> >>>> change the number of crtcs of a driver on the fly, we propose adding
>> >>>> and removing gpus with one crtc attached and no rendering
>> >>>> capabilities.
>> >>>>
>> >>>> Compositors and X currently use udev to list gpus and get run-time
>> >>>> events for gpu hot-plugging (see the work from Dave Airlie for USB
>> >>>> GPUs, using the modesetting X driver). We did not find a way to tell
>> >>>> udev that we have a new device and it seems like the only way to get
>> >>>> it to pick up our driver is from a uevent which can only be generated
>> >>>> from the kernel.
>> >>>>
>> >>>> Since we have so many userspace components, it doesn't make sense to
>> >>>> implement the entire driver in the kernel.
>> >>>>
>> >>>> We would thus need to have a communication from the kernel space to
>> >>>> the userspace at least to send the flip commands to the fake crtc.
>> >>>> Since we need this, why not implement everything in the userspace and
>> >>>> just redirect the ioctls to the userspace driver?
>> >>>>
>> >>>> This is exactly what fuse / cuse [1] does, with the minor catch that
>> >>>> it creates devices in /sys/class/cuse instead of drm. This prevents
>> >>>> the wayland compositors and X to pick it up as a normal drm driver...
>> >>>>
>> >>>> We would thus need to have the drm subsystem create the device nodes
>> >>>> for us when the userspace needs to create a new gpu. We could create a
>> >>>> node named /dev/dri/cuse_card that, when opened, would allocate a node
>> >>>> (/dev/dri/cardX) and would use cuse/fuse to redirect the ioctls to the
>> >>>> process who opened /dev/dri/cuse_card.
>> >>>>
>> >>>> The process would then be responsible for decoding the ioctl and
>> >>>> implementing the drm API.
>> >>>>
>> >>>> Since this is a major change which would allow proprietary drivers to
>> >>>> be implemented in the userspace and since we may have missed something
>> >>>> obvious, we would like to start a discussion on this. What are your
>> >>>> thoughts?
>> >>>
>> >>> As you raise the issue, how would you prevent proprietary userspace
>> >>> drivers to be implemented ? Anything that would allow vendors to
>> >>> destroy the Linux graphics ecosystem would receive a big nack from me.
>> >>
>> >> AFAIK the displaylink people already have precisely such a driver -- a
>> >> (open-source) kernel module that allows their (closed-source)
>> >> userspace blob to present a drm node to pass through modesetting/etc
>> >> ioctl's.
>> >
>> > Are you talking about the drivers/gpu/drm/udl/ driver ? I might be wrong
>> > but I'm not aware of that kernel driver requiring a closed-source
>> > userspace blob.
>> Nope. That driver only works for their USB2 parts. This is what I mean:
>>
>> https://github.com/DisplayLink/evdi
>> http://support.displaylink.com/knowledgebase/articles/679060
>> http://support.displaylink.com/knowledgebase/articles/615714#ubuntu
>
> Right. That's out-of-tree, people are free to screw up on their own there ;-)

Sure, but it's identical to Jaakko's proposal from what I can
(quickly) tell. And it's an example of someone taking an interface
like that and writing a proprietary driver on top.

  -ilia

Implementing Miracast?

[Ilia Mirkin]

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 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
>> >> integration with X/Wayland and can only mirror the current desktop
>> >> using gstreamer.
>> >>
>> >> We're looking into extending the implementation so that we would be
>> >> able to use the remote screens just as any other connected screen, but
>> >> we're not quite sure where we should implement it.
>> >>
>> >> The DRM interface seems like the perfect fit since we wouldn't need to
>> >> patch every compositor.
>> >>
>> >> Right now, gstreamer is the equivalent of the crtc/encoder, in the DRM
>> >> model. Screens / crtcs are discovered using a WiFi's p2p protocol which
>> >> means that screens should be hotpluggable. Since we cannot change the
>> >> number of crtcs of a driver on the fly, we propose adding and removing
>> >> gpus with one crtc attached and no rendering capabilities.
>> >>
>> >> Compositors and X currently use udev to list gpus and get run-time
>> >> events for gpu hot-plugging (see the work from Dave Airlie for USB
>> >> GPUs, using the modesetting X driver). We did not find a way to tell
>> >> udev that we have a new device and it seems like the only way to get it
>> >> to pick up our driver is from a uevent which can only be generated from
>> >> the kernel.
>> >>
>> >> Since we have so many userspace components, it doesn't make sense to
>> >> implement the entire driver in the kernel.
>> >>
>> >> We would thus need to have a communication from the kernel space to the
>> >> userspace at least to send the flip commands to the fake crtc. Since we
>> >> need this, why not implement everything in the userspace and just
>> >> redirect the ioctls to the userspace driver?
>> >>
>> >> This is exactly what fuse / cuse [1] does, with the minor catch that it
>> >> creates devices in /sys/class/cuse instead of drm. This prevents the
>> >> wayland compositors and X to pick it up as a normal drm driver...
>> >>
>> >> We would thus need to have the drm subsystem create the device nodes
>> >> for us when the userspace needs to create a new gpu. We could create a
>> >> node named /dev/dri/cuse_card that, when opened, would allocate a node
>> >> (/dev/dri/cardX) and would use cuse/fuse to redirect the ioctls to the
>> >> process who opened /dev/dri/cuse_card.
>> >>
>> >> The process would then be responsible for decoding the ioctl and
>> >> implementing the drm API.
>> >>
>> >> Since this is a major change which would allow proprietary drivers to
>> >> be implemented in the userspace and since we may have missed something
>> >> obvious, we would like to start a discussion on this. What are your
>> >> thoughts?
>> >
>> > As you raise the issue, how would you prevent proprietary userspace
>> > drivers to be implemented ? Anything that would allow vendors to destroy
>> > the Linux graphics ecosystem would receive a big nack from me.
>>
>> AFAIK the displaylink people already have precisely such a driver -- a
>> (open-source) kernel module that allows their (closed-source)
>> userspace blob to present a drm node to pass through modesetting/etc
>> ioctl's.
>
> Are you talking about the drivers/gpu/drm/udl/ driver ? I might be wrong but
> I'm not aware of that kernel driver requiring a closed-source userspace blob.

Nope. That driver only works for their USB2 parts. This is what I mean:

https://github.com/DisplayLink/evdi
http://support.displaylink.com/knowledgebase/articles/679060
http://support.displaylink.com/knowledgebase/articles/615714#ubuntu

  -ilia

Implementing Miracast?

[Ilia Mirkin]

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
>> integration with X/Wayland and can only mirror the current desktop
>> using gstreamer.
>>
>> We're looking into extending the implementation so that we would be
>> able to use the remote screens just as any other connected screen, but
>> we're not quite sure where we should implement it.
>>
>> The DRM interface seems like the perfect fit since we wouldn't need to
>> patch every compositor.
>>
>> Right now, gstreamer is the equivalent of the crtc/encoder, in the DRM
>> model. Screens / crtcs are discovered using a WiFi's p2p protocol which
>> means that screens should be hotpluggable. Since we cannot change the
>> number of crtcs of a driver on the fly, we propose adding and removing
>> gpus with one crtc attached and no rendering capabilities.
>>
>> Compositors and X currently use udev to list gpus and get run-time
>> events for gpu hot-plugging (see the work from Dave Airlie for USB
>> GPUs, using the modesetting X driver). We did not find a way to tell
>> udev that we have a new device and it seems like the only way to get it
>> to pick up our driver is from a uevent which can only be generated from
>> the kernel.
>>
>> Since we have so many userspace components, it doesn't make sense to
>> implement the entire driver in the kernel.
>>
>> We would thus need to have a communication from the kernel space to the
>> userspace at least to send the flip commands to the fake crtc. Since we
>> need this, why not implement everything in the userspace and just
>> redirect the ioctls to the userspace driver?
>>
>> This is exactly what fuse / cuse [1] does, with the minor catch that it
>> creates devices in /sys/class/cuse instead of drm. This prevents the
>> wayland compositors and X to pick it up as a normal drm driver...
>>
>> We would thus need to have the drm subsystem create the device nodes
>> for us when the userspace needs to create a new gpu. We could create a
>> node named /dev/dri/cuse_card that, when opened, would allocate a node
>> (/dev/dri/cardX) and would use cuse/fuse to redirect the ioctls to the
>> process who opened /dev/dri/cuse_card.
>>
>> The process would then be responsible for decoding the ioctl and
>> implementing the drm API.
>>
>> Since this is a major change which would allow proprietary drivers to
>> be implemented in the userspace and since we may have missed something
>> obvious, we would like to start a discussion on this. What are your
>> thoughts?
>
> As you raise the issue, how would you prevent proprietary userspace drivers to
> be implemented ? Anything that would allow vendors to destroy the Linux
> graphics ecosystem would receive a big nack from me.

AFAIK the displaylink people already have precisely such a driver -- a
(open-source) kernel module that allows their (closed-source)
userspace blob to present a drm node to pass through modesetting/etc
ioctl's.

  -ilia