[Bug 202873] (amdgpu) Screen flickering when using a 75Hz monitor paired with an RX 480 GPU
https://bugzilla.kernel.org/show_bug.cgi?id=202873 --- Comment #4 from Thomas (v10la...@myway.de) --- Kernel 5.0.5 still flickers. Anyway, after watching this more closely I'm pretty sure it's the same bug (the text cursor for entering username/password causes flickering on SDDM, for example). Still it seems to be fixed by deactivating the second monitor. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110345] Unrecoverable GPU crash with DiRT 4
https://bugs.freedesktop.org/show_bug.cgi?id=110345 Bug ID: 110345 Summary: Unrecoverable GPU crash with DiRT 4 Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: v10la...@myway.de QA Contact: dri-devel@lists.freedesktop.org At first I thought this is a kernel bug bug Alex Deucher told it's most likely a mesa bug. The game randomly freezes. When that happens the screen is frozen and input by mouse or keyboard doesn't work (LEDs on the keyboard are frozen, too). It's still possible to SSH to the PC to get some logs but that's about it: Even the reboot command freezes. Here's a log from Mesa 18.3.4 and kernel 5.0.4: > [52700.498697] [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, signaled > seq=1423558, emitted seq=1423560` > [52700.498702] [drm:amdgpu_job_timedout] *ERROR* Process information: process > Dirt4 pid 10332 thread WebViewRenderer pid 10391 > [52700.498705] amdgpu :01:00.0: GPU reset begin! > [52710.728397] [drm:amdgpu_dm_atomic_check] *ERROR* [CRTC:47:crtc-0] hw_done > or flip_done timed out > [52873.699280] WARNING: CPU: 2 PID: 4034 at kernel/kthread.c:529 > kthread_park+0x67/0x78 > [52873.699283] Modules linked in: nfsd > [52873.699287] CPU: 2 PID: 4034 Comm: TaskSchedulerFo Not tainted 5.0.4 #1 > [52873.699288] Hardware name: To be filled by O.E.M. To be filled by > O.E.M./SABERTOOTH 990FX R2.0, BIOS 2901 05/04/2016 > [52873.699290] RIP: 0010:kthread_park+0x67/0x78 > [52873.699291] Code: 18 e8 9d 78 aa 00 be 40 00 00 00 48 89 df e8 60 72 00 00 > 48 85 c0 74 1b 31 c0 5b 5d c3 0f 0b eb ae 0f 0b b8 da ff ff ff eb f0 <0f> 0b > b8 f0 ff ff ff eb e7 0f 0b eb e3 0f 1f 40 00 f6 47 26 20 74 > [52873.699293] RSP: 0018:a0144460fb78 EFLAGS: 00210202 > [52873.699294] RAX: 0004 RBX: 9155631210c0 RCX: > > [52873.699295] RDX: 9155ef427428 RSI: 9155631210c0 RDI: > 9155ef9bbfc0 > [52873.699296] RBP: 9155f013b8a0 R08: 9155f2a97480 R09: > 9155f2a94a00 > [52873.699297] R10: d46d0abbfe3a R11: 33d8b581bc78 R12: > 9155ef422790 > [52873.699298] R13: 9155a2f83c00 R14: 0202 R15: > dead0100 > [52873.699299] FS: 7fc756cff700() GS:9155f2a8() > knlGS: > [52873.699301] CS: 0010 DS: ES: CR0: 80050033 > [52873.699302] CR2: 7fc7650b8070 CR3: 000322b86000 CR4: > 000406e0 > [52873.699302] Call Trace: > [52873.699307] drm_sched_entity_fini+0x32/0x180 > [52873.699309] amdgpu_vm_fini+0xa8/0x520 > [52873.699311] ? idr_destroy+0x78/0xc0 > [52873.699313] amdgpu_driver_postclose_kms+0x14c/0x268 > [52873.699316] drm_file_free.part.7+0x21a/0x2f8 > [52873.699318] drm_release+0xa5/0x120 > [52873.699320] __fput+0x9a/0x1c8 > [52873.699323] task_work_run+0x8a/0xb0 > [52873.699325] do_exit+0x2b5/0xb30 > [52873.699326] do_group_exit+0x35/0x98 > [52873.699328] get_signal+0xbd/0x690 > [52873.699331] ? _raw_spin_unlock+0xd/0x20 > [52873.699333] ? do_signal+0x2b/0x6b8 > [52873.699335] ? __x64_sys_futex+0x137/0x178 > [52873.699337] ? exit_to_usermode_loop+0x46/0xa0 > [52873.699338] ? do_syscall_64+0x14c/0x178 > [52873.699339] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [52873.699341] ---[ end trace 1e1efc0508ef22df ]--- > [52875.619562] [drm] Skip scheduling IBs! > [52875.625247] [drm:amdgpu_cs_ioctl] *ERROR* Failed to initialize parser -125! > [52885.826983] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* > [CRTC:47:crtc-0] flip_done timed out > [52896.066581] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [CRTC:47:crtc-0] flip_done timed out > [52906.306280] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* > [PLANE:45:plane-5] flip_done timed out Mesa 19.0.1 / kernel 5.0.5: > [178793.032358] [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, signaled > seq=12332054, emitted seq=12332056 > [178793.032362] [drm:amdgpu_job_timedout] *ERROR* Process information: > process Dirt4 pid 31348 thread WebViewRenderer pid 31422 > [178793.032365] amdgpu :01:00.0: GPU reset begin! > [178803.262008] [drm:amdgpu_dm_atomic_check] *ERROR* [CRTC:47:crtc-0] hw_done > or flip_done timed out Mesa git (26e161b1e9) / kernel 5.0.5: > [ 7819.095648] [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, signaled > seq=2652771, emitted seq=2652773 > [ 7819.095652] [drm:amdgpu_job_timedout] *ERROR* Process information: process > Dirt4 pid 3075 thread WebViewRenderer pid 3152 > [ 7819.095655] amdgpu :01:00.0: GPU reset begin! > [ 7829.315220] [drm:amdgpu_dm_atomic_check] *ERROR* [CRTC:47:crtc-0] hw_done > or flip_done timed out This is on with a Radeon RX 580 (Sapphire NITRO+). Link to the kernel bug report: https://bugzilla.kernel.org/show_bug.cgi?id=
Re: [PATCH v5 1/7] dt-bindings: Add panel-timing subnode to simple-panel
On Mon, 1 Apr 2019 10:17:18 -0700, Douglas Anderson wrote: > From: Sean Paul > > This patch adds a new subnode to simple-panel allowing us to override > the typical timing expressed in the panel's display_timing. > > Changes in v2: > - Split out the binding into a new patch (Rob) > - display-timings is a new section (Rob) > - Use the full display-timings subnode instead of picking the timing >out (Rob/Thierry) > Changes in v3: > - Go back to using the timing subnode directly, but rename to >panel-timing (Rob) > Changes in v4: > - Simplify desc. for when override should be used (Thierry/Laurent) > - Removed Rob H review since it's been a year and wording changed > Changes in v5: > - Removed bit about OS may ignore (Rob/Ezequiel) > > Cc: Doug Anderson > Cc: Eric Anholt > Cc: Heiko Stuebner > Cc: Jeffy Chen > Cc: Rob Herring > Cc: Stéphane Marchesin > Cc: Thierry Reding > Cc: devicet...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-rockc...@lists.infradead.org > Signed-off-by: Sean Paul > Signed-off-by: Douglas Anderson > --- > > .../bindings/display/panel/simple-panel.txt | 22 +++ > 1 file changed, 22 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/5] dt-bindings: display: stm32: add supply property to DSI controller
On Wed, 3 Apr 2019 10:16:25 +0200, =?UTF-8?q?Yannick=20Fertr=C3=A9?= wrote: > This patch adds documentation of a new property phy-dsi-supply to the > STM32 DSI controller. > > Signed-off-by: Yannick Fertré > --- > Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2.1 22/22] dt-bindings: tc358767: add HPD support
On Mon, 1 Apr 2019 13:13:08 +0300, Tomi Valkeinen wrote: > Add DT property for defining the pin used for HPD. > > Signed-off-by: Tomi Valkeinen > Cc: devicet...@vger.kernel.org > Cc: Rob Herring > --- > > * Dropped the interrupt properties > * Renamed hpd-num to hpd-pin > * Added toshiba prefix for hpd-pin > > .../devicetree/bindings/display/bridge/toshiba,tc358767.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] dt-bindings: gpu: Add ASPEED GFX bindings document
On Wed, Apr 03, 2019 at 10:49:07AM +1030, Joel Stanley wrote:
> This describes the ASPEED BMC SoC's display controller.
>
> Signed-off-by: Joel Stanley
> Reviewed-by: Andrew Jeffery
> ---
> v3:
> Add Andrew's reviewed-by
>
> .../devicetree/bindings/gpu/aspeed-gfx.txt| 41 +++
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpu/aspeed-gfx.txt
>
> diff --git a/Documentation/devicetree/bindings/gpu/aspeed-gfx.txt
> b/Documentation/devicetree/bindings/gpu/aspeed-gfx.txt
> new file mode 100644
> index ..a7402668
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpu/aspeed-gfx.txt
> @@ -0,0 +1,41 @@
> +Device tree configuration for the GFX display deivce on the AST2500 SoCs.
> +
> +Required properties:
> + - compatible
> +* Must be one of the following:
> + + aspeed,ast2500-gfx
> + + aspeed,ast2400-gfx
> +* In addition, the ASPEED pinctrl bindings require the 'syscon' property
> to
> + be present
> +
> + - reg: Physical base address and length of the GFX registers
> +
> + - interrupts: interrupt number for the GFX device
> +
> + - clocks: clock number used to generate the pixel clock
> +
> + - resets: reset line that must be released to use the GFX device
> +
> + - memory-region:
> +Phandle to a memory region to allocate from, as defined in
> +Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
If required, does that mean the h/w can only use certain memory? Why?
> +
> +
> +Example:
> +
> +gfx: display@1e6e6000 {
> + compatible = "aspeed,ast2500-gfx", "syscon";
> + reg = <0x1e6e6000 0x1000>;
> + reg-io-width = <4>;
Not documented as used. This should be implied by the compatible though.
> + clocks = <&syscon ASPEED_CLK_GATE_D1CLK>;
> + resets = <&syscon ASPEED_RESET_CRT1>;
> + interrupts = <0x19>;
> + memory-region = <&gfx_memory>;
> +};
> +
> +gfx_memory: framebuffer {
> + size = <0x0100>;
> + alignment = <0x0100>;
> + compatible = "shared-dma-pool";
> + reusable;
> +};
> --
> 2.20.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 5/6] dt-bindings: display: sii902x: Add HDMI audio bindings
On Tue, Apr 02, 2019 at 10:29:14AM +0300, Jyri Sarha wrote:
> The sii902x chip family supports also HDMI audio. Add binding for
> describing the necessary i2s and mclk wiring for it.
>
> Signed-off-by: Jyri Sarha
> ---
> .../bindings/display/bridge/sii902x.txt | 37 +++
> 1 file changed, 37 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> index c4c1855ca654..d124a5fedab1 100644
> --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> @@ -9,6 +9,37 @@ Optional properties:
> about hotplug events.
> - reset-gpios: OF device-tree gpio specification for RST_N pin.
>
> + HDMI audio properties:
> + - #sound-dai-cells: <0> or <1>. <0> if only i2s or spdif pin
> +is wired, <1> if the both are wired. HDMI audio is
> +configured only if this property is found.
> + - sil,i2s-data-lanes: Array of up to 4 integers with values of 0-3
> +Each integer indicates which i2s pin is connected to which
> +audio fifo. The first integer selects i2s audio pin for the
> +first audio fifo#0 (HDMI channels 1&2), second for fifo#1
> +(HDMI channels 3&4), and so on. There is 4 fifos and 4 i2s
> +pins (SD0 - SD3). Any i2s pin can be connected to any fifo,
> +but there can be no gaps. E.g. an i2s pin must be mapped to
> +fifo#0 and fifo#1 before mapping a channel to fifo#2. Default
> +value is <0>, describing SD0 pin beiging routed to hdmi audio
> +fifo #0.
> + - clocks: phandle and clock specifier for each clock listed in
> + the clock-names property
> + - clock-names: "mclk"
> +Describes SII902x MCLK input. MCLK is used to produce
> +HDMI audio CTS values. This property is required if
> +"#sound-dai-cells"-property is present. This property follows
> +Documentation/devicetree/bindings/clock/clock-bindings.txt
> +consumer binding.
> +
> + If HDMI audio is configured the sii902x device becomes an ASoC
> + codec component, that can be used in configuring full audio
> + devices with ASoC simple-card or audio-graph-card. See their
ASoC is a Linux thing.
> + binding documents on how to describe how the sii902x device is
> + connected to the rest of the audio system:
> + Documentation/devicetree/bindings/sound/simple-card.txt
> + Documentation/devicetree/bindings/sound/audio-graph-card.txt
> +
> Optional subnodes:
> - video input: this subnode can contain a video input port node
> to connect the bridge to a display controller output (See this
> @@ -21,6 +52,12 @@ Example:
> compatible = "sil,sii9022";
> reg = <0x39>;
> reset-gpios = <&pioA 1 0>;
> +
> + #sound-dai-cells = <0>;
> + i2s-data-lanes = < 0 1 2 >;
> + clocks = <&mclk>;
> + clock-names = "mclk";
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/2] dt-bindings: phy: Add documentation for mixel dphy
On Mon, 1 Apr 2019 12:13:35 +0200, =?UTF-8?q?Guido=20G=C3=BCnther?= wrote: > Add support for the MIXEL DPHY IP as found on NXP's i.MX8MQ SoCs. > > Signed-off-by: Guido Günther > Reviewed-by: Sam Ravnborg > --- > .../bindings/phy/mixel,mipi-dsi-phy.txt | 29 +++ > 1 file changed, 29 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] dt-bindings: display: tfp410: Add bus-width parameter property
On Mon, 1 Apr 2019 15:41:42 +0300, Peter Ujfalusi wrote: > tfp410 can be connect to host processor in 24bit, single-edge (24 lines) or > 12bit, dual-edge (12 lines). > > Add bus-width to the documentation so it can be used to select between the > two connection scheme. > > Signed-off-by: Peter Ujfalusi > --- > .../devicetree/bindings/display/bridge/ti,tfp410.txt | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 0/7] sunxi: Add DT representation for the MBUS controller
On Mon, Apr 01, 2019 at 10:56:40AM +0200, Maxime Ripard wrote: > Hi, > > We've had for quite some time to hack around in our drivers to take into > account the fact that our DMA accesses are not done through the parent > node, but through another bus with a different mapping than the CPU for the > RAM (0 instead of 0x4000 for most SoCs). > > After some discussion after the submission of a camera device suffering of > the same hacks, I've decided to put together a serie that introduce a > special interconnect name called "dma" that that allows to express the DMA > relationship between a master and its bus, even if they are not direct > parents in the DT. > > Let me know what you think, > Maxime LGTM. How do you propose merging this? I can take 1-5, and 6 and 7 thru arm-soc? Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 7/7] MAINTAINERS: sm712fb: list myself as one maintainer.
On Wed, Apr 3, 2019 at 2:53 PM Bartlomiej Zolnierkiewicz wrote: > > > On 04/02/2019 11:09 PM, Sudip Mukherjee wrote: > > On Mon, Apr 1, 2019 at 6:41 PM Tom Li wrote: > >> > >> On Sun, Mar 31, 2019 at 08:08:01PM +0100, Sudip Mukherjee wrote: > >>> Technically I donot have any problem with this, you seem to know more > >>> about SM712 than I know. But Teddy Wang is also an existing maintainer > >>> and I think there should be an ack from him before this is accepted. > >> > >> Okay, I'll write a personal mail to Teddy. I think it could be a separate > >> patch to allow more time for communication, but the problem is that, if > > The first version of the patchset was posted on 2nd February and > Teddy was on Cc:. Unless there is an explicit NACK (with valid > rationale) from him lets assume that he is fine with having another > co-maintainer. > > >> the MAINTAINERS and the new changes are not merged at the same time, users > >> who have problems may unable to see my name and E-mail address for > >> reporting > >> problems. > > > > git will not forget that you have done the changes. :) > > So anyone who has a problem only needs to do a "git blame" to see who > > has done it and the user will get your name and email to contact you. > > If that is the only reason you think your name is added as a > > The original patch description suggests that there is more than > that: > > "I have working on the sm712fb driver for a while and have some > familiarity with this hardware, I'll be helping working on and > testing problems of this driver, so add myself to the MAINTAINERS > file." > > > maintainer then I guess that is not a valid concern and then in that > > case I am not seeing any need to add your name in maintainer. > > > > Bartlomiej can you advise please. > > 2D acceleration seems to be an important contribution to the driver > (functionality wise and code wise -> it grows the driver source code > by ~25%) and it shows that Yifeng knows the driver well. > > He has also access to SM720 (you have SM712 only) to verify potential > issues with the future driver changes (I assume that he don't mind > getting Cc:ed on all driver related patches, not that there should be > much of them). Agreed with all the points. -- Regards Sudip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203111] Unrecoverable GPU crash with DiRT 4
https://bugzilla.kernel.org/show_bug.cgi?id=203111 Thomas (v10la...@myway.de) changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203111] Unrecoverable GPU crash with DiRT 4
https://bugzilla.kernel.org/show_bug.cgi?id=203111 --- Comment #5 from Thomas (v10la...@myway.de) --- Thanks a lot for the detailed answer. I'm still not sure if I understand everything correctly (shouldn't the kernel driver validate the command stream from userspace/mesa and stop bad things before they hit hardware / hang the GPU?) but I'll close this now and check for or open a new mesa bug report tomorrow (I really need sleep now). Damn, if this wouldn't be the wrong place I would ask for more details about your last reply (the thing about the display servers not catching up with the GPU reset - aren't there drivers which perform GPU resets just nice under X11 already? What about Wayland?). It's so freaking nice, I bet I would learn a lot if we wold continue the discussion... Anyway, thanks again for explaining and sorry for me going a bit off topic in this reply. One last thing... It's exremely off topic but I already derailed this reply and it has to be told: Thank you Alex for being the guy you are. I bet AMD doesn't pay you to explain technical details to stupid end users like me but that's very appreciated. You're a hero, keep on rockin'! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109692] deadlock occurs during GPU reset
https://bugs.freedesktop.org/show_bug.cgi?id=109692 --- Comment #20 from Andrey Grodzovsky --- Created attachment 143883 --> https://bugs.freedesktop.org/attachment.cgi?id=143883&action=edit 0002-drm-sched-Adapt-drivers-to-new-job-destruction-logic.patch Mikhail, attached 2 patches should help avoid the deadlock you see. Please apply them on top of latest https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109692] deadlock occurs during GPU reset
https://bugs.freedesktop.org/show_bug.cgi?id=109692 --- Comment #19 from Andrey Grodzovsky --- Created attachment 143882 --> https://bugs.freedesktop.org/attachment.cgi?id=143882&action=edit 0001-drm-scheduler-rework-job-destruction.patch -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 203111] Unrecoverable GPU crash with DiRT 4
https://bugzilla.kernel.org/show_bug.cgi?id=203111 --- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) --- (In reply to Thomas from comment #3) > > Are you sure this could be a mesa bug? Just asking cause for me a hanging > kernel sounds like a kernel bug. Likely a mesa bug. Mesa submits gfx/video/compute jobs to the kernel driver. If there are subtle bugs in those jobs, the GPU can hang. The kernel driver can reset the GPU, but the display server needs to catch the reset and properly re-initialize it's context and buffers. At the moment, none of the display servers do this so you need to restart them after a GPU reset. The: [drm:amdgpu_cs_ioctl] *ERROR* Failed to initialize parser -125! error is because userspace tried to submit more work to the kernel after a reset without re-initializing it's context, so the kernel rejects it. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] drm/tegra: Fixes for v5.1-rc2
On Thu, Apr 4, 2019 at 7:33 AM Thierry Reding wrote: > > On Thu, Apr 04, 2019 at 12:15:48PM +1000, Dave Airlie wrote: > > On Thu, 4 Apr 2019 at 02:07, Thierry Reding > > wrote: > > > > > > On Fri, Mar 22, 2019 at 02:15:17PM +0100, Thierry Reding wrote: > > > > Hi Dave, > > > > > > > > The following changes since commit > > > > 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b: > > > > > > > > Linux 5.1-rc1 (2019-03-17 14:22:26 -0700) > > > > > > > > are available in the Git repository at: > > > > > > > > git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-5.1-rc2 > > > > > > > > for you to fetch changes up to 509869a2fec36ecb2b841180915995f41d5a0219: > > > > > > > > drm/tegra: vic: Fix implicit function declaration warning (2019-03-22 > > > > 14:08:55 +0100) > > > > > > > > I'm a little late sending this out, so I realize this will probably go > > > > into v5.1-rc3 despite the name of the tag. > > > > > > > > Thanks, > > > > Thierry > > > > > > > > > > > > drm/tegra: Fixes for v5.1-rc2 > > > > > > > > These are a couple of minor fixes for build issues and sparse warnings. > > > > > > > > > > > > Anders Roxell (1): > > > > drm/tegra: vic: Fix implicit function declaration warning > > > > > > > > Thierry Reding (1): > > > > drm/tegra: hub: Fix dereference before check > > > > > > > > drivers/gpu/drm/tegra/hub.c | 4 +++- > > > > drivers/gpu/drm/tegra/vic.c | 2 ++ > > > > 2 files changed, 5 insertions(+), 1 deletion(-) > > > > > > Ping. Can we get this into drm-fixes? > > > > Huh this already landed in Linus tree afaik, > > Indeed it has. I must've gotten confused because this is not in drm-misc > and I was seeing build failures due to the above. > Adding Maxime for a backmerge/rebase of -fixes so we can pick this up. Sean > Anyway, sorry for the noise. > > Thierry > ___ > 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
[Bug 203111] Unrecoverable GPU crash with DiRT 4
https://bugzilla.kernel.org/show_bug.cgi?id=203111 Thomas (v10la...@myway.de) changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #3 from Thomas (v10la...@myway.de) --- (In reply to Alex Deucher from comment #1) > I'd suggest trying a new version of mesa I was too fast with closing this: It crashes with newer mesa, too, just (subjective) less frequent. Here's a log from mesa 19.0.1: > [178793.032358] [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, signaled > seq=12332054, emitted seq=12332056 > [178793.032362] [drm:amdgpu_job_timedout] *ERROR* Process information: > process Dirt4 pid 31348 thread WebViewRenderer pid 31422 > [178793.032365] amdgpu :01:00.0: GPU reset begin! > [178803.262008] [drm:amdgpu_dm_atomic_check] *ERROR* [CRTC:47:crtc-0] hw_done > or flip_done timed out And from git (26e161b1e9): > [ 7819.095648] [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, signaled > seq=2652771, emitted seq=2652773 > [ 7819.095652] [drm:amdgpu_job_timedout] *ERROR* Process information: process > Dirt4 pid 3075 thread WebViewRenderer pid 3152 > [ 7819.095655] amdgpu :01:00.0: GPU reset begin! > [ 7829.315220] [drm:amdgpu_dm_atomic_check] *ERROR* [CRTC:47:crtc-0] hw_done > or flip_done timed out Not sure if the log is shorter cause of new mesa or new kernel (updated from 5.0.4 to 5.0.5). Are you sure this could be a mesa bug? Just asking cause for me a hanging kernel sounds like a kernel bug. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/11] drm/vmwgfx: Fix formatting and spaces in vmwgfx_execbuf.c
No functional change with this change, just fixing formatting and
spaces.
v2: Rebase.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 687 +++-
1 file changed, 302 insertions(+), 385 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index e7c93f422a7e..0d703f431f1f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -54,7 +54,7 @@
__type body; \
} __var
-/*
+/**
* struct vmw_relocation - Buffer object relocation
*
* @head: List head for the command submission context's relocation list
@@ -78,9 +78,8 @@ struct vmw_relocation {
* command stream is replaced with the actual id after validation.
* @vmw_res_rel_nop: NOP relocation. The command is unconditionally replaced
* with a NOP.
- * @vmw_res_rel_cond_nop: Conditional NOP relocation. If the resource id
- * after validation is -1, the command is replaced with a NOP. Otherwise no
- * action.
+ * @vmw_res_rel_cond_nop: Conditional NOP relocation. If the resource id after
+ * validation is -1, the command is replaced with a NOP. Otherwise no action.
*/
enum vmw_resource_relocation_type {
vmw_res_rel_normal,
@@ -94,8 +93,8 @@ enum vmw_resource_relocation_type {
*
* @head: List head for the software context's relocation list.
* @res: Non-ref-counted pointer to the resource.
- * @offset: Offset of single byte entries into the command buffer where the
- * id that needs fixup is located.
+ * @offset: Offset of single byte entries into the command buffer where the id
+ * that needs fixup is located.
* @rel_type: Type of relocation.
*/
struct vmw_resource_relocation {
@@ -105,8 +104,9 @@ struct vmw_resource_relocation {
enum vmw_resource_relocation_type rel_type:3;
};
-/*
+/**
* struct vmw_ctx_validation_info - Extra validation metadata for contexts
+ *
* @head: List head of context list
* @ctx: The context resource
* @cur: The context's persistent binding state
@@ -161,9 +161,10 @@ static size_t vmw_ptr_diff(void *a, void *b)
/**
* vmw_execbuf_bindings_commit - Commit modified binding state
+ *
* @sw_context: The command submission context
- * @backoff: Whether this is part of the error path and binding state
- * changes should be ignored
+ * @backoff: Whether this is part of the error path and binding state changes
+ * should be ignored
*/
static void vmw_execbuf_bindings_commit(struct vmw_sw_context *sw_context,
bool backoff)
@@ -173,6 +174,7 @@ static void vmw_execbuf_bindings_commit(struct
vmw_sw_context *sw_context,
list_for_each_entry(entry, &sw_context->ctx_list, head) {
if (!backoff)
vmw_binding_state_commit(entry->cur, entry->staged);
+
if (entry->staged != sw_context->staged_bindings)
vmw_binding_state_free(entry->staged);
else
@@ -185,6 +187,7 @@ static void vmw_execbuf_bindings_commit(struct
vmw_sw_context *sw_context,
/**
* vmw_bind_dx_query_mob - Bind the DX query MOB if referenced
+ *
* @sw_context: The command submission context
*/
static void vmw_bind_dx_query_mob(struct vmw_sw_context *sw_context)
@@ -195,8 +198,8 @@ static void vmw_bind_dx_query_mob(struct vmw_sw_context
*sw_context)
}
/**
- * vmw_cmd_ctx_first_setup - Perform the setup needed when a context is
- * added to the validate list.
+ * vmw_cmd_ctx_first_setup - Perform the setup needed when a context is added
to
+ * the validate list.
*
* @dev_priv: Pointer to the device private:
* @sw_context: The command submission context
@@ -214,8 +217,7 @@ static int vmw_cmd_ctx_first_setup(struct vmw_private
*dev_priv,
goto out_err;
if (!sw_context->staged_bindings) {
- sw_context->staged_bindings =
- vmw_binding_state_alloc(dev_priv);
+ sw_context->staged_bindings = vmw_binding_state_alloc(dev_priv);
if (IS_ERR(sw_context->staged_bindings)) {
ret = PTR_ERR(sw_context->staged_bindings);
sw_context->staged_bindings = NULL;
@@ -240,19 +242,20 @@ static int vmw_cmd_ctx_first_setup(struct vmw_private
*dev_priv,
list_add_tail(&node->head, &sw_context->ctx_list);
return 0;
+
out_err:
return ret;
}
/**
- * vmw_execbuf_res_size - calculate extra size fore the resource validation
- * node
+ * vmw_execbuf_res_size - calculate extra size fore the resource validation
node
+ *
* @dev_priv: Pointer to the device private struct.
* @res_type: The resource type.
*
- * Guest-backed contexts and DX contexts require extra size to store
- * execbuf private information in the validation node. Typically the
- * binding manager associated data structures.
+
[PATCH 04/11] drm/vmwgfx: Use preprocessor macro to get valid context node
Several command verifier function check if context node is present or
not and if not present print an error and return. Use a preprocessor
macro to print the message.
v2: Name-space distinction for preprocessor macro
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 102 +++-
1 file changed, 45 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 4955a48a9d86..4f5445c53111 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -35,6 +35,19 @@
#define VMW_RES_HT_ORDER 12
+/*
+ * Helper macro to get dx_ctx_node if available otherwise print an error
+ * message. This is for use in command verifier function where if dx_ctx_node
+ * is not set then command is invalid.
+ */
+#define VMW_GET_CTX_NODE(__sw_context)\
+({\
+ __sw_context->dx_ctx_node ? __sw_context->dx_ctx_node : ({\
+ DRM_ERROR("SM context is not set at %s\n", __func__); \
+ __sw_context->dx_ctx_node;\
+ }); \
+})
+
/*
* struct vmw_relocation - Buffer object relocation
*
@@ -774,13 +787,11 @@ static int vmw_view_bindings_add(struct vmw_sw_context
*sw_context,
uint32 view_ids[], u32 num_views,
u32 first_slot)
{
- struct vmw_ctx_validation_info *ctx_node = sw_context->dx_ctx_node;
+ struct vmw_ctx_validation_info *ctx_node = VMW_GET_CTX_NODE(sw_context);
u32 i;
- if (!ctx_node) {
- DRM_ERROR("DX Context not set.\n");
+ if (!ctx_node)
return -EINVAL;
- }
for (i = 0; i < num_views; ++i) {
struct vmw_ctx_bindinfo_view binding;
@@ -1280,14 +1291,11 @@ static int vmw_cmd_dx_define_query(struct vmw_private
*dev_priv,
} *cmd;
intret;
- struct vmw_ctx_validation_info *ctx_node = sw_context->dx_ctx_node;
+ struct vmw_ctx_validation_info *ctx_node = VMW_GET_CTX_NODE(sw_context);
struct vmw_resource *cotable_res;
-
- if (ctx_node == NULL) {
- DRM_ERROR("DX Context not set for query.\n");
+ if (!ctx_node)
return -EINVAL;
- }
cmd = container_of(header, struct vmw_dx_define_query_cmd, header);
@@ -2270,14 +2278,12 @@ vmw_cmd_dx_set_single_constant_buffer(struct
vmw_private *dev_priv,
SVGA3dCmdDXSetSingleConstantBuffer body;
} *cmd;
struct vmw_resource *res = NULL;
- struct vmw_ctx_validation_info *ctx_node = sw_context->dx_ctx_node;
+ struct vmw_ctx_validation_info *ctx_node = VMW_GET_CTX_NODE(sw_context);
struct vmw_ctx_bindinfo_cb binding;
int ret;
- if (unlikely(ctx_node == NULL)) {
- DRM_ERROR("DX Context not set.\n");
+ if (!ctx_node)
return -EINVAL;
- }
cmd = container_of(header, typeof(*cmd), header);
ret = vmw_cmd_res_check(dev_priv, sw_context, vmw_res_surface,
@@ -2358,14 +2364,12 @@ static int vmw_cmd_dx_set_shader(struct vmw_private
*dev_priv,
SVGA3dCmdDXSetShader body;
} *cmd;
struct vmw_resource *res = NULL;
- struct vmw_ctx_validation_info *ctx_node = sw_context->dx_ctx_node;
+ struct vmw_ctx_validation_info *ctx_node = VMW_GET_CTX_NODE(sw_context);
struct vmw_ctx_bindinfo_shader binding;
int ret = 0;
- if (unlikely(ctx_node == NULL)) {
- DRM_ERROR("DX Context not set.\n");
+ if (!ctx_node)
return -EINVAL;
- }
cmd = container_of(header, typeof(*cmd), header);
@@ -2411,7 +2415,7 @@ static int vmw_cmd_dx_set_vertex_buffers(struct
vmw_private *dev_priv,
struct vmw_sw_context *sw_context,
SVGA3dCmdHeader *header)
{
- struct vmw_ctx_validation_info *ctx_node = sw_context->dx_ctx_node;
+ struct vmw_ctx_validation_info *ctx_node = VMW_GET_CTX_NODE(sw_context);
struct vmw_ctx_bindinfo_vb binding;
struct vmw_resource *res;
struct {
@@ -2421,10 +2425,8 @@ static int vmw_cmd_dx_set_vertex_buffers(struct
vmw_private *dev_priv,
} *cmd;
int i, ret, num;
- if (unlikely(ctx_node == NULL)) {
- DRM_ERROR("DX Context not set.\n");
+ if (!ctx_node)
return -EINVAL;
- }
cmd = container_of(header, typeof(*cmd), header);
num = (cmd->header.size - sizeof(cmd->body)) /
@@ -2469,7 +2471,7 @@ static int vmw_cmd_dx_set_index_buffer(struct vmw_private
*dev_priv,
[PATCH 07/11] drm/vmwgfx: Print message when command verifier returns with error
Whenever command verifier function returns with an error, print a debug
message using VMW_DEBUG_USER. This will make sure failing commands can
be easily tracked for debugging purpose.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 9362670af03c..9df334340146 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -3287,8 +3287,11 @@ static int vmw_cmd_check(struct vmw_private *dev_priv,
goto out_new;
ret = entry->func(dev_priv, sw_context, header);
- if (unlikely(ret != 0))
- goto out_invalid;
+ if (unlikely(ret != 0)) {
+ VMW_DEBUG_USER("SVGA3D command: %d failed with error %d\n",
+ cmd_id + SVGA_3D_CMD_BASE, ret);
+ return ret;
+ }
return 0;
out_invalid:
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/11] drm/vmwgfx: Add a new define for vmwgfx user-space debugging
Error messages or debugging message reported during user-space command
submission should not be printed to dmesg by default. So add a new
preprocessor define called VMW_DEBUG_USER which translates to
DRM_DEBUG_DRIVER.
v2: Use VMW_DEBUG_USER instead of using DRM_DEBUG_DRIVER directly.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 14 ++
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 140 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 12 +-
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 7 +-
.../gpu/drm/vmwgfx/vmwgfx_simple_resource.c | 12 +-
drivers/gpu/drm/vmwgfx/vmwgfx_so.c| 9 +-
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 32 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_validation.c| 3 +-
9 files changed, 119 insertions(+), 112 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
index 694fabafaeee..39e96bb86329 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
@@ -751,7 +751,7 @@ static int vmw_context_define(struct drm_device *dev, void
*data,
int ret;
if (!dev_priv->has_dx && dx) {
- DRM_ERROR("DX contexts not supported by device.\n");
+ VMW_DEBUG_USER("DX contexts not supported by device.\n");
return -EINVAL;
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index abe975b7ea89..92367d4ebdf3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1313,6 +1313,20 @@ int vmw_host_get_guestinfo(const char *guest_info_param,
char *buffer, size_t *length);
int vmw_host_log(const char *log);
+/* VMW logging */
+
+/**
+ * VMW_DEBUG_USER - Debug output for user-space debugging.
+ *
+ * @fmt: printf() like format string.
+ *
+ * This macro is for logging user-space error and debugging messages for e.g.
+ * command buffer execution errors due to malformed commands, invalid context,
+ * etc.
+ */
+#define VMW_DEBUG_USER(fmt, ...) \
+ DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__)
+
/**
* Inline helper functions
*/
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 2c92744817ec..9362670af03c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -43,7 +43,7 @@
#define VMW_GET_CTX_NODE(__sw_context)\
({\
__sw_context->dx_ctx_node ? __sw_context->dx_ctx_node : ({\
- DRM_ERROR("SM context is not set at %s\n", __func__); \
+ VMW_DEBUG_USER("SM context is not set at %s\n", __func__);\
__sw_context->dx_ctx_node;\
}); \
})
@@ -217,8 +217,7 @@ static int vmw_cmd_ctx_first_setup(struct vmw_private
*dev_priv,
sw_context->staged_bindings =
vmw_binding_state_alloc(dev_priv);
if (IS_ERR(sw_context->staged_bindings)) {
- DRM_ERROR("Failed to allocate context binding "
- "information.\n");
+ VMW_DEBUG_USER("Failed to alloc ctx binding info.\n");
ret = PTR_ERR(sw_context->staged_bindings);
sw_context->staged_bindings = NULL;
goto out_err;
@@ -228,8 +227,7 @@ static int vmw_cmd_ctx_first_setup(struct vmw_private
*dev_priv,
if (sw_context->staged_bindings_inuse) {
node->staged = vmw_binding_state_alloc(dev_priv);
if (IS_ERR(node->staged)) {
- DRM_ERROR("Failed to allocate context binding "
- "information.\n");
+ VMW_DEBUG_USER("Failed to alloc ctx binding info.\n");
ret = PTR_ERR(node->staged);
node->staged = NULL;
goto out_err;
@@ -424,7 +422,7 @@ vmw_view_id_val_add(struct vmw_sw_context *sw_context,
int ret;
if (!ctx_node) {
- DRM_ERROR("DX Context not set.\n");
+ VMW_DEBUG_USER("DX Context not set.\n");
return ERR_PTR(-EINVAL);
}
@@ -522,7 +520,7 @@ static int vmw_resource_relocation_add(struct
vmw_sw_context *sw_context,
rel = vmw_validation_mem_alloc(sw_context->ctx, sizeof(*rel));
if (unlikely(!rel)) {
- DRM_ERROR("Failed to allocate a resource relocation.\n");
+ VMW_DEBUG_USER("Failed to allocate a resource relocation.\n");
[PATCH 05/11] drm/vmwgfx: Use preprocessor macro for cmd struct
Use preprocessor macro for repetitive device command struct format.
v2: Name-space distinction for preprocessor macro.
v3: Struct name as macro parameter and rebase.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 405
1 file changed, 125 insertions(+), 280 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 4f5445c53111..2c92744817ec 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -48,6 +48,12 @@
}); \
})
+#define VMW_DECLARE_CMD_VAR(__var, __type)\
+ struct { \
+ SVGA3dCmdHeader header; \
+ __type body; \
+ } __var
+
/*
* struct vmw_relocation - Buffer object relocation
*
@@ -710,11 +716,7 @@ static int vmw_rebind_all_dx_query(struct vmw_resource
*ctx_res)
{
struct vmw_private *dev_priv = ctx_res->dev_priv;
struct vmw_buffer_object *dx_query_mob;
- struct {
- SVGA3dCmdHeader header;
- SVGA3dCmdDXBindAllQuery body;
- } *cmd;
-
+ VMW_DECLARE_CMD_VAR(*cmd, SVGA3dCmdDXBindAllQuery);
dx_query_mob = vmw_context_get_dx_query_mob(ctx_res);
@@ -831,15 +833,12 @@ static int vmw_cmd_cid_check(struct vmw_private *dev_priv,
struct vmw_sw_context *sw_context,
SVGA3dCmdHeader *header)
{
- struct vmw_cid_cmd {
- SVGA3dCmdHeader header;
- uint32_t cid;
- } *cmd;
+ VMW_DECLARE_CMD_VAR(*cmd, uint32_t) =
+ container_of(header, typeof(*cmd), header);
- cmd = container_of(header, struct vmw_cid_cmd, header);
return vmw_cmd_res_check(dev_priv, sw_context, vmw_res_context,
VMW_RES_DIRTY_SET, user_context_converter,
-&cmd->cid, NULL);
+&cmd->body, NULL);
}
/**
@@ -874,15 +873,12 @@ static int vmw_cmd_set_render_target_check(struct
vmw_private *dev_priv,
struct vmw_sw_context *sw_context,
SVGA3dCmdHeader *header)
{
- struct vmw_sid_cmd {
- SVGA3dCmdHeader header;
- SVGA3dCmdSetRenderTarget body;
- } *cmd;
+ VMW_DECLARE_CMD_VAR(*cmd, SVGA3dCmdSetRenderTarget);
struct vmw_resource *ctx;
struct vmw_resource *res;
int ret;
- cmd = container_of(header, struct vmw_sid_cmd, header);
+ cmd = container_of(header, typeof(*cmd), header);
if (cmd->body.type >= SVGA3D_RT_MAX) {
DRM_ERROR("Illegal render target type %u.\n",
@@ -924,13 +920,10 @@ static int vmw_cmd_surface_copy_check(struct vmw_private
*dev_priv,
struct vmw_sw_context *sw_context,
SVGA3dCmdHeader *header)
{
- struct vmw_sid_cmd {
- SVGA3dCmdHeader header;
- SVGA3dCmdSurfaceCopy body;
- } *cmd;
+ VMW_DECLARE_CMD_VAR(*cmd, SVGA3dCmdSurfaceCopy);
int ret;
- cmd = container_of(header, struct vmw_sid_cmd, header);
+ cmd = container_of(header, typeof(*cmd), header);
ret = vmw_cmd_res_check(dev_priv, sw_context, vmw_res_surface,
VMW_RES_DIRTY_NONE, user_surface_converter,
@@ -947,10 +940,7 @@ static int vmw_cmd_buffer_copy_check(struct vmw_private
*dev_priv,
struct vmw_sw_context *sw_context,
SVGA3dCmdHeader *header)
{
- struct {
- SVGA3dCmdHeader header;
- SVGA3dCmdDXBufferCopy body;
- } *cmd;
+ VMW_DECLARE_CMD_VAR(*cmd, SVGA3dCmdDXBufferCopy);
int ret;
cmd = container_of(header, typeof(*cmd), header);
@@ -969,10 +959,7 @@ static int vmw_cmd_pred_copy_check(struct vmw_private
*dev_priv,
struct vmw_sw_context *sw_context,
SVGA3dCmdHeader *header)
{
- struct {
- SVGA3dCmdHeader header;
- SVGA3dCmdDXPredCopyRegion body;
- } *cmd;
+ VMW_DECLARE_CMD_VAR(*cmd, SVGA3dCmdDXPredCopyRegion);
int ret;
cmd = container_of(header, typeof(*cmd), header);
@@ -991,13 +978,10 @@ static int vmw_cmd_stretch_blt_check(struct vmw_private
*dev_priv,
struct vmw_sw_context *sw_context,
SVGA3dCmdHeader *header)
{
- struct vmw_sid_cmd {
- SVGA3dCmdHeader hea
[PATCH 09/11] drm/vmwgfx: Use VMW_DEBUG_USER for device command buffer errors
DRM_ERROR overwhelms dmesgi so use VMW_DEBUG_USER instead. Any malformed
command should not really go to device so WARN_ONCE to spot this.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
index ed15655eacd2..56979e412ca8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
@@ -393,6 +393,7 @@ static void vmw_cmdbuf_ctx_process(struct vmw_cmdbuf_man
*man,
__vmw_cmdbuf_header_free(entry);
break;
case SVGA_CB_STATUS_COMMAND_ERROR:
+ WARN_ONCE(true, "Command buffer error.\n");
entry->cb_header->status = SVGA_CB_STATUS_NONE;
list_add_tail(&entry->list, &man->error);
schedule_work(&man->work);
@@ -533,19 +534,20 @@ static void vmw_cmdbuf_work_func(struct work_struct *work)
global_block = true;
if (!vmw_cmd_describe(header, &error_cmd_size, &cmd_name)) {
- DRM_ERROR("Unknown command causing device error.\n");
- DRM_ERROR("Command buffer offset is %lu\n",
- (unsigned long) cb_hdr->errorOffset);
+ VMW_DEBUG_USER("Unknown command causing device
error.\n");
+ VMW_DEBUG_USER("Command buffer offset is %lu\n",
+ (unsigned long) cb_hdr->errorOffset);
__vmw_cmdbuf_header_free(entry);
send_fence = true;
continue;
}
- DRM_ERROR("Command \"%s\" causing device error.\n", cmd_name);
- DRM_ERROR("Command buffer offset is %lu\n",
- (unsigned long) cb_hdr->errorOffset);
- DRM_ERROR("Command size is %lu\n",
- (unsigned long) error_cmd_size);
+ VMW_DEBUG_USER("Command \"%s\" causing device error.\n",
+ cmd_name);
+ VMW_DEBUG_USER("Command buffer offset is %lu\n",
+ (unsigned long) cb_hdr->errorOffset);
+ VMW_DEBUG_USER("Command size is %lu\n",
+ (unsigned long) error_cmd_size);
new_start_offset = cb_hdr->errorOffset + error_cmd_size;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/11] drm/vmwgfx: Clean up some debug messages in vmwgfx_execbuf.c
Now that vmw_cmd_check prints debug message whenever a command verifier
fails, some of debug statements are unnecessary. Also rearranged some
debug print-out with this patch.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 9df334340146..e7c93f422a7e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -217,7 +217,6 @@ static int vmw_cmd_ctx_first_setup(struct vmw_private
*dev_priv,
sw_context->staged_bindings =
vmw_binding_state_alloc(dev_priv);
if (IS_ERR(sw_context->staged_bindings)) {
- VMW_DEBUG_USER("Failed to alloc ctx binding info.\n");
ret = PTR_ERR(sw_context->staged_bindings);
sw_context->staged_bindings = NULL;
goto out_err;
@@ -227,7 +226,6 @@ static int vmw_cmd_ctx_first_setup(struct vmw_private
*dev_priv,
if (sw_context->staged_bindings_inuse) {
node->staged = vmw_binding_state_alloc(dev_priv);
if (IS_ERR(node->staged)) {
- VMW_DEBUG_USER("Failed to alloc ctx binding info.\n");
ret = PTR_ERR(node->staged);
node->staged = NULL;
goto out_err;
@@ -327,8 +325,10 @@ static int vmw_execbuf_res_noref_val_add(struct
vmw_sw_context *sw_context,
if (priv_size && first_usage) {
ret = vmw_cmd_ctx_first_setup(dev_priv, sw_context, res,
ctx_info);
- if (ret)
+ if (ret) {
+ VMW_DEBUG_USER("Failed first usage context setup.\n");
return ret;
+ }
}
vmw_execbuf_rcache_update(rcache, res, ctx_info);
@@ -421,10 +421,8 @@ vmw_view_id_val_add(struct vmw_sw_context *sw_context,
struct vmw_resource *view;
int ret;
- if (!ctx_node) {
- VMW_DEBUG_USER("DX Context not set.\n");
+ if (!ctx_node)
return ERR_PTR(-EINVAL);
- }
view = vmw_view_lookup(sw_context->man, view_type, id);
if (IS_ERR(view))
@@ -723,10 +721,8 @@ static int vmw_rebind_all_dx_query(struct vmw_resource
*ctx_res)
cmd = vmw_fifo_reserve_dx(dev_priv, sizeof(*cmd), ctx_res->id);
- if (cmd == NULL) {
- VMW_DEBUG_USER("Failed to rebind queries.\n");
+ if (cmd == NULL)
return -ENOMEM;
- }
cmd->header.id = SVGA_3D_CMD_DX_BIND_ALL_QUERY;
cmd->header.size = sizeof(cmd->body);
@@ -761,8 +757,10 @@ static int vmw_rebind_contexts(struct vmw_sw_context
*sw_context)
}
ret = vmw_rebind_all_dx_query(val->ctx);
- if (ret != 0)
+ if (ret != 0) {
+ VMW_DEBUG_USER("Failed to rebind queries.\n");
return ret;
+ }
}
return 0;
@@ -2713,8 +2711,6 @@ static int vmw_cmd_dx_destroy_shader(struct vmw_private
*dev_priv,
ret = vmw_shader_remove(sw_context->man, cmd->body.shaderId, 0,
&sw_context->staged_cmd_res);
- if (ret)
- VMW_DEBUG_USER("Could not find shader to remove.\n");
return ret;
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/11] drm/vmwgfx: Use preprocessor macro for FIFO allocation
Whenever FIFO allocation fails an error message is printed to dmesg.
Since this is common operation a lot of similar messages are scattered
everywhere. Use preprocessor macro to remove this cluttering.
Signed-off-by: Deepak Rawat
Reviewed-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_binding.c | 72
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 55 ++
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 23 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 13 -
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 12 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 27 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c | 9 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 23 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 6 +-
drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 25 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 7 +--
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 20 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c | 37
drivers/gpu/drm/vmwgfx/vmwgfx_so.c | 12 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 35
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 48 +---
17 files changed, 138 insertions(+), 290 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c
index ef1469c4e91f..66e14e38d5e8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c
@@ -499,12 +499,9 @@ static int vmw_binding_scrub_shader(struct
vmw_ctx_bindinfo *bi, bool rebind)
SVGA3dCmdSetShader body;
} *cmd;
- cmd = vmw_fifo_reserve(dev_priv, sizeof(*cmd));
- if (unlikely(cmd == NULL)) {
- DRM_ERROR("Failed reserving FIFO space for shader "
- "unbinding.\n");
+ cmd = VMW_FIFO_RESERVE(dev_priv, sizeof(*cmd));
+ if (unlikely(cmd == NULL))
return -ENOMEM;
- }
cmd->header.id = SVGA_3D_CMD_SET_SHADER;
cmd->header.size = sizeof(cmd->body);
@@ -534,12 +531,9 @@ static int vmw_binding_scrub_render_target(struct
vmw_ctx_bindinfo *bi,
SVGA3dCmdSetRenderTarget body;
} *cmd;
- cmd = vmw_fifo_reserve(dev_priv, sizeof(*cmd));
- if (unlikely(cmd == NULL)) {
- DRM_ERROR("Failed reserving FIFO space for render target "
- "unbinding.\n");
+ cmd = VMW_FIFO_RESERVE(dev_priv, sizeof(*cmd));
+ if (unlikely(cmd == NULL))
return -ENOMEM;
- }
cmd->header.id = SVGA_3D_CMD_SETRENDERTARGET;
cmd->header.size = sizeof(cmd->body);
@@ -576,12 +570,9 @@ static int vmw_binding_scrub_texture(struct
vmw_ctx_bindinfo *bi,
} body;
} *cmd;
- cmd = vmw_fifo_reserve(dev_priv, sizeof(*cmd));
- if (unlikely(cmd == NULL)) {
- DRM_ERROR("Failed reserving FIFO space for texture "
- "unbinding.\n");
+ cmd = VMW_FIFO_RESERVE(dev_priv, sizeof(*cmd));
+ if (unlikely(cmd == NULL))
return -ENOMEM;
- }
cmd->header.id = SVGA_3D_CMD_SETTEXTURESTATE;
cmd->header.size = sizeof(cmd->body);
@@ -610,12 +601,10 @@ static int vmw_binding_scrub_dx_shader(struct
vmw_ctx_bindinfo *bi, bool rebind)
SVGA3dCmdDXSetShader body;
} *cmd;
- cmd = vmw_fifo_reserve_dx(dev_priv, sizeof(*cmd), bi->ctx->id);
- if (unlikely(cmd == NULL)) {
- DRM_ERROR("Failed reserving FIFO space for DX shader "
- "unbinding.\n");
+ cmd = VMW_FIFO_RESERVE_DX(dev_priv, sizeof(*cmd), bi->ctx->id);
+ if (unlikely(cmd == NULL))
return -ENOMEM;
- }
+
cmd->header.id = SVGA_3D_CMD_DX_SET_SHADER;
cmd->header.size = sizeof(cmd->body);
cmd->body.type = binding->shader_slot + SVGA3D_SHADERTYPE_MIN;
@@ -641,12 +630,9 @@ static int vmw_binding_scrub_cb(struct vmw_ctx_bindinfo
*bi, bool rebind)
SVGA3dCmdDXSetSingleConstantBuffer body;
} *cmd;
- cmd = vmw_fifo_reserve_dx(dev_priv, sizeof(*cmd), bi->ctx->id);
- if (unlikely(cmd == NULL)) {
- DRM_ERROR("Failed reserving FIFO space for DX shader "
- "unbinding.\n");
+ cmd = VMW_FIFO_RESERVE_DX(dev_priv, sizeof(*cmd), bi->ctx->id);
+ if (unlikely(cmd == NULL))
return -ENOMEM;
- }
cmd->header.id = SVGA_3D_CMD_DX_SET_SINGLE_CONSTANT_BUFFER;
cmd->header.size = sizeof(cmd->body);
@@ -768,12 +754,9 @@ static int vmw_emit_set_sr(struct vmw_ctx_binding_state
*cbs,
view_id_size = cbs->bind_cmd_count*sizeof(uint32);
cmd_size = sizeof(*cmd) + view_id_size;
- cmd = vmw_fifo_reserve_dx(ctx->dev_priv, cmd_size, ctx->id);
- if (unlikely(cmd == NULL)) {
- DRM_ERROR("Failed reserving FIFO spac
[PATCH 02/11] drm/vmwgfx: Remove set but not used variable 'restart'
From: YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c: In function 'vmw_cmdbuf_work_func':
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:514:7: warning:
variable 'restart' set but not used [-Wunused-but-set-variable]
It not used any more after commit dc366364c4ef ("drm/vmwgfx: Fix multiple
command buffer context use")
Signed-off-by: YueHaibing
Reviewed-by: Deepak Rawat
Signed-off-by: Deepak Rawat
Fixes: dc366364c4ef ("drm/vmwgfx: Fix multiple command buffer context use")
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
index 70dab55e7888..ed15655eacd2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c
@@ -511,17 +511,14 @@ static void vmw_cmdbuf_work_func(struct work_struct *work)
container_of(work, struct vmw_cmdbuf_man, work);
struct vmw_cmdbuf_header *entry, *next;
uint32_t dummy;
- bool restart[SVGA_CB_CONTEXT_MAX];
bool send_fence = false;
struct list_head restart_head[SVGA_CB_CONTEXT_MAX];
int i;
struct vmw_cmdbuf_context *ctx;
bool global_block = false;
- for_each_cmdbuf_ctx(man, i, ctx) {
+ for_each_cmdbuf_ctx(man, i, ctx)
INIT_LIST_HEAD(&restart_head[i]);
- restart[i] = false;
- }
mutex_lock(&man->error_mutex);
spin_lock(&man->lock);
@@ -533,7 +530,6 @@ static void vmw_cmdbuf_work_func(struct work_struct *work)
const char *cmd_name;
list_del_init(&entry->list);
- restart[entry->cb_context] = true;
global_block = true;
if (!vmw_cmd_describe(header, &error_cmd_size, &cmd_name)) {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/11] drm/vmwgfx: remove redundant unlikely annotation
From: Chengguang Xu
unlikely has already included in IS_ERR(), so just
remove redundant unlikely annotation.
Signed-off-by: Chengguang Xu
Reviewed-by: Deepak Rawat
Signed-off-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
index 14bd760a62fd..694fabafaeee 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_context.c
@@ -210,7 +210,7 @@ static int vmw_gb_context_init(struct vmw_private *dev_priv,
for (i = 0; i < SVGA_COTABLE_DX10_MAX; ++i) {
uctx->cotables[i] = vmw_cotable_alloc(dev_priv,
&uctx->res, i);
- if (unlikely(IS_ERR(uctx->cotables[i]))) {
+ if (IS_ERR(uctx->cotables[i])) {
ret = PTR_ERR(uctx->cotables[i]);
goto out_cotables;
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index dc5698fbb654..4955a48a9d86 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -660,7 +660,7 @@ vmw_cmd_res_check(struct vmw_private *dev_priv,
res = vmw_user_resource_noref_lookup_handle
(dev_priv, sw_context->fp->tfile, *id_loc, converter);
- if (unlikely(IS_ERR(res))) {
+ if (IS_ERR(res)) {
DRM_ERROR("Could not find or use resource 0x%08x.\n",
(unsigned int) *id_loc);
return PTR_ERR(res);
@@ -3835,7 +3835,7 @@ static int vmw_execbuf_tie_context(struct vmw_private
*dev_priv,
res = vmw_user_resource_noref_lookup_handle
(dev_priv, sw_context->fp->tfile, handle,
user_context_converter);
- if (unlikely(IS_ERR(res))) {
+ if (IS_ERR(res)) {
DRM_ERROR("Could not find or user DX context 0x%08x.\n",
(unsigned) handle);
return PTR_ERR(res);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/11] drm/vmwgfx: Be more restrictive when dirtying resources
From: Thomas Hellstrom
Currently we flag resources as dirty (GPU contents not yet read back to
the backing MOB) whenever they have been part of a command stream.
Obviously many resources can't be dirty and others can only be dirty when
written to by the GPU. That is when they are either bound to the context as
render-targets, depth-stencil, copy / clear destinations and
stream-output targets, or similarly when there are corresponding views into
them.
So mark resources dirty only in these special cases. Context- and cotable
resources are always marked dirty when referenced.
This is important for upcoming emulated coherent memory, since we can avoid
issuing automatic readbacks to non-dirty resources when the CPU tries to
access part of the backing MOB.
Testing: Unigine Heaven with max GPU memory set to 256MB resulting in
heavy resource thrashing.
---
v2: Addressed review comments by Deepak Rawat.
v3: Added some documentation
Signed-off-by: Thomas Hellstrom
Reviewed-by: Deepak Rawat
---
drivers/gpu/drm/vmwgfx/vmwgfx_binding.c| 26
drivers/gpu/drm/vmwgfx/vmwgfx_binding.h| 2 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 2 +
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 166 +
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 5 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 21 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_so.c | 24 +++
drivers/gpu/drm/vmwgfx/vmwgfx_so.h | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 12 +-
drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 58 +--
drivers/gpu/drm/vmwgfx/vmwgfx_validation.h | 7 +
12 files changed, 234 insertions(+), 93 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c
index 0b9ee7fb45d6..ef1469c4e91f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_binding.c
@@ -1269,6 +1269,32 @@ void vmw_binding_state_reset(struct
vmw_ctx_binding_state *cbs)
vmw_binding_drop(entry);
}
+/**
+ * vmw_binding_dirtying - Return whether a binding type is dirtying its
resource
+ * @binding_type: The binding type
+ *
+ * Each time a resource is put on the validation list as the result of a
+ * context binding referencing it, we need to determine whether that resource
+ * will be dirtied (written to by the GPU) as a result of the corresponding
+ * GPU operation. Currently rendertarget-, depth-stencil-, and
+ * stream-output-target bindings are capable of dirtying its resource.
+ *
+ * Return: Whether the binding type dirties the resource its binding points to.
+ */
+u32 vmw_binding_dirtying(enum vmw_ctx_binding_type binding_type)
+{
+ static u32 is_binding_dirtying[vmw_ctx_binding_max] = {
+ [vmw_ctx_binding_rt] = VMW_RES_DIRTY_SET,
+ [vmw_ctx_binding_dx_rt] = VMW_RES_DIRTY_SET,
+ [vmw_ctx_binding_ds] = VMW_RES_DIRTY_SET,
+ [vmw_ctx_binding_so] = VMW_RES_DIRTY_SET,
+ };
+
+ /* Review this function as new bindings are added. */
+ BUILD_BUG_ON(vmw_ctx_binding_max != 11);
+ return is_binding_dirtying[binding_type];
+}
+
/*
* This function is unused at run-time, and only used to hold various build
* asserts important for code optimization assumptions.
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_binding.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_binding.h
index 6a2a9d69043b..f6ab79d23923 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_binding.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_binding.h
@@ -205,5 +205,7 @@ extern void vmw_binding_state_free(struct
vmw_ctx_binding_state *cbs);
extern struct list_head *
vmw_binding_state_list(struct vmw_ctx_binding_state *cbs);
extern void vmw_binding_state_reset(struct vmw_ctx_binding_state *cbs);
+extern u32 vmw_binding_dirtying(enum vmw_ctx_binding_type binding_type);
+
#endif
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 6302c12c2298..abe975b7ea89 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -699,6 +699,8 @@ extern int vmw_user_stream_lookup(struct vmw_private
*dev_priv,
uint32_t *inout_id,
struct vmw_resource **out);
extern void vmw_resource_unreserve(struct vmw_resource *res,
+ bool dirty_set,
+ bool dirty,
bool switch_backup,
struct vmw_buffer_object *new_backup,
unsigned long new_backup_offset);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 88b8178d4687..dc5698fbb654 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -272,13 +272,15 @@ static void vmw_execbuf_rcache_update(struct
vmw_res_cache_en
[Bug 110339] Cursor hides and reappear in the middle of screen, when moving mouse horizontally
https://bugs.freedesktop.org/show_bug.cgi?id=110339 --- Comment #1 from Pinky --- kernel: Linux 5.1.0-rc2-1-next-git-g7cdd4dc58d28 #5 SMP Fri Apr 5 18:06:31 CEST 2019 x86_64 GNU/Linux -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] drm/panfrost: Expose HW counters to userspace
On Fri, 5 Apr 2019 09:33:55 -0700 Alyssa Rosenzweig wrote: > > Since one of the primary use cases is to draw pretty graphs of the > > system load [1], this "per-job" information isn't all that relevant (and > > minimal performance overhead is important). And if you want to monitor > > just one application it is usually easiest to ensure that it is the only > > thing running. > > Ah-ha, gotch. I don't know why I didn't put 2 and 2 together, but that > definitely makes sense, yeah :) Boris, thoughts? Nothing to add, except, I had the gut feeling I was doing the wrong choice here, hence the mention to this design decision in my cover letter :-). I'll rework the implementation to have perfmons apply globally (instead of being attached to jobs) and get rid of the perfcnt fence. Note that we could support both per-job and global perfmons and avoid the perf penalty when only global perfmons are used, but I don't think it's worth the extra complexity (not to mention that it makes things even more confusing for userspace users). ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110339] Cursor hides and reappear in the middle of screen, when moving mouse horizontally
https://bugs.freedesktop.org/show_bug.cgi?id=110339 Bug ID: 110339 Summary: Cursor hides and reappear in the middle of screen, when moving mouse horizontally Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: j...@seznam.cz Cursor gradually disappears and then reappears at once when moving mouse horizontally. This happends on vertical line exactly in the center of the screen. It creates impression there are 2 tiles on the screen, (left and right). When mouse moves to the right edge of the left tile it gradually "hides" under the one on the right side, when when the cursor is whole on the right tile it "pop ups" again at once. This happends even on external monitor, where resolution is different, it still dissapears exactly in the center of the screen. This does not happends when both monitors are used as outputs (orientation does not matter, they can be left, right, above, bellow of each other or even overlap). I did not find any horizontal line where the cursor "hides". Also in some positions along the central line sometimes some artifacts appears, when the mouse is partialy hidden. They change when the mouse moves in any direction. But those are not always reproducible and in fact are rare. I actually does not have an idea where the bug actually is (can be anywhere along the pipeline including kernel). This is on Lenovo A485 notebook with Arch linux. mesa 19.0.1 xf86-video-amdgpu-git-19.0.1.0 [lspci] 06:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev d1) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #75 from Diego Viola --- (In reply to Diego Viola from comment #72) > (In reply to Michel Dänzer from comment #51) > > The working hypothesis is that it's a Mesa regression between 18.3 and 19.0, > > so that makes sense? > > That was a mistake from my part, sorry. > > Setting 'export MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage"' after > startx still makes xterm work fine even after startx (from a running Xorg > session). > > Sorry for the confusion. Replied to the wrong comment, this was supposed to be a reply to #68. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/5] drm/stm: dw_mipi_dsi-stm: add support of an optional regulator
On 4/3/19 10:16 AM, Yannick Fertré wrote:
> Add support of an optional regulator for the phy part of the DSI
> controller.
>
> Signed-off-by: Yannick Fertré
> ---
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> index a672b59..84703d0 100644
> --- a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> +++ b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -76,6 +77,7 @@ struct dw_mipi_dsi_stm {
> u32 hw_version;
> int lane_min_kbps;
> int lane_max_kbps;
> + struct regulator *vdd_supply;
> };
>
> static inline void dsi_write(struct dw_mipi_dsi_stm *dsi, u32 reg, u32 val)
> @@ -318,16 +320,32 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
> *pdev)
> return PTR_ERR(dsi->base);
> }
>
> + dsi->vdd_supply = devm_regulator_get_optional(dev, "phy-dsi");
> + if (IS_ERR(dsi->vdd_supply)) {
> + ret = PTR_ERR(dsi->vdd_supply);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev, "failed to request regulator: %d\n", ret);
> + return ret;
> + }
> +
> + ret = regulator_enable(dsi->vdd_supply);
> + if (ret) {
> + dev_err(dev, "failed to enable regulator: %d\n", ret);
> + return ret;
> + }
> +
> dsi->pllref_clk = devm_clk_get(dev, "ref");
> if (IS_ERR(dsi->pllref_clk)) {
> ret = PTR_ERR(dsi->pllref_clk);
> dev_err(dev, "Unable to get pll reference clock: %d\n", ret);
> + regulator_disable(dsi->vdd_supply);
> return ret;
> }
>
> ret = clk_prepare_enable(dsi->pllref_clk);
> if (ret) {
> dev_err(dev, "%s: Failed to enable pllref_clk\n", __func__);
> + regulator_disable(dsi->vdd_supply);
> return ret;
> }
>
> @@ -339,6 +357,7 @@ static int dw_mipi_dsi_stm_probe(struct platform_device
> *pdev)
> dsi->dsi = dw_mipi_dsi_probe(pdev, &dw_mipi_dsi_stm_plat_data);
> if (IS_ERR(dsi->dsi)) {
> DRM_ERROR("Failed to initialize mipi dsi host\n");
> + regulator_disable(dsi->vdd_supply);
> clk_disable_unprepare(dsi->pllref_clk);
> return PTR_ERR(dsi->dsi);
> }
> @@ -351,6 +370,7 @@ static int dw_mipi_dsi_stm_remove(struct platform_device
> *pdev)
> struct dw_mipi_dsi_stm *dsi = platform_get_drvdata(pdev);
>
> clk_disable_unprepare(dsi->pllref_clk);
> + regulator_disable(dsi->vdd_supply);
Dear Yannick,
Acked-by: Philippe Cornu
Philippe
> dw_mipi_dsi_remove(dsi->dsi);
>
> return 0;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/5] dt-bindings: display: stm32: add supply property to DSI controller
On 4/3/19 10:16 AM, Yannick Fertré wrote:
> This patch adds documentation of a new property phy-dsi-supply to the
> STM32 DSI controller.
>
> Signed-off-by: Yannick Fertré
> ---
> Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
> b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
> index 3eb1b48..60c54da 100644
> --- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
> +++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt
> @@ -40,6 +40,8 @@ Mandatory nodes specific to STM32 DSI:
> - panel or bridge node: A node containing the panel or bridge description as
> documented in [6].
> - port: panel or bridge port node, connected to the DSI output port
> (port@1).
> +Optional properties:
> +- phy-dsi-supply: phandle of the regulator that provides the supply voltage.
>
> Note: You can find more documentation in the following references
> [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> @@ -101,6 +103,7 @@ Example 2: DSI panel
> clock-names = "pclk", "ref";
> resets = <&rcc STM32F4_APB2_RESET(DSI)>;
> reset-names = "apb";
> + phy-dsi-supply = <®18>;
Dear Yannick,
Thank you for your patch,
Reviewed-by: Philippe Cornu
Philippe :)
>
> ports {
> #address-cells = <1>;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: ltdc: add modifier support
On 4/3/19 11:25 AM, Yannick Fertré wrote:
> Signed-off-by: Mickael Reulier
> Signed-off-by: Yannick Fertré
> ---
> drivers/gpu/drm/stm/ltdc.c | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index b1741a9..6fa8fbc 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -232,6 +232,11 @@ static const enum ltdc_pix_fmt ltdc_pix_fmt_a1[NB_PF] = {
> PF_ARGB /* 0x07 */
> };
>
> +static const u64 ltdc_format_modifiers[] = {
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
> static inline u32 reg_read(void __iomem *base, u32 reg)
> {
> return readl_relaxed(base + reg);
> @@ -864,6 +869,16 @@ static void ltdc_plane_atomic_print_state(struct
> drm_printer *p,
> fpsi->counter = 0;
> }
>
> +static bool ltdc_plane_format_mod_supported(struct drm_plane *plane,
> + u32 format,
> + u64 modifier)
> +{
> + if (modifier == DRM_FORMAT_MOD_LINEAR)
> + return true;
> +
> + return false;
> +}
> +
> static const struct drm_plane_funcs ltdc_plane_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> @@ -872,6 +887,7 @@ static const struct drm_plane_funcs ltdc_plane_funcs = {
> .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> .atomic_print_state = ltdc_plane_atomic_print_state,
> + .format_mod_supported = ltdc_plane_format_mod_supported,
> };
>
> static const struct drm_plane_helper_funcs ltdc_plane_helper_funcs = {
> @@ -890,6 +906,7 @@ static struct drm_plane *ltdc_plane_create(struct
> drm_device *ddev,
> unsigned int i, nb_fmt = 0;
> u32 formats[NB_PF * 2];
> u32 drm_fmt, drm_fmt_no_alpha;
> + const u64 *modifiers = ltdc_format_modifiers;
> int ret;
>
> /* Get supported pixel formats */
> @@ -918,7 +935,7 @@ static struct drm_plane *ltdc_plane_create(struct
> drm_device *ddev,
>
> ret = drm_universal_plane_init(ddev, plane, possible_crtcs,
> -NULL, type, NULL);
> +modifiers, type, NULL);
> if (ret < 0)
> return NULL;
>
> @@ -1179,6 +1196,8 @@ int ltdc_load(struct drm_device *ddev)
> goto err;
> }
>
> + ddev->mode_config.allow_fb_modifiers = true;
> +
Acked-by: Philippe Cornu
Philippe :)
> ret = ltdc_crtc_init(ddev, crtc);
> if (ret) {
> DRM_ERROR("Failed to init crtc\n");
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: ltdc: reset controller to avoid partial refresh
On 4/3/19 11:24 AM, Yannick Fertré wrote:
> Display controller reset must be done as soon as possible after enable
> the clock to avoid partial refresh on screen.
>
> Signed-off-by: Yannick Fertré
> ---
> drivers/gpu/drm/stm/ltdc.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index 32fd6a3..7bbe61c 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -1134,6 +1134,12 @@ int ltdc_load(struct drm_device *ddev)
> return -ENODEV;
> }
>
> + if (!IS_ERR(rstc)) {
> + reset_control_assert(rstc);
> + usleep_range(10, 20);
> + reset_control_deassert(rstc);
> + }
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> ldev->regs = devm_ioremap_resource(dev, res);
> if (IS_ERR(ldev->regs)) {
> @@ -1156,12 +1162,6 @@ int ltdc_load(struct drm_device *ddev)
> }
> }
>
> - if (!IS_ERR(rstc)) {
> - reset_control_assert(rstc);
> - usleep_range(10, 20);
> - reset_control_deassert(rstc);
> - }
> -
Dear Yannick,
Thank you for your patch,
Acked-by: Philippe Cornu
Philippe :)
> /* Disable interrupts */
> reg_clear(ldev->regs, LTDC_IER,
> IER_LIE | IER_RRIE | IER_FUIE | IER_TERRIE);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/stm: ltdc: limit number of layer to avoid memory overflow
Dear Yannick, Thank you for your patch, Acked-by: Philippe Cornu Philippe :) On 4/3/19 11:20 AM, Yannick Fertré wrote: > If the number of layer is greater than LTDC_MAX_LAYER, we can have > memory overflow when reading plane_fpsi[]. > > Signed-off-by: Yannick Fertré > --- > drivers/gpu/drm/stm/ltdc.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c > index 32fd6a3..05bd4b6 100644 > --- a/drivers/gpu/drm/stm/ltdc.c > +++ b/drivers/gpu/drm/stm/ltdc.c > @@ -1021,10 +1021,13 @@ static int ltdc_get_caps(struct drm_device *ddev) > struct ltdc_device *ldev = ddev->dev_private; > u32 bus_width_log2, lcr, gc2r; > > - /* at least 1 layer must be managed */ > + /* > + * at least 1 layer must be managed & the number of layers > + * must not exceed LTDC_MAX_LAYER > + */ > lcr = reg_read(ldev->regs, LTDC_LCR); > > - ldev->caps.nb_layers = max_t(int, lcr, 1); > + ldev->caps.nb_layers = clamp((int)lcr, 1, LTDC_MAX_LAYER); > > /* set data bus width */ > gc2r = reg_read(ldev->regs, LTDC_GC2R); > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [v2 0/7] Add Multi Segment Gamma Support
On Mon, Apr 01, 2019 at 11:00:04PM +0530, Uma Shankar wrote: > This series adds support for programmable gamma modes and > exposes a property interface for the same. Also added, > support for multi segment gamma mode introduced in ICL+ > > It creates 2 property interfaces : > 1. GAMMA_MODE_CAPS: This is immutable property and exposes > the various gamma modes supported and the lut ranges. This > is an enum property with element as blob id. Getting the > blob id in userspace, user can get the mode supported and > also the range of gamma mode supported with number of lut > coefficients. > > 2. GAMMA_MODE: This is for user to set the gamma mode and > send the lut values for that particular mode. I think we should just go for the BLOB_ENUM prop type instead. Then the possible values and the current value are all part of the same prop. > > v2: Used Ville's design and approach to define the interfaces. > Addressed Matt Roper's review feedback and re-ordered the > patches. > > Uma Shankar (5): > drm: Add gamma mode property > drm/i915/icl: Add register definitions for Multi Segmented gamma > drm/i915/icl: Add support for multi segmented gamma mode > drm/i915: Add gamma mode caps property > drm/i915: Attach gamma mode property > > Ville Syrjälä (2): > drm: Add gamma mode caps property > drm/i915: Define color lut range structure > > drivers/gpu/drm/drm_atomic_uapi.c| 13 + > drivers/gpu/drm/drm_color_mgmt.c | 110 + > drivers/gpu/drm/i915/i915_reg.h | 17 ++ > drivers/gpu/drm/i915/intel_color.c | 465 > ++- > drivers/gpu/drm/i915/intel_display.c | 5 + > include/drm/drm_color_mgmt.h | 11 + > include/drm/drm_crtc.h | 17 ++ > include/drm/drm_mode_config.h| 10 + > include/uapi/drm/drm_mode.h | 49 > 9 files changed, 690 insertions(+), 7 deletions(-) > > -- > 1.9.1 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Assistance with a problem related to GEM and Atomic Commit inside vkms
On Wed, Apr 03, 2019 at 04:35:11PM -0300, Rodrigo Siqueira wrote: > Hi, > > I’m working to add writeback support to vkms; you can see my current > patch at the end of this email (some prints highlight the issue that I’m > asking for help here). I’m using the Liviu Dudau and Brian Starkey IGT > patchset, which can be seen here: > https://patchwork.freedesktop.org/series/39229/. > > I’m stuck with a problem that happens in my vkms_wb_atomic_commit() > function, which is a helper function at drm_connector_helper_funcs. You > can see the full implementation of this function at the end of this > email, but here is the important part: > > struct drm_framebuffer *fb = conn_state->writeback_job->fb; > struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0); > struct vkms_gem_object *vkms_obj = drm_gem_to_vkms_gem(gem_obj); > > A few lines after this variable initialization, I try to make a memory > copy like this: > > memcpy(vkms_conn->writeback_vaddr, vkms_obj->vaddr, vkms_obj->gem.size); > > If I test my implementation with the subtest writeback-fb-id, everything > work as expected; for extra details, this is the dmesg output after this > test and with a debug print: > > => writeback-fb-id > > [Apr 3 11:30] CIFS: Attempting to mount //10.0.2.4/qemu > [ +1.601900] Console: switching to colour dummy device 80x25 > [ +0.17] [IGT] kms_writeback: executing > [ +0.032532] [IGT] kms_writeback: starting subtest writeback-fb-id > [ +0.001932] VKMS_OBJ (1): Buff (1) - Vaddr (1) - Size = 1228800 - count = 1 > [ +0.050524] [IGT] kms_writeback: exiting, ret=0 > [ +0.005202] Console: switching to colour frame buffer device 100x37 > > In the above log, you can see the print info; notice that Vaddr is the > output of vkms_obj->vaddr (Vaddr -> vkms_obj->vaddr != NULL). On the > other hand, if I try the subtest writeback-check-output, something weird > happens in this function. Here is the dmesg output for this test: > > => writeback-check-output > > [ +29.911185] Console: switching to colour dummy device 80x25 > [ +0.17] [IGT] kms_writeback: executing > [ +0.021289] [IGT] kms_writeback: starting subtest writeback-check-output > [ +0.016270] VKMS_OBJ (1): Buff (1) - Vaddr (0) - Size = 1228800 - count = 0 > [ +0.05] BUG: unable to handle kernel NULL pointer dereference at > > [ +0.04] #PF error: [normal kernel read fault] > [ +0.01] PGD 0 P4D 0 > [ +0.03] Oops: [#1] PREEMPT SMP PTI > [ +0.02] CPU: 3 PID: 426 Comm: kms_writeback Not tainted > 5.0.0-VKMS-RULES+ #102 > [ +0.02] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > 1.12.0-20181126_142135-anatol 04/01/2014 > [ +0.21] RIP: 0010:__memcpy+0x12/0x20 > [ +0.02] Code: ff 0f 31 48 c1 e2 20 48 09 c2 48 31 d3 e9 79 ff ff ff 90 > 90 90 90 90 90 0f 1f 44 00 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 > a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4 > [ +0.01] RSP: 0018:adaf0098fbd8 EFLAGS: 00010246 > [ +0.02] RAX: 9f1bf540 RBX: 9f1bfa28df00 RCX: > 00025800 > [ +0.01] RDX: RSI: RDI: > 9f1bf540 > [ +0.01] RBP: 0001 R08: 0017818788be R09: > adaf0098fb60 > [ +0.01] R10: 9f1bfffdc998 R11: a25ec401 R12: > 9f1b777ff430 > [ +0.01] R13: c06558b8 R14: c06853c0 R15: > c0685520 > [ +0.02] FS: 7f2862deae80() GS:9f1bfc98() > knlGS: > [ +0.01] CS: 0010 DS: ES: CR0: 80050033 > [ +0.01] CR2: CR3: baf6c000 CR4: > 06e0 > [ +0.04] Call Trace: > [ +0.23] drm_atomic_helper_commit_modeset_enables+0x15d/0x1e0 > [drm_kms_helper] > [ +0.28] drm_atomic_helper_commit_tail+0x31/0x60 [drm_kms_helper] > [ +0.08] commit_tail+0x58/0x70 [drm_kms_helper] > [ +0.08] drm_atomic_helper_commit+0x103/0x110 [drm_kms_helper] > [ +0.40] drm_mode_atomic_ioctl+0x829/0x950 [drm] > [ +0.12] ? drm_atomic_set_property+0x960/0x960 [drm] > [ +0.29] drm_ioctl_kernel+0xb2/0xf0 [drm] > [ +0.11] drm_ioctl+0x25f/0x3f0 [drm] > [ +0.09] ? drm_atomic_set_property+0x960/0x960 [drm] > [ +0.04] ? n_tty_open+0xa0/0xa0 > [ +0.04] do_vfs_ioctl+0xa4/0x630 > [ +0.03] ksys_ioctl+0x60/0x90 > [ +0.03] ? ksys_write+0x4f/0xb0 > [ +0.02] __x64_sys_ioctl+0x16/0x20 > [ +0.03] do_syscall_64+0x5b/0x170 > [ +0.03] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ +0.02] RIP: 0033:0x7f286677580b > [ +0.01] Code: 0f 1e fa 48 8b 05 55 b6 0c 00 64 c7 00 26 00 00 00 48 c7 > c0 ff > > Notice that Vaddr became NULL for some reason that I cannot understand. Just missing the .prepare_writeback_job() hook? -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/
[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #74 from Diego Viola --- (In reply to Diego Viola from comment #65) > Just to make it a bit more clear: > > If I set that environment variable while I'm already on X: > > export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" > > It has no effect on Xephyr (from current git master), i.e. xterm still shows > the bug. This comment is completely wrong, ignore it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/panfrost: Expose HW counters to userspace
Alyssa Rosenzweig writes:
>> @@ -55,6 +63,15 @@ struct drm_panfrost_submit {
>>
>> /** A combination of PANFROST_JD_REQ_* */
>> __u32 requirements;
>> +
>> +/** Pointer to a u32 array of perfmons that should be attached to the
>> job. */
>> +__u64 perfmon_handles;
>> +
>> +/** Number of perfmon handles passed in (size is that times 4). */
>> +__u32 perfmon_handle_count;
>> +
>> +/** Unused field, should be set to 0. */
>> +__u32 padding;
>
> Bleep blorp. If we're modifying _submit, we'll need to be swift about
> merging this ahead of the main code to make sure we don't break the
> UABI. Although I guess if we're just adding fields at the end, that's a
> nonissue.
You can extend ioctl structs safely. When older userspace passes theirs
in, it has the shorter length encoded in the cmd. The kernel allocates
the newest version's space, copies in the shorter struct, and
zero-extends the rest.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #73 from Diego Viola --- Sorry for the confusing comments. export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" makes xterm always work with Xpehyr git, no matter if I set that variable before or after startx. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #72 from Diego Viola --- (In reply to Michel Dänzer from comment #51) > The working hypothesis is that it's a Mesa regression between 18.3 and 19.0, > so that makes sense? That was a mistake from my part, sorry. Setting 'export MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage"' after startx still makes xterm work fine even after startx (from a running Xorg session). Sorry for the confusion. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #71 from Marek Olšák --- (In reply to Michel Dänzer from comment #69) > (In reply to Marek Olšák from comment #67) > > Primitives aren't reordered with DPBB. Primitives can't also survive a > > barrier with DPBB. DPBB has no effect on behavior, it just changes how PS > > wavefronts are formed. > > Is there any way that could affect the glamor shader which samples from one > area of a buffer and draws to another (non-overlapping) area of the same > buffer? As long as the blits are truly non-overlapping, DPBB doesn't affect it. > > What is the reason for radeonsi disabling DPBB for blits? because it's not useful for blits and it might add latency because of binning. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #70 from Diego Viola --- (In reply to Michel Dänzer from comment #68) > (In reply to Diego Viola from comment #65) > > If I set that environment variable while I'm already on X: > > By "X" I assume you mean Xorg here? Yes, Xorg. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Assistance with a problem related to GEM and Atomic Commit inside vkms
On Wed, Apr 03, 2019 at 04:35:11PM -0300, Rodrigo Siqueira wrote: > Hi, Hi Rodrigo, > > I’m working to add writeback support to vkms; you can see my current > patch at the end of this email (some prints highlight the issue that I’m > asking for help here). I’m using the Liviu Dudau and Brian Starkey IGT > patchset, which can be seen here: > https://patchwork.freedesktop.org/series/39229/. > > I’m stuck with a problem that happens in my vkms_wb_atomic_commit() > function, which is a helper function at drm_connector_helper_funcs. You > can see the full implementation of this function at the end of this > email, but here is the important part: > > struct drm_framebuffer *fb = conn_state->writeback_job->fb; > struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0); > struct vkms_gem_object *vkms_obj = drm_gem_to_vkms_gem(gem_obj); > > A few lines after this variable initialization, I try to make a memory > copy like this: > > memcpy(vkms_conn->writeback_vaddr, vkms_obj->vaddr, vkms_obj->gem.size); > > If I test my implementation with the subtest writeback-fb-id, everything > work as expected; for extra details, this is the dmesg output after this > test and with a debug print: > > => writeback-fb-id > > [Apr 3 11:30] CIFS: Attempting to mount //10.0.2.4/qemu > [ +1.601900] Console: switching to colour dummy device 80x25 > [ +0.17] [IGT] kms_writeback: executing > [ +0.032532] [IGT] kms_writeback: starting subtest writeback-fb-id > [ +0.001932] VKMS_OBJ (1): Buff (1) - Vaddr (1) - Size = 1228800 - count = 1 > [ +0.050524] [IGT] kms_writeback: exiting, ret=0 > [ +0.005202] Console: switching to colour frame buffer device 100x37 > > In the above log, you can see the print info; notice that Vaddr is the > output of vkms_obj->vaddr (Vaddr -> vkms_obj->vaddr != NULL). On the > other hand, if I try the subtest writeback-check-output, something weird > happens in this function. Here is the dmesg output for this test: > > => writeback-check-output > > [ +29.911185] Console: switching to colour dummy device 80x25 > [ +0.17] [IGT] kms_writeback: executing > [ +0.021289] [IGT] kms_writeback: starting subtest writeback-check-output > [ +0.016270] VKMS_OBJ (1): Buff (1) - Vaddr (0) - Size = 1228800 - count = 0 > [ +0.05] BUG: unable to handle kernel NULL pointer dereference at > > [ +0.04] #PF error: [normal kernel read fault] > [ +0.01] PGD 0 P4D 0 > [ +0.03] Oops: [#1] PREEMPT SMP PTI > [ +0.02] CPU: 3 PID: 426 Comm: kms_writeback Not tainted > 5.0.0-VKMS-RULES+ #102 > [ +0.02] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > 1.12.0-20181126_142135-anatol 04/01/2014 > [ +0.21] RIP: 0010:__memcpy+0x12/0x20 > [ +0.02] Code: ff 0f 31 48 c1 e2 20 48 09 c2 48 31 d3 e9 79 ff ff ff 90 > 90 90 90 90 90 0f 1f 44 00 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 > a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4 > [ +0.01] RSP: 0018:adaf0098fbd8 EFLAGS: 00010246 > [ +0.02] RAX: 9f1bf540 RBX: 9f1bfa28df00 RCX: > 00025800 > [ +0.01] RDX: RSI: RDI: > 9f1bf540 > [ +0.01] RBP: 0001 R08: 0017818788be R09: > adaf0098fb60 > [ +0.01] R10: 9f1bfffdc998 R11: a25ec401 R12: > 9f1b777ff430 > [ +0.01] R13: c06558b8 R14: c06853c0 R15: > c0685520 > [ +0.02] FS: 7f2862deae80() GS:9f1bfc98() > knlGS: > [ +0.01] CS: 0010 DS: ES: CR0: 80050033 > [ +0.01] CR2: CR3: baf6c000 CR4: > 06e0 > [ +0.04] Call Trace: > [ +0.23] drm_atomic_helper_commit_modeset_enables+0x15d/0x1e0 > [drm_kms_helper] > [ +0.28] drm_atomic_helper_commit_tail+0x31/0x60 [drm_kms_helper] > [ +0.08] commit_tail+0x58/0x70 [drm_kms_helper] > [ +0.08] drm_atomic_helper_commit+0x103/0x110 [drm_kms_helper] > [ +0.40] drm_mode_atomic_ioctl+0x829/0x950 [drm] > [ +0.12] ? drm_atomic_set_property+0x960/0x960 [drm] > [ +0.29] drm_ioctl_kernel+0xb2/0xf0 [drm] > [ +0.11] drm_ioctl+0x25f/0x3f0 [drm] > [ +0.09] ? drm_atomic_set_property+0x960/0x960 [drm] > [ +0.04] ? n_tty_open+0xa0/0xa0 > [ +0.04] do_vfs_ioctl+0xa4/0x630 > [ +0.03] ksys_ioctl+0x60/0x90 > [ +0.03] ? ksys_write+0x4f/0xb0 > [ +0.02] __x64_sys_ioctl+0x16/0x20 > [ +0.03] do_syscall_64+0x5b/0x170 > [ +0.03] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ +0.02] RIP: 0033:0x7f286677580b > [ +0.01] Code: 0f 1e fa 48 8b 05 55 b6 0c 00 64 c7 00 26 00 00 00 48 c7 > c0 ff This call stack looks strange! drm_atomic_set_property() (if that is right function being called) should not end up calling drm_atomic_helper_commit(). I would start by trying to get the actual call function trace to see what is going on. Best regards, Liviu > >
[Bug 110337] Mesa 19.0.0(1)
https://bugs.freedesktop.org/show_bug.cgi?id=110337 Michel Dänzer changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org Component|Mesa core |Drivers/Gallium/radeonsi QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #69 from Michel Dänzer --- (In reply to Marek Olšák from comment #67) > Primitives aren't reordered with DPBB. Primitives can't also survive a > barrier with DPBB. DPBB has no effect on behavior, it just changes how PS > wavefronts are formed. Is there any way that could affect the glamor shader which samples from one area of a buffer and draws to another (non-overlapping) area of the same buffer? What is the reason for radeonsi disabling DPBB for blits? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #68 from Michel Dänzer --- (In reply to Diego Viola from comment #65) > If I set that environment variable while I'm already on X: By "X" I assume you mean Xorg here? > export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" > > It has no effect on Xephyr (from current git master), i.e. xterm still shows > the bug. Did you set the variable before starting Xephyr though, so it was set in the Xephyr process? If yes, that makes things confusing again, just when it seemed like they were starting to make sense... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 5/5] drm/cirrus: rewrite and modernize driver.
Den 05.04.2019 11.52, skrev Gerd Hoffmann: > Time to kill some bad sample code people are copying from ;) > > This is a complete rewrite of the cirrus driver. The cirrus_mode_set() > function is pretty much the only function which is carried over largely > unmodified. Everything else is upside down. > > It is a single monster patch. But given that it does some pretty > fundamental changes to the drivers workflow and also reduces the code > size by roughly 70% I think it'll still be alot easier to review than a > longish baby-step patch series. > > Changes summary: > - Given the small amout of video memory (4 MB) the cirrus device has >the rewritten driver doesn't try to manage buffers there. Instead >it will blit (memcpy) the active framebuffer to video memory. > - All gem objects are stored in main memory and are manged using the >new shmem helpers. ttm is out. > - It supports RG16, RG24 and XR24 formats. XR24 gets converted to RG24 >or RG16 at blit time if needed, to avoid the pitch becoming larger >than what the cirrus hardware can handle. > - The simple display pipeline is used. > - The generic fbdev emulation is used. > - It's a atomic driver now. > - It runs wayland. > > Signed-off-by: Gerd Hoffmann > --- Acked-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/lima: Fix broken compilation.
> On Apr 4, 2019, at 6:39 PM, Dave Airlie wrote: > >> On Fri, 5 Apr 2019 at 08:43, Rodrigo Vivi wrote: >> >>> On Thu, Apr 04, 2019 at 03:25:38PM -0700, Rodrigo Vivi wrote: >>> From: Rodrigo Vivi >> >> And it seems that I don't know how to spell my own name anymore! :) >> >> If you decide for this patch please let me know, so we can fix while >> pushing to drm-misc-fixes or tell me to send a v2. >> >>> >>> I'm not entirely sure about the limits we should use >>> here on ARM based driver, but apparently the entry and limit >>> are inverted and UINT_MAX cannot be used directly there. >>> >>> So let's at least for now fix this compilation issue >>> on a compilation only driver: > > I ended up writing this as well and squashing it into the merge into drm-next. Cool, thanks > > Thanks, > Dave. > >>> >>> CC [M] drivers/gpu/drm/lima/lima_ctx.o >>> In file included from ./include/linux/kernel.h:7, >>> from ./include/asm-generic/bug.h:18, >>> from ./arch/x86/include/asm/bug.h:83, >>> from ./include/linux/bug.h:5, >>> from ./include/linux/mmdebug.h:5, >>> from ./include/linux/gfp.h:5, >>> from ./include/linux/slab.h:15, >>> from drivers/gpu/drm/lima/lima_ctx.c:4: >>> drivers/gpu/drm/lima/lima_ctx.c: In function ‘lima_ctx_create’: >>> ./include/linux/limits.h:13:18: error: incompatible type for argument 4 of >>> ‘xa_alloc’ >>> #define UINT_MAX (~0U) >>> ^ >>> drivers/gpu/drm/lima/lima_ctx.c:27:41: note: in expansion of macro >>> ‘UINT_MAX’ >>> err = xa_alloc(&mgr->handles, id, ctx, UINT_MAX, GFP_KERNEL); >>> ^~~~ >>> In file included from ./include/linux/radix-tree.h:31, >>> from ./include/linux/idr.h:15, >>> from ./include/drm/drm_device.h:7, >>> from drivers/gpu/drm/lima/lima_device.h:7, >>> from drivers/gpu/drm/lima/lima_ctx.c:7: >>> ./include/linux/xarray.h:817:32: note: expected ‘struct xa_limit’ but >>> argument is of type ‘unsigned int’ >>> void *entry, struct xa_limit limit, gfp_t gfp) >>>^ >>> make[4]: *** [scripts/Makefile.build:276: drivers/gpu/drm/lima/lima_ctx.o] >>> Error 1 >>> make[3]: *** [scripts/Makefile.build:486: drivers/gpu/drm/lima] Error 2 >>> make[2]: *** [scripts/Makefile.build:486: drivers/gpu/drm] Error 2 >>> make[1]: *** [scripts/Makefile.build:486: drivers/gpu] Error 2 >>> make: *** [Makefile:1051: drivers] Error 2 >>> >>> Cc: Qiang Yu >>> Signed-off-by: Rodrigo Vivi >>> --- >>> drivers/gpu/drm/lima/lima_ctx.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/lima/lima_ctx.c >>> b/drivers/gpu/drm/lima/lima_ctx.c >>> index c8d12f7c6894..22fff6caa961 100644 >>> --- a/drivers/gpu/drm/lima/lima_ctx.c >>> +++ b/drivers/gpu/drm/lima/lima_ctx.c >>> @@ -23,7 +23,7 @@ int lima_ctx_create(struct lima_device *dev, struct >>> lima_ctx_mgr *mgr, u32 *id) >>> goto err_out0; >>> } >>> >>> - err = xa_alloc(&mgr->handles, id, UINT_MAX, ctx, GFP_KERNEL); >>> + err = xa_alloc(&mgr->handles, id, ctx, xa_limit_32b, GFP_KERNEL); >>> if (err < 0) >>> goto err_out0; >>> >>> -- >>> 2.20.1 >>> >> ___ >> 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
[Bug 109957] radeon: DisplayPort Out of range 1280x800x59.91
https://bugs.freedesktop.org/show_bug.cgi?id=109957 --- Comment #4 from Ricardo Ribalda --- Created attachment 143880 --> https://bugs.freedesktop.org/attachment.cgi?id=143880&action=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #67 from Marek Olšák --- (In reply to Michel Dänzer from comment #63) > (In reply to Diego Viola from comment #62) > > export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" > > > > This helps alleviate the problem (xterm does not have the issue with this), > > however, the problem is still present in Xephyr. > > To clarify, you mean Xephyr from xserver 1.16 here (where glamor didn't make > use of GL_NV_texture_barrier yet), disabling GL_NV_texture_barrier helps > with current Xephyr, right? > > It seems like DPBB needs to be disabled when glTextureBarrier(NV) is called, > otherwise primitives may be reordered across the barrier. Does that make > sense, Marek? Primitives aren't reordered with DPBB. Primitives can't also survive a barrier with DPBB. DPBB has no effect on behavior, it just changes how PS wavefronts are formed. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109957] radeon: DisplayPort Out of range 1280x800x59.91
https://bugs.freedesktop.org/show_bug.cgi?id=109957 --- Comment #3 from Ricardo Ribalda --- Created attachment 143879 --> https://bugs.freedesktop.org/attachment.cgi?id=143879&action=edit Dmesg with drm.debug=0x3f -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/5] drm: add drm_fb_xrgb8888_to_rgb888_dstclip()
Den 05.04.2019 11.52, skrev Gerd Hoffmann: > Simliar to drm_fb_xrgb_to_rgb565_dstclip() but converts to rgb888 Simliar -> Similar > instead of rgb565. > > Signed-off-by: Gerd Hoffmann > --- Reviewed-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/5] drm: add drm_fb_xrgb8888_to_rgb565_dstclip()
Den 05.04.2019 11.52, skrev Gerd Hoffmann: > It is a drm_fb_xrgb_to_rgb565() variant which checks the clip > rectangle for the destination too. > > Common code between drm_fb_xrgb_to_rgb565() and > drm_fb_xrgb_to_rgb565_dstclip() was factored out into the > drm_fb_xrgb_to_rgb565_lines() helper function. > > Signed-off-by: Gerd Hoffmann > --- Reviewed-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/5] drm: add drm_fb_memcpy_dstclip() helper
Den 05.04.2019 11.52, skrev Gerd Hoffmann: > It is a drm_fb_memcpy() variant which checks the clip rectangle for the > destination too. > > Common code between drm_fb_memcpy() and drm_fb_memcpy_dstclip() was > factored out into the drm_fb_memcpy_lines() helper function. > > Signed-off-by: Gerd Hoffmann > --- Reviewed-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/5] drm: move tinydrm format conversion helpers to new drm_format_helper.c
Den 05.04.2019 11.52, skrev Gerd Hoffmann: > Also rename them from tinydrm_* to drm_fb_* > Pure code motion, no functional change. > > Signed-off-by: Gerd Hoffmann > --- Thanks for doing this! Reviewed-by: Noralf Trønnes ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/i915: Don't panic on non-empty list of free cachelines
From: Janusz Krzysztofik If there are active users of a device during driver unbind, the driver now panics on non-empty list of free cachelines. By design, cachelines which are not in use are kept on a list of free cachelines associated with a timeline and removed from that list either when in use or when the timeline is destroyed. Timelines in turn are assigned to open file descriptors. As long as a device file is open, its associated timeline with its list of free cachelines will be hopefully destroyed on device close, either while outstanding execlists are destroyed or on i915_timeline_put() called directly, so as long as device file descriptors are protected from unwanted user activities by the device being marked unplugged, there should be no reason to panic. Moreover, timeline mutex which is destroyed right after the check for emptyness of a free cacheline list succeeds is never used to protect that list, only a list of active cachelines, so it can be freely destroyed even if the former is not empty. Since the desired behavior is to clean up active contexts first, unpinning the contexts and resources, and so letting the timeline be freed, the panic is there to say that i915_timelines_fini() is called to early. Don't remove the check completely then but convert it from the BUG() to a WARN() so the indication a long term fix is needed is still given. Signed-off-by: Janusz Krzysztofik --- drivers/gpu/drm/i915/i915_timeline.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_timeline.c b/drivers/gpu/drm/i915/i915_timeline.c index b2202d2e58a2..965fd3052b25 100644 --- a/drivers/gpu/drm/i915/i915_timeline.c +++ b/drivers/gpu/drm/i915/i915_timeline.c @@ -325,7 +325,7 @@ void i915_timelines_fini(struct drm_i915_private *i915) struct i915_gt_timelines *gt = &i915->gt.timelines; GEM_BUG_ON(!list_empty(>->active_list)); - GEM_BUG_ON(!list_empty(>->hwsp_free_list)); + GEM_WARN_ON(!list_empty(>->hwsp_free_list)); mutex_destroy(>->mutex); } -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/udl: move to embedding drm device inside udl device.
On Thu, Apr 4, 2019 at 11:17 PM Dave Airlie wrote:
>
> From: Dave Airlie
>
> This should help with some of the lifetime issues, and move us away
> from load/unload.
>
> Signed-off-by: Dave Airlie
Not too familiar with the usb interface stuff, but it seems to be
doing the right thing. Patches 1, 2 are:
Reviewed-by: Alex Deucher
Patch 3:
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/udl/udl_drv.c | 56 +++---
> drivers/gpu/drm/udl/udl_drv.h | 9 +++---
> drivers/gpu/drm/udl/udl_fb.c | 2 +-
> drivers/gpu/drm/udl/udl_main.c | 23 ++
> 4 files changed, 53 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> index ff47f890e6ad..15c0e3eeaf3b 100644
> --- a/drivers/gpu/drm/udl/udl_drv.c
> +++ b/drivers/gpu/drm/udl/udl_drv.c
> @@ -48,10 +48,16 @@ static const struct file_operations udl_driver_fops = {
> .llseek = noop_llseek,
> };
>
> +static void udl_driver_release(struct drm_device *dev)
> +{
> + udl_fini(dev);
> + udl_modeset_cleanup(dev);
> + drm_dev_fini(dev);
> + kfree(dev);
> +}
> +
> static struct drm_driver driver = {
> .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
> - .load = udl_driver_load,
> - .unload = udl_driver_unload,
> .release = udl_driver_release,
>
> /* gem hooks */
> @@ -75,28 +81,56 @@ static struct drm_driver driver = {
> .patchlevel = DRIVER_PATCHLEVEL,
> };
>
> +static struct udl_device *udl_driver_create(struct usb_interface *interface)
> +{
> + struct usb_device *udev = interface_to_usbdev(interface);
> + struct udl_device *udl;
> + int r;
> +
> + udl = kzalloc(sizeof(struct udl_device), GFP_KERNEL);
> + if (!udl)
> + return ERR_PTR(-ENOMEM);
> +
> + r = drm_dev_init(&udl->drm, &driver, &interface->dev);
> + if (r) {
> + kfree(udl);
> + return ERR_PTR(r);
> + }
> +
> + udl->udev = udev;
> + udl->drm.dev_private = udl;
> +
> + r = udl_init(udl);
> + if (r) {
> + drm_dev_fini(&udl->drm);
> + kfree(udl);
> + return ERR_PTR(r);
> + }
> +
> + usb_set_intfdata(interface, udl);
> + return udl;
> +}
> +
> +
> static int udl_usb_probe(struct usb_interface *interface,
> const struct usb_device_id *id)
> {
> - struct usb_device *udev = interface_to_usbdev(interface);
> - struct drm_device *dev;
> int r;
>
> - dev = drm_dev_alloc(&driver, &interface->dev);
> - if (IS_ERR(dev))
> - return PTR_ERR(dev);
> + struct udl_device *udl = udl_driver_create(interface);
> + if (IS_ERR(udl))
> + return PTR_ERR(udl);
>
> - r = drm_dev_register(dev, (unsigned long)udev);
> + r = drm_dev_register(&udl->drm, 0);
> if (r)
> goto err_free;
>
> - usb_set_intfdata(interface, dev);
> - DRM_INFO("Initialized udl on minor %d\n", dev->primary->index);
> + DRM_INFO("Initialized udl on minor %d\n", udl->drm.primary->index);
>
> return 0;
>
> err_free:
> - drm_dev_put(dev);
> + drm_dev_put(&udl->drm);
> return r;
> }
>
> diff --git a/drivers/gpu/drm/udl/udl_drv.h b/drivers/gpu/drm/udl/udl_drv.h
> index b3e08e876d62..35c1f33fbc1a 100644
> --- a/drivers/gpu/drm/udl/udl_drv.h
> +++ b/drivers/gpu/drm/udl/udl_drv.h
> @@ -50,8 +50,8 @@ struct urb_list {
> struct udl_fbdev;
>
> struct udl_device {
> + struct drm_device drm;
> struct device *dev;
> - struct drm_device *ddev;
> struct usb_device *udev;
> struct drm_crtc *crtc;
>
> @@ -71,7 +71,7 @@ struct udl_device {
> atomic_t cpu_kcycles_used; /* transpired during pixel processing */
> };
>
> -#define to_udl(x) ((x)->dev_private)
> +#define to_udl(x) container_of(x, struct udl_device, drm)
>
> struct udl_gem_object {
> struct drm_gem_object base;
> @@ -104,9 +104,8 @@ struct urb *udl_get_urb(struct drm_device *dev);
> int udl_submit_urb(struct drm_device *dev, struct urb *urb, size_t len);
> void udl_urb_completion(struct urb *urb);
>
> -int udl_driver_load(struct drm_device *dev, unsigned long flags);
> -void udl_driver_unload(struct drm_device *dev);
> -void udl_driver_release(struct drm_device *dev);
> +int udl_init(struct udl_device *udl);
> +void udl_fini(struct drm_device *dev);
>
> int udl_fbdev_init(struct drm_device *dev);
> void udl_fbdev_cleanup(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
> index 590323ea261f..4ab101bf1df0 100644
> --- a/drivers/gpu/drm/udl/udl_fb.c
> +++ b/drivers/gpu/drm/udl/udl_fb.c
> @@ -213,7 +213,7 @@ static int udl_fb_open(struct fb_info *info, int user)
> struct udl_device *udl = to_udl(dev);
>
> /* If the USB device is gone, we don't accept new opens */
> -
[PATCH 2/2] drm/i915: Mark GEM wedged right after marking device unplugged
As soon as a device is considered unplugged, not only prevent pending users from accessing the device structures but also cancel all their pending requests so all consumed resources can be cleaned up as soon as possible. Suggested-by: Chris Wilson Signed-off-by: Janusz Krzysztofik Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 66163378c481..03a563ce7e6b 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1598,6 +1598,13 @@ static void i915_driver_unregister(struct drm_i915_private *dev_priv) i915_teardown_sysfs(dev_priv); drm_dev_unplug(&dev_priv->drm); + /* +* After unregistering the device to prevent any new users, cancel +* all in-flight requests so that we can quickly unbind the active +* resources. +*/ + i915_gem_set_wedged(dev_priv); + i915_gem_shrinker_unregister(dev_priv); } -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/i915: Use drm_dev_unplug()
From: Janusz Krzysztofik The driver does not currently support unbinding from a device which is in use. Since open file descriptors may still be pointing into kernel memory where the device structures used to be, entirely correct kernel panics protect the driver from being unbound as we should not be unbinding it before those dangling pointers have been made safe. According to the documentation found inside drivers/gpu/drm/drm_drv.c, drm_dev_unplug() should be used instead of drm_dev_unregister() in order to make a device inaccessible to users as soon as it is unpluged. Follow that advice to make those possibly dangling pointers safe, protected by DRM layer from a user who is otherwise left pointing into possibly reused kernel memory after the driver has been unbound from the device. Once done, also cancel inflight operations immediately by calling i915_gem_set_wedged(). Signed-off-by: Janusz Krzysztofik Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 9df65d386d11..66163378c481 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1596,7 +1596,7 @@ static void i915_driver_unregister(struct drm_i915_private *dev_priv) i915_pmu_unregister(dev_priv); i915_teardown_sysfs(dev_priv); - drm_dev_unregister(&dev_priv->drm); + drm_dev_unplug(&dev_priv->drm); i915_gem_shrinker_unregister(dev_priv); } -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] Stop users from using the device on driver unbind
Use drm_dev_unplug() to have device resources protected from user access by DRM layer as soon as the driver is going to be unbound. Also, cancel all pending work so associated resources can be quickly released. Janusz Krzysztofik (2): drm/i915: Use drm_dev_unplug() drm/i915: Mark GEM wedged right after marking device unplugged drivers/gpu/drm/i915/i915_drv.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) I'm resending these two patches together in series to make the robot happy about the second one. Also, I've added the Suggested-by: clause to credit actual Chris' contribution. Thanks, Janusz -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/3] drm/panfrost: Add initial panfrost driver
On 03/04/2019 05:57, Rob Herring wrote:
[...]
+static int panfrost_clk_init(struct panfrost_device *pfdev)
+{
+ int err;
+ unsigned long rate;
+
+ pfdev->clock = devm_clk_get(pfdev->dev, NULL);
+ if (IS_ERR(pfdev->clock)) {
The DT binding says clocks are optional, but this doesn't treat them as
such.
Hum, I would think effectively clocks are always there and necessary
for thermal reasons.
Should the binding be updated to move clocks from "optional" to
"required" then? Juno does actually have a GPU clock for DVFS, but the
clk-scmi driver didn't seem to want to play nicely with either
mali_kbase or panfrost DRM, so I've just been leaving it out of my DT
for now (and mali_kbase was perfectly happy without).
+ spin_lock_init(&pfdev->mm_lock);
+
+ /* 4G enough for now. can be 48-bit */
+ drm_mm_init(&pfdev->mm, SZ_32M >> PAGE_SHIFT, SZ_4G);
You probably want a dma_set_mask_and_coherent() call for your 'real'
output address size somewhere - the default 32-bit mask works out OK for
RK3399, but on systems with RAM above 4GB io-pgtable will get very
unhappy about DMA bounce-buffering.
Yes, I have a todo for figuring out the # of physaddr bits in the mmu
setup (as this call is just relevant to the input address side).
Though maybe just calling dma_set_mask_and_coherent() is enough and I
don't need to know the exact number of output bits for the io-pgtable
setup?
True, io-pgtable itself only really depends on the input size, but in
order for non-coherent pagtables to work correctly in general, the DMA
mask does need to be set appropriately, at which point it may as well
also be propagated into OAS for completeness (as we do in arm-smmu*).
FWIW I'm just gonna leave this quote here...
gpu_props->mmu.va_bits = KBASE_UBFX32(raw->mmu_features, 0U, 8);
gpu_props->mmu.pa_bits = KBASE_UBFX32(raw->mmu_features, 8U, 8);
Robin.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Documentation/gpu/meson: Remove link to meson_canvas.c
On Fri, Apr 05, 2019 at 02:14:35PM +0200, Neil Armstrong wrote:
> On 04/04/2019 16:31, Sean Paul wrote:
> > On Thu, Apr 04, 2019 at 10:28:29AM +0200, Neil Armstrong wrote:
> >> On 04/04/2019 08:56, Neil Armstrong wrote:
> >>> On 03/04/2019 22:56, Sean Paul wrote:
> From: Sean Paul
>
> The file was removed in the below patch and is causing this error:
> WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno -function
> Canvas ../drivers/gpu/drm/meson/meson_canvas.c' failed with return code
>
> Fixes: 2bf6b5b0e374 ("drm/meson: exclusively use the canvas provider
> module")
> Cc: Maxime Jourdan
> Cc: Neil Armstrong
> Cc: Kevin Hilman
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Sean Paul
> ---
> Documentation/gpu/meson.rst | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/Documentation/gpu/meson.rst b/Documentation/gpu/meson.rst
> index 479f6f51a13b..b9e2f9aa3bd8 100644
> --- a/Documentation/gpu/meson.rst
> +++ b/Documentation/gpu/meson.rst
> @@ -42,12 +42,6 @@ Video Encoder
> .. kernel-doc:: drivers/gpu/drm/meson/meson_venc.c
> :doc: Video Encoder
>
> -Video Canvas Management
> -===
> -
> -.. kernel-doc:: drivers/gpu/drm/meson/meson_canvas.c
> - :doc: Canvas
> -
> Video Clocks
>
>
>
> >>>
> >>> Acked-by: Neil Armstrong
> >>>
> >>
> >> Applied to drm-misc-fixes
> >
> > Hmm, the commit referenced in the Fixes line hasn't landed in -fixes yet,
> > it's
> > in -next. So the fix has landed before the bug :(
>
> Seems I'll still need to apply it to -next !
I've just applied it, thanks for staying on top of this.
Sean
>
> Neil
>
> >
> > I'll ping mripard on irc and see what he wants to do about this.
> >
> > Sean
> >
> >>
> >> Neil
> >
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #66 from Diego Viola --- (In reply to Diego Viola from comment #65) > Just to make it a bit more clear: > > If I set that environment variable while I'm already on X: > > export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" > > It has no effect on Xephyr (from current git master), i.e. xterm still shows > the bug. xterm still shows the bug in Xephyr from git if that environment was set later (while X was running). Works fine with both (Xephyr git and X) if the environment variable was set before startx. Please let me know if you have more questions. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/i915: Don't panic on non-empty list of free cachelines
On Fri, 2019-04-05 at 13:20 +0100, Chris Wilson wrote: > Quoting Janusz Krzysztofik (2019-04-05 13:13:31) > > From: Janusz Krzysztofik > > > > If there are active users of a device during driver unbind, the > > driver > > now panics on non-empty list of free cachelines. > > This panic is there to say that fini is being called with active > contexts, that it is being called too early. Those requests should be > cleaned up first, unpinning the contexts and resources, and so > letting > the timeline be freed. OK, I see. But why panic? Maybe a WARN() would be enough. Thanks, Janusz > -Chris > ___ > 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
[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #65 from Diego Viola --- Just to make it a bit more clear: If I set that environment variable while I'm already on X: export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" It has no effect on Xephyr (from current git master), i.e. xterm still shows the bug. However, if I set before `startx`. It works with both, X and Xephyr (from git master), i.e. xterm works fine. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 05/13] drivers: create binary sysfs for class
On Fri, Apr 05, 2019 at 04:06:22PM +0530, Ramalingam C wrote: > On 2019-04-05 at 11:23:00 +0200, Greg Kroah-Hartman wrote: > > On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote: > > > Functions to create and remove the binary sysfs for class are added. > > > > > > These are getting introduced as DRM wants to create the common binary > > > sysfs across the drm subsystem to handle hdcp srm. > > > > Why do you need individual files? That's almost always a sign that you > > are going to race with userspace in a bad way. Why not just use an > > attribute group which provides automatic support for this? > Greg, > > Reason behind this move is to have a common srm entry path across all drm > drivers. And the data fed into this is binary blob. So I am creating a > binary sysfs "hdcp_srm" at /sys/class/drm/ Ah, you want to have a file in your class directory, not your class device directory. No, please do not do that. There's a reason I got rid of those same types of apis in the past. And "binary blobs" are horrid anyway, they are only to be used as a pass-through to the device itself, from the kernel, no touching the data at all. If you really need/want this, then put it in the device's directory as that is where the data is going to, not the kernel "class" code as it sure as heck better not be doing anything with it. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/i915: Don't panic on non-empty list of free cachelines
Quoting Janusz Krzysztofik (2019-04-05 13:13:31) > From: Janusz Krzysztofik > > If there are active users of a device during driver unbind, the driver > now panics on non-empty list of free cachelines. This panic is there to say that fini is being called with active contexts, that it is being called too early. Those requests should be cleaned up first, unpinning the contexts and resources, and so letting the timeline be freed. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 --- Comment #64 from Diego Viola --- (In reply to Michel Dänzer from comment #63) > (In reply to Diego Viola from comment #62) > > export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" > > > > This helps alleviate the problem (xterm does not have the issue with this), > > however, the problem is still present in Xephyr. > > To clarify, you mean Xephyr from xserver 1.16 here (where glamor didn't make > use of GL_NV_texture_barrier yet), disabling GL_NV_texture_barrier helps > with current Xephyr, right? Yes, that's correct. If I set `export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" ` before running `startx`, xterm works fine either in X or Xephyr (from git master). > > It seems like DPBB needs to be disabled when glTextureBarrier(NV) is called, > otherwise primitives may be reordered across the barrier. Does that make > sense, Marek? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Documentation/gpu/meson: Remove link to meson_canvas.c
On 04/04/2019 16:31, Sean Paul wrote:
> On Thu, Apr 04, 2019 at 10:28:29AM +0200, Neil Armstrong wrote:
>> On 04/04/2019 08:56, Neil Armstrong wrote:
>>> On 03/04/2019 22:56, Sean Paul wrote:
From: Sean Paul
The file was removed in the below patch and is causing this error:
WARNING: kernel-doc '../scripts/kernel-doc -rst -enable-lineno -function
Canvas ../drivers/gpu/drm/meson/meson_canvas.c' failed with return code
Fixes: 2bf6b5b0e374 ("drm/meson: exclusively use the canvas provider
module")
Cc: Maxime Jourdan
Cc: Neil Armstrong
Cc: Kevin Hilman
Cc: dri-devel@lists.freedesktop.org
Cc: linux-amlo...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Sean Paul
---
Documentation/gpu/meson.rst | 6 --
1 file changed, 6 deletions(-)
diff --git a/Documentation/gpu/meson.rst b/Documentation/gpu/meson.rst
index 479f6f51a13b..b9e2f9aa3bd8 100644
--- a/Documentation/gpu/meson.rst
+++ b/Documentation/gpu/meson.rst
@@ -42,12 +42,6 @@ Video Encoder
.. kernel-doc:: drivers/gpu/drm/meson/meson_venc.c
:doc: Video Encoder
-Video Canvas Management
-===
-
-.. kernel-doc:: drivers/gpu/drm/meson/meson_canvas.c
- :doc: Canvas
-
Video Clocks
>>>
>>> Acked-by: Neil Armstrong
>>>
>>
>> Applied to drm-misc-fixes
>
> Hmm, the commit referenced in the Fixes line hasn't landed in -fixes yet, it's
> in -next. So the fix has landed before the bug :(
Seems I'll still need to apply it to -next !
Neil
>
> I'll ping mripard on irc and see what he wants to do about this.
>
> Sean
>
>>
>> Neil
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm/i915: Don't panic on non-empty list of free cachelines
From: Janusz Krzysztofik If there are active users of a device during driver unbind, the driver now panics on non-empty list of free cachelines. By design, chachelines which are not in use are kept on a list of free chachelines associated with a timeline and rmoved from that list either when in use or when the timeline is destroyed. Timelines in turn are assigned to open file descriptors. As long as a device file is open, its associated timeline with its list of free cachelines will be hopefully destroyed on device close, either while outstanding execlists are destroyed or on i915_timeline_put() called directly, so as long as device file descriptors are protected from unwanted user activities by the device being marked unplugged, there should be no reason to panic. Moreover, timeline mutex which is destroyed right after the check for emptyness of a free cacheline list succeeds is never used to protect that list, only a list of active cachelines, so it can be freely destroyed even if the former is not empty. Simply remove the GEM_BUG_ON(!list_empty(>->hwsp_free_list)); line from i915_timelines_fini(). Signed-off-by: Janusz Krzysztofik --- drivers/gpu/drm/i915/i915_timeline.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_timeline.c b/drivers/gpu/drm/i915/i915_timeline.c index b2202d2e58a2..1f23c2dcc0da 100644 --- a/drivers/gpu/drm/i915/i915_timeline.c +++ b/drivers/gpu/drm/i915/i915_timeline.c @@ -325,7 +325,6 @@ void i915_timelines_fini(struct drm_i915_private *i915) struct i915_gt_timelines *gt = &i915->gt.timelines; GEM_BUG_ON(!list_empty(>->active_list)); - GEM_BUG_ON(!list_empty(>->hwsp_free_list)); mutex_destroy(>->mutex); } -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 13/13] drm/i915: Populate downstream info for HDCP
On 2019-04-05 at 14:13:02 +0530, Ramalingam C wrote:
> Implements drm blob property content_protection_downstream_info
> property on HDCP capable connectors.
>
> Downstream topology info is gathered across authentication stages
> and stored in intel_hdcp. When HDCP authentication is complete,
> new blob with latest downstream topology information is updated to
> content_protection_downstream_info property.
>
> v2:
> %s/cp_downstream/content_protection_downstream [daniel]
> v3:
> %s/content_protection_downstream/hdcp_topology [daniel]
> v4:
> Rebased.
Daniel,
Hope I have done enough explicit padding struct hdcp_topology_info.
Please correct me if i am still missing something.
For populating the structure for the blob, as you sugegsted this patch
is not using the separate functions. IMHO I feel usage is very minimal,
separate functions might not be justified here. Hope you are fine with
that.
-Ram
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_drv.h | 2 +
> drivers/gpu/drm/i915/intel_hdcp.c | 87 ++-
> include/drm/drm_hdcp.h| 1 +
> 3 files changed, 76 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index e387e842f414..6a321a56ce42 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -482,6 +482,8 @@ struct intel_hdcp {
> wait_queue_head_t cp_irq_queue;
> atomic_t cp_irq_count;
> int cp_irq_count_cached;
> +
> + struct hdcp_topology_info *topology_info;
> };
>
> struct intel_connector {
> diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
> b/drivers/gpu/drm/i915/intel_hdcp.c
> index f70f1e98e4ae..6993bb9ecd0b 100644
> --- a/drivers/gpu/drm/i915/intel_hdcp.c
> +++ b/drivers/gpu/drm/i915/intel_hdcp.c
> @@ -490,9 +490,10 @@ int intel_hdcp_validate_v_prime(struct
> intel_digital_port *intel_dig_port,
>
> /* Implements Part 2 of the HDCP authorization procedure */
> static
> -int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
> -const struct intel_hdcp_shim *shim)
> +int intel_hdcp_auth_downstream(struct intel_hdcp *hdcp,
> +struct intel_digital_port *intel_dig_port)
> {
> + const struct intel_hdcp_shim *shim = hdcp->shim;
> u8 bstatus[2], num_downstream, *ksv_fifo;
> int ret, i, tries = 3;
>
> @@ -523,6 +524,9 @@ int intel_hdcp_auth_downstream(struct intel_digital_port
> *intel_dig_port,
> if (num_downstream == 0)
> return -EINVAL;
>
> + hdcp->topology_info->device_count = num_downstream;
> + hdcp->topology_info->depth = DRM_HDCP_DEPTH(bstatus[1]);
> +
> ksv_fifo = kcalloc(DRM_HDCP_KSV_LEN, num_downstream, GFP_KERNEL);
> if (!ksv_fifo)
> return -ENOMEM;
> @@ -536,6 +540,8 @@ int intel_hdcp_auth_downstream(struct intel_digital_port
> *intel_dig_port,
> return -EPERM;
> }
>
> + memcpy(hdcp->topology_info->ksv_list, ksv_fifo,
> +num_downstream * DRM_HDCP_KSV_LEN);
> /*
>* When V prime mismatches, DP Spec mandates re-read of
>* V prime atleast twice.
> @@ -562,9 +568,11 @@ int intel_hdcp_auth_downstream(struct intel_digital_port
> *intel_dig_port,
> }
>
> /* Implements Part 1 of the HDCP authorization procedure */
> -static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
> -const struct intel_hdcp_shim *shim)
> +static int intel_hdcp_auth(struct intel_connector *connector)
> {
> + struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
> + struct intel_hdcp *hdcp = &connector->hdcp;
> + const struct intel_hdcp_shim *shim = hdcp->shim;
> struct drm_i915_private *dev_priv;
> enum port port;
> unsigned long r0_prime_gen_start;
> @@ -635,15 +643,20 @@ static int intel_hdcp_auth(struct intel_digital_port
> *intel_dig_port,
> return -EPERM;
> }
>
> + hdcp->topology_info->ver_in_force = DRM_MODE_HDCP14_IN_FORCE;
> + memcpy(hdcp->topology_info->bksv, bksv.shim, DRM_MODE_HDCP_KSV_LEN);
> +
> I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
> I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
>
> ret = shim->repeater_present(intel_dig_port, &repeater_present);
> if (ret)
> return ret;
> - if (repeater_present)
> + if (repeater_present) {
> I915_WRITE(HDCP_REP_CTL,
> intel_hdcp_get_repeater_ctl(intel_dig_port));
> + hdcp->topology_info->is_repeater = true;
> + }
>
> ret = shim->toggle_signalling(intel_dig_port, true);
> if (ret)
> @@ -708,7 +721,7 @@ static int intel_hdcp_auth(struct intel_digital_port
> *intel_dig_port,
>*/
>
> if (repeater_present)
> - return intel_hdcp_auth_downstream(intel_dig_port, shim);
> + return in
[PATCH] drm/i915: Mark GEM wedged right after marking device unplugged
As soon as a device is considered unplugged, not only prevent pending users from accessing the device structures but also cancel all their pending requests so all consumed resources can be cleaned up as soon as possible. Signed-off-by: Janusz Krzysztofik Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 66163378c481..03a563ce7e6b 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1598,6 +1598,13 @@ static void i915_driver_unregister(struct drm_i915_private *dev_priv) i915_teardown_sysfs(dev_priv); drm_dev_unplug(&dev_priv->drm); + /* +* After unregistering the device to prevent any new users, cancel +* all in-flight requests so that we can quickly unbind the active +* resources. +*/ + i915_gem_set_wedged(dev_priv); + i915_gem_shrinker_unregister(dev_priv); } -- 2.20.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Use drm_dev_unplug()
On Fri, 2019-04-05 at 09:24 +0100, Chris Wilson wrote: > Quoting Janusz Krzysztofik (2019-04-05 09:11:54) > > On Fri, 2019-04-05 at 08:41 +0100, Chris Wilson wrote: > > > Quoting Janusz Krzysztofik (2019-04-05 08:26:57) > > > > From: Janusz Krzysztofik > > > > > > > > The driver does not currently support unbinding from a device > > > > which > > > > is > > > > in use. Since open file descriptors may still be pointing into > > > > kernel > > > > memory where the device structures used to be, entirely correct > > > > kernel > > > > panics protect the driver from being unbound as we should not > > > > be > > > > unbinding it before those dangling pointers have been made > > > > safe. > > > > > > > > According to the documentation found inside > > > > drivers/gpu/drm/drm_drv.c, > > > > drm_dev_unplug() should be used instead of drm_dev_unregister() > > > > in > > > > order to make a device inaccessible to users as soon as it is > > > > unpluged. > > > > Follow that advice to make those possibly dangling pointers > > > > safe, > > > > protected by DRM layer from a user who is otherwise left > > > > pointing > > > > into > > > > possibly reused kernel memory after the driver has been unbound > > > > from > > > > the device. > > > > > > > > Signed-off-by: Janusz Krzysztofik > > > > > > > > --- > > > > drivers/gpu/drm/i915/i915_drv.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c > > > > b/drivers/gpu/drm/i915/i915_drv.c > > > > index 9df65d386d11..66163378c481 100644 > > > > --- a/drivers/gpu/drm/i915/i915_drv.c > > > > +++ b/drivers/gpu/drm/i915/i915_drv.c > > > > @@ -1596,7 +1596,7 @@ static void i915_driver_unregister(struct > > > > drm_i915_private *dev_priv) > > > > i915_pmu_unregister(dev_priv); > > > > > > > > i915_teardown_sysfs(dev_priv); > > > > - drm_dev_unregister(&dev_priv->drm); > > > > + drm_dev_unplug(&dev_priv->drm); > > > > > > I think we may have our onion inverted here. We want to stop the > > > users > > > as the first step, then start removing the entries. (That will > > > also > > > nicely invert the order from register, which is what we typically > > > expect). > > > > > > After calling i915_driver_unregister(); call > > > i915_gem_set_wedged() to > > > immediately (give or take external fences) cancel inflight > > > operations. > > > > OK, thanks. Do you prefer them squashed or as serparate patches? > > Quite happy to do the s/unregister/unplug/ and move in one go. Have a > pre-emptive > Reviewed-by: Chris Wilson > on that as that seems to be the right thing to do. > > And there should be no issues in placing a i915_gem_set_wedged() > immediately after the call to i915_driver_unregister, so if you > include > a line of commentary about why, for example > > /* > * After unregistering the device to prevent any new users, cancel > * all in-flight requests so that we can quickly unbind the active > * resources. > */ > i915_gem_set_wedged(dev_priv); > > Reviewed-by: Chris Wilson I've given it some testing, no side effects with test workloads I've tried, and looks like it at least helps to prevent from making the device actually wedged. With these two patches, plus the one we discussed yesterday, and yet another one I'm going to submit soon, I'm now able to unbind the driver from a device while a workload is running on it, unload the module, reload it and successfully perform basic GEM health checks, all in a quick succession :-). Unfortunately, not 100% reproducible, as well as not the case with device unplug simulated by writing 1 to device/remove sysfs file. Surely that needs the work you describe below to be done first. Thanks for your cooperation, Janusz > > I think overall though, we need to go through i915_driver_unload() > and > push the module cleanup operations to i915_driver_release -- that > will > take a bit of surgery to separate the different phases that are > currently smashed together. > -Chris > ___ > 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: [PATCH] drm: aspeed: Select CMA only if available
Den 05.04.2019 07.28, skrev Joel Stanley:
> When building this driver for architectures where CMA is not available.
>
> Fixes: 4f2a8f5898ec ("drm: Add ASPEED GFX driver")
> Reported-by: Stephen Rothwell
> Reported-by: kernel test robot
> Signed-off-by: Joel Stanley
> ---
> This fixes the build break.
>
> Another question is if we need to select this at all, as we have a
> reserved memory region to allocate from. I am not familiar with this
> area, so advice is welcome.
>
> drivers/gpu/drm/aspeed/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/aspeed/Kconfig b/drivers/gpu/drm/aspeed/Kconfig
> index 42b74d18a41b..1775fb85ec74 100644
> --- a/drivers/gpu/drm/aspeed/Kconfig
> +++ b/drivers/gpu/drm/aspeed/Kconfig
> @@ -4,8 +4,8 @@ config DRM_ASPEED_GFX
> select DRM_KMS_HELPER
> select DRM_KMS_CMA_HELPER
> select DRM_PANEL
> - select DMA_CMA
> - select CMA
> + select DMA_CMA if HAVE_DMA_CONTIGUOUS
> + select CMA if HAVE_DMA_CONTIGUOUS
I'm no expert on this, but the rule is that you should not select
options that are user visible which both of these are. The user should
select them. So I believe that you should remove them.
Docs: Documentation/kbuild/kconfig-language.txt
Noralf.
> select MFD_SYSCON
> help
> Chose this option if you have an ASPEED AST2500 SOC Display
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110327] [exynos-drm] failed to presentate a dumb buffer format NV12 with modifier DRM_FORMAT_MOD_SAMSUNG_64_32_TILE
https://bugs.freedesktop.org/show_bug.cgi?id=110327 --- Comment #2 from Jens Ziller --- Created attachment 143878 --> https://bugs.freedesktop.org/attachment.cgi?id=143878&action=edit complete dmesg out The added dmesg out is complete from boot. The warning during boot is new. I never see it before. v4l2-drm-test runs like before. My code is on github. It's ugly code. Much things are hardcoded. It's only for testing. https://github.com/zillevdr/v4l2-drm-test -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 05/13] drivers: create binary sysfs for class
On 2019-04-05 at 11:23:00 +0200, Greg Kroah-Hartman wrote: > On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote: > > Functions to create and remove the binary sysfs for class are added. > > > > These are getting introduced as DRM wants to create the common binary > > sysfs across the drm subsystem to handle hdcp srm. > > Why do you need individual files? That's almost always a sign that you > are going to race with userspace in a bad way. Why not just use an > attribute group which provides automatic support for this? Greg, Reason behind this move is to have a common srm entry path across all drm drivers. And the data fed into this is binary blob. So I am creating a binary sysfs "hdcp_srm" at /sys/class/drm/ Thanks, Ram. > > thanks, > > greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] iommu: io-pgtable: Add ARM Mali midgard MMU page table format
On 01/04/2019 20:11, Robin Murphy wrote:
On 01/04/2019 08:47, Rob Herring wrote:
ARM Mali midgard GPU is similar to standard 64-bit stage 1 page
tables, but
have a few differences. Add a new format type to represent the format.
The
input address size is 48-bits and the output address size is 40-bits (and
possibly less?). Note that the later bifrost GPUs follow the standard
64-bit stage 1 format.
The differences in the format compared to 64-bit stage 1 format are:
The 3rd level page entry bits are 0x1 instead of 0x3 for page entries.
The access flags are not read-only and unprivileged, but read and write.
This is similar to stage 2 entries, but the memory attributes field
matches
stage 1 being an index.
The nG bit is not set by the vendor driver. This one didn't seem to
matter,
but we'll keep it aligned to the vendor driver.
Cc: Will Deacon
Cc: Robin Murphy
Cc: Joerg Roedel
Cc: linux-arm-ker...@lists.infradead.org
Cc: io...@lists.linux-foundation.org
Signed-off-by: Rob Herring
---
Please ack this as I need to apply it to the drm-misc tree. Or we need a
stable branch with this patch.
With the diff below squashed in to address my outstanding style nits,
Acked-by: Robin Murphy
I don't foresee any conflicting io-pgtable changes to prevent this going
via DRM, but I'll leave the final say up to Joerg.
Urgh, sorry, turns out I flipped one condition too many there. On
reflection I may also forget my clever trick in future and inadvertently
break it, so it probably warrants a comment. Please supersede my
previous request with the (actually tested) diff below :)
Thanks,
Robin.
->8-
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 98551d0cff59..4f7be5a3e19b 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -197,12 +197,13 @@ struct arm_lpae_io_pgtable {
typedef u64 arm_lpae_iopte;
-static inline bool iopte_leaf(arm_lpae_iopte pte, int l, enum
io_pgtable_fmt fmt)
+static inline bool iopte_leaf(arm_lpae_iopte pte, int lvl,
+ enum io_pgtable_fmt fmt)
{
- if ((l == (ARM_LPAE_MAX_LEVELS - 1)) && (fmt != ARM_MALI_LPAE))
- return iopte_type(pte,l) == ARM_LPAE_PTE_TYPE_PAGE;
+ if (lvl == (ARM_LPAE_MAX_LEVELS - 1) && fmt != ARM_MALI_LPAE)
+ return iopte_type(pte, lvl) == ARM_LPAE_PTE_TYPE_PAGE;
- return iopte_type(pte,l) == ARM_LPAE_PTE_TYPE_BLOCK;
+ return iopte_type(pte, lvl) == ARM_LPAE_PTE_TYPE_BLOCK;
}
static arm_lpae_iopte paddr_to_iopte(phys_addr_t paddr,
@@ -310,12 +311,9 @@ static void __arm_lpae_init_pte(struct
arm_lpae_io_pgtable *data,
if (data->iop.cfg.quirks & IO_PGTABLE_QUIRK_ARM_NS)
pte |= ARM_LPAE_PTE_NS;
- if (lvl == ARM_LPAE_MAX_LEVELS - 1) {
- if (data->iop.fmt == ARM_MALI_LPAE)
- pte |= ARM_LPAE_PTE_TYPE_BLOCK;
- else
- pte |= ARM_LPAE_PTE_TYPE_PAGE;
- } else
+ if (data->iop.fmt != ARM_MALI_LPAE && lvl == ARM_LPAE_MAX_LEVELS - 1)
+ pte |= ARM_LPAE_PTE_TYPE_PAGE;
+ else
pte |= ARM_LPAE_PTE_TYPE_BLOCK;
if (data->iop.fmt != ARM_MALI_LPAE)
@@ -452,7 +450,10 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct
arm_lpae_io_pgtable *data,
if (prot & IOMMU_WRITE)
pte |= ARM_LPAE_PTE_HAP_WRITE;
}
-
+ /*
+* Note that this logic is structured to accommodate Mali LPAE
+* having stage-1-like attributes but stage-2-like permissions.
+*/
if (data->iop.fmt == ARM_64_LPAE_S2 ||
data->iop.fmt == ARM_32_LPAE_S2) {
if (prot & IOMMU_MMIO)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/lima: Fix broken compilation.
Thanks, I'm OK with this patch. Regards, Qiang On Fri, Apr 5, 2019 at 9:39 AM Dave Airlie wrote: > > On Fri, 5 Apr 2019 at 08:43, Rodrigo Vivi wrote: > > > > On Thu, Apr 04, 2019 at 03:25:38PM -0700, Rodrigo Vivi wrote: > > > From: Rodrigo Vivi > > > > And it seems that I don't know how to spell my own name anymore! :) > > > > If you decide for this patch please let me know, so we can fix while > > pushing to drm-misc-fixes or tell me to send a v2. > > > > > > > > I'm not entirely sure about the limits we should use > > > here on ARM based driver, but apparently the entry and limit > > > are inverted and UINT_MAX cannot be used directly there. > > > > > > So let's at least for now fix this compilation issue > > > on a compilation only driver: > > I ended up writing this as well and squashing it into the merge into drm-next. > > Thanks, > Dave. > > > > > > > CC [M] drivers/gpu/drm/lima/lima_ctx.o > > > In file included from ./include/linux/kernel.h:7, > > > from ./include/asm-generic/bug.h:18, > > > from ./arch/x86/include/asm/bug.h:83, > > > from ./include/linux/bug.h:5, > > > from ./include/linux/mmdebug.h:5, > > > from ./include/linux/gfp.h:5, > > > from ./include/linux/slab.h:15, > > > from drivers/gpu/drm/lima/lima_ctx.c:4: > > > drivers/gpu/drm/lima/lima_ctx.c: In function ‘lima_ctx_create’: > > > ./include/linux/limits.h:13:18: error: incompatible type for argument 4 > > > of ‘xa_alloc’ > > > #define UINT_MAX (~0U) > > > ^ > > > drivers/gpu/drm/lima/lima_ctx.c:27:41: note: in expansion of macro > > > ‘UINT_MAX’ > > > err = xa_alloc(&mgr->handles, id, ctx, UINT_MAX, GFP_KERNEL); > > > ^~~~ > > > In file included from ./include/linux/radix-tree.h:31, > > > from ./include/linux/idr.h:15, > > > from ./include/drm/drm_device.h:7, > > > from drivers/gpu/drm/lima/lima_device.h:7, > > > from drivers/gpu/drm/lima/lima_ctx.c:7: > > > ./include/linux/xarray.h:817:32: note: expected ‘struct xa_limit’ but > > > argument is of type ‘unsigned int’ > > >void *entry, struct xa_limit limit, gfp_t gfp) > > > ^ > > > make[4]: *** [scripts/Makefile.build:276: > > > drivers/gpu/drm/lima/lima_ctx.o] Error 1 > > > make[3]: *** [scripts/Makefile.build:486: drivers/gpu/drm/lima] Error 2 > > > make[2]: *** [scripts/Makefile.build:486: drivers/gpu/drm] Error 2 > > > make[1]: *** [scripts/Makefile.build:486: drivers/gpu] Error 2 > > > make: *** [Makefile:1051: drivers] Error 2 > > > > > > Cc: Qiang Yu > > > Signed-off-by: Rodrigo Vivi > > > --- > > > drivers/gpu/drm/lima/lima_ctx.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/lima/lima_ctx.c > > > b/drivers/gpu/drm/lima/lima_ctx.c > > > index c8d12f7c6894..22fff6caa961 100644 > > > --- a/drivers/gpu/drm/lima/lima_ctx.c > > > +++ b/drivers/gpu/drm/lima/lima_ctx.c > > > @@ -23,7 +23,7 @@ int lima_ctx_create(struct lima_device *dev, struct > > > lima_ctx_mgr *mgr, u32 *id) > > > goto err_out0; > > > } > > > > > > - err = xa_alloc(&mgr->handles, id, UINT_MAX, ctx, GFP_KERNEL); > > > + err = xa_alloc(&mgr->handles, id, ctx, xa_limit_32b, GFP_KERNEL); > > > if (err < 0) > > > goto err_out0; > > > > > > -- > > > 2.20.1 > > > > > ___ > > 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 v3 5/5] drm/cirrus: rewrite and modernize driver.
Time to kill some bad sample code people are copying from ;)
This is a complete rewrite of the cirrus driver. The cirrus_mode_set()
function is pretty much the only function which is carried over largely
unmodified. Everything else is upside down.
It is a single monster patch. But given that it does some pretty
fundamental changes to the drivers workflow and also reduces the code
size by roughly 70% I think it'll still be alot easier to review than a
longish baby-step patch series.
Changes summary:
- Given the small amout of video memory (4 MB) the cirrus device has
the rewritten driver doesn't try to manage buffers there. Instead
it will blit (memcpy) the active framebuffer to video memory.
- All gem objects are stored in main memory and are manged using the
new shmem helpers. ttm is out.
- It supports RG16, RG24 and XR24 formats. XR24 gets converted to RG24
or RG16 at blit time if needed, to avoid the pitch becoming larger
than what the cirrus hardware can handle.
- The simple display pipeline is used.
- The generic fbdev emulation is used.
- It's a atomic driver now.
- It runs wayland.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/cirrus/cirrus_drv.h | 251 --
drivers/gpu/drm/cirrus/cirrus.c | 657 ++
drivers/gpu/drm/cirrus/cirrus_drv.c | 161 ---
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 309
drivers/gpu/drm/cirrus/cirrus_main.c | 328 -
drivers/gpu/drm/cirrus/cirrus_mode.c | 617
drivers/gpu/drm/cirrus/cirrus_ttm.c | 343 --
drivers/gpu/drm/cirrus/Kconfig| 2 +-
drivers/gpu/drm/cirrus/Makefile | 3 -
9 files changed, 658 insertions(+), 2013 deletions(-)
delete mode 100644 drivers/gpu/drm/cirrus/cirrus_drv.h
create mode 100644 drivers/gpu/drm/cirrus/cirrus.c
delete mode 100644 drivers/gpu/drm/cirrus/cirrus_drv.c
delete mode 100644 drivers/gpu/drm/cirrus/cirrus_fbdev.c
delete mode 100644 drivers/gpu/drm/cirrus/cirrus_main.c
delete mode 100644 drivers/gpu/drm/cirrus/cirrus_mode.c
delete mode 100644 drivers/gpu/drm/cirrus/cirrus_ttm.c
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h
b/drivers/gpu/drm/cirrus/cirrus_drv.h
deleted file mode 100644
index 828b150cdb20..
--- a/drivers/gpu/drm/cirrus/cirrus_drv.h
+++ /dev/null
@@ -1,251 +0,0 @@
-/*
- * Copyright 2012 Red Hat
- *
- * This file is subject to the terms and conditions of the GNU General
- * Public License version 2. See the file COPYING in the main
- * directory of this archive for more details.
- *
- * Authors: Matthew Garrett
- * Dave Airlie
- */
-#ifndef __CIRRUS_DRV_H__
-#define __CIRRUS_DRV_H__
-
-#include
-
-#include
-#include
-
-#include
-#include
-#include
-#include
-#include
-
-#include
-
-#define DRIVER_AUTHOR "Matthew Garrett"
-
-#define DRIVER_NAME"cirrus"
-#define DRIVER_DESC"qemu Cirrus emulation"
-#define DRIVER_DATE"20110418"
-
-#define DRIVER_MAJOR 1
-#define DRIVER_MINOR 0
-#define DRIVER_PATCHLEVEL 0
-
-#define CIRRUSFB_CONN_LIMIT 1
-
-#define RREG8(reg) ioread8(((void __iomem *)cdev->rmmio) + (reg))
-#define WREG8(reg, v) iowrite8(v, ((void __iomem *)cdev->rmmio) + (reg))
-#define RREG32(reg) ioread32(((void __iomem *)cdev->rmmio) + (reg))
-#define WREG32(reg, v) iowrite32(v, ((void __iomem *)cdev->rmmio) + (reg))
-
-#define SEQ_INDEX 4
-#define SEQ_DATA 5
-
-#define WREG_SEQ(reg, v) \
- do {\
- WREG8(SEQ_INDEX, reg); \
- WREG8(SEQ_DATA, v); \
- } while (0) \
-
-#define CRT_INDEX 0x14
-#define CRT_DATA 0x15
-
-#define WREG_CRT(reg, v) \
- do {\
- WREG8(CRT_INDEX, reg); \
- WREG8(CRT_DATA, v); \
- } while (0) \
-
-#define GFX_INDEX 0xe
-#define GFX_DATA 0xf
-
-#define WREG_GFX(reg, v) \
- do {\
- WREG8(GFX_INDEX, reg); \
- WREG8(GFX_DATA, v); \
- } while (0) \
-
-/*
- * Cirrus has a "hidden" DAC register that can be accessed by writing to
- * the pixel mask register to reset the state, then reading from the register
- * four times. The next write will then pass to the DAC
- */
-#define VGA_DAC_MASK 0x6
-
-#define WREG_HDR(v)\
- do {\
- RREG8(VGA_DAC_MASK);
[PATCH v3 1/5] drm: move tinydrm format conversion helpers to new drm_format_helper.c
Also rename them from tinydrm_* to drm_fb_*
Pure code motion, no functional change.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_format_helper.h | 26 +++
include/drm/tinydrm/tinydrm-helpers.h | 10 -
drivers/gpu/drm/drm_format_helper.c | 180 ++
.../gpu/drm/tinydrm/core/tinydrm-helpers.c| 158 ---
drivers/gpu/drm/tinydrm/mipi-dbi.c| 7 +-
drivers/gpu/drm/tinydrm/repaper.c | 3 +-
drivers/gpu/drm/tinydrm/st7586.c | 3 +-
drivers/gpu/drm/Makefile | 3 +-
8 files changed, 216 insertions(+), 174 deletions(-)
create mode 100644 include/drm/drm_format_helper.h
create mode 100644 drivers/gpu/drm/drm_format_helper.c
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
new file mode 100644
index ..5a7ada6b0bef
--- /dev/null
+++ b/include/drm/drm_format_helper.h
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef __LINUX_DRM_FORMAT_HELPER_H
+#define __LINUX_DRM_FORMAT_HELPER_H
+
+struct drm_framebuffer;
+struct drm_rect;
+
+void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
+ struct drm_rect *clip);
+void drm_fb_swab16(u16 *dst, void *vaddr, struct drm_framebuffer *fb,
+ struct drm_rect *clip);
+void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
+ struct drm_framebuffer *fb,
+ struct drm_rect *clip, bool swap);
+void drm_fb_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer *fb,
+ struct drm_rect *clip);
+
+#endif /* __LINUX_DRM_FORMAT_HELPER_H */
diff --git a/include/drm/tinydrm/tinydrm-helpers.h
b/include/drm/tinydrm/tinydrm-helpers.h
index ae4a6abc43b5..7d259acb8826 100644
--- a/include/drm/tinydrm/tinydrm-helpers.h
+++ b/include/drm/tinydrm/tinydrm-helpers.h
@@ -46,16 +46,6 @@ int tinydrm_display_pipe_init(struct drm_device *drm,
const struct drm_display_mode *mode,
unsigned int rotation);
-void tinydrm_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
- struct drm_rect *clip);
-void tinydrm_swab16(u16 *dst, void *vaddr, struct drm_framebuffer *fb,
- struct drm_rect *clip);
-void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
- struct drm_framebuffer *fb,
- struct drm_rect *clip, bool swap);
-void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer
*fb,
- struct drm_rect *clip);
-
size_t tinydrm_spi_max_transfer_size(struct spi_device *spi, size_t max_len);
bool tinydrm_spi_bpw_supported(struct spi_device *spi, u8 bpw);
int tinydrm_spi_transfer(struct spi_device *spi, u32 speed_hz,
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
new file mode 100644
index ..62bb4913d6f6
--- /dev/null
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -0,0 +1,180 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+/**
+ * drm_fb_memcpy - Copy clip buffer
+ * @dst: Destination buffer
+ * @vaddr: Source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ */
+void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
+ struct drm_rect *clip)
+{
+ unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0);
+ unsigned int pitch = fb->pitches[0];
+ void *src = vaddr + (clip->y1 * pitch) + (clip->x1 * cpp);
+ size_t len = (clip->x2 - clip->x1) * cpp;
+ unsigned int y;
+
+ for (y = clip->y1; y < clip->y2; y++) {
+ memcpy(dst, src, len);
+ src += pitch;
+ dst += len;
+ }
+}
+EXPORT_SYMBOL(drm_fb_memcpy);
+
+/**
+ * drm_fb_swab16 - Swap bytes into clip buffer
+ * @dst: RGB565 destination buffer
+ * @vaddr: RGB565 source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ */
+void drm_fb_swab16(u16 *dst, void *vaddr, struct drm_framebuffer *fb,
+ struct drm_rect *clip)
+{
+ size_t len = (clip->x2 - clip->x1) * sizeof(u16);
+ unsigned int x, y;
+ u16 *src, *buf;
+
+ /*
+* The cma memory is write-combine
[PATCH v3 3/5] drm: add drm_fb_xrgb8888_to_rgb565_dstclip()
It is a drm_fb_xrgb_to_rgb565() variant which checks the clip
rectangle for the destination too.
Common code between drm_fb_xrgb_to_rgb565() and
drm_fb_xrgb_to_rgb565_dstclip() was factored out into the
drm_fb_xrgb_to_rgb565_lines() helper function.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_format_helper.h | 5 +-
drivers/gpu/drm/drm_format_helper.c | 113
2 files changed, 86 insertions(+), 32 deletions(-)
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index c52b7b9a25f0..a84d71fa446b 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -19,9 +19,12 @@ void drm_fb_memcpy_dstclip(void *dst, void *vaddr, struct
drm_framebuffer *fb,
struct drm_rect *clip);
void drm_fb_swab16(u16 *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
-void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
+void drm_fb_xrgb_to_rgb565(void *dst, void *vaddr,
struct drm_framebuffer *fb,
struct drm_rect *clip, bool swap);
+void drm_fb_xrgb_to_rgb565_dstclip(void *dst, unsigned int dst_pitch,
+ void *vaddr, struct drm_framebuffer *fb,
+ struct drm_rect *clip, bool swap);
void drm_fb_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 55a2d629a75f..246775510c2e 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -110,6 +110,44 @@ void drm_fb_swab16(u16 *dst, void *vaddr, struct
drm_framebuffer *fb,
}
EXPORT_SYMBOL(drm_fb_swab16);
+static void drm_fb_xrgb_to_rgb565_lines(void *dst, unsigned int dst_pitch,
+ void *src, unsigned int src_pitch,
+ unsigned int src_linelength,
+ unsigned int lines,
+ bool swap)
+{
+ unsigned int linepixels = src_linelength / sizeof(u32);
+ unsigned int x, y;
+ u32 *sbuf;
+ u16 *dbuf, val16;
+
+ /*
+* The cma memory is write-combined so reads are uncached.
+* Speed up by fetching one line at a time.
+*/
+ sbuf = kmalloc(src_linelength, GFP_KERNEL);
+ if (!sbuf)
+ return;
+
+ for (y = 0; y < lines; y++) {
+ memcpy(sbuf, src, src_linelength);
+ dbuf = dst;
+ for (x = 0; x < linepixels; x++) {
+ val16 = ((sbuf[x] & 0x00F8) >> 8) |
+ ((sbuf[x] & 0xFC00) >> 5) |
+ ((sbuf[x] & 0x00F8) >> 3);
+ if (swap)
+ *dbuf++ = swab16(val16);
+ else
+ *dbuf++ = val16;
+ }
+ src += src_pitch;
+ dst += dst_pitch;
+ }
+
+ kfree(sbuf);
+}
+
/**
* drm_fb_xrgb_to_rgb565 - Convert XRGB to RGB565 clip buffer
* @dst: RGB565 destination buffer
@@ -120,45 +158,58 @@ EXPORT_SYMBOL(drm_fb_swab16);
*
* Drivers can use this function for RGB565 devices that don't natively
* support XRGB.
+ *
+ * This function does not apply clipping on dst, i.e. the destination
+ * is a small buffer containing the clip rect only.
*/
-void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
+void drm_fb_xrgb_to_rgb565(void *dst, void *vaddr,
struct drm_framebuffer *fb,
struct drm_rect *clip, bool swap)
{
- size_t len = (clip->x2 - clip->x1) * sizeof(u32);
- unsigned int x, y;
- u32 *src, *buf;
- u16 val16;
+ unsigned int src_offset = (clip->y1 * fb->pitches[0])
+ + (clip->x1 * sizeof(u32));
+ size_t src_len = (clip->x2 - clip->x1) * sizeof(u32);
+ size_t dst_len = (clip->x2 - clip->x1) * sizeof(u16);
- /*
-* The cma memory is write-combined so reads are uncached.
-* Speed up by fetching one line at a time.
-*/
- buf = kmalloc(len, GFP_KERNEL);
- if (!buf)
- return;
-
- for (y = clip->y1; y < clip->y2; y++) {
- src = vaddr + (y * fb->pitches[0]);
- src += clip->x1;
- memcpy(buf, src, len);
- src = buf;
- for (x = clip->x1; x < clip->x2; x++) {
- val16 = ((*src & 0x00F8) >> 8) |
- ((*src & 0xFC00) >> 5) |
- ((*src & 0x00F8) >> 3);
- src++;
- if (swap)
-
[PATCH v3 4/5] drm: add drm_fb_xrgb8888_to_rgb888_dstclip()
Simliar to drm_fb_xrgb_to_rgb565_dstclip() but converts to rgb888
instead of rgb565.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_format_helper.h | 3 ++
drivers/gpu/drm/drm_format_helper.c | 60 +
2 files changed, 63 insertions(+)
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index a84d71fa446b..6f84380757ee 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -25,6 +25,9 @@ void drm_fb_xrgb_to_rgb565(void *dst, void *vaddr,
void drm_fb_xrgb_to_rgb565_dstclip(void *dst, unsigned int dst_pitch,
void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip, bool swap);
+void drm_fb_xrgb_to_rgb888_dstclip(void *dst, unsigned int dst_pitch,
+ void *vaddr, struct drm_framebuffer *fb,
+ struct drm_rect *clip);
void drm_fb_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 246775510c2e..00d716f14173 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -210,6 +210,66 @@ void drm_fb_xrgb_to_rgb565_dstclip(void *dst, unsigned
int dst_pitch,
}
EXPORT_SYMBOL(drm_fb_xrgb_to_rgb565_dstclip);
+static void drm_fb_xrgb_to_rgb888_lines(void *dst, unsigned int dst_pitch,
+ void *src, unsigned int src_pitch,
+ unsigned int src_linelength,
+ unsigned int lines)
+{
+ unsigned int linepixels = src_linelength / 3;
+ unsigned int x, y;
+ u32 *sbuf;
+ u8 *dbuf;
+
+ sbuf = kmalloc(src_linelength, GFP_KERNEL);
+ if (!sbuf)
+ return;
+
+ for (y = 0; y < lines; y++) {
+ memcpy(sbuf, src, src_linelength);
+ dbuf = dst;
+ for (x = 0; x < linepixels; x++) {
+ *dbuf++ = (sbuf[x] & 0x00FF) >> 0;
+ *dbuf++ = (sbuf[x] & 0xFF00) >> 8;
+ *dbuf++ = (sbuf[x] & 0x00FF) >> 16;
+ }
+ src += src_pitch;
+ dst += dst_pitch;
+ }
+
+ kfree(sbuf);
+}
+
+/**
+ * drm_fb_xrgb_to_rgb888_dstclip - Convert XRGB to RGB888 clip buffer
+ * @dst: RGB565 destination buffer
+ * @dst_pitch: destination buffer pitch
+ * @vaddr: XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ * @dstclip: Clip destination too.
+ *
+ * Drivers can use this function for RGB888 devices that don't natively
+ * support XRGB.
+ *
+ * This function applies clipping on dst, i.e. the destination is a
+ * full framebuffer but only the clip rect content is copied over.
+ */
+void drm_fb_xrgb_to_rgb888_dstclip(void *dst, unsigned int dst_pitch,
+ void *vaddr, struct drm_framebuffer *fb,
+ struct drm_rect *clip)
+{
+ unsigned int src_offset = (clip->y1 * fb->pitches[0])
+ + (clip->x1 * sizeof(u32));
+ unsigned int dst_offset = (clip->y1 * dst_pitch)
+ + (clip->x1 * 3);
+ size_t src_len = (clip->x2 - clip->x1) * sizeof(u32);
+
+ drm_fb_xrgb_to_rgb888_lines(dst + dst_offset, dst_pitch,
+ vaddr + src_offset, fb->pitches[0],
+ src_len, clip->y2 - clip->y1);
+}
+EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888_dstclip);
+
/**
* drm_fb_xrgb_to_gray8 - Convert XRGB to grayscale
* @dst: 8-bit grayscale destination buffer
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/5] drm/cirrus: rewrite and modernize driver.
v3: - move tinydrm converters to new drm_format_helpers.[ch] - drop dstclip bool argument, use multiple functions instead (with common code factored out into a helper). - rewrite cirrus register access to use helpers instead of macros. - misc minor fixes. v2: - It's a little series now. It moves tinydrm converters to drm_fb_helpers.c first. - Added support for RG24 and XR24. Without bpp module parameter, instead the driver will convert formats if needed. - A bunch of little tweaks here and there (embedded struct drm_driver, use more drm helpers, ...) Gerd Hoffmann (5): drm: move tinydrm format conversion helpers to new drm_format_helper.c drm: add drm_fb_memcpy_dstclip() helper drm: add drm_fb_xrgb_to_rgb565_dstclip() drm: add drm_fb_xrgb_to_rgb888_dstclip() drm/cirrus: rewrite and modernize driver. drivers/gpu/drm/cirrus/cirrus_drv.h | 251 --- include/drm/drm_format_helper.h | 34 + include/drm/tinydrm/tinydrm-helpers.h | 10 - drivers/gpu/drm/cirrus/cirrus.c | 657 ++ drivers/gpu/drm/cirrus/cirrus_drv.c | 161 - drivers/gpu/drm/cirrus/cirrus_fbdev.c | 309 drivers/gpu/drm/cirrus/cirrus_main.c | 328 - drivers/gpu/drm/cirrus/cirrus_mode.c | 617 drivers/gpu/drm/cirrus/cirrus_ttm.c | 343 - drivers/gpu/drm/drm_format_helper.c | 326 + .../gpu/drm/tinydrm/core/tinydrm-helpers.c| 158 - drivers/gpu/drm/tinydrm/mipi-dbi.c| 7 +- drivers/gpu/drm/tinydrm/repaper.c | 3 +- drivers/gpu/drm/tinydrm/st7586.c | 3 +- drivers/gpu/drm/Makefile | 3 +- drivers/gpu/drm/cirrus/Kconfig| 2 +- drivers/gpu/drm/cirrus/Makefile | 3 - 17 files changed, 1028 insertions(+), 2187 deletions(-) delete mode 100644 drivers/gpu/drm/cirrus/cirrus_drv.h create mode 100644 include/drm/drm_format_helper.h create mode 100644 drivers/gpu/drm/cirrus/cirrus.c delete mode 100644 drivers/gpu/drm/cirrus/cirrus_drv.c delete mode 100644 drivers/gpu/drm/cirrus/cirrus_fbdev.c delete mode 100644 drivers/gpu/drm/cirrus/cirrus_main.c delete mode 100644 drivers/gpu/drm/cirrus/cirrus_mode.c delete mode 100644 drivers/gpu/drm/cirrus/cirrus_ttm.c create mode 100644 drivers/gpu/drm/drm_format_helper.c -- 2.18.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] iommu: io-pgtable: Add ARM Mali midgard MMU page table format
Hi Steve,
On 05/04/2019 10:42, Steven Price wrote:
First let me say congratulations to everyone working on Panfrost - it's
an impressive achievement!
Full disclosure: I used to work on the Mali kbase driver. And have been
playing around with running the Mali user-space blob with the Panfrost
kernel driver.
On 01/04/2019 08:47, Rob Herring wrote:
ARM Mali midgard GPU is similar to standard 64-bit stage 1 page tables, but
have a few differences. Add a new format type to represent the format. The
input address size is 48-bits and the output address size is 40-bits (and
possibly less?). Note that the later bifrost GPUs follow the standard
64-bit stage 1 format.
The differences in the format compared to 64-bit stage 1 format are:
The 3rd level page entry bits are 0x1 instead of 0x3 for page entries.
The access flags are not read-only and unprivileged, but read and write.
This is similar to stage 2 entries, but the memory attributes field matches
stage 1 being an index.
The nG bit is not set by the vendor driver. This one didn't seem to matter,
but we'll keep it aligned to the vendor driver.
The nG bit should be ignored by the hardware.
The MMU in Midgard/Bifrost has a quirk similar to
IO_PGTABLE_QUIRK_TLBI_ON_MAP - you must perform a cache flush for the
GPU to (reliably) pick up new page table mappings.
You may not have seen this because of the use of the JS_CONFIG_START_MMU
bit - this effectively performs a cache flush and TLB invalidate before
starting a job, however when using a GPU like T760 (e.g. on the Firefly
RK3288) this bit isn't being set. In my testing on the Firefly board I
saw GPU page faults because of this.
There's two options for fixing this - a patch like below adds the quirk
mode to the MMU. Or alternatively always set JS_CONFIG_START_MMU on
jobs. In my testing both options solve the page faults.
To be honest I don't know the reasoning behind kbase making the
JS_CONFIG_START_MMU bit conditional - I'm not aware of any reason why it
can't always be set. My guess is performance, but I haven't benchmarked
the difference between this and JS_CONFIG_START_MMU.
-8<--
From e3f75c7f04e43238dfc579029b8c11fb6b4a0c18 Mon Sep 17 00:00:00 2001
From: Steven Price
Date: Thu, 4 Apr 2019 15:53:17 +0100
Subject: [PATCH] iommu: io-pgtable: IO_PGTABLE_QUIRK_TLBI_ON_MAP for LPAE
Midgard/Bifrost GPUs require a TLB invalidation when mapping pages,
implement IO_PGTABLE_QUIRK_TLBI_ON_MAP for LPAE iommu page table
formats and add the quirk bit to Panfrost.
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_mmu.c | 1 +
drivers/iommu/io-pgtable-arm.c | 11 +--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_mmu.c
b/drivers/gpu/drm/panfrost/panfrost_mmu.c
index f3aad8591cf4..094312074d66 100644
--- a/drivers/gpu/drm/panfrost/panfrost_mmu.c
+++ b/drivers/gpu/drm/panfrost/panfrost_mmu.c
@@ -343,6 +343,7 @@ int panfrost_mmu_init(struct panfrost_device *pfdev)
mmu_write(pfdev, MMU_INT_MASK, ~0);
pfdev->mmu->pgtbl_cfg = (struct io_pgtable_cfg) {
+ .quirks = IO_PGTABLE_QUIRK_TLBI_ON_MAP,
.pgsize_bitmap = SZ_4K, // | SZ_2M | SZ_1G),
.ias= 48,
.oas= 40, /* Should come from dma mask? */
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 84beea1f47a7..45fd7bbdf9aa 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -505,7 +505,13 @@ static int arm_lpae_map(struct io_pgtable_ops *ops,
unsigned long iova,
* Synchronise all PTE updates for the new mapping before there's
* a chance for anything to kick off a table walk for the new iova.
*/
- wmb();
+ if (data->iop.cfg.quirks & IO_PGTABLE_QUIRK_TLBI_ON_MAP) {
+ io_pgtable_tlb_add_flush(&data->iop, iova, size,
+ARM_LPAE_BLOCK_SIZE(2, data), false);
For correctness (in case this ever ends up used for something with
VMSA-like invalidation behaviour), the granule would need to be "size"
here, rather than effectively hard-coded.
However, since Mali's invalidations appear to operate on arbitrary
ranges, it would probably be a lot more efficient for the driver to
handle this case directly, by just issuing a single big invalidation
after the for_each_sg() loop in panfrost_mmu_map().
Robin.
+ io_pgtable_tlb_sync(&data->iop);
+ } else {
+ wmb();
+ }
return ret;
}
@@ -800,7 +806,8 @@ arm_64_lpae_alloc_pgtable_s1(struct io_pgtable_cfg
*cfg, void *cookie)
struct arm_lpae_io_pgtable *data;
if (cfg->quirks & ~(IO_PGTABLE_QUIRK_ARM_NS | IO_PGTABLE_QUIRK_NO_DMA |
- IO_PGTABLE_QUIRK_NON_STRICT))
+ IO_PGTABLE_QUIRK_NON_STRICT |
+ IO_PGTABLE_QUIRK_TLBI_ON_MAP))
[PATCH v3 2/5] drm: add drm_fb_memcpy_dstclip() helper
It is a drm_fb_memcpy() variant which checks the clip rectangle for the
destination too.
Common code between drm_fb_memcpy() and drm_fb_memcpy_dstclip() was
factored out into the drm_fb_memcpy_lines() helper function.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_format_helper.h | 2 ++
drivers/gpu/drm/drm_format_helper.c | 51 -
2 files changed, 45 insertions(+), 8 deletions(-)
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index 5a7ada6b0bef..c52b7b9a25f0 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -15,6 +15,8 @@ struct drm_rect;
void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
+void drm_fb_memcpy_dstclip(void *dst, void *vaddr, struct drm_framebuffer *fb,
+ struct drm_rect *clip);
void drm_fb_swab16(u16 *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip);
void drm_fb_xrgb_to_rgb565(u16 *dst, void *vaddr,
diff --git a/drivers/gpu/drm/drm_format_helper.c
b/drivers/gpu/drm/drm_format_helper.c
index 62bb4913d6f6..55a2d629a75f 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -16,30 +16,65 @@
#include
#include
+static void drm_fb_memcpy_lines(void *dst, unsigned int dst_pitch,
+ void *src, unsigned int src_pitch,
+ unsigned int linelength, unsigned int lines)
+{
+ int line;
+
+ for (line = 0; line < lines; line++) {
+ memcpy(dst, src, linelength);
+ src += src_pitch;
+ dst += dst_pitch;
+ }
+}
+
/**
* drm_fb_memcpy - Copy clip buffer
* @dst: Destination buffer
* @vaddr: Source buffer
* @fb: DRM framebuffer
* @clip: Clip rectangle area to copy
+ *
+ * This function does not apply clipping on dst, i.e. the destination
+ * is a small buffer containing the clip rect only.
*/
void drm_fb_memcpy(void *dst, void *vaddr, struct drm_framebuffer *fb,
struct drm_rect *clip)
{
unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0);
- unsigned int pitch = fb->pitches[0];
- void *src = vaddr + (clip->y1 * pitch) + (clip->x1 * cpp);
+ unsigned int offset = (clip->y1 * fb->pitches[0]) + (clip->x1 * cpp);
size_t len = (clip->x2 - clip->x1) * cpp;
- unsigned int y;
- for (y = clip->y1; y < clip->y2; y++) {
- memcpy(dst, src, len);
- src += pitch;
- dst += len;
- }
+ drm_fb_memcpy_lines(dst, len,
+ vaddr + offset, fb->pitches[0],
+ len, clip->y2 - clip->y1);
}
EXPORT_SYMBOL(drm_fb_memcpy);
+/**
+ * drm_fb_memcpy_dstclip - Copy clip buffer
+ * @dst: Destination buffer
+ * @vaddr: Source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ *
+ * This function applies clipping on dst, i.e. the destination is a
+ * full framebuffer but only the clip rect content is copied over.
+ */
+void drm_fb_memcpy_dstclip(void *dst, void *vaddr, struct drm_framebuffer *fb,
+ struct drm_rect *clip)
+{
+ unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0);
+ unsigned int offset = (clip->y1 * fb->pitches[0]) + (clip->x1 * cpp);
+ size_t len = (clip->x2 - clip->x1) * cpp;
+
+ drm_fb_memcpy_lines(dst + offset, fb->pitches[0],
+ vaddr + offset, fb->pitches[0],
+ len, clip->y2 - clip->y1);
+}
+EXPORT_SYMBOL(drm_fb_memcpy_dstclip);
+
/**
* drm_fb_swab16 - Swap bytes into clip buffer
* @dst: RGB565 destination buffer
--
2.18.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 05/13] drivers: create binary sysfs for class
On Fri, Apr 05, 2019 at 02:12:54PM +0530, Ramalingam C wrote: > Functions to create and remove the binary sysfs for class are added. > > These are getting introduced as DRM wants to create the common binary > sysfs across the drm subsystem to handle hdcp srm. Why do you need individual files? That's almost always a sign that you are going to race with userspace in a bad way. Why not just use an attribute group which provides automatic support for this? thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and PgDn
https://bugs.freedesktop.org/show_bug.cgi?id=110214 Michel Dänzer changed: What|Removed |Added Version|19.0|git --- Comment #63 from Michel Dänzer --- (In reply to Diego Viola from comment #62) > export MESA_EXTENSION_OVERRIDE="-GL_NV_texture_barrier" > > This helps alleviate the problem (xterm does not have the issue with this), > however, the problem is still present in Xephyr. To clarify, you mean Xephyr from xserver 1.16 here (where glamor didn't make use of GL_NV_texture_barrier yet), disabling GL_NV_texture_barrier helps with current Xephyr, right? It seems like DPBB needs to be disabled when glTextureBarrier(NV) is called, otherwise primitives may be reordered across the barrier. Does that make sense, Marek? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: DW HDMI: Lower max. supported rate for H6
On Sun, Mar 24, 2019 at 08:06:09PM +0100, Jernej Skrabec wrote:
> Currently resolutions with pixel clock higher than 340 MHz don't work
> with H6 HDMI controller. They just produce a blank screen.
>
> Limit maximum pixel clock rate to 340 MHz until scrambling is supported.
>
> Cc: sta...@vger.kernel.org # 5.0
> Fixes: 40bb9d3147b2 ("drm/sun4i: Add support for H6 DW HDMI controller")
> Signed-off-by: Jernej Skrabec
Applied, thanks!
(And sorry for the delay)
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Revert "Documentation/gpu/meson: Remove link to meson_canvas.c"
On Thu, Apr 04, 2019 at 10:52:02AM -0400, Sean Paul wrote:
> On Thu, Apr 04, 2019 at 04:43:42PM +0200, Neil Armstrong wrote:
> > This reverts commit a3f98bb22cbfaaf67717e156f79e2bfeb42d4cac.
> >
> > Patch "Documentation/gpu/meson: Remove link to meson_canvas.c" was
> > incorrectly applied on the wrong branch not containing the fixed
> > commit 2bf6b5b0e374 ("drm/meson: exclusively use the canvas provider
> > module")
> >
> > Signed-off-by: Neil Armstrong
>
> Acked-by: Sean Paul
>
> and I'll leave this for Maxime to apply if he so chooses.
Applied, thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 09/13] drm: uevent for connector status change
DRM API for generating uevent for a status changes of connector's
property.
This uevent will have following details related to the status change:
HOTPLUG=1, CONNECTOR= and PROPERTY=
v2:
Minor fixes at KDoc comments [Daniel]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/drm_sysfs.c | 31 +++
include/drm/drm_sysfs.h | 5 -
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 18b1ac442997..e8f1fd73677f 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -320,6 +320,9 @@ void drm_sysfs_lease_event(struct drm_device *dev)
* Send a uevent for the DRM device specified by @dev. Currently we only
* set HOTPLUG=1 in the uevent environment, but this could be expanded to
* deal with other types of events.
+ *
+ * Any new uapi should be using the drm_sysfs_connector_status_event()
+ * for uevents on connector status change.
*/
void drm_sysfs_hotplug_event(struct drm_device *dev)
{
@@ -332,6 +335,34 @@ void drm_sysfs_hotplug_event(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_sysfs_hotplug_event);
+/**
+ * drm_sysfs_connector_status_event - generate a DRM uevent for connector
+ * property status change
+ * @connector: connector on which property status changed
+ * @property: connector property whoes status changed.
+ *
+ * Send a uevent for the DRM device specified by @dev. Currently we
+ * set HOTPLUG=1 and connector id along with the attached property id
+ * related to the status change.
+ */
+void drm_sysfs_connector_status_event(struct drm_connector *connector,
+ struct drm_property *property)
+{
+ struct drm_device *dev = connector->dev;
+ char hotplug_str[] = "HOTPLUG=1", conn_id[30], prop_id[30];
+ char *envp[4] = { hotplug_str, conn_id, prop_id, NULL };
+
+ snprintf(conn_id, ARRAY_SIZE(conn_id),
+"CONNECTOR=%u", connector->base.id);
+ snprintf(prop_id, ARRAY_SIZE(prop_id),
+"PROPERTY=%u", property->base.id);
+
+ DRM_DEBUG("generating connector status event\n");
+
+ kobject_uevent_env(&dev->primary->kdev->kobj, KOBJ_CHANGE, envp);
+}
+EXPORT_SYMBOL(drm_sysfs_connector_status_event);
+
static void drm_sysfs_release(struct device *dev)
{
kfree(dev);
diff --git a/include/drm/drm_sysfs.h b/include/drm/drm_sysfs.h
index 4f311e836cdc..d454ef617b2c 100644
--- a/include/drm/drm_sysfs.h
+++ b/include/drm/drm_sysfs.h
@@ -4,10 +4,13 @@
struct drm_device;
struct device;
+struct drm_connector;
+struct drm_property;
int drm_class_device_register(struct device *dev);
void drm_class_device_unregister(struct device *dev);
void drm_sysfs_hotplug_event(struct drm_device *dev);
-
+void drm_sysfs_connector_status_event(struct drm_connector *connector,
+ struct drm_property *property);
#endif
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 12/13] drm: Add CP downstream_info property
This patch adds a optional CP downstream info blob property to the
connectors. This enables the Userspace to read the information of HDCP
authenticated downstream topology.
Driver will update this blob with all downstream information at the
end of the authentication.
In case userspace configures this platform as repeater, then this
information is needed for the authentication with upstream HDCP
transmitter.
v2:
s/cp_downstream/content_protection_downstream [daniel]
v3:
s/content_protection_downstream/hdcp_topology [daniel]
v4:
hdcp_topology_info struct is added with explicit padding [Daniel]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/drm_atomic_uapi.c | 3 ++
drivers/gpu/drm/drm_connector.c | 20 ++
drivers/gpu/drm/drm_hdcp.c| 65 +++
include/drm/drm_connector.h | 6 +++
include/drm/drm_hdcp.h| 6 +++
include/drm/drm_mode_config.h | 6 +++
include/uapi/drm/drm_mode.h | 37 ++
7 files changed, 143 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index fa50fac2e952..3a1858d5730c 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -826,6 +826,9 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->content_protection;
} else if (property == config->hdcp_content_type_property) {
*val = state->hdcp_content_type;
+ } else if (property == config->hdcp_topology_property) {
+ *val = connector->hdcp_topology_blob_ptr ?
+ connector->hdcp_topology_blob_ptr->base.id : 0;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 436cf8e764cc..033ced774d37 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -246,6 +246,7 @@ int drm_connector_init(struct drm_device *dev,
mutex_init(&connector->mutex);
connector->edid_blob_ptr = NULL;
connector->tile_blob_ptr = NULL;
+ connector->hdcp_topology_blob_ptr = NULL;
connector->status = connector_status_unknown;
connector->display_info.panel_orientation =
DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
@@ -972,6 +973,25 @@ static const struct drm_prop_enum_list hdmi_colorspaces[]
= {
* authentication process. If content type is changed when
* content_protection is not UNDESIRED, then kernel will disable the HDCP
* and re-enable with new type in the same atomic commit
+ * HDCP Topology:
+ * This blob property is used to pass the HDCP downstream topology details
+ * of a HDCP encrypted connector, from kernel to userspace.
+ * This provides all required information to userspace, so that userspace
+ * can implement the HDCP repeater using the kernel as downstream ports of
+ * the repeater. as illustrated below:
+ *
+ * HDCP Repeaters
+ * +--+
+ * | |
+ * | | |
+ * | Userspace HDCP Receiver +->KMD HDCP transmitters |
+ * | (Upstream Port) <--+ (Downstream Ports)|
+ * | | |
+ * | |
+ * +--+
+ *
+ * Kernel will populate this blob only when the HDCP authentication is
+ * successful.
*
* max bpc:
* This range property is used by userspace to limit the bit depth. When
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 38c90c053cdd..3f57ca424a1b 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -444,3 +444,68 @@ void drm_hdcp_update_content_protection(struct
drm_connector *connector,
dev->mode_config.content_protection_property);
}
EXPORT_SYMBOL(drm_hdcp_update_content_protection);
+
+/**
+ * drm_connector_attach_hdcp_topology_property - attach hdcp topology property
+ *
+ * @connector: connector to attach hdcp topology property with.
+ *
+ * This is used to add support for hdcp topology support on select connectors.
+ * When Intel platform is configured as repeater, this downstream info is used
+ * by userspace, to complete the repeater authentication of HDCP specification
+ * with upstream HDCP transmitter.
+ *
+ * The blob_id of the hdcp topology info will be set to
+ * &drm_connector_state.hdcp_topology
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_hdcp_topology_property(struct drm_connector
*connector)
+{
+
[PATCH v4 13/13] drm/i915: Populate downstream info for HDCP
Implements drm blob property content_protection_downstream_info
property on HDCP capable connectors.
Downstream topology info is gathered across authentication stages
and stored in intel_hdcp. When HDCP authentication is complete,
new blob with latest downstream topology information is updated to
content_protection_downstream_info property.
v2:
%s/cp_downstream/content_protection_downstream [daniel]
v3:
%s/content_protection_downstream/hdcp_topology [daniel]
v4:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_hdcp.c | 87 ++-
include/drm/drm_hdcp.h| 1 +
3 files changed, 76 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e387e842f414..6a321a56ce42 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -482,6 +482,8 @@ struct intel_hdcp {
wait_queue_head_t cp_irq_queue;
atomic_t cp_irq_count;
int cp_irq_count_cached;
+
+ struct hdcp_topology_info *topology_info;
};
struct intel_connector {
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.c
index f70f1e98e4ae..6993bb9ecd0b 100644
--- a/drivers/gpu/drm/i915/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/intel_hdcp.c
@@ -490,9 +490,10 @@ int intel_hdcp_validate_v_prime(struct intel_digital_port
*intel_dig_port,
/* Implements Part 2 of the HDCP authorization procedure */
static
-int intel_hdcp_auth_downstream(struct intel_digital_port *intel_dig_port,
- const struct intel_hdcp_shim *shim)
+int intel_hdcp_auth_downstream(struct intel_hdcp *hdcp,
+ struct intel_digital_port *intel_dig_port)
{
+ const struct intel_hdcp_shim *shim = hdcp->shim;
u8 bstatus[2], num_downstream, *ksv_fifo;
int ret, i, tries = 3;
@@ -523,6 +524,9 @@ int intel_hdcp_auth_downstream(struct intel_digital_port
*intel_dig_port,
if (num_downstream == 0)
return -EINVAL;
+ hdcp->topology_info->device_count = num_downstream;
+ hdcp->topology_info->depth = DRM_HDCP_DEPTH(bstatus[1]);
+
ksv_fifo = kcalloc(DRM_HDCP_KSV_LEN, num_downstream, GFP_KERNEL);
if (!ksv_fifo)
return -ENOMEM;
@@ -536,6 +540,8 @@ int intel_hdcp_auth_downstream(struct intel_digital_port
*intel_dig_port,
return -EPERM;
}
+ memcpy(hdcp->topology_info->ksv_list, ksv_fifo,
+ num_downstream * DRM_HDCP_KSV_LEN);
/*
* When V prime mismatches, DP Spec mandates re-read of
* V prime atleast twice.
@@ -562,9 +568,11 @@ int intel_hdcp_auth_downstream(struct intel_digital_port
*intel_dig_port,
}
/* Implements Part 1 of the HDCP authorization procedure */
-static int intel_hdcp_auth(struct intel_digital_port *intel_dig_port,
- const struct intel_hdcp_shim *shim)
+static int intel_hdcp_auth(struct intel_connector *connector)
{
+ struct intel_digital_port *intel_dig_port = conn_to_dig_port(connector);
+ struct intel_hdcp *hdcp = &connector->hdcp;
+ const struct intel_hdcp_shim *shim = hdcp->shim;
struct drm_i915_private *dev_priv;
enum port port;
unsigned long r0_prime_gen_start;
@@ -635,15 +643,20 @@ static int intel_hdcp_auth(struct intel_digital_port
*intel_dig_port,
return -EPERM;
}
+ hdcp->topology_info->ver_in_force = DRM_MODE_HDCP14_IN_FORCE;
+ memcpy(hdcp->topology_info->bksv, bksv.shim, DRM_MODE_HDCP_KSV_LEN);
+
I915_WRITE(PORT_HDCP_BKSVLO(port), bksv.reg[0]);
I915_WRITE(PORT_HDCP_BKSVHI(port), bksv.reg[1]);
ret = shim->repeater_present(intel_dig_port, &repeater_present);
if (ret)
return ret;
- if (repeater_present)
+ if (repeater_present) {
I915_WRITE(HDCP_REP_CTL,
intel_hdcp_get_repeater_ctl(intel_dig_port));
+ hdcp->topology_info->is_repeater = true;
+ }
ret = shim->toggle_signalling(intel_dig_port, true);
if (ret)
@@ -708,7 +721,7 @@ static int intel_hdcp_auth(struct intel_digital_port
*intel_dig_port,
*/
if (repeater_present)
- return intel_hdcp_auth_downstream(intel_dig_port, shim);
+ return intel_hdcp_auth_downstream(hdcp, intel_dig_port);
DRM_DEBUG_KMS("HDCP is enabled (no repeater present)\n");
return 0;
@@ -739,13 +752,18 @@ static int _intel_hdcp_disable(struct intel_connector
*connector)
return ret;
}
+ memset(hdcp->topology_info, 0, sizeof(struct hdcp_topology_info));
+
+ if (drm_connector_update_hdcp_topology_property(&connector->base,
+ connector->hdcp.topology_info))
+ DRM_ERROR("Downstream_info update faile
[PATCH v4 05/13] drivers: create binary sysfs for class
Functions to create and remove the binary sysfs for class are added.
These are getting introduced as DRM wants to create the common binary
sysfs across the drm subsystem to handle hdcp srm.
Signed-off-by: Ramalingam C
cc: Greg Kroah-Hartman
cc: Daniel Vetter
---
drivers/base/class.c | 19 +++
include/linux/device.h | 4
2 files changed, 23 insertions(+)
diff --git a/drivers/base/class.c b/drivers/base/class.c
index d8a6a5864c2e..b0f37de16a14 100644
--- a/drivers/base/class.c
+++ b/drivers/base/class.c
@@ -83,6 +83,23 @@ static struct kobj_type class_ktype = {
/* Hotplug events for classes go to the class subsys */
static struct kset *class_kset;
+int class_create_bin_file(struct class *cls, const struct bin_attribute *attr)
+{
+ int error;
+
+ if (cls)
+ error = sysfs_create_bin_file(&cls->p->subsys.kobj, attr);
+ else
+ error = -EINVAL;
+ return error;
+}
+
+void class_remove_bin_file(struct class *cls, const struct bin_attribute *attr)
+{
+ if (cls)
+ sysfs_remove_bin_file(&cls->p->subsys.kobj, attr);
+}
+
int class_create_file_ns(struct class *cls, const struct class_attribute *attr,
const void *ns)
@@ -577,6 +594,8 @@ int __init classes_init(void)
return 0;
}
+EXPORT_SYMBOL_GPL(class_create_bin_file);
+EXPORT_SYMBOL_GPL(class_remove_bin_file);
EXPORT_SYMBOL_GPL(class_create_file_ns);
EXPORT_SYMBOL_GPL(class_remove_file_ns);
EXPORT_SYMBOL_GPL(class_unregister);
diff --git a/include/linux/device.h b/include/linux/device.h
index b6c6a4634801..004c8064a78a 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -485,6 +485,10 @@ struct class_attribute {
#define CLASS_ATTR_WO(_name) \
struct class_attribute class_attr_##_name = __ATTR_WO(_name)
+extern int __must_check class_create_bin_file(struct class *class,
+ const struct bin_attribute *attr);
+extern void class_remove_bin_file(struct class *class,
+ const struct bin_attribute *attr);
extern int __must_check class_create_file_ns(struct class *class,
const struct class_attribute *attr,
const void *ns);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 08/13] drm/hdcp: gathering hdcp related code into drm_hdcp.c
Considering the significant size of hdcp related code in drm, all
hdcp related codes are moved into separate file called drm_hdcp.c.
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
---
drivers/gpu/drm/drm_connector.c | 78 ---
drivers/gpu/drm/drm_hdcp.c | 82 +
include/drm/drm_connector.h | 2 -
include/drm/drm_hdcp.h | 4 ++
4 files changed, 86 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 03907d13ef66..436cf8e764cc 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -823,13 +823,6 @@ static const struct drm_prop_enum_list
drm_tv_subconnector_enum_list[] = {
DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
drm_tv_subconnector_enum_list)
-static struct drm_prop_enum_list drm_cp_enum_list[] = {
- { DRM_MODE_CONTENT_PROTECTION_UNDESIRED, "Undesired" },
- { DRM_MODE_CONTENT_PROTECTION_DESIRED, "Desired" },
- { DRM_MODE_CONTENT_PROTECTION_ENABLED, "Enabled" },
-};
-DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
-
static const struct drm_prop_enum_list hdmi_colorspaces[] = {
/* For Default case, driver will set the colorspace */
{ DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
@@ -857,13 +850,6 @@ static const struct drm_prop_enum_list hdmi_colorspaces[]
= {
{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
};
-static struct drm_prop_enum_list drm_hdcp_content_type_enum_list[] = {
- { DRM_MODE_HDCP_CONTENT_TYPE0, "HDCP Type0" },
- { DRM_MODE_HDCP_CONTENT_TYPE1, "HDCP Type1" },
-};
-DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
-drm_hdcp_content_type_enum_list)
-
/**
* DOC: standard connector properties
*
@@ -1539,70 +1525,6 @@ int drm_connector_attach_scaling_mode_property(struct
drm_connector *connector,
}
EXPORT_SYMBOL(drm_connector_attach_scaling_mode_property);
-/**
- * drm_connector_attach_content_protection_property - attach content protection
- * property
- *
- * @connector: connector to attach CP property on.
- * @hdcp_content_type: is HDCP Content Type property needed for connector
- *
- * This is used to add support for content protection on select connectors.
- * Content Protection is intentionally vague to allow for different underlying
- * technologies, however it is most implemented by HDCP.
- *
- * When hdcp_content_type is true enum property called HDCP Content Type is
- * created (if it is not already) and attached to the connector.
- *
- * This property is used for sending the protected content's stream type
- * from userspace to kernel on selected connectors. Protected content provider
- * will decide their type of their content and declare the same to kernel.
- *
- * Content type will be used during the HDCP 2.2 authentication.
- * Content type will be set to &drm_connector_state.hdcp_content_type.
- *
- * The content protection will be set to
&drm_connector_state.content_protection
- *
- * Returns:
- * Zero on success, negative errno on failure.
- */
-int drm_connector_attach_content_protection_property(
- struct drm_connector *connector, bool hdcp_content_type)
-{
- struct drm_device *dev = connector->dev;
- struct drm_property *prop =
- dev->mode_config.content_protection_property;
-
- if (!prop)
- prop = drm_property_create_enum(dev, 0, "Content Protection",
- drm_cp_enum_list,
- ARRAY_SIZE(drm_cp_enum_list));
- if (!prop)
- return -ENOMEM;
-
- drm_object_attach_property(&connector->base, prop,
- DRM_MODE_CONTENT_PROTECTION_UNDESIRED);
- dev->mode_config.content_protection_property = prop;
-
- if (!hdcp_content_type)
- return 0;
-
- prop = dev->mode_config.hdcp_content_type_property;
- if (!prop)
- prop = drm_property_create_enum(dev, 0, "HDCP Content Type",
- drm_hdcp_content_type_enum_list,
- ARRAY_SIZE(
- drm_hdcp_content_type_enum_list));
- if (!prop)
- return -ENOMEM;
-
- drm_object_attach_property(&connector->base, prop,
- DRM_MODE_HDCP_CONTENT_TYPE0);
- dev->mode_config.hdcp_content_type_property = prop;
-
- return 0;
-}
-EXPORT_SYMBOL(drm_connector_attach_content_protection_property);
-
/**
* drm_mode_create_aspect_ratio_property - create aspect ratio property
* @dev: DRM device
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
index 2f0367d6be64..c1483862c87c 100644
--- a/drivers/gpu/drm/drm_hdcp.c
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -15,6 +15,10 @@
#include
#include
#in
[PATCH v4 03/13] drm: Add Content protection type property
This patch adds a DRM ENUM property to the selected connectors.
This property is used for mentioning the protected content's type
from userspace to kernel HDCP authentication.
Type of the stream is decided by the protected content providers.
Type 0 content can be rendered on any HDCP protected display wires.
But Type 1 content can be rendered only on HDCP2.2 protected paths.
So when a userspace sets this property to Type 1 and starts the HDCP
enable, kernel will honour it only if HDCP2.2 authentication is through
for type 1. Else HDCP enable will be failed.
v2:
cp_content_type is replaced with content_protection_type [daniel]
check at atomic_set_property is removed [Maarten]
v3:
%s/content_protection_type/hdcp_content_type [Pekka]
v4:
property is created for the first requested connector and then reused.
[Danvet]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
drivers/gpu/drm/drm_connector.c | 53 ++-
drivers/gpu/drm/i915/intel_hdcp.c | 4 ++-
include/drm/drm_connector.h | 9 +-
include/drm/drm_mode_config.h | 6
include/uapi/drm/drm_mode.h | 4 +++
6 files changed, 77 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index e52acad9005f..fa50fac2e952 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+ } else if (property == config->hdcp_content_type_property) {
+ state->hdcp_content_type = val;
} else if (property == connector->colorspace_property) {
state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
@@ -822,6 +824,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->scaling_mode;
} else if (property == config->content_protection_property) {
*val = state->content_protection;
+ } else if (property == config->hdcp_content_type_property) {
+ *val = state->hdcp_content_type;
} else if (property == config->writeback_fb_id_property) {
/* Writeback framebuffer is one-shot, write and forget */
*val = 0;
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7c0eda9cca60..03907d13ef66 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -857,6 +857,13 @@ static const struct drm_prop_enum_list hdmi_colorspaces[]
= {
{ DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
};
+static struct drm_prop_enum_list drm_hdcp_content_type_enum_list[] = {
+ { DRM_MODE_HDCP_CONTENT_TYPE0, "HDCP Type0" },
+ { DRM_MODE_HDCP_CONTENT_TYPE1, "HDCP Type1" },
+};
+DRM_ENUM_NAME_FN(drm_get_hdcp_content_type_name,
+drm_hdcp_content_type_enum_list)
+
/**
* DOC: standard connector properties
*
@@ -962,6 +969,23 @@ static const struct drm_prop_enum_list hdmi_colorspaces[]
= {
* the value transitions from ENABLED to DESIRED. This signifies the link
* is no longer protected and userspace should take appropriate action
* (whatever that might be).
+ * HDCP Content Type:
+ * This property is used by the userspace to configure the kernel with
+ * upcoming stream's content type. Content Type of a stream is decided by
+ * the owner of the stream, as HDCP Type0 or HDCP Type1.
+ *
+ * The value of the property can be one the below:
+ * - DRM_MODE_HDCP_CONTENT_TYPE0 = 0
+ * HDCP Type0 streams can be transmitted on a link which is
+ * encrypted with HDCP 1.4 or HDCP 2.2.
+ * - DRM_MODE_HDCP_CONTENT_TYPE1 = 1
+ * HDCP Type1 streams can be transmitted on a link which is
+ * encrypted only with HDCP 2.2.
+ *
+ * Please note this content type is introduced at HDCP 2.2 and used in its
+ * authentication process. If content type is changed when
+ * content_protection is not UNDESIRED, then kernel will disable the HDCP
+ * and re-enable with new type in the same atomic commit
*
* max bpc:
* This range property is used by userspace to limit the bit depth. When
@@ -1520,18 +1544,29 @@
EXPORT_SYMBOL(drm_connector_attach_scaling_mode_property);
* property
*
* @connector: connector to attach CP property on.
+ * @hdcp_content_type: is HDCP Content Type property needed for connector
*
* This is used to add support for content protection on select connectors.
* Content Protection is intentionally vague to allow for different underlying
* technologies, however it is most implemented by HDCP.
*
+ * When hdcp_content_type is true enum property called HDCP Content Type is
+ * created (if
[PATCH v4 06/13] drm: HDCP SRM binary sysfs for subsystem
A common binary sysfs called "hdcp_srm" is created at /sys/class/drm
with only write permission.
SRM table is parsed and stored at drm_hdcp.c, with functions exported
for the services for revocation check from drivers (which
implements the HDCP authentication)
This patch handles the HDCP1.4 and 2.2 versions of SRM table.
Signed-off-by: Ramalingam C
Suggested-by: Daniel Vetter
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_hdcp.c | 351 +
drivers/gpu/drm/drm_internal.h | 4 +
drivers/gpu/drm/drm_sysfs.c| 2 +
include/drm/drm_hdcp.h | 35
5 files changed, 393 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/drm_hdcp.c
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index e630eccb951c..ef6e484c964b 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -19,7 +19,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
- drm_atomic_uapi.o
+ drm_atomic_uapi.o drm_hdcp.o
drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c
new file mode 100644
index ..2f0367d6be64
--- /dev/null
+++ b/drivers/gpu/drm/drm_hdcp.c
@@ -0,0 +1,351 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Intel Corporation.
+ *
+ * Authors:
+ * Ramalingam C
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+struct hdcp_srm {
+ u8 *srm_buf;
+ size_t received_srm_sz;
+ u32 revocated_ksv_cnt;
+ u8 *revocated_ksv_list;
+
+ /* Mutex to protect above struct member */
+ struct mutex mutex;
+} *srm_data;
+
+static inline void drm_hdcp_print_ksv(const char *ksv)
+{
+ DRM_DEBUG("\t%#04x, %#04x, %#04x, %#04x, %#04x\n", *ksv & 0xff,
+ *(ksv + 1) & 0xff, *(ksv + 2) & 0xff, *(ksv + 3) & 0xff,
+ *(ksv + 4) & 0xff);
+}
+
+static u32 drm_hdcp_get_revocated_ksv_count(const char *buf, u32 vrls_length)
+{
+ u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz;
+
+ do {
+ vrl_ksv_cnt = *buf;
+ ksv_count += vrl_ksv_cnt;
+
+ vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1;
+ buf += vrl_sz;
+ parsed_bytes += vrl_sz;
+ } while (parsed_bytes < vrls_length);
+
+ return ksv_count;
+}
+
+static u32 drm_hdcp_get_revocated_ksvs(const char *buf, u8 *revocated_ksv_list,
+ u32 vrls_length)
+{
+ u32 parsed_bytes = 0, ksv_count = 0;
+ u32 vrl_ksv_cnt, vrl_ksv_sz, vrl_idx = 0;
+
+ do {
+ vrl_ksv_cnt = *buf;
+ vrl_ksv_sz = vrl_ksv_cnt * DRM_HDCP_KSV_LEN;
+
+ buf++;
+
+ DRM_DEBUG("vrl: %d, Revoked KSVs: %d\n", vrl_idx++,
+ vrl_ksv_cnt);
+ memcpy(revocated_ksv_list, buf, vrl_ksv_sz);
+
+ ksv_count += vrl_ksv_cnt;
+ revocated_ksv_list += vrl_ksv_sz;
+ buf += vrl_ksv_sz;
+
+ parsed_bytes += (vrl_ksv_sz + 1);
+ } while (parsed_bytes < vrls_length);
+
+ return ksv_count;
+}
+
+static int drm_hdcp_parse_hdcp1_srm(const char *buf, size_t count)
+{
+ struct hdcp_srm_header *header;
+ u32 vrl_length, ksv_count;
+
+ if (count < (sizeof(struct hdcp_srm_header) +
+ DRM_HDCP_1_4_VRL_LENGTH_SIZE + DRM_HDCP_1_4_DCP_SIG_SIZE)) {
+ DRM_ERROR("Invalid blob length\n");
+ return -EINVAL;
+ }
+
+ header = (struct hdcp_srm_header *)buf;
+ mutex_lock(&srm_data->mutex);
+ DRM_DEBUG("SRM ID: 0x%x, SRM Ver: 0x%x, SRM Gen No: 0x%x\n",
+ header->spec_indicator.srm_id,
+ __swab16(header->srm_version), header->srm_gen_no);
+
+ WARN_ON(header->spec_indicator.reserved_hi ||
+ header->spec_indicator.reserved_lo);
+
+ if (header->spec_indicator.srm_id != DRM_HDCP_1_4_SRM_ID) {
+ DRM_ERROR("Invalid srm_id\n");
+ mutex_unlock(&srm_data->mutex);
+ return -EINVAL;
+ }
+
+ buf = buf + sizeof(*header);
+ vrl_length = (*buf << 16 | *(buf + 1) << 8 | *(buf + 2));
+ if (count < (sizeof(struct hdcp_srm_header) + vrl_length) ||
+ vrl_length < (DRM_HDCP_1_4_VRL_LENGTH_SIZE +
+ DRM_HDCP_1_4_DCP_SIG_SIZE)) {
+ DRM_ERROR("Invalid blob length or vrl length\n");
+ mutex_unlock(&srm_data->mutex);
+ return -EINVAL;
+ }
+
+ /* Length of the all vrls combined */
+ vrl_length -= (DRM_HDCP_1_4_VRL_LENGTH_SIZE +
+
